From weijun at openjdk.org  Sat Oct  1 15:02:04 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 1 Oct 2022 15:02:04 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: <azol0p7osOA4BoEFm_2HZT1U9GmKrrF4_vMq3o35hVE=.7e936b3f-a0fa-41e8-bf82-66f977688fd8@github.com>

On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> 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 "../"

Thanks @prrace. And yes, git link is better.

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

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


From darcy at openjdk.org  Sun Oct  2 22:06:20 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 2 Oct 2022 22:06:20 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: <pCQ2BQu90c5Y1unot4E9spU79ReaV4hRXafN0Cfwsjw=.dce5abe4-ef72-412a-874d-dcda57317b6e@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 darcy (Reviewer).

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

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


From jdv at openjdk.org  Mon Oct  3 06:43:20 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 3 Oct 2022 06:43:20 GMT
Subject: RFR: 8278086: [REDO] ImageIO.write() method will throw
 IndexOutOfBoundsException [v2]
In-Reply-To: <hTENGHR5qnfSNQCPiAPCHLsuHXoHcait9pGVQ9EyPrs=.58a20567-4da3-410a-b3aa-a6efb663e3e2@github.com>
References: <m6yQDNwg4jCq1vRHp9i-aaiBjutuSMNboon6xAs8UGQ=.162d3d4c-641f-41d1-8392-ce7bbde96613@github.com>
 <cy1Vkb0CECBWHX0F3DDUdhDFGCKhTZlGZ9y35YGayPo=.144df86a-f0eb-4d1e-9bf2-ccf0955d857d@github.com>
 <hTENGHR5qnfSNQCPiAPCHLsuHXoHcait9pGVQ9EyPrs=.58a20567-4da3-410a-b3aa-a6efb663e3e2@github.com>
Message-ID: <JK7S6_rT-LlBTMF_Kv1wFOYREdt2X-dsqdqNT4fEfYY=.94f65bac-6294-42b4-a402-f613c80f855a@github.com>

On Fri, 30 Sep 2022 20:50:15 GMT, Phil Race <prr 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 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 ?

Hi Phil,

We never had any bpp check to verify what standard bpp's should be allowed in BMP.
Because of this when we tried to decode 2 bpp PNG img and write it to BMP we used to get IOOBE as captured in https://bugs.openjdk.org/browse/JDK-8262297. So under this bug, check was added to allow only standard bpp's for BMP encoding : https://github.com/openjdk/jdk/commit/c73319354399596ab2b9aab0a7f62e8fa0ab9365. 

But this caused regression of many jtreg tests which were using USHORT_555_RGB to encode BMP image(we round off this 15bpp to 16bpp and at later stage : https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java#L472 and store it in 16bit data buffer). So i relaxed this check which caused jtreg regressions to allow 15bpp also.

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

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


From tr at openjdk.org  Mon Oct  3 09:06:18 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 3 Oct 2022 09:06:18 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: <kUZMPIZrxIV_DwysUUCeVlvSfjoSyu1pF7a_OWDzoF8=.cb04237e-c463-4647-9c20-ff310729c2d8@github.com>

On Fri, 30 Sep 2022 07:44:31 GMT, Abhishek Kumar <duke 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?

@kumarabhi006 - Reviewer

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

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


From tr at openjdk.org  Mon Oct  3 09:14:12 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 3 Oct 2022 09:14:12 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
Message-ID: <ZJa-QmWkQcL9wsQ2qQi_QRPUoeP05948LdLyy2HkKoM=.a02697d3-0141-464c-8651-18bb752cc405@github.com>

On Fri, 30 Sep 2022 10:57:37 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.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

@azuev-java Can you please review this PR.

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

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


From aivanov at openjdk.org  Mon Oct  3 11:12:36 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 11:12:36 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
Message-ID: <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>

On Fri, 30 Sep 2022 10:57:37 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.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

You say that the current directory in `JFileChooser` gets set to `null` because of forbidden navigation to a folder which is not traversable. You avoid the NPE by a null-check.

However, you should prevent the current directory to be set to `null`. If navigation is not allowed, the current directory should remain unchanged _instead of being reset to `null`_.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java line 1271:

> 1269:             File curDir = getFileChooser().getCurrentDirectory();
> 1270: 
> 1271:             if (curDir != null && !curDir.equals(f)) {

If `f` is always not null, you can you use `!f.equals(curDir)`.

test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 84:

> 82:         String path = "";
> 83:         if (Platform.isWindows()) {
> 84:             path = "C:" + File.separator + "temp";

It's rare but possible that Windows is installed not on `C:` drive.

test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 114:

> 112:         } else {
> 113:             return false;
> 114:         }

I can be simplified to:
Suggestion:

        return ((filePath != null) && (filePath.isDirectory())
                && filePath.getAbsolutePath().startsWith(basePath));

I'm not insisting though.

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

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


From tr at openjdk.org  Mon Oct  3 11:31:49 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 3 Oct 2022 11:31:49 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
Message-ID: <vvX-NoTTOvgWbXY8228J0siOiAqBQbZU0203QFcan04=.5fedf288-711e-46e2-895a-6ce9fc1e4777@github.com>

On Mon, 3 Oct 2022 11:02:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java line 1271:
> 
>> 1269:             File curDir = getFileChooser().getCurrentDirectory();
>> 1270: 
>> 1271:             if (curDir != null && !curDir.equals(f)) {
> 
> If `f` is always not null, you can you use `!f.equals(curDir)`.

> 

Prevention of not setting to null means I have to modify `JFileChooser` class itself, so just handling here. And yeah` f `can't be null, can do that.

> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 114:
> 
>> 112:         } else {
>> 113:             return false;
>> 114:         }
> 
> I can be simplified to:
> Suggestion:
> 
>         return ((filePath != null) && (filePath.isDirectory())
>                 && filePath.getAbsolutePath().startsWith(basePath));
> 
> I'm not insisting though.

Can be done, no issues.

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

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


From tr at openjdk.org  Mon Oct  3 11:34:46 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 3 Oct 2022 11:34:46 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
Message-ID: <CF_HYeww7iVgYnnge_d64a1bixwL9zgsiufcMgMPfCs=.cbf4683b-a74d-466e-976b-688a093f97d5@github.com>

On Mon, 3 Oct 2022 11:06:14 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 84:
> 
>> 82:         String path = "";
>> 83:         if (Platform.isWindows()) {
>> 84:             path = "C:" + File.separator + "temp";
> 
> It's rare but possible that Windows is installed not on `C:` drive.

Since temp will be better option without creating any new directory for the test, I didn't change it (it was reused from JBS report). Any other alternative......?

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

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


From aivanov at openjdk.org  Mon Oct  3 11:39:36 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 11:39:36 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <vvX-NoTTOvgWbXY8228J0siOiAqBQbZU0203QFcan04=.5fedf288-711e-46e2-895a-6ce9fc1e4777@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
 <vvX-NoTTOvgWbXY8228J0siOiAqBQbZU0203QFcan04=.5fedf288-711e-46e2-895a-6ce9fc1e4777@github.com>
Message-ID: <g7KCKfHvpg8X-NoqSbDl2AjXV0DB7PPhPKJB6OSdvaA=.8fcd7854-46a5-4992-98b9-0ebf466ff4d0@github.com>

On Mon, 3 Oct 2022 11:28:09 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java line 1271:
>> 
>>> 1269:             File curDir = getFileChooser().getCurrentDirectory();
>>> 1270: 
>>> 1271:             if (curDir != null && !curDir.equals(f)) {
>> 
>> If `f` is always not null, you can you use `!f.equals(curDir)`.
>
>> 
> 
> Prevention of not setting to null means I have to modify `JFileChooser` class itself, so just handling here. And yeah` f `can't be null, can do that.

Why is it bad to modify `JFileChooser` class itself?

I think setting the current directory to `null` while it displays a directory kind of breaks the invariant.

`JFileChooser` navigated to a directory and the current directory is set to it. You tried navigating to another directory, `FileSystem` didn't allow the navigation, so `JFileChooser` continues to display the files in the directory that is showed before. Thus, the current directory hasn't changed. From this point of view, the current directory should remain unchanged.

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

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


From tr at openjdk.org  Mon Oct  3 11:46:23 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 3 Oct 2022 11:46:23 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <g7KCKfHvpg8X-NoqSbDl2AjXV0DB7PPhPKJB6OSdvaA=.8fcd7854-46a5-4992-98b9-0ebf466ff4d0@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
 <vvX-NoTTOvgWbXY8228J0siOiAqBQbZU0203QFcan04=.5fedf288-711e-46e2-895a-6ce9fc1e4777@github.com>
 <g7KCKfHvpg8X-NoqSbDl2AjXV0DB7PPhPKJB6OSdvaA=.8fcd7854-46a5-4992-98b9-0ebf466ff4d0@github.com>
Message-ID: <aCT4duM6lzakXt1PZy_-Bk5PLmuvMTOfTDAUMHUCYoE=.d25c2b5f-a654-493b-970e-478dac203e18@github.com>

On Mon, 3 Oct 2022 11:37:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> 
>> 
>> Prevention of not setting to null means I have to modify `JFileChooser` class itself, so just handling here. And yeah` f `can't be null, can do that.
>
> Why is it bad to modify `JFileChooser` class itself?
> 
> I think setting the current directory to `null` while it displays a directory kind of breaks the invariant.
> 
> `JFileChooser` navigated to a directory and the current directory is set to it. You tried navigating to another directory, `FileSystem` didn't allow the navigation, so `JFileChooser` continues to display the files in the directory that is showed before. Thus, the current directory hasn't changed. From this point of view, the current directory should remain unchanged.

https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L608
Here the above logic checks if the current selected directory is traversable and if not it goes up to parent directory till top level and when every check fails then null is set to `currentDirectory`. Should we think of modifying this logic to not to set to null, rather remain in previously valid folder......?

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

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


From aivanov at openjdk.org  Mon Oct  3 11:49:24 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 11:49:24 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <CF_HYeww7iVgYnnge_d64a1bixwL9zgsiufcMgMPfCs=.cbf4683b-a74d-466e-976b-688a093f97d5@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
 <CF_HYeww7iVgYnnge_d64a1bixwL9zgsiufcMgMPfCs=.cbf4683b-a74d-466e-976b-688a093f97d5@github.com>
Message-ID: <NhIhwpydtvLFaaVypTlb51uInHO8LxgTv3v2OzC_vvE=.e0c9a4be-be6e-4122-96b4-c9f0a42157cc@github.com>

On Mon, 3 Oct 2022 11:32:17 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 84:
>> 
>>> 82:         String path = "";
>>> 83:         if (Platform.isWindows()) {
>>> 84:             path = "C:" + File.separator + "temp";
>> 
>> It's rare but possible that Windows is installed not on `C:` drive.
>
> Since temp will be better option without creating any new directory for the test, I didn't change it (it was reused from JBS report). Any other alternative......?

Why not request the path to the system temporary directory?

Temporary directory on Windows is not located in `C:\temp`. Likely this folder does not exist. You should use `TMP` or `TEMP` environment variable. Alternatively, you can use `createTempFile` from from [`java.io.File`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/File.html#createTempFile(java.lang.String,java.lang.String)) or [`java.nio.Files`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Files.html#createTempFile(java.lang.String,java.lang.String,java.nio.file.attribute.FileAttribute...)) to create a file in the temp directory, its parent is the path to the temp directory.

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

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


From aivanov at openjdk.org  Mon Oct  3 11:53:24 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 11:53:24 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <NhIhwpydtvLFaaVypTlb51uInHO8LxgTv3v2OzC_vvE=.e0c9a4be-be6e-4122-96b4-c9f0a42157cc@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
 <CF_HYeww7iVgYnnge_d64a1bixwL9zgsiufcMgMPfCs=.cbf4683b-a74d-466e-976b-688a093f97d5@github.com>
 <NhIhwpydtvLFaaVypTlb51uInHO8LxgTv3v2OzC_vvE=.e0c9a4be-be6e-4122-96b4-c9f0a42157cc@github.com>
Message-ID: <pXff3tKo16_BupmrK1tJm8YMzMxpFz5P3NMM6cCLgnE=.19c51347-2f57-459d-ad1b-7194cce1488f@github.com>

On Mon, 3 Oct 2022 11:47:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Since temp will be better option without creating any new directory for the test, I didn't change it (it was reused from JBS report). Any other alternative......?
>
> Why not request the path to the system temporary directory?
> 
> Temporary directory on Windows is not located in `C:\temp`. Likely this folder does not exist. You should use `TMP` or `TEMP` environment variable. Alternatively, you can use `createTempFile` from from [`java.io.File`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/File.html#createTempFile(java.lang.String,java.lang.String)) or [`java.nio.Files`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Files.html#createTempFile(java.lang.String,java.lang.String,java.nio.file.attribute.FileAttribute...)) to create a file in the temp directory, its parent is the path to the temp directory.

User's home could be a better option. It's guaranteed to exist, `user.home` system property points to it. And it's a more real-life scenario.

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

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


From tr at openjdk.org  Mon Oct  3 12:00:20 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 3 Oct 2022 12:00:20 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <pXff3tKo16_BupmrK1tJm8YMzMxpFz5P3NMM6cCLgnE=.19c51347-2f57-459d-ad1b-7194cce1488f@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
 <CF_HYeww7iVgYnnge_d64a1bixwL9zgsiufcMgMPfCs=.cbf4683b-a74d-466e-976b-688a093f97d5@github.com>
 <NhIhwpydtvLFaaVypTlb51uInHO8LxgTv3v2OzC_vvE=.e0c9a4be-be6e-4122-96b4-c9f0a42157cc@github.com>
 <pXff3tKo16_BupmrK1tJm8YMzMxpFz5P3NMM6cCLgnE=.19c51347-2f57-459d-ad1b-7194cce1488f@github.com>
Message-ID: <MuinxMf75JAPbCYcu7TVmy3ECrg9io2AmInpsJgncws=.c0cb475d-345a-4578-997b-82c99358dd19@github.com>

On Mon, 3 Oct 2022 11:49:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Why not request the path to the system temporary directory?
>> 
>> Temporary directory on Windows is not located in `C:\temp`. Likely this folder does not exist. You should use `TMP` or `TEMP` environment variable. Alternatively, you can use `createTempFile` from from [`java.io.File`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/File.html#createTempFile(java.lang.String,java.lang.String)) or [`java.nio.Files`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Files.html#createTempFile(java.lang.String,java.lang.String,java.nio.file.attribute.FileAttribute...)) to create a file in the temp directory, its parent is the path to the temp directory.
>
> User's home could be a better option. It's guaranteed to exist, `user.home` system property points to it. And it's a more real-life scenario.

Then I can just make user.home directory as the only traversable.......?

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

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


From aivanov at openjdk.org  Mon Oct  3 12:05:19 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 12:05:19 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <aCT4duM6lzakXt1PZy_-Bk5PLmuvMTOfTDAUMHUCYoE=.d25c2b5f-a654-493b-970e-478dac203e18@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
 <vvX-NoTTOvgWbXY8228J0siOiAqBQbZU0203QFcan04=.5fedf288-711e-46e2-895a-6ce9fc1e4777@github.com>
 <g7KCKfHvpg8X-NoqSbDl2AjXV0DB7PPhPKJB6OSdvaA=.8fcd7854-46a5-4992-98b9-0ebf466ff4d0@github.com>
 <aCT4duM6lzakXt1PZy_-Bk5PLmuvMTOfTDAUMHUCYoE=.d25c2b5f-a654-493b-970e-478dac203e18@github.com>
Message-ID: <IeZgo_VXamPXcm-Lp17oALmeDLVM8MPSWpV7cke0Dz0=.aae474b1-10c5-45aa-b966-14da2952ec36@github.com>

On Mon, 3 Oct 2022 11:42:36 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Why is it bad to modify `JFileChooser` class itself?
>> 
>> I think setting the current directory to `null` while it displays a directory kind of breaks the invariant.
>> 
>> `JFileChooser` navigated to a directory and the current directory is set to it. You tried navigating to another directory, `FileSystem` didn't allow the navigation, so `JFileChooser` continues to display the files in the directory that is showed before. Thus, the current directory hasn't changed. From this point of view, the current directory should remain unchanged.
>
> https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L608
> Here the above logic checks if the current selected directory is traversable and if not it goes up to parent directory till top level and when every check fails then null is set to `currentDirectory`. Should we think of modifying this logic to not to set to null, rather remain in previously valid folder......?

Well, the logic there tries to prevent the current directory from becoming `null`. Yet it traverses up the tree:
https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L603-L607

Probably, if `dir` becomes `null` in the end, it should resort to its default behaviour: `getFileSystemView().getDefaultDirectory()`. Or not change at all?

Then, you can handle the situation here: if `getFileChooser().getCurrentDirectory()` returns `null`, restore the previous current directory.

And what about other L&F? If the same code runs in Windows L&F, Nimbus L&F, any other?

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

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


From aivanov at openjdk.org  Mon Oct  3 12:05:21 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 12:05:21 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <MuinxMf75JAPbCYcu7TVmy3ECrg9io2AmInpsJgncws=.c0cb475d-345a-4578-997b-82c99358dd19@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
 <CF_HYeww7iVgYnnge_d64a1bixwL9zgsiufcMgMPfCs=.cbf4683b-a74d-466e-976b-688a093f97d5@github.com>
 <NhIhwpydtvLFaaVypTlb51uInHO8LxgTv3v2OzC_vvE=.e0c9a4be-be6e-4122-96b4-c9f0a42157cc@github.com>
 <pXff3tKo16_BupmrK1tJm8YMzMxpFz5P3NMM6cCLgnE=.19c51347-2f57-459d-ad1b-7194cce1488f@github.com>
 <MuinxMf75JAPbCYcu7TVmy3ECrg9io2AmInpsJgncws=.c0cb475d-345a-4578-997b-82c99358dd19@github.com>
Message-ID: <AxFTPnmGcRXxnC-1fGOxGfO_42jB74nS3ek8USGdaU4=.b3da06a0-a6f9-4e78-acb4-c9f5a9dabed3@github.com>

On Mon, 3 Oct 2022 11:56:25 GMT, Tejesh R <tr at openjdk.org> wrote:

>> User's home could be a better option. It's guaranteed to exist, `user.home` system property points to it. And it's a more real-life scenario.
>
> Then I can just make user.home directory as the only traversable.......?

Makes sense to me.

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

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


From tr at openjdk.org  Mon Oct  3 12:09:22 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 3 Oct 2022 12:09:22 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <IeZgo_VXamPXcm-Lp17oALmeDLVM8MPSWpV7cke0Dz0=.aae474b1-10c5-45aa-b966-14da2952ec36@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
 <vvX-NoTTOvgWbXY8228J0siOiAqBQbZU0203QFcan04=.5fedf288-711e-46e2-895a-6ce9fc1e4777@github.com>
 <g7KCKfHvpg8X-NoqSbDl2AjXV0DB7PPhPKJB6OSdvaA=.8fcd7854-46a5-4992-98b9-0ebf466ff4d0@github.com>
 <aCT4duM6lzakXt1PZy_-Bk5PLmuvMTOfTDAUMHUCYoE=.d25c2b5f-a654-493b-970e-478dac203e18@github.com>
 <IeZgo_VXamPXcm-Lp17oALmeDLVM8MPSWpV7cke0Dz0=.aae474b1-10c5-45aa-b966-14da2952ec36@github.com>
Message-ID: <Y4K5FZji8MQVhs8ZgKc24JI_kLgKBikNkPlKmEZJXA8=.563c2715-ae53-4a46-b550-c0d7f2b0803d@github.com>

On Mon, 3 Oct 2022 12:00:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L608
>> Here the above logic checks if the current selected directory is traversable and if not it goes up to parent directory till top level and when every check fails then null is set to `currentDirectory`. Should we think of modifying this logic to not to set to null, rather remain in previously valid folder......?
>
> Well, the logic there tries to prevent the current directory from becoming `null`. Yet it traverses up the tree:
> https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L603-L607
> 
> Probably, if `dir` becomes `null` in the end, it should resort to its default behaviour: `getFileSystemView().getDefaultDirectory()`. Or not change at all?
> 
> Then, you can handle the situation here: if `getFileChooser().getCurrentDirectory()` returns `null`, restore the previous current directory.
> 
> And what about other L&F? If the same code runs in Windows L&F, Nimbus L&F, any other?

In other L&F the same problem exist, but NPE is does not occurs because previous state check is not done, directly the clicked file is been set. 
https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java#L1328

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

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


From aivanov at openjdk.org  Mon Oct  3 12:13:24 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 12:13:24 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <Y4K5FZji8MQVhs8ZgKc24JI_kLgKBikNkPlKmEZJXA8=.563c2715-ae53-4a46-b550-c0d7f2b0803d@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
 <vvX-NoTTOvgWbXY8228J0siOiAqBQbZU0203QFcan04=.5fedf288-711e-46e2-895a-6ce9fc1e4777@github.com>
 <g7KCKfHvpg8X-NoqSbDl2AjXV0DB7PPhPKJB6OSdvaA=.8fcd7854-46a5-4992-98b9-0ebf466ff4d0@github.com>
 <aCT4duM6lzakXt1PZy_-Bk5PLmuvMTOfTDAUMHUCYoE=.d25c2b5f-a654-493b-970e-478dac203e18@github.com>
 <IeZgo_VXamPXcm-Lp17oALmeDLVM8MPSWpV7cke0Dz0=.aae474b1-10c5-45aa-b966-14da2952ec36@github.com>
 <Y4K5FZji8MQVhs8ZgKc24JI_kLgKBikNkPlKmEZJXA8=.563c2715-ae53-4a46-b550-c0d7f2b0803d@github.com>
Message-ID: <8ObsdiR4UJkawXd_FXCXrKyjwvq6tFneOrF5CkTU8po=.9526541a-44a8-46f7-8f13-147e7d8dad71@github.com>

On Mon, 3 Oct 2022 12:07:10 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Well, the logic there tries to prevent the current directory from becoming `null`. Yet it traverses up the tree:
>> https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L603-L607
>> 
>> Probably, if `dir` becomes `null` in the end, it should resort to its default behaviour: `getFileSystemView().getDefaultDirectory()`. Or not change at all?
>> 
>> Then, you can handle the situation here: if `getFileChooser().getCurrentDirectory()` returns `null`, restore the previous current directory.
>> 
>> And what about other L&F? If the same code runs in Windows L&F, Nimbus L&F, any other?
>
> In other L&F the same problem exist, but NPE is does not occurs because previous state check is not done, directly the clicked file is been set. 
> https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java#L1328

> Well, the logic there tries to prevent the current directory from becoming `null`. Yet it traverses up the tree:
> 
> https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L603-L607
> 
> Probably, if `dir` becomes `null` in the end, it should resort to its default behaviour: `getFileSystemView().getDefaultDirectory()`. Or not change at all?

This behaviour is specified. https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L576-L580

Yet it doesn't take into account a custom implementation of `FileSystem` which does not allow navigating up. It may be a problem in `FileSystem` implementation.

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

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


From aivanov at openjdk.org  Mon Oct  3 12:17:32 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 12:17:32 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <8ObsdiR4UJkawXd_FXCXrKyjwvq6tFneOrF5CkTU8po=.9526541a-44a8-46f7-8f13-147e7d8dad71@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
 <vvX-NoTTOvgWbXY8228J0siOiAqBQbZU0203QFcan04=.5fedf288-711e-46e2-895a-6ce9fc1e4777@github.com>
 <g7KCKfHvpg8X-NoqSbDl2AjXV0DB7PPhPKJB6OSdvaA=.8fcd7854-46a5-4992-98b9-0ebf466ff4d0@github.com>
 <aCT4duM6lzakXt1PZy_-Bk5PLmuvMTOfTDAUMHUCYoE=.d25c2b5f-a654-493b-970e-478dac203e18@github.com>
 <IeZgo_VXamPXcm-Lp17oALmeDLVM8MPSWpV7cke0Dz0=.aae474b1-10c5-45aa-b966-14da2952ec36@github.com>
 <Y4K5FZji8MQVhs8ZgKc24JI_kLgKBikNkPlKmEZJXA8=.563c2715-ae53-4a46-b550-c0d7f2b0803d@github.com>
 <8ObsdiR4UJkawXd_FXCXrKyjwvq6tFneOrF5CkTU8po=.9526541a-44a8-46f7-8f13-147e7d8dad71@github.com>
Message-ID: <qUdcH7tD7h8ZzySAxpmZ-jH6RCbkZ9-M_v75F-TXI04=.ba0c7373-e716-4723-826c-4d918997c41b@github.com>

On Mon, 3 Oct 2022 12:09:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> In other L&F the same problem exist, but NPE is does not occurs because previous state check is not done, directly the clicked file is been set. 
>> https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java#L1328
>
>> Well, the logic there tries to prevent the current directory from becoming `null`. Yet it traverses up the tree:
>> 
>> https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L603-L607
>> 
>> Probably, if `dir` becomes `null` in the end, it should resort to its default behaviour: `getFileSystemView().getDefaultDirectory()`. Or not change at all?
> 
> This behaviour is specified. https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L576-L580
> 
> Yet it doesn't take into account a custom implementation of `FileSystem` which does not allow navigating up. It may be a problem in `FileSystem` implementation.

> In other L&F the same problem exist, but NPE is does not occurs because previous state check is not done, directly the clicked file is been set.
> 
> https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java#L1328

Maybe it's the way to go for Metal too? I mean call `setCurrentDirectory` unconditionally.

What do other L&Fs do?

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

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


From aivanov at openjdk.org  Mon Oct  3 12:28:46 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 12:28:46 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: <2bRWmn9tz1W2Hc6L-EQgVmw7UzVz38XMGoo71uA1HEc=.6a744d13-98cd-4a9b-9a43-7bbc09ed7be1@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.

src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java line 958:

> 956:                 int index = bidiRoot.getElementIndex(p0);
> 957:                 Element bidiElem = bidiRoot.getElement(index);
> 958:                 if (bidiElem != null && bidiElem.getEndOffset() >= p1) {

Is it possible that `bidiElem` is `null`? It should never be. If it is, it is a bug in the code and throwing NPE seems good ? it will be the indication of the bug.

Since the NPE has never been thrown from this code, I'd rather leave it unchanged here.

src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java line 2325:

> 2323:             int src = Math.abs(offset + length);
> 2324:             int nmove = Math.abs(nchildren - src);
> 2325:             int dest = Math.abs(src + delta);

I'm rather unsure why any of these could become negative. Would it be possible that using `Math.abs` corrupts the document or leads to a data loss?

The thing is the `UndoableEdit` was produced while the document and the component didn't have `bidi` set to `true`. Inserting a right-to-left text changes that situation, and `bidiRoot` starts to contain elements. I assume changing the component orientation also modifies the contents of `bidiRoot`. As such, performing the undo operation may become impossible because the recorded state in the `UndoableEdit` is inconsistent with the current state of the document.

test/jdk/javax/swing/text/AbstractDocument/TestUndoError.java line 39:

> 37: import javax.swing.undo.UndoManager;
> 38: 
> 39: public class TestUndoError {

`TestUndoInsertArabicText`? It's more specific this way.

test/jdk/javax/swing/text/AbstractDocument/TestUndoError.java line 42:

> 40: 
> 41:     private static JTextArea textArea_;
> 42:     private static UndoManager manager_;

Is the underscore necessary at the end of the field names?

test/jdk/javax/swing/text/AbstractDocument/TestUndoError.java line 51:

> 49:                 textArea_ = new JTextArea();
> 50:                 manager_ = new UndoManager();
> 51:                 frame = new JFrame("Undo - Redo Error");

Is `frame` even required? Using `textArea` should be enough.

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

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


From jdv at openjdk.org  Mon Oct  3 14:09:05 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 3 Oct 2022 14:09:05 GMT
Subject: RFR: 8270915: GIFImageReader disregards ignoreMetadata flag which
 causes memory exhaustion
Message-ID: <MNVf1oMbzOO8Zpyk551X7bNJQeGsUbHiyC8kBKsuixw=.fd9b04d2-5cce-4dd7-9b49-15042925743c@github.com>

In https://bugs.openjdk.org/browse/JDK-8270915 we have a valid GIF image which was generated using a third party app, but it contains large amount of Metadata(numerous Application extension blocks).

Also GIFImageReader doesn't use ignoreMetadata flag set by user while reading Metadata which causes heavy memory usage in this scenario. We need to provide support for ignoring metadata in GIFImageReader, so readMetadata() is updated to use the "ignoreMetadata" flag and ignore all blocks except "Image Descriptor" and "Graphics Control Extension".

I have updated readMedata() to also use ReaderUtil.staggeredReadByteStream() where we are allocating upfront memory based on parameters from metadata. Also this PR has small refactoring of import statements.

To replicate the bug we need byte stream with large amount of valid metadata, so i am not able to add regression test case.

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

Commit messages:
 - Fix indentation
 - Use Staggered read instead of readFully in readMetadata()
 - Fix extra blocksize logic
 - Update concatenateBlocks logic
 - Initial working change

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

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


From tr at openjdk.org  Mon Oct  3 14:50:18 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 3 Oct 2022 14:50:18 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <qUdcH7tD7h8ZzySAxpmZ-jH6RCbkZ9-M_v75F-TXI04=.ba0c7373-e716-4723-826c-4d918997c41b@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
 <vvX-NoTTOvgWbXY8228J0siOiAqBQbZU0203QFcan04=.5fedf288-711e-46e2-895a-6ce9fc1e4777@github.com>
 <g7KCKfHvpg8X-NoqSbDl2AjXV0DB7PPhPKJB6OSdvaA=.8fcd7854-46a5-4992-98b9-0ebf466ff4d0@github.com>
 <aCT4duM6lzakXt1PZy_-Bk5PLmuvMTOfTDAUMHUCYoE=.d25c2b5f-a654-493b-970e-478dac203e18@github.com>
 <IeZgo_VXamPXcm-Lp17oALmeDLVM8MPSWpV7cke0Dz0=.aae474b1-10c5-45aa-b966-14da2952ec36@github.com>
 <Y4K5FZji8MQVhs8ZgKc24JI_kLgKBikNkPlKmEZJXA8=.563c2715-ae53-4a46-b550-c0d7f2b0803d@github.com>
 <8ObsdiR4UJkawXd_FXCXrKyjwvq6tFneOrF5CkTU8po=.9526541a-44a8-46f7-8f13-147e7d8dad71@github.com>
 <qUdcH7tD7h8ZzySAxpmZ-jH6RCbkZ9-M_v75F-TXI04=.ba0c7373-e716-4723-826c-4d918997c41b@github.com>
Message-ID: <xTHfXR6cFPqsdpkbm4q-ARB9aWs1Qfrzyzye02sjAbw=.767edad7-c33e-4750-af06-40942ef04a85@github.com>

On Mon, 3 Oct 2022 12:13:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Well, the logic there tries to prevent the current directory from becoming `null`. Yet it traverses up the tree:
>>> 
>>> https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L603-L607
>>> 
>>> Probably, if `dir` becomes `null` in the end, it should resort to its default behaviour: `getFileSystemView().getDefaultDirectory()`. Or not change at all?
>> 
>> This behaviour is specified. https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L576-L580
>> 
>> Yet it doesn't take into account a custom implementation of `FileSystem` which does not allow navigating up. It may be a problem in `FileSystem` implementation.
>
>> In other L&F the same problem exist, but NPE is does not occurs because previous state check is not done, directly the clicked file is been set.
>> 
>> https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java#L1328
> 
> Maybe it's the way to go for Metal too? I mean call `setCurrentDirectory` unconditionally.
> 
> What do other L&Fs do?

In other L&F, null gets assigned to `currentDirectory` and NPE doesn't occur since that previous directory check is not done.

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

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


From aivanov at openjdk.org  Mon Oct  3 15:00:17 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 15:00:17 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <xTHfXR6cFPqsdpkbm4q-ARB9aWs1Qfrzyzye02sjAbw=.767edad7-c33e-4750-af06-40942ef04a85@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
 <vvX-NoTTOvgWbXY8228J0siOiAqBQbZU0203QFcan04=.5fedf288-711e-46e2-895a-6ce9fc1e4777@github.com>
 <g7KCKfHvpg8X-NoqSbDl2AjXV0DB7PPhPKJB6OSdvaA=.8fcd7854-46a5-4992-98b9-0ebf466ff4d0@github.com>
 <aCT4duM6lzakXt1PZy_-Bk5PLmuvMTOfTDAUMHUCYoE=.d25c2b5f-a654-493b-970e-478dac203e18@github.com>
 <IeZgo_VXamPXcm-Lp17oALmeDLVM8MPSWpV7cke0Dz0=.aae474b1-10c5-45aa-b966-14da2952ec36@github.com>
 <Y4K5FZji8MQVhs8ZgKc24JI_kLgKBikNkPlKmEZJXA8=.563c2715-ae53-4a46-b550-c0d7f2b0803d@github.com>
 <8ObsdiR4UJkawXd_FXCXrKyjwvq6tFneOrF5CkTU8po=.9526541a-44a8-46f7-8f13-147e7d8dad71@github.com>
 <qUdcH7tD7h8ZzySAxpmZ-jH6RCbkZ9-M_v75F-TXI04=.ba0c7373-e716-4723-826c-4d918997c41b@github.com>
 <xTHfXR6cFPqsdpkbm4q-ARB9aWs1Qfrzyzy
 e02sjAbw=.767edad7-c33e-4750-af06-40942ef04a85@github.com>
Message-ID: <59MrYlRrNbNfDkq5YDrXTxf-S-enC_P0dltSBc0BPUc=.8241456c-6efe-4a63-a589-9bf8a0c507e0@github.com>

On Mon, 3 Oct 2022 14:48:04 GMT, Tejesh R <tr at openjdk.org> wrote:

> ? NPE doesn't occur since that previous directory check is not done.

Then I suggest going this way and just drop the checks from Metal L&F.

The test should set Metal L&F explicitly. Or better yet, it should be run in all L&Fs to ensure NPE isn't thrown.

<hr>

As for preserving the current value of `currentDirectory` if the passed in folder cannot be navigated to. I think it should be done yet it's a separate issue from this one. Shall I submit a new bug? Does anyone have an opinion on this?

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

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


From aivanov at openjdk.org  Mon Oct  3 15:28:16 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 15:28:16 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
Message-ID: <hhovPbK-E9zFYe8naRtdI0KrJNjieKGKklq8qW1ygY4=.f4ae4916-f4b0-432d-a5f6-02ef66edd307@github.com>

On Fri, 30 Sep 2022 10:57:37 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.
>
> 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/FileViewNPETest.java line 40:

> 38:  * @bug 6616245
> 39:  * @key headful
> 40:  * @requires (os.family == "windows" | os.family == "linux")

Is there a specific reason to exclude macOS? Is it only because the default L&F isn't Metal?

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

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


From aivanov at openjdk.org  Mon Oct  3 15:55:22 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 15:55:22 GMT
Subject: RFR: 5080391: ArrayIndexOutOfBounds during "undo" of Right-to-Left
 text insert
In-Reply-To: <svg5hS5K-OQR_85YRGgk-FHqujyV3X1R5Sj2CLfegac=.23cfd45c-56b0-44e3-ae11-832d05c07397@github.com>
References: <6RcEPyVsdn3GAryyi2QYk3OGfPDUGxFD-W0c_2s8iH4=.b10fa89b-07b7-4e8b-858f-1311d0ffeaae@github.com>
 <svg5hS5K-OQR_85YRGgk-FHqujyV3X1R5Sj2CLfegac=.23cfd45c-56b0-44e3-ae11-832d05c07397@github.com>
Message-ID: <Y4SMriLZe1UzdmzEBjjuIYTkjBlUBM1x8tPfEnIbezc=.112d7fc8-2b64-4314-90ba-dba565c26417@github.com>

On Fri, 30 Sep 2022 20:44:03 GMT, Phil Race <prr at openjdk.org> wrote:

> 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.

And with some text being inserted in the middle of existing text in the document.

I also wonder if changing component orientation breaks undo/redo with left-to-right text only since RTL component orientation enables bidi support.

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

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


From aivanov at openjdk.org  Mon Oct  3 16:09:20 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 16:09:20 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails
In-Reply-To: <KT0UHwEiZuPO2uS1XWDJrlk1wFRdEsgVs1b_IBR3kSM=.2c862a0b-3222-485e-b713-bdd12a7f4097@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>
 <KT0UHwEiZuPO2uS1XWDJrlk1wFRdEsgVs1b_IBR3kSM=.2c862a0b-3222-485e-b713-bdd12a7f4097@github.com>
Message-ID: <totUL5_2P1GiiDSP3wNt_EyGEZBosBgroBsHk1EqJhc=.968bb83e-b446-4e41-84f7-981d78911e17@github.com>

On Wed, 28 Sep 2022 09:51:08 GMT, Alexey Ivanov <aivanov 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
>
>> 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.

I suggest amending `setSelectionInterval` to throw IOOBE if `Integer.MAX_VALUE` is passed.

Then I suggest amending `removeIndexInterval` to throw IOOBE if a negative value is passed or an index is `Integer.MAX_VALUE`. Explicit handling of negative values could be an optimisation made in addition to handling `MAX_VALUE`.

In both cases, the spec needs to be updated, and therefore the CSR will be required.

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

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


From tr at openjdk.org  Mon Oct  3 16:36:23 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 3 Oct 2022 16:36:23 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <hhovPbK-E9zFYe8naRtdI0KrJNjieKGKklq8qW1ygY4=.f4ae4916-f4b0-432d-a5f6-02ef66edd307@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <hhovPbK-E9zFYe8naRtdI0KrJNjieKGKklq8qW1ygY4=.f4ae4916-f4b0-432d-a5f6-02ef66edd307@github.com>
Message-ID: <NFqU4oxo-9fiYaS3Lvdn3xFdHtj4PV1ikw3bj455gxQ=.4cb1bfb3-8bc6-47a6-8e55-dd791c719fa4@github.com>

On Mon, 3 Oct 2022 15:24:43 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 40:
> 
>> 38:  * @bug 6616245
>> 39:  * @key headful
>> 40:  * @requires (os.family == "windows" | os.family == "linux")
> 
> Is there a specific reason to exclude macOS? Is it only because the default L&F isn't Metal?

Yeah, was not able to reproduce in macOS.

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

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


From jdv at openjdk.org  Mon Oct  3 16:42:21 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 3 Oct 2022 16:42:21 GMT
Subject: RFR: 8292280: Unused field 'keyListener' in BasicRadioButtonUI
 [v2]
In-Reply-To: <Mh3c2YhtqAjZHkF466CILvxcIuAk_Ui7ESMvD7aOVU0=.4b23cb63-6f38-4bad-8dde-5fdde200e0a2@github.com>
References: <IWbq6Zr-IcRpKs5_IQvKnEL-8lEc9OVxS9GrGkA9t38=.126f3214-32d2-4fef-9505-d61f157d22fb@github.com>
 <Mh3c2YhtqAjZHkF466CILvxcIuAk_Ui7ESMvD7aOVU0=.4b23cb63-6f38-4bad-8dde-5fdde200e0a2@github.com>
Message-ID: <_WbjCmOnO-1uxsCJWFWqfmbTXzG33DJc7Uyc7wgP1MA=.5d4e8258-c888-495b-9927-21db218e0002@github.com>

On Sun, 21 Aug 2022 21:40:43 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Field `keyListener` was added under [JDK-8033699](https://bugs.openjdk.org/browse/JDK-8033699). But then all its usages were removed in [JDK-8249548](https://bugs.openjdk.org/browse/JDK-8249548)
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292280: Unused field 'keyListener' in BasicRadioButtonUI
>   
>   reverted unrelated changes

Verified build with change. LGTM.

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

Marked as reviewed by jdv (Reviewer).

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


From dnguyen at openjdk.org  Mon Oct  3 17:00:22 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 3 Oct 2022 17:00:22 GMT
Subject: RFR: 8292214: Memory leak in getAllConfigs of
 awt_GraphicsEnv.c:386 [v2]
In-Reply-To: <DLbk4bvKzqMPSS9pMCgUFCB_PmTnMpJ9Ua8GnoP92dc=.38fa8b6b-279d-4d04-ae5b-4a43e573b6f4@github.com>
References: <1gj0XMmbPLGkiWBwJ09LeKvujGCrLa45Qm5utSp-dCI=.1c9f3e8d-4ef4-4e4e-8a57-cd288645b961@github.com>
 <kFLmxT7O_yBBjqAU_la48ZaHBNi9ark3rAnDZU7zzjg=.a36db9ef-99d2-428b-8611-485b1dc9cbe5@github.com>
 <DLbk4bvKzqMPSS9pMCgUFCB_PmTnMpJ9Ua8GnoP92dc=.38fa8b6b-279d-4d04-ae5b-4a43e573b6f4@github.com>
Message-ID: <c04S77xY55yAp1igRH9hamNQcJzBeVv0u9hbIPgAypU=.cf52ee11-b2cd-486d-a6f3-1f2a6c0b08e4@github.com>

On Fri, 30 Sep 2022 14:46:35 GMT, Alexander Zvegintsev <azvegint 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 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.

I tried building without the new int i and it does seem to be fine. Probably worth it to follow the rest of the class's format and reuse the i var for getAllConfigs.

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

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


From jdv at openjdk.org  Mon Oct  3 17:18:29 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 3 Oct 2022 17:18:29 GMT
Subject: RFR: 8292309 : Fix
 java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java test
 [v3]
In-Reply-To: <pj-9Z23sskoEF5GTDQfp_n-xFTZSQ9JfEpTL4M5thwA=.247a77a6-6cb0-4741-bdc6-adce5254bf2a@github.com>
References: <uFqQUzkuWOrGXowhXEwVwRN5HjCisrPLGNK-rpaUyUc=.6c97b5ba-e463-45d1-8cb4-e4799148e212@github.com>
 <pj-9Z23sskoEF5GTDQfp_n-xFTZSQ9JfEpTL4M5thwA=.247a77a6-6cb0-4741-bdc6-adce5254bf2a@github.com>
Message-ID: <UKSDJTMtJKrxkR_qCWkXcUo0qBCCmHhAis23B9N1Jxs=.7780ee8a-b89f-4ca0-86e2-5f8b05c75c88@github.com>

On Tue, 20 Sep 2022 21:38:48 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:
> 
>   Removed @key printer keyword since this is a manual test

Looks like concern related to jtreg.SkippedException and its probably solution captured at : https://github.com/openjdk/jdk/pull/8412#issuecomment-1113522265

Since updated test follows https://openjdk.org/jtreg/faq.html#what-if-a-test-does-not-apply-in-a-given-situation and test is able to run in an environment where printer is configured. And throws SkippedException with appropriate message when printer is not configured, change looks okay to me.

But as captured at https://github.com/openjdk/jdk/pull/8412#issuecomment-1113522265, we may need to update PassFailJFrame to handle these manual test case scenarios and show UI message that test is not run because of bad environment.

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

Marked as reviewed by jdv (Reviewer).

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


From darcy at openjdk.org  Mon Oct  3 17:20:53 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:20:53 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@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>
 <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>
Message-ID: <H7mN4EfTvxE72FBcCrQ3MDstHI5Sm0u0fhH6o8YJRfU=.e61230a2-0413-4262-9142-76126c181725@github.com>

On Fri, 30 Sep 2022 20:25:28 GMT, Joe Darcy <darcy 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..?

Filed a few follow-up bugs:

JDK-8294724: Update openjdk.java.net => openjdk.org in tests (umbrella)
JDK-8294725: Update openjdk.java.net => openjdk.org in java command man page

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

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


From darcy at openjdk.org  Mon Oct  3 17:25:30 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:25:30 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v6]
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: <_UYUckHSBcJizYd7JBVbr6evdOrHu9h2MopGUlzrLR8=.b5c6d747-800b-462b-a19a-73a0f5096e3e@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:

  Update doc directory files.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/fbaf3d4c..6bf7bf61

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

  Stats: 38 lines in 4 files changed: 0 ins; 0 del; 38 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  Mon Oct  3 17:29:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:29:45 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v7]
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: <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@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:

  Update make directory.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/6bf7bf61..224ed7a0

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

  Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 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  Mon Oct  3 17:38:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:38:14 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <H7mN4EfTvxE72FBcCrQ3MDstHI5Sm0u0fhH6o8YJRfU=.e61230a2-0413-4262-9142-76126c181725@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>
 <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>
 <H7mN4EfTvxE72FBcCrQ3MDstHI5Sm0u0fhH6o8YJRfU=.e61230a2-0413-4262-9142-76126c181725@github.com>
Message-ID: <w8oqOHIlJyGizESmriPdGYTsVqpLZya2cPRL-2FjHWE=.8730e026-5e1c-4b3f-9543-a8f3eb4a8c3c@github.com>

On Mon, 3 Oct 2022 17:17:39 GMT, Joe Darcy <darcy 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..?
> 
> Filed a few follow-up bugs:
> 
> JDK-8294724: Update openjdk.java.net => openjdk.org in tests (umbrella) JDK-8294725: Update openjdk.java.net => openjdk.org in java command man page

And also filed

JDK-8294728: Update openjdk.java.net => openjdk.org in hotspot unit test docs

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

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


From jdv at openjdk.org  Mon Oct  3 18:05:05 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 3 Oct 2022 18:05:05 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: <lXGj0vY817JOHTUp5FH8tuuM3hVqQ2AgAJG2JglQ2MM=.107c5bff-c7c8-43ba-97fd-09ce6d0409ba@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

This test fails for me everytime at Robot.mouseMove test with/without fix at Screen #0(built-in display). I have built-in display as main display and external monitor. It is not moving forward to verify PixelColor with/without fix.

I think we dont run these tests in CI and the fix needs to be verified in local machines.

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

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


From jdv at openjdk.org  Mon Oct  3 18:36:21 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 3 Oct 2022 18:36:21 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes [v6]
In-Reply-To: <Swv1MlZIHdX49KF1yvy-ZXupg7S1qyPMl0zovUa2yYk=.cd6d7358-3461-4883-97f0-e97939153237@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
 <Swv1MlZIHdX49KF1yvy-ZXupg7S1qyPMl0zovUa2yYk=.cd6d7358-3461-4883-97f0-e97939153237@github.com>
Message-ID: <L-lJYGln-5ED81DqLoqsrZCfJtc_yyWYCQ6TdRVPo8c=.d6648a24-b3ad-47fc-93db-63fcab49dc80@github.com>

On Thu, 29 Sep 2022 15:36:32 GMT, Emmanuel Bourg <duke at openjdk.org> wrote:

>> When a list of icons is set on a window, the most appropiate icon is selected depending on the graphics configuration. But if the graphics configuration changes (because the window is moved to a different screen, or because the DPI settings of the screen is changed), the frame icon isn't updated.
>> 
>> Here is an example illustrating the issue:
>> 
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeLater(() -> {
>>             JFrame frame = new JFrame("Window Icon Test");
>>             frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>>             frame.setSize(400, 300);
>>             frame.setVisible(true);
>> 
>>             List<Image> images = new ArrayList<>();
>>             for (int size = 16; size <= 32; size++) {
>>                 // create an image displaying the size used
>>                 BufferedImage image = new BufferedImage(size, size, BufferedImage.TYPE_INT_ARGB);
>>                 Graphics2D g = image.createGraphics();
>>                 g.setFont(new Font("dialog", Font.BOLD, 12));
>>                 g.setColor(Color.BLACK);
>>                 g.drawString(String.valueOf(size), 0, size - (size - g.getFont().getSize()) / 2);
>>                 images.add(image);
>>             }
>> 
>>             frame.setIconImages(images);
>>         });
>>     }
>> 
>> On Windows if the screen scaling is set to 100% the 16x16 icon is picked from the list. If the scaling of the screen is set to 150% while the application is running, the 16x16 icon is upscaled and looks blurry.
>> 
>> A way to work around this issue is to listen for graphics configuration changes with:
>> 
>>     frame.addPropertyChangeListener("graphicsConfiguration", event -> frame.setIconImages(frame.getIconImages()));
>> 
>> 
>> Ideally this should be done automatically by the JDK. Maybe the `WindowPeer` could call `updateIconImages()` when `updateGraphicsData()` or `displayChanged()` is invoked?
>
> 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)

Current change is specific to Windows. LGTM.

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

Marked as reviewed by jdv (Reviewer).

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


From duke at openjdk.org  Mon Oct  3 18:45:37 2022
From: duke at openjdk.org (Emmanuel Bourg)
Date: Mon, 3 Oct 2022 18:45:37 GMT
Subject: Integrated: 8276849: Refresh the window icon on graphics configuration
 changes
In-Reply-To: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
Message-ID: <64FEdblJKcNQH2l11EsEZaBdUjCXfZhxqFDV957D7W8=.f428e643-51f6-4577-a3d3-8ae29819921a@github.com>

On Sun, 31 Oct 2021 08:21:58 GMT, Emmanuel Bourg <duke at openjdk.org> wrote:

> When a list of icons is set on a window, the most appropiate icon is selected depending on the graphics configuration. But if the graphics configuration changes (because the window is moved to a different screen, or because the DPI settings of the screen is changed), the frame icon isn't updated.
> 
> Here is an example illustrating the issue:
> 
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeLater(() -> {
>             JFrame frame = new JFrame("Window Icon Test");
>             frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>             frame.setSize(400, 300);
>             frame.setVisible(true);
> 
>             List<Image> images = new ArrayList<>();
>             for (int size = 16; size <= 32; size++) {
>                 // create an image displaying the size used
>                 BufferedImage image = new BufferedImage(size, size, BufferedImage.TYPE_INT_ARGB);
>                 Graphics2D g = image.createGraphics();
>                 g.setFont(new Font("dialog", Font.BOLD, 12));
>                 g.setColor(Color.BLACK);
>                 g.drawString(String.valueOf(size), 0, size - (size - g.getFont().getSize()) / 2);
>                 images.add(image);
>             }
> 
>             frame.setIconImages(images);
>         });
>     }
> 
> On Windows if the screen scaling is set to 100% the 16x16 icon is picked from the list. If the scaling of the screen is set to 150% while the application is running, the 16x16 icon is upscaled and looks blurry.
> 
> A way to work around this issue is to listen for graphics configuration changes with:
> 
>     frame.addPropertyChangeListener("graphicsConfiguration", event -> frame.setIconImages(frame.getIconImages()));
> 
> 
> Ideally this should be done automatically by the JDK. Maybe the `WindowPeer` could call `updateIconImages()` when `updateGraphicsData()` or `displayChanged()` is invoked?

This pull request has now been integrated.

Changeset: ed40d88f
Author:    Emmanuel Bourg <ebourg at apache.org>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed40d88f29d97347c101793f5aa9747061a36902
Stats:     150 lines in 2 files changed: 150 ins; 0 del; 0 mod

8276849: Refresh the window icon on graphics configuration changes

Reviewed-by: prr, jdv

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

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


From achung at openjdk.org  Mon Oct  3 20:04:32 2022
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 3 Oct 2022 20:04:32 GMT
Subject: RFR: 8292214: Memory leak in getAllConfigs of
 awt_GraphicsEnv.c:386 [v3]
In-Reply-To: <1gj0XMmbPLGkiWBwJ09LeKvujGCrLa45Qm5utSp-dCI=.1c9f3e8d-4ef4-4e4e-8a57-cd288645b961@github.com>
References: <1gj0XMmbPLGkiWBwJ09LeKvujGCrLa45Qm5utSp-dCI=.1c9f3e8d-4ef4-4e4e-8a57-cd288645b961@github.com>
Message-ID: <BmEH5VQVN47OLid0lARfAi3FqxSqY2-jAzYOsrqb7KQ=.33f4adfb-fece-4b86-855a-bdcdf858ee91@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, removed unnecessary conditional check to free graphicsConfigs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10378/files
  - new: https://git.openjdk.org/jdk/pull/10378/files/687c55db..a885893c

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

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 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 prr at openjdk.org  Mon Oct  3 20:08:19 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 3 Oct 2022 20:08:19 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v7]
In-Reply-To: <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>
Message-ID: <RJ23ZyPLKtf2O6dWE_xNJZ8m11z66OmIB24BuZ3lAXA=.39b0cdf3-bb6e-4d9a-a6ec-6efb20f1ebee@github.com>

On Mon, 3 Oct 2022 17:29: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:
> 
>   Update make directory.

src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 36:

> 34:  * https://git.openjdk.org/jdk/blob/master/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
> 35:  *
> 36:  * Also note that the API is used in the jaccessinspector and jaccesswalker tools.

The problem with this is, is that anyone who gets JDK 20 (or 21 the LTS) will be forever more then pointed at the OpenJDK "tip" and if we made an incompatible ABI change, that would be a problem.
At this point I'd prefer that this be updated to point to JDK 17, as in
https://github.com/openjdk/jdk17/blob/master/src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp
So it is a defined, known, compatible version.

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

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


From darcy at openjdk.org  Mon Oct  3 20:37:11 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 20:37:11 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v8]
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: <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@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 11 additional commits since the last revision:

 - Update accessibility URLs.
 - Merge branch 'master' into JDK-8294618
 - Update make directory.
 - Update doc directory files.
 - Update hg URLs to git.
 - Merge branch 'master' into JDK-8294618
 - http -> https
 - Undo manpage update.
 - Update copyright.
 - Revert unintended update to binary file.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/7a8d31f3...4055f1a6

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/224ed7a0..4055f1a6

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

  Stats: 5510 lines in 75 files changed: 3554 ins; 1669 del; 287 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  Mon Oct  3 20:37:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 20:37:14 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v7]
In-Reply-To: <RJ23ZyPLKtf2O6dWE_xNJZ8m11z66OmIB24BuZ3lAXA=.39b0cdf3-bb6e-4d9a-a6ec-6efb20f1ebee@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>
 <RJ23ZyPLKtf2O6dWE_xNJZ8m11z66OmIB24BuZ3lAXA=.39b0cdf3-bb6e-4d9a-a6ec-6efb20f1ebee@github.com>
Message-ID: <hGRiPhKIV8XCNGN7oJ010i5zPMJJlaYU7XzaP-c0vjM=.dee8d1ca-3312-4540-9f43-879aeffe7431@github.com>

On Mon, 3 Oct 2022 20:04:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update make directory.
>
> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 36:
> 
>> 34:  * https://git.openjdk.org/jdk/blob/master/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
>> 35:  *
>> 36:  * Also note that the API is used in the jaccessinspector and jaccesswalker tools.
> 
> The problem with this is, is that anyone who gets JDK 20 (or 21 the LTS) will be forever more then pointed at the OpenJDK "tip" and if we made an incompatible ABI change, that would be a problem.
> At this point I'd prefer that this be updated to point to JDK 17, as in
> https://github.com/openjdk/jdk17/blob/master/src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp
> So it is a defined, known, compatible version.

Updated to refer to JDK 17 specifically.

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

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


From prr at openjdk.org  Mon Oct  3 20:42:11 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 3 Oct 2022 20:42:11 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: <FGIWTkGS33-GJSBVHyy7i9V9_36ED713Q5sSDLmo0qc=.64235bde-ed5f-463c-b75c-ac58253596f4@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.

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Mon Oct  3 20:42:12 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 3 Oct 2022 20:42:12 GMT
Subject: RFR: 8294426: Two fingers tap generates wrong mouse modifiers on
 M2 MacBooks
In-Reply-To: <PUxdE8gZPsQbYpACOxu8liDdcUkkfSua9If_itYkrEQ=.06e28bb0-079c-47c8-8482-baf4d1909d2a@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>
 <PUxdE8gZPsQbYpACOxu8liDdcUkkfSua9If_itYkrEQ=.06e28bb0-079c-47c8-8482-baf4d1909d2a@github.com>
Message-ID: <kQHChV6_Pm4_p_TaCfxGedUqyIMkCTvRefJQnzZbmhw=.2b002e7d-6951-412d-a2a1-13a4ac65b080@github.com>

On Fri, 30 Sep 2022 22:26:44 GMT, Nikita Provotorov <duke at openjdk.org> wrote:

>> 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.

OK .. well I've at least run all our automated tests and no regressions were found, so I'll approve this.

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

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


From achung at openjdk.org  Mon Oct  3 20:56:48 2022
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 3 Oct 2022 20:56:48 GMT
Subject: RFR: 8292214: Memory leak in getAllConfigs of
 awt_GraphicsEnv.c:386 [v4]
In-Reply-To: <1gj0XMmbPLGkiWBwJ09LeKvujGCrLa45Qm5utSp-dCI=.1c9f3e8d-4ef4-4e4e-8a57-cd288645b961@github.com>
References: <1gj0XMmbPLGkiWBwJ09LeKvujGCrLa45Qm5utSp-dCI=.1c9f3e8d-4ef4-4e4e-8a57-cd288645b961@github.com>
Message-ID: <QF2MuGcYUA6b7afhrJMccr3AU8XVwt7oQahSnvGS17w=.3128060d-9c48-46a0-9083-f77b4b09b011@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:

  reused i variable for loop

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10378/files
  - new: https://git.openjdk.org/jdk/pull/10378/files/a885893c..f49c0342

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

  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 dnguyen at openjdk.org  Mon Oct  3 20:56:48 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 3 Oct 2022 20:56:48 GMT
Subject: RFR: 8292214: Memory leak in getAllConfigs of
 awt_GraphicsEnv.c:386 [v4]
In-Reply-To: <QF2MuGcYUA6b7afhrJMccr3AU8XVwt7oQahSnvGS17w=.3128060d-9c48-46a0-9083-f77b4b09b011@github.com>
References: <1gj0XMmbPLGkiWBwJ09LeKvujGCrLa45Qm5utSp-dCI=.1c9f3e8d-4ef4-4e4e-8a57-cd288645b961@github.com>
 <QF2MuGcYUA6b7afhrJMccr3AU8XVwt7oQahSnvGS17w=.3128060d-9c48-46a0-9083-f77b4b09b011@github.com>
Message-ID: <V5RyJlzv-QR59OX92WtUWk05_GS-NMwfHWArLRFxlSk=.09a29248-8491-4777-be78-2ceb603a1882@github.com>

On Mon, 3 Oct 2022 20:52:18 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:
> 
>   reused i variable for loop

Marked as reviewed by dnguyen (Author).

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

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


From duke at openjdk.org  Mon Oct  3 21:33:05 2022
From: duke at openjdk.org (Emmanuel Bourg)
Date: Mon, 3 Oct 2022 21:33:05 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes [v6]
In-Reply-To: <Swv1MlZIHdX49KF1yvy-ZXupg7S1qyPMl0zovUa2yYk=.cd6d7358-3461-4883-97f0-e97939153237@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
 <Swv1MlZIHdX49KF1yvy-ZXupg7S1qyPMl0zovUa2yYk=.cd6d7358-3461-4883-97f0-e97939153237@github.com>
Message-ID: <kJKw7kEyFDyqKPO5jgVKNwsGjkkCpXmVc_ofN0tUUAk=.0f968473-88cb-4749-80b5-3369670a8f04@github.com>

On Thu, 29 Sep 2022 15:36:32 GMT, Emmanuel Bourg <duke at openjdk.org> wrote:

>> When a list of icons is set on a window, the most appropiate icon is selected depending on the graphics configuration. But if the graphics configuration changes (because the window is moved to a different screen, or because the DPI settings of the screen is changed), the frame icon isn't updated.
>> 
>> Here is an example illustrating the issue:
>> 
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeLater(() -> {
>>             JFrame frame = new JFrame("Window Icon Test");
>>             frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>>             frame.setSize(400, 300);
>>             frame.setVisible(true);
>> 
>>             List<Image> images = new ArrayList<>();
>>             for (int size = 16; size <= 32; size++) {
>>                 // create an image displaying the size used
>>                 BufferedImage image = new BufferedImage(size, size, BufferedImage.TYPE_INT_ARGB);
>>                 Graphics2D g = image.createGraphics();
>>                 g.setFont(new Font("dialog", Font.BOLD, 12));
>>                 g.setColor(Color.BLACK);
>>                 g.drawString(String.valueOf(size), 0, size - (size - g.getFont().getSize()) / 2);
>>                 images.add(image);
>>             }
>> 
>>             frame.setIconImages(images);
>>         });
>>     }
>> 
>> On Windows if the screen scaling is set to 100% the 16x16 icon is picked from the list. If the scaling of the screen is set to 150% while the application is running, the 16x16 icon is upscaled and looks blurry.
>> 
>> A way to work around this issue is to listen for graphics configuration changes with:
>> 
>>     frame.addPropertyChangeListener("graphicsConfiguration", event -> frame.setIconImages(frame.getIconImages()));
>> 
>> 
>> Ideally this should be done automatically by the JDK. Maybe the `WindowPeer` could call `updateIconImages()` when `updateGraphicsData()` or `displayChanged()` is invoked?
>
> 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)

Thanks !

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

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


From aivanov at openjdk.org  Mon Oct  3 21:56:54 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 21:56:54 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: <vktd4cobwhxENll2YtBaheylCfXLFghyOlOtq6vKW78=.e9641c42-347f-427e-ade2-50dc2c67da94@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

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 32:

> 30: 
> 31: import javax.swing.AbstractButton;
> 32: import javax.swing.ButtonModel;

I'm unsure if we all agree on the order of imports in client area, however, the common order is

import java.*;
// optional blank line
import javax.*;
// blank line
import sun.*; // other packages
// blank line
import static *; // if applicable

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 313:

> 311: 
> 312:             // border and corner scaling
> 313:             int scaledCorner = (int) Math.round(corner * at.getScaleX());

Just a suggestion, you can call this variable `corner` but make the constant above upper case `CORNER`. This way the old code would remain basically the same and continue using `corner` (which was previously a field).

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 326:

> 324:             g.drawLine( 0, 1, 0, height-1);
> 325:             g.drawLine( width-1, 1, width-1, height-1);
> 326:             g.drawLine( 1, height-1, width-1, height-1);

I suggest removing the space after the opening parenthesis.

There's usually a space on either side of binary operators, the `-` in this case.

I believe this is existing code which was just moved around, so maybe its style is not worth touching.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 343:

> 341:                         width-midPoint, height- scaledCorner); //right
> 342:                 g.drawLine(scaledCorner + 1, height-midPoint,
> 343:                         width- scaledCorner, height-midPoint); //bottom

This looks a bit weird to me. The old code used no spaces around the binary operators, the new code is inconsistent: some cases do, some don't, some have space only after the operator.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 74:

> 72:     private static final int FRAME_SIZE = 300;
> 73:     private static final int INTFRAME_SIZE = 200;
> 74:     private static final int MIDPOINT = INTFRAME_SIZE/2;

Suggestion:

    private static final int MIDPOINT = INTFRAME_SIZE / 2;

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 112:

> 110: 
> 111:             // Check Borders
> 112:             SwingUtilities.invokeAndWait(() -> {

None of the `check*` are required to be run on EDT. They use `robot` to read pixels from the screen, it can be done on the main thread.

It's probably to call `jFrame.getBounds()`. However, you can pre-save the bounds of the frame in the block above.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 139:

> 137: 
> 138:     private static void checkBorderMidPoints(String borderDirection) {
> 139:         int x = 0, y = 0, start = 0, stop = 0;

The initialisers are redundant.  
It's not recommended to have several local variable declarations on one line.

When using two lines

int x, y;
int start, stop;

the coordinates and loop control variables are on separate lines, easier to parse.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 180:

> 178:                     isHorizontal ? i : (iFrameLoc.y + MIDPOINT)))) {
> 179:                         saveScreenCapture(borderDirection + "_" + uiScale + ".png");
> 180:                         errorLog.append("uiScale: "+ uiScale +

The body of `if` shouldn't be indented compared to the indentation of the condition, it should start at the regular four-column indent.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 181:

> 179:                         saveScreenCapture(borderDirection + "_" + uiScale + ".png");
> 180:                         errorLog.append("uiScale: "+ uiScale +
> 181:                                 " Red background color" + " detected at "

Another nit:
Suggestion:

                        errorLog.append("uiScale: " + uiScale +
                                " Red background color detected at "

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 189:

> 187: 
> 188:     private static void checkCorners(String cornerLocation) {
> 189:         int x, y = 0;

Suggestion:

        int x, y;

Initialising `y` _only_ is redundant.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 211:

> 209:                     + cornerLocation);
> 210:         }
> 211:         robot.mouseMove(x, y);

Moving the mouse cursor is not required. However, it gives a visual feedback of where the check is happening.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 240:

> 238:     }
> 239:     // for debugging purpose, saves screen capture when test fails.
> 240:     private static void saveScreenCapture(String filename) {

The comment is probably redundant. Yet a blank line between methods is recommended.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 241:

> 239:     // for debugging purpose, saves screen capture when test fails.
> 240:     private static void saveScreenCapture(String filename) {
> 241:         BufferedImage image = robot.createScreenCapture(jFrame.getBounds());

I guess we lose pixel details here. If uiScale > 1, `createScreenCapture` scales down the captured image. Do we want to preserve the original image too? [`Robot.createMultiResolutionScreenCapture`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Robot.html#createMultiResolutionScreenCapture(java.awt.Rectangle)) can be useful.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 243:

> 241:         BufferedImage image = robot.createScreenCapture(jFrame.getBounds());
> 242:         try {
> 243:             ImageIO.write(image,"png", new File(filename));

Suggestion:

            ImageIO.write(image, "png", new File(filename));

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

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


From aivanov at openjdk.org  Mon Oct  3 22:01:06 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 22:01:06 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: <0SIw07r--T4zF6fgkVRw0UY9qv0duIELblGCuxqcuZc=.f0d01224-6d2b-4e25-882b-cf0f0205004f@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

Out of curiosity, can this test use `BufferedImage` to render `JInternalFrame` into?

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

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


From aivanov at openjdk.org  Mon Oct  3 22:05:10 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Oct 2022 22:05:10 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes [v6]
In-Reply-To: <kJKw7kEyFDyqKPO5jgVKNwsGjkkCpXmVc_ofN0tUUAk=.0f968473-88cb-4749-80b5-3369670a8f04@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
 <Swv1MlZIHdX49KF1yvy-ZXupg7S1qyPMl0zovUa2yYk=.cd6d7358-3461-4883-97f0-e97939153237@github.com>
 <kJKw7kEyFDyqKPO5jgVKNwsGjkkCpXmVc_ofN0tUUAk=.0f968473-88cb-4749-80b5-3369670a8f04@github.com>
Message-ID: <0xRKnWuskSRDDowHBIwMTiWdq8-eTmM-OeABP2lNGaE=.e10f8f97-00e9-43c8-b22d-7d2ea3b2ec41@github.com>

On Mon, 3 Oct 2022 21:31:04 GMT, Emmanuel Bourg <duke at openjdk.org> wrote:

>> 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)
>
> Thanks !

Thank you, @ebourg, for your contribution.

It looks good to me too. I didn't have time to look at your latest update though before you integrated it. Anyway.

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

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


From achung at openjdk.org  Mon Oct  3 22:07:13 2022
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 3 Oct 2022 22:07:13 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: <eNAZ5y3qOhSUvb4VNzivXXo3WyfFJy3rsWjM8bKBJf4=.98c7a66d-6295-421f-affe-9546ee88915d@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

Changes requested by achung (Author).

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 255:

> 253:          * @return a {@code int} which is the rounded value of provided number
> 254:          */
> 255:         private static int roundDown(double d)

The name of this method is a bit misleading, the operation doesn't actually round down, but rounds the number normally except for the x.5 case right? Does this operation exist somewhere else?

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 329:

> 327: 
> 328:             // Draw the bulk of the border
> 329:             for (int i = 1; i <= loopCount; i++) {

Should we redo the drawing of this border to use Graphics2D fillRect instead?

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 336:

> 334:                 // Draw the Long highlight lines
> 335:                 g.setColor(highlight);
> 336:                 g.drawLine(scaledCorner + 1, midPoint+stkWidth,

The spacing here and when drawing shadow lines is a bit inconsistent

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

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


From serb at openjdk.org  Mon Oct  3 22:09:17 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Oct 2022 22:09:17 GMT
Subject: RFR: 8270915: GIFImageReader disregards ignoreMetadata flag which
 causes memory exhaustion
In-Reply-To: <MNVf1oMbzOO8Zpyk551X7bNJQeGsUbHiyC8kBKsuixw=.fd9b04d2-5cce-4dd7-9b49-15042925743c@github.com>
References: <MNVf1oMbzOO8Zpyk551X7bNJQeGsUbHiyC8kBKsuixw=.fd9b04d2-5cce-4dd7-9b49-15042925743c@github.com>
Message-ID: <RvbV88C4onapywWXG0S3wcYsVN9eXzJDxskdVgz-I-g=.16917659-2fbd-48af-a89a-be37e5ace1fe@github.com>

On Mon, 3 Oct 2022 13:59:25 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> I have updated readMedata() to also use ReaderUtil.staggeredReadByteStream() where we are allocating upfront memory based on parameters from metadata. 

Probably it is possible to create a small test just for this change?

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

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


From honkar at openjdk.org  Mon Oct  3 22:20:09 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 3 Oct 2022 22:20:09 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <0SIw07r--T4zF6fgkVRw0UY9qv0duIELblGCuxqcuZc=.f0d01224-6d2b-4e25-882b-cf0f0205004f@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <0SIw07r--T4zF6fgkVRw0UY9qv0duIELblGCuxqcuZc=.f0d01224-6d2b-4e25-882b-cf0f0205004f@github.com>
Message-ID: <UemCGrDaiy4osk-rRrilEZG-HpCu9bN9Q_sHztLpdyU=.49fe52f2-1306-45f2-a455-f8c627d1ae31@github.com>

On Mon, 3 Oct 2022 21:57:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Out of curiosity, can this test use `BufferedImage` to render `JInternalFrame` into?

@aivanov-jdk Thank you for reviewing. I wanted to clarify whether you meant saving just the JInternalFrame into BufferedImage?

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

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


From honkar at openjdk.org  Mon Oct  3 22:46:54 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 3 Oct 2022 22:46:54 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <eNAZ5y3qOhSUvb4VNzivXXo3WyfFJy3rsWjM8bKBJf4=.98c7a66d-6295-421f-affe-9546ee88915d@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <eNAZ5y3qOhSUvb4VNzivXXo3WyfFJy3rsWjM8bKBJf4=.98c7a66d-6295-421f-affe-9546ee88915d@github.com>
Message-ID: <4zanUg4ogg5XN71yR_lVWw3-2Cww15jC9ey_IBeT1lI=.552f826c-e870-454f-b187-0fbb8419f429@github.com>

On Mon, 3 Oct 2022 22:02:34 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed redundant jtreg header
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 329:
> 
>> 327: 
>> 328:             // Draw the bulk of the border
>> 329:             for (int i = 1; i <= loopCount; i++) {
> 
> Should we redo the drawing of this border to use Graphics2D fillRect instead?

Since loopCount won't be really large,(it is 15 for 300% scaling) and it wouldn't affect the performance drastically,I have retained the original code.

> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 336:
> 
>> 334:                 // Draw the Long highlight lines
>> 335:                 g.setColor(highlight);
>> 336:                 g.drawLine(scaledCorner + 1, midPoint+stkWidth,
> 
> The spacing here and when drawing shadow lines is a bit inconsistent

@alisenchung  I tried by increasing and decreasing the line position a bit, the current combination provided the optimal positioning of both the shadow and highlight line within the border for all the scales. The slight inconsistency in spacing is probably due to rounding losses in loop count, stroke width and corner. I'll check it again.

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

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


From serb at openjdk.org  Tue Oct  4 02:44:50 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 4 Oct 2022 02:44:50 GMT
Subject: RFR: 8294488: Delete KCMS transforms wrappers
Message-ID: <NPi08uuC9X_65nmI52YUY-fDamcRo9A26Q69wsl6dDU=.3de3ad05-1adb-44b0-8a23-82cc025e48f7@github.com>

This is a request to cleanup the shared code for the colors conversions. That code still uses some wrappers which can be simplified and/or deleted after KCMS removal. For example each conversion from one color space to another creates 3 wrappers - for the first color profile, the second color profile and one to combine the first two. But for the lcms library we only need the list of color profiles and rendering intent -> only one transform object can be used.

The new constructor for the LCMSTransform is [added](https://github.com/openjdk/jdk/pull/10459/files#diff-7448ea8346eb08c6ec1a518e3c3399d7d078a514c07956ee7e8e2b5be3d082e1R77) and now used everywhere:
`LCMSTransform(int renderingIntent, ICC_Profile... profiles)` 
It will wrap the `cmsCreateMultiprofileTransform` [function ](https://github.com/openjdk/jdk/pull/10459/files#diff-eed6ddb15e9c5bdab9fc3b3930d5d959966165d9622ddd293e8572489adea98bR202) in LCMS library:

I tried to preserve the current behavior, as a result two "workarounds" are used for the next bugs.
 * [JDK-8216369](https://bugs.openjdk.org/browse/JDK-8216369): after the cleanup it became obvious that we use a hardcoded value for the first rendering [intent](https://github.com/openjdk/jdk/pull/10459/files#diff-e3d6eea060882cab00827c00e1a83b0e0a5b2a31fa9a9aa2122841bbd57c4a6dR473). There is a code to fetch the intent from the color profile but I postponed use it for now because some of our built-in profiles use different default intents..
 * [JDK-8272860](https://bugs.openjdk.org/browse/JDK-8272860): the old code always fetched some information from the color profile header a result we cache the headers for any profiles we used. This cache workaround the JDK-8272860 while the direct access to the profile via LCMS library could fail.The new code intentionally cache the [header](https://github.com/openjdk/jdk/pull/10459/files#diff-7448ea8346eb08c6ec1a518e3c3399d7d078a514c07956ee7e8e2b5be3d082e1R91).

Notes:
* The old wrappers used a rendering intent for each intermediate transform, the LCMS use only one intent
* The old wrappers could throw the cmm exception if the rendering intent was not supported. The LCMS ignores unsupported intents and use some [default](https://github.com/LuaDist/lcms/blob/master/doc/TUTORIAL.TXT#L1094)
 * The old wrappers had a way to specifiy the input and output profiles, the LCMS library use the first profile as input and the last profile as output. That parameters are [removed](https://github.com/openjdk/jdk/pull/10459/files#diff-81b49f067b32296497e9e727bda25efe0b7f84fb2c05645eb6b272bfc32469f1L38)
 * If at some point the new CMS library will be added it will be easy to integrate it using XXCMS plugin, instead of using some specific library logic in the shared code

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

Commit messages:
 - rename renderType to renderingIntent
 - Merge remote-tracking branch 'upstream/master' into tfmCleanup
 - Add a dot.
 - cleanup

Changes: https://git.openjdk.org/jdk/pull/10459/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10459&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294488
  Stats: 282 lines in 9 files changed: 18 ins; 175 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/10459.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10459/head:pull/10459

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


From tr at openjdk.org  Tue Oct  4 05:50:13 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 4 Oct 2022 05:50:13 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v3]
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: <IBx49yaBn4NM0Ge-2pAIHPu9wGJ40_rydCY_IdZma_s=.e9cd891c-372a-4e11-9d5f-edf6076546b5@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/54ddc88b..a0299038

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

  Stats: 32 lines in 2 files changed: 3 ins; 16 del; 13 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  Tue Oct  4 05:50:15 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 4 Oct 2022 05:50:15 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
Message-ID: <CQk_asv3R6dcRVAousvRe-NwbDw_N2-B_8g5GczwISM=.70731343-2c66-4587-90ee-19fcc35af1af@github.com>

On Mon, 3 Oct 2022 11:10:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> You say that the current directory in `JFileChooser` gets set to `null` because of forbidden navigation to a folder which is not traversable. You avoid the NPE by a null-check.
> 
> However, you should prevent the current directory to be set to `null`. If navigation is not allowed, the current directory should remain unchanged _instead of being reset to `null`_.

@aivanov-jdk I have updated as per the review comments. Please let me know if its fine. I have put up the mach5 test link in JBS for reference.

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

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


From tr at openjdk.org  Tue Oct  4 05:50:15 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 4 Oct 2022 05:50:15 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <AxFTPnmGcRXxnC-1fGOxGfO_42jB74nS3ek8USGdaU4=.b3da06a0-a6f9-4e78-acb4-c9f5a9dabed3@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
 <CF_HYeww7iVgYnnge_d64a1bixwL9zgsiufcMgMPfCs=.cbf4683b-a74d-466e-976b-688a093f97d5@github.com>
 <NhIhwpydtvLFaaVypTlb51uInHO8LxgTv3v2OzC_vvE=.e0c9a4be-be6e-4122-96b4-c9f0a42157cc@github.com>
 <pXff3tKo16_BupmrK1tJm8YMzMxpFz5P3NMM6cCLgnE=.19c51347-2f57-459d-ad1b-7194cce1488f@github.com>
 <MuinxMf75JAPbCYcu7TVmy3ECrg9io2AmInpsJgncws=.c0cb475d-345a-4578-997b-82c99358dd19@github.com>
 <AxFTPnmGcRXxnC-1fGOxGfO_42jB74nS3ek8USGdaU4=.b3da06a0-a6f9-4e78-acb4-c9f5a9dabed3@github.com>
Message-ID: <5HJJWyKp9jq-3ZzEJWGNS2ajQZhVUN2QwUS04eZRMCk=.82631fdd-2b8d-465b-a614-0cecf10cfe5e@github.com>

On Mon, 3 Oct 2022 12:01:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Then I can just make user.home directory as the only traversable.......?
>
> Makes sense to me.

Updated.

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

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


From tr at openjdk.org  Tue Oct  4 05:50:17 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 4 Oct 2022 05:50:17 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <vvX-NoTTOvgWbXY8228J0siOiAqBQbZU0203QFcan04=.5fedf288-711e-46e2-895a-6ce9fc1e4777@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
 <vvX-NoTTOvgWbXY8228J0siOiAqBQbZU0203QFcan04=.5fedf288-711e-46e2-895a-6ce9fc1e4777@github.com>
Message-ID: <WBcZZwcc5_eKy9SUtP0imZPya7VEnbdDCk9KkMheSpE=.65247020-6cd0-460a-ad27-5dce469bbb3d@github.com>

On Mon, 3 Oct 2022 11:29:14 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 114:
>> 
>>> 112:         } else {
>>> 113:             return false;
>>> 114:         }
>> 
>> It can be simplified to:
>> Suggestion:
>> 
>>         return ((filePath != null) && (filePath.isDirectory())
>>                 && filePath.getAbsolutePath().startsWith(basePath));
>> 
>> I'm not insisting though.
>
> Can be done, no issues.

Updated.

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

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


From tr at openjdk.org  Tue Oct  4 08:06:24 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 4 Oct 2022 08:06:24 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v4]
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: <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@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:

  Test case update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10485/files
  - new: https://git.openjdk.org/jdk/pull/10485/files/a0299038..62f6c307

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

  Stats: 1 line in 1 file changed: 0 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  Tue Oct  4 11:40:27 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Oct 2022 11:40:27 GMT
Subject: RFR: 8294255: Add link to DEFAULT_WAIT_TIME in javadoc for
 SunToolKit.realsSync
In-Reply-To: <5IKSHb5lsL9So0XoN2YDv7GhGjL0j_gi9FWtpZ0IykE=.f315a62e-1d87-4ed5-a6a7-f86d6db34b7f@github.com>
References: <5IKSHb5lsL9So0XoN2YDv7GhGjL0j_gi9FWtpZ0IykE=.f315a62e-1d87-4ed5-a6a7-f86d6db34b7f@github.com>
Message-ID: <vRWBDw6vFaY02p_BLtPw1XZ9xG5V70y_oiQyaxfjFyA=.0f4c4a4d-531d-494c-9f0e-b823e6311f8d@github.com>

On Fri, 23 Sep 2022 01:11:14 GMT, SWinxy <duke at openjdk.org> wrote:

> 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}.
>   */

Marked as reviewed by aivanov (Reviewer).

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

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


From azvegint at openjdk.org  Tue Oct  4 15:22:02 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 4 Oct 2022 15:22:02 GMT
Subject: RFR: 8292214: Memory leak in getAllConfigs of
 awt_GraphicsEnv.c:386 [v4]
In-Reply-To: <QF2MuGcYUA6b7afhrJMccr3AU8XVwt7oQahSnvGS17w=.3128060d-9c48-46a0-9083-f77b4b09b011@github.com>
References: <1gj0XMmbPLGkiWBwJ09LeKvujGCrLa45Qm5utSp-dCI=.1c9f3e8d-4ef4-4e4e-8a57-cd288645b961@github.com>
 <QF2MuGcYUA6b7afhrJMccr3AU8XVwt7oQahSnvGS17w=.3128060d-9c48-46a0-9083-f77b4b09b011@github.com>
Message-ID: <CPH7luUQWE77Xm-ZK08g6BznSRd83GEC-6XqAjoSxKM=.670597fe-123a-46f0-9813-355b8dc0c340@github.com>

On Mon, 3 Oct 2022 20:56: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
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reused i variable for loop

Marked as reviewed by azvegint (Reviewer).

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

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


From achung at openjdk.org  Tue Oct  4 15:26:32 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 4 Oct 2022 15:26:32 GMT
Subject: Integrated: 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: <ap4fAWrW2bQssBpsRLDTSUQNeTB210eRdpy1doPhzQg=.8eb26cff-0cc6-4158-a6b6-82f53c2af500@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

This pull request has now been integrated.

Changeset: 1166a8ab
Author:    Alisen Chung <achung at openjdk.org>
Committer: Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1166a8abd2e5fba16b5cd29431de2628a52a8e08
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8292214: Memory leak in getAllConfigs of awt_GraphicsEnv.c:386

Reviewed-by: azvegint, dnguyen

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

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


From dnguyen at openjdk.org  Tue Oct  4 17:39:09 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 4 Oct 2022 17:39:09 GMT
Subject: RFR: 8293672: Update freetype md file
Message-ID: <b-dzUsyVw43_GNHgj0SvJX-HRTZ83wdjMpGSXBUuNjk=.9ad77320-25bc-420a-b24e-d282920a84b8@github.com>

Update the freetype md file with the newly generated md file from attribution tool. The new format slightly differs from the previous version when separating different licenses. Added logic for combining of copyright lines and support for other licenses such as MIT.

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

Commit messages:
 - Update md file

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

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


From honkar at openjdk.org  Tue Oct  4 17:48:55 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 4 Oct 2022 17:48:55 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v5]
In-Reply-To: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
Message-ID: <TfVEzqvCHRXUBpWMM_5nO5ej7yg_OwjOEL1wS9HgiXM=.0f9835af-b518-4d26-8d89-7d6c09a72d45@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:

  review changes, saving a scaled version of image

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10274/files
  - new: https://git.openjdk.org/jdk/pull/10274/files/4047f9d7..6efd8417

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

  Stats: 107 lines in 2 files changed: 35 ins; 22 del; 50 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  Tue Oct  4 17:53:31 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 4 Oct 2022 17:53:31 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <vktd4cobwhxENll2YtBaheylCfXLFghyOlOtq6vKW78=.e9641c42-347f-427e-ade2-50dc2c67da94@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <vktd4cobwhxENll2YtBaheylCfXLFghyOlOtq6vKW78=.e9641c42-347f-427e-ade2-50dc2c67da94@github.com>
Message-ID: <ZaDYasiX7t19j57Kp7BQV296arhgZce7mXW6Dq92nqo=.5ae63705-0491-4362-ae99-cf0742d40e41@github.com>

On Mon, 3 Oct 2022 21:18:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed redundant jtreg header
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 313:
> 
>> 311: 
>> 312:             // border and corner scaling
>> 313:             int scaledCorner = (int) Math.round(corner * at.getScaleX());
> 
> Just a suggestion, you can call this variable `corner` but make the constant above upper case `CORNER`. This way the old code would remain basically the same and continue using `corner` (which was previously a field).

Updated

> test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 211:
> 
>> 209:                     + cornerLocation);
>> 210:         }
>> 211:         robot.mouseMove(x, y);
> 
> Moving the mouse cursor is not required. However, it gives a visual feedback of where the check is happening.

@aivanov-jdk I have retained the mouseMove for visual confirmation

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

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


From dnguyen at openjdk.org  Tue Oct  4 18:03:39 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 4 Oct 2022 18:03:39 GMT
Subject: RFR: 8293672: Update freetype md file [v2]
In-Reply-To: <b-dzUsyVw43_GNHgj0SvJX-HRTZ83wdjMpGSXBUuNjk=.9ad77320-25bc-420a-b24e-d282920a84b8@github.com>
References: <b-dzUsyVw43_GNHgj0SvJX-HRTZ83wdjMpGSXBUuNjk=.9ad77320-25bc-420a-b24e-d282920a84b8@github.com>
Message-ID: <24bzyIC2B6IuXlyByb_dSzOwT0GjtPN2YhxbY2uzsUo=.02c0d507-aacc-41a7-9492-44944f483bf0@github.com>

> Update the freetype md file with the newly generated md file from attribution tool. The new format slightly differs from the previous version when separating different licenses. Added logic for combining of copyright lines and support for other licenses such as MIT.

Damon Nguyen 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 'openjdk:master' into 8293672/updateFreeTypeMd
 - Update md file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10561/files
  - new: https://git.openjdk.org/jdk/pull/10561/files/2bb32afc..16c4ed07

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

  Stats: 208500 lines in 3586 files changed: 104542 ins; 82118 del; 21840 mod
  Patch: https://git.openjdk.org/jdk/pull/10561.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10561/head:pull/10561

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


From prr at openjdk.org  Tue Oct  4 18:03:40 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Oct 2022 18:03:40 GMT
Subject: RFR: 8293672: Update freetype md file [v2]
In-Reply-To: <24bzyIC2B6IuXlyByb_dSzOwT0GjtPN2YhxbY2uzsUo=.02c0d507-aacc-41a7-9492-44944f483bf0@github.com>
References: <b-dzUsyVw43_GNHgj0SvJX-HRTZ83wdjMpGSXBUuNjk=.9ad77320-25bc-420a-b24e-d282920a84b8@github.com>
 <24bzyIC2B6IuXlyByb_dSzOwT0GjtPN2YhxbY2uzsUo=.02c0d507-aacc-41a7-9492-44944f483bf0@github.com>
Message-ID: <Uf9NfQLjJ63MHSLATKgl_3DbzluH8pvLrNmg3OSdesE=.ac802530-4d23-43ae-9026-20a42419be1e@github.com>

On Tue, 4 Oct 2022 18:00:32 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Update the freetype md file with the newly generated md file from attribution tool. The new format slightly differs from the previous version when separating different licenses. Added logic for combining of copyright lines and support for other licenses such as MIT.
>
> Damon Nguyen 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 'openjdk:master' into 8293672/updateFreeTypeMd
>  - Update md file

src/java.desktop/share/legal/freetype.md line 2:

> 1: ## The FreeType Project: Freetype v2.12.1
> 2: 

Why does this show a .0 -> .1 update ?
The currently checked in file was updated in July so it already has .1 .. so that is very puzzling to me.

src/java.desktop/share/legal/freetype.md line 542:

> 540: /*
> 541:  * Copyright 2000 Computing Research Labs, New Mexico State University
> 542:  * Copyright 2001-2015

Why did this notice need to be moved down to the end of the file ?
It makes the diff look bigger than it actually is and I can't imagine any reason we would need to change the order.

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

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


From prr at openjdk.org  Tue Oct  4 18:03:40 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Oct 2022 18:03:40 GMT
Subject: RFR: 8293672: Update freetype md file [v2]
In-Reply-To: <Uf9NfQLjJ63MHSLATKgl_3DbzluH8pvLrNmg3OSdesE=.ac802530-4d23-43ae-9026-20a42419be1e@github.com>
References: <b-dzUsyVw43_GNHgj0SvJX-HRTZ83wdjMpGSXBUuNjk=.9ad77320-25bc-420a-b24e-d282920a84b8@github.com>
 <24bzyIC2B6IuXlyByb_dSzOwT0GjtPN2YhxbY2uzsUo=.02c0d507-aacc-41a7-9492-44944f483bf0@github.com>
 <Uf9NfQLjJ63MHSLATKgl_3DbzluH8pvLrNmg3OSdesE=.ac802530-4d23-43ae-9026-20a42419be1e@github.com>
Message-ID: <q78ZlRUZG0vbeLmI4pzJNLXOOHZUEJyBhvaxeWotOxU=.e7867937-2bf3-484a-8fb5-f79296e9562b@github.com>

On Tue, 4 Oct 2022 17:49:40 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen 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 'openjdk:master' into 8293672/updateFreeTypeMd
>>  - Update md file
>
> src/java.desktop/share/legal/freetype.md line 2:
> 
>> 1: ## The FreeType Project: Freetype v2.12.1
>> 2: 
> 
> Why does this show a .0 -> .1 update ?
> The currently checked in file was updated in July so it already has .1 .. so that is very puzzling to me.

Hmm .. it has disappeared with your 2nd commit. I can only suppose you were using a VERY out of date repo ..

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

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


From dnguyen at openjdk.org  Tue Oct  4 18:03:40 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 4 Oct 2022 18:03:40 GMT
Subject: RFR: 8293672: Update freetype md file [v2]
In-Reply-To: <q78ZlRUZG0vbeLmI4pzJNLXOOHZUEJyBhvaxeWotOxU=.e7867937-2bf3-484a-8fb5-f79296e9562b@github.com>
References: <b-dzUsyVw43_GNHgj0SvJX-HRTZ83wdjMpGSXBUuNjk=.9ad77320-25bc-420a-b24e-d282920a84b8@github.com>
 <24bzyIC2B6IuXlyByb_dSzOwT0GjtPN2YhxbY2uzsUo=.02c0d507-aacc-41a7-9492-44944f483bf0@github.com>
 <Uf9NfQLjJ63MHSLATKgl_3DbzluH8pvLrNmg3OSdesE=.ac802530-4d23-43ae-9026-20a42419be1e@github.com>
 <q78ZlRUZG0vbeLmI4pzJNLXOOHZUEJyBhvaxeWotOxU=.e7867937-2bf3-484a-8fb5-f79296e9562b@github.com>
Message-ID: <JyTQ3575PTqw2TLRFrdtjwzOVu7ID1DPZj9gwl-5KKw=.2304f8f7-d803-4b21-b9b5-c3c6afe817e3@github.com>

On Tue, 4 Oct 2022 17:55:51 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/legal/freetype.md line 2:
>> 
>>> 1: ## The FreeType Project: Freetype v2.12.1
>>> 2: 
>> 
>> Why does this show a .0 -> .1 update ?
>> The currently checked in file was updated in July so it already has .1 .. so that is very puzzling to me.
>
> Hmm .. it has disappeared with your 2nd commit. I can only suppose you were using a VERY out of date repo ..

Needed to resync branch. Resolved!

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

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


From dnguyen at openjdk.org  Tue Oct  4 18:03:41 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 4 Oct 2022 18:03:41 GMT
Subject: RFR: 8293672: Update freetype md file [v2]
In-Reply-To: <Uf9NfQLjJ63MHSLATKgl_3DbzluH8pvLrNmg3OSdesE=.ac802530-4d23-43ae-9026-20a42419be1e@github.com>
References: <b-dzUsyVw43_GNHgj0SvJX-HRTZ83wdjMpGSXBUuNjk=.9ad77320-25bc-420a-b24e-d282920a84b8@github.com>
 <24bzyIC2B6IuXlyByb_dSzOwT0GjtPN2YhxbY2uzsUo=.02c0d507-aacc-41a7-9492-44944f483bf0@github.com>
 <Uf9NfQLjJ63MHSLATKgl_3DbzluH8pvLrNmg3OSdesE=.ac802530-4d23-43ae-9026-20a42419be1e@github.com>
Message-ID: <0-gwG-fhyvLXp4LWBNnJPj-WR2cItRn73VsV1SSeJNw=.f7f6ba4b-a5fe-48f5-8ac6-5c4473a0d07d@github.com>

On Tue, 4 Oct 2022 17:52:05 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen 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 'openjdk:master' into 8293672/updateFreeTypeMd
>>  - Update md file
>
> src/java.desktop/share/legal/freetype.md line 542:
> 
>> 540: /*
>> 541:  * Copyright 2000 Computing Research Labs, New Mexico State University
>> 542:  * Copyright 2001-2015
> 
> Why did this notice need to be moved down to the end of the file ?
> It makes the diff look bigger than it actually is and I can't imagine any reason we would need to change the order.

This is due to the addition of the MIT license being treated as a separate license from the freetype license. In the modified tool, licenses are separated by license type. The additional freetype licenses seems more logically related to freetype licenses so it follows the freetype & GPL license. Then, other licenses (such as MIT in this case) follow afterwards.

This can be manually modified to maintain the old order but I believed it made more sense this way in the tool since "variants" of the primary license (freetype) would follow the primary license.

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

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


From duke at openjdk.org  Tue Oct  4 18:05:50 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Tue, 4 Oct 2022 18:05:50 GMT
Subject: Integrated: 8292309 : Fix
 java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java test
In-Reply-To: <uFqQUzkuWOrGXowhXEwVwRN5HjCisrPLGNK-rpaUyUc=.6c97b5ba-e463-45d1-8cb4-e4799148e212@github.com>
References: <uFqQUzkuWOrGXowhXEwVwRN5HjCisrPLGNK-rpaUyUc=.6c97b5ba-e463-45d1-8cb4-e4799148e212@github.com>
Message-ID: <3HTZ7Gc-spLQwHxlrvVyQVA6X0wvrnJWhJ0F4lRQbl8=.52156f0a-319b-452c-94db-3fcd010dea33@github.com>

On Fri, 12 Aug 2022 23:10:01 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

This pull request has now been integrated.

Changeset: b22a38de
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b22a38dedb06199f2cba3b6f8962ddf2f9f4f16d
Stats:     336 lines in 1 file changed: 52 ins; 224 del; 60 mod

8292309: Fix java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java test

Reviewed-by: jdv

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

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


From honkar at openjdk.org  Tue Oct  4 18:14:28 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 4 Oct 2022 18:14:28 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <0SIw07r--T4zF6fgkVRw0UY9qv0duIELblGCuxqcuZc=.f0d01224-6d2b-4e25-882b-cf0f0205004f@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <0SIw07r--T4zF6fgkVRw0UY9qv0duIELblGCuxqcuZc=.f0d01224-6d2b-4e25-882b-cf0f0205004f@github.com>
Message-ID: <EzzrDZfHCVBjkbnOaGyk40ZS_aRNRNEDsHQs_tyouqM=.294e4b7b-d865-45c1-80d7-d145d4088426@github.com>

On Mon, 3 Oct 2022 21:57:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed redundant jtreg header
>
> Out of curiosity, can this test use `BufferedImage` to render `JInternalFrame` into?

@aivanov-jdk Regarding saving the screen capture -

- When JIF bounds are used, a partial image of JInternalFrame (JIF) is saved. Hence I'm using the entire JFrame bounds to capture the screenshot.
- For the screenCapture I wanted to use **BufferedImage's getScaledInstance()** to create the scaled version (code snippet below), but experiencing issues while saving it. Currently I'm scaling the original image and re-drawing it using graphics object.


BufferedImage bufferedImage= robot.createScreenCapture(jFrameBounds);
Image image= bufferedImage.getScaledInstance((int) (scale * bufferedImage.getWidth(null)),
	(int) (scale * bufferedImage.getHeight(null)), Image.SCALE_DEFAULT);

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

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


From prr at openjdk.org  Tue Oct  4 18:22:34 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Oct 2022 18:22:34 GMT
Subject: RFR: 8293672: Update freetype md file [v2]
In-Reply-To: <24bzyIC2B6IuXlyByb_dSzOwT0GjtPN2YhxbY2uzsUo=.02c0d507-aacc-41a7-9492-44944f483bf0@github.com>
References: <b-dzUsyVw43_GNHgj0SvJX-HRTZ83wdjMpGSXBUuNjk=.9ad77320-25bc-420a-b24e-d282920a84b8@github.com>
 <24bzyIC2B6IuXlyByb_dSzOwT0GjtPN2YhxbY2uzsUo=.02c0d507-aacc-41a7-9492-44944f483bf0@github.com>
Message-ID: <3_6yDaTEJ8Ryd-5GKZQ0PXLgYd-hpYzmQoi35d_Gwqo=.9939c3ab-751d-48a2-b9e2-9807d166bcfa@github.com>

On Tue, 4 Oct 2022 18:03:39 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Update the freetype md file with the newly generated md file from attribution tool. The new format slightly differs from the previous version when separating different licenses. Added logic for combining of copyright lines and support for other licenses such as MIT.
>
> Damon Nguyen 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 'openjdk:master' into 8293672/updateFreeTypeMd
>  - Update md file

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Tue Oct  4 18:22:36 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Oct 2022 18:22:36 GMT
Subject: RFR: 8293672: Update freetype md file [v2]
In-Reply-To: <0-gwG-fhyvLXp4LWBNnJPj-WR2cItRn73VsV1SSeJNw=.f7f6ba4b-a5fe-48f5-8ac6-5c4473a0d07d@github.com>
References: <b-dzUsyVw43_GNHgj0SvJX-HRTZ83wdjMpGSXBUuNjk=.9ad77320-25bc-420a-b24e-d282920a84b8@github.com>
 <24bzyIC2B6IuXlyByb_dSzOwT0GjtPN2YhxbY2uzsUo=.02c0d507-aacc-41a7-9492-44944f483bf0@github.com>
 <Uf9NfQLjJ63MHSLATKgl_3DbzluH8pvLrNmg3OSdesE=.ac802530-4d23-43ae-9026-20a42419be1e@github.com>
 <0-gwG-fhyvLXp4LWBNnJPj-WR2cItRn73VsV1SSeJNw=.f7f6ba4b-a5fe-48f5-8ac6-5c4473a0d07d@github.com>
Message-ID: <nrCKwtpnSirfSuUcQLZwIo4EOUN_Pmg0Rfq-uwVKOy8=.50252324-e4ca-4875-81e0-989c983c218d@github.com>

On Tue, 4 Oct 2022 17:57:46 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/share/legal/freetype.md line 542:
>> 
>>> 540: /*
>>> 541:  * Copyright 2000 Computing Research Labs, New Mexico State University
>>> 542:  * Copyright 2001-2015
>> 
>> Why did this notice need to be moved down to the end of the file ?
>> It makes the diff look bigger than it actually is and I can't imagine any reason we would need to change the order.
>
> This is due to the addition of the MIT license being treated as a separate license from the freetype license. In the modified tool, licenses are separated by license type. The additional freetype licenses are "variants" of the primary license (freetype) so it seemed to make sense for it to follow the freetype & GPL license. Then, other licenses (such as MIT in this case) follow afterwards.
> 
> This can be manually modified to maintain the old order but I believed it made more sense this way in the tool since variants of the primary license would follow the primary license.

Well if it is only a one-off...

BTW phrases such as "the modified tool" etc are very out of place here .. I don't see a tool in this PR, do you ?
I believe you are referring to some script(s) that not part of OpenJDK that you are using to produce these updates.

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

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


From cjplummer at openjdk.org  Tue Oct  4 18:23:32 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 4 Oct 2022 18:23:32 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <bj6-5xC1mWXfuzSDLowQQPxYmo9OcqnW0XYnGLvEW0c=.c97b6b36-8590-47af-bdc2-e94f2230af08@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>
 <bj6-5xC1mWXfuzSDLowQQPxYmo9OcqnW0XYnGLvEW0c=.c97b6b36-8590-47af-bdc2-e94f2230af08@github.com>
Message-ID: <CR61AGqmsFAARRtaenUEX9DJvp3BC5TknkAuUGNXr8w=.ba3ebdbf-056c-46b7-8762-3e6aff4f1edd@github.com>

On Wed, 28 Sep 2022 15:32:11 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> The title was edited by someone other than me, as you can see from the PR history.

The PR title needs to match the CR synopsis, so update the CR first, and then update the PR.

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

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


From honkar at openjdk.org  Tue Oct  4 18:28:53 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 4 Oct 2022 18:28:53 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <eNAZ5y3qOhSUvb4VNzivXXo3WyfFJy3rsWjM8bKBJf4=.98c7a66d-6295-421f-affe-9546ee88915d@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <eNAZ5y3qOhSUvb4VNzivXXo3WyfFJy3rsWjM8bKBJf4=.98c7a66d-6295-421f-affe-9546ee88915d@github.com>
Message-ID: <bW6_rP-aHGFs9uZWwxTmJfTpw0CKu49eHzmLgFwPy6o=.f748291b-5d23-442f-86d7-4c5dd27105f3@github.com>

On Mon, 3 Oct 2022 22:02:28 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed redundant jtreg header
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 255:
> 
>> 253:          * @return a {@code int} which is the rounded value of provided number
>> 254:          */
>> 255:         private static int roundDown(double d)
> 
> The name of this method is a bit misleading, the operation doesn't actually round down, but rounds the number normally except for the x.5 case right? Does this operation exist somewhere else?

Yes, that is correct. The method doc does clarify the purpose. But I see your point - probably `roundOff()` would sound less ambiguous and neutral?

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

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


From duke at openjdk.org  Tue Oct  4 18:28:53 2022
From: duke at openjdk.org (Stanimir Stamenkov)
Date: Tue, 4 Oct 2022 18:28:53 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <bW6_rP-aHGFs9uZWwxTmJfTpw0CKu49eHzmLgFwPy6o=.f748291b-5d23-442f-86d7-4c5dd27105f3@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <eNAZ5y3qOhSUvb4VNzivXXo3WyfFJy3rsWjM8bKBJf4=.98c7a66d-6295-421f-affe-9546ee88915d@github.com>
 <bW6_rP-aHGFs9uZWwxTmJfTpw0CKu49eHzmLgFwPy6o=.f748291b-5d23-442f-86d7-4c5dd27105f3@github.com>
Message-ID: <h6SEEOYcF1MHdokP0lRYaZA1Z3HTF2Gp2ebanP_HR1c=.a2d9200c-a9b9-42d8-afaf-262b9537887c@github.com>

On Tue, 4 Oct 2022 18:23:17 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 255:
>> 
>>> 253:          * @return a {@code int} which is the rounded value of provided number
>>> 254:          */
>>> 255:         private static int roundDown(double d)
>> 
>> The name of this method is a bit misleading, the operation doesn't actually round down, but rounds the number normally except for the x.5 case right? Does this operation exist somewhere else?
>
> Yes, that is correct. The method doc does clarify the purpose. But I see your point - probably `roundOff()` would sound less ambiguous and neutral?

[`roundHalfDown`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/math/RoundingMode.html#HALF_DOWN)?

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

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


From aivanov at openjdk.org  Tue Oct  4 18:40:19 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Oct 2022 18:40:19 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <UemCGrDaiy4osk-rRrilEZG-HpCu9bN9Q_sHztLpdyU=.49fe52f2-1306-45f2-a455-f8c627d1ae31@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <0SIw07r--T4zF6fgkVRw0UY9qv0duIELblGCuxqcuZc=.f0d01224-6d2b-4e25-882b-cf0f0205004f@github.com>
 <UemCGrDaiy4osk-rRrilEZG-HpCu9bN9Q_sHztLpdyU=.49fe52f2-1306-45f2-a455-f8c627d1ae31@github.com>
Message-ID: <VdrfTNGNyvcyE7teukQrl1ATUAKGEN4Nrzsinr5ipQI=.9013c0e0-d93f-455e-bfb7-e088fd95bd42@github.com>

On Mon, 3 Oct 2022 22:16:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> > Out of curiosity, can this test use `BufferedImage` to render `JInternalFrame` into?
> 
> @aivanov-jdk Thank you for reviewing. I wanted to clarify whether you meant saving just the JInternalFrame into BufferedImage?

Yes, just `JInternalFrame`. Yet I was talking about rendering rather than capturing from the screen.

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

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


From honkar at openjdk.org  Tue Oct  4 18:40:21 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 4 Oct 2022 18:40:21 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <h6SEEOYcF1MHdokP0lRYaZA1Z3HTF2Gp2ebanP_HR1c=.a2d9200c-a9b9-42d8-afaf-262b9537887c@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <eNAZ5y3qOhSUvb4VNzivXXo3WyfFJy3rsWjM8bKBJf4=.98c7a66d-6295-421f-affe-9546ee88915d@github.com>
 <bW6_rP-aHGFs9uZWwxTmJfTpw0CKu49eHzmLgFwPy6o=.f748291b-5d23-442f-86d7-4c5dd27105f3@github.com>
 <h6SEEOYcF1MHdokP0lRYaZA1Z3HTF2Gp2ebanP_HR1c=.a2d9200c-a9b9-42d8-afaf-262b9537887c@github.com>
Message-ID: <13z2p5wpCDecwKztf2NtsxGisqYYZ5FPhPdds0WDdyw=.f289ded7-c81b-4f27-8e4e-a8eda81728db@github.com>

On Tue, 4 Oct 2022 18:26:26 GMT, Stanimir Stamenkov <duke at openjdk.org> wrote:

>> Yes, that is correct. The method doc does clarify the purpose. But I see your point - probably `roundOff()` would sound less ambiguous and neutral?
>
> [`roundHalfDown`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/math/RoundingMode.html#HALF_DOWN)?

@stanio Thank you for the suggestion- roundHalfDown fits the rounding functionality I was looking for.

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

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


From aivanov at openjdk.org  Tue Oct  4 18:40:24 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Oct 2022 18:40:24 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <4zanUg4ogg5XN71yR_lVWw3-2Cww15jC9ey_IBeT1lI=.552f826c-e870-454f-b187-0fbb8419f429@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <eNAZ5y3qOhSUvb4VNzivXXo3WyfFJy3rsWjM8bKBJf4=.98c7a66d-6295-421f-affe-9546ee88915d@github.com>
 <4zanUg4ogg5XN71yR_lVWw3-2Cww15jC9ey_IBeT1lI=.552f826c-e870-454f-b187-0fbb8419f429@github.com>
Message-ID: <V5owlypWt9Ev0IqxdWrXVfey1MPx6Q8Ghf_H0SX0wKY=.792c4dd8-4023-42fd-95f7-51d542e86332@github.com>

On Mon, 3 Oct 2022 22:43:40 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 329:
>> 
>>> 327: 
>>> 328:             // Draw the bulk of the border
>>> 329:             for (int i = 1; i <= loopCount; i++) {
>> 
>> Should we redo the drawing of this border to use Graphics2D fillRect instead?
>
> That was my initial thought too. But, as the loopCount won't be really large (Eg. it is 15 for 300% scaling) and it wouldn't affect the performance drastically, I have retained the original approach to draw the bulk of the border.

Let us leave it as is at this time. There are enough changes.

At the same time, it's a good suggestion for optimization. We should consider it in a separate CR.

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

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


From achung at openjdk.org  Tue Oct  4 18:40:25 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 4 Oct 2022 18:40:25 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <4zanUg4ogg5XN71yR_lVWw3-2Cww15jC9ey_IBeT1lI=.552f826c-e870-454f-b187-0fbb8419f429@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <eNAZ5y3qOhSUvb4VNzivXXo3WyfFJy3rsWjM8bKBJf4=.98c7a66d-6295-421f-affe-9546ee88915d@github.com>
 <4zanUg4ogg5XN71yR_lVWw3-2Cww15jC9ey_IBeT1lI=.552f826c-e870-454f-b187-0fbb8419f429@github.com>
Message-ID: <jK-7-a2DtjUpJy5kKnwnS_LQjhr9DAzZ8MQ4cYLhEDo=.6f060e93-60f5-449f-96c2-88cd7fe100fa@github.com>

On Mon, 3 Oct 2022 22:29:06 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 336:
>> 
>>> 334:                 // Draw the Long highlight lines
>>> 335:                 g.setColor(highlight);
>>> 336:                 g.drawLine(scaledCorner + 1, midPoint+stkWidth,
>> 
>> The spacing here and when drawing shadow lines is a bit inconsistent
>
> @alisenchung  I tried by increasing and decreasing the line position a bit, the current combination provided optimal positioning of both the shadow and highlight line within the border for all the scales. The slight inconsistency in spacing is probably due to rounding losses in loop count, stroke width and corner. I'll check it again.

Oh, I meant the actual code spacing, theres a space between scaledCorner and 1, but not space between midPoint and stkWidth

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

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


From prr at openjdk.org  Tue Oct  4 18:42:44 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Oct 2022 18:42:44 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v8]
In-Reply-To: <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
Message-ID: <sHOtl2OQ9-SEwkAbYNVq8gBaJMrW-my-5CBX2s1avkI=.8c95a200-f440-4e98-907f-2060e620c5b6@github.com>

On Mon, 3 Oct 2022 20:37:11 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 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 11 additional commits since the last revision:
> 
>  - Update accessibility URLs.
>  - Merge branch 'master' into JDK-8294618
>  - Update make directory.
>  - Update doc directory files.
>  - Update hg URLs to git.
>  - Merge branch 'master' into JDK-8294618
>  - http -> https
>  - Undo manpage update.
>  - Update copyright.
>  - Revert unintended update to binary file.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/571e4932...4055f1a6

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Tue Oct  4 18:43:26 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Oct 2022 18:43:26 GMT
Subject: RFR: 8270915: GIFImageReader disregards ignoreMetadata flag which
 causes memory exhaustion
In-Reply-To: <MNVf1oMbzOO8Zpyk551X7bNJQeGsUbHiyC8kBKsuixw=.fd9b04d2-5cce-4dd7-9b49-15042925743c@github.com>
References: <MNVf1oMbzOO8Zpyk551X7bNJQeGsUbHiyC8kBKsuixw=.fd9b04d2-5cce-4dd7-9b49-15042925743c@github.com>
Message-ID: <zEwaySsQ-o_5A2Ow6ZMSgQTALPFB-BpnVxVGevQOKhg=.c712b32e-88c3-4d51-b4a4-9491190f1212@github.com>

On Mon, 3 Oct 2022 13:59:25 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> In https://bugs.openjdk.org/browse/JDK-8270915 we have a valid GIF image which was generated using a third party app, but it contains large amount of Metadata(numerous Application extension blocks).
> 
> Also GIFImageReader doesn't use ignoreMetadata flag set by user while reading Metadata which causes heavy memory usage in this scenario. We need to provide support for ignoring metadata in GIFImageReader, so readMetadata() is updated to use the "ignoreMetadata" flag and ignore all blocks except "Image Descriptor" and "Graphics Control Extension".
> 
> I have updated readMedata() to also use ReaderUtil.staggeredReadByteStream() where we are allocating upfront memory based on parameters from metadata. Also this PR has small refactoring of import statements.
> 
> To replicate the bug we need byte stream with large amount of valid metadata, so i am not able to add regression test case. I have run all javax/imageio jtreg tests and there are no issues.

LGTM

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

Marked as reviewed by prr (Reviewer).

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


From aivanov at openjdk.org  Tue Oct  4 18:52:34 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Oct 2022 18:52:34 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <VdrfTNGNyvcyE7teukQrl1ATUAKGEN4Nrzsinr5ipQI=.9013c0e0-d93f-455e-bfb7-e088fd95bd42@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <0SIw07r--T4zF6fgkVRw0UY9qv0duIELblGCuxqcuZc=.f0d01224-6d2b-4e25-882b-cf0f0205004f@github.com>
 <UemCGrDaiy4osk-rRrilEZG-HpCu9bN9Q_sHztLpdyU=.49fe52f2-1306-45f2-a455-f8c627d1ae31@github.com>
 <VdrfTNGNyvcyE7teukQrl1ATUAKGEN4Nrzsinr5ipQI=.9013c0e0-d93f-455e-bfb7-e088fd95bd42@github.com>
Message-ID: <hnlpIVPe1vxw8KeulUxLSmEYiGgMQIIkTKv00KF-oFk=.eaa9e60b-f77e-4c4d-a6b1-cfb59f8642fe@github.com>

On Tue, 4 Oct 2022 18:32:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Out of curiosity, can this test use `BufferedImage` to render `JInternalFrame` into?
>> 
>> @aivanov-jdk Thank you for reviewing. I wanted to clarify whether you meant saving just the JInternalFrame into BufferedImage?
>
>> > Out of curiosity, can this test use `BufferedImage` to render `JInternalFrame` into?
>> 
>> @aivanov-jdk Thank you for reviewing. I wanted to clarify whether you meant saving just the JInternalFrame into BufferedImage?
> 
> Yes, just `JInternalFrame`. Yet I was talking about rendering rather than capturing from the screen.

> @aivanov-jdk Regarding saving the screen capture -
> 
> When JIF bounds are used, a partial image of JInternalFrame (JIF) is saved. Hence I'm using the entire outer JFrame bounds to capture the screenshot.

Could be? It shouldn't. Anyway, I have no problem with capturing the entire `JFrame`.

> 
> For the screenCapture I wanted to use **BufferedImage's getScaledInstance()** to create the scaled version (code snippet below), but experiencing issues while saving it. Currently I'm scaling the original image and re-drawing it using graphics object.
 
This is definitely not what we want. It just up-scales or down-scales the current image stored in `BufferedImage`.

When you run in a HiDPI environment or with `uiScale` set explicitly to a value greater than 1.0, the number of pixels is higher. `Robot.createScreenCapture` up-scales the passed in rectangle, captures all the pixels and then down-scales the captured screenshot to the user's space coordinates.

At the same time, [`createMultiResolutionScreenCapture`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Robot.html#createScreenCapture(java.awt.Rectangle)) returns a `MultiResolutionImage` which contains two variants: (1) the base image with the user specified size, down-scaled from the screen; (2) native resolution image with the device size pixels. The second variant will preserve all the pixels seen on the screen.

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

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


From prr at openjdk.org  Tue Oct  4 19:14:21 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Oct 2022 19:14:21 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: <s5B0E96IjoO4O-z7P-mDch7ZLlfYbKujVMXw5YrhcNg=.8f2a4175-1470-4b51-9797-45f88f79c00b@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 prr (Reviewer).

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

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


From prr at openjdk.org  Tue Oct  4 19:14:23 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Oct 2022 19:14:23 GMT
Subject: RFR: 8278086: [REDO] ImageIO.write() method will throw
 IndexOutOfBoundsException [v2]
In-Reply-To: <JK7S6_rT-LlBTMF_Kv1wFOYREdt2X-dsqdqNT4fEfYY=.94f65bac-6294-42b4-a402-f613c80f855a@github.com>
References: <m6yQDNwg4jCq1vRHp9i-aaiBjutuSMNboon6xAs8UGQ=.162d3d4c-641f-41d1-8392-ce7bbde96613@github.com>
 <cy1Vkb0CECBWHX0F3DDUdhDFGCKhTZlGZ9y35YGayPo=.144df86a-f0eb-4d1e-9bf2-ccf0955d857d@github.com>
 <hTENGHR5qnfSNQCPiAPCHLsuHXoHcait9pGVQ9EyPrs=.58a20567-4da3-410a-b3aa-a6efb663e3e2@github.com>
 <JK7S6_rT-LlBTMF_Kv1wFOYREdt2X-dsqdqNT4fEfYY=.94f65bac-6294-42b4-a402-f613c80f855a@github.com>
Message-ID: <TGNcM9jf4lut0c7-LHN5MVNeIwT15yNH4PvZXKnl_V4=.4db532c5-e303-45e8-b747-4adc1b96a538@github.com>

On Mon, 3 Oct 2022 06:41:03 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> 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 ?
>
> Hi Phil,
> 
> We never had any bpp check to verify what standard bpp's should be allowed in BMP.
> Because of this when we tried to decode 2 bpp PNG img and write it to BMP we used to get IOOBE as captured in https://bugs.openjdk.org/browse/JDK-8262297. So under this bug, check was added to allow only standard bpp's for BMP encoding : https://github.com/openjdk/jdk/commit/c73319354399596ab2b9aab0a7f62e8fa0ab9365. 
> 
> But this caused regression of many jtreg tests which were using USHORT_555_RGB to encode BMP image(we round off this 15bpp to 16bpp and at later stage : https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java#L472 and store it in 16bit data buffer). So i relaxed this check which caused jtreg regressions to allow 15bpp also.
> 
> Since we straight away reject non-standard bits per pixel (like 2 bpp) for BMP encoding, we will throw IOException instead to going ahead and throwing non-documented exceptions like IOOBE.

Ah, the bit you weren't / aren't explaining is that the reason I'm not seeing the check which would have dis-allowed 15bpp 
is that you backed it out ages ago https://github.com/openjdk/jdk/commit/84aa0a191b085a3d7cb338fd5e67281d0e4b57be
because of the failures it caused.

So now that code is being re-added but this time allowing 15bpp

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

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


From prr at openjdk.org  Tue Oct  4 19:16:21 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Oct 2022 19:16:21 GMT
Subject: RFR: 8294255: Add link to DEFAULT_WAIT_TIME in javadoc for
 SunToolKit.realsSync
In-Reply-To: <5IKSHb5lsL9So0XoN2YDv7GhGjL0j_gi9FWtpZ0IykE=.f315a62e-1d87-4ed5-a6a7-f86d6db34b7f@github.com>
References: <5IKSHb5lsL9So0XoN2YDv7GhGjL0j_gi9FWtpZ0IykE=.f315a62e-1d87-4ed5-a6a7-f86d6db34b7f@github.com>
Message-ID: <3iMLLP1QnhYtKJkESRtwil_McyMF7wDjVhxF9CWbBTE=.16fa8abd-c70b-4e4e-8607-4a229197ab51@github.com>

On Fri, 23 Sep 2022 01:11:14 GMT, SWinxy <duke at openjdk.org> wrote:

> 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}.
>   */

Marked as reviewed by prr (Reviewer).

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

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


From duke at openjdk.org  Tue Oct  4 19:19:10 2022
From: duke at openjdk.org (SWinxy)
Date: Tue, 4 Oct 2022 19:19:10 GMT
Subject: Integrated: 8294255: Add link to DEFAULT_WAIT_TIME in javadoc for
 SunToolKit.realsSync
In-Reply-To: <5IKSHb5lsL9So0XoN2YDv7GhGjL0j_gi9FWtpZ0IykE=.f315a62e-1d87-4ed5-a6a7-f86d6db34b7f@github.com>
References: <5IKSHb5lsL9So0XoN2YDv7GhGjL0j_gi9FWtpZ0IykE=.f315a62e-1d87-4ed5-a6a7-f86d6db34b7f@github.com>
Message-ID: <m3TDYS7G2NWXJP99U_zcpznH_NH_t_eCpgsxwGjG3s8=.200b9d5b-e56b-43b4-b310-0f061ce55480@github.com>

On Fri, 23 Sep 2022 01:11:14 GMT, SWinxy <duke at openjdk.org> wrote:

> 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}.
>   */

This pull request has now been integrated.

Changeset: b2e86a62
Author:    SWinxy <swinxythecat at gmail.com>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b2e86a620936cc0d65ca884ff2b6644998530354
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8294255: Add link to DEFAULT_WAIT_TIME in javadoc for SunToolKit.realsSync

Reviewed-by: aivanov, prr

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

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


From aivanov at openjdk.org  Tue Oct  4 19:52:27 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Oct 2022 19:52:27 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v5]
In-Reply-To: <TfVEzqvCHRXUBpWMM_5nO5ej7yg_OwjOEL1wS9HgiXM=.0f9835af-b518-4d26-8d89-7d6c09a72d45@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <TfVEzqvCHRXUBpWMM_5nO5ej7yg_OwjOEL1wS9HgiXM=.0f9835af-b518-4d26-8d89-7d6c09a72d45@github.com>
Message-ID: <ZqCPxOHwep_nHU8fm_Lo6NaYcOxxttxMGYowaH8E4Ww=.0e2242a2-427c-44f2-9e84-3fa348239d2b@github.com>

On Tue, 4 Oct 2022 17:48:55 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:
> 
>   review changes, saving a scaled version of image

It looks good to me, except for the comments I left on the coding style.

Yet there's one thing which I noticed in the rendered border. The top left corner has one pixel which is painted over the title bar. It's present in the original painting code. The top right corner has such a pixel too.

The updated code paints the top left corner with that pixel. Yet in the top right corner, it moved to left.
![top right corner of the JInternalFrame](https://user-images.githubusercontent.com/70774172/193912190-8faf432e-0bc2-4906-8811-e3780da86b9b.png)

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 29:

> 27: import javax.swing.JLabel;
> 28: import javax.swing.SwingUtilities;
> 29: import javax.swing.UIManager;

I'd rather stick to the same order of imports in sources and tests. However, swing components used are more important.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 185:

> 183:                 errorLog.append("At uiScale: "+ uiScale +
> 184:                 ", Red background color detected at "
> 185:                 + borderDirection + " border\n");

This doesn't look right either. The old code had only the body of `if` incorrectly indented.


            if (Color.RED.equals(robot.getPixelColor(
                    isVertical ? i : (iFrameLoc.x + MIDPOINT),
                    isHorizontal ? i : (iFrameLoc.y + MIDPOINT)))) {
                saveScreenCapture(borderDirection + "_" + uiScale + ".png");
                errorLog.append("uiScale: " + uiScale
                        + " Red background color detected at "
                        + borderDirection + " border\n");


Continuation lines are indented twice as much or to align with a level they're wrapped at. The example for the second case:

                errorLog.append("uiScale: " + uiScale
                                + " Red background color detected at "
                                + borderDirection + " border\n");

Here, the operators on the wrapped lines align to the following column of the opening parenthesis for parameters of `append`.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 217:

> 215:         if (Color.RED.equals(robot.getPixelColor(x, y))) {
> 216:             saveScreenCapture(cornerLocation + "_" + uiScale + ".png", uiScale);
> 217:             errorLog.append("At uiScale: "+ uiScale + ", Red background color" +

Suggestion:

            errorLog.append("At uiScale: " + uiScale + ", Red background color" +

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 229:

> 227:         jFrame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
> 228: 
> 229:         JLabel scale = new JLabel("UI Scale: "+ uiScale);

Suggestion:

        JLabel scale = new JLabel("UI Scale: " + uiScale);

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 252:

> 250:         g2d.scale(scale, scale);
> 251:         g2d.drawImage(image, 0, 0, null);
> 252:         g2d.dispose();

This does not make sense, it up-scales a down-scaled image. Either revert to the previous version or use `createMultiResolutionScreenCapture` and save all resolution variants from the `MultiResolutionImage`.

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

Changes requested by aivanov (Reviewer).

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


From aivanov at openjdk.org  Tue Oct  4 20:01:28 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Oct 2022 20:01:28 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v5]
In-Reply-To: <ZqCPxOHwep_nHU8fm_Lo6NaYcOxxttxMGYowaH8E4Ww=.0e2242a2-427c-44f2-9e84-3fa348239d2b@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <TfVEzqvCHRXUBpWMM_5nO5ej7yg_OwjOEL1wS9HgiXM=.0f9835af-b518-4d26-8d89-7d6c09a72d45@github.com>
 <ZqCPxOHwep_nHU8fm_Lo6NaYcOxxttxMGYowaH8E4Ww=.0e2242a2-427c-44f2-9e84-3fa348239d2b@github.com>
Message-ID: <q9PsQ70JJ3N6Hg1zHQNfOZZgAJVSCtGwgYwo5K546fw=.40d9581e-bd6a-478d-bae1-dfb84e42ae05@github.com>

On Tue, 4 Oct 2022 19:37:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review changes, saving a scaled version of image
>
> test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 185:
> 
>> 183:                 errorLog.append("At uiScale: "+ uiScale +
>> 184:                 ", Red background color detected at "
>> 185:                 + borderDirection + " border\n");
> 
> This doesn't look right either. The old code had only the body of `if` incorrectly indented.
> 
> 
>             if (Color.RED.equals(robot.getPixelColor(
>                     isVertical ? i : (iFrameLoc.x + MIDPOINT),
>                     isHorizontal ? i : (iFrameLoc.y + MIDPOINT)))) {
>                 saveScreenCapture(borderDirection + "_" + uiScale + ".png");
>                 errorLog.append("uiScale: " + uiScale
>                         + " Red background color detected at "
>                         + borderDirection + " border\n");
> 
> 
> Continuation lines are indented twice as much or to align with a level they're wrapped at. The example for the second case:
> 
>                 errorLog.append("uiScale: " + uiScale
>                                 + " Red background color detected at "
>                                 + borderDirection + " border\n");
> 
> Here, the operators on the wrapped lines align to the following column of the opening parenthesis for parameters of `append`.

In my example, I put the operators on the continuation line, it's what Java Coding Style recommends. However, leaving the operators on the previous line is very common.

Here, you're mixing two styles: the first continuation line with `append` parameter had `+` at the end of the line, but the second line wrapped the `+` operator to the next line.

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

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


From aivanov at openjdk.org  Tue Oct  4 20:09:42 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Oct 2022 20:09:42 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <13z2p5wpCDecwKztf2NtsxGisqYYZ5FPhPdds0WDdyw=.f289ded7-c81b-4f27-8e4e-a8eda81728db@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <eNAZ5y3qOhSUvb4VNzivXXo3WyfFJy3rsWjM8bKBJf4=.98c7a66d-6295-421f-affe-9546ee88915d@github.com>
 <bW6_rP-aHGFs9uZWwxTmJfTpw0CKu49eHzmLgFwPy6o=.f748291b-5d23-442f-86d7-4c5dd27105f3@github.com>
 <h6SEEOYcF1MHdokP0lRYaZA1Z3HTF2Gp2ebanP_HR1c=.a2d9200c-a9b9-42d8-afaf-262b9537887c@github.com>
 <13z2p5wpCDecwKztf2NtsxGisqYYZ5FPhPdds0WDdyw=.f289ded7-c81b-4f27-8e4e-a8eda81728db@github.com>
Message-ID: <XMcvhF3ciHeQWW3IlDUVnZldyz0BVPZVBEMPbWxQRBw=.48c3479a-78e1-47ba-82c7-df34847767d5@github.com>

On Tue, 4 Oct 2022 18:35:34 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> [`roundHalfDown`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/math/RoundingMode.html#HALF_DOWN)?
>
> @stanio Thank you for the suggestion- roundHalfDown fits the rounding functionality I was looking for.

Since you'll be changing the name of the method, please place the opening brace on the same line as the method declaration.

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

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


From aivanov at openjdk.org  Tue Oct  4 20:09:43 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Oct 2022 20:09:43 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v5]
In-Reply-To: <TfVEzqvCHRXUBpWMM_5nO5ej7yg_OwjOEL1wS9HgiXM=.0f9835af-b518-4d26-8d89-7d6c09a72d45@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <TfVEzqvCHRXUBpWMM_5nO5ej7yg_OwjOEL1wS9HgiXM=.0f9835af-b518-4d26-8d89-7d6c09a72d45@github.com>
Message-ID: <Wi3cDHOWkd_k9ss3O3hBjz-Wy5PDF1NoCQ4rDt0Sjm8=.df041859-9495-4ffb-b31a-ba461d2fc1a2@github.com>

On Tue, 4 Oct 2022 17:48:55 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:
> 
>   review changes, saving a scaled version of image

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 320:

> 318:             // midpoint at which highlight & shadow lines
> 319:             // are positioned on the border
> 320:             int midPoint = loopCount / 2;

This variable is used only if the internal frame is resizable. It should be declared inside the corresponding `if` statement.

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

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


From aivanov at openjdk.org  Tue Oct  4 20:28:27 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Oct 2022 20:28:27 GMT
Subject: RFR: 8294807: Fix typos and clarify javadoc for SunToolKit.realsSync
Message-ID: <eOSJ4nSjRiskHcEirxMJmllsCP0e0wHQQ8__azU0CEw=.3a2a29b2-a349-43f9-bbd5-14b6e2ee32a2@github.com>

I fixed the typo ?serie? ? "series" which was highlighted by a spellchecker.

I also simplified the description, fixed the grammar, added `{@code}` around types, added link to `requestFocus` in the example.

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

Commit messages:
 - Amend the javadoc for SunToolkit.realSync(long)

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

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


From aivanov at openjdk.org  Tue Oct  4 20:28:28 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Oct 2022 20:28:28 GMT
Subject: RFR: 8294807: Fix typos and clarify javadoc for
 SunToolKit.realsSync
In-Reply-To: <eOSJ4nSjRiskHcEirxMJmllsCP0e0wHQQ8__azU0CEw=.3a2a29b2-a349-43f9-bbd5-14b6e2ee32a2@github.com>
References: <eOSJ4nSjRiskHcEirxMJmllsCP0e0wHQQ8__azU0CEw=.3a2a29b2-a349-43f9-bbd5-14b6e2ee32a2@github.com>
Message-ID: <5GlfDtRnHLa7PIslOaYDEg8g0M2oB2-YNAatMtJbDWU=.6d381cb4-c329-4b83-a5d6-29dc96521edb@github.com>

On Tue, 4 Oct 2022 20:21:10 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I fixed the typo ?serie? ? "series" which was highlighted by a spellchecker.
> 
> I also simplified the description, fixed the grammar, added `{@code}` around types, added link to `requestFocus` in the example.

src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1451:

> 1449:      *
> 1450:      * <p> This method allows writing tests without explicit timeouts
> 1451:      * or waiting for some event.  Example:

Should it be ?without _using_ ? or waiting ???  
Does ?for an event? sound better?

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

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


From aivanov at openjdk.org  Tue Oct  4 20:29:56 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Oct 2022 20:29:56 GMT
Subject: RFR: 8294807: Fix typos and clarify javadoc for
 SunToolKit.realsSync
In-Reply-To: <eOSJ4nSjRiskHcEirxMJmllsCP0e0wHQQ8__azU0CEw=.3a2a29b2-a349-43f9-bbd5-14b6e2ee32a2@github.com>
References: <eOSJ4nSjRiskHcEirxMJmllsCP0e0wHQQ8__azU0CEw=.3a2a29b2-a349-43f9-bbd5-14b6e2ee32a2@github.com>
Message-ID: <hXC8HiNXdHgKcyZnFbI9iYVeeHoSDl3MP7tcH2sWI6s=.ef447351-52ad-4fca-a28b-e60cc862d88c@github.com>

On Tue, 4 Oct 2022 20:21:10 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I fixed the typo ?serie? ? "series" which was highlighted by a spellchecker.
> 
> I also simplified the description, fixed the grammar, added `{@code}` around types, added link to `requestFocus` in the example.

src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1481:

> 1479:      * focus events, which then generate a series of paint events,
> 1480:      * a series of Java focus events, which then generate
> 1481:      * a series of paint events which then are processed &mdash;

The only change here is I added the link to `requestFocus` and replaced hyphen with mdash. I re-flowed the text for easier reading in the source code.

Probably, this text could be improved?

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

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


From honkar at openjdk.org  Tue Oct  4 20:37:35 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 4 Oct 2022 20:37:35 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v6]
In-Reply-To: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
Message-ID: <LEKoN3bLUDwPutRG2n_dB0kXKfgNGJw8lJCW67RopfU=.65912059-f36e-4bf0-904c-8ef364c1a120@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:

  MRI changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10274/files
  - new: https://git.openjdk.org/jdk/pull/10274/files/6efd8417..d72d6d16

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

  Stats: 41 lines in 2 files changed: 14 ins; 7 del; 20 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  Tue Oct  4 21:34:38 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Oct 2022 21:34:38 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v6]
In-Reply-To: <LEKoN3bLUDwPutRG2n_dB0kXKfgNGJw8lJCW67RopfU=.65912059-f36e-4bf0-904c-8ef364c1a120@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <LEKoN3bLUDwPutRG2n_dB0kXKfgNGJw8lJCW67RopfU=.65912059-f36e-4bf0-904c-8ef364c1a120@github.com>
Message-ID: <5XLuv9NDunqVdUSXNO_UsMKLVyc0EYfAwOEfzS-wdRo=.0fa69cfd-318e-456b-bdfd-21f35100988f@github.com>

On Tue, 4 Oct 2022 20:37:35 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:
> 
>   MRI changes

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 256:

> 254:         } else {
> 255:             nativeResImage = resolutionVariants.get(0);
> 256:         }

Suggestion:

        RenderedImage image = (RenderedImage) resolutionVariants.get(resolutionVariants.size() > 1 ? 1 : 0);

or rather simpler:
Suggestion:

        RenderedImage image = (RenderedImage) resolutionVariants.get(resolutionVariants.size() - 1);

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

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


From honkar at openjdk.org  Tue Oct  4 22:06:07 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 4 Oct 2022 22:06:07 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v7]
In-Reply-To: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
Message-ID: <5LBhU0Tkp2GngUkCt1tAAEe1f8qxzP2I4CVMAQhW8zw=.9c520957-5aa6-4431-83d5-0f76119e39b9@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:

  review changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10274/files
  - new: https://git.openjdk.org/jdk/pull/10274/files/d72d6d16..827a3484

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

  Stats: 45 lines in 2 files changed: 12 ins; 19 del; 14 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 duke at openjdk.org  Tue Oct  4 23:00:00 2022
From: duke at openjdk.org (SWinxy)
Date: Tue, 4 Oct 2022 23:00:00 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled
Message-ID: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>

Many `installDefaults` methods set the font, foreground, and background on objects but their inverse methods `uninstallDefaults` do not remove them. I've added an inverse method to remove the colors and font to call for the `uninstallDefaults` methods that install defaults.

`AquaButtonUI` can call its super since it would otherwise be repeated code. `BasicComboBoxUI` (weirdly) installs the properties again when it should be uninstalling them, so I changed.

I noticed that, in a few subclasses, only one of calls to the super of `installDefaults` and `uninstallDefaults` are made. That is, an overridden `installDefaults` may call its super while the overridden `uninstallDefaults` does not call its super (or vise versa). These classes are: `AquaTabbedPaneUI`, `SynthMenuItemUI`, `SynthSplitPaneUI`, and `XTextAreaPeer`.

Sorry I couldn't write a test; I wasn't sure how I should have accessed the protected variable aside from creating extending classes for each class that changed.

See also #6603, where this issue was discovered.

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

Commit messages:
 - Accidental imports added
 - 8278620: properties installed by javax.swing.LookAndFeel installColors and installColorsAndFont are not uninstalled

Changes: https://git.openjdk.org/jdk/pull/10565/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10565&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8278620
  Stats: 112 lines in 28 files changed: 74 ins; 12 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/10565.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10565/head:pull/10565

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


From honkar at openjdk.org  Wed Oct  5 00:31:55 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 5 Oct 2022 00:31:55 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v5]
In-Reply-To: <ZqCPxOHwep_nHU8fm_Lo6NaYcOxxttxMGYowaH8E4Ww=.0e2242a2-427c-44f2-9e84-3fa348239d2b@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <TfVEzqvCHRXUBpWMM_5nO5ej7yg_OwjOEL1wS9HgiXM=.0f9835af-b518-4d26-8d89-7d6c09a72d45@github.com>
 <ZqCPxOHwep_nHU8fm_Lo6NaYcOxxttxMGYowaH8E4Ww=.0e2242a2-427c-44f2-9e84-3fa348239d2b@github.com>
Message-ID: <S6wtILhxRJGil5zmnKEYXOpYQpKqntL8N35g5uZ2bZk=.96fa64e9-bfd3-4a95-a98c-d90d6237e4c2@github.com>

On Tue, 4 Oct 2022 19:50:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> It looks good to me, except for the comments I left on the coding style.
> 
> Yet there's one thing which I noticed in the rendered border. The top left corner has one pixel which is painted over the title bar. It's present in the original painting code. The top right corner has such a pixel too.
> 
> The updated code paints the top left corner with that pixel. Yet in the top right corner, it moved to left. ![top right corner of the JInternalFrame](https://user-images.githubusercontent.com/70774172/193912190-8faf432e-0bc2-4906-8811-e3780da86b9b.png)

@aivanov-jdk The extra pixel seems to be added due to JInternalFrame titlebar and not from the paintBorder() code changes. Below is the screenshot of JIF (at 300% scale) rendered when the paintBorder() code is commented out completely. It seems to match the pixel of the pattern on the title bar.

![image](https://user-images.githubusercontent.com/95945681/193954011-fefc967b-62fb-4035-8fba-7ae7db471f23.png)

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

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


From honkar at openjdk.org  Wed Oct  5 01:18:06 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 5 Oct 2022 01:18:06 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <V5owlypWt9Ev0IqxdWrXVfey1MPx6Q8Ghf_H0SX0wKY=.792c4dd8-4023-42fd-95f7-51d542e86332@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <eNAZ5y3qOhSUvb4VNzivXXo3WyfFJy3rsWjM8bKBJf4=.98c7a66d-6295-421f-affe-9546ee88915d@github.com>
 <4zanUg4ogg5XN71yR_lVWw3-2Cww15jC9ey_IBeT1lI=.552f826c-e870-454f-b187-0fbb8419f429@github.com>
 <V5owlypWt9Ev0IqxdWrXVfey1MPx6Q8Ghf_H0SX0wKY=.792c4dd8-4023-42fd-95f7-51d542e86332@github.com>
Message-ID: <3p4Nc9qBWBWXHvrfX7NaS-F6k2i8gKPd981RPBOmSWo=.2041124e-435f-4aa0-8a56-967ac594b22e@github.com>

On Tue, 4 Oct 2022 18:31:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> That was my initial thought too. But, as the loopCount won't be really large (Eg. it is 15 for 300% scaling) and it wouldn't affect the performance drastically, I have retained the original approach to draw the bulk of the border.
>
> Let us leave it as is at this time. There are enough changes.
> 
> At the same time, it's a good suggestion for optimization. We should consider it in a separate CR.

I agree, this code can be improved further using fillRect().

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

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


From ihse at openjdk.org  Wed Oct  5 07:43:19 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 5 Oct 2022 07:43:19 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v8]
In-Reply-To: <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
Message-ID: <VwPBSkgS79Le2mS0S-MK5Zsm49GZ3eIHj-M-yyHovZg=.219c7fcd-da16-4b54-b50f-6b203107fde2@github.com>

On Mon, 3 Oct 2022 20:37:11 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 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 11 additional commits since the last revision:
> 
>  - Update accessibility URLs.
>  - Merge branch 'master' into JDK-8294618
>  - Update make directory.
>  - Update doc directory files.
>  - Update hg URLs to git.
>  - Merge branch 'master' into JDK-8294618
>  - http -> https
>  - Undo manpage update.
>  - Update copyright.
>  - Revert unintended update to binary file.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/72d7bf5d...4055f1a6

Marked as reviewed by ihse (Reviewer).

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

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


From rgiulietti at openjdk.org  Wed Oct  5 10:02:49 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 10:02:49 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - 8294456: Fix misleading-indentation warnings in JDK
   
   Merge branch 'master' into JDK-8294456
 - 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=01
  Stats: 9 lines in 4 files changed: 1 ins; 1 del; 7 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  Wed Oct  5 10:08:31 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 10:08:31 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
Message-ID: <56bmZbja-KHTjSDqWCsX7s2RwGkpyWIDwGLBua1d5FA=.063111f6-4ad4-4508-9ae1-7e55a9810261@github.com>

On Wed, 5 Oct 2022 10:02:49 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.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8294456: Fix misleading-indentation warnings in JDK
>    
>    Merge branch 'master' into JDK-8294456
>  - 8294456: Fix misleading-indentation warnings in JDK

I had to solve a merge conflict after https://github.com/openjdk/jdk/pull/10426 was integrated.
I think my changes need another review on the conflicting file.

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

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


From shade at openjdk.org  Wed Oct  5 10:20:33 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 10:20:33 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
Message-ID: <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>

On Wed, 5 Oct 2022 10:02:49 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.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8294456: Fix misleading-indentation warnings in JDK
>    
>    Merge branch 'master' into JDK-8294456
>  - 8294456: Fix misleading-indentation warnings in JDK

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 298:

> 296:     HEADERS_FROM_SRC := $(LIBLCMS_HEADERS_FROM_SRC), \
> 297:     DISABLED_WARNINGS_gcc := format-nonliteral type-limits \
> 298:         undef unused-function stringop-truncation, \

Ok, let's not touch this global warning and rename the issue to "Fix misleading-indentation warnings in core JDK libraries". Leave the Awt2d change to another day.

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

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


From aivanov at openjdk.org  Wed Oct  5 10:49:24 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Oct 2022 10:49:24 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v31]
In-Reply-To: <84Tcbg0LrWSfpvD0bb2Ca6y4T-CNhYVZHVGeTCo0Ef4=.b63d26a1-817f-498d-84b8-39ed3a987dbe@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <84Tcbg0LrWSfpvD0bb2Ca6y4T-CNhYVZHVGeTCo0Ef4=.b63d26a1-817f-498d-84b8-39ed3a987dbe@github.com>
Message-ID: <kgvAJf50p35BpiPF3gfYbkDH_N_zYUieEZvA1uWV3TI=.9b05503d-ccc4-49fe-8d62-c28206696f5d@github.com>

On Thu, 29 Sep 2022 14:39:04 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 rgiulietti at openjdk.org  Wed Oct  5 12:03:22 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 12:03:22 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
 <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>
Message-ID: <1UQyX79zIVU7mGxkOTSULe7S7DZNDUjOy6NPnSP8V1c=.ddb4d2f9-f784-4fe2-9eb1-bb29349ecb55@github.com>

On Wed, 5 Oct 2022 10:16:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - 8294456: Fix misleading-indentation warnings in JDK
>>    
>>    Merge branch 'master' into JDK-8294456
>>  - 8294456: Fix misleading-indentation warnings in JDK
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 298:
> 
>> 296:     HEADERS_FROM_SRC := $(LIBLCMS_HEADERS_FROM_SRC), \
>> 297:     DISABLED_WARNINGS_gcc := format-nonliteral type-limits \
>> 298:         undef unused-function stringop-truncation, \
> 
> Ok, let's not touch this global warning and rename the issue to "Fix misleading-indentation warnings in core JDK libraries". Leave the Awt2d change to another day.

What is the problem with Awt2d? Other conflicts?

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

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


From shade at openjdk.org  Wed Oct  5 12:11:21 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 12:11:21 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <1UQyX79zIVU7mGxkOTSULe7S7DZNDUjOy6NPnSP8V1c=.ddb4d2f9-f784-4fe2-9eb1-bb29349ecb55@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
 <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>
 <1UQyX79zIVU7mGxkOTSULe7S7DZNDUjOy6NPnSP8V1c=.ddb4d2f9-f784-4fe2-9eb1-bb29349ecb55@github.com>
Message-ID: <c7hWjn16Z60UOPEWegOIMbAk8RkWYbNvV_gEoPLbwZU=.8bf3e6e6-5fbd-4d3d-9662-b5e099ff6a89@github.com>

On Wed, 5 Oct 2022 12:01:00 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 298:
>> 
>>> 296:     HEADERS_FROM_SRC := $(LIBLCMS_HEADERS_FROM_SRC), \
>>> 297:     DISABLED_WARNINGS_gcc := format-nonliteral type-limits \
>>> 298:         undef unused-function stringop-truncation, \
>> 
>> Ok, let's not touch this global warning and rename the issue to "Fix misleading-indentation warnings in core JDK libraries". Leave the Awt2d change to another day.
>
> What is the problem with Awt2d? Other conflicts?

I am not completely sure all `misleading-indentation` warnings are fixed in Awt2d, this would require some more testing. I'd defer that to #10453.

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

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


From aivanov at openjdk.org  Wed Oct  5 13:27:29 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Oct 2022 13:27:29 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: <PnxcaX4A0UPATWCWR6qBg7AHmu1d6spEkRYu5mpKFME=.e81f7c64-59d7-48a9-b74a-254af1cc1a18@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

Changes requested by aivanov (Reviewer).

src/hotspot/share/opto/memnode.cpp line 2365:

> 2363:   if (x != this)  return x;
> 2364: 
> 2365:   // Take apart the address into an oop and offset.

?and _an_ offset??

src/java.xml/share/classes/org/w3c/dom/Document.java line 293:

> 291:      * <code>systemId</code>, and <code>notationName</code> attributes are
> 292:      * copied. If a <code>deep</code> import is requested, the descendants
> 293:      * of the source <code>Entity</code> are recursively imported and

This class may come from a 3rd party library. Anyone from `java.xml` can confirm it?

test/hotspot/jtreg/vmTestbase/nsk/share/locks/DeadlockMaker.java line 31:

> 29: /*
> 30:  * Class used to create deadlocked threads. It is possible create 2 or more deadlocked thread, also
> 31:  * is possible to specify resource of which type should lock each deadlocked thread

Suggestion:

 * it is possible to specify resource of which type should lock each deadlocked thread

It doesn't sound right without _?it?_.

test/jdk/com/sun/jdi/connect/spi/GeneratedConnectors.java line 28:

> 26:  * @summary Unit test for "Pluggable Connectors and Transports" feature.
> 27:  *
> 28:  * When a transport service is deployed the virtual machine

Suggestion:

 * When a transport service is deployed, the virtual machine

Let's add a comma for clarity.

test/jdk/java/security/testlibrary/SimpleOCSPServer.java line 445:

> 443: 
> 444:     /**
> 445:      * Check the status database for revocation information on one or more

Suggestion:

     * Check the status database for revocation information of one or more

test/jdk/sun/jvmstat/testlibrary/utils.sh line 181:

> 179:         if [ $? -eq 0 ]
> 180:         then
> 181:             # it's still lingering, now it is hard

Suggestion:

            # it's still lingering, now hit it hard

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

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


From rgiulietti at openjdk.org  Wed Oct  5 13:50:23 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 13:50:23 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <c7hWjn16Z60UOPEWegOIMbAk8RkWYbNvV_gEoPLbwZU=.8bf3e6e6-5fbd-4d3d-9662-b5e099ff6a89@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
 <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>
 <1UQyX79zIVU7mGxkOTSULe7S7DZNDUjOy6NPnSP8V1c=.ddb4d2f9-f784-4fe2-9eb1-bb29349ecb55@github.com>
 <c7hWjn16Z60UOPEWegOIMbAk8RkWYbNvV_gEoPLbwZU=.8bf3e6e6-5fbd-4d3d-9662-b5e099ff6a89@github.com>
Message-ID: <-dZ60_xB0xnIsH6YI7kFMQgtyaeLyYn60Ik0aK4ctzE=.66561a3c-2f68-40a2-a256-3f30b66ff444@github.com>

On Wed, 5 Oct 2022 12:07:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> What is the problem with Awt2d? Other conflicts?
>
> I am not completely sure all `misleading-indentation` warnings are fixed in Awt2d, this would require some more testing. I'd defer that to #10453.

Awt2dLibraries.gmk in https://github.com/openjdk/jdk/pull/10453 seems more about clang if I'm not mistaken, while this change is about gcc.
The JDK successfully builds on several platforms with this change.

What else could go wrong? I'm asking because I'm not a build engineering expert at all.

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

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


From shade at openjdk.org  Wed Oct  5 13:54:10 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 13:54:10 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <-dZ60_xB0xnIsH6YI7kFMQgtyaeLyYn60Ik0aK4ctzE=.66561a3c-2f68-40a2-a256-3f30b66ff444@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
 <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>
 <1UQyX79zIVU7mGxkOTSULe7S7DZNDUjOy6NPnSP8V1c=.ddb4d2f9-f784-4fe2-9eb1-bb29349ecb55@github.com>
 <c7hWjn16Z60UOPEWegOIMbAk8RkWYbNvV_gEoPLbwZU=.8bf3e6e6-5fbd-4d3d-9662-b5e099ff6a89@github.com>
 <-dZ60_xB0xnIsH6YI7kFMQgtyaeLyYn60Ik0aK4ctzE=.66561a3c-2f68-40a2-a256-3f30b66ff444@github.com>
Message-ID: <0vEUzzox7stDb-K4l3Tlj3p5dyUDCKYcm3LcJC9DAd0=.1d0d5f0b-ec4e-40d0-9e6f-7ffae1e9d875@github.com>

On Wed, 5 Oct 2022 13:46:23 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> I am not completely sure all `misleading-indentation` warnings are fixed in Awt2d, this would require some more testing. I'd defer that to #10453.
>
> Awt2dLibraries.gmk in https://github.com/openjdk/jdk/pull/10453 seems more about clang if I'm not mistaken, while this change is about gcc.
> The JDK successfully builds on several platforms with this change.
> 
> What else could go wrong? I'm asking because I'm not a build engineering expert at all.

This could fail the build on some toolchains. Cleanliness and least surprise: this PR changes the particular files, and so it should remove the warnings for those specific files.

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

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


From rgiulietti at openjdk.org  Wed Oct  5 14:06:21 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 14:06:21 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in core JDK
 libraries [v3]
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <61eXki6R0QjODAaLPVm1PrjNlPD5LCjbvzeG9Iz12o8=.8f33b181-7ced-4ed8-bdd2-037e43fa56ec@github.com>

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

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

  8294456: Fix misleading-indentation warnings in JDK

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10487/files
  - new: https://git.openjdk.org/jdk/pull/10487/files/4581b7dd..7b455e5a

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Wed Oct  5 14:06:24 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 14:06:24 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in core JDK
 libraries [v2]
In-Reply-To: <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
Message-ID: <jdqZWOfEPFZIDV15uRNw-D7L7OUcQLJG2D1V26WOGZw=.a9bd1fcc-ab7e-445f-9878-998a7150fd13@github.com>

On Wed, 5 Oct 2022 10:02:49 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.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8294456: Fix misleading-indentation warnings in JDK
>    
>    Merge branch 'master' into JDK-8294456
>  - 8294456: Fix misleading-indentation warnings in JDK

Restored `misleading-indentation` warning in `Awt2dLibraries.gmk`

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

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


From aivanov at openjdk.org  Wed Oct  5 14:17:13 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Oct 2022 14:17:13 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: <VFoXow0glQ610il1bDU1a3KC6dP3S7cxr63T2tRJRZE=.46f798ba-af7c-4aea-9ca8-ce706658b5cc@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

I agree with everyone who said the PR should be broken to smaller pieces so that it touches code / tests in one or two packages, modules. It would be easier to review, you would need to get an approval from reviewers in a one or two specific areas. At this time, this PR touches files in 11 areas according the number of labels which correspond to a specific mailing list where discussions for the area are held.

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

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


From duke at openjdk.org  Wed Oct  5 14:50:15 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 5 Oct 2022 14:50:15 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v23]
In-Reply-To: <HtNU4ZI24fXLSGh0IwQQCyxXcxZuPoxm6dYcHXPhU3s=.893025db-bf5f-4af3-a2ec-2c5778050cb5@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>
 <HtNU4ZI24fXLSGh0IwQQCyxXcxZuPoxm6dYcHXPhU3s=.893025db-bf5f-4af3-a2ec-2c5778050cb5@github.com>
Message-ID: <Xi2aZgw-3sKjmMEjWkBRLIRsSpCw-Joo22YlG_j0CLA=.f5e670e6-bb38-4d83-a288-dcaf564d2b94@github.com>

On Fri, 30 Sep 2022 17:42:43 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.
>
>> > 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.

@aivanov-jdk  A proposition to update the specification of `StyleSheet.stringToColor`.

  /**
   * Converts a color string such as "RED" or "#NNN", "#NNNN", "#NNNNNN",
   * "#NNNNNNNN" N digits in radix-16 or "rgb(r, g, b)" or
   * "rgba(r, g, b, a)" to a Color.
   * <p>
   * Note : This will only convert string colors using names or 3, 4, 6, 8
   *        digit hexadecimal notations as they are listed and described in
   *        the CSS Color Module Level 4;
   *        otherwise, it will return null.
   *        This method is case-insensitive.
   * <p>
   * The following code defines instances of the same color :
   * {@snippet lang="java" :
   *   import java.awt.Color;
   *   import javax.swing.text.html.StyleSheet;
   *   StyleSheet styleSheet = new StyleSheet();
   *   // An opaque lightseagreen
   *   Color color1 = styleSheet.stringToColor("Lightseagreen");
   *   Color color2 = styleSheet.stringToColor("LIGHTSEAGREEN");
   *   Color color3 = styleSheet.stringToColor("rgb(32 178 170)");
   *   Color color4 = styleSheet.stringToColor("#20b2aa");
   *   // A slightly-transparent lightseagreen
   *   Color color5 = styleSheet.stringToColor("rgba(32 178 170 0.8)");
   *   Color color6 = styleSheet.stringToColor("#20b2aacc");
   * }
   * <p>
   * @param string color, string such as "RED" or "#NNNNNNNN" or
   * "rgb(r, g, b)" or "rgba(r, g, b, a)"
   * @return the color
   */

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

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


From shade at openjdk.org  Wed Oct  5 15:05:22 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 15:05:22 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in core JDK
 libraries [v3]
In-Reply-To: <61eXki6R0QjODAaLPVm1PrjNlPD5LCjbvzeG9Iz12o8=.8f33b181-7ced-4ed8-bdd2-037e43fa56ec@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <61eXki6R0QjODAaLPVm1PrjNlPD5LCjbvzeG9Iz12o8=.8f33b181-7ced-4ed8-bdd2-037e43fa56ec@github.com>
Message-ID: <kASsj6bokAL0NZ2yQiugQbCEYx9nS6Y8DhMkTqyIZdo=.f4e6c2c7-0173-4ac0-a0fb-de0628e79255@github.com>

On Wed, 5 Oct 2022 14:06:21 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.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8294456: Fix misleading-indentation warnings in JDK

Marked as reviewed by shade (Reviewer).

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

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


From aivanov at openjdk.org  Wed Oct  5 16:32:22 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Oct 2022 16:32:22 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <hnlpIVPe1vxw8KeulUxLSmEYiGgMQIIkTKv00KF-oFk=.eaa9e60b-f77e-4c4d-a6b1-cfb59f8642fe@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <0SIw07r--T4zF6fgkVRw0UY9qv0duIELblGCuxqcuZc=.f0d01224-6d2b-4e25-882b-cf0f0205004f@github.com>
 <UemCGrDaiy4osk-rRrilEZG-HpCu9bN9Q_sHztLpdyU=.49fe52f2-1306-45f2-a455-f8c627d1ae31@github.com>
 <VdrfTNGNyvcyE7teukQrl1ATUAKGEN4Nrzsinr5ipQI=.9013c0e0-d93f-455e-bfb7-e088fd95bd42@github.com>
 <hnlpIVPe1vxw8KeulUxLSmEYiGgMQIIkTKv00KF-oFk=.eaa9e60b-f77e-4c4d-a6b1-cfb59f8642fe@github.com>
Message-ID: <zFlPWHcSwIfXlnTeEXtv3YohImvHSGjdgQXvaqAcsGY=.6d908441-d787-48b7-86ef-2d200d92c049@github.com>

On Tue, 4 Oct 2022 18:48:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> > Out of curiosity, can this test use `BufferedImage` to render `JInternalFrame` into?
>>> 
>>> @aivanov-jdk Thank you for reviewing. I wanted to clarify whether you meant saving just the JInternalFrame into BufferedImage?
>> 
>> Yes, just `JInternalFrame`. Yet I was talking about rendering rather than capturing from the screen.
>
>> @aivanov-jdk Regarding saving the screen capture -
>> 
>> When JIF bounds are used, a partial image of JInternalFrame (JIF) is saved. Hence I'm using the entire outer JFrame bounds to capture the screenshot.
> 
> Could be? It shouldn't. Anyway, I have no problem with capturing the entire `JFrame`.
> 
>> 
>> For the screenCapture I wanted to use **BufferedImage's getScaledInstance()** to create the scaled version (code snippet below), but experiencing issues while saving it. Currently I'm scaling the original image and re-drawing it using graphics object.
>  
> This is definitely not what we want. It just up-scales or down-scales the current image stored in `BufferedImage`.
> 
> When you run in a HiDPI environment or with `uiScale` set explicitly to a value greater than 1.0, the number of pixels is higher. `Robot.createScreenCapture` up-scales the passed in rectangle, captures all the pixels and then down-scales the captured screenshot to the user's space coordinates.
> 
> At the same time, [`createMultiResolutionScreenCapture`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Robot.html#createScreenCapture(java.awt.Rectangle)) returns a `MultiResolutionImage` which contains two variants: (1) the base image with the user specified size, down-scaled from the screen; (2) native resolution image with the device size pixels. The second variant will preserve all the pixels seen on the screen.

> @aivanov-jdk The extra pixel seems to be added due to JInternalFrame titlebar and not from the paintBorder() code changes.

Good then. It's not from the border.

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

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


From darcy at openjdk.org  Wed Oct  5 16:39:32 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 5 Oct 2022 16:39:32 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v9]
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: <T3sWlUnikg_EsuKqJ5PFiXj8IDAbk0fYG-WR3iLLvTw=.19912185-605f-4201-8022-0ffb7e00342d@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 12 additional commits since the last revision:

 - Merge branch 'master' into JDK-8294618
 - Update accessibility URLs.
 - Merge branch 'master' into JDK-8294618
 - Update make directory.
 - Update doc directory files.
 - Update hg URLs to git.
 - Merge branch 'master' into JDK-8294618
 - http -> https
 - Undo manpage update.
 - Update copyright.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/8aa24fec...eba2bd4b

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/4055f1a6..eba2bd4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=07-08

  Stats: 1452 lines in 87 files changed: 912 ins; 312 del; 228 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  Wed Oct  5 16:52:27 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 5 Oct 2022 16:52:27 GMT
Subject: Integrated: 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: <vtc6z3XjCCr9yLV3usCQemL0opkJB2S_3H8IZGWwD_A=.7c03befe-b74b-48e0-ad2d-3594d6ebc1b5@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.

This pull request has now been integrated.

Changeset: 536c9a51
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/536c9a512ea90d97a1ae5310453410d55db98bdd
Stats:     128 lines in 45 files changed: 0 ins; 0 del; 128 mod

8294618: Update openjdk.java.net => openjdk.org

Reviewed-by: mikael, iris, joehw, prr, ihse

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

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


From aivanov at openjdk.org  Wed Oct  5 17:06:25 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Oct 2022 17:06:25 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v7]
In-Reply-To: <5LBhU0Tkp2GngUkCt1tAAEe1f8qxzP2I4CVMAQhW8zw=.9c520957-5aa6-4431-83d5-0f76119e39b9@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <5LBhU0Tkp2GngUkCt1tAAEe1f8qxzP2I4CVMAQhW8zw=.9c520957-5aa6-4431-83d5-0f76119e39b9@github.com>
Message-ID: <y3VVeYZafE0b28PGQxAWfqIgMs7fmpgT7Qjr-U56rOc=.24e0561f-908c-40a4-83ea-91ca03e5ddff@github.com>

On Tue, 4 Oct 2022 22:06:07 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:
> 
>   review changes

Other that a couple of nits, it looks good to me.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 254:

> 252:          *
> 253:          * @param d number to be rounded
> 254:          * @return a {@code int} which is the rounded value of provided number

Suggestion:

         * Rounds a double to the nearest integer. It rounds 0.5 down,
         * for example 1.5 is rounded to 1.0.
         *
         * @param d number to be rounded
         * @return the rounded value

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 257:

> 255:          */
> 256:         private static int roundHalfDown(double d)
> 257:         {

Suggestion:

        private static int roundHalfDown(double d) {

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 42:

> 40: import javax.swing.SwingUtilities;
> 41: import javax.swing.UIManager;
> 42: import javax.imageio.ImageIO;

`ImageIO` shouldn't have moved.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 81:

> 79:     private static final int BORDER_THICKNESS = 5;
> 80: 
> 81:     private static StringBuffer errorLog = new StringBuffer();

Suggestion:

    private static final StringBuffer errorLog = new StringBuffer();

IDE issues a warning that `errorLog` can be final and it should.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 89:

> 87: 
> 88:     private static Point iFrameLoc;
> 89:     private static int iFrameMaxX;

I think `jFrameBounds` logically belongs in this block.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 105:

> 103:             robot = new Robot();
> 104:             robot.setAutoDelay(200);
> 105:             uiScale =System.getProperty("sun.java2d.uiScale");

Suggestion:

            uiScale = System.getProperty("sun.java2d.uiScale");

A space is missing.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 178:

> 176:                 || borderDirection.equals("LEFT");
> 177:         boolean isHorizontal =  borderDirection.equals("TOP")
> 178:                 || borderDirection.equals("BOTTOM");

Suggestion:

        boolean isVertical = borderDirection.equals("RIGHT")
                || borderDirection.equals("LEFT");
        boolean isHorizontal = borderDirection.equals("TOP")
                || borderDirection.equals("BOTTOM");

No need for additional space after `=` sign.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 222:

> 220:             createMRIScreenCapture(cornerLocation + "_uiScale"
> 221:                     + uiScale + ".png");
> 222:             errorLog.append("At uiScale: "+ uiScale + ", Red background color"

Suggestion:

            errorLog.append("At uiScale: " + uiScale + ", Red background color"

A space before `+`.

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 255:

> 253:         try {
> 254:             ImageIO.write(image,
> 255:                     "png", new File(filename));

Wrapping is redundant now.

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

Marked as reviewed by aivanov (Reviewer).

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


From aivanov at openjdk.org  Wed Oct  5 17:06:28 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Oct 2022 17:06:28 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v5]
In-Reply-To: <ZqCPxOHwep_nHU8fm_Lo6NaYcOxxttxMGYowaH8E4Ww=.0e2242a2-427c-44f2-9e84-3fa348239d2b@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <TfVEzqvCHRXUBpWMM_5nO5ej7yg_OwjOEL1wS9HgiXM=.0f9835af-b518-4d26-8d89-7d6c09a72d45@github.com>
 <ZqCPxOHwep_nHU8fm_Lo6NaYcOxxttxMGYowaH8E4Ww=.0e2242a2-427c-44f2-9e84-3fa348239d2b@github.com>
Message-ID: <caXqCgSdDAIUdPRdFllhJjO9u-daJvKBYfZcOR2DeVs=.0bb3f292-4f14-4139-8f4a-31e7430772f7@github.com>

On Tue, 4 Oct 2022 19:39:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review changes, saving a scaled version of image
>
> test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 229:
> 
>> 227:         jFrame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
>> 228: 
>> 229:         JLabel scale = new JLabel("UI Scale: "+ uiScale);
> 
> Suggestion:
> 
>         JLabel scale = new JLabel("UI Scale: " + uiScale);

The space is still missing before `+`. Yes, there's space inside the string literal but it's inside, binary operators should still have spaces on either side.

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

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


From honkar at openjdk.org  Wed Oct  5 21:00:11 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 5 Oct 2022 21:00:11 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v8]
In-Reply-To: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
Message-ID: <PW-1fK5yC3BQzpbFre9ORzhHWTFvwamRG8XZ3hWpfAY=.2a832771-dee6-418a-b6e7-0cf860aa3fbc@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:

  test updated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10274/files
  - new: https://git.openjdk.org/jdk/pull/10274/files/827a3484..2e3b7af1

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

  Stats: 49 lines in 2 files changed: 16 ins; 9 del; 24 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 Oct  5 21:15:18 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 5 Oct 2022 21:15:18 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <zFlPWHcSwIfXlnTeEXtv3YohImvHSGjdgQXvaqAcsGY=.6d908441-d787-48b7-86ef-2d200d92c049@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <0SIw07r--T4zF6fgkVRw0UY9qv0duIELblGCuxqcuZc=.f0d01224-6d2b-4e25-882b-cf0f0205004f@github.com>
 <UemCGrDaiy4osk-rRrilEZG-HpCu9bN9Q_sHztLpdyU=.49fe52f2-1306-45f2-a455-f8c627d1ae31@github.com>
 <VdrfTNGNyvcyE7teukQrl1ATUAKGEN4Nrzsinr5ipQI=.9013c0e0-d93f-455e-bfb7-e088fd95bd42@github.com>
 <hnlpIVPe1vxw8KeulUxLSmEYiGgMQIIkTKv00KF-oFk=.eaa9e60b-f77e-4c4d-a6b1-cfb59f8642fe@github.com>
 <zFlPWHcSwIfXlnTeEXtv3YohImvHSGjdgQXvaqAcsGY=.6d908441-d787-48b7-86ef-2d200d92c049@github.com>
Message-ID: <HeHvI976nEJBZnV7eGZuJh999qxKW3onJw5N00MRllc=.363bae24-6aef-450b-89b7-62c42d537d52@github.com>

On Wed, 5 Oct 2022 16:28:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> @aivanov-jdk Regarding saving the screen capture -
>>> 
>>> When JIF bounds are used, a partial image of JInternalFrame (JIF) is saved. Hence I'm using the entire outer JFrame bounds to capture the screenshot.
>> 
>> Could be? It shouldn't. Anyway, I have no problem with capturing the entire `JFrame`.
>> 
>>> 
>>> For the screenCapture I wanted to use **BufferedImage's getScaledInstance()** to create the scaled version (code snippet below), but experiencing issues while saving it. Currently I'm scaling the original image and re-drawing it using graphics object.
>>  
>> This is definitely not what we want. It just up-scales or down-scales the current image stored in `BufferedImage`.
>> 
>> When you run in a HiDPI environment or with `uiScale` set explicitly to a value greater than 1.0, the number of pixels is higher. `Robot.createScreenCapture` up-scales the passed in rectangle, captures all the pixels and then down-scales the captured screenshot to the user's space coordinates.
>> 
>> At the same time, [`createMultiResolutionScreenCapture`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Robot.html#createScreenCapture(java.awt.Rectangle)) returns a `MultiResolutionImage` which contains two variants: (1) the base image with the user specified size, down-scaled from the screen; (2) native resolution image with the device size pixels. The second variant will preserve all the pixels seen on the screen.
>
>> @aivanov-jdk The extra pixel seems to be added due to JInternalFrame titlebar and not from the paintBorder() code changes.
> 
> Good then. It's not from the border.

@aivanov-jdk In addition to review changes, the following changes were made to the test case:

- To make the test more robust, corner check has been changed from corner pixel check to checking multiple pixels along the corner diagonals.
- Added break statements to the loop to avoid appending multiple error messages.
- Saving a single screenshot per uiScale after all the checks are done.

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

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


From aivanov at openjdk.org  Wed Oct  5 21:50:14 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Oct 2022 21:50:14 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v8]
In-Reply-To: <PW-1fK5yC3BQzpbFre9ORzhHWTFvwamRG8XZ3hWpfAY=.2a832771-dee6-418a-b6e7-0cf860aa3fbc@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <PW-1fK5yC3BQzpbFre9ORzhHWTFvwamRG8XZ3hWpfAY=.2a832771-dee6-418a-b6e7-0cf860aa3fbc@github.com>
Message-ID: <ndnaR6fkklnxoK-IVqmxwnfxuv6KLeq263i0hDapQ6Q=.c99b6a80-f543-4672-9210-6571562d6436@github.com>

On Wed, 5 Oct 2022 21:00:11 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:
> 
>   test updated

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 226:

> 224:         robot.mouseMove(x, y);
> 225: 
> 226:         for (int i = 0; i < 5; i++) {

Suggestion:

        for (int i = 0; i < BORDER_THICKNESS; i++) {

Is it the intention?

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

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


From dnguyen at openjdk.org  Wed Oct  5 23:29:22 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 5 Oct 2022 23:29:22 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0
In-Reply-To: <xSKq7POrfrJ4KYYBA8crdY5rJCjciMK4NEK-LZTcjDk=.8161df0a-2d8c-4784-948b-b7632af2d7e0@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
 <xSKq7POrfrJ4KYYBA8crdY5rJCjciMK4NEK-LZTcjDk=.8161df0a-2d8c-4784-948b-b7632af2d7e0@github.com>
Message-ID: <2JMfR5LPnaps6mypICTmVJ06Wvz-aM8TZCUCGFtPfRI=.a2f95c1a-08e4-484d-b9bd-d2e2de8b7a93@github.com>

On Mon, 26 Sep 2022 11:03:40 GMT, Tejesh R <tr at openjdk.org> wrote:

> 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.....?

I second this. The test can sit inside the Multiscreen folder without the need for a subfolder to match the way new tests are added.


> This test fails for me everytime at Robot.mouseMove test with/without fix at Screen #0(built-in display). I have built-in display as main display and external monitor. It is not moving forward to verify PixelColor with/without fix.

I plugged in an external monitor aand had my built-in display as the main display and can confirm that the test still fails every time I ran it (tested 5 times each) with and without the fix. I'm on macOS 12.3.1.

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

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


From jdv at openjdk.org  Thu Oct  6 05:26:52 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 6 Oct 2022 05:26:52 GMT
Subject: Integrated: 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: <TX5heX_C-0JtCM9PajAk--MHN9hIz-gkMcN-CIllvkw=.4292fb9e-a9a4-48b8-b49c-9d33969d813b@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.

This pull request has now been integrated.

Changeset: 6029120a
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6029120a5f53061f386d5dc72c76adf03ab28840
Stats:     93 lines in 2 files changed: 89 ins; 1 del; 3 mod

8278086: [REDO] ImageIO.write() method will throw IndexOutOfBoundsException

Co-authored-by: Masanori Yano <myano at openjdk.org>
Reviewed-by: tr, prr

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

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


From jdv at openjdk.org  Thu Oct  6 05:43:40 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 6 Oct 2022 05:43:40 GMT
Subject: RFR: 8270915: GIFImageReader disregards ignoreMetadata flag which
 causes memory exhaustion
In-Reply-To: <RvbV88C4onapywWXG0S3wcYsVN9eXzJDxskdVgz-I-g=.16917659-2fbd-48af-a89a-be37e5ace1fe@github.com>
References: <MNVf1oMbzOO8Zpyk551X7bNJQeGsUbHiyC8kBKsuixw=.fd9b04d2-5cce-4dd7-9b49-15042925743c@github.com>
 <RvbV88C4onapywWXG0S3wcYsVN9eXzJDxskdVgz-I-g=.16917659-2fbd-48af-a89a-be37e5ace1fe@github.com>
Message-ID: <6RXQGQBrVG3wZWwwXcAyLYPvU5lvVnvE4k3YKk3lC5Y=.75295909-c280-4b0b-90e8-27117ae537b2@github.com>

On Mon, 3 Oct 2022 22:05:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I have updated readMedata() to also use ReaderUtil.staggeredReadByteStream() where we are allocating upfront memory based on parameters from metadata.
> 
> Probably it is possible to create a small test just for this change?

Thanks for your review Sergey.
If i need to add tests for staggered read in this PR i need to create 3 different byte streams to capture all the scenarios and these streams will not be related to this bug.
I just added staggered read approach in readMetadata() as it is now time tested and acts as a barrier for corrupt header parameters.

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

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


From jdv at openjdk.org  Thu Oct  6 05:47:40 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 6 Oct 2022 05:47:40 GMT
Subject: Integrated: 8270915: GIFImageReader disregards ignoreMetadata flag
 which causes memory exhaustion
In-Reply-To: <MNVf1oMbzOO8Zpyk551X7bNJQeGsUbHiyC8kBKsuixw=.fd9b04d2-5cce-4dd7-9b49-15042925743c@github.com>
References: <MNVf1oMbzOO8Zpyk551X7bNJQeGsUbHiyC8kBKsuixw=.fd9b04d2-5cce-4dd7-9b49-15042925743c@github.com>
Message-ID: <L2JyFaqibaHxR6AzWrmrwejR4rt022__O7LvkVzPIto=.07c9175b-1d12-48a0-9417-2b3c7e155481@github.com>

On Mon, 3 Oct 2022 13:59:25 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> In https://bugs.openjdk.org/browse/JDK-8270915 we have a valid GIF image which was generated using a third party app, but it contains large amount of Metadata(numerous Application extension blocks).
> 
> Also GIFImageReader doesn't use ignoreMetadata flag set by user while reading Metadata which causes heavy memory usage in this scenario. We need to provide support for ignoring metadata in GIFImageReader, so readMetadata() is updated to use the "ignoreMetadata" flag and ignore all blocks except "Image Descriptor" and "Graphics Control Extension".
> 
> I have updated readMedata() to also use ReaderUtil.staggeredReadByteStream() where we are allocating upfront memory based on parameters from metadata. Also this PR has small refactoring of import statements.
> 
> To replicate the bug we need byte stream with large amount of valid metadata, so i am not able to add regression test case. I have run all javax/imageio jtreg tests and there are no issues.

This pull request has now been integrated.

Changeset: 8c15f77a
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c15f77abac0beb7f39a90fdfc5efb245b09ca32
Stats:     88 lines in 1 file changed: 39 ins; 10 del; 39 mod

8270915: GIFImageReader disregards ignoreMetadata flag which causes memory exhaustion

Reviewed-by: prr

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

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


From rgiulietti at openjdk.org  Thu Oct  6 09:35:09 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 6 Oct 2022 09:35:09 GMT
Subject: Integrated: 8294456: Fix misleading-indentation warnings in core JDK
 libraries
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <p6anLs2K5nMnmfJGCi71-RbijOfCBjjLd-pwBJQgucg=.0ed1c704-1575-4ff0-9c9e-754ec656ca72@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 pull request has now been integrated.

Changeset: 2ceebf68
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ceebf681ffd6f9bf6967fd81b30d721bc010b94
Stats:     8 lines in 3 files changed: 1 ins; 1 del; 6 mod

8294456: Fix misleading-indentation warnings in core JDK libraries

Reviewed-by: shade, rriggs, iris, darcy

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

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


From honkar at openjdk.org  Thu Oct  6 14:15:28 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 6 Oct 2022 14:15:28 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v8]
In-Reply-To: <ndnaR6fkklnxoK-IVqmxwnfxuv6KLeq263i0hDapQ6Q=.c99b6a80-f543-4672-9210-6571562d6436@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <PW-1fK5yC3BQzpbFre9ORzhHWTFvwamRG8XZ3hWpfAY=.2a832771-dee6-418a-b6e7-0cf860aa3fbc@github.com>
 <ndnaR6fkklnxoK-IVqmxwnfxuv6KLeq263i0hDapQ6Q=.c99b6a80-f543-4672-9210-6571562d6436@github.com>
Message-ID: <hndqnmKBLmxx2v0Quu-Gw9_VK_LHF-lC_GlAoWki5JU=.675d8b92-3f65-4f6d-8ce5-68cb47eb828d@github.com>

On Wed, 5 Oct 2022 21:44:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test updated
>
> test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 226:
> 
>> 224:         robot.mouseMove(x, y);
>> 225: 
>> 226:         for (int i = 0; i < 5; i++) {
> 
> Suggestion:
> 
>         for (int i = 0; i < BORDER_THICKNESS; i++) {
> 
> Is it the intention?

Yes, that is correct.

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

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


From aivanov at openjdk.org  Thu Oct  6 14:15:29 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 6 Oct 2022 14:15:29 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v8]
In-Reply-To: <hndqnmKBLmxx2v0Quu-Gw9_VK_LHF-lC_GlAoWki5JU=.675d8b92-3f65-4f6d-8ce5-68cb47eb828d@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <PW-1fK5yC3BQzpbFre9ORzhHWTFvwamRG8XZ3hWpfAY=.2a832771-dee6-418a-b6e7-0cf860aa3fbc@github.com>
 <ndnaR6fkklnxoK-IVqmxwnfxuv6KLeq263i0hDapQ6Q=.c99b6a80-f543-4672-9210-6571562d6436@github.com>
 <hndqnmKBLmxx2v0Quu-Gw9_VK_LHF-lC_GlAoWki5JU=.675d8b92-3f65-4f6d-8ce5-68cb47eb828d@github.com>
Message-ID: <EDG_NGDx-d1JUnEAkEQtV-xDWLpBeuUinYw2fqMP2ok=.76ed0e6f-6028-4c01-8261-e269fcee13b3@github.com>

On Wed, 5 Oct 2022 21:49:10 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 226:
>> 
>>> 224:         robot.mouseMove(x, y);
>>> 225: 
>>> 226:         for (int i = 0; i < 5; i++) {
>> 
>> Suggestion:
>> 
>>         for (int i = 0; i < BORDER_THICKNESS; i++) {
>> 
>> Is it the intention?
>
> Yes, that is correct.

Will you update it to use `BORDER_THICKNESS`?

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

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


From prappo at openjdk.org  Thu Oct  6 14:35:20 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Oct 2022 14:35:20 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <PlQjfMvDRNRyYFL9xVnKoirPgtOk_QhEMl_QbNRnzrU=.0b472944-6d3a-48f2-bc79-ec592df83c79@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
 <PlQjfMvDRNRyYFL9xVnKoirPgtOk_QhEMl_QbNRnzrU=.0b472944-6d3a-48f2-bc79-ec592df83c79@github.com>
Message-ID: <IDbm-8O6WIU3UVM8RfCgwumVv07BW1zqbpVkwYNhjps=.31e7c071-18d8-4278-a0cd-21a00d26e9ac@github.com>

On Fri, 30 Sep 2022 19:15:17 GMT, Phil Race <prr at openjdk.org> wrote:

> 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.

Since this change does not affect HTML pages for java.desktop, I take it as "approved".

> 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 ..

Let me try to clarify exception documentation inheritance for you.

A method **never** inherits exception documentation unless that method explicitly requests to do so. A method that wants to inherit documentation for a particular exception has two options: use a doc comment or use a method declaration.

Let's see how those options work. Suppose, a method wants to inherit documentation for an exception `X`. To inherit documentation through a doc comment, the method adds the following exception tag (`@throws` or `@exception`) to that method's doc comment:


?    @throws X {@inheritDoc}


To inherit documentation through a method declaration, the method lists `X` in that method's `throws` clause:


?    throws ..., X, ...


If a method chooses neither of those options, then that method won't inherit exception documentation for `X` (assuming that exception documentation for `X` exists in the supermethod).

Here's an informal, simplified, but conceptually correct version of the algorithm that javadoc uses to document exceptions thrown by a method:

  Step 1. For each exception tag, do the following. If an exception tag does not have `{@inheritDoc}` in its description, add an entry for the exception that this tag describes to the "Throws:" section. Otherwise, look for corresponding documentation in the supermethod, to which apply this step (Step 1) recursively.

  Step 2. For each exception from the `throws` clause, do the following. If an exception has not been documented on the previous step, document it using corresponding documentation in the supermethod, to which apply this algorithm (both steps in order) recursively.

A few notes on the algorithm: 

* Exception tags are examined prior to the `throws` clause. This allows a method to **override** documentation that could be otherwise inherited from the supermethod: if the method provides exception tags for a particular exception, then documentation for that exception will be found on Step 1 and, hence, won't be looked for in the supermethod on Step 2.


  ?    @throws X <overriding-description>


* If a method wants to **add** documentation for a particular exception, rather than **override** it, the method should both add documentation and inherit it using tags:


  ?    @throws X <additional-description>
  ?    @throws X {@inheritDoc}


The above model might explain a common **misconception** according to which methods inherit documentation for checked exceptions and do not inherit it for unchecked exceptions. In reality, javadoc treats all exceptions equally. It's just that if a method throws a checked exception, that exception (or its superclass) must be listed in that method's `throws` clause. Now, if such an exception is not documented by that method but documented by the supermethod, that exception documentation is inherited. That gives a false impression that the documentation is inherited because the exception is checked. In fact, the documentation would still be inherited if that exception, listed in the `throws` clause, were unchecked.

The above is how it has been working (barring bugs) since documentation comment inheritance appeared in its current form. Implicit inheritance (filling in missing text) appeared in JDK 1.3, explicit inheritance (`{@inheritDoc}`) appeared in JDK 1.4, auto-inheriting documentation for subclasses of exceptions whose documentation is inherited (JDK-4947455) appeared in JDK 5.

Back to this PR change in `java.desktop`. `ImageInputStreamImpl.readBoolean` inherits `EOFException` documentation not because that method doesn't have a doc comment of its own and, thus, inherits "the exact and entire" doc comment from its supermethod (`ImageInputStream.readBoolean`). It's because that when the algorithm reaches Step 2 and tries to find documentation for `IOException` (because it is listed in the `throws` clause), JDK-4947455 kicks in. And JDK-4947455 says that if a method inherits documentation for a particular exception, it should also inherit documentation for that exception's subclasses. So, javadoc goes ahead and inherits documentation for `IOException`, because it's a direct match, and for `EOFException`, because it's a subclass of `IOException`. 

To inherit `EOFException` documentation after JDK-4947455 has been reverted and, thus, the subclassing :magic_wand: has gone, `ImageInputStreamImpl.readBoolean` has two options: 

* list `EOFException` in the `throws` clause
* `@throws EOFException {@inheritDoc}`

Thanks to the current implementation of documentation inheritance, any of the above can be done **before** JDK-4947455 is reverted. For now doing so just adds a redundant but harmless inheritance route, which will become the only route in time. For this PR to be less disruptive and qualify as "noreg-doc" I chose to add an exception tag rather than amend the `throws` clause.

I hope that my reply clarifies the matter. Documentation inheritance can be surprising. We're trying hard to capture its model and simplify it where possible. We are constantly improving the Documentation Comment Specification for the Standard Doclet[^1] (spec), but since documentation inheritance is a popular topic which is often misunderstood, along with improving the spec in this area, we might also provide a less formal document dedicated to documentation inheritance.

[^1]: https://docs.oracle.com/en/java/javase/19/docs/specs/javadoc/doc-comment-spec.html

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

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


From jjg at openjdk.org  Thu Oct  6 15:05:56 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 6 Oct 2022 15:05:56 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: <lySOn6EkcX5ybd_-t8TFRBQfB51zAnoq5Bz79HZQmws=.f4be94e4-88d9-43c2-b052-0034e957738e@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

I'm marking the change as approved, in terms of the cumulative efforts of those who have commented.

I've browsed all the changes and read the jshell files in more detail, since no once else has so far.

I understand the reason for the change, and generally approve of undoing the magic of the old feature in JDK-8287796. That being said, the proposed state is "not great", and feels like the interim stage of "one step back, to take two steps forward", even though I do not have a good sense at this time of what that future direction might be.

So, looks OK for now, but I hope we revisit this issue again sometime.  Thanks, in general, for taking on this topic.

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

Marked as reviewed by jjg (Reviewer).

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


From aivanov at openjdk.org  Thu Oct  6 15:08:26 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 6 Oct 2022 15:08:26 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0
In-Reply-To: <2JMfR5LPnaps6mypICTmVJ06Wvz-aM8TZCUCGFtPfRI=.a2f95c1a-08e4-484d-b9bd-d2e2de8b7a93@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
 <xSKq7POrfrJ4KYYBA8crdY5rJCjciMK4NEK-LZTcjDk=.8161df0a-2d8c-4784-948b-b7632af2d7e0@github.com>
 <2JMfR5LPnaps6mypICTmVJ06Wvz-aM8TZCUCGFtPfRI=.a2f95c1a-08e4-484d-b9bd-d2e2de8b7a93@github.com>
Message-ID: <BR-jEkqs-cfBcLbYOIochka2ttiiXyyeVEbWMXq-ZPY=.d124a284-b194-4cf5-b4f5-8faf6c7a5856@github.com>

On Wed, 5 Oct 2022 23:22:28 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> > 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.....?
> 
> I second this. The test can sit inside the Multiscreen folder without the need for a subfolder to match the way new tests are added.

I prefer leaving the test at its original location. It's not a new test, it has a history in CI. Although, if everyone else thinks the test should be moved up, it's okay with me.

Previously, each test had its own folder. Now, we tend to use flatter structure.

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

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


From honkar at openjdk.org  Thu Oct  6 15:47:21 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 6 Oct 2022 15:47:21 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v8]
In-Reply-To: <EDG_NGDx-d1JUnEAkEQtV-xDWLpBeuUinYw2fqMP2ok=.76ed0e6f-6028-4c01-8261-e269fcee13b3@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <PW-1fK5yC3BQzpbFre9ORzhHWTFvwamRG8XZ3hWpfAY=.2a832771-dee6-418a-b6e7-0cf860aa3fbc@github.com>
 <ndnaR6fkklnxoK-IVqmxwnfxuv6KLeq263i0hDapQ6Q=.c99b6a80-f543-4672-9210-6571562d6436@github.com>
 <hndqnmKBLmxx2v0Quu-Gw9_VK_LHF-lC_GlAoWki5JU=.675d8b92-3f65-4f6d-8ce5-68cb47eb828d@github.com>
 <EDG_NGDx-d1JUnEAkEQtV-xDWLpBeuUinYw2fqMP2ok=.76ed0e6f-6028-4c01-8261-e269fcee13b3@github.com>
Message-ID: <jA5NMzQf6_P1qdl29H75vLNC1sekdc6ev3KJSPX_vE0=.92227269-d703-41e7-9bac-49ba7f953585@github.com>

On Thu, 6 Oct 2022 14:13:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Yes, that is correct.
>
> Will you update it to use `BORDER_THICKNESS`?

@aivanov-jdk I was waiting on testing results to make the final update along with the above change.

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

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


From duke at openjdk.org  Thu Oct  6 16:06:56 2022
From: duke at openjdk.org (Martin Desruisseaux)
Date: Thu, 6 Oct 2022 16:06:56 GMT
Subject: Integrated: 8290973: In AffineTransform,
 equals(Object) is inconsistent with hashCode()
In-Reply-To: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
References: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
Message-ID: <EVEJNKOpk3m3rXJTnH52BQMu3Vl-D9LBj1ic2scUknY=.eecdf7bc-c0ef-46bd-b55f-dede17e380df@github.com>

On Fri, 10 Jun 2022 09:39:48 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.

This pull request has now been integrated.

Changeset: 5c030ccc
Author:    Martin Desruisseaux <martin.desruisseaux at geomatys.com>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c030cccae6cd7862b7ecc563fde4b7670f25c10
Stats:     108 lines in 2 files changed: 100 ins; 0 del; 8 mod

8290973: In AffineTransform, equals(Object) is inconsistent with hashCode()

Reviewed-by: prr

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

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


From dnguyen at openjdk.org  Thu Oct  6 16:11:29 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 6 Oct 2022 16:11:29 GMT
Subject: Integrated: 8293672: Update freetype md file
In-Reply-To: <b-dzUsyVw43_GNHgj0SvJX-HRTZ83wdjMpGSXBUuNjk=.9ad77320-25bc-420a-b24e-d282920a84b8@github.com>
References: <b-dzUsyVw43_GNHgj0SvJX-HRTZ83wdjMpGSXBUuNjk=.9ad77320-25bc-420a-b24e-d282920a84b8@github.com>
Message-ID: <hwWl486f7fD6G2mvHTdOPpF4noCTiHqNnN9olj8Z3HE=.a7c1aa63-df0c-4507-98c4-d7388c6c640a@github.com>

On Tue, 4 Oct 2022 17:32:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Update the freetype md file with the newly generated md file. The new format slightly differs from the previous version when separating different licenses. Added logic for combining of copyright lines and support for other licenses such as MIT.

This pull request has now been integrated.

Changeset: fef345b1
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fef345b19f74f5d706b173b1af87bcda98dc6ff2
Stats:     95 lines in 1 file changed: 54 ins; 13 del; 28 mod

8293672: Update freetype md file

Reviewed-by: prr

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

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


From dnguyen at openjdk.org  Thu Oct  6 23:27:24 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 6 Oct 2022 23:27:24 GMT
Subject: RFR: 8294807: Fix typos and clarify javadoc for
 SunToolKit.realsSync
In-Reply-To: <5GlfDtRnHLa7PIslOaYDEg8g0M2oB2-YNAatMtJbDWU=.6d381cb4-c329-4b83-a5d6-29dc96521edb@github.com>
References: <eOSJ4nSjRiskHcEirxMJmllsCP0e0wHQQ8__azU0CEw=.3a2a29b2-a349-43f9-bbd5-14b6e2ee32a2@github.com>
 <5GlfDtRnHLa7PIslOaYDEg8g0M2oB2-YNAatMtJbDWU=.6d381cb4-c329-4b83-a5d6-29dc96521edb@github.com>
Message-ID: <tAs-uXk9d4__tcb4m_yegNiDI3ZNl1AHtj35rWxaQJI=.758713aa-af1c-4efd-8f06-145fd290bd35@github.com>

On Tue, 4 Oct 2022 20:23:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I fixed the typo ?serie? ? "series" which was highlighted by a spellchecker.
>> 
>> I also simplified the description, fixed the grammar, added `{@code}` around types, added link to `requestFocus` in the example.
>
> src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1451:
> 
>> 1449:      *
>> 1450:      * <p> This method allows writing tests without explicit timeouts
>> 1451:      * or waiting for some event.  Example:
> 
> Should it be ?without _using_ ? or waiting ???  
> Does ?for an event? sound better?

In my opinion, "without using ... or waiting ..." seems better to match the tense of "waiting" to show more clearly what the "or" is intended for (assuming the OR is meant for the explicit timeouts and the waiting for an event).

Otherwise, the "or" may be confused to be between "writing ... or waiting ...".

For the "event" portion, I think either here is OK. I don't think either would cause confusion and both sound reasonable.

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

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


From serb at openjdk.org  Fri Oct  7 00:11:24 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 7 Oct 2022 00:11:24 GMT
Subject: RFR: 8293984: Unnecessary Vector usage in PropertyEditorSupport
In-Reply-To: <d_Iu8wlX0aPiKtfN2F6okrdy8lyeM8zzG8F8Dett58E=.1bfbea3a-8bd1-4b46-8f14-8a860049081f@github.com>
References: <d_Iu8wlX0aPiKtfN2F6okrdy8lyeM8zzG8F8Dett58E=.1bfbea3a-8bd1-4b46-8f14-8a860049081f@github.com>
Message-ID: <WFI9Dx4CBmmtzSAUDu3Kex-DX4WeMWWUkjHRhe59_U8=.e3c3bfe2-221c-4bd0-b8cc-9a104ecf6113@github.com>

On Mon, 19 Sep 2022 06:55:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Field PropertyEditorSupport.listeners is accessed only under `synchronized(this)`.
> It means extra synchronization by Vector is not needed.

src/java.desktop/share/classes/java/beans/PropertyEditorSupport.java line 301:

> 299:     @SuppressWarnings("unchecked")
> 300:     private <T> ArrayList<T> unsafeClone(ArrayList<T> v) {
> 301:         return (ArrayList<T>)v.clone();

I think this can be simplified by using the new list in place of "unsafeClone".

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

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


From serb at openjdk.org  Fri Oct  7 02:03:28 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 7 Oct 2022 02:03:28 GMT
Subject: RFR: 8292280: Unused field 'keyListener' in BasicRadioButtonUI
 [v2]
In-Reply-To: <Mh3c2YhtqAjZHkF466CILvxcIuAk_Ui7ESMvD7aOVU0=.4b23cb63-6f38-4bad-8dde-5fdde200e0a2@github.com>
References: <IWbq6Zr-IcRpKs5_IQvKnEL-8lEc9OVxS9GrGkA9t38=.126f3214-32d2-4fef-9505-d61f157d22fb@github.com>
 <Mh3c2YhtqAjZHkF466CILvxcIuAk_Ui7ESMvD7aOVU0=.4b23cb63-6f38-4bad-8dde-5fdde200e0a2@github.com>
Message-ID: <8f3uOVdQYVeRlnnH033dT5BzUb0pYCCzHbY_H6vrIyc=.6db1a9c7-72d2-4d0c-a045-747c0d98ca90@github.com>

On Sun, 21 Aug 2022 21:40:43 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Field `keyListener` was added under [JDK-8033699](https://bugs.openjdk.org/browse/JDK-8033699). But then all its usages were removed in [JDK-8249548](https://bugs.openjdk.org/browse/JDK-8249548)
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292280: Unused field 'keyListener' in BasicRadioButtonUI
>   
>   reverted unrelated changes

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.org  Fri Oct  7 02:09:34 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 7 Oct 2022 02:09:34 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v8]
In-Reply-To: <PW-1fK5yC3BQzpbFre9ORzhHWTFvwamRG8XZ3hWpfAY=.2a832771-dee6-418a-b6e7-0cf860aa3fbc@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <PW-1fK5yC3BQzpbFre9ORzhHWTFvwamRG8XZ3hWpfAY=.2a832771-dee6-418a-b6e7-0cf860aa3fbc@github.com>
Message-ID: <bB5v1d6Wqb8RckDvDN-36a2I1gkAcr_GuN0e_fDiYcQ=.2dbecf9e-76f7-455f-9462-8af31867d2c3@github.com>

On Wed, 5 Oct 2022 21:00:11 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:
> 
>   test updated

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 256:

> 254:          * @return the rounded value
> 255:          */
> 256:         private static int roundHalfDown(double d) {

The sun.java2d.pipe.Region#clipRound() seems have the same purpose, but it also clip the double to int.

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

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


From psadhukhan at openjdk.org  Fri Oct  7 03:05:34 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Oct 2022 03:05:34 GMT
Subject: Integrated: 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: <fUYzWheC60HTk90hdz6ogA3Bkua5pm9quxcPqYvevwM=.5683598a-76ec-469e-b8ee-671c2b3e38bf@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.

This pull request has now been integrated.

Changeset: 37bd4fbe
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/37bd4fbe3031fd7793ab947e7f58aefd9c021c44
Stats:     78 lines in 3 files changed: 78 ins; 0 del; 0 mod

6852577: Only for Nimbus LAF UIManager.get("PasswordField.echoChar") is null

Reviewed-by: tr, aivanov

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

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


From psadhukhan at openjdk.org  Fri Oct  7 03:13:28 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Oct 2022 03:13:28 GMT
Subject: Integrated: 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: <cL4cjTVodtsY1_svCaKaoQbLrosa_A5CpRWZxB0MF70=.77ce1876-15de-4406-8ca7-e8f85db35634@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.

This pull request has now been integrated.

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

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

Reviewed-by: tr, aivanov

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

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


From serb at openjdk.org  Fri Oct  7 04:32:28 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 7 Oct 2022 04:32:28 GMT
Subject: RFR: 8293986: Incorrect double-checked locking in
 com.sun.beans.introspect.ClassInfo
In-Reply-To: <xy5SGxYpSr1HEYXXTGxlr_dJz4bwQmMaHZ0-rSnzbxk=.fbede544-9152-4320-b97c-aa50209f0b42@github.com>
References: <xy5SGxYpSr1HEYXXTGxlr_dJz4bwQmMaHZ0-rSnzbxk=.fbede544-9152-4320-b97c-aa50209f0b42@github.com>
Message-ID: <zzsGp8k6gLLDW5lIW7diuEiad1-a6IhQaT71dIbDtLU=.a690fc53-6860-4846-8565-f52e91578c94@github.com>

On Wed, 21 Sep 2022 08:03:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Fields `methods`, `properties`, `eventSets` are not volatile and read multiple times. This makes it an incorrect DCL.

Marked as reviewed by serb (Reviewer).

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

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


From psadhukhan at openjdk.org  Fri Oct  7 04:57:00 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Oct 2022 04:57:00 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types [v5]
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: <zGeNFJcTyOTqY94bKO84hSy1bYbfvyqbeWmphLyg_Ds=.cc6f3fb7-1b5e-47b4-8cb5-8c3bb3f7e718@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 update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10376/files
  - new: https://git.openjdk.org/jdk/pull/10376/files/4a1afda9..87f7e36c

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

  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  Fri Oct  7 04:57:03 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Oct 2022 04:57:03 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types [v4]
In-Reply-To: <6lI70mIUrPlclGDoFcSYkYasrOBlCxX4irw_4rQrWjY=.a1d32e29-b521-4ea9-8ebb-42eca6c04d4a@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
 <rt4u2JjnR9eEV5G0Dmbqhq6UjKs4gP61Jq_y79qdUN8=.68fa8334-1d6a-4d3e-adb2-ab510e86de73@github.com>
 <6lI70mIUrPlclGDoFcSYkYasrOBlCxX4irw_4rQrWjY=.a1d32e29-b521-4ea9-8ebb-42eca6c04d4a@github.com>
Message-ID: <0vVsWLEr2vN4qqjhO8caxuHHiBueq_I0xDkewpDDurc=.bafa1986-d6bb-408c-a6eb-31cdaf5672fe@github.com>

On Wed, 28 Sep 2022 12:23:59 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 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`.

Seems ok for consistency..
Have updated the PR and CSR...Can you please review CSR https://bugs.openjdk.org/browse/JDK-8294114

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

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


From aturbanov at openjdk.org  Fri Oct  7 06:23:32 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 7 Oct 2022 06:23:32 GMT
Subject: Integrated: 8292280: Unused field 'keyListener' in BasicRadioButtonUI
In-Reply-To: <IWbq6Zr-IcRpKs5_IQvKnEL-8lEc9OVxS9GrGkA9t38=.126f3214-32d2-4fef-9505-d61f157d22fb@github.com>
References: <IWbq6Zr-IcRpKs5_IQvKnEL-8lEc9OVxS9GrGkA9t38=.126f3214-32d2-4fef-9505-d61f157d22fb@github.com>
Message-ID: <KoS6fXQgwT8Y8btHjhO2qhwHab2tMiHmIkDRl28FaPY=.c920c37e-b20c-41a5-857c-5cc14cb97d22@github.com>

On Thu, 11 Aug 2022 06:53:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Field `keyListener` was added under [JDK-8033699](https://bugs.openjdk.org/browse/JDK-8033699). But then all its usages were removed in [JDK-8249548](https://bugs.openjdk.org/browse/JDK-8249548)

This pull request has now been integrated.

Changeset: 2d25c0a3
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d25c0a31c608ecddaa084d795a060598b3e0589
Stats:     8 lines in 1 file changed: 0 ins; 7 del; 1 mod

8292280: Unused field 'keyListener' in BasicRadioButtonUI

Reviewed-by: jdv, serb

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

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


From duke at openjdk.org  Fri Oct  7 07:35:06 2022
From: duke at openjdk.org (duke)
Date: Fri, 7 Oct 2022 07:35:06 GMT
Subject: Withdrawn: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
References: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
Message-ID: <iV1XfQTjfXzhIZuY9TxvmA1DwOSUixaniKt0lZEBneE=.99f1225a-483a-4877-b4af-e9ae98ae9853@github.com>

On Thu, 16 Jun 2022 15:01:12 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines. It seems to be a testbug as adding some stability improvements fix the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. I have removed the problem listing and tested it in windows platform also, it works fine there.
> 
> Fix:
> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.

This pull request has been closed without being integrated.

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

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


From psadhukhan at openjdk.org  Fri Oct  7 08:40:42 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Oct 2022 08:40:42 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v6]
In-Reply-To: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
Message-ID: <gojBDXuBwsy2q7ViZ_vBlSbLDi1vrtWI8edK9xm43Dw=.b37d240e-3036-404a-90df-9f88344565e1@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:

  Set foreground in installDefaults

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9900/files
  - new: https://git.openjdk.org/jdk/pull/9900/files/fd80f96a..af4cca92

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

  Stats: 14 lines in 1 file changed: 8 ins; 5 del; 1 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  Fri Oct  7 08:40:43 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Oct 2022 08:40:43 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v3]
In-Reply-To: <f03AaWZQ8ZlmIkRQQMlM4dMjuBi8E0b6rfti6hYF42I=.b7587e10-447b-4121-9022-821cde40a71f@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>
 <f03AaWZQ8ZlmIkRQQMlM4dMjuBi8E0b6rfti6hYF42I=.b7587e10-447b-4121-9022-821cde40a71f@github.com>
Message-ID: <FlDUJQ7wgsxCUMduygHOK-_0y20LMsWIOfS2gwsM4t4=.6f229b3f-f2a3-4040-a51c-8492e766158a@github.com>

On Thu, 29 Sep 2022 12:15:43 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> 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.

Fair point..Updated to set in installDefaults

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

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


From psadhukhan at openjdk.org  Fri Oct  7 08:54:29 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Oct 2022 08:54:29 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v2]
In-Reply-To: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
Message-ID: <5Vher43DGbdGinN4oUvmYdj4iXSSLFACUqFPvOhpLT0=.7eaa0540-d7e7-45b9-8acb-242998fefafe@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.

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

 - Test fix
 - Take care of integer overflow in setSelectionInterval

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10409/files
  - new: https://git.openjdk.org/jdk/pull/10409/files/94fdf905..e42f2afd

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

  Stats: 99 lines in 3 files changed: 59 ins; 39 del; 1 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 psadhukhan at openjdk.org  Fri Oct  7 08:54:30 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Oct 2022 08:54:30 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v2]
In-Reply-To: <totUL5_2P1GiiDSP3wNt_EyGEZBosBgroBsHk1EqJhc=.968bb83e-b446-4e41-84f7-981d78911e17@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>
 <KT0UHwEiZuPO2uS1XWDJrlk1wFRdEsgVs1b_IBR3kSM=.2c862a0b-3222-485e-b713-bdd12a7f4097@github.com>
 <totUL5_2P1GiiDSP3wNt_EyGEZBosBgroBsHk1EqJhc=.968bb83e-b446-4e41-84f7-981d78911e17@github.com>
Message-ID: <m1e0DU7f3Ek3U-j4uM_Rib9lD5F0TOg-_7Px4UtmKlI=.0616c53d-f7a1-4c8b-9bd8-a66b0e647e3c@github.com>

On Mon, 3 Oct 2022 16:07:15 GMT, Alexey Ivanov <aivanov 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.
>
> I suggest amending `setSelectionInterval` to throw IOOBE if `Integer.MAX_VALUE` is passed.
> 
> Then I suggest amending `removeIndexInterval` to throw IOOBE if a negative value is passed or an index is `Integer.MAX_VALUE`. Explicit handling of negative values could be an optimisation made in addition to handling `MAX_VALUE`.
> 
> In both cases, the spec needs to be updated, and therefore the CSR will be required.

I guess Integer.MAX_VALUE should be valid "int" value, its because of internal calculation which is causing it to overflow so I guess we should not update the spec for wrongful calculation. 
I have fixed the overflow in setSelectionInterval.

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

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


From psadhukhan at openjdk.org  Fri Oct  7 09:00:32 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Oct 2022 09:00:32 GMT
Subject: RFR: 5080391: ArrayIndexOutOfBounds during "undo" of Right-to-Left
 text insert [v2]
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: <sq5YNMPwZ0lbaQ-yPG5mp9bET-ERBhN1x81n0a4pGZc=.9aaa2a4a-973b-4c9a-aa3a-036e621c3de1@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.

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/10446/files
  - new: https://git.openjdk.org/jdk/pull/10446/files/c1020f15..8e07fdc3

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

  Stats: 198 lines in 2 files changed: 114 ins; 84 del; 0 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 psadhukhan at openjdk.org  Fri Oct  7 09:05:35 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Oct 2022 09:05:35 GMT
Subject: RFR: 5080391: ArrayIndexOutOfBounds during "undo" of Right-to-Left
 text insert [v2]
In-Reply-To: <2bRWmn9tz1W2Hc6L-EQgVmw7UzVz38XMGoo71uA1HEc=.6a744d13-98cd-4a9b-9a43-7bbc09ed7be1@github.com>
References: <6RcEPyVsdn3GAryyi2QYk3OGfPDUGxFD-W0c_2s8iH4=.b10fa89b-07b7-4e8b-858f-1311d0ffeaae@github.com>
 <2bRWmn9tz1W2Hc6L-EQgVmw7UzVz38XMGoo71uA1HEc=.6a744d13-98cd-4a9b-9a43-7bbc09ed7be1@github.com>
Message-ID: <2Yg2YfWHVULkQ5Flrxs-BHGIhx5Ej7ebbyR6D2SeKa0=.b035c42c-9966-4f41-9cc2-8aa0f72a1571@github.com>

On Mon, 3 Oct 2022 11:20:17 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
>
> src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java line 958:
> 
>> 956:                 int index = bidiRoot.getElementIndex(p0);
>> 957:                 Element bidiElem = bidiRoot.getElement(index);
>> 958:                 if (bidiElem != null && bidiElem.getEndOffset() >= p1) {
> 
> Is it possible that `bidiElem` is `null`? It should never be. If it is, it is a bug in the code and throwing NPE seems good ? it will be the indication of the bug.
> 
> Since the NPE has never been thrown from this code, I'd rather leave it unchanged here.

`getElement()` can return null [here](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java#L2619) and [here](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java#L2398)
so it should not be enitrely impossible not to get null, so it should be a ok

> test/jdk/javax/swing/text/AbstractDocument/TestUndoError.java line 39:
> 
>> 37: import javax.swing.undo.UndoManager;
>> 38: 
>> 39: public class TestUndoError {
> 
> `TestUndoInsertArabicText`? It's more specific this way.

ok

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

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


From psadhukhan at openjdk.org  Fri Oct  7 09:08:37 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Oct 2022 09:08:37 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v3]
In-Reply-To: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
Message-ID: <vH3nQmcLWDfKoMaWweYcI1rEPjTJEq0JTK5jJVysecQ=.ab95e113-9ef2-4c9b-a0fd-10281de796af@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.

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/10409/files
  - new: https://git.openjdk.org/jdk/pull/10409/files/e42f2afd..b70c6ad7

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

  Stats: 2 lines in 1 file changed: 0 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 psadhukhan at openjdk.org  Fri Oct  7 09:14:16 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Oct 2022 09:14:16 GMT
Subject: RFR: 5080391: ArrayIndexOutOfBounds during "undo" of Right-to-Left
 text insert [v2]
In-Reply-To: <sq5YNMPwZ0lbaQ-yPG5mp9bET-ERBhN1x81n0a4pGZc=.9aaa2a4a-973b-4c9a-aa3a-036e621c3de1@github.com>
References: <6RcEPyVsdn3GAryyi2QYk3OGfPDUGxFD-W0c_2s8iH4=.b10fa89b-07b7-4e8b-858f-1311d0ffeaae@github.com>
 <sq5YNMPwZ0lbaQ-yPG5mp9bET-ERBhN1x81n0a4pGZc=.9aaa2a4a-973b-4c9a-aa3a-036e621c3de1@github.com>
Message-ID: <ckPdqNq-2b28w7s8TT6cL9K-tS7QPNQT8MYX_vqgmag=.0f73b81c-a3f3-4dba-a187-2c414c426aea@github.com>

On Fri, 7 Oct 2022 09:00:32 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.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

test/jdk/javax/swing/text/AbstractDocument/TestUndoInsertArabicText.java line 38:

> 36: import javax.swing.undo.UndoManager;
> 37: 
> 38: public class TestUndoInsertArabicText {

Updated test to test insertion and undoing at beginning and middle, in addition to end of text

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

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


From aivanov at openjdk.org  Fri Oct  7 12:47:25 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 7 Oct 2022 12:47:25 GMT
Subject: RFR: 5080391: ArrayIndexOutOfBounds during "undo" of Right-to-Left
 text insert [v2]
In-Reply-To: <2Yg2YfWHVULkQ5Flrxs-BHGIhx5Ej7ebbyR6D2SeKa0=.b035c42c-9966-4f41-9cc2-8aa0f72a1571@github.com>
References: <6RcEPyVsdn3GAryyi2QYk3OGfPDUGxFD-W0c_2s8iH4=.b10fa89b-07b7-4e8b-858f-1311d0ffeaae@github.com>
 <2bRWmn9tz1W2Hc6L-EQgVmw7UzVz38XMGoo71uA1HEc=.6a744d13-98cd-4a9b-9a43-7bbc09ed7be1@github.com>
 <2Yg2YfWHVULkQ5Flrxs-BHGIhx5Ej7ebbyR6D2SeKa0=.b035c42c-9966-4f41-9cc2-8aa0f72a1571@github.com>
Message-ID: <sqgfeuzOUuPIYL3waQYeXf6A9COh07BiGi_PNNz1f_k=.df31410f-0202-41b2-b452-84a76aa3c34a@github.com>

On Fri, 7 Oct 2022 09:01:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> `getElement()` can return null [here](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java#L2619) and [here](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java#L2398) so it should not be enitrely impossible not to get null, so it should be a ok

I know it is possible _theoretically_. My point is for a valid offset in the document, this particular line must _never_ return `null`. If it does, the element tree is invalid. As such, we should rather catch the case of bad bidi element tree by throwing NPE rather than pretending nothing bad happened.

`BidiRootElement` is a `BranchElement`: https://github.com/openjdk/jdk/blob/096bca4a9c5e8ac2668dd965df92153ea1d80add/src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java#L2700-L2713

And [`BranchElement.getElementIndex`](https://github.com/openjdk/jdk/blob/096bca4a9c5e8ac2668dd965df92153ea1d80add/src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java#L2416-L2474) always returns a *valid* index.

So, I am against adding the `null`-check. It is not necessary here.

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

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


From aivanov at openjdk.org  Fri Oct  7 12:50:09 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 7 Oct 2022 12:50:09 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types [v5]
In-Reply-To: <zGeNFJcTyOTqY94bKO84hSy1bYbfvyqbeWmphLyg_Ds=.cc6f3fb7-1b5e-47b4-8cb5-8c3bb3f7e718@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
 <zGeNFJcTyOTqY94bKO84hSy1bYbfvyqbeWmphLyg_Ds=.cc6f3fb7-1b5e-47b4-8cb5-8c3bb3f7e718@github.com>
Message-ID: <rDBp2cUxItel-5sVCYX3RcK742R0H9T8IO1bBPD1X8w=.ef4d3c23-0a65-4682-9b08-f0a15055e0ec@github.com>

On Fri, 7 Oct 2022 04:57:00 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 update

Marked as reviewed by aivanov (Reviewer).

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

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


From alanb at openjdk.org  Fri Oct  7 12:53:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Oct 2022 12:53:30 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: <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@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

src/java.se/share/data/jdwp/jdwp.spec line 101:

> 99:         "<a href=../../api/java.base/java/lang/Thread.html#platform-threads>platform thread</a> "
> 100:         "in the target VM. This includes platform threads created with the Thread "
> 101:         "API and all native threads attached to the target VM with JNI code."

The spec for the JDWP AllThreads command was significantly reworded in Java 19 so this is where this typo crept in. We have JDK-8294672 tracking it to fix for Java 20, maybe you should take it?

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

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


From mvs at openjdk.org  Fri Oct  7 13:45:45 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Fri, 7 Oct 2022 13:45:45 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is unstable in
 MacOS machines
Message-ID: <nDQmbmLEjsXkX8ZiCHLPWIdek8QO364h84ObYSK0YdI=.6b99ed5b-6086-41bf-aa9c-df43b1bed70e@github.com>

java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.

Fix:
Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.

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

Commit messages:
 - 8288415: java/awt/PopupMenu/PopupMenuLocation.java is unstable in MacOS machines

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

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


From aivanov at openjdk.org  Fri Oct  7 16:34:23 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 7 Oct 2022 16:34:23 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v8]
In-Reply-To: <bB5v1d6Wqb8RckDvDN-36a2I1gkAcr_GuN0e_fDiYcQ=.2dbecf9e-76f7-455f-9462-8af31867d2c3@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <PW-1fK5yC3BQzpbFre9ORzhHWTFvwamRG8XZ3hWpfAY=.2a832771-dee6-418a-b6e7-0cf860aa3fbc@github.com>
 <bB5v1d6Wqb8RckDvDN-36a2I1gkAcr_GuN0e_fDiYcQ=.2dbecf9e-76f7-455f-9462-8af31867d2c3@github.com>
Message-ID: <R6T7gpYuF81el5sR-FEsspnsqM_B4V_aO0E1OPk_-lQ=.1dd7a35c-65b2-4770-8ca5-ddb396b07bc4@github.com>

On Fri, 7 Oct 2022 02:07:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The sun.java2d.pipe.Region#clipRound() seems have the same purpose, but it also clip the double to int.

Thank you, @mrserb. It's better to re-use the existing implementation. I tested with it, it gives the same result.

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

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


From honkar at openjdk.org  Fri Oct  7 17:28:35 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 7 Oct 2022 17:28:35 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v8]
In-Reply-To: <PW-1fK5yC3BQzpbFre9ORzhHWTFvwamRG8XZ3hWpfAY=.2a832771-dee6-418a-b6e7-0cf860aa3fbc@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <PW-1fK5yC3BQzpbFre9ORzhHWTFvwamRG8XZ3hWpfAY=.2a832771-dee6-418a-b6e7-0cf860aa3fbc@github.com>
Message-ID: <Yn8f_kxzHgPRyp4vQU0iLyeS5I7uVBrVzdLeBVsF8xA=.6b139e11-72fd-4736-b209-98a9c03d5c56@github.com>

On Wed, 5 Oct 2022 21:00:11 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:
> 
>   test updated

Two edge cases issues were identified while testing with different frame sizes and on different platforms-

- One was due to the inherent issue of robot.getPixelColor() which sometimes returns a different pixel color returned at the edge of border. This is a test issue and is fixed by adding a offset of 1 pixel to the border and corner checks.

- The other issue occurs only in specific scenario - when the internal frame size is set to 125, 150, 225, 250...etc on uiScale of 1.25 (on Windows). A thin red line is seen at the bottom of the border. This is might be due the `loopCount` value.

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

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


From honkar at openjdk.org  Fri Oct  7 17:28:37 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 7 Oct 2022 17:28:37 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v8]
In-Reply-To: <bB5v1d6Wqb8RckDvDN-36a2I1gkAcr_GuN0e_fDiYcQ=.2dbecf9e-76f7-455f-9462-8af31867d2c3@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <PW-1fK5yC3BQzpbFre9ORzhHWTFvwamRG8XZ3hWpfAY=.2a832771-dee6-418a-b6e7-0cf860aa3fbc@github.com>
 <bB5v1d6Wqb8RckDvDN-36a2I1gkAcr_GuN0e_fDiYcQ=.2dbecf9e-76f7-455f-9462-8af31867d2c3@github.com>
Message-ID: <1hPZXAFjEQ-JH2bQ_ZPAQt2ZR--EABys-P_KLP6eg7Q=.e4c4ef5d-4a84-4ca9-948a-1289cca7eb4b@github.com>

On Fri, 7 Oct 2022 02:07:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test updated
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 256:
> 
>> 254:          * @return the rounded value
>> 255:          */
>> 256:         private static int roundHalfDown(double d) {
> 
> The sun.java2d.pipe.Region#clipRound() seems have the same purpose, but it also clip the double to int.

@mrserb Thank you for the suggestion.

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

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


From honkar at openjdk.org  Fri Oct  7 18:02:34 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 7 Oct 2022 18:02:34 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v9]
In-Reply-To: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
Message-ID: <H5OWwPvbDv9LxfyICK-DcPu_dAU7AfZN-AFTfCD5NJc=.509dc09c-525a-4942-aaa4-fa31dbe3fca6@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:

  fix for pixel color at edge, outermost border lines drawn as part of bulk of border

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10274/files
  - new: https://git.openjdk.org/jdk/pull/10274/files/2e3b7af1..da54767f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10274&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10274&range=07-08

  Stats: 36 lines in 2 files changed: 1 ins; 20 del; 15 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 Oct  7 18:07:21 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 7 Oct 2022 18:07:21 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v9]
In-Reply-To: <H5OWwPvbDv9LxfyICK-DcPu_dAU7AfZN-AFTfCD5NJc=.509dc09c-525a-4942-aaa4-fa31dbe3fca6@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <H5OWwPvbDv9LxfyICK-DcPu_dAU7AfZN-AFTfCD5NJc=.509dc09c-525a-4942-aaa4-fa31dbe3fca6@github.com>
Message-ID: <EO850TZmgat4gn1QOR4vNvv8ZmzBYrxdY-WSmOED0sY=.6f49177b-2b55-445c-95ae-7e4dd50697ef@github.com>

On Fri, 7 Oct 2022 18:02:34 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:
> 
>   fix for pixel color at edge, outermost border lines drawn as part of bulk of border

With the current update, on some scales the highlight and shadow lines are not positioned exactly at the middle of the border. This is being investigated currently.

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

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


From aivanov at openjdk.org  Fri Oct  7 18:37:19 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 7 Oct 2022 18:37:19 GMT
Subject: RFR: 5080391: ArrayIndexOutOfBounds during "undo" of Right-to-Left
 text insert [v2]
In-Reply-To: <sq5YNMPwZ0lbaQ-yPG5mp9bET-ERBhN1x81n0a4pGZc=.9aaa2a4a-973b-4c9a-aa3a-036e621c3de1@github.com>
References: <6RcEPyVsdn3GAryyi2QYk3OGfPDUGxFD-W0c_2s8iH4=.b10fa89b-07b7-4e8b-858f-1311d0ffeaae@github.com>
 <sq5YNMPwZ0lbaQ-yPG5mp9bET-ERBhN1x81n0a4pGZc=.9aaa2a4a-973b-4c9a-aa3a-036e621c3de1@github.com>
Message-ID: <6Kqr4negWpT1Lzc01V3v-Uwa6aQZqdLptL-6RXFiRIw=.ed5df3db-39a2-40f6-92cf-bfbd563db66d@github.com>

On Fri, 7 Oct 2022 09:00:32 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.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

I do not think this makes a difference. Well, the first insertion does make a difference: it changes the text component state so from left-to-right only to bidirectional.

The following manipulations just add more Arabic text, so that the entire text run is right-to-left.

You want to test the situation where the change from left-to-right to bidirectional and component orientation occurs for the first time, and the text is inserted in the middle of a text run, in the end of text. You should probably, re-create `JTextArea` and `UndoManager` to test such scenarios.

You should also verify the result of undo. If you insert text by one character, each undo should remove that character from the text.

If you don't test the result of undo, you don't know whether the text was modified as expected or not.

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

Changes requested by aivanov (Reviewer).

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


From aivanov at openjdk.org  Fri Oct  7 19:52:22 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 7 Oct 2022 19:52:22 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v3]
In-Reply-To: <m1e0DU7f3Ek3U-j4uM_Rib9lD5F0TOg-_7Px4UtmKlI=.0616c53d-f7a1-4c8b-9bd8-a66b0e647e3c@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>
 <KT0UHwEiZuPO2uS1XWDJrlk1wFRdEsgVs1b_IBR3kSM=.2c862a0b-3222-485e-b713-bdd12a7f4097@github.com>
 <totUL5_2P1GiiDSP3wNt_EyGEZBosBgroBsHk1EqJhc=.968bb83e-b446-4e41-84f7-981d78911e17@github.com>
 <m1e0DU7f3Ek3U-j4uM_Rib9lD5F0TOg-_7Px4UtmKlI=.0616c53d-f7a1-4c8b-9bd8-a66b0e647e3c@github.com>
Message-ID: <k9VN9h1D3GOx-qR7rOkOI8Toz7eMX4Zvq2GJt8wJP1o=.7f18aa56-be2a-46db-977a-9e45ce1f2c42@github.com>

On Fri, 7 Oct 2022 08:49:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I suggest amending `setSelectionInterval` to throw IOOBE if `Integer.MAX_VALUE` is passed.
>> 
>> Then I suggest amending `removeIndexInterval` to throw IOOBE if a negative value is passed or an index is `Integer.MAX_VALUE`. Explicit handling of negative values could be an optimisation made in addition to handling `MAX_VALUE`.
>> 
>> In both cases, the spec needs to be updated, and therefore the CSR will be required.
>
> I guess Integer.MAX_VALUE should be valid "int" value, its because of internal calculation which is causing it to overflow so I guess we should not update the spec for wrongful calculation. 
> I have fixed the overflow in setSelectionInterval.

This is not a generic class, its main purpose is to handle list selection in UI components, such as `JList`. Excluding `Integer.MAX_VALUE` makes sense to me, it simplifies the code: no additional check in the loop and no special handling `removeIndexInterval` which also adds a condition to the loop.

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

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


From prr at openjdk.org  Fri Oct  7 20:27:25 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 7 Oct 2022 20:27:25 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types [v5]
In-Reply-To: <zGeNFJcTyOTqY94bKO84hSy1bYbfvyqbeWmphLyg_Ds=.cc6f3fb7-1b5e-47b4-8cb5-8c3bb3f7e718@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
 <zGeNFJcTyOTqY94bKO84hSy1bYbfvyqbeWmphLyg_Ds=.cc6f3fb7-1b5e-47b4-8cb5-8c3bb3f7e718@github.com>
Message-ID: <j6xKSBZRYMJi3Q05_KohOkBAC41Bn4REagSN1nux-wA=.e1ce2e0d-e411-4b49-b878-eceb7ba0fe59@github.com>

On Fri, 7 Oct 2022 04:57:00 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 update

Marked as reviewed by prr (Reviewer).

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

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


From serb at openjdk.org  Sat Oct  8 15:32:18 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 8 Oct 2022 15:32:18 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <nDQmbmLEjsXkX8ZiCHLPWIdek8QO364h84ObYSK0YdI=.6b99ed5b-6086-41bf-aa9c-df43b1bed70e@github.com>
References: <nDQmbmLEjsXkX8ZiCHLPWIdek8QO364h84ObYSK0YdI=.6b99ed5b-6086-41bf-aa9c-df43b1bed70e@github.com>
Message-ID: <mb_WFScum4x3-ifE0b3VKvwXwfifLooAOv9xZCu0ans=.e8b08cbe-f6e4-47d2-a5fa-835da1f27ebe@github.com>

On Fri, 7 Oct 2022 13:36:17 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
> 
> Fix:
> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 148:

> 146:         try {
> 147:             ImageIO.write(robot.createScreenCapture(
> 148:                     new Rectangle(0, 0, screenSize.width, screenSize.height)),

This may capture the default screen while the frame is currently visible on another one.

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

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


From serb at openjdk.org  Sat Oct  8 15:33:36 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 8 Oct 2022 15:33:36 GMT
Subject: RFR: 8294807: Fix typos and clarify javadoc for
 SunToolKit.realsSync
In-Reply-To: <tAs-uXk9d4__tcb4m_yegNiDI3ZNl1AHtj35rWxaQJI=.758713aa-af1c-4efd-8f06-145fd290bd35@github.com>
References: <eOSJ4nSjRiskHcEirxMJmllsCP0e0wHQQ8__azU0CEw=.3a2a29b2-a349-43f9-bbd5-14b6e2ee32a2@github.com>
 <5GlfDtRnHLa7PIslOaYDEg8g0M2oB2-YNAatMtJbDWU=.6d381cb4-c329-4b83-a5d6-29dc96521edb@github.com>
 <tAs-uXk9d4__tcb4m_yegNiDI3ZNl1AHtj35rWxaQJI=.758713aa-af1c-4efd-8f06-145fd290bd35@github.com>
Message-ID: <gnNBijpRyO16XbbTw1y1C9-KEkquWpejw11rb0GIEi8=.e8190cfa-466c-40b9-aadb-f27b8d4461d3@github.com>

On Thu, 6 Oct 2022 23:23:21 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1451:
>> 
>>> 1449:      *
>>> 1450:      * <p> This method allows writing tests without explicit timeouts
>>> 1451:      * or waiting for some event.  Example:
>> 
>> Should it be ?without _using_ ? or waiting ???  
>> Does ?for an event? sound better?
>
> In my opinion, "without using ... or waiting ..." seems better to match the tense of "waiting" to show more clearly what the "or" is intended for (assuming the OR is meant for the explicit timeouts and the waiting for an event).
> 
> Otherwise, the "or" may be confused to be between "writing ... or waiting ...".
> 
> For the "event" portion, I think either here is OK. I don't think either would cause confusion and both sound reasonable.

I do not think we should recommend as of now the usage of the internal API in the tests.

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

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


From prr at openjdk.org  Sat Oct  8 15:34:43 2022
From: prr at openjdk.org (Phil Race)
Date: Sat, 8 Oct 2022 15:34:43 GMT
Subject: RFR: 8294488: Delete KCMS transforms wrappers
In-Reply-To: <NPi08uuC9X_65nmI52YUY-fDamcRo9A26Q69wsl6dDU=.3de3ad05-1adb-44b0-8a23-82cc025e48f7@github.com>
References: <NPi08uuC9X_65nmI52YUY-fDamcRo9A26Q69wsl6dDU=.3de3ad05-1adb-44b0-8a23-82cc025e48f7@github.com>
Message-ID: <tlnU_u3d9hHO_VmA9psnu3uIicU__OYRTlxk_lB4Sa8=.e83db050-1b9e-4aa1-860a-38383a58ad57@github.com>

On Wed, 28 Sep 2022 03:12:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is a request to cleanup the shared code for the colors conversions. That code still uses some wrappers which can be simplified and/or deleted after KCMS removal. For example, each conversion from one color space to another creates 3 wrappers - for the first color profile, the second color profile, and one to combine the first two. But for the lcms library we only need the list of color profiles and rendering intent -> only one transform object can be used.
> 
> The new constructor for the LCMSTransform is [added](https://github.com/openjdk/jdk/pull/10459/files#diff-7448ea8346eb08c6ec1a518e3c3399d7d078a514c07956ee7e8e2b5be3d082e1R77) and now used everywhere:
> `LCMSTransform(int renderingIntent, ICC_Profile... profiles)` 
> It will wrap the `cmsCreateMultiprofileTransform` [function ](https://github.com/openjdk/jdk/pull/10459/files#diff-eed6ddb15e9c5bdab9fc3b3930d5d959966165d9622ddd293e8572489adea98bR202) in LCMS library:
> 
> I tried to preserve the current behavior, and as a result, two "workarounds" are used for the next bugs.
>  * [JDK-8216369](https://bugs.openjdk.org/browse/JDK-8216369): after the cleanup it became obvious that we use a hardcoded value for the first rendering [intent](https://github.com/openjdk/jdk/pull/10459/files#diff-e3d6eea060882cab00827c00e1a83b0e0a5b2a31fa9a9aa2122841bbd57c4a6dR473). There is a code to fetch the intent from the color profile but I postponed use it for now because some of our built-in profiles use different default intents.
>  * [JDK-8272860](https://bugs.openjdk.org/browse/JDK-8272860): the old code always fetched some information from the color profile header as result we cache the headers for any profiles we used. This cache workaround the JDK-8272860 while the direct access to the profile via LCMS library could fail. The new code intentionally caches the [header](https://github.com/openjdk/jdk/pull/10459/files#diff-7448ea8346eb08c6ec1a518e3c3399d7d078a514c07956ee7e8e2b5be3d082e1R91).
> 
> Notes:
> * The old wrappers used a rendering intent for each intermediate transform, the LCMS use only one intent
> * The old wrappers could throw the cmm exception if the rendering intent was not supported. The LCMS ignores unsupported intents and uses some [default](https://github.com/LuaDist/lcms/blob/master/doc/TUTORIAL.TXT#L1094)
>  * The old wrappers had a way to specify the input and output profiles, the LCMS library uses the first profile as input and the last profile as output. Those parameters are [removed](https://github.com/openjdk/jdk/pull/10459/files#diff-81b49f067b32296497e9e727bda25efe0b7f84fb2c05645eb6b272bfc32469f1L38)
>  * If at some point the new CMS library will be added it will be easy to integrate it using XXCMS plugin, instead of using some specific library logic in the shared code

It looks Ok. I ran all our automated tests and there was only one failure - of a closed (for no particular reason) jtreg test
that tests the pluggable interface. It will need to be problem listed until such time as it can be updated - or perhaps deleted.

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

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


From serb at openjdk.org  Sat Oct  8 15:37:18 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 8 Oct 2022 15:37:18 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v9]
In-Reply-To: <H5OWwPvbDv9LxfyICK-DcPu_dAU7AfZN-AFTfCD5NJc=.509dc09c-525a-4942-aaa4-fa31dbe3fca6@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <H5OWwPvbDv9LxfyICK-DcPu_dAU7AfZN-AFTfCD5NJc=.509dc09c-525a-4942-aaa4-fa31dbe3fca6@github.com>
Message-ID: <lMbemiq6UAVbkoCn2e8emYkiDxE8xZevDk7CzSzxVD8=.92837723-cfaa-4f3d-a525-c9dd90968e04@github.com>

On Fri, 7 Oct 2022 18:02:34 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:
> 
>   fix for pixel color at edge, outermost border lines drawn as part of bulk of border

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 266:

> 264:             }
> 265: 
> 266:             Graphics2D g2d = (Graphics2D) g;

It could be a DebugGraphics which is not a Graphics2D

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 277:

> 275:             resetTransform = (at.getShearX() == 0) && (at.getShearY() == 0);
> 276: 
> 277:             if (resetTransform) {

Please clarify why we should reset the current transform? How it will work if the user sets a transform and render this to the BufferedImage.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 292:

> 290:                 height = Region.clipRound(at.getScaleY() * h);
> 291:                 xtranslation = Region.clipRound(at.getScaleX() * x + at.getTranslateX());
> 292:                 ytranslation = Region.clipRound(at.getScaleY() * y + at.getTranslateY());

This probably should be refactored to something like this:
https://github.com/openjdk/jdk/blob/ec4fb47b90c9737dfdc285ebe98367a221c90c79/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L375

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

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


From honkar at openjdk.org  Sat Oct  8 15:37:18 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Sat, 8 Oct 2022 15:37:18 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v9]
In-Reply-To: <lMbemiq6UAVbkoCn2e8emYkiDxE8xZevDk7CzSzxVD8=.92837723-cfaa-4f3d-a525-c9dd90968e04@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <H5OWwPvbDv9LxfyICK-DcPu_dAU7AfZN-AFTfCD5NJc=.509dc09c-525a-4942-aaa4-fa31dbe3fca6@github.com>
 <lMbemiq6UAVbkoCn2e8emYkiDxE8xZevDk7CzSzxVD8=.92837723-cfaa-4f3d-a525-c9dd90968e04@github.com>
Message-ID: <lX-Q2pAERYf6ieC7xcmWpaJHQraPLI-q5Z0p8gr0bVM=.f0f57b95-7fef-45fe-a4a9-f9b73749f168@github.com>

On Fri, 7 Oct 2022 21:43:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix for pixel color at edge, outermost border lines drawn as part of bulk of border
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 277:
> 
>> 275:             resetTransform = (at.getShearX() == 0) && (at.getShearY() == 0);
>> 276: 
>> 277:             if (resetTransform) {
> 
> Please clarify why we should reset the current transform? How it will work if the user sets a transform and render this to the BufferedImage.

On fractional scaling, painting of lines and borders have issues (lines seem to be separated or look uneven) as shown above, https://github.com/openjdk/jdk/pull/10274#issue-1373421530. In order to paint them uniformly and next to each other, the idea is to render at 1x scaling, apply the required thickness/scaling to the lines at this point (when transform is reset) and then the original (old) transform is restored at the end. 

This idea was referenced from a similar issue https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648.

> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 292:
> 
>> 290:                 height = Region.clipRound(at.getScaleY() * h);
>> 291:                 xtranslation = Region.clipRound(at.getScaleX() * x + at.getTranslateX());
>> 292:                 ytranslation = Region.clipRound(at.getScaleY() * y + at.getTranslateY());
> 
> This probably should be refactored to something like this:
> https://github.com/openjdk/jdk/blob/ec4fb47b90c9737dfdc285ebe98367a221c90c79/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L375

@mrserb Thank for the suggestion. Are you suggesting that same transformations be applied for width, height and additionally to x&y translations? 
https://github.com/openjdk/jdk/blob/ec4fb47b90c9737dfdc285ebe98367a221c90c79/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L373

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

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


From serb at openjdk.org  Sat Oct  8 15:57:46 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 8 Oct 2022 15:57:46 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <WXtjNlMxrqPtVNIO8yUYQVdPwdVp--05A-IOgxv7g2c=.f697edc4-1690-448f-bc25-5e59914f73bc@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>
 <WXtjNlMxrqPtVNIO8yUYQVdPwdVp--05A-IOgxv7g2c=.f697edc4-1690-448f-bc25-5e59914f73bc@github.com>
Message-ID: <YF95OZ1hIYxP7NqTK3Na-YLGgIQVg2ly0bS74DrosnU=.82563b7f-ae39-4329-981b-72fe4fbc7f9b@github.com>

On Tue, 27 Sep 2022 18:03:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> 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.

Most of that "other" properties are specified by the "skin" file for the Nimbus L&F. Take a look to the "NimbusDefaults.java", it has many-many properties which are usually hardcoded in other L&F. Inital idea of the "skin" was the ability to swicth the UI appiarance, the style of "echo" is part of it.

It is of course possible to set/update that field directly by the application, but for the Nimbus L&F default value should be set by the skin.

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

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


From psadhukhan at openjdk.org  Sat Oct  8 19:42:43 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sat, 8 Oct 2022 19:42:43 GMT
Subject: RFR: 8295007: javax/swing/JRadioButton/4314194/bug4314194.java fails
 in mach5 for WIndowLookAndFeel
Message-ID: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>

javax/swing/JRadioButton/4314194/bug4314194.java correct color pixels pixel % varies between 30% for Metal to about 20% for Nimbus to about 19% for Windows L&F. But Nimbus in linux correct color pixel % falls to about 14%
so adjusted % tolerance check to 10
Also, JDK-8075916 is fixed for NimbusL&F but same issue is present for GTK L&F which is to be addressed separately as JDK-8295006 so problemlisted for now

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

Commit messages:
 - 8295007: javax/swing/JRadioButton/4314194/bug4314194.java fails in mach5 for WIndowLookAndFeel

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

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


From serb at openjdk.org  Sat Oct  8 19:44:48 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 8 Oct 2022 19:44:48 GMT
Subject: RFR: 8295003: Do not mention applets in the "java.awt.color" package
Message-ID: <-5VrLrHDBrYLd9a67snxU5jQYywXQmaKh8o702F0mY0=.dc60f1ff-40a1-4427-b5cc-e872f2cf44bb@github.com>

The usage of "applets" are replaced by the "applications" in the "java.awt.color" package.
If there are no objections I'll skip the CSR for this small cleanup.

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

Commit messages:
 - 8295003: Do not mention applets in the "java.awt.color" package

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

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


From duke at openjdk.org  Sun Oct  9 08:55:05 2022
From: duke at openjdk.org (duke)
Date: Sun, 9 Oct 2022 08:55:05 GMT
Subject: Withdrawn: 8288428: javax/swing/JInternalFrame/Test6505027.java fails
 frequently in MacOS 12 machines
In-Reply-To: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
References: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
Message-ID: <s4EE_l0Xr-8A9-h3x2_v9Ut0XP6_bkd0Wblp6rVQFNA=.9d414d95-c1c6-4ea7-9fa0-92c69b394f37@github.com>

On Fri, 17 Jun 2022 14:28:15 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> javax/swing/JInternalFrame/Test6505027.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines and it fails intermittently in CI causing some noise.
> It seems to be a testbug as adding some stability improvements fix the issue.
> 
> Fix:
> Some stability improvements have been done and the test has been run 10 times per platform in mach5 and got full PASS.

This pull request has been closed without being integrated.

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

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


From magare31 at gmail.com  Sun Oct  9 14:57:12 2022
From: magare31 at gmail.com (magare31 at gmail.com)
Date: Sun, 9 Oct 2022 10:57:12 -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: <028e01d8dbef$69b25070$3d16f150$@gmail.com>

Since I am new to this, and apologies for the broad email, could someone explain the following for the corresponding bug (JDK-8294904)?

 

*	This bug is listed as one for a generic OS, whereas I specified Windows (I can confirm that it is Windows only).
*	This bug is listed as "resolved" with an "incomplete resolution".  I did provide the full solution, so I am not sure what this means.  (Also, Oracle asked for a standalone test, which I also provided over email)

 

And thanks.

 

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/20221009/ffb8e49f/attachment.htm>

From aivanov at openjdk.org  Sun Oct  9 15:29:55 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sun, 9 Oct 2022 15:29:55 GMT
Subject: RFR: 8295007: javax/swing/JRadioButton/4314194/bug4314194.java
 fails in mach5 for WIndowLookAndFeel
In-Reply-To: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
References: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
Message-ID: <LsNTxLmmchMUqusNl0gWKXxWigZl8GpA0j86Qq068w8=.4163037c-ad19-40fe-b9ca-63ff7b350ddd@github.com>

On Sat, 8 Oct 2022 05:04:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JRadioButton/4314194/bug4314194.java correct color pixels pixel % varies between 30% for Metal to about 20% for Nimbus to about 19% for Windows L&F. But Nimbus in linux correct color pixel % falls to about 14%
> so adjusted % tolerance check to 10
> Also, JDK-8075916 is fixed for NimbusL&F but same issue is present for GTK L&F which is to be addressed separately as JDK-8295006 so problemlisted for now

I propose using the ?full block? character (U+2588 ?) which results in a text filled with the selected color. _The tolerance_ could be even increased in this case.


        checkBox = new JCheckBox("\u2588".repeat(5));
        radioButton = new JRadioButton("\u2588".repeat(5));


Otherwise, the test depends on the font used, if the strokes are thin, it may fail.

As I posted in the comment, the test should disable antialiasing and count the pixels of the correct color, it should ignore the pixels of the background color. To accommodate for anti-aliasing on macOS and rendering of the control itself, the tolerance which is already in place could be used. I can take on this improvement. Changing the text of the controls should already make the test robust enough.

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

Changes requested by aivanov (Reviewer).

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


From aturbanov at openjdk.org  Sun Oct  9 21:03:52 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 9 Oct 2022 21:03:52 GMT
Subject: RFR: 8293984: Unnecessary Vector usage in PropertyEditorSupport
 [v2]
In-Reply-To: <d_Iu8wlX0aPiKtfN2F6okrdy8lyeM8zzG8F8Dett58E=.1bfbea3a-8bd1-4b46-8f14-8a860049081f@github.com>
References: <d_Iu8wlX0aPiKtfN2F6okrdy8lyeM8zzG8F8Dett58E=.1bfbea3a-8bd1-4b46-8f14-8a860049081f@github.com>
Message-ID: <J7xW-Dl35eoSTiFcXmgmN3eJ00x9D0T_-4D6_5a1A7o=.f20be004-1612-4ee4-a9a8-a9e780936129@github.com>

> Field PropertyEditorSupport.listeners is accessed only under `synchronized(this)`.
> It means extra synchronization by Vector is not needed.

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

  8293984: Unnecessary Vector usage in PropertyEditorSupport
  
  use ArrayList constructor instead of clone

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10331/files
  - new: https://git.openjdk.org/jdk/pull/10331/files/b15462b4..303e4fbd

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

  Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 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  Sun Oct  9 21:03:54 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 9 Oct 2022 21:03:54 GMT
Subject: RFR: 8293984: Unnecessary Vector usage in PropertyEditorSupport
 [v2]
In-Reply-To: <WFI9Dx4CBmmtzSAUDu3Kex-DX4WeMWWUkjHRhe59_U8=.e3c3bfe2-221c-4bd0-b8cc-9a104ecf6113@github.com>
References: <d_Iu8wlX0aPiKtfN2F6okrdy8lyeM8zzG8F8Dett58E=.1bfbea3a-8bd1-4b46-8f14-8a860049081f@github.com>
 <WFI9Dx4CBmmtzSAUDu3Kex-DX4WeMWWUkjHRhe59_U8=.e3c3bfe2-221c-4bd0-b8cc-9a104ecf6113@github.com>
Message-ID: <i0DdWswFCZ1EvpoB_u0QbqZhz6AFqVVnSzvmDpcGtY8=.6b5c90b3-0f74-4531-90f0-e23585f7399d@github.com>

On Fri, 7 Oct 2022 00:07:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293984: Unnecessary Vector usage in PropertyEditorSupport
>>   
>>   use ArrayList constructor instead of clone
>
> src/java.desktop/share/classes/java/beans/PropertyEditorSupport.java line 301:
> 
>> 299:     @SuppressWarnings("unchecked")
>> 300:     private <T> ArrayList<T> unsafeClone(ArrayList<T> v) {
>> 301:         return (ArrayList<T>)v.clone();
> 
> I think this can be simplified by using the new list in place of "unsafeClone".

Updated

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

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


From aturbanov at openjdk.org  Sun Oct  9 21:31:20 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 9 Oct 2022 21:31:20 GMT
Subject: RFR: 8295026: Remove unused fields in StyleSheet
Message-ID: <9p71hu-CpTJ6dsy_0j2Rnks8TX7m4jyIgyGpeo8l18k=.9cfe4931-2d55-4ad8-bf67-78c05a13d7b7@github.com>

There are 3 unused fields in single `StyleSheet` file:
1. `static final Border noBorder = new EmptyBorder(0,0,0,0);`
2. `static final int DEFAULT_FONT_SIZE = 3;`
3. `URL imageurl;` in nested `javax.swing.text.html.StyleSheet.ListPainter` class

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

Commit messages:
 - [PATCH] Remove unused fields in StyleSheet

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

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


From duke at openjdk.org  Sun Oct  9 21:31:20 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 9 Oct 2022 21:31:20 GMT
Subject: RFR: 8295026: Remove unused fields in StyleSheet
In-Reply-To: <9p71hu-CpTJ6dsy_0j2Rnks8TX7m4jyIgyGpeo8l18k=.9cfe4931-2d55-4ad8-bf67-78c05a13d7b7@github.com>
References: <9p71hu-CpTJ6dsy_0j2Rnks8TX7m4jyIgyGpeo8l18k=.9cfe4931-2d55-4ad8-bf67-78c05a13d7b7@github.com>
Message-ID: <uVuEcLe5-HKC4L2wu2ipBlDzLBzJDSYZgU-xiIzd5qE=.97a04ba4-f103-4e1d-83eb-9683d57f67fd@github.com>

On Sat, 1 Oct 2022 17:05:11 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There are 3 unused fields in single `StyleSheet` file:
> 1. `static final Border noBorder = new EmptyBorder(0,0,0,0);`
> 2. `static final int DEFAULT_FONT_SIZE = 3;`
> 3. `URL imageurl;` in nested `javax.swing.text.html.StyleSheet.ListPainter` class

Nice little ~~spring~~ fall cleaning :)

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

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

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


From swinxythecat at gmail.com  Sun Oct  9 21:45:43 2022
From: swinxythecat at gmail.com (SWinxy)
Date: Sun, 9 Oct 2022 17:45:43 -0400
Subject: professional (24-bit) sampled audio support in the Windows native
 implementation of libjsound
In-Reply-To: <028e01d8dbef$69b25070$3d16f150$@gmail.com>
References: <02e901d8d4c0$7dd12ee0$79738ca0$@gmail.com>
 <506f19c5-28ae-e606-e7f1-22464793afcb@oracle.com>
 <028e01d8dbef$69b25070$3d16f150$@gmail.com>
Message-ID: <CAPRuVTW02i9b8zoivHk+wNMh7s_tu86Fvf0nEeoZbQ9VJYTNEw@mail.gmail.com>

JDK-8294904 [1] should be updated with your sample. I'm not exactly
sure why it was marked as resolved this past Friday, but the resolution of
'incomplete' makes me think they didn't feel you provided enough
information. Also I think the OS was set to 'generic' because the lack of
support might affect other operating systems' support for 24bit sampled
audio. The caveat is that I'm not well-versed in this area.

[1] https://bugs.openjdk.org/browse/JDK-8294904

On Sun, Oct 9, 2022 at 10:57 AM <magare31 at gmail.com> wrote:

> Since I am new to this, and apologies for the broad email, could someone
> explain the following for the corresponding bug (JDK-8294904)?
>
>
>
>    - This bug is listed as one for a generic OS, whereas I specified
>    Windows (I can confirm that it is Windows only).
>    - This bug is listed as "resolved" with an "incomplete resolution".  I
>    did provide the full solution, so I am not sure what this means.  (Also,
>    Oracle asked for a standalone test, which I also provided over email)
>
>
>
> And thanks.
>
>
>
> *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 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/20221009/05bfdce3/attachment.htm>

From dnguyen at openjdk.org  Mon Oct 10 05:35:28 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Oct 2022 05:35:28 GMT
Subject: RFR: 8294254: [macOS]
 javax/swing/plaf/aqua/CustomComboBoxFocusTest.java failure
Message-ID: <XmBIB7o0eNNj0Pq2udzXOSo0DtC0rO9s9bEqJSOJVx8=.64ffb7a6-0498-41b9-95ad-172b165826c3@github.com>

The previous change to AquaComboBoxUI had 1 pixel of overlap between the text field and the combo button. This caused a few pixels to darken sometimes when an editable combobox is displayed. Since this test passes sometimes and fails some other times, it was not initially detected.

Since these few darkening pixels occur due to the change in AquaComboBoxUI, no reasonable change to the test could really be made, and the change would need to be to the class for the combobox. This fix was tested with a high count repeat and no failures occurred for various macOS systems.

Also removing the test from the problem list.

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

Commit messages:
 - Merge branch 'openjdk:master' into 8294254/overlapFixEditableCombobox
 - Remove test from problem list
 - Adjust rect width to remove overlap

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

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


From tr at openjdk.org  Mon Oct 10 05:47:25 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 10 Oct 2022 05:47:25 GMT
Subject: RFR: 8295007: javax/swing/JRadioButton/4314194/bug4314194.java
 fails in mach5 for WIndowLookAndFeel
In-Reply-To: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
References: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
Message-ID: <mGmVI7xGbDyLairOnDg3_iQF_QK2GtfPOdTh6KsjpiE=.9a8d7cb3-9cbd-4d3c-bb82-8060c2302390@github.com>

On Sat, 8 Oct 2022 05:04:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JRadioButton/4314194/bug4314194.java correct color pixels pixel % varies between 30% for Metal to about 20% for Nimbus to about 19% for Windows L&F. But Nimbus in linux correct color pixel % falls to about 14%
> so adjusted % tolerance check to 10
> Also, JDK-8075916 is fixed for NimbusL&F but same issue is present for GTK L&F which is to be addressed separately as JDK-8295006 so problemlisted for now

Marked as reviewed by tr (Author).

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

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


From duke at openjdk.org  Mon Oct 10 05:57:45 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Mon, 10 Oct 2022 05:57:45 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <CQk_asv3R6dcRVAousvRe-NwbDw_N2-B_8g5GczwISM=.70731343-2c66-4587-90ee-19fcc35af1af@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <UMZbYx1LhO0r-eWhohpEgw3b9V-NLCQ06jR02cl73Nk=.db6d48ae-4027-4ee5-80c5-e3f81e8ee7f7@github.com>
 <CQk_asv3R6dcRVAousvRe-NwbDw_N2-B_8g5GczwISM=.70731343-2c66-4587-90ee-19fcc35af1af@github.com>
Message-ID: <93M7cIGLivT6u6rB-zalFnL38lEFpFHigcbHvPLZeGA=.187d1a3d-7d88-44e5-a622-755e057efac5@github.com>

On Tue, 4 Oct 2022 05:45:50 GMT, Tejesh R <tr at openjdk.org> wrote:

>> You say that the current directory in `JFileChooser` gets set to `null` because of forbidden navigation to a folder which is not traversable. You avoid the NPE by a null-check.
>> 
>> However, you should prevent the current directory to be set to `null`. If navigation is not allowed, the current directory should remain unchanged _instead of being reset to `null`_.
>
> @aivanov-jdk I have updated as per the review comments. Please let me know if its fine. I have put up the mach5 test link in JBS for reference.

@TejeshR13 Verified latest fix on ubuntu and fix is working fine.

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

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


From serb at openjdk.org  Mon Oct 10 06:29:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 10 Oct 2022 06:29:51 GMT
Subject: RFR: 8295007: javax/swing/JRadioButton/4314194/bug4314194.java
 fails in mach5 for WIndowLookAndFeel
In-Reply-To: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
References: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
Message-ID: <Qw-D9DQpCuO29CoivN7_iP0GprnxTOjg7EMRao4O_7A=.eb762bf8-dd01-4936-aab7-7469b0eb6312@github.com>

On Sat, 8 Oct 2022 05:04:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JRadioButton/4314194/bug4314194.java correct color pixels pixel % varies between 30% for Metal to about 20% for Nimbus to about 19% for Windows L&F. But Nimbus in linux correct color pixel % falls to about 14%
> so adjusted % tolerance check to 10
> Also, JDK-8075916 is fixed for NimbusL&F but same issue is present for GTK L&F which is to be addressed separately as JDK-8295006 so problemlisted for now

I suggest to recheck that the final version of this change will be able to verify an initial bug.

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

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


From serb at openjdk.org  Mon Oct 10 06:36:52 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 10 Oct 2022 06:36:52 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v4]
In-Reply-To: <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@github.com>
Message-ID: <HLpFGnS30XHDe9_HAEPVR3P-sAOtuO-bR2Klt2wFjhI=.9618ae1c-7e39-4acf-b2eb-9ce55fec9f1e@github.com>

On Tue, 4 Oct 2022 08:06:24 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.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test case update

test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 67:

> 65:         //Initialize the components
> 66:         final String INSTRUCTIONS = """
> 67:                 Instructions to Test:

JFileChooser extends JComponent, probably we can create a frame with embedded JFileChooser and programmatically change the value of that "Look-In ComboBox"-> and catch an exception.

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

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


From tr at openjdk.org  Mon Oct 10 06:44:57 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 10 Oct 2022 06:44:57 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v4]
In-Reply-To: <HLpFGnS30XHDe9_HAEPVR3P-sAOtuO-bR2Klt2wFjhI=.9618ae1c-7e39-4acf-b2eb-9ce55fec9f1e@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@github.com>
 <HLpFGnS30XHDe9_HAEPVR3P-sAOtuO-bR2Klt2wFjhI=.9618ae1c-7e39-4acf-b2eb-9ce55fec9f1e@github.com>
Message-ID: <FAiLGRmjzfge1Y2lBm8aHXMe1tDdgdcvRgfUJ9Rl0mw=.732d122c-c179-4253-9728-19c0b0012519@github.com>

On Mon, 10 Oct 2022 06:32:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test case update
>
> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 67:
> 
>> 65:         //Initialize the components
>> 66:         final String INSTRUCTIONS = """
>> 67:                 Instructions to Test:
> 
> JFileChooser extends JComponent, probably we can create a frame with embedded JFileChooser and programmatically change the value of that "Look-In ComboBox"-> and catch an exception.

Means in _Test INSTRUCTIONS_ a link to `Look-In` can be attached......?

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

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


From mvs at openjdk.org  Mon Oct 10 06:55:02 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Mon, 10 Oct 2022 06:55:02 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <mb_WFScum4x3-ifE0b3VKvwXwfifLooAOv9xZCu0ans=.e8b08cbe-f6e4-47d2-a5fa-835da1f27ebe@github.com>
References: <nDQmbmLEjsXkX8ZiCHLPWIdek8QO364h84ObYSK0YdI=.6b99ed5b-6086-41bf-aa9c-df43b1bed70e@github.com>
 <mb_WFScum4x3-ifE0b3VKvwXwfifLooAOv9xZCu0ans=.e8b08cbe-f6e4-47d2-a5fa-835da1f27ebe@github.com>
Message-ID: <WFmel4UuNL0uNFXvR2IJQgn-AcjMxrZriEYyIGGRcy0=.633884c0-d888-496b-95b4-be237a2aee41@github.com>

On Fri, 7 Oct 2022 21:15:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
>> 
>> Fix:
>> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
>
> test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 148:
> 
>> 146:         try {
>> 147:             ImageIO.write(robot.createScreenCapture(
>> 148:                     new Rectangle(0, 0, screenSize.width, screenSize.height)),
> 
> This may capture the default screen while the frame is currently visible on another one.

But, is there any way we can capture the current screen where the frame is displayed?

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

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


From psadhukhan at openjdk.org  Mon Oct 10 07:21:45 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 10 Oct 2022 07:21:45 GMT
Subject: RFR: 8295007: javax/swing/JRadioButton/4314194/bug4314194.java
 fails in mach5 for WIndowLookAndFeel [v2]
In-Reply-To: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
References: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
Message-ID: <CMyBbL5erz0Zib0rA2Rd4PSi13tG4WQuNfzUlDhWQ8k=.05bf894f-dc3a-4001-9397-d4840d6f11fa@github.com>

> javax/swing/JRadioButton/4314194/bug4314194.java correct color pixels pixel % varies between 30% for Metal to about 20% for Nimbus to about 19% for Windows L&F. But Nimbus in linux correct color pixel % falls to about 14%
> so adjusted % tolerance check to 10
> Also, JDK-8075916 is fixed for NimbusL&F but same issue is present for GTK L&F which is to be addressed separately as JDK-8295006 so problemlisted for now

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

  Use full block char

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10618/files
  - new: https://git.openjdk.org/jdk/pull/10618/files/a50ad3eb..a275e607

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

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

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


From psadhukhan at openjdk.org  Mon Oct 10 07:25:52 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 10 Oct 2022 07:25:52 GMT
Subject: RFR: 8295007: javax/swing/JRadioButton/4314194/bug4314194.java
 fails in mach5 for WIndowLookAndFeel [v2]
In-Reply-To: <LsNTxLmmchMUqusNl0gWKXxWigZl8GpA0j86Qq068w8=.4163037c-ad19-40fe-b9ca-63ff7b350ddd@github.com>
References: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
 <LsNTxLmmchMUqusNl0gWKXxWigZl8GpA0j86Qq068w8=.4163037c-ad19-40fe-b9ca-63ff7b350ddd@github.com>
Message-ID: <MX7JEvDfI7Sb9RVW2zCb1mXsWILcVV9HkL-MIoUHELY=.ceb72944-57bc-434d-ae69-fa4d25d922a4@github.com>

On Sun, 9 Oct 2022 15:26:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> propose using the ?full block? character (U+2588 ?)

OK, modified...Seems good, also regression can still be tested..Have kept the tolerance same, although it could have been increased. Maybe during improvement PR....

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

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


From tr at openjdk.org  Mon Oct 10 10:01:56 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 10 Oct 2022 10:01:56 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v4]
In-Reply-To: <FAiLGRmjzfge1Y2lBm8aHXMe1tDdgdcvRgfUJ9Rl0mw=.732d122c-c179-4253-9728-19c0b0012519@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@github.com>
 <HLpFGnS30XHDe9_HAEPVR3P-sAOtuO-bR2Klt2wFjhI=.9618ae1c-7e39-4acf-b2eb-9ce55fec9f1e@github.com>
 <FAiLGRmjzfge1Y2lBm8aHXMe1tDdgdcvRgfUJ9Rl0mw=.732d122c-c179-4253-9728-19c0b0012519@github.com>
Message-ID: <SIwyX2QC_4lS1Hjl-ijQUqux0mXug9mMemLM1MOBG2U=.f1cf6ec8-95ea-4504-bd88-c306c87ed374@github.com>

On Mon, 10 Oct 2022 06:41:24 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 67:
>> 
>>> 65:         //Initialize the components
>>> 66:         final String INSTRUCTIONS = """
>>> 67:                 Instructions to Test:
>> 
>> JFileChooser extends JComponent, probably we can create a frame with embedded JFileChooser and programmatically change the value of that "Look-In ComboBox"-> and catch an exception.
>
> Means in _Test INSTRUCTIONS_ a link to `Look-In` can be attached......?

Or suggesting to make the test automatic......?

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

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


From aivanov at openjdk.org  Mon Oct 10 10:22:47 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Oct 2022 10:22:47 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v4]
In-Reply-To: <HLpFGnS30XHDe9_HAEPVR3P-sAOtuO-bR2Klt2wFjhI=.9618ae1c-7e39-4acf-b2eb-9ce55fec9f1e@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@github.com>
 <HLpFGnS30XHDe9_HAEPVR3P-sAOtuO-bR2Klt2wFjhI=.9618ae1c-7e39-4acf-b2eb-9ce55fec9f1e@github.com>
Message-ID: <iGJG-n1plA-QXx-YlFSdwy-pTCzGu4Bl_cvUuAP7dJg=.75277867-433c-48f0-a95c-ab5a327ce8aa@github.com>

On Mon, 10 Oct 2022 06:32:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test case update
>
> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 67:
> 
>> 65:         //Initialize the components
>> 66:         final String INSTRUCTIONS = """
>> 67:                 Instructions to Test:
> 
> JFileChooser extends JComponent, probably we can create a frame with embedded JFileChooser and programmatically change the value of that "Look-In ComboBox"-> and catch an exception.

@mrserb is suggesting making the test automatic. `JFileChooser` is embedded in a frame in the test. It should be possible? I'm fine with manual test though? for now.

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

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


From tr at openjdk.org  Mon Oct 10 10:26:00 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 10 Oct 2022 10:26:00 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v4]
In-Reply-To: <iGJG-n1plA-QXx-YlFSdwy-pTCzGu4Bl_cvUuAP7dJg=.75277867-433c-48f0-a95c-ab5a327ce8aa@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@github.com>
 <HLpFGnS30XHDe9_HAEPVR3P-sAOtuO-bR2Klt2wFjhI=.9618ae1c-7e39-4acf-b2eb-9ce55fec9f1e@github.com>
 <iGJG-n1plA-QXx-YlFSdwy-pTCzGu4Bl_cvUuAP7dJg=.75277867-433c-48f0-a95c-ab5a327ce8aa@github.com>
Message-ID: <uwL1xSQ2_2tFiR2QAwUdhuQlnw0qrE1gGm_8efXiApU=.1c479d23-5885-4971-bd05-7bbdc41fc069@github.com>

On Mon, 10 Oct 2022 10:19:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 67:
>> 
>>> 65:         //Initialize the components
>>> 66:         final String INSTRUCTIONS = """
>>> 67:                 Instructions to Test:
>> 
>> JFileChooser extends JComponent, probably we can create a frame with embedded JFileChooser and programmatically change the value of that "Look-In ComboBox"-> and catch an exception.
>
> @mrserb is suggesting making the test automatic. `JFileChooser` is embedded in a frame in the test. It should be possible? I'm fine with manual test though? for now.

Ok, since the test has to select non traversable folders in both windows and linux I had thought that making it as manual would be better.

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

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


From aivanov at openjdk.org  Mon Oct 10 11:32:00 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Oct 2022 11:32:00 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v4]
In-Reply-To: <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@github.com>
Message-ID: <SObB-HMVVfNr7qzO7e6jaQR_uhBCkUl1MLrI7dXG6lo=.93b6b0dc-3ca8-4b14-9bee-f4b103cf3cdd@github.com>

On Tue, 4 Oct 2022 08:06:24 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.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test case update

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 81:

> 79:         passFailJFrame = new PassFailJFrame("Test Instructions", INSTRUCTIONS, 5L, 13, 40);
> 80:         jfc = new JFileChooser();
> 81:         String path = System.getProperty("user.home");

The test does not work for me on Windows. It starts with `user.home` as the current folder as expected; when select `C:`, it goes to Desktop which is the root of the Shell namespace.

I guess, you have to change it to `System.getProperty("user.home") + File.separator + "Documents"` as you and I discussed. It'll make Desktop unreachable.

On Linux, the test works correctly.

test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 97:

> 95: 
> 96: class CustomFileView extends FileView {
> 97:     private String basePath;

Suggestion:

    private final String basePath;

test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 105:

> 103:     public Boolean isTraversable(File filePath) {
> 104:         return ((filePath != null) && (filePath.isDirectory())) &&
> 105:                 filePath.getAbsolutePath().startsWith(basePath);

Suggestion:

        return ((filePath != null) && (filePath.isDirectory()))
                && filePath.getAbsolutePath().startsWith(basePath);

I prefer wrapping before the operator, it makes it clear that it's a continuation line. Java Coding Style suggests wrapping this way.

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

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


From aivanov at openjdk.org  Mon Oct 10 11:32:00 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Oct 2022 11:32:00 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v4]
In-Reply-To: <uwL1xSQ2_2tFiR2QAwUdhuQlnw0qrE1gGm_8efXiApU=.1c479d23-5885-4971-bd05-7bbdc41fc069@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@github.com>
 <HLpFGnS30XHDe9_HAEPVR3P-sAOtuO-bR2Klt2wFjhI=.9618ae1c-7e39-4acf-b2eb-9ce55fec9f1e@github.com>
 <iGJG-n1plA-QXx-YlFSdwy-pTCzGu4Bl_cvUuAP7dJg=.75277867-433c-48f0-a95c-ab5a327ce8aa@github.com>
 <uwL1xSQ2_2tFiR2QAwUdhuQlnw0qrE1gGm_8efXiApU=.1c479d23-5885-4971-bd05-7bbdc41fc069@github.com>
Message-ID: <Tu0tvbli3VGWB5CYS6X713_c2xHSoB4BvQLekqE-n1U=.16c5c4ff-d72c-4834-842d-b59a17b5071f@github.com>

On Mon, 10 Oct 2022 10:23:58 GMT, Tejesh R <tr at openjdk.org> wrote:

>> @mrserb is suggesting making the test automatic. `JFileChooser` is embedded in a frame in the test. It should be possible? I'm fine with manual test though? for now.
>
> Ok, since the test has to select non traversable folders in both windows and linux I had thought that making it as manual would be better.

Yet you control which folders are non-traversable. Anyway? A test is better than no test; an automatic test is better than a manual one.

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

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


From aivanov at openjdk.org  Mon Oct 10 11:36:35 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Oct 2022 11:36:35 GMT
Subject: RFR: 8295007: javax/swing/JRadioButton/4314194/bug4314194.java
 fails in mach5 for WIndowLookAndFeel [v2]
In-Reply-To: <CMyBbL5erz0Zib0rA2Rd4PSi13tG4WQuNfzUlDhWQ8k=.05bf894f-dc3a-4001-9397-d4840d6f11fa@github.com>
References: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
 <CMyBbL5erz0Zib0rA2Rd4PSi13tG4WQuNfzUlDhWQ8k=.05bf894f-dc3a-4001-9397-d4840d6f11fa@github.com>
Message-ID: <Ekk4WxT95ejfk_KmBggLlSRdPX0CLgo1Y5a3Fs3mmpU=.39618910-7c0d-4109-87f7-c854083d3b0b@github.com>

On Mon, 10 Oct 2022 07:21:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> javax/swing/JRadioButton/4314194/bug4314194.java correct color pixels pixel % varies between 30% for Metal to about 20% for Nimbus to about 19% for Windows L&F. But Nimbus in linux correct color pixel % falls to about 14%
>> so adjusted % tolerance check to 10
>> Also, JDK-8075916 is fixed for NimbusL&F but same issue is present for GTK L&F which is to be addressed separately as JDK-8295006 so problemlisted for now
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use full block char

Looks good to me.

The only question is the value of `tolerance`: the original one vs. the updated one.

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

Marked as reviewed by aivanov (Reviewer).

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


From aivanov at openjdk.org  Mon Oct 10 11:36:36 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Oct 2022 11:36:36 GMT
Subject: RFR: 8295007: javax/swing/JRadioButton/4314194/bug4314194.java
 fails in mach5 for WIndowLookAndFeel [v2]
In-Reply-To: <MX7JEvDfI7Sb9RVW2zCb1mXsWILcVV9HkL-MIoUHELY=.ceb72944-57bc-434d-ae69-fa4d25d922a4@github.com>
References: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
 <LsNTxLmmchMUqusNl0gWKXxWigZl8GpA0j86Qq068w8=.4163037c-ad19-40fe-b9ca-63ff7b350ddd@github.com>
 <MX7JEvDfI7Sb9RVW2zCb1mXsWILcVV9HkL-MIoUHELY=.ceb72944-57bc-434d-ae69-fa4d25d922a4@github.com>
Message-ID: <coFLXdqGnXZco1qbl45QIkbEAL0Ye866cViDGGoOOAk=.e109f94f-47f6-4093-a236-4dd02eb60118@github.com>

On Mon, 10 Oct 2022 07:21:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Have kept the tolerance same

You've kept the updated value of 10 compared to the original one of 20.

I propose keeping 20 as it was before. The use of the ?full block? character ensures there are many pixels of the correct color.

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

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


From aivanov at openjdk.org  Mon Oct 10 11:36:37 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Oct 2022 11:36:37 GMT
Subject: RFR: 8295007: javax/swing/JRadioButton/4314194/bug4314194.java
 fails in mach5 for WIndowLookAndFeel
In-Reply-To: <Qw-D9DQpCuO29CoivN7_iP0GprnxTOjg7EMRao4O_7A=.eb762bf8-dd01-4936-aab7-7469b0eb6312@github.com>
References: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
 <Qw-D9DQpCuO29CoivN7_iP0GprnxTOjg7EMRao4O_7A=.eb762bf8-dd01-4936-aab7-7469b0eb6312@github.com>
Message-ID: <epzEvNMUs4dlnz6ZnqiTXkfyFFLB1O51h0UIZr_l-U8=.6ae79916-7306-4cab-b8b9-b4a66bb0b520@github.com>

On Mon, 10 Oct 2022 06:27:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I suggest to recheck that the final version of this change will be able to verify an initial bug.

I believe this is implied, isn't it?

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

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


From psadhukhan at openjdk.org  Mon Oct 10 11:54:33 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 10 Oct 2022 11:54:33 GMT
Subject: RFR: 8295007: javax/swing/JRadioButton/4314194/bug4314194.java
 fails in mach5 for WIndowLookAndFeel [v2]
In-Reply-To: <CMyBbL5erz0Zib0rA2Rd4PSi13tG4WQuNfzUlDhWQ8k=.05bf894f-dc3a-4001-9397-d4840d6f11fa@github.com>
References: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
 <CMyBbL5erz0Zib0rA2Rd4PSi13tG4WQuNfzUlDhWQ8k=.05bf894f-dc3a-4001-9397-d4840d6f11fa@github.com>
Message-ID: <NiLD4I80Y7qx3apFLUpYMOqIjyEzZjtOfF6Mt8-CWSY=.bd128ebb-5b19-4869-a028-ca2d846dfd17@github.com>

On Mon, 10 Oct 2022 07:21:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> javax/swing/JRadioButton/4314194/bug4314194.java correct color pixels pixel % varies between 30% for Metal to about 20% for Nimbus to about 19% for Windows L&F. But Nimbus in linux correct color pixel % falls to about 14%
>> so adjusted % tolerance check to 10
>> Also, JDK-8075916 is fixed for NimbusL&F but same issue is present for GTK L&F which is to be addressed separately as JDK-8295006 so problemlisted for now
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use full block char

Tolerance has been kept same as in the original closed test

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

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


From aivanov at openjdk.org  Mon Oct 10 11:54:34 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Oct 2022 11:54:34 GMT
Subject: RFR: 8295007: javax/swing/JRadioButton/4314194/bug4314194.java
 fails in mach5 for WIndowLookAndFeel [v2]
In-Reply-To: <NiLD4I80Y7qx3apFLUpYMOqIjyEzZjtOfF6Mt8-CWSY=.bd128ebb-5b19-4869-a028-ca2d846dfd17@github.com>
References: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
 <CMyBbL5erz0Zib0rA2Rd4PSi13tG4WQuNfzUlDhWQ8k=.05bf894f-dc3a-4001-9397-d4840d6f11fa@github.com>
 <NiLD4I80Y7qx3apFLUpYMOqIjyEzZjtOfF6Mt8-CWSY=.bd128ebb-5b19-4869-a028-ca2d846dfd17@github.com>
Message-ID: <_3vinG8gnVJQ_pRv1mBds2iArGBF56-BycfEG22Fdx0=.1f5f0a03-f7a0-4d0a-b0d1-288bd9d00969@github.com>

On Mon, 10 Oct 2022 11:50:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Tolerance has been kept same as in the original closed test

Yes, I'm sorry I didn't notice that change has been removed. Thank you.

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

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


From psadhukhan at openjdk.org  Mon Oct 10 11:54:36 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 10 Oct 2022 11:54:36 GMT
Subject: Integrated: 8295007: javax/swing/JRadioButton/4314194/bug4314194.java
 fails in mach5 for WIndowLookAndFeel
In-Reply-To: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
References: <q9Alfc4-4puMvPLWaccWaA3XmIBBR1B3sZMmEoGYTFc=.0440d2bb-45b4-457f-aec9-af8f62b786ed@github.com>
Message-ID: <ZOvPug4qLm9rjnJS4LqqIuBalZ-IhTXRWQ4Gvulv_3M=.b5c9d061-0dbf-4ebb-b5c2-01c80298e1a0@github.com>

On Sat, 8 Oct 2022 05:04:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JRadioButton/4314194/bug4314194.java correct color pixels pixel % varies between 30% for Metal to about 20% for Nimbus to about 19% for Windows L&F. But Nimbus in linux correct color pixel % falls to about 14%
> so adjusted % tolerance check to 10
> Also, JDK-8075916 is fixed for NimbusL&F but same issue is present for GTK L&F which is to be addressed separately as JDK-8295006 so problemlisted for now

This pull request has now been integrated.

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

8295007: javax/swing/JRadioButton/4314194/bug4314194.java fails in mach5 for WIndowLookAndFeel

Reviewed-by: aivanov, tr

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

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


From aivanov at openjdk.org  Mon Oct 10 12:12:52 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Oct 2022 12:12:52 GMT
Subject: RFR: 8295026: Remove unused fields in StyleSheet
In-Reply-To: <9p71hu-CpTJ6dsy_0j2Rnks8TX7m4jyIgyGpeo8l18k=.9cfe4931-2d55-4ad8-bf67-78c05a13d7b7@github.com>
References: <9p71hu-CpTJ6dsy_0j2Rnks8TX7m4jyIgyGpeo8l18k=.9cfe4931-2d55-4ad8-bf67-78c05a13d7b7@github.com>
Message-ID: <kwgX2S5xMGTbn7P8u3k8vbq4pWQXUpKmE2kqspu_dZI=.9650ee44-378b-4b64-84a7-dfc898061a58@github.com>

On Sat, 1 Oct 2022 17:05:11 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There are 3 unused fields in single `StyleSheet` file:
> 1. `static final Border noBorder = new EmptyBorder(0,0,0,0);`
> 2. `static final int DEFAULT_FONT_SIZE = 3;`
> 3. `URL imageurl;` in nested `javax.swing.text.html.StyleSheet.ListPainter` class

Looks good to me.

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

Marked as reviewed by aivanov (Reviewer).

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


From aivanov at openjdk.org  Mon Oct 10 12:19:52 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Oct 2022 12:19:52 GMT
Subject: RFR: 8295003: Do not mention applets in the "java.awt.color"
 package
In-Reply-To: <-5VrLrHDBrYLd9a67snxU5jQYywXQmaKh8o702F0mY0=.dc60f1ff-40a1-4427-b5cc-e872f2cf44bb@github.com>
References: <-5VrLrHDBrYLd9a67snxU5jQYywXQmaKh8o702F0mY0=.dc60f1ff-40a1-4427-b5cc-e872f2cf44bb@github.com>
Message-ID: <OVzYwBLekLCjX38noEkgug0UV-rME9DAnohcr-VJxjM=.975296f1-c06c-4b53-9a6f-f2062770fe5e@github.com>

On Fri, 7 Oct 2022 23:18:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The usage of "applets" are replaced by the "applications" in the "java.awt.color" package.
> If there are no objections I'll skip the CSR for this small cleanup.

Looks good to me.

As for CSR, applets are deprecated, it looks fine to me to remove the reference to them. Yet I suggest that you wait for other opinions.

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

Marked as reviewed by aivanov (Reviewer).

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


From tr at openjdk.org  Mon Oct 10 13:58:30 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 10 Oct 2022 13:58:30 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v5]
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: <k7YbI_DPpnwcd2vC4P2KDJV2-yMhyKsb8iei_QB1E5U=.705e00c0-d168-4b99-b641-ce56c5552e4c@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/62f6c307..11a697ea

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

  Stats: 4 lines in 1 file changed: 0 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  Mon Oct 10 13:58:35 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 10 Oct 2022 13:58:35 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v4]
In-Reply-To: <SObB-HMVVfNr7qzO7e6jaQR_uhBCkUl1MLrI7dXG6lo=.93b6b0dc-3ca8-4b14-9bee-f4b103cf3cdd@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@github.com>
 <SObB-HMVVfNr7qzO7e6jaQR_uhBCkUl1MLrI7dXG6lo=.93b6b0dc-3ca8-4b14-9bee-f4b103cf3cdd@github.com>
Message-ID: <pPJawvVKHTlmncqeStK8CMr7DAOEFAEwrHMdFk-1Dls=.8cc16953-7e13-43f7-b3c5-855b33fa070c@github.com>

On Mon, 10 Oct 2022 11:24:43 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test case update
>
> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 81:
> 
>> 79:         passFailJFrame = new PassFailJFrame("Test Instructions", INSTRUCTIONS, 5L, 13, 40);
>> 80:         jfc = new JFileChooser();
>> 81:         String path = System.getProperty("user.home");
> 
> The test does not work for me on Windows. It starts with `user.home` as the current folder as expected; when select `C:`, it goes to Desktop which is the root of the Shell namespace.
> 
> I guess, you have to change it to `System.getProperty("user.home") + File.separator + "Documents"` as you and I discussed. It'll make Desktop unreachable.
> 
> On Linux, the test works correctly.

Updated.

> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 97:
> 
>> 95: 
>> 96: class CustomFileView extends FileView {
>> 97:     private String basePath;
> 
> Suggestion:
> 
>     private final String basePath;

Updated.

> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 105:
> 
>> 103:     public Boolean isTraversable(File filePath) {
>> 104:         return ((filePath != null) && (filePath.isDirectory())) &&
>> 105:                 filePath.getAbsolutePath().startsWith(basePath);
> 
> Suggestion:
> 
>         return ((filePath != null) && (filePath.isDirectory()))
>                 && filePath.getAbsolutePath().startsWith(basePath);
> 
> I prefer wrapping before the operator, it makes it clear that it's a continuation line. Java Coding Style suggests wrapping this way.

Updated.

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

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


From aivanov at openjdk.org  Mon Oct 10 16:29:42 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Oct 2022 16:29:42 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v5]
In-Reply-To: <k7YbI_DPpnwcd2vC4P2KDJV2-yMhyKsb8iei_QB1E5U=.705e00c0-d168-4b99-b641-ce56c5552e4c@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <k7YbI_DPpnwcd2vC4P2KDJV2-yMhyKsb8iei_QB1E5U=.705e00c0-d168-4b99-b641-ce56c5552e4c@github.com>
Message-ID: <XoHEPY8weCtfKDLlRckCfy-osAVENh2hX_zcHrs_ITE=.548e7349-0048-46f2-bf0b-cbd60ee4b62d@github.com>

On Mon, 10 Oct 2022 13:58:30 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.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 35:

> 33: 
> 34: import javax.swing.filechooser.FileView;
> 35: import jdk.test.lib.Platform;

It's not used any more, please remove.

Leave one blank line after the last import and the following comment with the jtreg tags.

test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 42:

> 40:  * @requires (os.family == "windows" | os.family == "linux")
> 41:  * @library /java/awt/regtesthelpers /test/lib
> 42:  * @build PassFailJFrame jdk.test.lib.Platform

Suggestion:

 * @library /java/awt/regtesthelpers
 * @build PassFailJFrame


`Platform` class from `/test/lib` is not used any more.

test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 65:

> 63:         JFileChooser jfc;
> 64: 
> 65:         //Initialize the components

I believe the comment is redundant. Being placed before the instruction text, it's confusing. The method name `initialize` is self-explanatory.

test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 77:

> 75:                 3. If NPE occurs on second selection then test FAILS, else test
> 76:                  is PASS.
> 77:                 """;

I propose the following text:


                Instructions to Test:
                1. The traversable folder is set to the Documents folder,
                 if it exists, in the user's home folder, otherwise
                 it's the user's home. Other folders are non-traversable.
                2. When the file chooser appears on the screen, select any
                 non-traversable folder from "Look-In" combo box,
                 for example the user's folder or a folder above it.
                 (The folder will not be opened since it's non-traversable).
                3. Select the Documents folder again.
                4. If NullPointerException occurs in the step 3, click Fail,
                 otherwise click Pass.

It consistently uses _?folder?_, no mention of ?directory?. It explains that the user's home could be the root of the traversable tree. The instructions use imperative to select either _Fail_ or _Pass_.

test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 81:

> 79:         passFailJFrame = new PassFailJFrame("Test Instructions", INSTRUCTIONS, 5L, 13, 40);
> 80:         jfc = new JFileChooser();
> 81:         String path = System.getProperty("user.home") + File.separator + "Documents";

Suggestion:


        String userHome = System.getProperty("user.home");
        String docs = userHome + File.separator + "Documents";
        String path = (new File(docs).exists()) ? docs : userHome;

This will make the test more robust, it can continue to run even if `Documents` folder does not exist.

test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 84:

> 82: 
> 83:         jfc.setCurrentDirectory(new File(path));
> 84:         jfc.setFileView(new CustomFileView(path));

Suggestion:

        jfc.setFileView(new CustomFileView(path));
        jfc.setControlButtonsAreShown(false);

Hide _Open_ and _Cancel_ buttons in the file chooser.

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

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


From aivanov at openjdk.org  Mon Oct 10 16:29:45 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Oct 2022 16:29:45 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <NFqU4oxo-9fiYaS3Lvdn3xFdHtj4PV1ikw3bj455gxQ=.4cb1bfb3-8bc6-47a6-8e55-dd791c719fa4@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <hhovPbK-E9zFYe8naRtdI0KrJNjieKGKklq8qW1ygY4=.f4ae4916-f4b0-432d-a5f6-02ef66edd307@github.com>
 <NFqU4oxo-9fiYaS3Lvdn3xFdHtj4PV1ikw3bj455gxQ=.4cb1bfb3-8bc6-47a6-8e55-dd791c719fa4@github.com>
Message-ID: <UqrobmjXWb8o1KBWydL6ct_RblQvTdus_kMW1Id9gbY=.3b6e55f6-b5d5-4abe-9b2f-4fc519f2a494@github.com>

On Mon, 3 Oct 2022 16:33:59 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 40:
>> 
>>> 38:  * @bug 6616245
>>> 39:  * @key headful
>>> 40:  * @requires (os.family == "windows" | os.family == "linux")
>> 
>> Is there a specific reason to exclude macOS? Is it only because the default L&F isn't Metal?
>
> Yeah, was not able to reproduce in macOS.

You can set Metal L&F explicitly on macOS.

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

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


From tr at openjdk.org  Mon Oct 10 16:36:54 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 10 Oct 2022 16:36:54 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v5]
In-Reply-To: <XoHEPY8weCtfKDLlRckCfy-osAVENh2hX_zcHrs_ITE=.548e7349-0048-46f2-bf0b-cbd60ee4b62d@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <k7YbI_DPpnwcd2vC4P2KDJV2-yMhyKsb8iei_QB1E5U=.705e00c0-d168-4b99-b641-ce56c5552e4c@github.com>
 <XoHEPY8weCtfKDLlRckCfy-osAVENh2hX_zcHrs_ITE=.548e7349-0048-46f2-bf0b-cbd60ee4b62d@github.com>
Message-ID: <6-2jJdaYubAdgfgVO53efiFDYOFTgYI7NWAmIg-3p-E=.31f1ae77-7327-4f11-b329-b2f6f130875e@github.com>

On Mon, 10 Oct 2022 16:17:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 42:
> 
>> 40:  * @requires (os.family == "windows" | os.family == "linux")
>> 41:  * @library /java/awt/regtesthelpers /test/lib
>> 42:  * @build PassFailJFrame jdk.test.lib.Platform
> 
> Suggestion:
> 
>  * @library /java/awt/regtesthelpers
>  * @build PassFailJFrame
> 
> 
> `Platform` class from `/test/lib` is not used any more.

In mac the issue was not reproducible.....

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

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


From tr at openjdk.org  Mon Oct 10 16:52:48 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 10 Oct 2022 16:52:48 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v6]
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: <umg-Fh9k6EZ375NrIwkafUa9NfJPDbp-Ry36z467Prc=.27ded4c7-797b-4c24-bf6b-a67cd7df1a8a@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/11a697ea..cbc3ba1e

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

  Stats: 17 lines in 1 file changed: 4 ins; 0 del; 13 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  Mon Oct 10 16:52:54 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 10 Oct 2022 16:52:54 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v5]
In-Reply-To: <XoHEPY8weCtfKDLlRckCfy-osAVENh2hX_zcHrs_ITE=.548e7349-0048-46f2-bf0b-cbd60ee4b62d@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <k7YbI_DPpnwcd2vC4P2KDJV2-yMhyKsb8iei_QB1E5U=.705e00c0-d168-4b99-b641-ce56c5552e4c@github.com>
 <XoHEPY8weCtfKDLlRckCfy-osAVENh2hX_zcHrs_ITE=.548e7349-0048-46f2-bf0b-cbd60ee4b62d@github.com>
Message-ID: <kDL8hzd6cnFDmT78euNNrrsASnZwpCUATjzeSOpDi3c=.d58bcd2c-9504-470f-817f-ace816006ddf@github.com>

On Mon, 10 Oct 2022 16:14:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 35:
> 
>> 33: 
>> 34: import javax.swing.filechooser.FileView;
>> 35: import jdk.test.lib.Platform;
> 
> It's not used any more, please remove.
> 
> Leave one blank line after the last import and the following comment with the jtreg tags.

Updated.

> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 65:
> 
>> 63:         JFileChooser jfc;
>> 64: 
>> 65:         //Initialize the components
> 
> I believe the comment is redundant. Being placed before the instruction text, it's confusing. The method name `initialize` is self-explanatory.

Updated.

> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 77:
> 
>> 75:                 3. If NPE occurs on second selection then test FAILS, else test
>> 76:                  is PASS.
>> 77:                 """;
> 
> I propose the following text:
> 
> 
>                 Instructions to Test:
>                 1. The traversable folder is set to the Documents folder,
>                  if it exists, in the user's home folder, otherwise
>                  it's the user's home. Other folders are non-traversable.
>                 2. When the file chooser appears on the screen, select any
>                  non-traversable folder from "Look-In" combo box,
>                  for example the user's folder or a folder above it.
>                  (The folder will not be opened since it's non-traversable).
>                 3. Select the Documents folder again.
>                 4. If NullPointerException occurs in the step 3, click Fail,
>                  otherwise click Pass.
> 
> It consistently uses _?folder?_, no mention of ?directory?. It explains that the user's home could be the root of the traversable tree. The instructions use imperative to select either _Fail_ or _Pass_.

4th point has been modified, since user can only select Pass, otherwise the test itself fails.

> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 81:
> 
>> 79:         passFailJFrame = new PassFailJFrame("Test Instructions", INSTRUCTIONS, 5L, 13, 40);
>> 80:         jfc = new JFileChooser();
>> 81:         String path = System.getProperty("user.home") + File.separator + "Documents";
> 
> Suggestion:
> 
> 
>         String userHome = System.getProperty("user.home");
>         String docs = userHome + File.separator + "Documents";
>         String path = (new File(docs).exists()) ? docs : userHome;
> 
> This will make the test more robust, it can continue to run even if `Documents` folder does not exist.

Updated.

> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 84:
> 
>> 82: 
>> 83:         jfc.setCurrentDirectory(new File(path));
>> 84:         jfc.setFileView(new CustomFileView(path));
> 
> Suggestion:
> 
>         jfc.setFileView(new CustomFileView(path));
>         jfc.setControlButtonsAreShown(false);
> 
> Hide _Open_ and _Cancel_ buttons in the file chooser.

Updated.

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

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


From prappo at openjdk.org  Mon Oct 10 16:57:21 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 10 Oct 2022 16:57:21 GMT
Subject: Integrated: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited
In-Reply-To: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
Message-ID: <5x7fG0iSo2qnkGEPeTumleeWMpV15E_qSXdIrdVHoUY=.369c8b00-4a6e-4f50-9ca7-62be5556be8e@github.com>

On Tue, 27 Sep 2022 11:43:08 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.

This pull request has now been integrated.

Changeset: eb90c4fc
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb90c4fc0479379c8c1452afca8f37746c762e18
Stats:     320 lines in 14 files changed: 310 ins; 0 del; 10 mod

8294377: Prepare to stop auto-inheriting documentation for subclasses of exceptions whose documentation is inherited

Reviewed-by: jjg

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

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


From serb at openjdk.org  Mon Oct 10 18:02:52 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 10 Oct 2022 18:02:52 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <WFmel4UuNL0uNFXvR2IJQgn-AcjMxrZriEYyIGGRcy0=.633884c0-d888-496b-95b4-be237a2aee41@github.com>
References: <nDQmbmLEjsXkX8ZiCHLPWIdek8QO364h84ObYSK0YdI=.6b99ed5b-6086-41bf-aa9c-df43b1bed70e@github.com>
 <mb_WFScum4x3-ifE0b3VKvwXwfifLooAOv9xZCu0ans=.e8b08cbe-f6e4-47d2-a5fa-835da1f27ebe@github.com>
 <WFmel4UuNL0uNFXvR2IJQgn-AcjMxrZriEYyIGGRcy0=.633884c0-d888-496b-95b4-be237a2aee41@github.com>
Message-ID: <iJNhPcRH6O3ARrmFyiTfpbsUbTlEwmZU6gbW-rCcptk=.866654ba-697b-4602-8f3c-2e19d9e34168@github.com>

On Mon, 10 Oct 2022 06:50:41 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 148:
>> 
>>> 146:         try {
>>> 147:             ImageIO.write(robot.createScreenCapture(
>>> 148:                     new Rectangle(0, 0, screenSize.width, screenSize.height)),
>> 
>> This may capture the default screen while the frame is currently visible on another one.
>
> But, is there any way we can capture the current screen where the frame is displayed?

You can pass coordinates/bounds of that screen to the createScreenCapture.

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

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


From dnguyen at openjdk.org  Mon Oct 10 18:41:24 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Oct 2022 18:41:24 GMT
Subject: RFR: 8294254: [macOS]
 javax/swing/plaf/aqua/CustomComboBoxFocusTest.java failure [v2]
In-Reply-To: <XmBIB7o0eNNj0Pq2udzXOSo0DtC0rO9s9bEqJSOJVx8=.64ffb7a6-0498-41b9-95ad-172b165826c3@github.com>
References: <XmBIB7o0eNNj0Pq2udzXOSo0DtC0rO9s9bEqJSOJVx8=.64ffb7a6-0498-41b9-95ad-172b165826c3@github.com>
Message-ID: <AcQY1jED4CA6__TIdnit-sElejd1aDSIrOAG96_D8-E=.bfd71671-273b-4572-b405-0b898415a079@github.com>

> The previous change to AquaComboBoxUI had 1 pixel of overlap between the text field and the combo button. This caused a few pixels to darken sometimes when an editable combobox is displayed. Since this test passes sometimes and fails some other times, it was not initially detected.
> 
> Since these few darkening pixels occur due to the change in AquaComboBoxUI, no reasonable change to the test could really be made, and the change would need to be to the class for the combobox. This fix was tested with a high count repeat and no failures occurred for various macOS systems.
> 
> Also removing the test from the problem list.

Damon Nguyen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into 8294254/overlapFixEditableCombobox
 - Merge branch 'openjdk:master' into 8294254/overlapFixEditableCombobox
 - Remove test from problem list
 - Adjust rect width to remove overlap

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

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

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


From aivanov at openjdk.org  Mon Oct 10 18:47:57 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Oct 2022 18:47:57 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v6]
In-Reply-To: <umg-Fh9k6EZ375NrIwkafUa9NfJPDbp-Ry36z467Prc=.27ded4c7-797b-4c24-bf6b-a67cd7df1a8a@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <umg-Fh9k6EZ375NrIwkafUa9NfJPDbp-Ry36z467Prc=.27ded4c7-797b-4c24-bf6b-a67cd7df1a8a@github.com>
Message-ID: <xPL-AM_Y5dV1CCUUI9p77NeAQQcL0YtUJV67Tq2EjTw=.dd51540d-2992-4aaf-8797-5fdf81e9a951@github.com>

On Mon, 10 Oct 2022 16:52:48 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.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Looks good to me now.

test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 82:

> 80:         passFailJFrame = new PassFailJFrame("Test Instructions", INSTRUCTIONS, 5L, 13, 40);
> 81:         jfc = new JFileChooser();
> 82:         String userHome = System.getProperty("user.home");

I prefer a blank line here to logically separate dealing with paths from creating the components. But it's a nit.

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

Marked as reviewed by aivanov (Reviewer).

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


From honkar at openjdk.org  Mon Oct 10 19:10:05 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 10 Oct 2022 19:10:05 GMT
Subject: RFR: 8294254: [macOS]
 javax/swing/plaf/aqua/CustomComboBoxFocusTest.java failure [v2]
In-Reply-To: <AcQY1jED4CA6__TIdnit-sElejd1aDSIrOAG96_D8-E=.bfd71671-273b-4572-b405-0b898415a079@github.com>
References: <XmBIB7o0eNNj0Pq2udzXOSo0DtC0rO9s9bEqJSOJVx8=.64ffb7a6-0498-41b9-95ad-172b165826c3@github.com>
 <AcQY1jED4CA6__TIdnit-sElejd1aDSIrOAG96_D8-E=.bfd71671-273b-4572-b405-0b898415a079@github.com>
Message-ID: <hvtPJEr2r9rFYXp6mZpeG9L91i0tfd2vE5Ctu4wtgUQ=.da27ce6c-b850-48ef-b21a-a0a24737f413@github.com>

On Mon, 10 Oct 2022 18:41:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The previous change to AquaComboBoxUI had 1 pixel of overlap between the text field and the combo button. This caused a few pixels to darken sometimes when an editable combobox is displayed. Since this test passes sometimes and fails some other times, it was not initially detected.
>> 
>> Since these few darkening pixels occur due to the change in AquaComboBoxUI, no reasonable change to the test could really be made, and the change would need to be to the class for the combobox. This fix was tested with a high count repeat and no failures occurred for various macOS systems.
>> 
>> Also removing the test from the problem list.
>
> Damon Nguyen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into 8294254/overlapFixEditableCombobox
>  - Merge branch 'openjdk:master' into 8294254/overlapFixEditableCombobox
>  - Remove test from problem list
>  - Adjust rect width to remove overlap

Suggestion: Does running the test - CustomComboBoxFocusTest.java with uiScale always set to 1 make it more robust?

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

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


From alexey.ivanov at oracle.com  Mon Oct 10 21:03:07 2022
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Mon, 10 Oct 2022 22:03:07 +0100
Subject: professional (24-bit) sampled audio support in the Windows native
 implementation of libjsound
In-Reply-To: <028e01d8dbef$69b25070$3d16f150$@gmail.com>
References: <02e901d8d4c0$7dd12ee0$79738ca0$@gmail.com>
 <506f19c5-28ae-e606-e7f1-22464793afcb@oracle.com>
 <028e01d8dbef$69b25070$3d16f150$@gmail.com>
Message-ID: <5ca697e2-fd4f-8a4b-9f98-b536ed5bb2a7@oracle.com>

Hi,

JDK-8294904 [1] was resolved as Incomplete because there's no sample 
code which demonstrates the problem. A comment was added:

Mail to submitter:
=============
Please share standalone test case/ reproducible step/ scenario to 
analyze the issue better.

I should have received an email with request for clarification.

I looked through the description but it's still unclear to me how to 
reproduce the problem and how to incorporate the fix you're proposing 
and what the fix is. If you could provide the test case and better yet 
the fix along with a regression test, it would be greatly appreciated.

The fix in the form of the diff would also help.

-- 
Regards,
Alexey

[1] https://bugs.openjdk.org/browse/JDK-8294904

On 09/10/2022 15:57, magare31 at gmail.com wrote:
>
> Since I am new to this, and apologies for the broad email, could 
> someone explain the following for the corresponding bug (JDK-8294904)?
>
>   * This bug is listed as one for a generic OS, whereas I specified
>     Windows (I can confirm that it is Windows only).
>   * This bug is listed as "resolved" with an "incomplete resolution".
>     ?I did provide the full solution, so I am not sure what this
>     means. ?(Also, Oracle asked for a standalone test, which I also
>     provided over email)
>
> And thanks.
>
> *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 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/20221010/715afcf0/attachment.htm>

From prr at openjdk.org  Mon Oct 10 23:51:21 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 10 Oct 2022 23:51:21 GMT
Subject: RFR: 8295003: Do not mention applets in the "java.awt.color"
 package
In-Reply-To: <-5VrLrHDBrYLd9a67snxU5jQYywXQmaKh8o702F0mY0=.dc60f1ff-40a1-4427-b5cc-e872f2cf44bb@github.com>
References: <-5VrLrHDBrYLd9a67snxU5jQYywXQmaKh8o702F0mY0=.dc60f1ff-40a1-4427-b5cc-e872f2cf44bb@github.com>
Message-ID: <lBkPZperJftu5PmY5Uxu5iWxedghv2SXPILFCyzpksc=.5dc35b12-4b58-4c4e-997d-22bba03ed697@github.com>

On Fri, 7 Oct 2022 23:18:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The usage of "applets" are replaced by the "applications" in the "java.awt.color" package.
> If there are no objections I'll skip the CSR for this small cleanup.

It sounds fine to me.

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

Marked as reviewed by prr (Reviewer).

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


From dnguyen at openjdk.org  Tue Oct 11 00:27:35 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 11 Oct 2022 00:27:35 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0
In-Reply-To: <BR-jEkqs-cfBcLbYOIochka2ttiiXyyeVEbWMXq-ZPY=.d124a284-b194-4cf5-b4f5-8faf6c7a5856@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
 <xSKq7POrfrJ4KYYBA8crdY5rJCjciMK4NEK-LZTcjDk=.8161df0a-2d8c-4784-948b-b7632af2d7e0@github.com>
 <2JMfR5LPnaps6mypICTmVJ06Wvz-aM8TZCUCGFtPfRI=.a2f95c1a-08e4-484d-b9bd-d2e2de8b7a93@github.com>
 <BR-jEkqs-cfBcLbYOIochka2ttiiXyyeVEbWMXq-ZPY=.d124a284-b194-4cf5-b4f5-8faf6c7a5856@github.com>
Message-ID: <u_xoruMy7Z4J9sy0zrJbeBiolJq0DhzjlheR92GXRSQ=.c28a5857-7d6e-468f-b342-38a4b50df6dc@github.com>

On Thu, 6 Oct 2022 15:04:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > 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.....?
> > 
> > 
> > I second this. The test can sit inside the Multiscreen folder without the need for a subfolder to match the way new tests are added.
> 
> I prefer leaving the test at its original location. It's not a new test, it has a history in CI. Although, if everyone else thinks the test should be moved up, it's okay with me.
> 
> Previously, each test had its own folder. Now, we tend to use flatter structure.

If that's the case, I have nothing else against keeping it in its current location. I had the impression to update tests (such as syntax) as they're updated, but I can understand why updating its location may be useful.

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

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


From serb at openjdk.org  Tue Oct 11 00:44:35 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Oct 2022 00:44:35 GMT
Subject: Integrated: 8295003: Do not mention applets in the "java.awt.color"
 package
In-Reply-To: <-5VrLrHDBrYLd9a67snxU5jQYywXQmaKh8o702F0mY0=.dc60f1ff-40a1-4427-b5cc-e872f2cf44bb@github.com>
References: <-5VrLrHDBrYLd9a67snxU5jQYywXQmaKh8o702F0mY0=.dc60f1ff-40a1-4427-b5cc-e872f2cf44bb@github.com>
Message-ID: <sWpV0pXWMs10DnYknRJO1GYmv-BeMCJaG6p17WWykLw=.c346dedc-b9de-4ecc-84e1-9a79e2ff42bf@github.com>

On Fri, 7 Oct 2022 23:18:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The usage of "applets" are replaced by the "applications" in the "java.awt.color" package.
> If there are no objections I'll skip the CSR for this small cleanup.

This pull request has now been integrated.

Changeset: 891156a7
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/891156a744e706e2d8da5082b2ee3e63ff6fab76
Stats:     9 lines in 2 files changed: 0 ins; 0 del; 9 mod

8295003: Do not mention applets in the "java.awt.color" package

Reviewed-by: aivanov, prr

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

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


From serb at openjdk.org  Tue Oct 11 01:40:21 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Oct 2022 01:40:21 GMT
Subject: RFR: 8293984: Unnecessary Vector usage in PropertyEditorSupport
 [v2]
In-Reply-To: <J7xW-Dl35eoSTiFcXmgmN3eJ00x9D0T_-4D6_5a1A7o=.f20be004-1612-4ee4-a9a8-a9e780936129@github.com>
References: <d_Iu8wlX0aPiKtfN2F6okrdy8lyeM8zzG8F8Dett58E=.1bfbea3a-8bd1-4b46-8f14-8a860049081f@github.com>
 <J7xW-Dl35eoSTiFcXmgmN3eJ00x9D0T_-4D6_5a1A7o=.f20be004-1612-4ee4-a9a8-a9e780936129@github.com>
Message-ID: <EUwZamA1LQdGyb2uR-ZmSVEvwJXK9qk66qdY0sjKpHg=.57f676bc-b5fc-41ef-8994-5183719b3402@github.com>

On Sun, 9 Oct 2022 21:03:52 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Field PropertyEditorSupport.listeners is accessed only under `synchronized(this)`.
>> It means extra synchronization by Vector is not needed.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293984: Unnecessary Vector usage in PropertyEditorSupport
>   
>   use ArrayList constructor instead of clone

Marked as reviewed by serb (Reviewer).

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

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


From philip.race at oracle.com  Tue Oct 11 02:21:28 2022
From: philip.race at oracle.com (Philip Race)
Date: Mon, 10 Oct 2022 19:21:28 -0700
Subject: professional (24-bit) sampled audio support in the Windows native
 implementation of libjsound
In-Reply-To: <5ca697e2-fd4f-8a4b-9f98-b536ed5bb2a7@oracle.com>
References: <02e901d8d4c0$7dd12ee0$79738ca0$@gmail.com>
 <506f19c5-28ae-e606-e7f1-22464793afcb@oracle.com>
 <028e01d8dbef$69b25070$3d16f150$@gmail.com>
 <5ca697e2-fd4f-8a4b-9f98-b536ed5bb2a7@oracle.com>
Message-ID: <0de52bab-dab9-a536-bd15-0df2b69f28a9@oracle.com>

So Magare (what is your actual name ?),

As admin for this list I saw your? latest email but due to size etc it 
was rejected by OpenJDK mail servers.
I don't think I can do anything about that. In fact it wasn't even a 
patch. It was a full copy of a file.
And I believe you misunderstood that Alexey was quoting what you should 
have sent in reply
to the person who is triaging your bug submission. NOT to be sent to 
this list. Go look in your inbox+spam.

Regardless OpenJDK does not take patches in email.
They need to be github PRs *after* following process below.

Have you read the OpenJDK Developer's Guide ? https://openjdk.org/guide/

Start here https://openjdk.org/guide/#contributing-to-an-openjdk-project
and make sure to sign and return the OCA mentioned there.

The OCA must be accepted in order to take code from you.

Do you have a github account ? You'll need one and it'll have to be 
linked to an approved OCA.
You can then submit a PR against https://github.com/openjdk/jdk

I can help you "sponsor" this change, but you need to absorb the process 
and do the OCA first.

-phil.


On 10/10/22 2:03 PM, Aleksei Ivanov wrote:
> Hi,
>
> JDK-8294904 [1] was resolved as Incomplete because there's no sample 
> code which demonstrates the problem. A comment was added:
>
> Mail to submitter:
> =============
> Please share standalone test case/ reproducible step/ scenario to 
> analyze the issue better.
>
> I should have received an email with request for clarification.
>
> I looked through the description but it's still unclear to me how to 
> reproduce the problem and how to incorporate the fix you're proposing 
> and what the fix is. If you could provide the test case and better yet 
> the fix along with a regression test, it would be greatly appreciated.
>
> The fix in the form of the diff would also help.
>
> -- 
> Regards,
> Alexey
>
> [1] https://bugs.openjdk.org/browse/JDK-8294904
>
> On 09/10/2022 15:57, magare31 at gmail.com wrote:
>>
>> Since I am new to this, and apologies for the broad email, could 
>> someone explain the following for the corresponding bug (JDK-8294904)?
>>
>>   * This bug is listed as one for a generic OS, whereas I specified
>>     Windows (I can confirm that it is Windows only).
>>   * This bug is listed as "resolved" with an "incomplete resolution".
>>     ?I did provide the full solution, so I am not sure what this
>>     means. ?(Also, Oracle asked for a standalone test, which I also
>>     provided over email)
>>
>> And thanks.
>>
>> *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 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/20221010/50c7743a/attachment.htm>

From tr at openjdk.org  Tue Oct 11 04:54:14 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 11 Oct 2022 04:54:14 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v7]
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: <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@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/cbc3ba1e..f5d345e5

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

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 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 psadhukhan at openjdk.org  Tue Oct 11 05:40:40 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Oct 2022 05:40:40 GMT
Subject: RFR: 5080391: ArrayIndexOutOfBounds during "undo" of Right-to-Left
 text insert [v3]
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: <NzW4BLiZO7Tj3dSKcVfO4nBwOCWXbkSgvn0NygJ-UkE=.1844a43a-6701-453f-bba4-e7a8ca125626@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.

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

  Test update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10446/files
  - new: https://git.openjdk.org/jdk/pull/10446/files/8e07fdc3..6414cdb3

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

  Stats: 81 lines in 1 file changed: 54 ins; 5 del; 22 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 psadhukhan at openjdk.org  Tue Oct 11 05:40:40 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Oct 2022 05:40:40 GMT
Subject: RFR: 5080391: ArrayIndexOutOfBounds during "undo" of Right-to-Left
 text insert [v3]
In-Reply-To: <sqgfeuzOUuPIYL3waQYeXf6A9COh07BiGi_PNNz1f_k=.df31410f-0202-41b2-b452-84a76aa3c34a@github.com>
References: <6RcEPyVsdn3GAryyi2QYk3OGfPDUGxFD-W0c_2s8iH4=.b10fa89b-07b7-4e8b-858f-1311d0ffeaae@github.com>
 <2bRWmn9tz1W2Hc6L-EQgVmw7UzVz38XMGoo71uA1HEc=.6a744d13-98cd-4a9b-9a43-7bbc09ed7be1@github.com>
 <2Yg2YfWHVULkQ5Flrxs-BHGIhx5Ej7ebbyR6D2SeKa0=.b035c42c-9966-4f41-9cc2-8aa0f72a1571@github.com>
 <sqgfeuzOUuPIYL3waQYeXf6A9COh07BiGi_PNNz1f_k=.df31410f-0202-41b2-b452-84a76aa3c34a@github.com>
Message-ID: <2qkbFDjRNL4LNVCLvwJYUUW0eOy7MFJq7lN8a_bR3Aw=.336eac22-62f6-4bf2-afeb-37f2267e5029@github.com>

On Fri, 7 Oct 2022 12:45:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> `getElement()` can return null [here](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java#L2619) and [here](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java#L2398)
>> so it should not be enitrely impossible not to get null, so it should be a ok
>
>> `getElement()` can return null [here](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java#L2619) and [here](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java#L2398) so it should not be enitrely impossible not to get null, so it should be a ok
> 
> I know it is possible _theoretically_. My point is for a valid offset in the document, this particular line must _never_ return `null`. If it does, the element tree is invalid. As such, we should rather catch the case of bad bidi element tree by throwing NPE rather than pretending nothing bad happened.
> 
> `BidiRootElement` is a `BranchElement`: https://github.com/openjdk/jdk/blob/096bca4a9c5e8ac2668dd965df92153ea1d80add/src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java#L2700-L2713
> 
> And [`BranchElement.getElementIndex`](https://github.com/openjdk/jdk/blob/096bca4a9c5e8ac2668dd965df92153ea1d80add/src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java#L2416-L2474) always returns a *valid* index.
> 
> So, I am against adding the `null`-check. It is not necessary here.

If there is only one character inserted/present in the document and then undo-ed, then there is no character/bidiElement so getElement() will return null and then getEndOffset() on that null element will return NPE, for which I have added the null check.

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

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


From psadhukhan at openjdk.org  Tue Oct 11 05:42:30 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Oct 2022 05:42:30 GMT
Subject: RFR: 5080391: ArrayIndexOutOfBounds during "undo" of Right-to-Left
 text insert [v2]
In-Reply-To: <6Kqr4negWpT1Lzc01V3v-Uwa6aQZqdLptL-6RXFiRIw=.ed5df3db-39a2-40f6-92cf-bfbd563db66d@github.com>
References: <6RcEPyVsdn3GAryyi2QYk3OGfPDUGxFD-W0c_2s8iH4=.b10fa89b-07b7-4e8b-858f-1311d0ffeaae@github.com>
 <sq5YNMPwZ0lbaQ-yPG5mp9bET-ERBhN1x81n0a4pGZc=.9aaa2a4a-973b-4c9a-aa3a-036e621c3de1@github.com>
 <6Kqr4negWpT1Lzc01V3v-Uwa6aQZqdLptL-6RXFiRIw=.ed5df3db-39a2-40f6-92cf-bfbd563db66d@github.com>
Message-ID: <mexoa3tKE0OpnnhKovuB0DSllHsbRlzqGLoReZt8vh0=.77e0ce4a-a02d-4438-9990-7c9482999e4b@github.com>

On Fri, 7 Oct 2022 18:33:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I do not think this makes a difference. Well, the first insertion does make a difference: it changes the text component state so from left-to-right only to bidirectional.
> 
> The following manipulations just add more Arabic text, so that the entire text run is right-to-left.
> 
> You want to test the situation where the change from left-to-right to bidirectional and component orientation occurs for the first time, and the text is inserted in the middle of a text run, in the end of text. You should probably, re-create `JTextArea` and `UndoManager` to test such scenarios.
> 
> You should also verify the result of undo. If you insert text by one character, each undo should remove that character from the text.
> 
> If you don't test the result of undo, you don't know whether the text was modified as expected or not.

Test updated to test insertion individually at end, middle and beginning and also test results of undo.

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

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


From tr at openjdk.org  Tue Oct 11 06:01:36 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 11 Oct 2022 06:01:36 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v6]
In-Reply-To: <xPL-AM_Y5dV1CCUUI9p77NeAQQcL0YtUJV67Tq2EjTw=.dd51540d-2992-4aaf-8797-5fdf81e9a951@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <umg-Fh9k6EZ375NrIwkafUa9NfJPDbp-Ry36z467Prc=.27ded4c7-797b-4c24-bf6b-a67cd7df1a8a@github.com>
 <xPL-AM_Y5dV1CCUUI9p77NeAQQcL0YtUJV67Tq2EjTw=.dd51540d-2992-4aaf-8797-5fdf81e9a951@github.com>
Message-ID: <S0lCn4z_BtgjhX7gfcb03CN6dKVJkaagst7hz7q3Rh0=.363803cd-2724-43f1-a882-f6daba3f4e10@github.com>

On Mon, 10 Oct 2022 17:23:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 82:
> 
>> 80:         passFailJFrame = new PassFailJFrame("Test Instructions", INSTRUCTIONS, 5L, 13, 40);
>> 81:         jfc = new JFileChooser();
>> 82:         String userHome = System.getProperty("user.home");
> 
> I prefer a blank line here to logically separate dealing with paths from creating the components. But it's a nit.

Updated.

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

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


From aturbanov at openjdk.org  Tue Oct 11 06:03:29 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 11 Oct 2022 06:03:29 GMT
Subject: Integrated: 8293986: Incorrect double-checked locking in
 com.sun.beans.introspect.ClassInfo
In-Reply-To: <xy5SGxYpSr1HEYXXTGxlr_dJz4bwQmMaHZ0-rSnzbxk=.fbede544-9152-4320-b97c-aa50209f0b42@github.com>
References: <xy5SGxYpSr1HEYXXTGxlr_dJz4bwQmMaHZ0-rSnzbxk=.fbede544-9152-4320-b97c-aa50209f0b42@github.com>
Message-ID: <TryPrtol-p4o8yE5aplEzm8eobu5N_NcRAg446_Abks=.eab10a68-b10f-4de9-a616-52bf8ddc09c0@github.com>

On Wed, 21 Sep 2022 08:03:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Fields `methods`, `properties`, `eventSets` are not volatile and read multiple times. This makes it an incorrect DCL.

This pull request has now been integrated.

Changeset: e775acf8
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e775acf889cde6f5bb463d4ecfe6eb035d18bdda
Stats:     25 lines in 1 file changed: 9 ins; 0 del; 16 mod

8293986: Incorrect double-checked locking in com.sun.beans.introspect.ClassInfo

Reviewed-by: serb

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

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


From jdv at openjdk.org  Tue Oct 11 06:30:25 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 11 Oct 2022 06:30:25 GMT
Subject: RFR: 8294254: [macOS]
 javax/swing/plaf/aqua/CustomComboBoxFocusTest.java failure [v2]
In-Reply-To: <AcQY1jED4CA6__TIdnit-sElejd1aDSIrOAG96_D8-E=.bfd71671-273b-4572-b405-0b898415a079@github.com>
References: <XmBIB7o0eNNj0Pq2udzXOSo0DtC0rO9s9bEqJSOJVx8=.64ffb7a6-0498-41b9-95ad-172b165826c3@github.com>
 <AcQY1jED4CA6__TIdnit-sElejd1aDSIrOAG96_D8-E=.bfd71671-273b-4572-b405-0b898415a079@github.com>
Message-ID: <F7UlLnmMNHJKWSGUKNF1BdVq-9VHGkKG5GGqwwjZXE4=.db78bbec-d231-47a1-8de8-e5686b56bd91@github.com>

On Mon, 10 Oct 2022 18:41:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The previous change to AquaComboBoxUI had 1 pixel of overlap between the text field and the combo button. This caused a few pixels to darken sometimes when an editable combobox is displayed. Since this test passes sometimes and fails some other times, it was not initially detected.
>> 
>> Since these few darkening pixels occur due to the change in AquaComboBoxUI, no reasonable change to the test could really be made, and the change would need to be to the class for the combobox. This fix was tested with a high count repeat and no failures occurred for various macOS systems.
>> 
>> Also removing the test from the problem list.
>
> Damon Nguyen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into 8294254/overlapFixEditableCombobox
>  - Merge branch 'openjdk:master' into 8294254/overlapFixEditableCombobox
>  - Remove test from problem list
>  - Adjust rect width to remove overlap

Its good that JComboBox misalignment issue is resolved under : https://bugs.openjdk.org/browse/JDK-8054572(I used to observe this at all places in SwingSet2 while testing Lanai)

I ran javax/swing/plaf/aqua/CustomComboBoxFocusTest.java without this change in built-in display and external display:
    Built-in display(uiScale 2) : Fails 1/5 times
    External display(uiScale 1) : Fails 3/5 times

Initially i was also under the impression that display scaling in test might be the root cause and making it run at some default scaling will solve the issue. But looks like this is a product regression introduced with fix under https://bugs.openjdk.org/browse/JDK-8054572.

Since the current fix takes care of both https://bugs.openjdk.org/browse/JDK-8054572 & https://bugs.openjdk.org/browse/JDK-8073001. This product change looks good to me.

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

Marked as reviewed by jdv (Reviewer).

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


From jdv at openjdk.org  Tue Oct 11 06:33:21 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 11 Oct 2022 06:33:21 GMT
Subject: RFR: 8294254: [macOS]
 javax/swing/plaf/aqua/CustomComboBoxFocusTest.java failure [v2]
In-Reply-To: <AcQY1jED4CA6__TIdnit-sElejd1aDSIrOAG96_D8-E=.bfd71671-273b-4572-b405-0b898415a079@github.com>
References: <XmBIB7o0eNNj0Pq2udzXOSo0DtC0rO9s9bEqJSOJVx8=.64ffb7a6-0498-41b9-95ad-172b165826c3@github.com>
 <AcQY1jED4CA6__TIdnit-sElejd1aDSIrOAG96_D8-E=.bfd71671-273b-4572-b405-0b898415a079@github.com>
Message-ID: <q7xaRAzbHZoACkf-qHK3xTzl7jgBKKG0DH-A9RZCaJw=.121db029-fa8f-4ee7-a609-1a198b61fe93@github.com>

On Mon, 10 Oct 2022 18:41:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The previous change to AquaComboBoxUI had 1 pixel of overlap between the text field and the combo button. This caused a few pixels to darken sometimes when an editable combobox is displayed. Since this test passes sometimes and fails some other times, it was not initially detected.
>> 
>> Since these few darkening pixels occur due to the change in AquaComboBoxUI, no reasonable change to the test could really be made, and the change would need to be to the class for the combobox. This fix was tested with a high count repeat and no failures occurred for various macOS systems.
>> 
>> Also removing the test from the problem list.
>
> Damon Nguyen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into 8294254/overlapFixEditableCombobox
>  - Merge branch 'openjdk:master' into 8294254/overlapFixEditableCombobox
>  - Remove test from problem list
>  - Adjust rect width to remove overlap

Additionally if we want to make javax/swing/plaf/aqua/CustomComboBoxFocusTest.java run at some default uiScale that also should be fine.

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

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


From duke at openjdk.org  Tue Oct 11 06:42:37 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Oct 2022 06:42:37 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v3]
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: <Pt6yoqrW_cHr13w3xRa3LK84H4Rj5_fsWrjC2PHJSRg=.9384dafa-47a6-49c5-9596-9bfad1f5098d@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:

  Review comment fix and test case changed to manual

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10390/files
  - new: https://git.openjdk.org/jdk/pull/10390/files/ff3bce2c..698a1202

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

  Stats: 98 lines in 2 files changed: 29 ins; 55 del; 14 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 jdv at openjdk.org  Tue Oct 11 06:52:41 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 11 Oct 2022 06:52:41 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v3]
In-Reply-To: <Pt6yoqrW_cHr13w3xRa3LK84H4Rj5_fsWrjC2PHJSRg=.9384dafa-47a6-49c5-9596-9bfad1f5098d@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <Pt6yoqrW_cHr13w3xRa3LK84H4Rj5_fsWrjC2PHJSRg=.9384dafa-47a6-49c5-9596-9bfad1f5098d@github.com>
Message-ID: <CmxsQg-AS4oVx7D0XqT_5hr7Lj2rGJJkByw8ykKv0K0=.7b93374a-92d3-4c6b-99b0-8de172c41913@github.com>

On Tue, 11 Oct 2022 06:42:37 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 remove "../" entry from JFileChooser directory list in GTK LAF if current directory is root.
>> 
>> 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:
> 
>   Review comment fix and test case changed to manual

Its good that now we are handling entries in directory list at appropriate place instead of modifying it at some event listeners. LGTM.

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

Marked as reviewed by jdv (Reviewer).

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


From duke at openjdk.org  Tue Oct 11 06:52:41 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Oct 2022 06:52:41 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: <VYKz0PeeJBDW0fqD8UNZ1YmVb46DIA61rHGAruCIHRg=.9c214b47-57e8-42d8-beea-483017a7f2e5@github.com>

On Mon, 26 Sep 2022 14:05: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
>
> 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"

@jayathirthrao @TejeshR13 As compared to previous fix where the condition was handled at listener level (mouse double click event), has been changed in current fix. 

Now as per the current fix the proposed solution is to remove the "../" from directory list if the current directory is root in GTK LAF. 

Test case has been updated to manual test as compared to previous fix. 
CI link is added in JBS for latest commit.

> 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?

Test case has been changed to manual now. So, there is no need of getting location on screen now.

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

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


From psadhukhan at openjdk.org  Tue Oct 11 07:04:21 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Oct 2022 07:04:21 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v3]
In-Reply-To: <Pt6yoqrW_cHr13w3xRa3LK84H4Rj5_fsWrjC2PHJSRg=.9384dafa-47a6-49c5-9596-9bfad1f5098d@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <Pt6yoqrW_cHr13w3xRa3LK84H4Rj5_fsWrjC2PHJSRg=.9384dafa-47a6-49c5-9596-9bfad1f5098d@github.com>
Message-ID: <ZcT9KPvfm8Qwst23JMr4xyY5T3GdPPdVEwpnpC2CFdQ=.6b65b4cc-afd6-4f69-81e4-be0e1ab384e5@github.com>

On Tue, 11 Oct 2022 06:42:37 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 remove "../" entry from JFileChooser directory list in GTK LAF if current directory is root.
>> 
>> 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:
> 
>   Review comment fix and test case changed to manual

src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java line 997:

> 995:             File crntDir = getFileChooser().getCurrentDirectory();
> 996:             if (crntDir != null && crntDir.getParentFile() == null &&
> 997:                 files.contains(new File("/.."))) {

Is it not possible to use "FileSystemView.isFileSystemRoot(File)" for this?

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

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


From psadhukhan at openjdk.org  Tue Oct 11 07:11:27 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Oct 2022 07:11:27 GMT
Subject: RFR: 8294254: [macOS]
 javax/swing/plaf/aqua/CustomComboBoxFocusTest.java failure [v2]
In-Reply-To: <AcQY1jED4CA6__TIdnit-sElejd1aDSIrOAG96_D8-E=.bfd71671-273b-4572-b405-0b898415a079@github.com>
References: <XmBIB7o0eNNj0Pq2udzXOSo0DtC0rO9s9bEqJSOJVx8=.64ffb7a6-0498-41b9-95ad-172b165826c3@github.com>
 <AcQY1jED4CA6__TIdnit-sElejd1aDSIrOAG96_D8-E=.bfd71671-273b-4572-b405-0b898415a079@github.com>
Message-ID: <RpUWenLwY8A71B5_BS2O7A1HIRU1qIfaWgDd7eAIvso=.c7f451f4-07a0-4c78-9d4c-fa35314c003e@github.com>

On Mon, 10 Oct 2022 18:41:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The previous change to AquaComboBoxUI had 1 pixel of overlap between the text field and the combo button. This caused a few pixels to darken sometimes when an editable combobox is displayed. Since this test passes sometimes and fails some other times, it was not initially detected.
>> 
>> Since these few darkening pixels occur due to the change in AquaComboBoxUI, no reasonable change to the test could really be made, and the change would need to be to the class for the combobox. This fix was tested with a high count repeat and no failures occurred for various macOS systems.
>> 
>> Also removing the test from the problem list.
>
> Damon Nguyen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into 8294254/overlapFixEditableCombobox
>  - Merge branch 'openjdk:master' into 8294254/overlapFixEditableCombobox
>  - Remove test from problem list
>  - Adjust rect width to remove overlap

src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 478:

> 476:             else {
> 477:                 return new Rectangle(insets.left + buttonSize, insets.top + midHeight,
> 478:                         width - (insets.left + insets.right + buttonSize) + 3,

I guess previous to this fix, we were using BasicComboBoxUI#rectangleForCurrentValue() which returns a width on which we add +4 for editor/textField width.
Since the calculation is basically same for width, why was it giving problem now (where only height is modified in the 8054572 fix) and not before this fix. I dont think this test use to fail before this fix was integrated with promoted CI builds

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

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


From duke at openjdk.org  Tue Oct 11 07:10:32 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Oct 2022 07:10:32 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v3]
In-Reply-To: <ZcT9KPvfm8Qwst23JMr4xyY5T3GdPPdVEwpnpC2CFdQ=.6b65b4cc-afd6-4f69-81e4-be0e1ab384e5@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <Pt6yoqrW_cHr13w3xRa3LK84H4Rj5_fsWrjC2PHJSRg=.9384dafa-47a6-49c5-9596-9bfad1f5098d@github.com>
 <ZcT9KPvfm8Qwst23JMr4xyY5T3GdPPdVEwpnpC2CFdQ=.6b65b4cc-afd6-4f69-81e4-be0e1ab384e5@github.com>
Message-ID: <CHVZQwLQpWZKSjKp6YeWXYehLeFLBRII0bndRzgaur8=.af87b0e4-f9c8-4ce4-bccc-f65dc0e9afa3@github.com>

On Tue, 11 Oct 2022 07:02:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fix and test case changed to manual
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java line 997:
> 
>> 995:             File crntDir = getFileChooser().getCurrentDirectory();
>> 996:             if (crntDir != null && crntDir.getParentFile() == null &&
>> 997:                 files.contains(new File("/.."))) {
> 
> Is it not possible to use "FileSystemView.isFileSystemRoot(File)" for this?

I have not checked this.
Do you mean to check `FileSystemView.isFileSystemRoot(crntDir )` ?

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

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


From psadhukhan at openjdk.org  Tue Oct 11 07:26:30 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Oct 2022 07:26:30 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v3]
In-Reply-To: <CHVZQwLQpWZKSjKp6YeWXYehLeFLBRII0bndRzgaur8=.af87b0e4-f9c8-4ce4-bccc-f65dc0e9afa3@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <Pt6yoqrW_cHr13w3xRa3LK84H4Rj5_fsWrjC2PHJSRg=.9384dafa-47a6-49c5-9596-9bfad1f5098d@github.com>
 <ZcT9KPvfm8Qwst23JMr4xyY5T3GdPPdVEwpnpC2CFdQ=.6b65b4cc-afd6-4f69-81e4-be0e1ab384e5@github.com>
 <CHVZQwLQpWZKSjKp6YeWXYehLeFLBRII0bndRzgaur8=.af87b0e4-f9c8-4ce4-bccc-f65dc0e9afa3@github.com>
Message-ID: <gZ1Q7R1FrU9bEoVaPowRlEPE1Ak27utjYfEmS1eNNLc=.abf70ed7-7318-4c01-a8fb-83c2aaca3cfb@github.com>

On Tue, 11 Oct 2022 07:06:35 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java line 997:
>> 
>>> 995:             File crntDir = getFileChooser().getCurrentDirectory();
>>> 996:             if (crntDir != null && crntDir.getParentFile() == null &&
>>> 997:                 files.contains(new File("/.."))) {
>> 
>> Is it not possible to use "FileSystemView.isFileSystemRoot(File)" for this?
>
> I have not checked this.
> Do you mean to check `FileSystemView.isFileSystemRoot(crntDir )` ?

I guess that's what you commented "if current directory is root"

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

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


From duke at openjdk.org  Tue Oct 11 07:33:41 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Oct 2022 07:33:41 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v3]
In-Reply-To: <gZ1Q7R1FrU9bEoVaPowRlEPE1Ak27utjYfEmS1eNNLc=.abf70ed7-7318-4c01-a8fb-83c2aaca3cfb@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <Pt6yoqrW_cHr13w3xRa3LK84H4Rj5_fsWrjC2PHJSRg=.9384dafa-47a6-49c5-9596-9bfad1f5098d@github.com>
 <ZcT9KPvfm8Qwst23JMr4xyY5T3GdPPdVEwpnpC2CFdQ=.6b65b4cc-afd6-4f69-81e4-be0e1ab384e5@github.com>
 <CHVZQwLQpWZKSjKp6YeWXYehLeFLBRII0bndRzgaur8=.af87b0e4-f9c8-4ce4-bccc-f65dc0e9afa3@github.com>
 <gZ1Q7R1FrU9bEoVaPowRlEPE1Ak27utjYfEmS1eNNLc=.abf70ed7-7318-4c01-a8fb-83c2aaca3cfb@github.com>
Message-ID: <5jNarH3tgm0W6SBM2KKn-tMm7plvCgVHgU4FYEnA-cQ=.ee131d4c-9b5c-4ae3-b0fa-134e441eee9f@github.com>

On Tue, 11 Oct 2022 07:22:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I have not checked this.
>> Do you mean to check `FileSystemView.isFileSystemRoot(crntDir )` ?
>
> I guess that's what you commented "if current directory is root"

Ok... I will check this.

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

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


From aivanov at openjdk.org  Tue Oct 11 07:51:37 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Oct 2022 07:51:37 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v7]
In-Reply-To: <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
Message-ID: <1uyz7IrOUnEVfq4Y2bmzs7GP1pppk4bqeUxYTi47ook=.7909ba4e-4c04-4f9a-9450-9f2c33ff981c@github.com>

On Tue, 11 Oct 2022 04:54:14 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.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 77:

> 75:                 3. Select the Documents folder again.
> 76:                 4. If NullPointerException does not occurs in the step 3,
> 77:                  click Pass, otherwise the Test Fails.

Suggestion:

                4. If NullPointerException does not occur in the step 3,
                 click Pass, otherwise the test fails automatically.

I guess this is better and has no grammar mistakes.

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

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


From duke at openjdk.org  Tue Oct 11 07:55:00 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Oct 2022 07:55:00 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v7]
In-Reply-To: <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
Message-ID: <5BSqtyelyosUlbni9ct5mf0Une9WE_N0A0jh_6MY4Ao=.4aa4975f-ae4b-4f85-92bd-138a124d8120@github.com>

On Tue, 11 Oct 2022 04:54:14 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.
>
> 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/FileViewNPETest.java line 39:

> 37:  * @test
> 38:  * @bug 6616245
> 39:  * @key headful

is it required to have a `key` tag for manual test case?

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

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


From duke at openjdk.org  Tue Oct 11 07:59:29 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Oct 2022 07:59:29 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v7]
In-Reply-To: <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
Message-ID: <82u3B21KXDPRCZP3ZtdlkWTgBm9AcPH-cmMCWqfz96E=.92d84ee2-e744-48a9-bb42-17e04a3b50aa@github.com>

On Tue, 11 Oct 2022 04:54:14 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.
>
> 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/FileViewNPETest.java line 80:

> 78:                 """;
> 79:         frame = new JFrame("JFileChooser File View NPE test");
> 80:         passFailJFrame = new PassFailJFrame("Test Instructions", INSTRUCTIONS, 5L, 13, 40);

Few lines are going beyond 80 columns, can you please update them?

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

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


From aivanov at openjdk.org  Tue Oct 11 08:50:30 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Oct 2022 08:50:30 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v7]
In-Reply-To: <82u3B21KXDPRCZP3ZtdlkWTgBm9AcPH-cmMCWqfz96E=.92d84ee2-e744-48a9-bb42-17e04a3b50aa@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
 <82u3B21KXDPRCZP3ZtdlkWTgBm9AcPH-cmMCWqfz96E=.92d84ee2-e744-48a9-bb42-17e04a3b50aa@github.com>
Message-ID: <b76LuIixAmC3lqdf2Z6eKP3p3eFhsGAgRQmQYcpEeok=.2ec76bed-ee3f-49d9-a45b-bea30a6a853f@github.com>

On Tue, 11 Oct 2022 07:57:26 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> Few lines are going beyond 80 columns, can you please update them?

I agree, line 80 could be wrapped, it's 92 columns long. At the same, I wouldn't have insisted because it contains the parameters to `PassFailJFrame` which aren't so important to understanding the logic of the test.

Line 92 with the position is better left untouched, it's not too long (five chars outside of 80-column limit) and it's cleaner unwrapped. You may statically-import `PassFailJFrame.Position` in which case the line would become shorter:

        PassFailJFrame.positionTestWindow(frame, Position.HORIZONTAL);


I am for keeping line 61 as it is now even though it doesn't fit the limit by 5 characters. It's still readable. In fact, this `throws` clause could be avoided altogether by restructuring the code. The constructor of `PassFailJFrame` is designed to be called on the main thread, yet Tejesh prefers it this way. I don't think it's worth moving the code around at this point when it's approved already.

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

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


From aivanov at openjdk.org  Tue Oct 11 08:54:35 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Oct 2022 08:54:35 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v7]
In-Reply-To: <5BSqtyelyosUlbni9ct5mf0Une9WE_N0A0jh_6MY4Ao=.4aa4975f-ae4b-4f85-92bd-138a124d8120@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
 <5BSqtyelyosUlbni9ct5mf0Une9WE_N0A0jh_6MY4Ao=.4aa4975f-ae4b-4f85-92bd-138a124d8120@github.com>
Message-ID: <EmvwChPTtgNByXgUNAAavtVdZ6b0T3fY3bEdiYvk9-c=.09c4198a-45cc-46e8-ba15-9fa78b99d874@github.com>

On Tue, 11 Oct 2022 07:52:42 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> Is it required to have a `key` tag for manual test case?

A manual test is declared by its `@run` tag:

 * @run main/manual FileViewNPETest


If `-a` (automatic tests) is passed to jtreg, this test isn't selected for running.

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

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


From duke at openjdk.org  Tue Oct 11 09:00:26 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Oct 2022 09:00:26 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v7]
In-Reply-To: <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
Message-ID: <oGiOtgZsvuRIAvN6kaBp7fP_mBnf0GKh1JHHmV_sHIM=.09c0b99a-f74e-4ea4-ab56-947867c1c346@github.com>

On Tue, 11 Oct 2022 04:54:14 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.
>
> 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 kumarabhi006 at github.com (no known OpenJDK username).

Verified the latest fix and is working fine.

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

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


From duke at openjdk.org  Tue Oct 11 09:00:28 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Oct 2022 09:00:28 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v7]
In-Reply-To: <b76LuIixAmC3lqdf2Z6eKP3p3eFhsGAgRQmQYcpEeok=.2ec76bed-ee3f-49d9-a45b-bea30a6a853f@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
 <82u3B21KXDPRCZP3ZtdlkWTgBm9AcPH-cmMCWqfz96E=.92d84ee2-e744-48a9-bb42-17e04a3b50aa@github.com>
 <b76LuIixAmC3lqdf2Z6eKP3p3eFhsGAgRQmQYcpEeok=.2ec76bed-ee3f-49d9-a45b-bea30a6a853f@github.com>
Message-ID: <KoCAqdk4i5YJCXt6JM6TAdhYvaF6Dc4_G8cVysGPR8w=.5130386d-a33c-4dd3-af99-cc941efb97b3@github.com>

On Tue, 11 Oct 2022 08:48:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 80:
>> 
>>> 78:                 """;
>>> 79:         frame = new JFrame("JFileChooser File View NPE test");
>>> 80:         passFailJFrame = new PassFailJFrame("Test Instructions", INSTRUCTIONS, 5L, 13, 40);
>> 
>> Few lines are going beyond 80 columns, can you please update them?
>
>> Few lines are going beyond 80 columns, can you please update them?
> 
> I agree, line 80 could be wrapped, it's 92 columns long. At the same, I wouldn't have insisted because it contains the parameters to `PassFailJFrame` which aren't so important to understanding the logic of the test.
> 
> Line 92 with the position is better left untouched, it's not too long (five chars outside of 80-column limit) and it's cleaner unwrapped. You may statically-import `PassFailJFrame.Position` in which case the line would become shorter:
> 
>         PassFailJFrame.positionTestWindow(frame, Position.HORIZONTAL);
> 
> 
> I am for keeping line 61 as it is now even though it doesn't fit the limit by 5 characters. It's still readable. In fact, this `throws` clause could be avoided altogether by restructuring the code. The constructor of `PassFailJFrame` is designed to be called on the main thread, yet Tejesh prefers it this way. I don't think it's worth moving the code around at this point when it's approved already.

Ok.

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

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


From duke at openjdk.org  Tue Oct 11 09:10:10 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Oct 2022 09:10:10 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v4]
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: <yMRUplOj_gIANNPiZH-qI7iG2U_I4vZ1f45LMhAzfmg=.c301c13a-1529-4263-aa38-03a921b5ba79@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 remove "../" entry from JFileChooser directory list in GTK LAF if current directory is root.
> 
> 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:

  Review comment fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10390/files
  - new: https://git.openjdk.org/jdk/pull/10390/files/698a1202..c7493bf1

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

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 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  Tue Oct 11 09:10:12 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Oct 2022 09:10:12 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v3]
In-Reply-To: <5jNarH3tgm0W6SBM2KKn-tMm7plvCgVHgU4FYEnA-cQ=.ee131d4c-9b5c-4ae3-b0fa-134e441eee9f@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <Pt6yoqrW_cHr13w3xRa3LK84H4Rj5_fsWrjC2PHJSRg=.9384dafa-47a6-49c5-9596-9bfad1f5098d@github.com>
 <ZcT9KPvfm8Qwst23JMr4xyY5T3GdPPdVEwpnpC2CFdQ=.6b65b4cc-afd6-4f69-81e4-be0e1ab384e5@github.com>
 <CHVZQwLQpWZKSjKp6YeWXYehLeFLBRII0bndRzgaur8=.af87b0e4-f9c8-4ce4-bccc-f65dc0e9afa3@github.com>
 <gZ1Q7R1FrU9bEoVaPowRlEPE1Ak27utjYfEmS1eNNLc=.abf70ed7-7318-4c01-a8fb-83c2aaca3cfb@github.com>
 <5jNarH3tgm0W6SBM2KKn-tMm7plvCgVHgU4FYEnA-cQ=.ee131d4c-9b5c-4ae3-b0fa-134e441eee9f@github.com>
Message-ID: <tARXGiEB5nKLEFgxwu_rg8hVxWqv9WZ-Ecte6PrgJJM=.67ff79e7-f224-442f-a3fe-446f4809100e@github.com>

On Tue, 11 Oct 2022 07:31:10 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> I guess that's what you commented "if current directory is root"
>
> Ok... I will check this.

> Is it not possible to use "FileSystemView.isFileSystemRoot(File)" for this?

Updated.

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

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


From psadhukhan at openjdk.org  Tue Oct 11 09:57:35 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Oct 2022 09:57:35 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v4]
In-Reply-To: <yMRUplOj_gIANNPiZH-qI7iG2U_I4vZ1f45LMhAzfmg=.c301c13a-1529-4263-aa38-03a921b5ba79@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <yMRUplOj_gIANNPiZH-qI7iG2U_I4vZ1f45LMhAzfmg=.c301c13a-1529-4263-aa38-03a921b5ba79@github.com>
Message-ID: <_bjrFdGf0G-M5TixEIp1WFs3PSEJwMOf7H0SLt5AWEk=.7332483b-5e80-4ed2-9968-ff767272c3e5@github.com>

On Tue, 11 Oct 2022 09:10:10 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 remove "../" entry from JFileChooser directory list in GTK LAF if current directory is root.
>> 
>> 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:
> 
>   Review comment fix

test/jdk/javax/swing/JFileChooser/TestFileChooserDirectorySelection.java line 34:

> 32:  * @run main/manual TestFileChooserDirectorySelection
> 33:  */
> 34: 

better to put the test in plaf/gtk folder as it fixed gtk issue

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

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


From duke at openjdk.org  Tue Oct 11 10:12:47 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Oct 2022 10:12:47 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v5]
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: <IFvphQQymfvOWn73MPac6hzH4kCYrVbFg9lm0j6B1Hw=.177d5085-286d-4ff1-a743-903a0f3563c1@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 remove "../" entry from JFileChooser directory list in GTK LAF if current directory is root.
> 
> 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:

  Test moved to plaf/gtk folder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10390/files
  - new: https://git.openjdk.org/jdk/pull/10390/files/c7493bf1..7b9b74f5

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

  Stats: 0 lines in 1 file changed: 0 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  Tue Oct 11 10:12:47 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Oct 2022 10:12:47 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v4]
In-Reply-To: <_bjrFdGf0G-M5TixEIp1WFs3PSEJwMOf7H0SLt5AWEk=.7332483b-5e80-4ed2-9968-ff767272c3e5@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <yMRUplOj_gIANNPiZH-qI7iG2U_I4vZ1f45LMhAzfmg=.c301c13a-1529-4263-aa38-03a921b5ba79@github.com>
 <_bjrFdGf0G-M5TixEIp1WFs3PSEJwMOf7H0SLt5AWEk=.7332483b-5e80-4ed2-9968-ff767272c3e5@github.com>
Message-ID: <q0HDUFVjgONNeu0QY3LGmMLWR-aTI7aCG5xnUmFGmvA=.1896026b-24ac-41db-a2af-c0552b2e389c@github.com>

On Tue, 11 Oct 2022 09:55:23 GMT, Prasanta Sadhukhan <psadhukhan 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/JFileChooser/TestFileChooserDirectorySelection.java line 34:
> 
>> 32:  * @run main/manual TestFileChooserDirectorySelection
>> 33:  */
>> 34: 
> 
> better to put the test in plaf/gtk folder as it fixed gtk issue

Test file moved to plaf/gtk folder.

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

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


From tr at openjdk.org  Tue Oct 11 10:15:10 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 11 Oct 2022 10:15:10 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v8]
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: <EmYyE3kgHC70cYU9dPVLoV-d2Z_DDh2KmpCbPu74QVc=.f14b8414-0353-4606-a509-da5b48d43409@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/f5d345e5..de312f56

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

  Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 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  Tue Oct 11 10:15:15 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 11 Oct 2022 10:15:15 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v7]
In-Reply-To: <EmvwChPTtgNByXgUNAAavtVdZ6b0T3fY3bEdiYvk9-c=.09c4198a-45cc-46e8-ba15-9fa78b99d874@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
 <5BSqtyelyosUlbni9ct5mf0Une9WE_N0A0jh_6MY4Ao=.4aa4975f-ae4b-4f85-92bd-138a124d8120@github.com>
 <EmvwChPTtgNByXgUNAAavtVdZ6b0T3fY3bEdiYvk9-c=.09c4198a-45cc-46e8-ba15-9fa78b99d874@github.com>
Message-ID: <BK6UUEh66DyE-GXt4JPVhk8ZfZ4_ELAClC4-Ws_YjMQ=.056e7090-b9fc-4c9e-8e39-bb27a0dcb8b3@github.com>

On Tue, 11 Oct 2022 08:50:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 39:
>> 
>>> 37:  * @test
>>> 38:  * @bug 6616245
>>> 39:  * @key headful
>> 
>> Is it required to have a `key` tag for manual test case?
>
>> Is it required to have a `key` tag for manual test case?
> 
> A manual test is declared by its `@run` tag:
> 
>  * @run main/manual FileViewNPETest
> 
> 
> If `-a` (automatic tests) is passed to jtreg, this test isn't selected for running.

Removed the tag.

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

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


From tr at openjdk.org  Tue Oct 11 10:15:17 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 11 Oct 2022 10:15:17 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v7]
In-Reply-To: <1uyz7IrOUnEVfq4Y2bmzs7GP1pppk4bqeUxYTi47ook=.7909ba4e-4c04-4f9a-9450-9f2c33ff981c@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
 <1uyz7IrOUnEVfq4Y2bmzs7GP1pppk4bqeUxYTi47ook=.7909ba4e-4c04-4f9a-9450-9f2c33ff981c@github.com>
Message-ID: <UOzm6qMhdY1yZ5OtByRjd3lCdvtP0i80mHVXSjDmv9w=.1b6c9f4b-4c36-4ed3-91cf-4bf3b3e659cf@github.com>

On Tue, 11 Oct 2022 07:46:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 77:
> 
>> 75:                 3. Select the Documents folder again.
>> 76:                 4. If NullPointerException does not occurs in the step 3,
>> 77:                  click Pass, otherwise the Test Fails.
> 
> Suggestion:
> 
>                 4. If NullPointerException does not occur in the step 3,
>                  click Pass, otherwise the test fails automatically.
> 
> I guess this is better and has no grammar mistakes.

Updated.

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

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


From tr at openjdk.org  Tue Oct 11 10:15:18 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 11 Oct 2022 10:15:18 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v7]
In-Reply-To: <KoCAqdk4i5YJCXt6JM6TAdhYvaF6Dc4_G8cVysGPR8w=.5130386d-a33c-4dd3-af99-cc941efb97b3@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
 <82u3B21KXDPRCZP3ZtdlkWTgBm9AcPH-cmMCWqfz96E=.92d84ee2-e744-48a9-bb42-17e04a3b50aa@github.com>
 <b76LuIixAmC3lqdf2Z6eKP3p3eFhsGAgRQmQYcpEeok=.2ec76bed-ee3f-49d9-a45b-bea30a6a853f@github.com>
 <KoCAqdk4i5YJCXt6JM6TAdhYvaF6Dc4_G8cVysGPR8w=.5130386d-a33c-4dd3-af99-cc941efb97b3@github.com>
Message-ID: <XpwDPI4LnnjKw19Yls2ANIOuykLL3-Dh1jSSEdr39jQ=.39c631a3-e465-4b09-aa9a-e4640e7d5873@github.com>

On Tue, 11 Oct 2022 08:54:45 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>>> Few lines are going beyond 80 columns, can you please update them?
>> 
>> I agree, line 80 could be wrapped, it's 92 columns long. At the same, I wouldn't have insisted because it contains the parameters to `PassFailJFrame` which aren't so important to understanding the logic of the test.
>> 
>> Line 92 with the position is better left untouched, it's not too long (five chars outside of 80-column limit) and it's cleaner unwrapped. You may statically-import `PassFailJFrame.Position` in which case the line would become shorter:
>> 
>>         PassFailJFrame.positionTestWindow(frame, Position.HORIZONTAL);
>> 
>> 
>> I am for keeping line 61 as it is now even though it doesn't fit the limit by 5 characters. It's still readable. In fact, this `throws` clause could be avoided altogether by restructuring the code. The constructor of `PassFailJFrame` is designed to be called on the main thread, yet Tejesh prefers it this way. I don't think it's worth moving the code around at this point when it's approved already.
>
> Ok.

Updated.

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

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


From aivanov at openjdk.org  Tue Oct 11 10:31:03 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Oct 2022 10:31:03 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v8]
In-Reply-To: <EmYyE3kgHC70cYU9dPVLoV-d2Z_DDh2KmpCbPu74QVc=.f14b8414-0353-4606-a509-da5b48d43409@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <EmYyE3kgHC70cYU9dPVLoV-d2Z_DDh2KmpCbPu74QVc=.f14b8414-0353-4606-a509-da5b48d43409@github.com>
Message-ID: <C-5YOCe3d2kHfSq56psDjivRIpSrMJ5MKW7VQinXL48=.d37f6c16-69c4-48dd-9c1b-bc967d01338c@github.com>

On Tue, 11 Oct 2022 10:15:10 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.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Changes requested by aivanov (Reviewer).

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

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


From aivanov at openjdk.org  Tue Oct 11 10:31:05 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Oct 2022 10:31:05 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v7]
In-Reply-To: <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
Message-ID: <sRtFn1eeD8hTkySYFLfXzuDV6H7N6kJCmyUP-RFyMAY=.031c70dc-5b34-4df6-a937-77bc4c8f732d@github.com>

On Tue, 11 Oct 2022 04:54:14 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.
>
> 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/FileViewNPETest.java line 39:

> 37:  * @test
> 38:  * @bug 6616245
> 39:  * @key headful

Why did you remove `headful`?

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

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


From tr at openjdk.org  Tue Oct 11 10:35:35 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 11 Oct 2022 10:35:35 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v9]
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: <tQcU-NCohuWHJ1OZHDAoXtWybnOmPZ5PuFA1C005TQg=.45c13041-bd7e-4d67-8f02-9f4130be5014@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/de312f56..5854ef23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10485&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10485&range=07-08

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 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  Tue Oct 11 10:41:29 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 11 Oct 2022 10:41:29 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v7]
In-Reply-To: <sRtFn1eeD8hTkySYFLfXzuDV6H7N6kJCmyUP-RFyMAY=.031c70dc-5b34-4df6-a937-77bc4c8f732d@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
 <sRtFn1eeD8hTkySYFLfXzuDV6H7N6kJCmyUP-RFyMAY=.031c70dc-5b34-4df6-a937-77bc4c8f732d@github.com>
Message-ID: <q7AQoQXi6VcTQfG4M300DYj4SOxZS7zYgzFbI5iXXhI=.012b037c-a536-41a2-8a5d-650ce8fb8638@github.com>

On Tue, 11 Oct 2022 10:27:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 39:
> 
>> 37:  * @test
>> 38:  * @bug 6616245
>> 39:  * @key headful
> 
> Why did you remove `headful`?

Added again, though some manual tests have this tag and some don't better to keep it as an indication that represents as headful test......

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

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


From magare31 at gmail.com  Tue Oct 11 10:47:31 2022
From: magare31 at gmail.com (magare31 at gmail.com)
Date: Tue, 11 Oct 2022 06:47:31 -0400
Subject: professional (24-bit) sampled audio support in the Windows native
 implementation of libjsound
In-Reply-To: <0de52bab-dab9-a536-bd15-0df2b69f28a9@oracle.com>
References: <02e901d8d4c0$7dd12ee0$79738ca0$@gmail.com>
 <506f19c5-28ae-e606-e7f1-22464793afcb@oracle.com>
 <028e01d8dbef$69b25070$3d16f150$@gmail.com>
 <5ca697e2-fd4f-8a4b-9f98-b536ed5bb2a7@oracle.com>
 <0de52bab-dab9-a536-bd15-0df2b69f28a9@oracle.com>
Message-ID: <042b01d8dd5e$dda3e640$98ebb2c0$@gmail.com>

Hi Phillip:

 

Actual name is Anton.  Understood.  

 

For various reasons, I am not interested in becoming a contributor at this point.  I was simply looking for a current contributor that would pick up a small change.  I'll drop this.  

 

Thank you all.

 

Anton

 

From: Philip Race <philip.race at oracle.com> 
Sent: Monday, October 10, 2022 10:21 PM
To: Aleksei Ivanov <alexey.ivanov at oracle.com>; magare31 at gmail.com; client-libs-dev at openjdk.org
Subject: Re: professional (24-bit) sampled audio support in the Windows native implementation of libjsound

 

So Magare (what is your actual name ?),

As admin for this list I saw your  latest email but due to size etc it was rejected by OpenJDK mail servers.
I don't think I can do anything about that. In fact it wasn't even a patch. It was a full copy of a file.
And I believe you misunderstood that Alexey was quoting what you should have sent in reply
to the person who is triaging your bug submission. NOT to be sent to this list. Go look in your inbox+spam.

Regardless OpenJDK does not take patches in email.
They need to be github PRs *after* following process below.

Have you read the OpenJDK Developer's Guide ? https://openjdk.org/guide/

Start here https://openjdk.org/guide/#contributing-to-an-openjdk-project
and make sure to sign and return the OCA mentioned there.

The OCA must be accepted in order to take code from you.

Do you have a github account ? You'll need one and it'll have to be linked to an approved OCA.
You can then submit a PR against https://github.com/openjdk/jdk

I can help you "sponsor" this change, but you need to absorb the process and do the OCA first.

-phil.



On 10/10/22 2:03 PM, Aleksei Ivanov wrote:

Hi,

JDK-8294904 [1] was resolved as Incomplete because there's no sample code which demonstrates the problem. A comment was added:

Mail to submitter: 
============= 
Please share standalone test case/ reproducible step/ scenario to analyze the issue better.

I should have received an email with request for clarification.

I looked through the description but it's still unclear to me how to reproduce the problem and how to incorporate the fix you're proposing and what the fix is. If you could provide the test case and better yet the fix along with a regression test, it would be greatly appreciated.

The fix in the form of the diff would also help.

-- 
Regards,
Alexey

[1] https://bugs.openjdk.org/browse/JDK-8294904

On 09/10/2022 15:57, magare31 at gmail.com <mailto:magare31 at gmail.com>  wrote:

Since I am new to this, and apologies for the broad email, could someone explain the following for the corresponding bug (JDK-8294904)?

 

1.	This bug is listed as one for a generic OS, whereas I specified Windows (I can confirm that it is Windows only).
2.	This bug is listed as "resolved" with an "incomplete resolution".  I did provide the full solution, so I am not sure what this means.  (Also, Oracle asked for a standalone test, which I also provided over email)

 

And thanks.

 

From: Kevin Rushforth  <mailto:kevin.rushforth at oracle.com> <kevin.rushforth at oracle.com> 
Sent: Friday, September 30, 2022 8:29 AM
To: magare31 at gmail.com <mailto:magare31 at gmail.com> ; client-libs-dev at openjdk.org <mailto:client-libs-dev at openjdk.org> ; core-libs-dev at openjdk.org <mailto: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/20221011/93010032/attachment.htm>

From tr at openjdk.org  Tue Oct 11 10:48:29 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 11 Oct 2022 10:48:29 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v5]
In-Reply-To: <IFvphQQymfvOWn73MPac6hzH4kCYrVbFg9lm0j6B1Hw=.177d5085-286d-4ff1-a743-903a0f3563c1@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <IFvphQQymfvOWn73MPac6hzH4kCYrVbFg9lm0j6B1Hw=.177d5085-286d-4ff1-a743-903a0f3563c1@github.com>
Message-ID: <Ri9ls4KSySi-Gi_HUQfwWx974aymWkObnP_Hh91ulsE=.7d720d5b-4af3-4b08-8c8c-4bce435ae241@github.com>

On Tue, 11 Oct 2022 10:12: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 remove "../" entry from JFileChooser directory list in GTK LAF if current directory is root.
>> 
>> 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:
> 
>   Test moved to plaf/gtk folder

Marked as reviewed by tr (Author).

Fix works fine and tested.

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

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


From psadhukhan at openjdk.org  Tue Oct 11 10:48:30 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Oct 2022 10:48:30 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v5]
In-Reply-To: <IFvphQQymfvOWn73MPac6hzH4kCYrVbFg9lm0j6B1Hw=.177d5085-286d-4ff1-a743-903a0f3563c1@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <IFvphQQymfvOWn73MPac6hzH4kCYrVbFg9lm0j6B1Hw=.177d5085-286d-4ff1-a743-903a0f3563c1@github.com>
Message-ID: <o2mZXfvIjkNhWjUm-2GiU8IxHQ7DnT0ymkudw50a3OY=.d24c2464-2533-4b9a-8f55-7ecd4c0daea3@github.com>

On Tue, 11 Oct 2022 10:12: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 remove "../" entry from JFileChooser directory list in GTK LAF if current directory is root.
>> 
>> 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:
> 
>   Test moved to plaf/gtk folder

Please confirm that along with ubuntu, you have tested on Oracle Linux too.

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

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


From aivanov at openjdk.org  Tue Oct 11 10:51:17 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Oct 2022 10:51:17 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v9]
In-Reply-To: <tQcU-NCohuWHJ1OZHDAoXtWybnOmPZ5PuFA1C005TQg=.45c13041-bd7e-4d67-8f02-9f4130be5014@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <tQcU-NCohuWHJ1OZHDAoXtWybnOmPZ5PuFA1C005TQg=.45c13041-bd7e-4d67-8f02-9f4130be5014@github.com>
Message-ID: <Xd-iR10kPTouiwHXOStdiaGl-2aSPQ5hO5jxXn1Js-g=.dbb9b5a6-d3fc-48ff-b03e-121df1d88be4@github.com>

On Tue, 11 Oct 2022 10:35:35 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.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.org  Tue Oct 11 10:51:19 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Oct 2022 10:51:19 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v7]
In-Reply-To: <5BSqtyelyosUlbni9ct5mf0Une9WE_N0A0jh_6MY4Ao=.4aa4975f-ae4b-4f85-92bd-138a124d8120@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <sbyKOV9c4lsQwEZwri4swrwKV0UxGW-KVdFjuZfS2bg=.02c340a5-1fee-44c2-921c-0d84e02ee5d2@github.com>
 <5BSqtyelyosUlbni9ct5mf0Une9WE_N0A0jh_6MY4Ao=.4aa4975f-ae4b-4f85-92bd-138a124d8120@github.com>
Message-ID: <IuWAUptNdPQIvuDm6f_n0EV5q5MYZfXAjnn5gUewq9o=.3058ab32-c6ab-48e8-a7a1-f9fbac90b960@github.com>

On Tue, 11 Oct 2022 07:52:42 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
>
> test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 39:
> 
>> 37:  * @test
>> 38:  * @bug 6616245
>> 39:  * @key headful
> 
> Is it required to have a `key` tag for manual test case?

I admit I misunderstood the question. I thought @kumarabhi006 had asked for adding another keyword to `@key` to specify a _manual_ test.

I didn't think about removing `@key headful`. At the same time, a manual test implies being _headful_ to the UI with instructions.

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

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


From tr at openjdk.org  Tue Oct 11 11:14:34 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 11 Oct 2022 11:14:34 GMT
Subject: Integrated: 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: <LRzZfz27Nbs8dMISkleNkUzaZguIxi9gFqss3HC8dWk=.fe7a2d45-7703-463b-9f9a-8278b9011e75@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.

This pull request has now been integrated.

Changeset: 33d06188
Author:    Tejesh R <tr at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33d061881350c23b5116b3e555eaa905020636f7
Stats:     117 lines in 2 files changed: 113 ins; 2 del; 2 mod

6616245: NullPointerException when using JFileChooser with a custom FileView

Reviewed-by: aivanov

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

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


From kevin.rushforth at oracle.com  Tue Oct 11 11:17:45 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 11 Oct 2022 04:17:45 -0700
Subject: Examples Of Many Java Swing Components In One Program.
In-Reply-To: <a8357c5b-9616-7f19-83b0-12c5d56ff774@oracle.com>
References: <CAFf+5zhufpcpjxek5o9MMw51BNhYGYmfnFy_f92dg5szX7O1mA@mail.gmail.com>
 <a8357c5b-9616-7f19-83b0-12c5d56ff774@oracle.com>
Message-ID: <702e6103-a19f-2d60-9ae8-e207e917d787@oracle.com>

It's still there.

https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc/SwingSet2

Btw, client-libs-dev at openjdk.org (included) is the relevant mailing list 
for this message, not core-libs-dev.

-- Kevin


On 10/11/2022 1:54 AM, David Holmes wrote:
> On 11/10/2022 4:38 pm, Amit wrote:
>> Code for many Java Swing Components In One Program in case someone 
>> needs it.
>
> We used to have a Swing demo in the JDK ... don't know what happened 
> to it.
>
> David
>
>> Description: The program
>> Examples_Of_Many_Swing_Components_In_One_Program contains examples of
>> many swing components - that is, how to initialize them and use them.
>> You can use code from this program in your code. Where applicable,
>> appropriate listeners are also implemented.

snip




From duke at openjdk.org  Tue Oct 11 11:46:32 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Oct 2022 11:46:32 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v5]
In-Reply-To: <o2mZXfvIjkNhWjUm-2GiU8IxHQ7DnT0ymkudw50a3OY=.d24c2464-2533-4b9a-8f55-7ecd4c0daea3@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <IFvphQQymfvOWn73MPac6hzH4kCYrVbFg9lm0j6B1Hw=.177d5085-286d-4ff1-a743-903a0f3563c1@github.com>
 <o2mZXfvIjkNhWjUm-2GiU8IxHQ7DnT0ymkudw50a3OY=.d24c2464-2533-4b9a-8f55-7ecd4c0daea3@github.com>
Message-ID: <3Oewv3Ll4rb94Z0qMcP_YOat5UhosAbKEHXx0GJlhxg=.6e1278e5-77f3-425d-a647-c354c908f1a1@github.com>

On Tue, 11 Oct 2022 10:42:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please confirm that along with ubuntu, you have tested on Oracle Linux too.

I have checked in Oracle Linux, Fix is working fine.

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

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


From psadhukhan at openjdk.org  Tue Oct 11 12:22:28 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Oct 2022 12:22:28 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v5]
In-Reply-To: <IFvphQQymfvOWn73MPac6hzH4kCYrVbFg9lm0j6B1Hw=.177d5085-286d-4ff1-a743-903a0f3563c1@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <IFvphQQymfvOWn73MPac6hzH4kCYrVbFg9lm0j6B1Hw=.177d5085-286d-4ff1-a743-903a0f3563c1@github.com>
Message-ID: <dN6Lnkp84OSdmXYRd-S73p8kLdSsw6ToUC3GMiT34bc=.4e22415d-363b-4e64-adf7-0d18845c0423@github.com>

On Tue, 11 Oct 2022 10:12: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 remove "../" entry from JFileChooser directory list in GTK LAF if current directory is root.
>> 
>> 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:
> 
>   Test moved to plaf/gtk folder

Marked as reviewed by psadhukhan (Reviewer).

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

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


From duke at openjdk.org  Tue Oct 11 13:40:30 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 11 Oct 2022 13:40:30 GMT
Subject: Integrated: 6777156: GTK L&F: JFileChooser can jump beyond root
 directory 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: <DcXM6cSCYmQ3yCLhyoNt5ynotGbv5Oq9rAAhxu5BgoM=.d55cd3e1-4463-4050-bec3-2385220df47e@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 remove "../" entry from JFileChooser directory list in GTK LAF if current directory is root.
> 
> Test case has been added and checked in CI pipeline. Link is attached in JBS.

This pull request has now been integrated.

Changeset: 9d0009e9
Author:    Abhishek Kumar <abhishek.cx.kumar at oracle.com>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9d0009e92b790b43153e3db353db775e6ff731cb
Stats:     98 lines in 2 files changed: 97 ins; 0 del; 1 mod

6777156: GTK L&F: JFileChooser can jump beyond root directory in combobox and selection textarea.

Reviewed-by: jdv, tr, psadhukhan

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

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


From mvs at openjdk.org  Tue Oct 11 13:49:31 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 11 Oct 2022 13:49:31 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v2]
In-Reply-To: <nDQmbmLEjsXkX8ZiCHLPWIdek8QO364h84ObYSK0YdI=.6b99ed5b-6086-41bf-aa9c-df43b1bed70e@github.com>
References: <nDQmbmLEjsXkX8ZiCHLPWIdek8QO364h84ObYSK0YdI=.6b99ed5b-6086-41bf-aa9c-df43b1bed70e@github.com>
Message-ID: <6vNrM57A4zL2ezWR8d_dA6P3_qdKJjqmI35pX8OfJYg=.c1295d00-99a8-496b-a362-bbed75cc169a@github.com>

> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
> 
> Fix:
> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.

Manukumar V S has updated the pull request incrementally with 39 additional commits since the last revision:

 - Updated screen capture code, made frame undecorated, added some prints for debugging
 - 6777156: GTK L&F: JFileChooser can jump beyond root directory in combobox and selection textarea.
   
   Reviewed-by: jdv, tr, psadhukhan
 - 8294751: Zero: Allow larger default heaps
   
   Reviewed-by: iklam, rkennke
 - 6616245: NullPointerException when using JFileChooser with a custom FileView
   
   Reviewed-by: aivanov
 - 8291519: jdk/jfr/api/event/TestShouldCommit.java failed with Unexpected value of shouldCommit()
   
   Reviewed-by: mgronlun
 - 8293782: Shenandoah: some tests failed on lock rank check
   
   Reviewed-by: mdoerr, shade
 - 8282395: URL.openConnection can throw IOOBE
   
   Reviewed-by: dfuchs
 - 8294958: java/net/httpclient/ConnectTimeout tests are slow
   
   Reviewed-by: dfuchs, aefimov
 - 8294356: IGV: scheduled graphs contain duplicated elements
   
   Reviewed-by: chagedorn, thartmann
 - 8294901: remove pre-VS2017 checks in Windows related coding
   
   Reviewed-by: dholmes, mdoerr, kbarrett
 - ... and 29 more: https://git.openjdk.org/jdk/compare/d738f35d...5af46570

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10606/files
  - new: https://git.openjdk.org/jdk/pull/10606/files/d738f35d..5af46570

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

  Stats: 4199 lines in 126 files changed: 3306 ins; 375 del; 518 mod
  Patch: https://git.openjdk.org/jdk/pull/10606.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10606/head:pull/10606

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


From aivanov at openjdk.org  Tue Oct 11 13:50:58 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Oct 2022 13:50:58 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <nDQmbmLEjsXkX8ZiCHLPWIdek8QO364h84ObYSK0YdI=.6b99ed5b-6086-41bf-aa9c-df43b1bed70e@github.com>
References: <nDQmbmLEjsXkX8ZiCHLPWIdek8QO364h84ObYSK0YdI=.6b99ed5b-6086-41bf-aa9c-df43b1bed70e@github.com>
Message-ID: <OBk3gZlfqApXKUO8hKqo-EkjGnXlpOMRQO1Iqp2wKlQ=.7e287a5a-7e52-4c11-bc37-1d84636187a6@github.com>

On Fri, 7 Oct 2022 13:36:17 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
> 
> Fix:
> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.

You did something wrong, now there are 40 commits and 126 files changed. It doesn't look right.

Merging master should result in one commit only even though it brings multiple commits into the history.

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

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


From mvs at openjdk.org  Tue Oct 11 14:10:36 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 11 Oct 2022 14:10:36 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <OBk3gZlfqApXKUO8hKqo-EkjGnXlpOMRQO1Iqp2wKlQ=.7e287a5a-7e52-4c11-bc37-1d84636187a6@github.com>
References: <nDQmbmLEjsXkX8ZiCHLPWIdek8QO364h84ObYSK0YdI=.6b99ed5b-6086-41bf-aa9c-df43b1bed70e@github.com>
 <OBk3gZlfqApXKUO8hKqo-EkjGnXlpOMRQO1Iqp2wKlQ=.7e287a5a-7e52-4c11-bc37-1d84636187a6@github.com>
Message-ID: <gvXtlQSZJcK-bvmvQcFrxxpBuuj-GaXI04ZGnr3O5vE=.ff955b38-df86-4dbb-9f8c-2297a9386067@github.com>

On Tue, 11 Oct 2022 13:48:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> You did something wrong, now there are 40 commits and 126 files changed. It doesn't look right.
> 
> Merging master should result in one commit only even though it brings multiple commits into the history.

Yea, I have seen that. I tried to fix it, but its not working, will delete this branch and create a new one.

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

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


From mvs at openjdk.org  Tue Oct 11 14:10:37 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 11 Oct 2022 14:10:37 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v2]
In-Reply-To: <iJNhPcRH6O3ARrmFyiTfpbsUbTlEwmZU6gbW-rCcptk=.866654ba-697b-4602-8f3c-2e19d9e34168@github.com>
References: <nDQmbmLEjsXkX8ZiCHLPWIdek8QO364h84ObYSK0YdI=.6b99ed5b-6086-41bf-aa9c-df43b1bed70e@github.com>
 <mb_WFScum4x3-ifE0b3VKvwXwfifLooAOv9xZCu0ans=.e8b08cbe-f6e4-47d2-a5fa-835da1f27ebe@github.com>
 <WFmel4UuNL0uNFXvR2IJQgn-AcjMxrZriEYyIGGRcy0=.633884c0-d888-496b-95b4-be237a2aee41@github.com>
 <iJNhPcRH6O3ARrmFyiTfpbsUbTlEwmZU6gbW-rCcptk=.866654ba-697b-4602-8f3c-2e19d9e34168@github.com>
Message-ID: <gzNi1ZxiBE41wJT6tEQjhEZjB6ZEOLxu0ZCVRJimEzM=.bf685771-545d-40d4-af56-8a42a5eae8af@github.com>

On Mon, 10 Oct 2022 17:59:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> But, is there any way we can capture the current screen where the frame is displayed?
>
> You can pass coordinates/bounds of that screen to the createScreenCapture.

Will do that in a new PR as something went wrong with this and some unnecessary commits got added

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

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


From mvs at openjdk.org  Tue Oct 11 14:12:33 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 11 Oct 2022 14:12:33 GMT
Subject: Withdrawn: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <nDQmbmLEjsXkX8ZiCHLPWIdek8QO364h84ObYSK0YdI=.6b99ed5b-6086-41bf-aa9c-df43b1bed70e@github.com>
References: <nDQmbmLEjsXkX8ZiCHLPWIdek8QO364h84ObYSK0YdI=.6b99ed5b-6086-41bf-aa9c-df43b1bed70e@github.com>
Message-ID: <ea6CNUomuFcZi_BGX1Yb1aZ2NMHPZ5NeEKL7ZQffgvw=.15de385e-adc0-46b5-b76e-d0870f6c3f29@github.com>

On Fri, 7 Oct 2022 13:36:17 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
> 
> Fix:
> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.

This pull request has been closed without being integrated.

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

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


From mvs at openjdk.org  Tue Oct 11 14:27:25 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 11 Oct 2022 14:27:25 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is unstable in
 MacOS machines
Message-ID: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>

java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.

Fix:
Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
Also updated the screen capture code, made frame undecorated, added some prints for better debugging.

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

Commit messages:
 - 8288415: java/awt/PopupMenu/PopupMenuLocation.java is unstable in MacOS machines

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

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


From dnguyen at openjdk.org  Tue Oct 11 18:17:16 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 11 Oct 2022 18:17:16 GMT
Subject: RFR: 8294254: [macOS]
 javax/swing/plaf/aqua/CustomComboBoxFocusTest.java failure [v2]
In-Reply-To: <RpUWenLwY8A71B5_BS2O7A1HIRU1qIfaWgDd7eAIvso=.c7f451f4-07a0-4c78-9d4c-fa35314c003e@github.com>
References: <XmBIB7o0eNNj0Pq2udzXOSo0DtC0rO9s9bEqJSOJVx8=.64ffb7a6-0498-41b9-95ad-172b165826c3@github.com>
 <AcQY1jED4CA6__TIdnit-sElejd1aDSIrOAG96_D8-E=.bfd71671-273b-4572-b405-0b898415a079@github.com>
 <RpUWenLwY8A71B5_BS2O7A1HIRU1qIfaWgDd7eAIvso=.c7f451f4-07a0-4c78-9d4c-fa35314c003e@github.com>
Message-ID: <Ikp_AGqRAIfZeXPBGBrq7wTL7E2xUTJ__xiiSnvIuwg=.24ef672d-2074-4351-9336-769688a2f81b@github.com>

On Tue, 11 Oct 2022 07:08:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge branch 'master' into 8294254/overlapFixEditableCombobox
>>  - Merge branch 'openjdk:master' into 8294254/overlapFixEditableCombobox
>>  - Remove test from problem list
>>  - Adjust rect width to remove overlap
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 478:
> 
>> 476:             else {
>> 477:                 return new Rectangle(insets.left + buttonSize, insets.top + midHeight,
>> 478:                         width - (insets.left + insets.right + buttonSize) + 3,
> 
> I guess previous to this fix, we were using BasicComboBoxUI#rectangleForCurrentValue() which returns a width on which we add +4 for editor/textField width.
> Since the calculation is basically same for width, why was it giving problem now (where only height is modified in the 8054572 fix) and not before this fix. I dont think this test use to fail before this fix was integrated with promoted CI builds

Previously, editable comboboxes on macOS were misaligned altogether. The button and textfield were not at the same height (as seen on the "before" screenshots in [https://bugs.openjdk.org/browse/JDK-8054572](https://bugs.openjdk.org/browse/JDK-8054572)). My assumption is that these pixels that would normally overlap are no longer overlapping because of this.

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

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


From dnguyen at openjdk.org  Tue Oct 11 18:54:44 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 11 Oct 2022 18:54:44 GMT
Subject: RFR: 8294254: [macOS]
 javax/swing/plaf/aqua/CustomComboBoxFocusTest.java failure [v3]
In-Reply-To: <XmBIB7o0eNNj0Pq2udzXOSo0DtC0rO9s9bEqJSOJVx8=.64ffb7a6-0498-41b9-95ad-172b165826c3@github.com>
References: <XmBIB7o0eNNj0Pq2udzXOSo0DtC0rO9s9bEqJSOJVx8=.64ffb7a6-0498-41b9-95ad-172b165826c3@github.com>
Message-ID: <fICu-UYzbE8XTakT7lC1TERKhoqaeqtH4LQ_S8dUjD8=.58329a74-002c-475b-b658-1bba811d64ae@github.com>

> The previous change to AquaComboBoxUI had 1 pixel of overlap between the text field and the combo button. This caused a few pixels to darken sometimes when an editable combobox is displayed. Since this test passes sometimes and fails some other times, it was not initially detected.
> 
> Since these few darkening pixels occur due to the change in AquaComboBoxUI, no reasonable change to the test could really be made, and the change would need to be to the class for the combobox. This fix was tested with a high count repeat and no failures occurred for various macOS systems.
> 
> Also removing the test from the problem list.

Damon Nguyen has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch '8294254/overlapFixEditableCombobox' of github.com:DamonGuy/jdk into 8294254/overlapFixEditableCombobox
 - Set uiscale

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10626/files
  - new: https://git.openjdk.org/jdk/pull/10626/files/6ee1f92f..8c0e0d8e

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

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

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


From dnguyen at openjdk.org  Tue Oct 11 18:54:46 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 11 Oct 2022 18:54:46 GMT
Subject: RFR: 8294254: [macOS]
 javax/swing/plaf/aqua/CustomComboBoxFocusTest.java failure [v2]
In-Reply-To: <hvtPJEr2r9rFYXp6mZpeG9L91i0tfd2vE5Ctu4wtgUQ=.da27ce6c-b850-48ef-b21a-a0a24737f413@github.com>
References: <XmBIB7o0eNNj0Pq2udzXOSo0DtC0rO9s9bEqJSOJVx8=.64ffb7a6-0498-41b9-95ad-172b165826c3@github.com>
 <AcQY1jED4CA6__TIdnit-sElejd1aDSIrOAG96_D8-E=.bfd71671-273b-4572-b405-0b898415a079@github.com>
 <hvtPJEr2r9rFYXp6mZpeG9L91i0tfd2vE5Ctu4wtgUQ=.da27ce6c-b850-48ef-b21a-a0a24737f413@github.com>
Message-ID: <eeD3j1zSpu_SQnSM8bzVbcrizBtsF-2ZqLgwm_ZcAoc=.ab17be7b-6b5b-4a96-9382-ff489398518c@github.com>

On Mon, 10 Oct 2022 19:05:50 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Suggestion: Does running the test - CustomComboBoxFocusTest.java with uiScale always set to 1 make it more robust?

Sure, I can add a uiscale of 1 for robustness. Seems like a good idea since Jay's results at different uiscales may show variable pass rates at different uiscales.

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

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


From duke at openjdk.org  Tue Oct 11 19:59:00 2022
From: duke at openjdk.org (SWinxy)
Date: Tue, 11 Oct 2022 19:59:00 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
Message-ID: <BeUclrj6qIhfsOLWEISaLk3dgywTEFDxkNN-aXYMTjk=.76793d39-f33a-4b4d-b310-38d08876c109@github.com>

On Tue, 11 Oct 2022 14:17:42 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
> 
> Fix:
> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
> Also updated the screen capture code, made frame undecorated, added some prints for better debugging.

So, what's the difference between this and #9187 and #10606? And did one of them have git issues?

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

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


From psadhukhan at openjdk.org  Wed Oct 12 04:23:18 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 12 Oct 2022 04:23:18 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v4]
In-Reply-To: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
Message-ID: <S-SfFFGx5fboV595-6zUv_zQ226UC4MPNiZYb4kGjm0=.e47376d7-de90-47e6-8d29-a9c102832739@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.

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

  Review comment to exclude MAX_VALUE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10409/files
  - new: https://git.openjdk.org/jdk/pull/10409/files/b70c6ad7..23d59222

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

  Stats: 42 lines in 2 files changed: 26 ins; 11 del; 5 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 psadhukhan at openjdk.org  Wed Oct 12 04:23:19 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 12 Oct 2022 04:23:19 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v4]
In-Reply-To: <k9VN9h1D3GOx-qR7rOkOI8Toz7eMX4Zvq2GJt8wJP1o=.7f18aa56-be2a-46db-977a-9e45ce1f2c42@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>
 <KT0UHwEiZuPO2uS1XWDJrlk1wFRdEsgVs1b_IBR3kSM=.2c862a0b-3222-485e-b713-bdd12a7f4097@github.com>
 <totUL5_2P1GiiDSP3wNt_EyGEZBosBgroBsHk1EqJhc=.968bb83e-b446-4e41-84f7-981d78911e17@github.com>
 <m1e0DU7f3Ek3U-j4uM_Rib9lD5F0TOg-_7Px4UtmKlI=.0616c53d-f7a1-4c8b-9bd8-a66b0e647e3c@github.com>
 <k9VN9h1D3GOx-qR7rOkOI8Toz7eMX4Zvq2GJt8wJP1o=.7f18aa56-be2a-46db-977a-9e45ce1f2c42@github.com>
Message-ID: <pb4ud4okznMmxGdLtjIzbeqfq87M3_96aaQizvfYv90=.d75b9880-3914-4ef2-aa1f-8218c87c6f1c@github.com>

On Fri, 7 Oct 2022 19:50:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I guess Integer.MAX_VALUE should be valid "int" value, its because of internal calculation which is causing it to overflow so I guess we should not update the spec for wrongful calculation. 
>> I have fixed the overflow in setSelectionInterval.
>
> This is not a generic class, its main purpose is to handle list selection in UI components, such as `JList`. Excluding `Integer.MAX_VALUE` makes sense to me, it simplifies the code: no additional check in the loop and no special handling `removeIndexInterval` which also adds a condition to the loop.

OK. Practically, it seems right as list probably may not have MAX_VALUE entries..Updated to exclude MAX_VALUE and updated the javadoc.

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

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


From ihse at openjdk.org  Wed Oct 12 09:52:26 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 09:52:26 GMT
Subject: RFR: 8295205: Add jcheck whitespace checking for markdown files
Message-ID: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>

Markdown files are basically source code for documentation. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

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

Commit messages:
 - 8295205: Add jcheck whitespace checking for markdown files

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

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


From ihse at openjdk.org  Wed Oct 12 10:31:51 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 10:31:51 GMT
Subject: RFR: 8295211: Fix autoconf 2.71 warning
 "AC_CHECK_HEADERS: you should use literals"
Message-ID: <TFuckcu3wKtT0Cq53Ti_mAli1s-JLUxTtuFBEeVO7sw=.745e1a6f-998c-47f1-8d35-5ee13223b0b6@github.com>

In autoconf 2.71, there is a warning generated for calling AC_CHECK_HEADERS with a variable.

It is not clear to me why they consider this to be a problem, but the warning is printed whenever you run configure with autoconf 2.71 or newer, and it is annoying.

We're only doing this in one place. Let's hardcode the values instead so we get rid of the warning.

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

Commit messages:
 - 8295211: Fix autoconf 2.71 warning "AC_CHECK_HEADERS: you should use literals"

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

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


From ihse at openjdk.org  Wed Oct 12 11:03:13 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 11:03:13 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: <-2yChViV1cpNVUS3HMzM3d9I7J3ReBWr9G2w3skxF9M=.034c3f7f-d7fd-4961-a468-e250ac876062@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 Do you think you can approve this now, so we can finally close it? (I promise I won't open huge PRs like this in the future; lesson well learnt.)

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

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


From ihse at openjdk.org  Wed Oct 12 11:24:17 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 11:24:17 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v11]
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <qBSXGkjfwNWatB2ur-Lr_FcPctqCFo0XlyjJfcM6hfo=.df53e761-0ba4-47f7-917e-61ec70ffc721@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 50 commits:

 - Merge branch 'master' into typos-in-java.desktop
 - 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>
 - ... and 40 more: https://git.openjdk.org/jdk/compare/bdb4ed0f...e2d0979f

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

Changes: https://git.openjdk.org/jdk/pull/8328/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8328&range=10
  Stats: 1017 lines in 483 files changed: 0 ins; 0 del; 1017 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 erikj at openjdk.org  Wed Oct 12 13:19:22 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 12 Oct 2022 13:19:22 GMT
Subject: RFR: 8295205: Add jcheck whitespace checking for markdown files
In-Reply-To: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
References: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
Message-ID: <2owj2BREdvPlEo70s1rAvPywZeUPcimsej24fiAHyB4=.26f3a76b-0765-49ea-882d-591748bf1dcf@github.com>

On Wed, 12 Oct 2022 09:44:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Markdown files are basically source code for documentation. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

Thank you! Since I enabled visible whitespace in emacs (to be able to properly edit makefiles) editing any file where trailing whitespace isn't enforced makes my eyes bleed. :)

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

Marked as reviewed by erikj (Reviewer).

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


From ihse at openjdk.org  Wed Oct 12 13:34:32 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 13:34:32 GMT
Subject: Integrated: 8295205: Add jcheck whitespace checking for markdown files
In-Reply-To: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
References: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
Message-ID: <4JUC33BHEbQxyvmLXseCLGOGURYFR_6f0uHcyJaGUkc=.cb1528a9-2718-4bfc-9a70-dce6a9e4db00@github.com>

On Wed, 12 Oct 2022 09:44:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Markdown files are basically source code for documentation. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

This pull request has now been integrated.

Changeset: 86078423
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/860784238ea1f3e4a817fc3c28fb89cfee7549dd
Stats:     34 lines in 9 files changed: 0 ins; 0 del; 34 mod

8295205: Add jcheck whitespace checking for markdown files

Reviewed-by: erikj

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

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


From serb at openjdk.org  Wed Oct 12 21:19:15 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 12 Oct 2022 21:19:15 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v9]
In-Reply-To: <lX-Q2pAERYf6ieC7xcmWpaJHQraPLI-q5Z0p8gr0bVM=.f0f57b95-7fef-45fe-a4a9-f9b73749f168@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <H5OWwPvbDv9LxfyICK-DcPu_dAU7AfZN-AFTfCD5NJc=.509dc09c-525a-4942-aaa4-fa31dbe3fca6@github.com>
 <lMbemiq6UAVbkoCn2e8emYkiDxE8xZevDk7CzSzxVD8=.92837723-cfaa-4f3d-a525-c9dd90968e04@github.com>
 <lX-Q2pAERYf6ieC7xcmWpaJHQraPLI-q5Z0p8gr0bVM=.f0f57b95-7fef-45fe-a4a9-f9b73749f168@github.com>
Message-ID: <za9wIkiE_XwCl_HMgEHZ4JBvB5bxueSTidZnRrhasS8=.fa72d653-07cb-4c63-b41d-88d731c10b64@github.com>

On Fri, 7 Oct 2022 22:01:00 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 292:
>> 
>>> 290:                 height = Region.clipRound(at.getScaleY() * h);
>>> 291:                 xtranslation = Region.clipRound(at.getScaleX() * x + at.getTranslateX());
>>> 292:                 ytranslation = Region.clipRound(at.getScaleY() * y + at.getTranslateY());
>> 
>> This probably should be refactored to something like this:
>> https://github.com/openjdk/jdk/blob/ec4fb47b90c9737dfdc285ebe98367a221c90c79/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L375
>
> @mrserb Thank for the suggestion. Are you suggesting that same transformations be applied for width, height and additionally to x&y translations? 
> https://github.com/openjdk/jdk/blob/ec4fb47b90c9737dfdc285ebe98367a221c90c79/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L373

The methods like Rigion.dimAdd/clipScale should be used everywhere the overflow is possible.

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

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


From serb at openjdk.org  Wed Oct 12 21:25:09 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 12 Oct 2022 21:25:09 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v6]
In-Reply-To: <gojBDXuBwsy2q7ViZ_vBlSbLDi1vrtWI8edK9xm43Dw=.b37d240e-3036-404a-90df-9f88344565e1@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
 <gojBDXuBwsy2q7ViZ_vBlSbLDi1vrtWI8edK9xm43Dw=.b37d240e-3036-404a-90df-9f88344565e1@github.com>
Message-ID: <oMeydNLLGMcgBVitJO0UUcCBRQyrWMfFutV8lMtx-_Y=.80d8b996-205e-458b-89ad-08094b0c14c6@github.com>

On Fri, 7 Oct 2022 08:40:42 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:
> 
>   Set foreground in installDefaults

It would be good to understand how all that properties are handled by the skin.
For example can you please check how the next property in the NimbusDefaults.java is handled by the L&F.
`addColor(d, "Label[Disabled].textForeground", "nimbusDisabledText", 0.0f, 0.0f, 0.0f, 0);`
Does it works fine? If yes probably we should add something like
`addColor(d, "Label[Enabled].textForeground", "nimbusDisabledText", 0.0f, 0.0f, 0.0f, 0);`
?

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

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


From aivanov at openjdk.org  Wed Oct 12 21:28:10 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Oct 2022 21:28:10 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v9]
In-Reply-To: <za9wIkiE_XwCl_HMgEHZ4JBvB5bxueSTidZnRrhasS8=.fa72d653-07cb-4c63-b41d-88d731c10b64@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <H5OWwPvbDv9LxfyICK-DcPu_dAU7AfZN-AFTfCD5NJc=.509dc09c-525a-4942-aaa4-fa31dbe3fca6@github.com>
 <lMbemiq6UAVbkoCn2e8emYkiDxE8xZevDk7CzSzxVD8=.92837723-cfaa-4f3d-a525-c9dd90968e04@github.com>
 <lX-Q2pAERYf6ieC7xcmWpaJHQraPLI-q5Z0p8gr0bVM=.f0f57b95-7fef-45fe-a4a9-f9b73749f168@github.com>
 <za9wIkiE_XwCl_HMgEHZ4JBvB5bxueSTidZnRrhasS8=.fa72d653-07cb-4c63-b41d-88d731c10b64@github.com>
Message-ID: <94T9OU47fx7zjD8iKd9T89YvHP-8gxlZJusN7fJX7n4=.ee9c1377-67c5-4766-9883-54c2131941bc@github.com>

On Wed, 12 Oct 2022 21:16:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @mrserb Thank for the suggestion. Are you suggesting that same transformations be applied for width, height and additionally to x&y translations? 
>> https://github.com/openjdk/jdk/blob/ec4fb47b90c9737dfdc285ebe98367a221c90c79/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L373
>
> The methods like Rigion.dimAdd/clipScale should be used everywhere the overflow is possible.

Thank you, @mrserb, for your suggestion. I didn't know about those methods.

We already have [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) to refactor this code. If you don't object, I'd rather postpone updating the calculations to a later time. We should absolutely re-use the existing code if it does the same thing.

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

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


From serb at openjdk.org  Wed Oct 12 21:33:18 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 12 Oct 2022 21:33:18 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v4]
In-Reply-To: <Tu0tvbli3VGWB5CYS6X713_c2xHSoB4BvQLekqE-n1U=.16c5c4ff-d72c-4834-842d-b59a17b5071f@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@github.com>
 <HLpFGnS30XHDe9_HAEPVR3P-sAOtuO-bR2Klt2wFjhI=.9618ae1c-7e39-4acf-b2eb-9ce55fec9f1e@github.com>
 <iGJG-n1plA-QXx-YlFSdwy-pTCzGu4Bl_cvUuAP7dJg=.75277867-433c-48f0-a95c-ab5a327ce8aa@github.com>
 <uwL1xSQ2_2tFiR2QAwUdhuQlnw0qrE1gGm_8efXiApU=.1c479d23-5885-4971-bd05-7bbdc41fc069@github.com>
 <Tu0tvbli3VGWB5CYS6X713_c2xHSoB4BvQLekqE-n1U=.16c5c4ff-d72c-4834-842d-b59a17b5071f@github.com>
Message-ID: <2U1zChzBva4BAT9holXMofyEaw94-0TakLj7HA2PoLU=.f09e788e-a5b9-4d15-adf3-cfcd649fa7a1@github.com>

On Mon, 10 Oct 2022 11:27:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Ok, since the test has to select non traversable folders in both windows and linux I had thought that making it as manual would be better.
>
> Yet you control which folders are non-traversable. Anyway? A test is better than no test; an automatic test is better than a manual one.

Probably it will be good to automate it, and cover the macOS? I do not see a reason why we cannot set Metal L&F and verify the fix.

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

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


From serb at openjdk.org  Wed Oct 12 21:45:14 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 12 Oct 2022 21:45: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: <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: <GQrpOlGj1QqGsDQr1kjLDZHj5C9pP0dKWNxb9ZjJ0eA=.ec057811-eb88-41dd-8180-98a45cfef73a@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

The spec for the changed method mention that the "getColorForState" should be called for the component if the app did not specify the color explicetly. Should the fix do the same instead of direct call of "UIManager.getColor"? And if it does not work should we updated the skin to include these props?

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

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


From tr at openjdk.org  Thu Oct 13 04:54:18 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 13 Oct 2022 04:54:18 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v4]
In-Reply-To: <2U1zChzBva4BAT9holXMofyEaw94-0TakLj7HA2PoLU=.f09e788e-a5b9-4d15-adf3-cfcd649fa7a1@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@github.com>
 <HLpFGnS30XHDe9_HAEPVR3P-sAOtuO-bR2Klt2wFjhI=.9618ae1c-7e39-4acf-b2eb-9ce55fec9f1e@github.com>
 <iGJG-n1plA-QXx-YlFSdwy-pTCzGu4Bl_cvUuAP7dJg=.75277867-433c-48f0-a95c-ab5a327ce8aa@github.com>
 <uwL1xSQ2_2tFiR2QAwUdhuQlnw0qrE1gGm_8efXiApU=.1c479d23-5885-4971-bd05-7bbdc41fc069@github.com>
 <Tu0tvbli3VGWB5CYS6X713_c2xHSoB4BvQLekqE-n1U=.16c5c4ff-d72c-4834-842d-b59a17b5071f@github.com>
 <2U1zChzBva4BAT9holXMofyEaw94-0TakLj7HA2PoLU=.f09e788e-a5b9-4d15-adf3-cfcd649fa7a1@github.com>
Message-ID: <KJN01VzqTGhTfaevD3UWuwf04Z1hM-IOv4qHamnyl6Q=.2691b78e-0cb0-409c-b8e6-abec907bb9fd@github.com>

On Wed, 12 Oct 2022 21:30:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yet you control which folders are non-traversable. Anyway? A test is better than no test; an automatic test is better than a manual one.
>
> Probably it will be good to automate it, and cover the macOS? I do not see a reason why we cannot set Metal L&F and verify the fix.

I wasn't able to reproduce the issue in macOS, so didn't include it in test...... And the fix is for metal L&F and should we explicitly set the L&F? Anyhow default L&F is metal right....?

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

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


From aturbanov at openjdk.org  Thu Oct 13 07:00:11 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 13 Oct 2022 07:00:11 GMT
Subject: Integrated: 8293984: Unnecessary Vector usage in PropertyEditorSupport
In-Reply-To: <d_Iu8wlX0aPiKtfN2F6okrdy8lyeM8zzG8F8Dett58E=.1bfbea3a-8bd1-4b46-8f14-8a860049081f@github.com>
References: <d_Iu8wlX0aPiKtfN2F6okrdy8lyeM8zzG8F8Dett58E=.1bfbea3a-8bd1-4b46-8f14-8a860049081f@github.com>
Message-ID: <RsMvrUPpP1gf0vdEzw_axG04gpOeCp7l2KVI1EwYrr4=.0b360208-f91d-462e-b233-c03f4d7b7c1d@github.com>

On Mon, 19 Sep 2022 06:55:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Field PropertyEditorSupport.listeners is accessed only under `synchronized(this)`.
> It means extra synchronization by Vector is not needed.

This pull request has now been integrated.

Changeset: 6ae7e4d4
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6ae7e4d4aad5712cf2fe6ab9f98dc424fa4170cb
Stats:     14 lines in 1 file changed: 0 ins; 5 del; 9 mod

8293984: Unnecessary Vector usage in PropertyEditorSupport

Reviewed-by: serb

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

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


From mvs at openjdk.org  Thu Oct 13 07:46:01 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Thu, 13 Oct 2022 07:46:01 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <BeUclrj6qIhfsOLWEISaLk3dgywTEFDxkNN-aXYMTjk=.76793d39-f33a-4b4d-b310-38d08876c109@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
 <BeUclrj6qIhfsOLWEISaLk3dgywTEFDxkNN-aXYMTjk=.76793d39-f33a-4b4d-b310-38d08876c109@github.com>
Message-ID: <NnRgO9MDppGiQfqTkUNmdIye0Cv3Z76IIPdE2his_RA=.1100e069-6216-4414-a0df-fe8d4e82d6ad@github.com>

On Tue, 11 Oct 2022 19:56:49 GMT, SWinxy <duke at openjdk.org> wrote:

> So, what's the difference between this and #9187 and #10606? And did one of them have git issues?

No, #9187 got closed automatically by bot after being inactive for 8 weeks. And difference between #9187 and #10606 are,
1. Improved the screen capture logic in #10606 to capture the corresponding screen where the frame is displayed.
2. Made the frame undecorated as I have seen in some linux machines that, sometimes the mouse click inadvertently goes to the frame header which in turn fails the test(as it will not invoke the popup menu).

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

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


From duke at openjdk.org  Thu Oct 13 16:19:33 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 13 Oct 2022 16:19:33 GMT
Subject: Integrated: 8288882: JFileChooser - empty (0 bytes) file is displayed
 as 1 KB
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <wV180ptyI5aYZ5UT0Y7gy6PKITN4trVIQuTz5GlOknw=.5b32eb54-cdc3-450d-a18f-7853114062b9@github.com>

On Wed, 29 Jun 2022 13:06:21 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 3b343875
Author:    Abhishek Kumar <abhishek.cx.kumar at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b3438752cbac49272dfda7d11adbeac0ab2ea9d
Stats:     167 lines in 2 files changed: 155 ins; 1 del; 11 mod

8288882: JFileChooser - empty (0 bytes) file is displayed as 1 KB

Reviewed-by: aivanov, angorya, psadhukhan

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

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


From duke at openjdk.org  Thu Oct 13 16:32:19 2022
From: duke at openjdk.org (Rajat Mahajan)
Date: Thu, 13 Oct 2022 16:32:19 GMT
Subject: RFR: 8282958: Rendering issues of borders,
 TextFields on Windows High-DPI systems
Message-ID: <K017iqdcECzNK9JlZU_Li549-fSzgqYdmg3reHdhg3A=.0dbb6742-95cd-4886-a94f-4b02781165e5@github.com>

This fix is based on a similar approach as described here  https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648.
We rescale the line border to render the Textfield border correctly, so that all sides of the Textfield border are of same thickness.

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

Commit messages:
 - remove executable permission
 - fix file ending
 - 8282958: Rendering issues of borders, TextFields on Windows High-DPI systems

Changes: https://git.openjdk.org/jdk/pull/10681/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10681&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282958
  Stats: 663 lines in 3 files changed: 658 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10681.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10681/head:pull/10681

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


From aivanov at openjdk.org  Thu Oct 13 20:33:10 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 13 Oct 2022 20:33:10 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v4]
In-Reply-To: <KJN01VzqTGhTfaevD3UWuwf04Z1hM-IOv4qHamnyl6Q=.2691b78e-0cb0-409c-b8e6-abec907bb9fd@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@github.com>
 <HLpFGnS30XHDe9_HAEPVR3P-sAOtuO-bR2Klt2wFjhI=.9618ae1c-7e39-4acf-b2eb-9ce55fec9f1e@github.com>
 <iGJG-n1plA-QXx-YlFSdwy-pTCzGu4Bl_cvUuAP7dJg=.75277867-433c-48f0-a95c-ab5a327ce8aa@github.com>
 <uwL1xSQ2_2tFiR2QAwUdhuQlnw0qrE1gGm_8efXiApU=.1c479d23-5885-4971-bd05-7bbdc41fc069@github.com>
 <Tu0tvbli3VGWB5CYS6X713_c2xHSoB4BvQLekqE-n1U=.16c5c4ff-d72c-4834-842d-b59a17b5071f@github.com>
 <2U1zChzBva4BAT9holXMofyEaw94-0TakLj7HA2PoLU=.f09e788e-a5b9-4d15-adf3-cfcd649fa7a1@github.com>
 <KJN01VzqTGhTfaevD3UWuwf04Z1hM-IOv4qHamnyl6Q=.2691b78e-0cb0-409c-b8e6-abec907bb9fd@github.com>
Message-ID: <V6ZPBCoy5BkNyvK0uiYQYNGuLYHqkpe9J85pavk9Vsc=.761a8343-5fe9-412a-8e15-5d97148e8570@github.com>

On Thu, 13 Oct 2022 04:52:02 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Probably it will be good to automate it, and cover the macOS? I do not see a reason why we cannot set Metal L&F and verify the fix.
>
> I wasn't able to reproduce the issue in macOS, so didn't include it in test...... And the fix is for metal L&F and should we explicitly set the L&F? Anyhow default L&F is metal right....?

> Probably it will be good to automate it

I've submitted [JDK-8295298](https://bugs.openjdk.org/browse/JDK-8295298): Automate javax/swing/JFileChooser/FileViewNPETest.java

> ? and cover the macOS? I do not see a reason why we cannot set Metal L&F and verify the fix.

Agreed.

> I wasn't able to reproduce the issue in macOS, so didn't include it in test...... And the fix is for metal L&F and should we explicitly set the L&F? Anyhow default L&F is metal right....?

The default Look and Feel is Metal except for macOS where the default one is Aqua which is the system L&F. The default L&F can be changed using a property file or setting the system property.

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

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


From prr at openjdk.org  Thu Oct 13 21:28:04 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 13 Oct 2022 21:28:04 GMT
Subject: RFR: 8295301: Problem list TrayIcon tests that fail on Ubuntu 22.04
Message-ID: <t88eCx_DCMQ3kF5nIEa12XxoRjeoc6JEWaGqTyZjR3k=.1d0632f6-ab98-4eb6-ab5c-7b14fcc59308@github.com>

7 TrayIcon tests fail on Ubuntu 22.04. We need to problem list them until this can be resolved.

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

Commit messages:
 - 8295301

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

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


From dholmes at openjdk.org  Thu Oct 13 21:35:11 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 13 Oct 2022 21:35:11 GMT
Subject: RFR: 8295301: Problem list TrayIcon tests that fail on Ubuntu
 22.04
In-Reply-To: <t88eCx_DCMQ3kF5nIEa12XxoRjeoc6JEWaGqTyZjR3k=.1d0632f6-ab98-4eb6-ab5c-7b14fcc59308@github.com>
References: <t88eCx_DCMQ3kF5nIEa12XxoRjeoc6JEWaGqTyZjR3k=.1d0632f6-ab98-4eb6-ab5c-7b14fcc59308@github.com>
Message-ID: <jTAlE0Yd-Ncenrng4gZGq09iYltPR_OvDTveCkWXUwQ=.239915e0-b3c2-4587-b506-e438db89102b@github.com>

On Thu, 13 Oct 2022 21:21:12 GMT, Phil Race <prr at openjdk.org> wrote:

> 7 TrayIcon tests fail on Ubuntu 22.04. We need to problem list them until this can be resolved.

LGTM.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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


From prr at openjdk.org  Thu Oct 13 21:40:01 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 13 Oct 2022 21:40:01 GMT
Subject: Integrated: 8295301: Problem list TrayIcon tests that fail on Ubuntu
 22.04
In-Reply-To: <t88eCx_DCMQ3kF5nIEa12XxoRjeoc6JEWaGqTyZjR3k=.1d0632f6-ab98-4eb6-ab5c-7b14fcc59308@github.com>
References: <t88eCx_DCMQ3kF5nIEa12XxoRjeoc6JEWaGqTyZjR3k=.1d0632f6-ab98-4eb6-ab5c-7b14fcc59308@github.com>
Message-ID: <HEcjPauio1Cv0dM120oVwkTCi_73PaCIi_D58A_6zko=.62f3b1b9-761c-47b1-858c-ac9e54dba329@github.com>

On Thu, 13 Oct 2022 21:21:12 GMT, Phil Race <prr at openjdk.org> wrote:

> 7 TrayIcon tests fail on Ubuntu 22.04. We need to problem list them until this can be resolved.

This pull request has now been integrated.

Changeset: fdb74ed4
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fdb74ed45240477bd08eb40ede5eaa2345ca6b5d
Stats:     7 lines in 1 file changed: 0 ins; 0 del; 7 mod

8295301: Problem list TrayIcon tests that fail on Ubuntu 22.04

Reviewed-by: dholmes

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

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


From tr at openjdk.org  Fri Oct 14 04:42:47 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 14 Oct 2022 04:42:47 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v4]
In-Reply-To: <V6ZPBCoy5BkNyvK0uiYQYNGuLYHqkpe9J85pavk9Vsc=.761a8343-5fe9-412a-8e15-5d97148e8570@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@github.com>
 <HLpFGnS30XHDe9_HAEPVR3P-sAOtuO-bR2Klt2wFjhI=.9618ae1c-7e39-4acf-b2eb-9ce55fec9f1e@github.com>
 <iGJG-n1plA-QXx-YlFSdwy-pTCzGu4Bl_cvUuAP7dJg=.75277867-433c-48f0-a95c-ab5a327ce8aa@github.com>
 <uwL1xSQ2_2tFiR2QAwUdhuQlnw0qrE1gGm_8efXiApU=.1c479d23-5885-4971-bd05-7bbdc41fc069@github.com>
 <Tu0tvbli3VGWB5CYS6X713_c2xHSoB4BvQLekqE-n1U=.16c5c4ff-d72c-4834-842d-b59a17b5071f@github.com>
 <2U1zChzBva4BAT9holXMofyEaw94-0TakLj7HA2PoLU=.f09e788e-a5b9-4d15-adf3-cfcd649fa7a1@github.com>
 <KJN01VzqTGhTfaevD3UWuwf04Z1hM-IOv4qHamnyl6Q=.2691b78e-0cb0-409c-b8e6-abec907bb9fd@github.com>
 <V6ZPBCoy5BkNyvK0uiYQYNGuLYHqkpe9J85pavk9Vsc=.761a8343-5fe9-412a-8e15-5d97148e8570@github.com>
Message-ID: <_ThHKmYvKqYhRNLoXCwIh6ykBNLlV8h9gITFBbaUElc=.23d55327-e2d8-404b-953b-00c64f27d7f4@github.com>

On Thu, 13 Oct 2022 20:01:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I wasn't able to reproduce the issue in macOS, so didn't include it in test...... And the fix is for metal L&F and should we explicitly set the L&F? Anyhow default L&F is metal right....?
>
>> Probably it will be good to automate it
> 
> I've submitted [JDK-8295298](https://bugs.openjdk.org/browse/JDK-8295298): Automate javax/swing/JFileChooser/FileViewNPETest.java
> 
>> ? and cover the macOS? I do not see a reason why we cannot set Metal L&F and verify the fix.
> 
> Agreed.
> 
>> I wasn't able to reproduce the issue in macOS, so didn't include it in test...... And the fix is for metal L&F and should we explicitly set the L&F? Anyhow default L&F is metal right....?
> 
> The default Look and Feel is Metal except for macOS where the default one is Aqua which is the system L&F. The default L&F can be changed using a property file or setting the system property.
> 
> You can always change the L&F in the code.

Ok will check in macOS again then.

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

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


From aturbanov at openjdk.org  Fri Oct 14 06:46:02 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 14 Oct 2022 06:46:02 GMT
Subject: Integrated: 8295026: Remove unused fields in StyleSheet
In-Reply-To: <9p71hu-CpTJ6dsy_0j2Rnks8TX7m4jyIgyGpeo8l18k=.9cfe4931-2d55-4ad8-bf67-78c05a13d7b7@github.com>
References: <9p71hu-CpTJ6dsy_0j2Rnks8TX7m4jyIgyGpeo8l18k=.9cfe4931-2d55-4ad8-bf67-78c05a13d7b7@github.com>
Message-ID: <q1I_NekQ6lj6AF2dxGzJcufDUtUUWpt4AYswxydVV4Y=.51123f47-1e2d-41ab-ba6c-a0ecef70e4d9@github.com>

On Sat, 1 Oct 2022 17:05:11 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There are 3 unused fields in single `StyleSheet` file:
> 1. `static final Border noBorder = new EmptyBorder(0,0,0,0);`
> 2. `static final int DEFAULT_FONT_SIZE = 3;`
> 3. `URL imageurl;` in nested `javax.swing.text.html.StyleSheet.ListPainter` class

This pull request has now been integrated.

Changeset: be3b3354
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/be3b3354523917c024fb9d7d99de7c7eec3d175a
Stats:     5 lines in 1 file changed: 0 ins; 5 del; 0 mod

8295026: Remove unused fields in StyleSheet

Reviewed-by: aivanov

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

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


From aturbanov at openjdk.org  Fri Oct 14 07:10:11 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 14 Oct 2022 07:10:11 GMT
Subject: RFR: 8295323: Unnecessary HashTable usage in StyleSheet
Message-ID: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>

Hashtable was used only from single thread. And only non-null key/values added to it. We can safely replace it with HashSet.

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

Commit messages:
 - [PATCH] Unnecessary HashTable usage in StyleSheet

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

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


From duke at openjdk.org  Fri Oct 14 07:10:11 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 14 Oct 2022 07:10:11 GMT
Subject: RFR: 8295323: Unnecessary HashTable usage in StyleSheet
In-Reply-To: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
References: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
Message-ID: <iR1IT4_fnOpf0QDXsvToT8uJXkASMb_FFkJbozapAiY=.fcb62fe5-e864-4dc5-845d-638ea5c0fdc2@github.com>

On Sat, 1 Oct 2022 16:53:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Hashtable was used only from single thread. And only non-null key/values added to it. We can safely replace it with HashSet.

src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 1364:

> 1362:                            HashSet<SelectorMapping> alreadyChecked) {
> 1363:         // Avoid descending the same mapping twice.
> 1364:         if (!alreadyChecked.add(parentMapping)) {

Clever!

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

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


From psadhukhan at openjdk.org  Fri Oct 14 09:06:40 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 14 Oct 2022 09:06:40 GMT
Subject: RFR: 7172359: HTML parser StackOverflowError on invalid HTML: <li>
 tag inside an <option> [v4]
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: <uya6WhOVB4w7gRgSodvSAntrI2tHZj_WnqY8sH3UElA=.6e8d64a9-4c20-4b59-9415-be4ac123468a@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:

  Add paranthesis

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10279/files
  - new: https://git.openjdk.org/jdk/pull/10279/files/46c477d8..c56601ee

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

  Stats: 1 line in 1 file changed: 0 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 psadhukhan at openjdk.org  Fri Oct 14 09:08:23 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 14 Oct 2022 09:08:23 GMT
Subject: Integrated: 7172359: HTML parser StackOverflowError on invalid HTML:
 <li> tag inside an <option>
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: <jOU1Z4m8PF-h2dsNmw9aXqySDFzEA4mXsHMhMTk1i9E=.66b4e3dc-d9ee-4a8d-afbf-27ba10f53655@github.com>

On Thu, 15 Sep 2022 08:05:29 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.

This pull request has now been integrated.

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

7172359: HTML parser StackOverflowError on invalid HTML: <li> tag inside an <option>

Reviewed-by: tr, jdv, aivanov

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

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


From tr at openjdk.org  Fri Oct 14 09:15:30 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 14 Oct 2022 09:15:30 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <UqrobmjXWb8o1KBWydL6ct_RblQvTdus_kMW1Id9gbY=.3b6e55f6-b5d5-4abe-9b2f-4fc519f2a494@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>
 <hhovPbK-E9zFYe8naRtdI0KrJNjieKGKklq8qW1ygY4=.f4ae4916-f4b0-432d-a5f6-02ef66edd307@github.com>
 <NFqU4oxo-9fiYaS3Lvdn3xFdHtj4PV1ikw3bj455gxQ=.4cb1bfb3-8bc6-47a6-8e55-dd791c719fa4@github.com>
 <UqrobmjXWb8o1KBWydL6ct_RblQvTdus_kMW1Id9gbY=.3b6e55f6-b5d5-4abe-9b2f-4fc519f2a494@github.com>
Message-ID: <6h5OAsRt-a5_Rr7JmN6OeNrsor7q2xOOyLwFPYFRXjc=.fc7daf33-525b-4bc8-9149-6d6c6caae590@github.com>

On Mon, 10 Oct 2022 16:17:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Yeah, was not able to reproduce in macOS.
>
> You can set Metal L&F explicitly on macOS.

Yeah, I checked it now and the issue is reproducible in macOS also, have to update the test to include macOS.

Had thought that default L&F in macOS will be metal, didn't realize have to set it explicitly. My mistake, thank you @aivanov-jdk and @mrserb for pointing it out.

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

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


From tr at openjdk.org  Fri Oct 14 09:15:30 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 14 Oct 2022 09:15:30 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v4]
In-Reply-To: <_ThHKmYvKqYhRNLoXCwIh6ykBNLlV8h9gITFBbaUElc=.23d55327-e2d8-404b-953b-00c64f27d7f4@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <tQdIA_OwBn1AT34qvAQb0X5iMnHrQtOHv8wBI8JnDEM=.3c19e77b-e3ec-4c4e-961e-840cc0e7d481@github.com>
 <HLpFGnS30XHDe9_HAEPVR3P-sAOtuO-bR2Klt2wFjhI=.9618ae1c-7e39-4acf-b2eb-9ce55fec9f1e@github.com>
 <iGJG-n1plA-QXx-YlFSdwy-pTCzGu4Bl_cvUuAP7dJg=.75277867-433c-48f0-a95c-ab5a327ce8aa@github.com>
 <uwL1xSQ2_2tFiR2QAwUdhuQlnw0qrE1gGm_8efXiApU=.1c479d23-5885-4971-bd05-7bbdc41fc069@github.com>
 <Tu0tvbli3VGWB5CYS6X713_c2xHSoB4BvQLekqE-n1U=.16c5c4ff-d72c-4834-842d-b59a17b5071f@github.com>
 <2U1zChzBva4BAT9holXMofyEaw94-0TakLj7HA2PoLU=.f09e788e-a5b9-4d15-adf3-cfcd649fa7a1@github.com>
 <KJN01VzqTGhTfaevD3UWuwf04Z1hM-IOv4qHamnyl6Q=.2691b78e-0cb0-409c-b8e6-abec907bb9fd@github.com>
 <V6ZPBCoy5BkNyvK0uiYQYNGuLYHqkpe9J85pavk9Vsc=.761a8343-5fe9-412a-8e15-5d97148e8570@github.com>
 <_ThHKmYvKqYhRNLoXCwIh6ykBNLlV8h9gITFBbaUElc=.23d55327-e2d8-404b-953b-00c64f27d7f4@github.com>
Message-ID: <B-EpsVNOStZ3fbAnbNSjcovSD-l763z6RIp80DQWCcU=.58fb8fd6-b4c9-4687-9518-e5ea97812112@github.com>

On Fri, 14 Oct 2022 04:39:02 GMT, Tejesh R <tr at openjdk.org> wrote:

>>> Probably it will be good to automate it
>> 
>> I've submitted [JDK-8295298](https://bugs.openjdk.org/browse/JDK-8295298): Automate javax/swing/JFileChooser/FileViewNPETest.java
>> 
>>> ? and cover the macOS? I do not see a reason why we cannot set Metal L&F and verify the fix.
>> 
>> Agreed.
>> 
>>> I wasn't able to reproduce the issue in macOS, so didn't include it in test...... And the fix is for metal L&F and should we explicitly set the L&F? Anyhow default L&F is metal right....?
>> 
>> The default Look and Feel is Metal except for macOS where the default one is Aqua which is the system L&F. The default L&F can be changed using a property file or setting the system property.
>> 
>> You can always change the L&F in the code.
>
> Ok will check in macOS again then.

Sorry, I had not set Metal L&F while checking in macOS, the is reproducible in macOS also, and the test case has to be updated for macOS.

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

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


From psadhukhan at openjdk.org  Fri Oct 14 09:16:27 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 14 Oct 2022 09:16:27 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v5]
In-Reply-To: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
Message-ID: <G-xU8XRZeIuOZ3G2IV1g8IYw4PAStyR9tU5xh8zIMDc=.06f7cd80-4bb4-44de-afdb-966796b16a2c@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.

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

  javadoc update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10409/files
  - new: https://git.openjdk.org/jdk/pull/10409/files/23d59222..ee43bd8d

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

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 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 psadhukhan at openjdk.org  Fri Oct 14 09:28:05 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 14 Oct 2022 09:28:05 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v5]
In-Reply-To: <G-xU8XRZeIuOZ3G2IV1g8IYw4PAStyR9tU5xh8zIMDc=.06f7cd80-4bb4-44de-afdb-966796b16a2c@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <G-xU8XRZeIuOZ3G2IV1g8IYw4PAStyR9tU5xh8zIMDc=.06f7cd80-4bb4-44de-afdb-966796b16a2c@github.com>
Message-ID: <mtsFI2JxGJiqcetPaBOrdQ24PR7fil4dDwJrVJ-Vc8Q=.82426199-e4f3-4e25-bb0a-ae269319c129@github.com>

On Fri, 14 Oct 2022 09:16:27 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.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc update

CSR raised..https://bugs.openjdk.org/browse/JDK-8295329...please review

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

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


From tnakamura at openjdk.org  Fri Oct 14 09:29:46 2022
From: tnakamura at openjdk.org (Toshio Nakamura)
Date: Fri, 14 Oct 2022 09:29:46 GMT
Subject: RFR: 8295248: JEditorPane HTML form with multi selection broke drawing
 after reseting
Message-ID: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>

When JEditorPane shown HTML form with multi-selection, the reset operation broke its drawing.

There are two issues. The current method `OptionListModel.removeIndexInterval()` disabled selections, but it didn't fire the change. Then, no re-drawing. Another issue is the method works as remove and shift. Then, selection values were corrupted.
I think the clear method `OptionListModel.clearSelection()` is suitable here.

Test: jdk_desktop on macOS (x64, Monterey), Linux (x64, RHEL8), and Windows (x64, 2012R2).
      No regression found

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

Commit messages:
 - 8295248: JEditorPane HTML form with multi selection broke drawing after reseting

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

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


From duke at openjdk.org  Fri Oct 14 13:37:06 2022
From: duke at openjdk.org (Nikita Provotorov)
Date: Fri, 14 Oct 2022 13:37:06 GMT
Subject: RFR: 8294426: Two fingers tap generates wrong mouse modifiers on
 M2 MacBooks
In-Reply-To: <kQHChV6_Pm4_p_TaCfxGedUqyIMkCTvRefJQnzZbmhw=.2b002e7d-6951-412d-a2a1-13a4ac65b080@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>
 <PUxdE8gZPsQbYpACOxu8liDdcUkkfSua9If_itYkrEQ=.06e28bb0-079c-47c8-8482-baf4d1909d2a@github.com>
 <kQHChV6_Pm4_p_TaCfxGedUqyIMkCTvRefJQnzZbmhw=.2b002e7d-6951-412d-a2a1-13a4ac65b080@github.com>
Message-ID: <m1AlkMq7y2BAT_3nvycAKqvJXJOtpIdnWsJn2WXhgyA=.12aee4d3-7855-45b4-8576-8a6a88316701@github.com>

On Mon, 3 Oct 2022 20:38:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> 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.
>
> OK .. well I've at least run all our automated tests and no regressions were found, so I'll approve this.

I've checked behavior of tap holding modifiers on M2 and here are which mouse events are received:
* _Ctrl + Two fingers tap_:
  * event: `java.awt.event.MouseEvent[MOUSE_PRESSED,(86,102),absolute(86,302),button=3,modifiers=?+?+Button3,extModifiers=?,clickCount=1] on MouseWindow$1[,0,136,200x200,layout=java.awt.FlowLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777225,maximumSize=,minimumSize=,preferredSize=]`
  * modifiers: 6 (`?+?+Button3`)
  * modifiersEx: 128 (`?`)
* _Option + Two fingers tap_:
  * event: `java.awt.event.MouseEvent[MOUSE_PRESSED,(63,135),absolute(63,335),button=3,modifiers=?+?+Button2+Button3,extModifiers=?,clickCount=1] on MouseWindow$1[,0,136,200x200,layout=java.awt.FlowLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777225,maximumSize=,minimumSize=,preferredSize=]`
  * modifiers: 12 (`?+?+Button2+Button3`)
  * modifiersEx: 512 (`?`)

Thus, as I assumed, modifiersEx don't contain `BUTTON3_DOWN_MASK`, so we shouldn't restrict the patch by the `jmodifiers == 0` condition.

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

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


From duke at openjdk.org  Fri Oct 14 14:17:10 2022
From: duke at openjdk.org (Nikita Provotorov)
Date: Fri, 14 Oct 2022 14:17:10 GMT
Subject: Integrated: 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: <_COdttLHrW8y8UlYuuZWPH9Q9B9Dqg-KFrDO8MjHvNY=.601ff954-46d8-4c60-9c19-a6a76ecb3e35@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.

This pull request has now been integrated.

Changeset: 2da079c6
Author:    Nikita Provotorov <nikita.provotorov at jetbrains.com>
Committer: Alexey Ushakov <avu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2da079c64e880835c9c0eb36f5e63a7752ebb328
Stats:     365 lines in 2 files changed: 365 ins; 0 del; 0 mod

8294426: Two fingers tap generates wrong mouse modifiers on M2 MacBooks

Reviewed-by: prr

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

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


From aivanov at openjdk.org  Fri Oct 14 19:51:00 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 14 Oct 2022 19:51:00 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v5]
In-Reply-To: <G-xU8XRZeIuOZ3G2IV1g8IYw4PAStyR9tU5xh8zIMDc=.06f7cd80-4bb4-44de-afdb-966796b16a2c@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <G-xU8XRZeIuOZ3G2IV1g8IYw4PAStyR9tU5xh8zIMDc=.06f7cd80-4bb4-44de-afdb-966796b16a2c@github.com>
Message-ID: <3KDSj8YueLVrsfWyzqcXef5_80bBcqvTkPRFVD8-nHg=.3a0ed8f5-5856-4e45-9fd0-8ba711e426fa@github.com>

On Fri, 14 Oct 2022 09:16:27 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.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc update

I was wrong, disallowing `Integer.MAX_VALUE` for `setSelectionInterval` is **not enough**. Moreover, if `Integer.MAX_VALUE` isn't accepted for `setSelectionInterval` and `removeIndexInterval`, it should be rejected in other places too. Otherwise, `selectionModel.isSelectedIndex(Integer.MAX_VALUE))` being valid looks inconsistent.

Even when the `gapLength` remains positive, the following loop could throw IOOBE because a negative index being accessed. The following code


        selectionModel.setSelectionInterval(Integer.MAX_VALUE - 2, Integer.MAX_VALUE - 1);
        selectionModel.removeIndexInterval(0, Integer.MAX_VALUE - 1);

throws

Exception in thread "main" java.lang.IndexOutOfBoundsException: bitIndex < 0: -2147483648
	at java.base/java.util.BitSet.get(BitSet.java:626)
	at java.desktop/javax.swing.DefaultListSelectionModel.removeIndexInterval(DefaultListSelectionModel.java:713)
	at SelectionModelTest.main(SelectionModelTest.java)

where line 713 https://github.com/openjdk/jdk/blob/ee43bd8db4c378c8cecdf5051cbaa6ac177d3592/src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java#L713

I suggested the code to fix that problem.

Then the infinite loop in `changeSelection` https://github.com/openjdk/jdk/blob/ee43bd8db4c378c8cecdf5051cbaa6ac177d3592/src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java#L432
for `MAX_VALUE` is resolved by reversing it:

-        for(int i = Math.min(setMin, clearMin); i <= Math.max(setMax, clearMax); i++) {
+        for(int i = Math.max(setMax, clearMax); i >= Math.min(setMin, clearMin); i--) {


The proposed changes will resolve the bug.

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 707:

> 705:         int rmMinIndex = Math.min(index0, index1);
> 706:         int rmMaxIndex = Math.max(index0, index1);
> 707:         int gapLength = (rmMaxIndex - rmMinIndex) + 1;

Suggestion:

        int gapLength = (rmMaxIndex - rmMinIndex) == Integer.MAX_VALUE
                        ? Integer.MAX_VALUE
                        : (rmMaxIndex - rmMinIndex) + 1;

This ensures `gapLength` remains positive. (The condition `(rmMaxIndex - rmMinIndex) == Integer.MAX_VALUE` is `true` if and only if `rmMinIndex == 0 && rmMaxIndex == Integer.MAX_VALUE`.)

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 714:

> 712:         for(int i = rmMinIndex; i <= maxIndex; i++) {
> 713:             setState(i, value.get(i + gapLength));
> 714:         }

The `for`-loop should look like this:

        for(int i = rmMinIndex; i >= 0 && i <= maxIndex; i++) {
            setState(i, (i <= Integer.MAX_VALUE - gapLength)
                        && (i + gapLength >= minIndex)
                        && value.get(i + gapLength));
        }

It breaks if `i` becomes negative. In the body, the first condition `(i <= Integer.MAX_VALUE - gapLength)` prevents accessing indexes greater than `Integer.MAX_VALUE`, the second condition `(i + gapLength >= minIndex)` is an optimisation, the values for indexes below `minIndex` are `false`, so the call to `value.get` is skipped. (The second condition is not required.)

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

Changes requested by aivanov (Reviewer).

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


From aivanov at openjdk.org  Fri Oct 14 20:08:56 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 14 Oct 2022 20:08:56 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v5]
In-Reply-To: <G-xU8XRZeIuOZ3G2IV1g8IYw4PAStyR9tU5xh8zIMDc=.06f7cd80-4bb4-44de-afdb-966796b16a2c@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <G-xU8XRZeIuOZ3G2IV1g8IYw4PAStyR9tU5xh8zIMDc=.06f7cd80-4bb4-44de-afdb-966796b16a2c@github.com>
Message-ID: <0spOcf_172kecR65BWKb11Orfp-jNcvutM5ZQ0O6oRA=.2e17fad3-22bc-4c84-9ac5-491fb5adeb5c@github.com>

On Fri, 14 Oct 2022 09:16:27 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.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc update

There exists at least one other problem because of integer overflow in `insertIndexInterval`.

This code

        selectionModel.setSelectionInterval(Integer.MAX_VALUE - 1, Integer.MAX_VALUE);
        selectionModel.insertIndexInterval(Integer.MAX_VALUE - 1, Integer.MAX_VALUE, true);

throws

Exception in thread "main" java.lang.IndexOutOfBoundsException: bitIndex < 0: -2
	at java.base/java.util.BitSet.get(BitSet.java:626)
	at java.desktop/javax.swing.DefaultListSelectionModel.set(DefaultListSelectionModel.java:311)
	at java.desktop/javax.swing.DefaultListSelectionModel.setState(DefaultListSelectionModel.java:629)
	at java.desktop/javax.swing.DefaultListSelectionModel.insertIndexInterval(DefaultListSelectionModel.java:657)
	at SelectionModelTest.main(SelectionModelTest.java)


Would you like to include it as part of this fix? Shall I submit a new bug for this?

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

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


From achung at openjdk.org  Fri Oct 14 20:42:57 2022
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 14 Oct 2022 20:42:57 GMT
Subject: RFR: 8294254: [macOS]
 javax/swing/plaf/aqua/CustomComboBoxFocusTest.java failure [v3]
In-Reply-To: <fICu-UYzbE8XTakT7lC1TERKhoqaeqtH4LQ_S8dUjD8=.58329a74-002c-475b-b658-1bba811d64ae@github.com>
References: <XmBIB7o0eNNj0Pq2udzXOSo0DtC0rO9s9bEqJSOJVx8=.64ffb7a6-0498-41b9-95ad-172b165826c3@github.com>
 <fICu-UYzbE8XTakT7lC1TERKhoqaeqtH4LQ_S8dUjD8=.58329a74-002c-475b-b658-1bba811d64ae@github.com>
Message-ID: <MbtJukJnWrGAaa0eQXY54M9rpf0WJVJNjh4m_8Hzelo=.8a0f5c32-916b-4613-a918-3625d2fde629@github.com>

On Tue, 11 Oct 2022 18:54:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The previous change to AquaComboBoxUI had 1 pixel of overlap between the text field and the combo button. This caused a few pixels to darken sometimes when an editable combobox is displayed. Since this test passes sometimes and fails some other times, it was not initially detected.
>> 
>> Since these few darkening pixels occur due to the change in AquaComboBoxUI, no reasonable change to the test could really be made, and the change would need to be to the class for the combobox. This fix was tested with a high count repeat and no failures occurred for various macOS systems.
>> 
>> Also removing the test from the problem list.
>
> Damon Nguyen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch '8294254/overlapFixEditableCombobox' of github.com:DamonGuy/jdk into 8294254/overlapFixEditableCombobox
>  - Set uiscale

Looks fine

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

Marked as reviewed by achung (Author).

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


From aturbanov at openjdk.org  Sat Oct 15 13:18:49 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 15 Oct 2022 13:18:49 GMT
Subject: RFR: 8282463: javax/sound/sampled/Clip/DataPusherThreadCheck.java
 fails
Message-ID: <myMXcksU12EK7xpYDTIW7PWDv2Gl1pftNHFeQzGrU8Q=.79d47610-3fb8-416a-961d-dc22f6c92480@github.com>

Test failed on Ubuntu, because both implementations of `MixerProvider` have no devices:
1. com.sun.media.sound.DirectAudioDeviceProvider#nGetNumDevices returns `0`
 ![DirectAudioDeviceProvider init](https://user-images.githubusercontent.com/741251/195988216-aa86da0f-739b-433f-87e2-86c2d6904a0d.png)
2. com.sun.media.sound.PortMixerProvider#nGetNumDevices returns `0`
 ![PortMixerProvider init](https://user-images.githubusercontent.com/741251/195988239-59678e0c-be7b-43ff-b02a-9abb2392e8f9.png)


It leads to `javax.sound.sampled.spi.MixerProvider#getMixerInfo` returns empty array.
![AudioSystem getMixedInfoList](https://user-images.githubusercontent.com/741251/195988266-1656e6d3-de4a-4e53-a613-415f60075726.png)

And DataPusher thread is not created, because of AudioSystem.isLineSupported returns false in the method `com.sun.media.sound.JavaSoundAudioClip#createSourceDataLine`.
I propose to perform the same check in test code and skip it.

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

Commit messages:
 - 8282463: javax/sound/sampled/Clip/DataPusherThreadCheck.java fails

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

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


From tnakamura at openjdk.org  Mon Oct 17 01:38:00 2022
From: tnakamura at openjdk.org (Toshio Nakamura)
Date: Mon, 17 Oct 2022 01:38:00 GMT
Subject: RFR: 8295248: JEditorPane HTML form with multi selection broke
 drawing after reseting [v2]
In-Reply-To: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
References: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
Message-ID: <UZyvKviWLdxsdAbfgaJkNRt860Jl0crItOzjouxn27M=.f8fc1388-9d3c-4f9d-a4d1-20eb846bfa4d@github.com>

> When JEditorPane shown HTML form with multi-selection, the reset operation broke its drawing.
> 
> There are two issues. The current method `OptionListModel.removeIndexInterval()` disabled selections, but it didn't fire the change. Then, no re-drawing. Another issue is the method works as remove and shift. Then, selection values were corrupted.
> I think the clear method `OptionListModel.clearSelection()` is suitable here.
> 
> Test: jdk_desktop on macOS (x64, Monterey), Linux (x64, RHEL8), and Windows (x64, 2012R2).
>       No regression found

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

  Update testcase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10685/files
  - new: https://git.openjdk.org/jdk/pull/10685/files/529bed84..e1ff53d2

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

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

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


From tnakamura at openjdk.org  Mon Oct 17 01:39:52 2022
From: tnakamura at openjdk.org (Toshio Nakamura)
Date: Mon, 17 Oct 2022 01:39:52 GMT
Subject: RFR: 8295248: JEditorPane HTML form with multi selection broke
 drawing after reseting
In-Reply-To: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
References: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
Message-ID: <U2cPnto2VCWtgqLZKlceIYadmcLsafPvYPbDTdzXUhY=.88371e2b-80d2-4f91-bf2e-0031d5adbe36@github.com>

On Thu, 13 Oct 2022 01:48:45 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> When JEditorPane shown HTML form with multi-selection, the reset operation broke its drawing.
> 
> There are two issues. The current method `OptionListModel.removeIndexInterval()` disabled selections, but it didn't fire the change. Then, no re-drawing. Another issue is the method works as remove and shift. Then, selection values were corrupted.
> I think the clear method `OptionListModel.clearSelection()` is suitable here.
> 
> Test: jdk_desktop on macOS (x64, Monterey), Linux (x64, RHEL8), and Windows (x64, 2012R2).
>       No regression found

Hi Patrick,

> Can you use stream instead of for loop ? 

Thank you for the comment.
Updated the testcase. I hope this meets your requirements. The remaining for-loop is for checking each position of multi selection. I think this case is better to use for-loop.

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

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


From psadhukhan at openjdk.org  Mon Oct 17 06:11:18 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 17 Oct 2022 06:11:18 GMT
Subject: RFR: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF. [v3]
In-Reply-To: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
Message-ID: <ggHccT9puFj6lP2GN7pxVOCLCKr07PCtrFaFLB1DSbc=.071ed779-ae46-4ab1-9f53-8e4dd2cb046a@github.com>

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

  Review comment fix. Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9937/files
  - new: https://git.openjdk.org/jdk/pull/9937/files/1dafa3d6..ee0fd693

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

  Stats: 130 lines in 2 files changed: 110 ins; 19 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9937.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9937/head:pull/9937

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


From psadhukhan at openjdk.org  Mon Oct 17 06:11:18 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 17 Oct 2022 06:11:18 GMT
Subject: RFR: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF. [v2]
In-Reply-To: <R0CffOuYu7VXSb_8Lg1dtlEl0IikS2WlEoobYgMa77Y=.2514785d-cf54-4471-b0cb-7de3c25b890e@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
 <-21DskiK73HbWK0fvkx1WKzGv9hDLuUM7vCMgMDDpG4=.c7df46c6-9f62-45ed-a8f2-d8f309924015@github.com>
 <R0CffOuYu7VXSb_8Lg1dtlEl0IikS2WlEoobYgMa77Y=.2514785d-cf54-4471-b0cb-7de3c25b890e@github.com>
Message-ID: <zyLpDFWzl_2Bka90odB458j45SeiBbbMnr2nm3jT_6M=.0992f9cb-eee7-451f-8a60-9c91ea136454@github.com>

On Wed, 28 Sep 2022 12:01:18 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> 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 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.

ok..removed..

> 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

ok..removed...

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

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


From psadhukhan at openjdk.org  Mon Oct 17 06:11:19 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 17 Oct 2022 06:11:19 GMT
Subject: RFR: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF. [v2]
In-Reply-To: <04eB0KFlqFESn9fsYVt7-ZjAenDHRP8ByXgC81Vb89c=.6db7eb87-f600-4c62-bd10-b51a65798edd@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
 <-21DskiK73HbWK0fvkx1WKzGv9hDLuUM7vCMgMDDpG4=.c7df46c6-9f62-45ed-a8f2-d8f309924015@github.com>
 <04eB0KFlqFESn9fsYVt7-ZjAenDHRP8ByXgC81Vb89c=.6db7eb87-f600-4c62-bd10-b51a65798edd@github.com>
Message-ID: <dDT67BLxCdOczxyFQ1CTAByFva8TlWtXW2lGwUljsM0=.9ac91ec8-55d2-4156-b0d7-f20c5984b77d@github.com>

On Tue, 27 Sep 2022 20:34:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> 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 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?

helper method added

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

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


From psadhukhan at openjdk.org  Mon Oct 17 06:13:35 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 17 Oct 2022 06:13:35 GMT
Subject: RFR: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF. [v4]
In-Reply-To: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
Message-ID: <5ZbLh_p6aVIRxk39BJS2fv7AQX_oSR5Dxdidq3uisT8=.b09e35e5-dc22-4d5d-bd9f-b873c91fbaf0@github.com>

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

  Test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9937/files
  - new: https://git.openjdk.org/jdk/pull/9937/files/ee0fd693..0e08608f

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

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

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


From dnguyen at openjdk.org  Mon Oct 17 17:44:22 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 17 Oct 2022 17:44:22 GMT
Subject: RFR: 8294254: [macOS]
 javax/swing/plaf/aqua/CustomComboBoxFocusTest.java failure [v2]
In-Reply-To: <q7xaRAzbHZoACkf-qHK3xTzl7jgBKKG0DH-A9RZCaJw=.121db029-fa8f-4ee7-a609-1a198b61fe93@github.com>
References: <XmBIB7o0eNNj0Pq2udzXOSo0DtC0rO9s9bEqJSOJVx8=.64ffb7a6-0498-41b9-95ad-172b165826c3@github.com>
 <AcQY1jED4CA6__TIdnit-sElejd1aDSIrOAG96_D8-E=.bfd71671-273b-4572-b405-0b898415a079@github.com>
 <q7xaRAzbHZoACkf-qHK3xTzl7jgBKKG0DH-A9RZCaJw=.121db029-fa8f-4ee7-a609-1a198b61fe93@github.com>
Message-ID: <M8DfCrYp36BwNSvc4DG3UFtaS8ybXI3exhjenGoNvI8=.72d5a00d-be96-48a5-8d3d-dbaea8aa60e5@github.com>

On Tue, 11 Oct 2022 06:30:52 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge branch 'master' into 8294254/overlapFixEditableCombobox
>>  - Merge branch 'openjdk:master' into 8294254/overlapFixEditableCombobox
>>  - Remove test from problem list
>>  - Adjust rect width to remove overlap
>
> Additionally if we want to make javax/swing/plaf/aqua/CustomComboBoxFocusTest.java run at some default uiScale that also should be fine.

@jayathirthrao Could you please sponsor this PR?

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

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


From serb at openjdk.org  Mon Oct 17 23:38:59 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 17 Oct 2022 23:38:59 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: <XFcWzIb-rshjZJkrJ5FICx_48HP9ntCuHAEuxF_GHCs=.7fcf2b4f-5ec1-47ce-87e4-52255961866d@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.

Can we report this behaviour change to Apple for investigation?

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

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


From dnguyen at openjdk.org  Tue Oct 18 00:50:50 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 18 Oct 2022 00:50:50 GMT
Subject: RFR: 8295429: Update harfbuzz md file
Message-ID: <zFYi5fbFVHXnXKAO4BA4I_sduJ7CxErKJVA8fIp8shA=.c1955ac5-c614-4f35-9e0a-14a5709a0e8d@github.com>

Update the harfbuzz md file with the newly generated md file. Matched format of previous license and organized copyright lines.

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

Commit messages:
 - Update md file

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

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


From dnguyen at openjdk.org  Tue Oct 18 03:59:37 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 18 Oct 2022 03:59:37 GMT
Subject: Integrated: 8294254: [macOS]
 javax/swing/plaf/aqua/CustomComboBoxFocusTest.java failure
In-Reply-To: <XmBIB7o0eNNj0Pq2udzXOSo0DtC0rO9s9bEqJSOJVx8=.64ffb7a6-0498-41b9-95ad-172b165826c3@github.com>
References: <XmBIB7o0eNNj0Pq2udzXOSo0DtC0rO9s9bEqJSOJVx8=.64ffb7a6-0498-41b9-95ad-172b165826c3@github.com>
Message-ID: <cGKWR5qIupqtel_T4UPZFG9Y-pxHAoMxHu2isccNAT4=.a923f263-7d38-4fc3-861b-b1b7a617caa5@github.com>

On Mon, 10 Oct 2022 05:26:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> The previous change to AquaComboBoxUI had 1 pixel of overlap between the text field and the combo button. This caused a few pixels to darken sometimes when an editable combobox is displayed. Since this test passes sometimes and fails some other times, it was not initially detected.
> 
> Since these few darkening pixels occur due to the change in AquaComboBoxUI, no reasonable change to the test could really be made, and the change would need to be to the class for the combobox. This fix was tested with a high count repeat and no failures occurred for various macOS systems.
> 
> Also removing the test from the problem list.

This pull request has now been integrated.

Changeset: 358ac072
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/358ac07255cc640cbcb9b0df5302d97891a34087
Stats:     8 lines in 3 files changed: 2 ins; 3 del; 3 mod

8294254: [macOS] javax/swing/plaf/aqua/CustomComboBoxFocusTest.java failure

Reviewed-by: jdv, achung

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

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


From psadhukhan at openjdk.org  Tue Oct 18 04:56:07 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 18 Oct 2022 04:56:07 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v6]
In-Reply-To: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
Message-ID: <ksfkgR3SplG4vRoZy2t_NLR4uM0zxFO40nYfM49g_bs=.73a98022-a9e7-4597-85a8-bde2d038d89f@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.

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

  insertIndexInterval fix. Add more subtests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10409/files
  - new: https://git.openjdk.org/jdk/pull/10409/files/ee43bd8d..0c4b2846

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

  Stats: 62 lines in 2 files changed: 31 ins; 24 del; 7 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 psadhukhan at openjdk.org  Tue Oct 18 05:01:06 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 18 Oct 2022 05:01:06 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v6]
In-Reply-To: <ksfkgR3SplG4vRoZy2t_NLR4uM0zxFO40nYfM49g_bs=.73a98022-a9e7-4597-85a8-bde2d038d89f@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <ksfkgR3SplG4vRoZy2t_NLR4uM0zxFO40nYfM49g_bs=.73a98022-a9e7-4597-85a8-bde2d038d89f@github.com>
Message-ID: <5p7951QsZ7zLKY-cFEyJiLKnmSD_-BNczpJAAT_RGX4=.f6c75351-4249-4b97-b94e-1be36d39a086@github.com>

On Tue, 18 Oct 2022 04:56:07 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.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   insertIndexInterval fix. Add more subtests

Thanks for your suggestive code..
I guess you are now ok with handling Integer.MAX_VALUE in the code rather than only in javadoc.

BTW, your code change resulted in JCK failure so I have used a mix of what I had in previous iterations and your code and this satisfied JCK as well as the unit tests.
Regarding `insertIndexInterval` I guess it's better to address in this PR as it has same issue in same file, so I have added a fix for it also in this PR.

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

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


From psadhukhan at openjdk.org  Tue Oct 18 05:16:04 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 18 Oct 2022 05:16:04 GMT
Subject: Integrated: 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: <WUCDJ6_He5GblfpYFeB7tfvRLBv5CZCruMDfVtORUQ0=.51eb61b5-9119-4389-818b-46305dcfbdf1@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.

This pull request has now been integrated.

Changeset: c33ca0c5
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c33ca0c5edd60454c58916cb588e5b2cfcc7b36a
Stats:     5 lines in 2 files changed: 0 ins; 1 del; 4 mod

6229853: BasicTextAreaUI:create incompletely documents the possible returned View types

Reviewed-by: aivanov, prr

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

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


From psadhukhan at openjdk.org  Tue Oct 18 06:44:16 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 18 Oct 2022 06:44:16 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors
Message-ID: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>

The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec.

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

Commit messages:
 - 6201035: Undefined behavior of MatteBorder Ctors

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

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


From jdv at openjdk.org  Tue Oct 18 08:59:18 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 18 Oct 2022 08:59:18 GMT
Subject: RFR: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF. [v4]
In-Reply-To: <5ZbLh_p6aVIRxk39BJS2fv7AQX_oSR5Dxdidq3uisT8=.b09e35e5-dc22-4d5d-bd9f-b873c91fbaf0@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
 <5ZbLh_p6aVIRxk39BJS2fv7AQX_oSR5Dxdidq3uisT8=.b09e35e5-dc22-4d5d-bd9f-b873c91fbaf0@github.com>
Message-ID: <t5P7bceeyf3cOEEv5k-20j9h3Pa1D4tVREk_5cWTwRA=.e7e42eed-f3fd-4721-8365-5b76da63b59c@github.com>

On Mon, 17 Oct 2022 06:13:35 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:
> 
>   Test fix

Marked as reviewed by jdv (Reviewer).

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

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


From psadhukhan at openjdk.org  Tue Oct 18 14:09:12 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 18 Oct 2022 14:09:12 GMT
Subject: Integrated: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF.
In-Reply-To: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
Message-ID: <25h-js3Sp2utYC4ZVhFPJ2TfWqiz22sSxJIMrpKDZPU=.a42d84b9-abc2-4935-8427-da7fd6dcde00@github.com>

On Fri, 19 Aug 2022 07:40:13 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.

This pull request has now been integrated.

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

7175397: The divider color is not changed to green when dragging for Nimbus LaF.

Reviewed-by: jdv

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

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


From ihse at openjdk.org  Tue Oct 18 15:45:01 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Oct 2022 15:45:01 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test code
Message-ID: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>

This is a continuation of the effort to update all our URLs to the new top-level domain.

This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.

I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

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

Commit messages:
 - 8295470: Update openjdk.java.net => openjdk.org URLs in test code

Changes: https://git.openjdk.org/jdk/pull/10744/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10744&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295470
  Stats: 138 lines in 45 files changed: 46 ins; 0 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/10744.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10744/head:pull/10744

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


From ihse at openjdk.org  Tue Oct 18 15:45:02 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Oct 2022 15:45:02 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test
 code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <v3W5NeJ07ZOb3Q9438eICJZDJYgnGRzSmOSQ_YixhIM=.61781355-3c3b-4a8c-b18f-a64d71771dee@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

I noticed that a couple of files where missing copyright headers, when I tried to update those. I did some code archaeology and found out which year they were created, and added a copyright header.

Just to be reasonably sure that I did not affect any tests, I have let this go through the GHA and our internal CI testing tier1-3. The failed GHA test is `SuperWaitTest`, which I did not modify.

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

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


From michaelm at openjdk.org  Tue Oct 18 16:03:57 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 18 Oct 2022 16:03:57 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test
 code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <CfPkyYI0R_caEpiCxoTNMXatXKfS_8jk6xM0IzrMlFc=.881f4da4-2de8-4044-a51f-dfdd87ed360f@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

net changes look fine

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

Marked as reviewed by michaelm (Reviewer).

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


From prr at openjdk.org  Tue Oct 18 16:49:10 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 18 Oct 2022 16:49:10 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v11]
In-Reply-To: <qBSXGkjfwNWatB2ur-Lr_FcPctqCFo0XlyjJfcM6hfo=.df53e761-0ba4-47f7-917e-61ec70ffc721@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <qBSXGkjfwNWatB2ur-Lr_FcPctqCFo0XlyjJfcM6hfo=.df53e761-0ba4-47f7-917e-61ec70ffc721@github.com>
Message-ID: <u69_ioy7ox5H4LiEfST4n9sW-U3f62MIenuQMj2A2mg=.06751863-a9ac-466b-aa78-58bb47390cac@github.com>

On Wed, 12 Oct 2022 11:24:17 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 50 commits:
> 
>  - Merge branch 'master' into typos-in-java.desktop
>  - 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>
>  - ... and 40 more: https://git.openjdk.org/jdk/compare/bdb4ed0f...e2d0979f

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Tue Oct 18 16:51:10 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 18 Oct 2022 16:51:10 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test
 code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <m0t2ZmdJ-yCzmpDu8zgql3thiOR8ea2bRlp9F1X6_ZM=.b720bff5-afdd-41e1-984a-be2b0bf95067@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

Marked as reviewed by prr (Reviewer).

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

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


From ihse at openjdk.org  Tue Oct 18 17:13:15 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Oct 2022 17:13:15 GMT
Subject: Integrated: 8285306: Fix typos in java.desktop
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <DH7sHDlZa7CvNfM33RvFIvJdLvgSJKDFkELt7eygEJw=.e0b40813-e25a-4ff1-8e53-156258d97aa5@github.com>

On Thu, 21 Apr 2022 08:35:36 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.

This pull request has now been integrated.

Changeset: 2a799e5c
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a799e5c82395919b807561da4a062e0fe6da31d
Stats:     1017 lines in 483 files changed: 0 ins; 0 del; 1017 mod

8285306: Fix typos in java.desktop

Co-authored-by: Andrey Turbanov <aturbanov at openjdk.org>
Reviewed-by: aturbanov, prr

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

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


From darcy at openjdk.org  Tue Oct 18 17:24:02 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Oct 2022 17:24:02 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test
 code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <h2_NlmWAUfCsO8WRXBZKPYWb4jBgLGigcLgk15s97S4=.a0d0812b-0952-4bb0-828c-508a4304f048@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

Marked as reviewed by darcy (Reviewer).

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

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


From aivanov at openjdk.org  Tue Oct 18 20:27:18 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 18 Oct 2022 20:27:18 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v6]
In-Reply-To: <ksfkgR3SplG4vRoZy2t_NLR4uM0zxFO40nYfM49g_bs=.73a98022-a9e7-4597-85a8-bde2d038d89f@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <ksfkgR3SplG4vRoZy2t_NLR4uM0zxFO40nYfM49g_bs=.73a98022-a9e7-4597-85a8-bde2d038d89f@github.com>
Message-ID: <z-BiQU5cPkkx2nBXeIKNh-0lUpBFH98Rs0LNE4cSMlg=.8bcbe572-37c7-48c6-b24b-bf7d333cbfaa@github.com>

On Tue, 18 Oct 2022 04:56:07 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.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   insertIndexInterval fix. Add more subtests

This is tough. The number of test cases has grown to 25. There are many failures.

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 455:

> 453:             if (i + 1 < i) {
> 454:                 break;
> 455:             }

I would rather add `i >= 0` to the loop condition. Yet I can't see why the reversed loop doesn't work.

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

> 658:          * insMinIndex).
> 659:          */
> 660:         for(int i = maxIndex; i >= insMinIndex; i--) {

`insertIndexInterval` doesn't verify its parameters: negative `index`, negative `length` should be rejected right away.

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 661:

> 659:          */
> 660:         for(int i = maxIndex; i >= insMinIndex; i--) {
> 661:             if ((i + length) >= length) {

I suggest using `i <= Integer.MAX_VALUE - length`. Yet I'm still unsure it's enough and *correct*.

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 664:

> 662:                 setState(i + length, value.get(i));
> 663:             } else {
> 664:                 setState(i, value.get(i));

This operation in the `else` block doesn't make sense, you can just skip it.

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 721:

> 719:                 setState(i, value.get(gapLength));
> 720:                 break;
> 721:             }

This does not work. It must not break. With this code, 5 of my tests fail.

For example,


        selectionModel.setSelectionInterval(0, Integer.MAX_VALUE);
        selectionModel.removeIndexInterval(0, Integer.MAX_VALUE);

must result in empty selection. All the possible indexes were selected, you removed all the possible indexes (so that ?the list? contains no elements at all). This test case fails either way, unfortunately: `selectionModel.isSelectedIndex(0)` still returns `true`.

This edge case where `rmMinIndex = 0` and `rmMaxIndex = Integer.MAX_VALUE` should probably be short-circuited: `setState(i, false)` for all the elements. Other values are handled correctly by my suggested code, as far as I can see.

This test case:

        selectionModel.setSelectionInterval(0, Integer.MAX_VALUE);
        selectionModel.removeIndexInterval(1, Integer.MAX_VALUE);

passed before and now it fails again. Here, `selectionModel.isSelectedIndex(0)` must be `true`.

test/jdk/javax/swing/TestDefListModelException.java line 62:

> 60:         DefaultListSelectionModel selectionModel = new DefaultListSelectionModel();
> 61:         selectionModel.setSelectionInterval(Integer.MAX_VALUE - 1, Integer.MAX_VALUE);
> 62:         selectionModel.insertIndexInterval(Integer.MAX_VALUE - 1, Integer.MAX_VALUE, true);

I think testing that it does not throw an exception is not enough. You should verify that the data selection model holds is correct.

According to the spec, the interval from `Integer.MAX_VALUE - 1` to `Integer.MAX_VALUE` should remain selected.

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

Changes requested by aivanov (Reviewer).

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


From dnguyen at openjdk.org  Tue Oct 18 21:55:20 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 18 Oct 2022 21:55:20 GMT
Subject: RFR: 8295429: Update harfbuzz md file [v2]
In-Reply-To: <zFYi5fbFVHXnXKAO4BA4I_sduJ7CxErKJVA8fIp8shA=.c1955ac5-c614-4f35-9e0a-14a5709a0e8d@github.com>
References: <zFYi5fbFVHXnXKAO4BA4I_sduJ7CxErKJVA8fIp8shA=.c1955ac5-c614-4f35-9e0a-14a5709a0e8d@github.com>
Message-ID: <tnS3TnF0MOp0lLWOXck9Qt_h-uoiN_Sn6CJ3A4Vyzvs=.7a482d75-a357-444d-83f5-2b7891dbda7c@github.com>

> Update the harfbuzz md file with the newly generated md file. Matched format of previous license and organized copyright lines.

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

  Add copyrights. Add license path.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10735/files
  - new: https://git.openjdk.org/jdk/pull/10735/files/884b9ade..5361656d

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

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

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


From ihse at openjdk.org  Tue Oct 18 22:24:39 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Oct 2022 22:24:39 GMT
Subject: RFR: 8294466: Minimize disabled warnings in java.desktop
Message-ID: <P3ypBcY4pLz6ruMi5FIS6dZDO959LJ7nvW0BePnzyqQ=.958cf136-95bc-4715-8b6e-e9c110761539@github.com>

After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.

Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

Some warnings didn't trigger in any file anymore, and could just be removed.

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

Commit messages:
 - Merge branch 'master' into java.desktop-warnings-per-file
 - Fix java.desktop-static-libs
 - 8295419: JFR: Change name of jdk.JitRestart
 - 8295517: Fix stutter typo in JDK-8294539
 - 8295029: runtime/cds/appcds/LotsOfClasses.java fail with jfx
 - 8284614: on macOS "spindump" should be run from failure_handler as root
 - 8285306: Fix typos in java.desktop
 - 6924219: (fc spec) FileChannel.write(ByteBuffer, position) behavior when file opened for append not specified
 - 8295457: Make the signatures of write barrier methods consistent
 - 8295469: S390X: Optimized builds are broken
 - ... and 286 more: https://git.openjdk.org/jdk/compare/ecfb6bce...1c855e42

Changes: https://git.openjdk.org/jdk/pull/10453/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10453&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294466
  Stats: 100 lines in 2 files changed: 43 ins; 18 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/10453.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10453/head:pull/10453

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


From azvegint at openjdk.org  Tue Oct 18 22:41:55 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 18 Oct 2022 22:41:55 GMT
Subject: RFR: 8295429: Update harfbuzz md file [v2]
In-Reply-To: <tnS3TnF0MOp0lLWOXck9Qt_h-uoiN_Sn6CJ3A4Vyzvs=.7a482d75-a357-444d-83f5-2b7891dbda7c@github.com>
References: <zFYi5fbFVHXnXKAO4BA4I_sduJ7CxErKJVA8fIp8shA=.c1955ac5-c614-4f35-9e0a-14a5709a0e8d@github.com>
 <tnS3TnF0MOp0lLWOXck9Qt_h-uoiN_Sn6CJ3A4Vyzvs=.7a482d75-a357-444d-83f5-2b7891dbda7c@github.com>
Message-ID: <lUV9dMEh_QPQOtYswT8gvOXcrucJoaj9obEaGm9nHHs=.5efedf1d-b61c-4127-b03e-3ffb5fe47e4d@github.com>

On Tue, 18 Oct 2022 21:55:20 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Update the harfbuzz md file with the newly generated md file. Matched format of previous license and organized copyright lines.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add copyrights. Add license path.

Marked as reviewed by azvegint (Reviewer).

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

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


From duke at openjdk.org  Wed Oct 19 04:49:28 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 19 Oct 2022 04:49:28 GMT
Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and
 radiobutton with GTK LAF for bug4314194
Message-ID: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>

Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF.

The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. 

Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS.

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

Commit messages:
 - 8295006 entry removed from problem lists
 - Fix for disabled checkbox and radiobutton colored text

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

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


From duke at openjdk.org  Wed Oct 19 07:13:44 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 19 Oct 2022 07:13:44 GMT
Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and
 radiobutton with GTK LAF for bug4314194 [v2]
In-Reply-To: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>
References: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>
Message-ID: <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>

> Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF.
> 
> The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. 
> 
> Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS.

Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - ProblemList.txt file merge resolved
 - 8295006 entry removed from problem lists
 - Fix for disabled checkbox and radiobutton colored text

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

Changes: https://git.openjdk.org/jdk/pull/10755/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10755&range=01
  Stats: 13 lines in 2 files changed: 12 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10755.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10755/head:pull/10755

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


From duke at openjdk.org  Wed Oct 19 07:13:45 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 19 Oct 2022 07:13:45 GMT
Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and
 radiobutton with GTK LAF for bug4314194
In-Reply-To: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>
References: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>
Message-ID: <BSlaPcuAZThNH2dXVmJxenExIfZbn_Qi4IOHUPO_uUU=.b02f6de8-e0b2-42cc-9f18-0c6d38a5a3e6@github.com>

On Wed, 19 Oct 2022 04:25:42 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF.
> 
> The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. 
> 
> Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS.

@TejeshR13 @prsadhuk Please review the PR.

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

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


From serb at openjdk.org  Wed Oct 19 08:25:11 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 19 Oct 2022 08:25:11 GMT
Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and
 radiobutton with GTK LAF for bug4314194 [v2]
In-Reply-To: <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
References: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>
 <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
Message-ID: <pkMB2MBI-CQvt2w5npoRc21zw_kj_OZZ8gsnQ_bz7nI=.c0a3e531-ed55-41ee-b397-c3e0418fac13@github.com>

On Wed, 19 Oct 2022 07:13:44 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF.
>> 
>> The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. 
>> 
>> Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - ProblemList.txt file merge resolved
>  - 8295006 entry removed from problem lists
>  - Fix for disabled checkbox and radiobutton colored text

Why we did not get this colors from the native system? I also suggest to check an initial [fix](https://github.com/openjdk/jdk/pull/10177#issuecomment-1276765550). looks like it contradicts the specification.

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

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


From duke at openjdk.org  Wed Oct 19 08:47:59 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 19 Oct 2022 08:47:59 GMT
Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and
 radiobutton with GTK LAF for bug4314194 [v2]
In-Reply-To: <pkMB2MBI-CQvt2w5npoRc21zw_kj_OZZ8gsnQ_bz7nI=.c0a3e531-ed55-41ee-b397-c3e0418fac13@github.com>
References: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>
 <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
 <pkMB2MBI-CQvt2w5npoRc21zw_kj_OZZ8gsnQ_bz7nI=.c0a3e531-ed55-41ee-b397-c3e0418fac13@github.com>
Message-ID: <F1YK550CQbSWsPUfmZVU_P5ZFUPPnCA_P6E-wXb02Co=.fa7b71fe-1313-428b-b4c7-2389605e3931@github.com>

On Wed, 19 Oct 2022 08:21:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Why we did not get this colors from the native system? I also suggest to check an initial [fix](https://github.com/openjdk/jdk/pull/10177#issuecomment-1276765550). looks like it contradicts the specification.

The color returned from the native system is `grey` even though the user has explicitly set it to be some other color in GTK LAF. So, `UIManager.getColor` is used to retrieve the color for disabled checkbox and radiobutton if property is set by user else `getColorForState` will return the appropriate color.

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

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


From serb at openjdk.org  Wed Oct 19 08:59:12 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 19 Oct 2022 08:59:12 GMT
Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and
 radiobutton with GTK LAF for bug4314194 [v2]
In-Reply-To: <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
References: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>
 <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
Message-ID: <Erw1sNWqPXNdMhU2MDMkuMoeZ-3RrZOkLD1zfZ0pTxE=.077696a7-aec3-4141-b65d-a1fe1b0cb713@github.com>

On Wed, 19 Oct 2022 07:13:44 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF.
>> 
>> The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. 
>> 
>> Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - ProblemList.txt file merge resolved
>  - 8295006 entry removed from problem lists
>  - Fix for disabled checkbox and radiobutton colored text

I wonder do the GTK/Nimbus L&F actually use that UIDefault properties or they all based on SynthContext/SynthStyle? I see that all usages of UIManager.getColor() is added there by @prsadhuk, any reason why it was not used before?

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

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


From serb at openjdk.org  Wed Oct 19 09:06:04 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 19 Oct 2022 09:06:04 GMT
Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and
 radiobutton with GTK LAF for bug4314194 [v2]
In-Reply-To: <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
References: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>
 <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
Message-ID: <lM3zXXB-AmBrnu6W5UzVwMlw0iFQ2bbhNd_tYRXpVoI=.dacb217f-1e0a-40c2-86ab-c2758d323a5b@github.com>

On Wed, 19 Oct 2022 07:13:44 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF.
>> 
>> The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. 
>> 
>> Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - ProblemList.txt file merge resolved
>  - 8295006 entry removed from problem lists
>  - Fix for disabled checkbox and radiobutton colored text

For example maybe the test should uses the properties [supported](https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/_nimbusDefaults.html) by the L&F? what happen if the test sets `RadioButton[Disabled].textForeground` to some value?

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

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


From serb at openjdk.org  Wed Oct 19 09:26:57 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 19 Oct 2022 09:26:57 GMT
Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and
 radiobutton with GTK LAF for bug4314194 [v2]
In-Reply-To: <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
References: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>
 <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
Message-ID: <3r8XE6-mudzNEVz5lTdsWspILAZehoLhn5WbHV6_lLQ=.d6001a79-8b52-4461-b6bc-9ce59c1d018a@github.com>

On Wed, 19 Oct 2022 07:13:44 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF.
>> 
>> The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. 
>> 
>> Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - ProblemList.txt file merge resolved
>  - 8295006 entry removed from problem lists
>  - Fix for disabled checkbox and radiobutton colored text

Something like this should work I think:

        checkBox = new JCheckBox("\u2588".repeat(5));
        UIDefaults checkBoxDefaults = new UIDefaults();
        checkBoxDefaults.put("CheckBox.textForeground", checkboxColor);
        checkBox.putClientProperty("Nimbus.Overrides",checkBoxDefaults);

        radioButton = new JRadioButton("\u2588".repeat(5));
        UIDefaults radioDefaults = new UIDefaults();
        radioDefaults.put("RadioButton.textForeground", radioButtonColor);
        radioButton.putClientProperty("Nimbus.Overrides",radioDefaults);

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

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


From duke at openjdk.org  Wed Oct 19 10:34:57 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 19 Oct 2022 10:34:57 GMT
Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and
 radiobutton with GTK LAF for bug4314194 [v2]
In-Reply-To: <Erw1sNWqPXNdMhU2MDMkuMoeZ-3RrZOkLD1zfZ0pTxE=.077696a7-aec3-4141-b65d-a1fe1b0cb713@github.com>
References: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>
 <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
 <Erw1sNWqPXNdMhU2MDMkuMoeZ-3RrZOkLD1zfZ0pTxE=.077696a7-aec3-4141-b65d-a1fe1b0cb713@github.com>
Message-ID: <O83zeadeca4YObitYGBn37CpGX4--ybpLL09gtlQA3U=.0d45bee5-19ce-44bd-98bd-a6054b13fd65@github.com>

On Wed, 19 Oct 2022 08:56:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I wonder do the GTK/Nimbus L&F actually use that UIDefault properties or they all based on SynthContext/SynthStyle? I see that all usages of UIManager.getColor() is added there by @prsadhuk, any reason why it was not used before?

I am not sure about it, maybe @prsadhuk can add his opinion.

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

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


From psadhukhan at openjdk.org  Wed Oct 19 11:11:00 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Oct 2022 11:11:00 GMT
Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and
 radiobutton with GTK LAF for bug4314194 [v2]
In-Reply-To: <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
References: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>
 <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
Message-ID: <RYMTw2lDQ3HNcUFbpw_Z24g3QYFpQB-rKo8Iyt8xJ5c=.d061ca60-5823-4fcf-9433-5c0b74c00abd@github.com>

On Wed, 19 Oct 2022 07:13:44 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF.
>> 
>> The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. 
>> 
>> Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - ProblemList.txt file merge resolved
>  - 8295006 entry removed from problem lists
>  - Fix for disabled checkbox and radiobutton colored text

As per https://docs.oracle.com/en/java/javase/19/docs/api/java.desktop/javax/swing/plaf/nimbus/package-summary.html
it seems UIDefaults (ie UIManager.getDefaults) should be honoured first which can be overridden by altering the table via UIManager.put. There's also client property named "Nimbus.Overrides" which override the UIManager settings, so as I interpret it the UIManager.getDefaults() should be honoured unless it is overridden by Nimbus.Overrides which was not the case in my fix.

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

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


From aivanov at openjdk.org  Wed Oct 19 13:22:01 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 19 Oct 2022 13:22:01 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v6]
In-Reply-To: <z-BiQU5cPkkx2nBXeIKNh-0lUpBFH98Rs0LNE4cSMlg=.8bcbe572-37c7-48c6-b24b-bf7d333cbfaa@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <ksfkgR3SplG4vRoZy2t_NLR4uM0zxFO40nYfM49g_bs=.73a98022-a9e7-4597-85a8-bde2d038d89f@github.com>
 <z-BiQU5cPkkx2nBXeIKNh-0lUpBFH98Rs0LNE4cSMlg=.8bcbe572-37c7-48c6-b24b-bf7d333cbfaa@github.com>
Message-ID: <KEhf6SPDcZT2OjhacP8xHOqyGD2dPi7taKSxPYcM4ag=.3b5b18ec-a4c5-49a1-baab-be5236aab81d@github.com>

On Tue, 18 Oct 2022 20:01:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   insertIndexInterval fix. Add more subtests
>
> src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 721:
> 
>> 719:                 setState(i, value.get(gapLength));
>> 720:                 break;
>> 721:             }
> 
> This does not work. It must not break. With this code, 5 of my tests fail.
> 
> For example,
> 
> 
>         selectionModel.setSelectionInterval(0, Integer.MAX_VALUE);
>         selectionModel.removeIndexInterval(0, Integer.MAX_VALUE);
> 
> must result in empty selection. All the possible indexes were selected, you removed all the possible indexes (so that ?the list? contains no elements at all). This test case fails either way, unfortunately: `selectionModel.isSelectedIndex(0)` still returns `true`.
> 
> This edge case where `rmMinIndex = 0` and `rmMaxIndex = Integer.MAX_VALUE` should probably be short-circuited: `setState(i, false)` for all the elements. Other values are handled correctly by my suggested code, as far as I can see.
> 
> This test case:
> 
>         selectionModel.setSelectionInterval(0, Integer.MAX_VALUE);
>         selectionModel.removeIndexInterval(1, Integer.MAX_VALUE);
> 
> passed before and now it fails again. Here, `selectionModel.isSelectedIndex(0)` must be `true`.

If we handle the edge case separately, it looks better and the first test case as well as other tests for `remove` pass successfully:


    public void removeIndexInterval(int index0, int index1)
    {
        if (index0 < 0 || index1 < 0) {
            throw new IndexOutOfBoundsException("index is negative");
        }

        int rmMinIndex = Math.min(index0, index1);
        int rmMaxIndex = Math.max(index0, index1);

        if (rmMinIndex == 0 && rmMaxIndex == Integer.MAX_VALUE) {
            for (int i = Integer.MAX_VALUE; i >= 0; i--) {
                setState(i, false);
            }
            // min and max are updated automatically by the for-loop

            // TODO Update anchor and lead
            return;
        }

        int gapLength = (rmMaxIndex - rmMinIndex) + 1;

        /* Shift the entire bitset to the left to close the index0, index1
         * gap.
         */
        for(int i = rmMinIndex; i >= 0 && i <= maxIndex; i++) {
            setState(i, (i <= Integer.MAX_VALUE - gapLength)
                        && (i + gapLength >= minIndex)
                        && value.get(i + gapLength));
        }

        // The rest of the method
    }

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

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


From alanb at openjdk.org  Wed Oct 19 13:41:46 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Oct 2022 13:41:46 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test
 code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <oEDAuhIBqZqqS3y_9Q7BuQkndrxJSU-ozVrKMhAUr3g=.875d970e-8dc9-4240-97bb-19623b89a247@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

This updates several tests that are also in Doug Lea's CVS for j.u.concurrent. That should be okay, just need to get them in sync at some point.

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

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


From dnguyen at openjdk.org  Wed Oct 19 14:22:05 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 19 Oct 2022 14:22:05 GMT
Subject: Integrated: 8295429: Update harfbuzz md file
In-Reply-To: <zFYi5fbFVHXnXKAO4BA4I_sduJ7CxErKJVA8fIp8shA=.c1955ac5-c614-4f35-9e0a-14a5709a0e8d@github.com>
References: <zFYi5fbFVHXnXKAO4BA4I_sduJ7CxErKJVA8fIp8shA=.c1955ac5-c614-4f35-9e0a-14a5709a0e8d@github.com>
Message-ID: <kuXUQUM7YuMs4G5ku7NG_HV6ozs7nLRN4FQLol5hOxs=.ef721df1-bb14-4b7a-b91c-92feefebebb4@github.com>

On Tue, 18 Oct 2022 00:43:02 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Update the harfbuzz md file with the newly generated md file. Matched format of previous license and organized copyright lines.

This pull request has now been integrated.

Changeset: 21aeb9e7
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21aeb9e7946fc7450ee48939944a69c8aa04bcce
Stats:     16 lines in 1 file changed: 8 ins; 0 del; 8 mod

8295429: Update harfbuzz md file

Reviewed-by: azvegint

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

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


From aivanov at openjdk.org  Wed Oct 19 20:54:21 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 19 Oct 2022 20:54:21 GMT
Subject: RFR: 5080391: ArrayIndexOutOfBounds during "undo" of Right-to-Left
 text insert [v3]
In-Reply-To: <NzW4BLiZO7Tj3dSKcVfO4nBwOCWXbkSgvn0NygJ-UkE=.1844a43a-6701-453f-bba4-e7a8ca125626@github.com>
References: <6RcEPyVsdn3GAryyi2QYk3OGfPDUGxFD-W0c_2s8iH4=.b10fa89b-07b7-4e8b-858f-1311d0ffeaae@github.com>
 <NzW4BLiZO7Tj3dSKcVfO4nBwOCWXbkSgvn0NygJ-UkE=.1844a43a-6701-453f-bba4-e7a8ca125626@github.com>
Message-ID: <GIfpNvXVzQV7FotN4bOE7Fg3z3degIMI5f92bpdpOEU=.34493fd2-c6d4-4d4a-ae70-902e4e8bcdca@github.com>

On Tue, 11 Oct 2022 05:40:40 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.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

This does **corrupt the document structure**.

The negative indexes are the sign that the undoable edit contradicts to the current document structure and cannot be applied therefore. Ignoring that is a call for trouble in another place.

What happens in the provided test case?

The document before the Arabic character is inserted:

--- empty ---
<paragraph>
  <content>
    [0,1][
]
<bidi root>
  <bidi level
    bidiLevel=0
  >
    [0,1][
]


This is the document dump obtained via [`AbstractDocument.dump`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/text/AbstractDocument.html#dump(java.io.PrintStream)).

After the Arabic character is inserted:

--- one char ---
<paragraph>
  <content>
    [0,2][?
]
<bidi root>
  <bidi level
    bidiLevel=1
  >
    [0,1][?]
  <bidi level
    bidiLevel=0
  >
    [1,2][
]


Now the text component orientation is changed to RTL:


--- orientation changed ---
<paragraph>
  <content>
    [0,2][?
]
<bidi root>
  <bidi level
    bidiLevel=1
  >
    [0,2][?
]


The most important change is that bidi-root now contains only one element with level 1 which contains the entire document content whereas before the orientation was changed it had contained two elements with level 1 and 0.

The undoable edit stores the data to restore the bidi-root from two leaf elements to one leaf. Yet now the bidi-root has only one leaf element. That's why the indexes in `replace` are negative: the undoable edit cannot be applied correctly.

Let's continue, as the indexes are positive now and the undo can be performed.

--- undone ---
<paragraph>
  <content>
    [0,1][
]
<bidi root>

This results in bidi-root which has no elements. This is _**not** a valid document_ any more. I [mentioned above](https://github.com/openjdk/jdk/pull/10446#discussion_r985670722) that `bidiElem` in `isLeftToRight` must never be `null`. It *is* `null` because converting negative indexes to positive in `replace` breaks the structure.

The proposed fix must not be integrated.

Is there a solution? I'm afraid there's none.

The best approach would be to invalidate all the undo information in the `UndoManager`. *Nothing can be undone* after the orientation of a text component is changed. This is true even if the edit doesn't throw an exception.

For example, if the document contains the following text: "start &lt;Arabic-char&gt; end". The insertion of an Arabic character is the last operation, it will be undone when `undo` is called. The component orientation was changed to RTL after inserting that Arabic character, which changes the levels in bidi-root from 0-1-0 to 2-1-2. Calling `undo` undoes the changes and restores the levels which had been before the orientation was changed, that is to 0 instead of the expected 2. This results in wrong rendering of bidirectional text.

I came up with a test case which throws `ArrayIndexOutOfBounds` before the fix is applied. With the fix applied, it throws an exception on EDT:

Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: offsetLimit must be after current position
	at java.desktop/java.awt.font.LineBreakMeasurer.nextOffset(LineBreakMeasurer.java:356)
	at java.desktop/javax.swing.text.TextLayoutStrategy.getLimitingOffset(TextLayoutStrategy.java:286)
	at java.desktop/javax.swing.text.TextLayoutStrategy.createView(TextLayoutStrategy.java:194)
	at ...


What can we recommend? Set the component orientation *before* editing text and capturing undoable edits.

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

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


From serb at openjdk.org  Wed Oct 19 22:16:57 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 19 Oct 2022 22:16:57 GMT
Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and
 radiobutton with GTK LAF for bug4314194 [v2]
In-Reply-To: <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
References: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>
 <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
Message-ID: <BNxzSUxHqwWQuKtiIrNI0Ph5Ykemz2nWz9rIk8eqjGA=.716a9c10-129f-4900-9427-49420b8d224d@github.com>

On Wed, 19 Oct 2022 07:13:44 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF.
>> 
>> The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. 
>> 
>> Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - ProblemList.txt file merge resolved
>  - 8295006 entry removed from problem lists
>  - Fix for disabled checkbox and radiobutton colored text

That text mention the Nimbus properties, which are different from the properties used in the test.
The next line should change the color globally:
UIManager.getDefaults().put("CheckBox[Enabled].textForeground", Color.RED);
But it is unclear why the next does not work
UIManager.getDefaults().put("CheckBox[Disabled].textForeground", Color.GREEN);

It is interesting that the next line works fine in 11 and 19, but does not work in 20.
UIManager.getDefaults().put("CheckBox.textForeground", Color.RED);
I think that previouse fixes should be updated.

The next line is also does not work in 20
UIManager.getDefaults().put("CheckBox[Enabled].textForeground", Color.GREEN);

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

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


From serb at openjdk.org  Thu Oct 20 04:53:48 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 20 Oct 2022 04:53:48 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
Message-ID: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>

The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into JDK-8295554
 - 8295554: Move the "sizecalc.h" to the correct location

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

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


From serb at openjdk.org  Thu Oct 20 04:53:49 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 20 Oct 2022 04:53:49 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <kM7au4SfOdQxSS_s4CvCLxx0U4rqwpbuLPu0-vqunJg=.6e411ab7-bbdc-4d3c-9611-14fb11fd2aaa@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

make/common/modules/LauncherCommon.gmk line 48:

> 46: LAUNCHER_SRC := $(TOPDIR)/src/java.base/share/native/launcher
> 47: LAUNCHER_CFLAGS += -I$(TOPDIR)/src/java.base/share/native/launcher \
> 48:     -I$(TOPDIR)/src/java.desktop/share/native/include \

This line was added recently, not sure why.

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

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


From duke at openjdk.org  Thu Oct 20 06:31:06 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 20 Oct 2022 06:31:06 GMT
Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and
 radiobutton with GTK LAF for bug4314194 [v2]
In-Reply-To: <BNxzSUxHqwWQuKtiIrNI0Ph5Ykemz2nWz9rIk8eqjGA=.716a9c10-129f-4900-9427-49420b8d224d@github.com>
References: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>
 <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
 <BNxzSUxHqwWQuKtiIrNI0Ph5Ykemz2nWz9rIk8eqjGA=.716a9c10-129f-4900-9427-49420b8d224d@github.com>
Message-ID: <RZD18dmtmmdgLWfKhE2lamktkIZrXL6vApGJFI-Qt5E=.53202958-78c0-4e6d-9f22-5876693d3b9e@github.com>

On Wed, 19 Oct 2022 22:13:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - ProblemList.txt file merge resolved
>>  - 8295006 entry removed from problem lists
>>  - Fix for disabled checkbox and radiobutton colored text
>
> The next line is also does not work in 20
> UIManager.getDefaults().put("CheckBox[Enabled].textForeground", Color.GREEN);

@mrserb I think what you are suggesting is for Nimbus LAF. In case of GTK LAF, as I mentioned earlier that native system returned gray color for disabled checkbox and radio button.

As per my understanding I think user defined color should have precedence over native system color.
What should I do?

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

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


From serb at openjdk.org  Thu Oct 20 08:54:54 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 20 Oct 2022 08:54:54 GMT
Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and
 radio button with GTK LAF for bug4314194. [v2]
In-Reply-To: <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
References: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>
 <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
Message-ID: <0mHZC93-XJf0OQdkSyvpYjMwaC4zXI_UALAxiS6C8yg=.d8e63f02-22b9-4018-b8af-9a40c2092da5@github.com>

On Wed, 19 Oct 2022 07:13:44 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF.
>> 
>> The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. 
>> 
>> Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - ProblemList.txt file merge resolved
>  - 8295006 entry removed from problem lists
>  - Fix for disabled checkbox and radiobutton colored text

The current change mostly replicates the previous fix in Nimbus L&F. Since that fix is questionable we should rethink it first. The open questions are:
 - Why did the Nimbus properties above stop working in 20
 - Why the "[Disabled]" does not work as expected
 - Why Nimbus should honor "CheckBox.disabledText" property and not [these](https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/_nimbusDefaults.html) properties
 
After that we can answer the next question: "what property GTK L&F should honor". The GTK implementation is based on SynthContext/SynthStyle so I assume it should use the same props as Nimbus, and provide a way to override it by the user when needed(same as Nimbus).

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

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


From ihse at openjdk.org  Thu Oct 20 10:33:10 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 10:33:10 GMT
Subject: RFR: 8295717: Minimize disabled warnings in accessibility native code
Message-ID: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>

After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the accessibility native code.

Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

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

Commit messages:
 - 8295717: Minimize disabled warnings in accessibility native code

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

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


From ihse at openjdk.org  Thu Oct 20 10:36:03 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 10:36:03 GMT
Subject: Integrated: 8295470: Update openjdk.java.net => openjdk.org URLs in
 test code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <ikUR8BWcMaOfzg0XpZjCi7OeWhugVYhHsAcXp2KZV1k=.0baf7f30-4033-44f8-b6ea-19442a984b97@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

This pull request has now been integrated.

Changeset: d5a1521f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5a1521fde3f6ff7e810e8257a4722a09c9ef60b
Stats:     138 lines in 45 files changed: 46 ins; 0 del; 92 mod

8295470: Update openjdk.java.net => openjdk.org URLs in test code

Reviewed-by: michaelm, prr, darcy

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

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


From ihse at openjdk.org  Thu Oct 20 10:37:59 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 10:37:59 GMT
Subject: RFR: 8294466: Minimize disabled warnings in java.desktop
In-Reply-To: <P3ypBcY4pLz6ruMi5FIS6dZDO959LJ7nvW0BePnzyqQ=.958cf136-95bc-4715-8b6e-e9c110761539@github.com>
References: <P3ypBcY4pLz6ruMi5FIS6dZDO959LJ7nvW0BePnzyqQ=.958cf136-95bc-4715-8b6e-e9c110761539@github.com>
Message-ID: <YIYFXrFE7-xAxs_u4TnojiRhmUFlmLPbhK5goo9_jqc=.35dda2fa-8a85-4330-8ecb-a01abf898bf9@github.com>

On Tue, 27 Sep 2022 16:14:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

I fouled up with the merge, and this PR got just messy. I'll close this and open a new.

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

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


From ihse at openjdk.org  Thu Oct 20 10:38:00 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 10:38:00 GMT
Subject: Withdrawn: 8294466: Minimize disabled warnings in java.desktop
In-Reply-To: <P3ypBcY4pLz6ruMi5FIS6dZDO959LJ7nvW0BePnzyqQ=.958cf136-95bc-4715-8b6e-e9c110761539@github.com>
References: <P3ypBcY4pLz6ruMi5FIS6dZDO959LJ7nvW0BePnzyqQ=.958cf136-95bc-4715-8b6e-e9c110761539@github.com>
Message-ID: <Z8pTvM7B4Pc4GVK2Sy_Jx_KjuVe4BJIqZkxMBRpcIt0=.f459f4b7-9b6a-4ccb-ad77-750f9d6b0593@github.com>

On Tue, 27 Sep 2022 16:14:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

This pull request has been closed without being integrated.

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

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


From ihse at openjdk.org  Thu Oct 20 10:43:19 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 10:43:19 GMT
Subject: RFR: 8294466: Minimize disabled warnings in java.desktop
Message-ID: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>

After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.

Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

Some warnings didn't trigger in any file anymore, and could just be removed.

(This is a reboot of https://github.com/openjdk/jdk/pull/10453)

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

Commit messages:
 - 8294466: Minimize disabled warnings in java.desktop

Changes: https://git.openjdk.org/jdk/pull/10790/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10790&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294466
  Stats: 100 lines in 2 files changed: 43 ins; 18 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/10790.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10790/head:pull/10790

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


From ihse at openjdk.org  Thu Oct 20 12:06:27 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 12:06:27 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
Message-ID: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>

Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).

The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

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

Commit messages:
 - 8295729: Add jcheck whitespace checking for properties files

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

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


From erikj at openjdk.org  Thu Oct 20 18:03:48 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:03:48 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <cxLfmrrBUYs-PYK-SznAJbeViJPKV89s3mw2wsQ646E=.8bd5438a-3dd5-4404-9840-ad493da21fa5@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Thu Oct 20 18:09:16 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:09:16 GMT
Subject: RFR: 8295717: Minimize disabled warnings in accessibility native
 code
In-Reply-To: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
References: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
Message-ID: <ce7zx48PfM_s8PbgHd7AEdYQ3O4mhBcovYe37HMGMkI=.24f69caf-f657-4740-84be-3ebde04cf487@github.com>

On Thu, 20 Oct 2022 10:24:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the accessibility native code.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

make/modules/jdk.accessibility/Launcher.gmk line 46:

> 44:           -analyze- -Od -Gd -D_WINDOWS \
> 45:           -D_UNICODE -DUNICODE -RTC1 -EHsc, \
> 46:       DISABLED_WARNINGS_microsoft_jabswitch.cpp := 4267 4996, \

This lib only has one cpp file, so this change doesn't seem that useful.

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

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


From erikj at openjdk.org  Thu Oct 20 18:16:52 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:16:52 GMT
Subject: RFR: 8294466: Minimize disabled warnings in java.desktop
In-Reply-To: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
References: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
Message-ID: <somtlyJyxdK432gQ2H51CalLnjdhjN1LFerqxdKx4ys=.fd12fb37-dc0e-469f-ad7f-cc2e4689dd3c@github.com>

On Thu, 20 Oct 2022 10:36:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.
> 
> (This is a reboot of https://github.com/openjdk/jdk/pull/10453)

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 222:

> 220:     endif
> 221: 
> 222:     ifeq ($(TOOLCHAIN_TYPE), gcc)

How did you solve this?

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

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


From erikj at openjdk.org  Thu Oct 20 18:26:46 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:26:46 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <NObZDn88VUQ8fHaLhcrqe0wkth0EfVAwjWA7K4eAY2k=.0c70399e-f307-4ca4-a637-e2f1ebedf960@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Nice job!

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

Marked as reviewed by erikj (Reviewer).

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


From naoto at openjdk.org  Thu Oct 20 18:33:47 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 18:33:47 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <0VhVC2dpGOdpE3OL1278r0iCVXO1Jd_83Q4kszfikjY=.fecfe4ed-9a48-4fe4-827a-7ab1bc2defa2@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

LGTM. Haven't looked at all the l10n files.

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

Marked as reviewed by naoto (Reviewer).

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


From angorya at openjdk.org  Thu Oct 20 18:40:47 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Oct 2022 18:40:47 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

I would vote against this change.  Per java properties spec
https://github.com/openjdk/jdk/pull/10792


White space following the property value is not ignored, and is treated as part of the property value.


This change might break localization or messages where trailing whitespace is important (example: "Label: ")

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

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


From ihse at openjdk.org  Thu Oct 20 18:48:17 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 18:48:17 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
Message-ID: <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>

On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> I would vote against this change.  Per java properties spec
> https://github.com/openjdk/jdk/pull/10792
> 
> 
> White space following the property value is not ignored, and is treated as part of the property value.
> 
> 
> This change might break localization or messages where trailing whitespace is important (example: "Label: ")
> 
> edit: sorry, the link above is not a spec.  looking at the Properties.load(Reader) javadoc:
> https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader)
> 
> 
> Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string;

@andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored.

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

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


From erikj at openjdk.org  Thu Oct 20 18:53:49 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:53:49 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <qf8daMUSgSlaXN3bROLfbFbpzrDJh5wSJdnTYQdol64=.df762075-9646-4aab-ab95-ead96e45936a@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Given that trailing whitespace may be part of a property value, then I take back my review.

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

Changes requested by erikj (Reviewer).

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


From cjplummer at openjdk.org  Thu Oct 20 18:53:50 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Oct 2022 18:53:50 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
Message-ID: <uNs096Y7_C0U9CTifzO1PL71uAgKv0RwAxTfOuL5LGw=.e8e725f6-3fac-4b54-b406-111628923ae8@github.com>

On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> `White space following the property value is not ignored, and is treated as part of the property value.`

Although I didn't know this was in the spec, I suspected it might be the case. When looking at the jdk.management.agent changes, it looked like the extra space was actually a typo and was copied into all the localized versions (and not actually localized for unicode locales). In this case removing the white space is the right thing to do. It is in fact fixing an actual bug.

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

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


From angorya at openjdk.org  Thu Oct 20 18:53:51 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Oct 2022 18:53:51 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
 <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>
Message-ID: <HJm4YG5tr3dJ4SeXPS58BEpkBqzUEk7QwX6Cmf5x8JA=.7076b0a9-6fe2-4e0a-99f9-d3ca8a828a5a@github.com>

On Thu, 20 Oct 2022 18:46:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I would vote against this change.  Per java properties spec
>> https://github.com/openjdk/jdk/pull/10792
>> 
>> 
>> White space following the property value is not ignored, and is treated as part of the property value.
>> 
>> 
>> This change might break localization or messages where trailing whitespace is important (example: "Label: ")
>> 
>> edit: sorry, the link above is not a spec.  looking at the Properties.load(Reader) javadoc:
>> https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader)
>> 
>> 
>> Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string;
>
> @andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored.

@magicus  : 
no, this is how Properties were working from day one.


package goryachev.research;

import java.io.IOException;
import java.io.StringReader;
import java.util.Properties;

public class TestProperties {
    public static void main(String[] args) throws IOException {
        String text = "key= value ";
        Properties p = new Properties();
        p.load(new StringReader(text));
        System.out.println("value=["  +p.getProperty("key") + "]");
    }
}


outputs:

value=[value ]

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

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


From ihse at openjdk.org  Thu Oct 20 18:55:55 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 18:55:55 GMT
Subject: RFR: 8294466: Minimize disabled warnings in java.desktop
In-Reply-To: <somtlyJyxdK432gQ2H51CalLnjdhjN1LFerqxdKx4ys=.fd12fb37-dc0e-469f-ad7f-cc2e4689dd3c@github.com>
References: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
 <somtlyJyxdK432gQ2H51CalLnjdhjN1LFerqxdKx4ys=.fd12fb37-dc0e-469f-ad7f-cc2e4689dd3c@github.com>
Message-ID: <mNm0cbDTRz4IRpaejMIOGqXzcnLbXvzzE7N2c5WZvw8=.b039cb42-0741-4a04-a72a-d09045bba75d@github.com>

On Thu, 20 Oct 2022 18:14:45 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.
>> 
>> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
>> 
>> Some warnings didn't trigger in any file anymore, and could just be removed.
>> 
>> (This is a reboot of https://github.com/openjdk/jdk/pull/10453)
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 222:
> 
>> 220:     endif
>> 221: 
>> 222:     ifeq ($(TOOLCHAIN_TYPE), gcc)
> 
> How did you solve this?

I did not solve anything. Apparently the code has changed so the warnings is no longer triggered. Or that's at least what I assume, just as for other warnings that were no longer needed.

It might be that it also triggered only for older versions of gcc. I've tested with a couple of different versions, but I have not done an extensive test of all possible gcc version. The worst thing that can happen is that some specific, old version of gcc will still trigger these (or any other removed) warning(s). If that happens, the speedy workaround is to run with `--disable-warnings-as-error`, and then I'll restore the warning, possibly with a version check.

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

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


From ihse at openjdk.org  Thu Oct 20 19:01:02 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 19:01:02 GMT
Subject: RFR: 8295717: Minimize disabled warnings in accessibility native
 code
In-Reply-To: <ce7zx48PfM_s8PbgHd7AEdYQ3O4mhBcovYe37HMGMkI=.24f69caf-f657-4740-84be-3ebde04cf487@github.com>
References: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
 <ce7zx48PfM_s8PbgHd7AEdYQ3O4mhBcovYe37HMGMkI=.24f69caf-f657-4740-84be-3ebde04cf487@github.com>
Message-ID: <c9QBA0xrPmEhinXsbjBFoys3OA3xzsXHXjRm345RObM=.a1a76b72-1c48-4826-9a78-f42d2cc1b133@github.com>

On Thu, 20 Oct 2022 18:06:09 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the accessibility native code.
>> 
>> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
>
> make/modules/jdk.accessibility/Launcher.gmk line 46:
> 
>> 44:           -analyze- -Od -Gd -D_WINDOWS \
>> 45:           -D_UNICODE -DUNICODE -RTC1 -EHsc, \
>> 46:       DISABLED_WARNINGS_microsoft_jabswitch.cpp := 4267 4996, \
> 
> This lib only has one cpp file, so this change doesn't seem that useful.

Heh, I did not notice that.

I'd still argue that this is a useful change. If some other file were ever to be added, it will not be covered by the blanked disabled warnings, and -- perhaps more important -- it is clear that these warnings can be addressed just by looking at a single file. This information has drastically increased the likelihood that a developer picks up the issue and actually resolves the warnings, as we have seen in other areas where I've done this "warnings-per-file" transition.

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

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


From ihse at openjdk.org  Thu Oct 20 19:07:52 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 19:07:52 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <vN85_fh3ocln38nEOKYh1GBwW5xzb3nIo_jYOQYqiLY=.6e65e099-3d3c-40fe-8cfa-1acf25fdd0a7@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Okay. That definitely rules out adding .properties to the whitespace jcheck verification.

However, I think that instead opens up a ton of more individual problems, since I think most (if perhaps not all) of these trailing whitespaces are incidental, and thus might be bugs. Perhaps no-one really noticed a double whitespace where it were not supposed to be, etc, especially not if it was just for a translated language.

I'm thinking I should redirect this PR to skip the jcheck requirement, and revert all changes to property values, but keep the part of the patch that removes trailing spaces in `#` comment lines. That seems to account for a majority of the changes.

For the remaining properties files with trailing spaces in the actual values, I'll make a sanity check if it seems correct or not, and if it looks fishy, I'll open bugs on the respective component teams to verify that their property values are indeed correct.

Does that sound reasonable?

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

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


From naoto at openjdk.org  Thu Oct 20 19:29:51 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 19:29:51 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <iu-qPLbaWYYTSq2jVgsGXDGt8Weqq2RVuoaHyuI0YRg=.f4131b5a-9685-4246-bbac-85b776fee6e3@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Retracting my approval too. Thanks for the catch, Andy!
That sounds reasonable > Magnus

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

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


From aivanov at openjdk.org  Thu Oct 20 19:39:27 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 20 Oct 2022 19:39:27 GMT
Subject: RFR: 8295298: Automate javax/swing/JFileChooser/FileViewNPETest.java
Message-ID: <QllenU8UW_STmxGG98HBbySNFuLEJFSHAn2SbHsnza8=.09c8619b-49da-4fd5-be6d-f24801313caf@github.com>

The automated test follows the instructions of the manual test that was added in #10485.

Instead of selecting the parent folder from the **Look in** combo box, it calls `setCurrentDirectory` directly with the parent of the path which is not traversable. Thus, the current directory of the file chooser is set to `null`.

As the second step, the test finds the combo box and re-selects the currently selected element. Without the fix for [JDK-6616245](https://bugs.openjdk.org/browse/JDK-6616245), `NullPointerException` is thrown and the test fails; with the fix applied, the original folder is selected and the test passes.

@mrserb and @TejeshR13, please, take a look.

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

Commit messages:
 - 8295298: Automate javax/swing/JFileChooser/FileViewNPETest.java

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

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


From naoto at openjdk.org  Thu Oct 20 19:40:55 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 19:40:55 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <eJ0YaIIkCYOV7stEG2AEVx05evyYix9H9Zp2eAlJsjA=.2e14e322-75f6-4651-bb96-c24cf2f10391@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

(retracting approval)

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

Changes requested by naoto (Reviewer).

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


From erikj at openjdk.org  Thu Oct 20 19:53:47 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 19:53:47 GMT
Subject: RFR: 8294466: Minimize disabled warnings in java.desktop
In-Reply-To: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
References: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
Message-ID: <J-a_PiAp2DQh_Z_43k8vqsZheKUnYv25354mVDz5Q54=.72fb1eae-de69-430f-afe9-2889d761499e@github.com>

On Thu, 20 Oct 2022 10:36:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.
> 
> (This is a reboot of https://github.com/openjdk/jdk/pull/10453)

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10790


From erikj at openjdk.org  Thu Oct 20 19:54:47 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 19:54:47 GMT
Subject: RFR: 8295717: Minimize disabled warnings in accessibility native
 code
In-Reply-To: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
References: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
Message-ID: <E-uDnAHrmrIXe7qWW-bQPKoLv1n0v4dSz1ArwFj50vo=.fd857699-3cbb-47f5-beec-d6d92bf7e6f2@github.com>

On Thu, 20 Oct 2022 10:24:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the accessibility native code.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10788


From aivanov at openjdk.org  Thu Oct 20 19:57:42 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 20 Oct 2022 19:57:42 GMT
Subject: RFR: 8295738: Automate javax/swing/JFileChooser/FileSizeCheck.java
Message-ID: <VIkeTYidMTjdV9cwai4WC0KLRXsUNHZEP43kXsC21pI=.b78cd68a-d4d3-4ea4-b7e2-16c98d63de30@github.com>

This automates the test added in #9327.

The test has a set of objects which store the size of the file and the expected displayed size, the file name is generated automatically. The pattern for the file names ensures the files are displayed in the expected order up to and including gigabytes, 10 digits. I added more test cases that the original test had to verify the displayed size is rounded up, an automatic test can easily verify more rows than a human can.

The finds the **Details** button in the file chooser and clicks it, then it finds the table, finds the row where the first file is displayed. The test compares the size displayed in the table to the expected one. If it doesn't match, an error is printed to `stderr`. All the file sizes are verified. The first error message, if any, is thrown to fail the test.

The test passes with the fix for [JDK-8288882](https://bugs.openjdk.org/browse/JDK-8288882) and fails without it.

-------------

Commit messages:
 - Make the test headful
 - 8295738: Automate javax/swing/JFileChooser/FileSizeCheck.java

Changes: https://git.openjdk.org/jdk/pull/10802/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10802&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295738
  Stats: 230 lines in 1 file changed: 170 ins; 33 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/10802.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10802/head:pull/10802

PR: https://git.openjdk.org/jdk/pull/10802


From honkar at openjdk.org  Thu Oct 20 22:56:04 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 20 Oct 2022 22:56:04 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v10]
In-Reply-To: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
Message-ID: <W4Fhep6bfK5JKYI9BTA7LQMlQpXMtf148CAXBOdzky8=.207b0b0c-b4fa-438f-8f0f-4e925320feeb@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:

  highlight and shadow line positioning changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10274/files
  - new: https://git.openjdk.org/jdk/pull/10274/files/da54767f..99664b3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10274&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10274&range=08-09

  Stats: 62 lines in 2 files changed: 24 ins; 13 del; 25 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 serb at openjdk.org  Thu Oct 20 23:29:46 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 20 Oct 2022 23:29:46 GMT
Subject: RFR: 8295298: Automate
 javax/swing/JFileChooser/FileViewNPETest.java
In-Reply-To: <QllenU8UW_STmxGG98HBbySNFuLEJFSHAn2SbHsnza8=.09c8619b-49da-4fd5-be6d-f24801313caf@github.com>
References: <QllenU8UW_STmxGG98HBbySNFuLEJFSHAn2SbHsnza8=.09c8619b-49da-4fd5-be6d-f24801313caf@github.com>
Message-ID: <Z8Gk5Qss_ESxuoodl53uFtGuVsu5TVKMB-n9aC4ymYY=.974e39dc-2498-4c17-8eb3-e7f197bc786c@github.com>

On Thu, 20 Oct 2022 19:31:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The automated test follows the instructions of the manual test that was added in #10485.
> 
> Instead of selecting the parent folder from the **Look in** combo box, it calls `setCurrentDirectory` directly with the parent of the path which is not traversable. Thus, the current directory of the file chooser is set to `null`.
> 
> As the second step, the test finds the combo box and re-selects the currently selected element. Without the fix for [JDK-6616245](https://bugs.openjdk.org/browse/JDK-6616245), `NullPointerException` is thrown and the test fails; with the fix applied, the original folder is selected and the test passes.
> 
> @mrserb and @TejeshR13, please, take a look.

test/jdk/javax/swing/JFileChooser/FileViewNPETest.java line 62:

> 60:             SwingUtilities.invokeAndWait(() -> {
> 61:                 jfc.setCurrentDirectory(path.getParentFile());
> 62:                 assert jfc.getCurrentDirectory() == null

This assertion could be skipped if the test executed standalone or via directly by the jtreg w/o makefiles.

-------------

PR: https://git.openjdk.org/jdk/pull/10801


From serb at openjdk.org  Thu Oct 20 23:42:49 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 20 Oct 2022 23:42:49 GMT
Subject: RFR: 8295738: Automate javax/swing/JFileChooser/FileSizeCheck.java
In-Reply-To: <VIkeTYidMTjdV9cwai4WC0KLRXsUNHZEP43kXsC21pI=.b78cd68a-d4d3-4ea4-b7e2-16c98d63de30@github.com>
References: <VIkeTYidMTjdV9cwai4WC0KLRXsUNHZEP43kXsC21pI=.b78cd68a-d4d3-4ea4-b7e2-16c98d63de30@github.com>
Message-ID: <1WzutCZrI9dygTmpu0Dkail5ffmTinDherQ62qaCJbk=.fdb75b73-8cea-4bef-8395-55480da80391@github.com>

On Thu, 20 Oct 2022 19:50:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This automates the test added in #9327.
> 
> The test has a set of objects which store the size of the file and the expected displayed size, the file name is generated automatically. The pattern for the file names ensures the files are displayed in the expected order up to and including gigabytes, 10 digits. I added more test cases that the original test had to verify the displayed size is rounded up, an automatic test can easily verify more rows than a human can.
> 
> The finds the **Details** button in the file chooser and clicks it, then it finds the table, finds the row where the first file is displayed. The test compares the size displayed in the table to the expected one. If it doesn't match, an error is printed to `stderr`. All the file sizes are verified. The first error message, if any, is thrown to fail the test.
> 
> The test passes with the fix for [JDK-8288882](https://bugs.openjdk.org/browse/JDK-8288882) and fails without it.

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 51:

> 49:  * @bug 8288882
> 50:  * @key headful
> 51:  * @requires (os.family == "linux")

Why the linux platform only? I think it should be able to work on all platform if Metal is used?

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 58:

> 56: public class FileSizeCheck {
> 57:     private enum FileSize {
> 58:         F0(    0, "0.0 KB"),

The text probably depends from the Locale? Do we need to set it explicitly?

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 128:

> 126:     private static void createUI() {
> 127:         // Create temp files
> 128:         Path dir = Paths.get(".");

It is better to create a testFolder, and then open the chooser in it, otherwise other files in the current folder may break it(if the test executed standalone)

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 158:

> 156:             robot.waitForIdle();
> 157:             robot.delay(500);
> 158:             SwingUtilities.invokeAndWait(FileSizeCheck::clickDetails);

Can we click that button programmatically w/o robot? That will make the test a little bit more stable.

-------------

PR: https://git.openjdk.org/jdk/pull/10802


From serb at openjdk.org  Thu Oct 20 23:49:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 20 Oct 2022 23:49:51 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors
In-Reply-To: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
Message-ID: <xJRbKyTl3LEZwOja3hVl8_efF6-LPpfRrLR6YLK9qlU=.025791ed-212b-4e72-949c-48d98b853022@github.com>

On Tue, 18 Oct 2022 06:36:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec.

It seems the same issue exists in other methods, like getBorderInsets?

-------------

PR: https://git.openjdk.org/jdk/pull/10740


From psadhukhan at openjdk.org  Fri Oct 21 03:37:16 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 21 Oct 2022 03:37:16 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v7]
In-Reply-To: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
Message-ID: <pRK-MA1QAQMcJCVvzgcccVJDJ98muUKGjczZ7CODAko=.e72f79ce-7a5e-49aa-a111-d8fbc9add718@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.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  removeIndexInterval, insertIndexInterval fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10409/files
  - new: https://git.openjdk.org/jdk/pull/10409/files/0c4b2846..ee02dc45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10409&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10409&range=05-06

  Stats: 38 lines in 1 file changed: 21 ins; 5 del; 12 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 tr at openjdk.org  Fri Oct 21 06:41:53 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 21 Oct 2022 06:41:53 GMT
Subject: RFR: 8295298: Automate
 javax/swing/JFileChooser/FileViewNPETest.java
In-Reply-To: <QllenU8UW_STmxGG98HBbySNFuLEJFSHAn2SbHsnza8=.09c8619b-49da-4fd5-be6d-f24801313caf@github.com>
References: <QllenU8UW_STmxGG98HBbySNFuLEJFSHAn2SbHsnza8=.09c8619b-49da-4fd5-be6d-f24801313caf@github.com>
Message-ID: <Z4cKVDDDqGzwgTp1qIaCOFsKeGjVMc5L_49bUI7fWqg=.c6ff7f4f-d671-4385-9740-cc61e890fd34@github.com>

On Thu, 20 Oct 2022 19:31:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The automated test follows the instructions of the manual test that was added in #10485.
> 
> Instead of selecting the parent folder from the **Look in** combo box, it calls `setCurrentDirectory` directly with the parent of the path which is not traversable. Thus, the current directory of the file chooser is set to `null`.
> 
> As the second step, the test finds the combo box and re-selects the currently selected element. Without the fix for [JDK-6616245](https://bugs.openjdk.org/browse/JDK-6616245), `NullPointerException` is thrown and the test fails; with the fix applied, the original folder is selected and the test passes.
> 
> @mrserb and @TejeshR13, please, take a look.

It looks good to me and have tested. It works fine.

-------------

PR: https://git.openjdk.org/jdk/pull/10801


From aturbanov at openjdk.org  Fri Oct 21 07:00:58 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 21 Oct 2022 07:00:58 GMT
Subject: RFR: 8295767: Remove unused fields in sun.awt.geom.Edge
Message-ID: <Hf8VzgFNka7JbpjDTh4_eDbKPqmSwp3f7zM8ximg-0E=.771f0e85-5add-4f65-b5bc-90c62b423b5f@github.com>

Remove couple of unused `static` fields in `sun.awt.geom.Edge` class.

-------------

Commit messages:
 - [PATCH] Remove unused fields in sun.awt.geom.Edge

Changes: https://git.openjdk.org/jdk/pull/10720/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10720&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295767
  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10720.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10720/head:pull/10720

PR: https://git.openjdk.org/jdk/pull/10720


From duke at openjdk.org  Fri Oct 21 07:00:58 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 21 Oct 2022 07:00:58 GMT
Subject: RFR: 8295767: Remove unused fields in sun.awt.geom.Edge
In-Reply-To: <Hf8VzgFNka7JbpjDTh4_eDbKPqmSwp3f7zM8ximg-0E=.771f0e85-5add-4f65-b5bc-90c62b423b5f@github.com>
References: <Hf8VzgFNka7JbpjDTh4_eDbKPqmSwp3f7zM8ximg-0E=.771f0e85-5add-4f65-b5bc-90c62b423b5f@github.com>
Message-ID: <wTfxXM26mWl8Biz8ZDZLMkOyZ-1O9rY2vSfqRQDiFUM=.f17ef1e8-80bc-4b9a-afc9-1d9364678113@github.com>

On Sun, 16 Oct 2022 21:30:47 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Remove couple of unused `static` fields in `sun.awt.geom.Edge` class.

I wonder what they were originally meant for. Some sort of growable list?

-------------

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

PR: https://git.openjdk.org/jdk/pull/10720


From serb at openjdk.org  Fri Oct 21 07:00:58 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Oct 2022 07:00:58 GMT
Subject: RFR: 8295767: Remove unused fields in sun.awt.geom.Edge
In-Reply-To: <Hf8VzgFNka7JbpjDTh4_eDbKPqmSwp3f7zM8ximg-0E=.771f0e85-5add-4f65-b5bc-90c62b423b5f@github.com>
References: <Hf8VzgFNka7JbpjDTh4_eDbKPqmSwp3f7zM8ximg-0E=.771f0e85-5add-4f65-b5bc-90c62b423b5f@github.com>
Message-ID: <DvIU3sXsk4JqQ2VfR07vKHWjbIK4IaBN2S6DiZxhWLY=.a623f73a-2d30-44fd-8272-ab9280dacc0b@github.com>

On Sun, 16 Oct 2022 21:30:47 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Remove couple of unused `static` fields in `sun.awt.geom.Edge` class.

Looks fine.

-------------

PR: https://git.openjdk.org/jdk/pull/10720


From ihse at openjdk.org  Fri Oct 21 08:17:46 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:17:46 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v2]
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Remove check for .properties from jcheck
 - Restore trailing whitespace for property values

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10792/files
  - new: https://git.openjdk.org/jdk/pull/10792/files/e33c0765..c91fdaa1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=00-01

  Stats: 412 lines in 131 files changed: 0 ins; 0 del; 412 mod
  Patch: https://git.openjdk.org/jdk/pull/10792.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792

PR: https://git.openjdk.org/jdk/pull/10792


From ihse at openjdk.org  Fri Oct 21 08:31:59 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:31:59 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <1mu65mMxl2Nf-mwa4iZczOBqJbPdutKpL6dE_3vMWcg=.c03430ed-70df-40fa-994e-700080b7b8fa@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Ok, I repurposed this PR to deal only with trailing space on non-value lines (comments and empty lines). This should be trivial, and will reduce the trailing spaces to only the value lines.

I believe most, but perhaps not all, trailing spaces in the value lines are actually bugs, but that will need further scrutiny by the owners of the properties files. Expect follow up bugs on this.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From alexsch at openjdk.org  Fri Oct 21 08:49:11 2022
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Fri, 21 Oct 2022 08:49:11 GMT
Subject: RFR: 8295737: macOS: Print content cut off when width > height with
 portrait orientation
Message-ID: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>

A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation.

To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS.

Four rectangles are printed:
1. size 300x100, portrait orientation
2. size 300x100, landscape orientation
3. size 100x300, portrait orientation
4. size 100x300, landscape orientation

The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf)

The reason is that NSPrintInfo class does not allow to set paper size and orientation independently.
Setting paper size width large than height changes NSPrintInfo orientation to landscape.
Setting paper size width less than height changes NSPrintInfo orientation to portrait.
Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height.

The Cocoa code that shows NSPrintInfo behavior:

#import <Cocoa/Cocoa.h>

int main()
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    NSApp = [NSApplication sharedApplication];

    #ifdef __MAC_10_9 // code for SDK 10.9 or newer
    #define NS_PORTRAIT NSPaperOrientationPortrait
    #define NS_LANDSCAPE NSPaperOrientationLandscape
    #else // code for SDK 10.8 or older
    #define NS_PORTRAIT NSPortraitOrientation
    #define NS_LANDSCAPE NSLandscapeOrientation
    #endif

    printf("NS_PORTRAIT: %d\n", NS_PORTRAIT);
    printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE);

    printf("create default print info\n");
    NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy];
    NSSize size = [defaultPrintInfo paperSize];
    printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);

    printf("call setUpPrintOperationDefaultValues\n");
    [defaultPrintInfo setUpPrintOperationDefaultValues];
    size = [defaultPrintInfo paperSize];
    printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);

    double w = 300.0;
    double h = 100.0;
    printf("set size: [%f, %f]\n", w, h);
    [defaultPrintInfo setPaperSize:NSMakeSize(w, h)];
    size = [defaultPrintInfo paperSize];
    printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);

    printf("Set NS_PORTRAIT orientation\n");
    [defaultPrintInfo setOrientation: NS_PORTRAIT];
    size = [defaultPrintInfo paperSize];
    printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);

    [NSApp run];

    [NSApp release];
    [pool release];
    return(EXIT_SUCCESS);
} 


On macOS Mojave 10.14.5 it prints:


NS_PORTRAIT: 0
NS_LANDSCAPE: 1
create default print info
orientation: 0, paper size: [612.000000, 792.000000]
call setUpPrintOperationDefaultValues
orientation: 0, paper size: [612.000000, 792.000000]
set size: [300.000000, 100.000000]
orientation: 1, paper size: [300.000000, 100.000000] // orientation flip
Set NS_PORTRAIT orientation
orientation: 0, paper size: [100.000000, 300.000000] // size flip
``` 

There are four possible cases for printing a rectangle with different size and orientation:
1. Input: paper size: (w > h), orientation portrait
  [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: landscape
  [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (h, w), orientation: portrait
  Note: width and height are swapped
2. Input: paper size: (w > h), orientation landscape
  [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: portrait
  [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (w, h), orientation: landscape
3. Input: paper size: (w < h), orientation portrait
  [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: portrait
  [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (w, h), orientation: portrait
4. Input: paper size: (w < h), orientation landscape
  [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: landscape
  [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (h, w), orientation: landscape
  Note: width and height are swapped

Only for cases 1 and 4 the final width and height are swapped.
The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle.

It is not full fix which draws rectangles for cases 1 and 4 in the requested size.
Setting requested size leads that subsequent orientation flips width and height.
The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix.

Printed rectangles before and after the fix:
1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf),  [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf)
2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf),  [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf)
3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf),  [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf)
4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf),  [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf)

All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf),  [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf)

-------------

Commit messages:
 - 8295737: macOS: Print content cut off when width > height with portrait orientation

Changes: https://git.openjdk.org/jdk/pull/10808/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10808&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295737
  Stats: 360 lines in 2 files changed: 356 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10808.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10808/head:pull/10808

PR: https://git.openjdk.org/jdk/pull/10808


From tr at openjdk.org  Fri Oct 21 09:52:57 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 21 Oct 2022 09:52:57 GMT
Subject: RFR: 8295298: Automate
 javax/swing/JFileChooser/FileViewNPETest.java
In-Reply-To: <QllenU8UW_STmxGG98HBbySNFuLEJFSHAn2SbHsnza8=.09c8619b-49da-4fd5-be6d-f24801313caf@github.com>
References: <QllenU8UW_STmxGG98HBbySNFuLEJFSHAn2SbHsnza8=.09c8619b-49da-4fd5-be6d-f24801313caf@github.com>
Message-ID: <aGkvwMVkasNsElhX0tsn0-OzPHTQA29R0o6mCwdhr7Q=.2e803934-4b49-49ff-a0a3-c5b2bbc3b6e4@github.com>

On Thu, 20 Oct 2022 19:31:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The automated test follows the instructions of the manual test that was added in #10485.
> 
> Instead of selecting the parent folder from the **Look in** combo box, it calls `setCurrentDirectory` directly with the parent of the path which is not traversable. Thus, the current directory of the file chooser is set to `null`.
> 
> As the second step, the test finds the combo box and re-selects the currently selected element. Without the fix for [JDK-6616245](https://bugs.openjdk.org/browse/JDK-6616245), `NullPointerException` is thrown and the test fails; with the fix applied, the original folder is selected and the test passes.
> 
> @mrserb and @TejeshR13, please, take a look.

Marked as reviewed by tr (Author).

-------------

PR: https://git.openjdk.org/jdk/pull/10801


From ihse at openjdk.org  Fri Oct 21 10:20:50 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 10:20:50 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <ugwrZd3SjXfR7U6fVWnGCxcOUjsX_XvoKwqjFgHcBPU=.47f5b4d8-0ce5-4633-8a3a-7db0801d6338@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

Can you please refrain from integrating this while I investigate while this was originally moved?

-------------

Changes requested by ihse (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10757


From aivanov at openjdk.org  Fri Oct 21 11:34:05 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Oct 2022 11:34:05 GMT
Subject: RFR: 8295738: Automate javax/swing/JFileChooser/FileSizeCheck.java
 [v2]
In-Reply-To: <VIkeTYidMTjdV9cwai4WC0KLRXsUNHZEP43kXsC21pI=.b78cd68a-d4d3-4ea4-b7e2-16c98d63de30@github.com>
References: <VIkeTYidMTjdV9cwai4WC0KLRXsUNHZEP43kXsC21pI=.b78cd68a-d4d3-4ea4-b7e2-16c98d63de30@github.com>
Message-ID: <ZR-H_KGDEUgvBZyV3WmH5sADt3qFGkgQgE9dfWTJ1Ls=.4dc0b626-f7d7-4e31-9eca-5f97585a7520@github.com>

> This automates the test added in #9327.
> 
> The test has a set of objects which store the size of the file and the expected displayed size, the file name is generated automatically. The pattern for the file names ensures the files are displayed in the expected order up to and including gigabytes, 10 digits. I added more test cases that the original test had to verify the displayed size is rounded up, an automatic test can easily verify more rows than a human can.
> 
> The finds the **Details** button in the file chooser and clicks it, then it finds the table, finds the row where the first file is displayed. The test compares the size displayed in the table to the expected one. If it doesn't match, an error is printed to `stderr`. All the file sizes are verified. The first error message, if any, is thrown to fail the test.
> 
> The test passes with the fix for [JDK-8288882](https://bugs.openjdk.org/browse/JDK-8288882) and fails without it.

Alexey Ivanov has updated the pull request incrementally with four additional commits since the last revision:

 - Set the locale to US
 - Adjust wrapping for error message
 - Use local variable to store first error message
 - Shorter error message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10802/files
  - new: https://git.openjdk.org/jdk/pull/10802/files/1dc4e2b6..614b0977

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10802&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10802&range=00-01

  Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10802.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10802/head:pull/10802

PR: https://git.openjdk.org/jdk/pull/10802


From aivanov at openjdk.org  Fri Oct 21 11:34:05 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Oct 2022 11:34:05 GMT
Subject: RFR: 8295738: Automate javax/swing/JFileChooser/FileSizeCheck.java
 [v2]
In-Reply-To: <1WzutCZrI9dygTmpu0Dkail5ffmTinDherQ62qaCJbk=.fdb75b73-8cea-4bef-8395-55480da80391@github.com>
References: <VIkeTYidMTjdV9cwai4WC0KLRXsUNHZEP43kXsC21pI=.b78cd68a-d4d3-4ea4-b7e2-16c98d63de30@github.com>
 <1WzutCZrI9dygTmpu0Dkail5ffmTinDherQ62qaCJbk=.fdb75b73-8cea-4bef-8395-55480da80391@github.com>
Message-ID: <uHxSArGJrsvrlYarzsfeTfvWGw7AvFWkFgvJv4rE7KI=.c64597d1-d793-4582-9aad-49706641febc@github.com>

On Thu, 20 Oct 2022 23:34:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Set the locale to US
>>  - Adjust wrapping for error message
>>  - Use local variable to store first error message
>>  - Shorter error message
>
> test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 58:
> 
>> 56: public class FileSizeCheck {
>> 57:     private enum FileSize {
>> 58:         F0(    0, "0.0 KB"),
> 
> The text probably depends from the Locale? Do we need to set it explicitly?

I does, indeed. I set the locale to `Locale.US`.

-------------

PR: https://git.openjdk.org/jdk/pull/10802


From aivanov at openjdk.org  Fri Oct 21 11:37:06 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Oct 2022 11:37:06 GMT
Subject: RFR: 8295738: Automate javax/swing/JFileChooser/FileSizeCheck.java
 [v2]
In-Reply-To: <1WzutCZrI9dygTmpu0Dkail5ffmTinDherQ62qaCJbk=.fdb75b73-8cea-4bef-8395-55480da80391@github.com>
References: <VIkeTYidMTjdV9cwai4WC0KLRXsUNHZEP43kXsC21pI=.b78cd68a-d4d3-4ea4-b7e2-16c98d63de30@github.com>
 <1WzutCZrI9dygTmpu0Dkail5ffmTinDherQ62qaCJbk=.fdb75b73-8cea-4bef-8395-55480da80391@github.com>
Message-ID: <Uw0RcEYrz1If9VDChZ_4myOPB7HNG0DRSDmYjFHYdjA=.823ee62e-d36c-43a2-884e-d3ce9afabf4a@github.com>

On Thu, 20 Oct 2022 23:37:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Set the locale to US
>>  - Adjust wrapping for error message
>>  - Use local variable to store first error message
>>  - Shorter error message
>
> test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 158:
> 
>> 156:             robot.waitForIdle();
>> 157:             robot.delay(500);
>> 158:             SwingUtilities.invokeAndWait(FileSizeCheck::clickDetails);
> 
> Can we click that button programmatically w/o robot? That will make the test a little bit more stable.

It is clicked programmatically. https://github.com/openjdk/jdk/blob/1dc4e2b6279f2c0b3180d448c1ce688475c9b025/test/jdk/javax/swing/JFileChooser/FileSizeCheck.java#L221

Robot is used only for `waitForIdle` to ensure events are processed.

-------------

PR: https://git.openjdk.org/jdk/pull/10802


From erikj at openjdk.org  Fri Oct 21 12:59:48 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 21 Oct 2022 12:59:48 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <AoFGXlCHPgwZa3u0Kwp6W-h5k-I_Malb2gWa3tSxSbw=.500a110c-0c73-4205-9a2e-e281bfb3a730@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From duke at openjdk.org  Fri Oct 21 14:00:23 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 21 Oct 2022 14:00:23 GMT
Subject: RFR: 8295779: Xcode 14.0 fails to build jdk on m1 macos
Message-ID: <qFM8FAL3ZssjFrYBU8qVzgSBwTe0enKHGgnduFKVsqQ=.1aa3e867-d8d3-48e8-ae45-f6378c746ad2@github.com>

Building on MacOS 12.6 M1 with Xcode 14.0 fails due to C compiler unused parameter warnings:

Creating support/modules_libs/java.desktop/libosx.dylib from 1 file(s)

-------------

Commit messages:
 - Fix build failure on MacOS 12.6 M1 with Xcode 14.0.

Changes: https://git.openjdk.org/jdk/pull/10768/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10768&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295779
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10768.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10768/head:pull/10768

PR: https://git.openjdk.org/jdk/pull/10768


From vkempik at openjdk.org  Fri Oct 21 14:00:24 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Fri, 21 Oct 2022 14:00:24 GMT
Subject: RFR: 8295779: Xcode 14.0 fails to build jdk on m1 macos
In-Reply-To: <qFM8FAL3ZssjFrYBU8qVzgSBwTe0enKHGgnduFKVsqQ=.1aa3e867-d8d3-48e8-ae45-f6378c746ad2@github.com>
References: <qFM8FAL3ZssjFrYBU8qVzgSBwTe0enKHGgnduFKVsqQ=.1aa3e867-d8d3-48e8-ae45-f6378c746ad2@github.com>
Message-ID: <sUDSdpeqADhU6QlDkmoYmg2-WwzTr6uRQu1TLD8PlVc=.35bf6f7b-dbf3-4666-80e1-980fa25876e9@github.com>

On Wed, 19 Oct 2022 15:33:31 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Building on MacOS 12.6 M1 with Xcode 14.0 fails due to C compiler unused parameter warnings:
> 
> Creating support/modules_libs/java.desktop/libosx.dylib from 1 file(s)

Hello, a jbs bug needs to be created first, let me create one for this issue

Here it is - https://bugs.openjdk.org/browse/JDK-8295779
So please rename this PR to  "8295779: Xcode 14.0 fails to build jdk on m1 macos"

-------------

PR: https://git.openjdk.org/jdk/pull/10768


From duke at openjdk.org  Fri Oct 21 14:00:25 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 21 Oct 2022 14:00:25 GMT
Subject: RFR: 8295779: Xcode 14.0 fails to build jdk on m1 macos
In-Reply-To: <qFM8FAL3ZssjFrYBU8qVzgSBwTe0enKHGgnduFKVsqQ=.1aa3e867-d8d3-48e8-ae45-f6378c746ad2@github.com>
References: <qFM8FAL3ZssjFrYBU8qVzgSBwTe0enKHGgnduFKVsqQ=.1aa3e867-d8d3-48e8-ae45-f6378c746ad2@github.com>
Message-ID: <Bs-T0Jz2yVdMfDdqy4Ohoo_c3wQx57HoHBh-CHS2mh0=.82114bc7-dbd6-40cb-a652-89c76a2cf057@github.com>

On Wed, 19 Oct 2022 15:33:31 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Building on MacOS 12.6 M1 with Xcode 14.0 fails due to C compiler unused parameter warnings:
> 
> Creating support/modules_libs/java.desktop/libosx.dylib from 1 file(s)

Thanks for doing that! PR title updated.

-------------

PR: https://git.openjdk.org/jdk/pull/10768


From aivanov at openjdk.org  Fri Oct 21 15:29:44 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Oct 2022 15:29:44 GMT
Subject: RFR: 8295738: Automate javax/swing/JFileChooser/FileSizeCheck.java
 [v2]
In-Reply-To: <1WzutCZrI9dygTmpu0Dkail5ffmTinDherQ62qaCJbk=.fdb75b73-8cea-4bef-8395-55480da80391@github.com>
References: <VIkeTYidMTjdV9cwai4WC0KLRXsUNHZEP43kXsC21pI=.b78cd68a-d4d3-4ea4-b7e2-16c98d63de30@github.com>
 <1WzutCZrI9dygTmpu0Dkail5ffmTinDherQ62qaCJbk=.fdb75b73-8cea-4bef-8395-55480da80391@github.com>
Message-ID: <eIIzXjkyuGoIxmSnqfNkpZ_0lH6G_mHrXsHu_9qjawM=.f96ead64-8a66-4853-ac3b-576430960fa9@github.com>

On Thu, 20 Oct 2022 23:31:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Set the locale to US
>>  - Adjust wrapping for error message
>>  - Use local variable to store first error message
>>  - Shorter error message
>
> test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 51:
> 
>> 49:  * @bug 8288882
>> 50:  * @key headful
>> 51:  * @requires (os.family == "linux")
> 
> Why the linux platform only? I think it should be able to work on all platform if Metal is used?

The original bug was seen on Linux.

On Windows, `JFileChooser` extensively uses `ShellFolder` and displays additional columns in the detailed view, the displayed file size comes from the Windows shell too. If I run this test on Windows, it fails for each file size:

Wrong rendered size for F0: 0 bytes vs. 0.0 KB
Wrong rendered size for F1: 1 bytes vs. 0.1 KB
Wrong rendered size for F99: 99 bytes vs. 0.1 KB
?
Wrong rendered size for F2_800_000: 2.66 MB vs. 2.8 MB


The test can be run on macOS if `MetalLookAndFeel` is set, but I don't see much value in doing so because the number of Mac systems is usually scarce compared to Linux ones and the behaviour is well verified by running the test on Linux.

-------------

PR: https://git.openjdk.org/jdk/pull/10802


From aivanov at openjdk.org  Fri Oct 21 15:41:40 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Oct 2022 15:41:40 GMT
Subject: RFR: 8295738: Automate javax/swing/JFileChooser/FileSizeCheck.java
 [v2]
In-Reply-To: <1WzutCZrI9dygTmpu0Dkail5ffmTinDherQ62qaCJbk=.fdb75b73-8cea-4bef-8395-55480da80391@github.com>
References: <VIkeTYidMTjdV9cwai4WC0KLRXsUNHZEP43kXsC21pI=.b78cd68a-d4d3-4ea4-b7e2-16c98d63de30@github.com>
 <1WzutCZrI9dygTmpu0Dkail5ffmTinDherQ62qaCJbk=.fdb75b73-8cea-4bef-8395-55480da80391@github.com>
Message-ID: <HCCYkvS_Y4aeuqKHAY4fBQFY9LikJurtHPiWN5I1mYE=.34f1aa22-9172-4f75-99f1-6afefcb83976@github.com>

On Thu, 20 Oct 2022 23:36:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Set the locale to US
>>  - Adjust wrapping for error message
>>  - Use local variable to store first error message
>>  - Shorter error message
>
> test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 128:
> 
>> 126:     private static void createUI() {
>> 127:         // Create temp files
>> 128:         Path dir = Paths.get(".");
> 
> It is better to create a testFolder, and then open the chooser in it, otherwise other files in the current folder may break it(if the test executed standalone)

In my opinion, the current directory is a good enough option. When run in jtreg, it is set to `scratch` which is empty when the test starts; when run manually as a standalone app, the chances you have other files named `000-0000000000` in the current directory are quite low. The test does not depend on the first file being displayed in the first row of the table, it looks for it; yet it depends on all the files being displayed in the sequence without alternating with other files.

-------------

PR: https://git.openjdk.org/jdk/pull/10802


From naoto at openjdk.org  Fri Oct 21 16:09:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 16:09:28 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

One possible solution to this is to replace those dangling white spaces with explicit Unicode escapes, i.e. "\u0009" and "\u0020".  This way jcheck can safely be enabled to detect future unwanted trailing spaces, and possibly existing ones can be visually recognizable by the engineers to correct them.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From angorya at openjdk.org  Fri Oct 21 16:09:29 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Oct 2022 16:09:29 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
 <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>
Message-ID: <khuIARsEyKMyIfUxBD69kijyjnwDFCzAra51YwctMyY=.71b00eb7-1312-4db9-a6a5-ff85f7635132@github.com>

On Fri, 21 Oct 2022 16:04:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> replace those dangling white spaces with explicit Unicode escapes

this is a *very good* idea.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From aivanov at openjdk.org  Fri Oct 21 16:10:17 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Oct 2022 16:10:17 GMT
Subject: RFR: 8295298: Automate
 javax/swing/JFileChooser/FileViewNPETest.java [v2]
In-Reply-To: <QllenU8UW_STmxGG98HBbySNFuLEJFSHAn2SbHsnza8=.09c8619b-49da-4fd5-be6d-f24801313caf@github.com>
References: <QllenU8UW_STmxGG98HBbySNFuLEJFSHAn2SbHsnza8=.09c8619b-49da-4fd5-be6d-f24801313caf@github.com>
Message-ID: <ReupJVBb6NEcVAW2VpLIfc8-m5NdPBxI6KjYn7uAbIE=.a8f6f9a0-f7f1-429d-ba08-c03da57e4f28@github.com>

> The automated test follows the instructions of the manual test that was added in #10485.
> 
> Instead of selecting the parent folder from the **Look in** combo box, it calls `setCurrentDirectory` directly with the parent of the path which is not traversable. Thus, the current directory of the file chooser is set to `null`.
> 
> As the second step, the test finds the combo box and re-selects the currently selected element. Without the fix for [JDK-6616245](https://bugs.openjdk.org/browse/JDK-6616245), `NullPointerException` is thrown and the test fails; with the fix applied, the original folder is selected and the test passes.
> 
> @mrserb and @TejeshR13, please, take a look.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Convert asserts to explicit checks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10801/files
  - new: https://git.openjdk.org/jdk/pull/10801/files/c878454b..478f2070

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10801&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10801&range=00-01

  Stats: 8 lines in 1 file changed: 3 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10801.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10801/head:pull/10801

PR: https://git.openjdk.org/jdk/pull/10801


From tr at openjdk.org  Fri Oct 21 16:10:41 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 21 Oct 2022 16:10:41 GMT
Subject: RFR: 6244831: JFileChooser does not have tooltip for Desktop,
 Recent etc ToggleButton on Windows Look and feel
Message-ID: <1yxgaZjxkI6-vUTqgVLXOyt-a8GmnpDi45mZdFBsZGI=.793f8299-6c5d-48e3-9e96-44f337e7388d@github.com>

Tooltip is not shown for the buttons placed in left side of JFileChooser(In Windows Look And Feel), namely the shellFolder like (Recent Items, Desktop, Documents). Hence the tooltip is added for those shell folders/WindowBar when they are constructed. The Automatic test is added.

-------------

Commit messages:
 - Test case added
 - Fix

Changes: https://git.openjdk.org/jdk/pull/10819/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10819&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6244831
  Stats: 112 lines in 2 files changed: 112 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10819.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10819/head:pull/10819

PR: https://git.openjdk.org/jdk/pull/10819


From duke at openjdk.org  Fri Oct 21 18:07:52 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 21 Oct 2022 18:07:52 GMT
Subject: RFR: 8295738: Automate javax/swing/JFileChooser/FileSizeCheck.java
 [v2]
In-Reply-To: <ZR-H_KGDEUgvBZyV3WmH5sADt3qFGkgQgE9dfWTJ1Ls=.4dc0b626-f7d7-4e31-9eca-5f97585a7520@github.com>
References: <VIkeTYidMTjdV9cwai4WC0KLRXsUNHZEP43kXsC21pI=.b78cd68a-d4d3-4ea4-b7e2-16c98d63de30@github.com>
 <ZR-H_KGDEUgvBZyV3WmH5sADt3qFGkgQgE9dfWTJ1Ls=.4dc0b626-f7d7-4e31-9eca-5f97585a7520@github.com>
Message-ID: <8kR96cwuIO0r6sUYParQe35sya-so9ce0aBqpGdW9P8=.aacbfc78-724e-488d-b327-8f6b143c62b4@github.com>

On Fri, 21 Oct 2022 11:34:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This automates the test added in #9327.
>> 
>> The test has a set of objects which store the size of the file and the expected displayed size, the file name is generated automatically. The pattern for the file names ensures the files are displayed in the expected order up to and including gigabytes, 10 digits. I added more test cases that the original test had to verify the displayed size is rounded up, an automatic test can easily verify more rows than a human can.
>> 
>> The finds the **Details** button in the file chooser and clicks it, then it finds the table, finds the row where the first file is displayed. The test compares the size displayed in the table to the expected one. If it doesn't match, an error is printed to `stderr`. All the file sizes are verified. The first error message, if any, is thrown to fail the test.
>> 
>> The test passes with the fix for [JDK-8288882](https://bugs.openjdk.org/browse/JDK-8288882) and fails without it.
>
> Alexey Ivanov has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Set the locale to US
>  - Adjust wrapping for error message
>  - Use local variable to store first error message
>  - Shorter error message

I have verified the test, it's working fine.

-------------

Marked as reviewed by kumarabhi006 at github.com (no known OpenJDK username).

PR: https://git.openjdk.org/jdk/pull/10802


From duke at openjdk.org  Fri Oct 21 19:04:55 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 21 Oct 2022 19:04:55 GMT
Subject: RFR: 8295737: macOS: Print content cut off when width > height
 with portrait orientation
In-Reply-To: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
References: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
Message-ID: <XtXkgNZ8F7yByRKkDqRa98ZD6CgpbCrAFxLP1uh-shc=.5f9de1ab-fb1d-404c-b4c0-ee8ab2d48570@github.com>

On Fri, 21 Oct 2022 08:42:12 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation.
> 
> To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS.
> 
> Four rectangles are printed:
> 1. size 300x100, portrait orientation
> 2. size 300x100, landscape orientation
> 3. size 100x300, portrait orientation
> 4. size 100x300, landscape orientation
> 
> The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf)
> 
> The reason is that NSPrintInfo class does not allow to set paper size and orientation independently.
> Setting paper size width large than height changes NSPrintInfo orientation to landscape.
> Setting paper size width less than height changes NSPrintInfo orientation to portrait.
> Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height.
> 
> The Cocoa code that shows NSPrintInfo behavior:
> 
> #import <Cocoa/Cocoa.h>
> 
> int main()
> {
>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>     NSApp = [NSApplication sharedApplication];
> 
>     #ifdef __MAC_10_9 // code for SDK 10.9 or newer
>     #define NS_PORTRAIT NSPaperOrientationPortrait
>     #define NS_LANDSCAPE NSPaperOrientationLandscape
>     #else // code for SDK 10.8 or older
>     #define NS_PORTRAIT NSPortraitOrientation
>     #define NS_LANDSCAPE NSLandscapeOrientation
>     #endif
> 
>     printf("NS_PORTRAIT: %d\n", NS_PORTRAIT);
>     printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE);
> 
>     printf("create default print info\n");
>     NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy];
>     NSSize size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     printf("call setUpPrintOperationDefaultValues\n");
>     [defaultPrintInfo setUpPrintOperationDefaultValues];
>     size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     double w = 300.0;
>     double h = 100.0;
>     printf("set size: [%f, %f]\n", w, h);
>     [defaultPrintInfo setPaperSize:NSMakeSize(w, h)];
>     size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     printf("Set NS_PORTRAIT orientation\n");
>     [defaultPrintInfo setOrientation: NS_PORTRAIT];
>     size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     [NSApp run];
> 
>     [NSApp release];
>     [pool release];
>     return(EXIT_SUCCESS);
> } 
> 
> 
> On macOS Mojave 10.14.5 it prints:
> 
> 
> NS_PORTRAIT: 0
> NS_LANDSCAPE: 1
> create default print info
> orientation: 0, paper size: [612.000000, 792.000000]
> call setUpPrintOperationDefaultValues
> orientation: 0, paper size: [612.000000, 792.000000]
> set size: [300.000000, 100.000000]
> orientation: 1, paper size: [300.000000, 100.000000] // orientation flip
> Set NS_PORTRAIT orientation
> orientation: 0, paper size: [100.000000, 300.000000] // size flip
> ``` 
> 
> There are four possible cases for printing a rectangle with different size and orientation:
> 1. Input: paper size: (w > h), orientation portrait
>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: landscape
>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (h, w), orientation: portrait
>   Note: width and height are swapped
> 2. Input: paper size: (w > h), orientation landscape
>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: portrait
>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (w, h), orientation: landscape
> 3. Input: paper size: (w < h), orientation portrait
>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: portrait
>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (w, h), orientation: portrait
> 4. Input: paper size: (w < h), orientation landscape
>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: landscape
>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (h, w), orientation: landscape
>   Note: width and height are swapped
> 
> Only for cases 1 and 4 the final width and height are swapped.
> The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle.
> 
> It is not full fix which draws rectangles for cases 1 and 4 in the requested size.
> Setting requested size leads that subsequent orientation flips width and height.
> The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix.
> 
> Printed rectangles before and after the fix:
> 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf),  [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf)
> 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf),  [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf)
> 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf),  [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf)
> 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf),  [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf)
> 
> All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf),  [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf)

src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m line 340:

> 338:             orientation = NS_PORTRAIT;
> 339:             break;
> 340:     }

Could we replace the switch with an if statement? I don't see a reason why we need to query the orientation if we're just going to override it.


int format = (*env)->CallIntMethod(env,srcPageFormat, jm_getOrientation); // AWT_THREADING Safe (!appKit)
NSPaperOrientation orientation;
if (format == java_awt_print_PageFormat_LANDSCAPE || format == java_awt_print_PageFormat_REVERSE_LANDSCAPE)) {
    // AppKit printing doesn't support REVERSE_LANDSCAPE. Radar 2960295.
    //+++gdb Are LANDSCAPE and REVERSE_LANDSCAPE still inverted?
    orientation = NS_LANDSCAPE; //+++gdb Are LANDSCAPE and REVERSE_LANDSCAPE still inverted?
} else {
    orientation = NS_PORTRAIT;
}

src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m line 362:

> 360:     //   [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: landscape
> 361:     //   [dstPrintInfo setOrientation: NS_LANDSCAPE]   // size: (h, w), orientation: landscape
> 362:     //   Note: width and height are swapped

Comment is too lengthy. Here's my suggestion to condense.
Suggestion:

    // It's not possible to set NSPrinterInfo paper size and orientation independently.
    // Changing the paper size will change the orientation, and vise versa.

-------------

PR: https://git.openjdk.org/jdk/pull/10808


From serb at openjdk.org  Fri Oct 21 19:09:52 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Oct 2022 19:09:52 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <ugwrZd3SjXfR7U6fVWnGCxcOUjsX_XvoKwqjFgHcBPU=.47f5b4d8-0ce5-4633-8a3a-7db0801d6338@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <ugwrZd3SjXfR7U6fVWnGCxcOUjsX_XvoKwqjFgHcBPU=.47f5b4d8-0ce5-4633-8a3a-7db0801d6338@github.com>
Message-ID: <2G8pjhPykplr0Bx7-g8L6F2VMU6TbR_bBwCSotImpNo=.97454d13-1afe-49c9-8441-63cbf1f96496@github.com>

On Fri, 21 Oct 2022 10:18:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Can you please refrain from integrating this while I investigate while this was originally moved?

sure.

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From serb at openjdk.org  Fri Oct 21 19:15:55 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Oct 2022 19:15:55 GMT
Subject: RFR: 8295738: Automate javax/swing/JFileChooser/FileSizeCheck.java
 [v2]
In-Reply-To: <ZR-H_KGDEUgvBZyV3WmH5sADt3qFGkgQgE9dfWTJ1Ls=.4dc0b626-f7d7-4e31-9eca-5f97585a7520@github.com>
References: <VIkeTYidMTjdV9cwai4WC0KLRXsUNHZEP43kXsC21pI=.b78cd68a-d4d3-4ea4-b7e2-16c98d63de30@github.com>
 <ZR-H_KGDEUgvBZyV3WmH5sADt3qFGkgQgE9dfWTJ1Ls=.4dc0b626-f7d7-4e31-9eca-5f97585a7520@github.com>
Message-ID: <OAS5_xQszhRaHdApVgPxs_B5XoozmZmGWcNx87st7rQ=.ce77be79-f0c3-4212-9241-5a7dfef4e17c@github.com>

On Fri, 21 Oct 2022 11:34:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This automates the test added in #9327.
>> 
>> The test has a set of objects which store the size of the file and the expected displayed size, the file name is generated automatically. The pattern for the file names ensures the files are displayed in the expected order up to and including gigabytes, 10 digits. I added more test cases that the original test had to verify the displayed size is rounded up, an automatic test can easily verify more rows than a human can.
>> 
>> The finds the **Details** button in the file chooser and clicks it, then it finds the table, finds the row where the first file is displayed. The test compares the size displayed in the table to the expected one. If it doesn't match, an error is printed to `stderr`. All the file sizes are verified. The first error message, if any, is thrown to fail the test.
>> 
>> The test passes with the fix for [JDK-8288882](https://bugs.openjdk.org/browse/JDK-8288882) and fails without it.
>
> Alexey Ivanov has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Set the locale to US
>  - Adjust wrapping for error message
>  - Use local variable to store first error message
>  - Shorter error message

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10802


From serb at openjdk.org  Fri Oct 21 19:18:54 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Oct 2022 19:18:54 GMT
Subject: RFR: 8295298: Automate
 javax/swing/JFileChooser/FileViewNPETest.java [v2]
In-Reply-To: <ReupJVBb6NEcVAW2VpLIfc8-m5NdPBxI6KjYn7uAbIE=.a8f6f9a0-f7f1-429d-ba08-c03da57e4f28@github.com>
References: <QllenU8UW_STmxGG98HBbySNFuLEJFSHAn2SbHsnza8=.09c8619b-49da-4fd5-be6d-f24801313caf@github.com>
 <ReupJVBb6NEcVAW2VpLIfc8-m5NdPBxI6KjYn7uAbIE=.a8f6f9a0-f7f1-429d-ba08-c03da57e4f28@github.com>
Message-ID: <QB5HMKwkNi8mzVxLLkgYho4FIfgihsL9o93GHJYt-gs=.44285b62-16b1-4474-b6f7-c8e1213b1617@github.com>

On Fri, 21 Oct 2022 16:10:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The automated test follows the instructions of the manual test that was added in #10485.
>> 
>> Instead of selecting the parent folder from the **Look in** combo box, it calls `setCurrentDirectory` directly with the parent of the path which is not traversable. Thus, the current directory of the file chooser is set to `null`.
>> 
>> As the second step, the test finds the combo box and re-selects the currently selected element. Without the fix for [JDK-6616245](https://bugs.openjdk.org/browse/JDK-6616245), `NullPointerException` is thrown and the test fails; with the fix applied, the original folder is selected and the test passes.
>> 
>> @mrserb and @TejeshR13, please, take a look.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert asserts to explicit checks

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10801


From serb at openjdk.org  Fri Oct 21 20:02:22 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Oct 2022 20:02:22 GMT
Subject: RFR: 8295430: Use cmsDoTransformLineStride instead of cmsDoTransform
 in the loop
Message-ID: <0FRqG16zkqljRkLjTq1bplcPpoJAm98eLYvjZdR6g14=.35e8b2b3-defe-4af0-a98f-1fadd358e42d@github.com>

This is the request to improve the change made by the
[8005530: [lcms] Improve performance of ColorConverOp for default destinations](http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/fd8810d50c99)

Right now the LCMSTransform mantain the special "imageAtOnce" flags and call cmsDoTransform function in the loop per line to support the gaps betwen the lines in the images . This code can be improved by using one call to cmsDoTransformLineStride. Some discussion about this method can be found [here](https://github.com/mm2/Little-CMS/issues/314), the full [specification](https://github.com/mm2/Little-CMS/blob/master/doc/LittleCMS2.14%20API.pdf):


void cmsDoTransformLineStride(cmsHTRANSFORM Transform,
                              const void* InputBuffer,
                              void* OutputBuffer,
                              cmsUInt32Number PixelsPerLine,
                              cmsUInt32Number LineCount,
                              cmsUInt32Number BytesPerLineIn,
                              cmsUInt32Number BytesPerLineOut,
                              cmsUInt32Number BytesPerPlaneIn,
                              cmsUInt32Number BytesPerPlaneOut);

This function translates bitmaps with complex organization. Each bitmap may contain
several lines, and every may have padding. The distance from one line to the next one is
BytesPerLine{In/Out}. In planar formats, each line may hold several planes, each plane may
have padding. Padding of lines and planes should be same across all bitmap. I.e. all lines
in same bitmap have to be padded in same way. This function may be more efficient that
repeated calls to cmsDoTransform(), especially when customized plug-ins are being used.

Parameters:

-  hTransform: Handle to a color transform object.
-  InputBuffer: A pointer to the input bitmap
-  OutputBuffer: A pointer to the output bitmap.
-  PixelsPerLine: The number of pixels for line, which is same on input and in output.
-  LineCount: The number of lines, which is same on input and output
-  BytesPerLine{In,Out}: The distance in bytes from one line to the next one.
-  BytesPerPlaneIn{In,Out}: The distance in bytes from one plane to the next one inside a line. Only applies
                            in planar formats. 


Notes:
- This function is quite efficient, and is used by some plug-ins to give a big
  speedup. If you can load whole image to memory and then call this function
  over it, it will be much faster than any other approach.
- BytesPerPlaneIn{In,Out} is ignored if the formats used are not planar. Please note
  1-plane planar is indistinguishable from 1-component chunky, so BytesPerPlane is
  ignored as well in this case.
- If the image does not have any gaps between the pixels and lines BytesPerLine{}
  are equal to the pixel's size * PixelsPerLine.
- To specify padding between pixels, use T_EXTRA() and EXTRA_SH() to specify
  extra channels.

-------------

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into JDK-8295430
 - Merge remote-tracking branch 'upstream/master' into JDK-8295430
 - 8295430: Use cmsDoTransformLineStride instead of cmsDoTransform in the loop

Changes: https://git.openjdk.org/jdk/pull/10754/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10754&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295430
  Stats: 379 lines in 6 files changed: 340 ins; 34 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10754.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10754/head:pull/10754

PR: https://git.openjdk.org/jdk/pull/10754


From serb at openjdk.org  Fri Oct 21 20:02:24 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Oct 2022 20:02:24 GMT
Subject: RFR: 8295430: Use cmsDoTransformLineStride instead of
 cmsDoTransform in the loop
In-Reply-To: <0FRqG16zkqljRkLjTq1bplcPpoJAm98eLYvjZdR6g14=.35e8b2b3-defe-4af0-a98f-1fadd358e42d@github.com>
References: <0FRqG16zkqljRkLjTq1bplcPpoJAm98eLYvjZdR6g14=.35e8b2b3-defe-4af0-a98f-1fadd358e42d@github.com>
Message-ID: <uvfS9kDQFf3CXzypaTpMh1aQLWMOIzFGCl32FonvsWk=.43fbbbfe-941e-4722-887e-112a161ab881@github.com>

On Wed, 19 Oct 2022 02:59:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the request to improve the change made by the
> [8005530: [lcms] Improve performance of ColorConverOp for default destinations](http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/fd8810d50c99)
> 
> Right now the LCMSTransform mantain the special "imageAtOnce" flags and call cmsDoTransform function in the loop per line to support the gaps betwen the lines in the images . This code can be improved by using one call to cmsDoTransformLineStride. Some discussion about this method can be found [here](https://github.com/mm2/Little-CMS/issues/314), the full [specification](https://github.com/mm2/Little-CMS/blob/master/doc/LittleCMS2.14%20API.pdf):
> 
> 
> void cmsDoTransformLineStride(cmsHTRANSFORM Transform,
>                               const void* InputBuffer,
>                               void* OutputBuffer,
>                               cmsUInt32Number PixelsPerLine,
>                               cmsUInt32Number LineCount,
>                               cmsUInt32Number BytesPerLineIn,
>                               cmsUInt32Number BytesPerLineOut,
>                               cmsUInt32Number BytesPerPlaneIn,
>                               cmsUInt32Number BytesPerPlaneOut);
> 
> This function translates bitmaps with complex organization. Each bitmap may contain
> several lines, and every may have padding. The distance from one line to the next one is
> BytesPerLine{In/Out}. In planar formats, each line may hold several planes, each plane may
> have padding. Padding of lines and planes should be same across all bitmap. I.e. all lines
> in same bitmap have to be padded in same way. This function may be more efficient that
> repeated calls to cmsDoTransform(), especially when customized plug-ins are being used.
> 
> Parameters:
> 
> -  hTransform: Handle to a color transform object.
> -  InputBuffer: A pointer to the input bitmap
> -  OutputBuffer: A pointer to the output bitmap.
> -  PixelsPerLine: The number of pixels for line, which is same on input and in output.
> -  LineCount: The number of lines, which is same on input and output
> -  BytesPerLine{In,Out}: The distance in bytes from one line to the next one.
> -  BytesPerPlaneIn{In,Out}: The distance in bytes from one plane to the next one inside a line. Only applies
>                             in planar formats. 
> 
> 
> Notes:
> - This function is quite efficient, and is used by some plug-ins to give a big
>   speedup. If you can load whole image to memory and then call this function
>   over it, it will be much faster than any other approach.
> - BytesPerPlaneIn{In,Out} is ignored if the formats used are not planar. Please note
>   1-plane planar is indistinguishable from 1-component chunky, so BytesPerPlane is
>   ignored as well in this case.
> - If the image does not have any gaps between the pixels and lines BytesPerLine{}
>   are equal to the pixel's size * PixelsPerLine.
> - To specify padding between pixels, use T_EXTRA() and EXTRA_SH() to specify
>   extra channels.

src/java.desktop/share/native/liblcms/LCMS.c line 554:

> 552: 
> 553:     cmsDoTransformLineStride(sTrans, input, output, width, height,
> 554:                              srcNextRowOffset, dstNextRowOffset, 0, 0);

We do not use "planar" types, so the last two parameters are ignored.

-------------

PR: https://git.openjdk.org/jdk/pull/10754


From aivanov at openjdk.org  Fri Oct 21 21:27:51 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 21 Oct 2022 21:27:51 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v7]
In-Reply-To: <pRK-MA1QAQMcJCVvzgcccVJDJ98muUKGjczZ7CODAko=.e72f79ce-7a5e-49aa-a111-d8fbc9add718@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <pRK-MA1QAQMcJCVvzgcccVJDJ98muUKGjczZ7CODAko=.e72f79ce-7a5e-49aa-a111-d8fbc9add718@github.com>
Message-ID: <6k77FcLBO337lfDL3KVuatd93reixvI-1sUKfW-qA_0=.6b5de255-99e6-4723-a7b5-55515b9985a4@github.com>

On Fri, 21 Oct 2022 03:37:16 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.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removeIndexInterval, insertIndexInterval fix

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 653:

> 651:         if (length < 0 || index < 0) {
> 652:             return;
> 653:         }

Throw IOOBE as it's done in other methods. Silently ignoring bad parameters isn't good, likely it means an error in the calling code.

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 656:

> 654:         if (index + length < 0) {
> 655:             return;
> 656:         }

Other methods, like `removeIndexInterval`, accept parameters which result in integer overflow, I think this should allow it too. Yet you have to ensure `index + length` isn't greater than `Integer.MAX_VALUE`. I mean `length` should be normalized in such a case, so that it doesn't cause the overflow.

Something like `length = Integer.MAX_VALUE - index`, it's off the top of my head, I haven't verified it's correct, it's just an idea on how this should be handled.

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 669:

> 667:         if (length + maxIndex < 0) {
> 668:             maxIndex = Integer.MAX_VALUE - length;
> 669:         }

You must not change `maxIndex` this way ? you just broke the class invariant: **`maxIndex` points to the highest selected index**. Now it doesn't.

You have to make sure `i + length <= Integer.MAX_VALUE` but you must not modify `maxIndex` directly. This would probably be handled automatically if you normalize `length`. If not, the body of `if` may need a condition. Alternatively, a better way, the start value of `i` should be reduced so that is always `i + length <= Integer.MAX_VALUE` and doesn't cause integer overflow.

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 735:

> 733:             setState(i, (i <= Integer.MAX_VALUE - gapLength)
> 734:                     && (i + gapLength >= minIndex)
> 735:                     && value.get(i + gapLength));

I would prefer if the `&&` operators are aligned to the opening parenthesis of the first condition, it makes it clearer that the condition is part of the second parameter. I don't insist on this one, the wrapping style is not agreed on.

-------------

PR: https://git.openjdk.org/jdk/pull/10409


From honkar at openjdk.org  Fri Oct 21 22:21:09 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 21 Oct 2022 22:21:09 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v11]
In-Reply-To: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
Message-ID: <1T21tMiVjVBLFw5lOCScck46i9MSse56klmgbWRrsks=.de04fd0d-c624-4aa9-9277-6e8be6877a45@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:

  new x,y and translate component added to fix pixel painting issue

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10274/files
  - new: https://git.openjdk.org/jdk/pull/10274/files/99664b3b..4fa34904

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10274&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10274&range=09-10

  Stats: 11 lines in 1 file changed: 3 ins; 0 del; 8 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 Oct 21 22:40:24 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 21 Oct 2022 22:40:24 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v11]
In-Reply-To: <1T21tMiVjVBLFw5lOCScck46i9MSse56klmgbWRrsks=.de04fd0d-c624-4aa9-9277-6e8be6877a45@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <1T21tMiVjVBLFw5lOCScck46i9MSse56klmgbWRrsks=.de04fd0d-c624-4aa9-9277-6e8be6877a45@github.com>
Message-ID: <KvoWypNLyMopHRhZLSE6V1qG84COiVbcQAg9riHkdm0=.3ecd376f-d568-4c05-b614-154208c1e86e@github.com>

On Fri, 21 Oct 2022 22:21:09 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:
> 
>   new x,y and translate component added to fix pixel painting issue

While testing, following issues were observed -
- Uneven border thickness (no. of pixels painted differed on 4 sides) thus making it difficult to evenly place the shadow and highlight lines - This was resolved by using an even multiplier (4) for border thickness instead of odd (5) and changing border insets to same number (4).
- Edges of border being painted over background and titlebar resolved by using even multiplier
- Shadow and highlight line painted at different offsets at left and bottom of the border even though the start location was same - Adding scaled x, y and respective translate to the scaled width and height as suggested by @aivanov-jdk helped to achieve consistent placement of the lines on all scales.


                w = clipRound(at.getScaleX() * width + xx) - xtranslation;
                h = clipRound(at.getScaleY() * height + yy) - ytranslation;

-------------

PR: https://git.openjdk.org/jdk/pull/10274


From dnguyen at openjdk.org  Fri Oct 21 22:55:49 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 21 Oct 2022 22:55:49 GMT
Subject: RFR: 8295248: JEditorPane HTML form with multi selection broke
 drawing after reseting [v2]
In-Reply-To: <UZyvKviWLdxsdAbfgaJkNRt860Jl0crItOzjouxn27M=.f8fc1388-9d3c-4f9d-a4d1-20eb846bfa4d@github.com>
References: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
 <UZyvKviWLdxsdAbfgaJkNRt860Jl0crItOzjouxn27M=.f8fc1388-9d3c-4f9d-a4d1-20eb846bfa4d@github.com>
Message-ID: <oAelyPsV_dUVfcwXMoJwH2WBrZuwGryHw8tmIwF89go=.f9257954-0c41-4b4f-baf7-d2eb836db1c3@github.com>

On Mon, 17 Oct 2022 01:38:00 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> When JEditorPane shown HTML form with multi-selection, the reset operation broke its drawing.
>> 
>> There are two issues. The current method `OptionListModel.removeIndexInterval()` disabled selections, but it didn't fire the change. Then, no re-drawing. Another issue is the method works as remove and shift. Then, selection values were corrupted.
>> I think the clear method `OptionListModel.clearSelection()` is suitable here.
>> 
>> Test: jdk_desktop on macOS (x64, Monterey), Linux (x64, RHEL8), and Windows (x64, 2012R2).
>>       No regression found
>
> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update testcase

Changes requested by dnguyen (Author).

test/jdk/javax/swing/text/html/TestResetSelectForm.java line 93:

> 91:             if (getMaxColorDiff(baseColor, c) > LIMIT) {
> 92:                 throw new RuntimeException("Unexpected List selection at " +
> 93:                     (i+1) + ", " + baseColor + "," + c);

The points mentioned seem valid since I see the same things when I test it myself. OptionListModel's clearSelection is being called without the drawing updating. The fix seems logical and works as intended.

Just to nitpick, adding a space before and after the '+' in '(i+1)' here would match the pattern of all the other additions.

-------------

PR: https://git.openjdk.org/jdk/pull/10685


From prr at openjdk.org  Sun Oct 23 00:41:09 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 23 Oct 2022 00:41:09 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <2G8pjhPykplr0Bx7-g8L6F2VMU6TbR_bBwCSotImpNo=.97454d13-1afe-49c9-8441-63cbf1f96496@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <ugwrZd3SjXfR7U6fVWnGCxcOUjsX_XvoKwqjFgHcBPU=.47f5b4d8-0ce5-4633-8a3a-7db0801d6338@github.com>
 <2G8pjhPykplr0Bx7-g8L6F2VMU6TbR_bBwCSotImpNo=.97454d13-1afe-49c9-8441-63cbf1f96496@github.com>
Message-ID: <7Xv3WEWo4oo152yiMpD9bKzhaAKJM3jJLp5HbuE44HE=.da915a24-7441-4bfd-beb0-a2b5fea11f74@github.com>

On Fri, 21 Oct 2022 19:06:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Can you please refrain from integrating this while I investigate while this was originally moved?
> 
> sure.

It was moved because it was designed for use by AWT and SOMEHOW during all the reshuffle for the modular JDK in JDK 9 it ended up in base, which doesn't use it and doesn't want it - it belongs in the desktop module.

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From prr at openjdk.org  Sun Oct 23 00:41:10 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 23 Oct 2022 00:41:10 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <kM7au4SfOdQxSS_s4CvCLxx0U4rqwpbuLPu0-vqunJg=.6e411ab7-bbdc-4d3c-9611-14fb11fd2aaa@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <kM7au4SfOdQxSS_s4CvCLxx0U4rqwpbuLPu0-vqunJg=.6e411ab7-bbdc-4d3c-9611-14fb11fd2aaa@github.com>
Message-ID: <sSHqPUKao0r0CWHr5pYumXydGoEHIK2zFhbGroy1nq4=.a57a53fe-e3ec-4c40-8afd-a5bb9c9cbaf7@github.com>

On Thu, 20 Oct 2022 04:15:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".
>
> make/common/modules/LauncherCommon.gmk line 48:
> 
>> 46: LAUNCHER_SRC := $(TOPDIR)/src/java.base/share/native/launcher
>> 47: LAUNCHER_CFLAGS += -I$(TOPDIR)/src/java.base/share/native/launcher \
>> 48:     -I$(TOPDIR)/src/java.desktop/share/native/include \
> 
> This line was added recently, not sure why.

Hmm .. IIRC Alex Zuev said  there is a (closed) native test and adding this was the only way he could make that test work .. 
Now clearly this location no longer makes sense when the file is moved, but someone will need to do something about the test. It needs Alex to chime in here.

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From prr at openjdk.org  Sun Oct 23 01:26:37 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 23 Oct 2022 01:26:37 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <sSHqPUKao0r0CWHr5pYumXydGoEHIK2zFhbGroy1nq4=.a57a53fe-e3ec-4c40-8afd-a5bb9c9cbaf7@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <kM7au4SfOdQxSS_s4CvCLxx0U4rqwpbuLPu0-vqunJg=.6e411ab7-bbdc-4d3c-9611-14fb11fd2aaa@github.com>
 <sSHqPUKao0r0CWHr5pYumXydGoEHIK2zFhbGroy1nq4=.a57a53fe-e3ec-4c40-8afd-a5bb9c9cbaf7@github.com>
Message-ID: <IuMVFpIBKI-gbjDgXfYvv9ZOansGZiiCJIVeOZeSmps=.dabbaa85-6f11-428d-835e-14e729322f23@github.com>

On Sun, 23 Oct 2022 00:36:11 GMT, Phil Race <prr at openjdk.org> wrote:

>> make/common/modules/LauncherCommon.gmk line 48:
>> 
>>> 46: LAUNCHER_SRC := $(TOPDIR)/src/java.base/share/native/launcher
>>> 47: LAUNCHER_CFLAGS += -I$(TOPDIR)/src/java.base/share/native/launcher \
>>> 48:     -I$(TOPDIR)/src/java.desktop/share/native/include \
>> 
>> This line was added recently, not sure why.
>
> Hmm .. IIRC Alex Zuev said  there is a (closed) native test and adding this was the only way he could make that test work .. 
> Now clearly this location no longer makes sense when the file is moved, but someone will need to do something about the test. It needs Alex to chime in here.

Superficially, it looks like the closed test has a direct pointer to where to get this which would need to be re-adjusted
but now I really do need Alex to explain why the above include dir was needed .. since it isn't for the closed test.

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From tnakamura at openjdk.org  Mon Oct 24 02:06:23 2022
From: tnakamura at openjdk.org (Toshio Nakamura)
Date: Mon, 24 Oct 2022 02:06:23 GMT
Subject: RFR: 8295248: JEditorPane HTML form with multi selection broke
 drawing after reseting [v3]
In-Reply-To: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
References: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
Message-ID: <XJ54TYURwthQqWedWpAuAGeRuDqq043NdAQRcucAWpc=.6160f318-c362-4788-909e-7f9932ee99fb@github.com>

> When JEditorPane shown HTML form with multi-selection, the reset operation broke its drawing.
> 
> There are two issues. The current method `OptionListModel.removeIndexInterval()` disabled selections, but it didn't fire the change. Then, no re-drawing. Another issue is the method works as remove and shift. Then, selection values were corrupted.
> I think the clear method `OptionListModel.clearSelection()` is suitable here.
> 
> Test: jdk_desktop on macOS (x64, Monterey), Linux (x64, RHEL8), and Windows (x64, 2012R2).
>       No regression found

Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:

  Fixed space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10685/files
  - new: https://git.openjdk.org/jdk/pull/10685/files/e1ff53d2..afe379e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10685&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10685&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10685.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10685/head:pull/10685

PR: https://git.openjdk.org/jdk/pull/10685


From tnakamura at openjdk.org  Mon Oct 24 02:06:25 2022
From: tnakamura at openjdk.org (Toshio Nakamura)
Date: Mon, 24 Oct 2022 02:06:25 GMT
Subject: RFR: 8295248: JEditorPane HTML form with multi selection broke
 drawing after reseting [v2]
In-Reply-To: <oAelyPsV_dUVfcwXMoJwH2WBrZuwGryHw8tmIwF89go=.f9257954-0c41-4b4f-baf7-d2eb836db1c3@github.com>
References: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
 <UZyvKviWLdxsdAbfgaJkNRt860Jl0crItOzjouxn27M=.f8fc1388-9d3c-4f9d-a4d1-20eb846bfa4d@github.com>
 <oAelyPsV_dUVfcwXMoJwH2WBrZuwGryHw8tmIwF89go=.f9257954-0c41-4b4f-baf7-d2eb836db1c3@github.com>
Message-ID: <JGAyrI0tFPc3IwtMygoIfrzxdUnNGt9I8cIwuqyHr5g=.b6d6c683-3211-4037-9713-a3d648923e39@github.com>

On Fri, 21 Oct 2022 22:51:49 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update testcase
>
> test/jdk/javax/swing/text/html/TestResetSelectForm.java line 93:
> 
>> 91:             if (getMaxColorDiff(baseColor, c) > LIMIT) {
>> 92:                 throw new RuntimeException("Unexpected List selection at " +
>> 93:                     (i+1) + ", " + baseColor + "," + c);
> 
> The points mentioned seem valid since I see the same things when I test it myself. OptionListModel's clearSelection is being called without the drawing updating. The fix seems logical and works as intended.
> 
> Just to nitpick, adding a space before and after the '+' in '(i+1)' here would match the pattern of all the other additions.

@DamonGuy Thank you for the comments. Fixed.

-------------

PR: https://git.openjdk.org/jdk/pull/10685


From prr at openjdk.org  Mon Oct 24 03:47:49 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 03:47:49 GMT
Subject: RFR: 8294466: Minimize disabled warnings in java.desktop
In-Reply-To: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
References: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
Message-ID: <kDQN9zmu4zJG-L8dnC2-zDyqlz86q-SwMb8t82EPtLY=.06bd4677-4fa5-4549-abe4-6fc28803fc19@github.com>

On Thu, 20 Oct 2022 10:36:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.
> 
> (This is a reboot of https://github.com/openjdk/jdk/pull/10453)

Looks OK. I mean it still builds, right ? That's the test here.
The only comment is that you established a sort-of precedent of including the 3rd party libs.
But I don't see the harm in the specific cases as these are ones here are ones we rarely update.
Just let's not try to do this for 3rd party libraries where there are lots of warnings across lots of files that change a lot as we update source and/or compiler.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10790


From prr at openjdk.org  Mon Oct 24 03:54:06 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 03:54:06 GMT
Subject: RFR: 8295717: Minimize disabled warnings in accessibility native
 code
In-Reply-To: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
References: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
Message-ID: <g83FVheeVcYhiGmEEN3ArdtVZlJO6jnkTdYDeFcn-Tw=.66bb487f-72b0-44a0-9a54-129f021a72d5@github.com>

On Thu, 20 Oct 2022 10:24:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the accessibility native code.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10788


From prr at openjdk.org  Mon Oct 24 03:54:07 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 03:54:07 GMT
Subject: RFR: 8295717: Minimize disabled warnings in accessibility native
 code
In-Reply-To: <c9QBA0xrPmEhinXsbjBFoys3OA3xzsXHXjRm345RObM=.a1a76b72-1c48-4826-9a78-f42d2cc1b133@github.com>
References: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
 <ce7zx48PfM_s8PbgHd7AEdYQ3O4mhBcovYe37HMGMkI=.24f69caf-f657-4740-84be-3ebde04cf487@github.com>
 <c9QBA0xrPmEhinXsbjBFoys3OA3xzsXHXjRm345RObM=.a1a76b72-1c48-4826-9a78-f42d2cc1b133@github.com>
Message-ID: <p-U1J7hO70qNrQT35ippHpnxFVPvxmGs195P4e9504o=.9f0c0722-6631-4ee1-a2ba-2b3e3f4ea37f@github.com>

On Thu, 20 Oct 2022 18:56:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/jdk.accessibility/Launcher.gmk line 46:
>> 
>>> 44:           -analyze- -Od -Gd -D_WINDOWS \
>>> 45:           -D_UNICODE -DUNICODE -RTC1 -EHsc, \
>>> 46:       DISABLED_WARNINGS_microsoft_jabswitch.cpp := 4267 4996, \
>> 
>> This lib only has one cpp file, so this change doesn't seem that useful.
>
> Heh, I did not notice that.
> 
> I'd still argue that this is a useful change. If some other file were ever to be added, it will not be covered by the blanked disabled warnings, and -- perhaps more important -- it is clear that these warnings can be addressed just by looking at a single file. This information has drastically increased the likelihood that a developer picks up the issue and actually resolves the warnings, as we have seen in other areas where I've done this "warnings-per-file" transition.

I suspect there's already a "fix disabled warnings in jdk.accessibility" .. can't we just fix that instead ?
I found it : https://bugs.openjdk.org/browse/JDK-8074847
Let me see what I can do about it.

-------------

PR: https://git.openjdk.org/jdk/pull/10788


From prr at openjdk.org  Mon Oct 24 03:54:07 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 03:54:07 GMT
Subject: RFR: 8295717: Minimize disabled warnings in accessibility native
 code
In-Reply-To: <p-U1J7hO70qNrQT35ippHpnxFVPvxmGs195P4e9504o=.9f0c0722-6631-4ee1-a2ba-2b3e3f4ea37f@github.com>
References: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
 <ce7zx48PfM_s8PbgHd7AEdYQ3O4mhBcovYe37HMGMkI=.24f69caf-f657-4740-84be-3ebde04cf487@github.com>
 <c9QBA0xrPmEhinXsbjBFoys3OA3xzsXHXjRm345RObM=.a1a76b72-1c48-4826-9a78-f42d2cc1b133@github.com>
 <p-U1J7hO70qNrQT35ippHpnxFVPvxmGs195P4e9504o=.9f0c0722-6631-4ee1-a2ba-2b3e3f4ea37f@github.com>
Message-ID: <H8NXj7UEFVMk1BUTdikcfu3F5360ZQEej2IKfwne83Y=.7af6f382-ee69-4651-9367-f60134a97b87@github.com>

On Mon, 24 Oct 2022 03:49:17 GMT, Phil Race <prr at openjdk.org> wrote:

>> Heh, I did not notice that.
>> 
>> I'd still argue that this is a useful change. If some other file were ever to be added, it will not be covered by the blanked disabled warnings, and -- perhaps more important -- it is clear that these warnings can be addressed just by looking at a single file. This information has drastically increased the likelihood that a developer picks up the issue and actually resolves the warnings, as we have seen in other areas where I've done this "warnings-per-file" transition.
>
> I suspect there's already a "fix disabled warnings in jdk.accessibility" .. can't we just fix that instead ?
> I found it : https://bugs.openjdk.org/browse/JDK-8074847
> Let me see what I can do about it.

but I'll approve this anyway .. no harm

-------------

PR: https://git.openjdk.org/jdk/pull/10788


From prr at openjdk.org  Mon Oct 24 03:55:56 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 03:55:56 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <6Nga-zBIoxnexiDJp-uJqSHjkki2U2n6y5WW9chvPz0=.f389c36c-e6bd-4b32-81a2-0304f23ba6a2@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From prr at openjdk.org  Mon Oct 24 04:11:46 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 04:11:46 GMT
Subject: RFR: 8295779: Xcode 14.0 fails to build jdk on m1 macos
In-Reply-To: <qFM8FAL3ZssjFrYBU8qVzgSBwTe0enKHGgnduFKVsqQ=.1aa3e867-d8d3-48e8-ae45-f6378c746ad2@github.com>
References: <qFM8FAL3ZssjFrYBU8qVzgSBwTe0enKHGgnduFKVsqQ=.1aa3e867-d8d3-48e8-ae45-f6378c746ad2@github.com>
Message-ID: <tYuNts6YaQnuzP5iJAmlfXn51V1EyoBZn4ciMaGJvZE=.6ce3bb9e-caf2-49ac-8f6c-22cabd6263cb@github.com>

On Wed, 19 Oct 2022 15:33:31 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Building on MacOS 12.6 M1 with Xcode 14.0 fails due to C compiler unused parameter warnings:
> 
> Creating support/modules_libs/java.desktop/libosx.dylib from 1 file(s)

Nope. This isn't the right thing to do. This is a 3rd party library.
Go to upstream and request source code changes.
But you are too late. I submitted an upstream PR for this months ago 
https://github.com/mm2/Little-CMS/commit/9575107f11fa0f8f326c88c8f730649be728d997
The 2nd case you cite is no longer in upstream as far as I can tel.
And we will be pulling in LCMS 2.14 in a couple of weeks.
If there's any outstanding issues it will be handled in that PR anyway.
So this PR should be withdrawn.

-------------

Changes requested by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10768


From prr at openjdk.org  Mon Oct 24 04:14:59 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 04:14:59 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <axHxt2piKk_7MiZ5-QsQ0dS5LCtZ8gqmH8PEqt5eDbw=.29b721e7-3203-44f7-b82e-73490da7fa15@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From prr at openjdk.org  Mon Oct 24 04:19:46 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 04:19:46 GMT
Subject: RFR: 8295767: Remove unused fields in sun.awt.geom.Edge
In-Reply-To: <Hf8VzgFNka7JbpjDTh4_eDbKPqmSwp3f7zM8ximg-0E=.771f0e85-5add-4f65-b5bc-90c62b423b5f@github.com>
References: <Hf8VzgFNka7JbpjDTh4_eDbKPqmSwp3f7zM8ximg-0E=.771f0e85-5add-4f65-b5bc-90c62b423b5f@github.com>
Message-ID: <T6Ccvg2zdHBhHxOJlO0ytVOOc3hRYC8_hhVWA6-4-co=.09f68be8-2362-49fd-a82d-091b7208e2b3@github.com>

On Sun, 16 Oct 2022 21:30:47 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Remove couple of unused `static` fields in `sun.awt.geom.Edge` class.

Hmm, not sure its worth checking into when this was obsoleted. Clearly not used now.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10720


From prr at openjdk.org  Mon Oct 24 04:30:45 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 04:30:45 GMT
Subject: RFR: 8295248: JEditorPane HTML form with multi selection broke
 drawing after reseting [v3]
In-Reply-To: <XJ54TYURwthQqWedWpAuAGeRuDqq043NdAQRcucAWpc=.6160f318-c362-4788-909e-7f9932ee99fb@github.com>
References: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
 <XJ54TYURwthQqWedWpAuAGeRuDqq043NdAQRcucAWpc=.6160f318-c362-4788-909e-7f9932ee99fb@github.com>
Message-ID: <ONuUz9De4hGoEk8j-OYAXn8G_4Hl3QMScNEIcSf5aQE=.9b6b0c16-9d96-4899-805d-a90f6aed2722@github.com>

On Mon, 24 Oct 2022 02:06:23 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> When JEditorPane shown HTML form with multi-selection, the reset operation broke its drawing.
>> 
>> There are two issues. The current method `OptionListModel.removeIndexInterval()` disabled selections, but it didn't fire the change. Then, no re-drawing. Another issue is the method works as remove and shift. Then, selection values were corrupted.
>> I think the clear method `OptionListModel.clearSelection()` is suitable here.
>> 
>> Test: jdk_desktop on macOS (x64, Monterey), Linux (x64, RHEL8), and Windows (x64, 2012R2).
>>       No regression found
>
> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed space

Can you try again to describe the issue ? 
The bug summary is misleading I'm sure. "Drawing" as in RENDERING is NOT broken.
I think you are trying to say something about expectations for what item(s) are selected .. 
Perhaps what is missing is a PROPER explanation of what you think reset and submit should do and so forth.
And this looks like one of those "tiny" changes which are "completely harmless" but you have said NOTHING about what wider testing you've done on other cases. Fix one case != make things uniformly better ..

-------------

PR: https://git.openjdk.org/jdk/pull/10685


From prr at openjdk.org  Mon Oct 24 04:40:46 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 04:40:46 GMT
Subject: RFR: 8294807: Fix typos and clarify javadoc for
 SunToolKit.realsSync
In-Reply-To: <eOSJ4nSjRiskHcEirxMJmllsCP0e0wHQQ8__azU0CEw=.3a2a29b2-a349-43f9-bbd5-14b6e2ee32a2@github.com>
References: <eOSJ4nSjRiskHcEirxMJmllsCP0e0wHQQ8__azU0CEw=.3a2a29b2-a349-43f9-bbd5-14b6e2ee32a2@github.com>
Message-ID: <DWaViDe_Y8fTfh-vR2WaeEP0qjxmfpPq3z1wP1W7YVk=.35c1a044-476a-4ebd-bd87-2c00f0aea67c@github.com>

On Tue, 4 Oct 2022 20:21:10 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I fixed the typo ?serie? ? "series" which was highlighted by a spellchecker.
> 
> I also simplified the description, fixed the grammar, added `{@code}` around types, added link to `requestFocus` in the example.

src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1446:

> 1444:      * return no additional Java events will be generated, unless
> 1445:      * caused by user. Obviously, the method cannot be used on the
> 1446:      * event dispatch thread (EDT). In case it gets

since we are being picky about grammar here, let's write "caused by the user"

And "In case it gets invoked on this thread" - > "If it is invoked on the EDT"

Ah .. whatever .. just fix grammar without going overboard here.
The bug summary about "javadoc" makes this sound like spec but is is NOT.
It is INTERNAL CODE COMMENTS. Really this is hardly worth more than a few minutes of anyone's time.
And (as Sergey is perhaps hinting at) we really don't want to encourage EVEN TESTS to be going here.
If Robot tests need this we should be pondering an API level fix instead ..

-------------

PR: https://git.openjdk.org/jdk/pull/10563


From prr at openjdk.org  Mon Oct 24 04:45:41 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 04:45:41 GMT
Subject: RFR: 8295323: Unnecessary HashTable usage in StyleSheet
In-Reply-To: <iR1IT4_fnOpf0QDXsvToT8uJXkASMb_FFkJbozapAiY=.fcb62fe5-e864-4dc5-845d-638ea5c0fdc2@github.com>
References: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
 <iR1IT4_fnOpf0QDXsvToT8uJXkASMb_FFkJbozapAiY=.fcb62fe5-e864-4dc5-845d-638ea5c0fdc2@github.com>
Message-ID: <E7ELwS_ym7HRMLnXnO_vlyRLEy7Xdlf2wYyzXSE0qfM=.97fcedee-aa0c-43cf-9cb5-eb3851b9500f@github.com>

On Wed, 5 Oct 2022 18:04:41 GMT, SWinxy <duke at openjdk.org> wrote:

>> Hashtable was used only from single thread. And only non-null key/values added to it. We can safely replace it with HashSet.
>
> src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 1364:
> 
>> 1362:                            HashSet<SelectorMapping> alreadyChecked) {
>> 1363:         // Avoid descending the same mapping twice.
>> 1364:         if (!alreadyChecked.add(parentMapping)) {
> 
> Clever!

Seriously ? That is your explanation ? Do better.

-------------

PR: https://git.openjdk.org/jdk/pull/10522


From tnakamura at openjdk.org  Mon Oct 24 05:26:32 2022
From: tnakamura at openjdk.org (Toshio Nakamura)
Date: Mon, 24 Oct 2022 05:26:32 GMT
Subject: RFR: 8295248: JEditorPane HTML form with multi selection broke
 drawing after reseting [v3]
In-Reply-To: <ONuUz9De4hGoEk8j-OYAXn8G_4Hl3QMScNEIcSf5aQE=.9b6b0c16-9d96-4899-805d-a90f6aed2722@github.com>
References: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
 <XJ54TYURwthQqWedWpAuAGeRuDqq043NdAQRcucAWpc=.6160f318-c362-4788-909e-7f9932ee99fb@github.com>
 <ONuUz9De4hGoEk8j-OYAXn8G_4Hl3QMScNEIcSf5aQE=.9b6b0c16-9d96-4899-805d-a90f6aed2722@github.com>
Message-ID: <wCFvJmOUAWaYYQD-Yp70QdIfCDFM9VXQNueT6RQ8-Zk=.afb040a1-0361-4306-a0a0-f31259a48c1b@github.com>

On Mon, 24 Oct 2022 04:27:15 GMT, Phil Race <prr at openjdk.org> wrote:

> Can you try again to describe the issue ? The bug summary is misleading I'm sure. "Drawing" as in RENDERING is NOT broken. I think you are trying to say something about expectations for what item(s) are selected .. Perhaps what is missing is a PROPER explanation of what you think reset and submit should do and so forth. And this looks like one of those "tiny" changes which are "completely harmless" but you have said NOTHING about what wider testing you've done on other cases. Fix one case != make things uniformly better ..

@prrace Sorry for my poor description. I've updated that in this PR.
The changed code only affects HTML multi-selection form. I manually tested with some HTML conditions.

-------------

PR: https://git.openjdk.org/jdk/pull/10685


From duke at openjdk.org  Mon Oct 24 06:54:49 2022
From: duke at openjdk.org (SWinxy)
Date: Mon, 24 Oct 2022 06:54:49 GMT
Subject: RFR: 8295323: Unnecessary HashTable usage in StyleSheet
In-Reply-To: <E7ELwS_ym7HRMLnXnO_vlyRLEy7Xdlf2wYyzXSE0qfM=.97fcedee-aa0c-43cf-9cb5-eb3851b9500f@github.com>
References: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
 <iR1IT4_fnOpf0QDXsvToT8uJXkASMb_FFkJbozapAiY=.fcb62fe5-e864-4dc5-845d-638ea5c0fdc2@github.com>
 <E7ELwS_ym7HRMLnXnO_vlyRLEy7Xdlf2wYyzXSE0qfM=.97fcedee-aa0c-43cf-9cb5-eb3851b9500f@github.com>
Message-ID: <qwFDL-FjKao0_nm8EmXAMPnX05qFwW3MzpkmIhn8wUw=.ae83e3f3-5111-4912-bccc-e03a0276875e@github.com>

On Mon, 24 Oct 2022 04:42:18 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 1364:
>> 
>>> 1362:                            HashSet<SelectorMapping> alreadyChecked) {
>>> 1363:         // Avoid descending the same mapping twice.
>>> 1364:         if (!alreadyChecked.add(parentMapping)) {
>> 
>> Clever!
>
> Seriously ? That is your explanation ? Do better.

Hi Phil,
I'm not sure what you mean by this. I'd like to give feedback to client-related PRs when I can, and this line stood out to me as a smart change. I don't want to be critical all the time, so when I see a change I quite like, I want to let the person who wrote it know. Here, I thought the usage of `add(parentMapping)` was clever.

-------------

PR: https://git.openjdk.org/jdk/pull/10522


From kizune at openjdk.org  Mon Oct 24 07:54:17 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 24 Oct 2022 07:54:17 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <0Gi5fB1CY1d8JmqfK4CFAbgUVR2hnZU6HzB6dTXWKcA=.43008757-c999-4916-b9d6-a08d158787ea@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From kizune at openjdk.org  Mon Oct 24 07:54:17 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 24 Oct 2022 07:54:17 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <IuMVFpIBKI-gbjDgXfYvv9ZOansGZiiCJIVeOZeSmps=.dabbaa85-6f11-428d-835e-14e729322f23@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <kM7au4SfOdQxSS_s4CvCLxx0U4rqwpbuLPu0-vqunJg=.6e411ab7-bbdc-4d3c-9611-14fb11fd2aaa@github.com>
 <sSHqPUKao0r0CWHr5pYumXydGoEHIK2zFhbGroy1nq4=.a57a53fe-e3ec-4c40-8afd-a5bb9c9cbaf7@github.com>
 <IuMVFpIBKI-gbjDgXfYvv9ZOansGZiiCJIVeOZeSmps=.dabbaa85-6f11-428d-835e-14e729322f23@github.com>
Message-ID: <5UPlJTdkkTGa39alXzYl1XbkCcEdUhcMxHN56UqfI0Q=.ba6f3139-084d-4c96-ad8c-753ffe046d4c@github.com>

On Sun, 23 Oct 2022 01:22:33 GMT, Phil Race <prr at openjdk.org> wrote:

> Superficially, it looks like the closed test has a direct pointer to where to get this which would need to be re-adjusted

The test has direct link to the include yet i had to add this line so jtreg could find it in the build phase. The fact that it will lead to publishing of this include was not an intentional consequence and it needs to be changed, probably the test should be adjusted later if it will start failing on certain platforms.

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From ihse at openjdk.org  Mon Oct 24 09:56:33 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 09:56:33 GMT
Subject: Integrated: 8294466: Minimize disabled warnings in java.desktop
In-Reply-To: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
References: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
Message-ID: <Y3oi5L299DW3b9SDkBFd7lpq7sPpP0tZ9K16lRePWDU=.17a49df9-2013-414b-b742-3a80a1178528@github.com>

On Thu, 20 Oct 2022 10:36:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.
> 
> (This is a reboot of https://github.com/openjdk/jdk/pull/10453)

This pull request has now been integrated.

Changeset: 74606614
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74606614e0a2e81dadf27e20028055f6305e2ac4
Stats:     100 lines in 2 files changed: 43 ins; 18 del; 39 mod

8294466: Minimize disabled warnings in java.desktop

Reviewed-by: erikj, prr

-------------

PR: https://git.openjdk.org/jdk/pull/10790


From jwaters at openjdk.org  Mon Oct 24 09:59:45 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 24 Oct 2022 09:59:45 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <7Xv3WEWo4oo152yiMpD9bKzhaAKJM3jJLp5HbuE44HE=.da915a24-7441-4bfd-beb0-a2b5fea11f74@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <ugwrZd3SjXfR7U6fVWnGCxcOUjsX_XvoKwqjFgHcBPU=.47f5b4d8-0ce5-4633-8a3a-7db0801d6338@github.com>
 <2G8pjhPykplr0Bx7-g8L6F2VMU6TbR_bBwCSotImpNo=.97454d13-1afe-49c9-8441-63cbf1f96496@github.com>
 <7Xv3WEWo4oo152yiMpD9bKzhaAKJM3jJLp5HbuE44HE=.da915a24-7441-4bfd-beb0-a2b5fea11f74@github.com>
Message-ID: <pB_OwiUeUqvYMEJQjh8yMg0gSSo9t00nJLamm5A9NaQ=.bbaee8b1-fd2a-4fba-a7c7-08e19c8b88bb@github.com>

On Sun, 23 Oct 2022 00:37:55 GMT, Phil Race <prr at openjdk.org> wrote:

> > > Can you please refrain from integrating this while I investigate while this was originally moved?
> > 
> > 
> > sure.
> 
> It was moved because it was designed for use by AWT and SOMEHOW during all the reshuffle for the modular JDK in JDK 9 it ended up in base, which doesn't use it and doesn't want it - it belongs in the desktop module.

I guess that explains why I was so confused when I found this in java.base and thought it was a codebase wide utility, except that I couldn't find it being used anywhere else other than java.desktop :P

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From ihse at openjdk.org  Mon Oct 24 10:05:54 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 10:05:54 GMT
Subject: Integrated: 8295717: Minimize disabled warnings in accessibility
 native code
In-Reply-To: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
References: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
Message-ID: <yd-Fa-c09Yg7Bs4rQaO4D9QEuttASSM4KHKgjJ2z8r8=.f650aa21-4e1b-4144-979d-eb371de62957@github.com>

On Thu, 20 Oct 2022 10:24:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the accessibility native code.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

This pull request has now been integrated.

Changeset: 7a49c9ba
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a49c9baa1d4ad7df90e7ca626ec48ba76881822
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8295717: Minimize disabled warnings in accessibility native code

Reviewed-by: erikj, prr

-------------

PR: https://git.openjdk.org/jdk/pull/10788


From aivanov at openjdk.org  Mon Oct 24 10:17:56 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Oct 2022 10:17:56 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <_lQB8faV1GqMi881H0wr45_2kkYS3j9xQRD3oao2N2k=.4f81ca75-b27c-4c7b-a5fc-c5d378058901@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From duke at openjdk.org  Mon Oct 24 13:20:54 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 24 Oct 2022 13:20:54 GMT
Subject: RFR: 8295779: Xcode 14.0 fails to build jdk on m1 macos
In-Reply-To: <qFM8FAL3ZssjFrYBU8qVzgSBwTe0enKHGgnduFKVsqQ=.1aa3e867-d8d3-48e8-ae45-f6378c746ad2@github.com>
References: <qFM8FAL3ZssjFrYBU8qVzgSBwTe0enKHGgnduFKVsqQ=.1aa3e867-d8d3-48e8-ae45-f6378c746ad2@github.com>
Message-ID: <bMwcJTF26bVULX7GDcqqToKJ8Z9KWqUpZyd2liDj_CE=.e9e76bdc-8985-44cb-96a3-ccb808ca7c16@github.com>

On Wed, 19 Oct 2022 15:33:31 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Building on MacOS 12.6 M1 with Xcode 14.0 fails due to C compiler unused parameter warnings:
> 
> Creating support/modules_libs/java.desktop/libosx.dylib from 1 file(s)

OK thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10768


From duke at openjdk.org  Mon Oct 24 13:20:55 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 24 Oct 2022 13:20:55 GMT
Subject: Withdrawn: 8295779: Xcode 14.0 fails to build jdk on m1 macos
In-Reply-To: <qFM8FAL3ZssjFrYBU8qVzgSBwTe0enKHGgnduFKVsqQ=.1aa3e867-d8d3-48e8-ae45-f6378c746ad2@github.com>
References: <qFM8FAL3ZssjFrYBU8qVzgSBwTe0enKHGgnduFKVsqQ=.1aa3e867-d8d3-48e8-ae45-f6378c746ad2@github.com>
Message-ID: <jPO03paUKZqof-dzyXGaSn46oYUqVCslvec1oaexR2k=.0d7acd54-d09b-478a-a75e-6788a77cb3ff@github.com>

On Wed, 19 Oct 2022 15:33:31 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Building on MacOS 12.6 M1 with Xcode 14.0 fails due to C compiler unused parameter warnings:
> 
> Creating support/modules_libs/java.desktop/libosx.dylib from 1 file(s)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10768


From aivanov at openjdk.org  Mon Oct 24 14:04:53 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Oct 2022 14:04:53 GMT
Subject: RFR: 8295323: Unnecessary HashTable usage in StyleSheet
In-Reply-To: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
References: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
Message-ID: <_Iuyaely_HgP9qlehNvN-MPYM1Bro_NjcWNhJMK4JG8=.85afbebb-1669-43b5-a859-f2e19ad85291@github.com>

On Sat, 1 Oct 2022 16:53:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Hashtable was used only from single thread. And only non-null key/values added to it. We can safely replace it with HashSet.

Looks good to me. All tests pass.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10522


From aivanov at openjdk.org  Mon Oct 24 15:49:55 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Oct 2022 15:49:55 GMT
Subject: RFR: 8295323: Unnecessary HashTable usage in StyleSheet
In-Reply-To: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
References: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
Message-ID: <Rr3nBvYFHbgzmu6rL2prNrTSqgF7fCs4y8GTtasoOl4=.8d807eb5-d057-4366-8adb-5852c03a1703@github.com>

On Sat, 1 Oct 2022 16:53:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Hashtable was used only from single thread. And only non-null key/values added to it. We can safely replace it with HashSet.

src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 1424:

> 1422:         @SuppressWarnings("unchecked")
> 1423:         Vector<SelectorMapping> tempVector = sb.getVector();
> 1424:         HashSet<SelectorMapping> tempHashSet = sb.getHashSet();

Rename variable to `alreadyChecked`?

-------------

PR: https://git.openjdk.org/jdk/pull/10522


From aivanov at openjdk.org  Mon Oct 24 17:33:09 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Oct 2022 17:33:09 GMT
Subject: Integrated: 8295298: Automate
 javax/swing/JFileChooser/FileViewNPETest.java
In-Reply-To: <QllenU8UW_STmxGG98HBbySNFuLEJFSHAn2SbHsnza8=.09c8619b-49da-4fd5-be6d-f24801313caf@github.com>
References: <QllenU8UW_STmxGG98HBbySNFuLEJFSHAn2SbHsnza8=.09c8619b-49da-4fd5-be6d-f24801313caf@github.com>
Message-ID: <44-um5xOSn-Viq2_ZhN4JiZ_XLcGow9hnPX3yS7RSvk=.29da27b6-9631-4552-a687-62e09ef6b94e@github.com>

On Thu, 20 Oct 2022 19:31:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The automated test follows the instructions of the manual test that was added in #10485.
> 
> Instead of selecting the parent folder from the **Look in** combo box, it calls `setCurrentDirectory` directly with the parent of the path which is not traversable. Thus, the current directory of the file chooser is set to `null`.
> 
> As the second step, the test finds the combo box and re-selects the currently selected element. Without the fix for [JDK-6616245](https://bugs.openjdk.org/browse/JDK-6616245), `NullPointerException` is thrown and the test fails; with the fix applied, the original folder is selected and the test passes.
> 
> @mrserb and @TejeshR13, please, take a look.

This pull request has now been integrated.

Changeset: 68cf248b
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68cf248b440a09c4d9bd16c862473f6a97cde279
Stats:     101 lines in 1 file changed: 55 ins; 22 del; 24 mod

8295298: Automate javax/swing/JFileChooser/FileViewNPETest.java

Reviewed-by: tr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/10801


From aivanov at openjdk.org  Mon Oct 24 17:43:16 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Oct 2022 17:43:16 GMT
Subject: Integrated: 8295738: Automate
 javax/swing/JFileChooser/FileSizeCheck.java
In-Reply-To: <VIkeTYidMTjdV9cwai4WC0KLRXsUNHZEP43kXsC21pI=.b78cd68a-d4d3-4ea4-b7e2-16c98d63de30@github.com>
References: <VIkeTYidMTjdV9cwai4WC0KLRXsUNHZEP43kXsC21pI=.b78cd68a-d4d3-4ea4-b7e2-16c98d63de30@github.com>
Message-ID: <utFcEyMqgr-sfsuRdm592YhkpWbjn0jPylBe5RJ7R-Q=.db9c8fb6-ad05-4e25-b75c-392886683114@github.com>

On Thu, 20 Oct 2022 19:50:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This automates the test added in #9327.
> 
> The test has a set of objects which store the size of the file and the expected displayed size, the file name is generated automatically. The pattern for the file names ensures the files are displayed in the expected order up to and including gigabytes, 10 digits. I added more test cases that the original test had to verify the displayed size is rounded up, an automatic test can easily verify more rows than a human can.
> 
> The finds the **Details** button in the file chooser and clicks it, then it finds the table, finds the row where the first file is displayed. The test compares the size displayed in the table to the expected one. If it doesn't match, an error is printed to `stderr`. All the file sizes are verified. The first error message, if any, is thrown to fail the test.
> 
> The test passes with the fix for [JDK-8288882](https://bugs.openjdk.org/browse/JDK-8288882) and fails without it.

This pull request has now been integrated.

Changeset: df81b3c6
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df81b3c66a3b17fc5d10098ce879416affbddd40
Stats:     235 lines in 1 file changed: 175 ins; 32 del; 28 mod

8295738: Automate javax/swing/JFileChooser/FileSizeCheck.java

Reviewed-by: serb

-------------

PR: https://git.openjdk.org/jdk/pull/10802


From ihse at openjdk.org  Mon Oct 24 19:21:07 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:21:07 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v3]
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Revert "Remove check for .properties from jcheck"
   
   This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
 - Change trailing space and tab in values to unicode encoding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10792/files
  - new: https://git.openjdk.org/jdk/pull/10792/files/c91fdaa1..f4f94341

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=01-02

  Stats: 412 lines in 131 files changed: 0 ins; 0 del; 412 mod
  Patch: https://git.openjdk.org/jdk/pull/10792.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792

PR: https://git.openjdk.org/jdk/pull/10792


From angorya at openjdk.org  Mon Oct 24 19:22:38 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:22:38 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

368 files to review!  I wish we had separate PRs for fixing properties and checking for trailing whitespace.  i 'd expect it will take some time to review localization, unless we just keep them as is.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From ihse at openjdk.org  Mon Oct 24 19:25:38 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:25:38 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <yZpwsDUeKIrGQT3tvyGfGHFjIOuQTOBfRyvV7b-uArA=.077497ab-51b8-4346-b67d-9838e3419964@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I agree, that was an excellent idea Naoto! In my last commit, I have converted all trailing spaces/tabs in value lines into explicit unicode characters. Since that means we have no trailing spaces (from a jcheck perspective), I could also restore the jcheck that was the original driver behind this bug. (And also restore the bug/PR title to show the original intent.)

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From ihse at openjdk.org  Mon Oct 24 19:31:26 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:31:26 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v2]
In-Reply-To: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
 <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>
Message-ID: <HmB2uBGv-fQnz3Kn7yEA0yIR4akDfM4tmso3sgA4-aQ=.d84de722-5d04-4aad-8ba3-572eea3cacc1@github.com>

On Mon, 24 Oct 2022 19:20:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove check for .properties from jcheck
>>  - Restore trailing whitespace for property values
>
> 368 files to review!  I wish we had separate PRs for fixing properties and checking for trailing whitespace.  i 'd expect it will take some time to review localization, unless we just keep them as is.

@andy-goryachev-oracle They are all automatically processed. There are two kinds of changes: Non-value lines have their trailing whitespace removed. You can verify that part of the PR by looking here: https://github.com/openjdk/jdk/pull/10792/files/c91fdaa19dc06351598bd1c0614e1af3bfa08ae2

This was the state of the PR as of three days ago. The most numerous number of changed files are here, but you can just scroll through the change and verify quickly that it is trivial.

The second change is the one suggested by Naoti; I have replaced all trailing tabs (there were just one) with `\u0009` and all trailing spaces with `\u0020`. That part was just pushed by me now. You can see that part separately here: https://github.com/openjdk/jdk/pull/10792/commits/a509b90f1b7f833924493fbd28b3cbb1a85c1f21

This affects far fewer files. And once again, it was mechanically generated. You can once again just scroll through and verify that all changes are due to the trailing whitespace being converted to unicode sequences.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From angorya at openjdk.org  Mon Oct 24 19:45:01 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Started looking at whether certain trailing spaces can be (and/or should be) removed, but it quickly became apparent that we should just keep these properties as is (with the unicode escapes), rather than risk regression.

src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187:

> 185: ### Button Demo ###
> 186: 
> 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020

trailing whitespace looks unnecessary (accessible description?)

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Fehler beim Umbenennen von Datei oder Ordner
> 66: FileChooser.renameError.textAndMnemonic={0} kann nicht umbenannt werden
> 67: FileChooser.renameErrorFileExists.textAndMnemonic={0} kann nicht umbenannt werden: Es ist bereits eine Datei mit dem angegebenen Namen vorhanden. Geben Sie einen anderen Dateinamen an.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Error al cambiar el nombre del archivo o carpeta
> 66: FileChooser.renameError.textAndMnemonic=No se puede cambiar el nombre de {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=No se puede cambiar el nombre de {0}: ya existe un archivo con el nombre especificado. Especifique otro nombre de archivo.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Erreur lors du changement de nom du fichier ou du dossier
> 66: FileChooser.renameError.textAndMnemonic=Impossible de renommer {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossible de renommer {0} : il existe d\u00E9j\u00E0 un fichier portant le nom indiqu\u00E9. Indiquez-en un autre.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Errore durante la ridenominazione del file o della cartella
> 66: FileChooser.renameError.textAndMnemonic=Impossibile rinominare {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossibile rinominare {0}: esiste gi\u00E0 un file con il nome specificato. Specificare un altro nome.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=\u30D5\u30A1\u30A4\u30EB\u307E\u305F\u306F\u30D5\u30A9\u30EB\u30C0\u306E\u540D\u524D\u5909\u66F4\u30A8\u30E9\u30FC
> 66: FileChooser.renameError.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093
> 67: FileChooser.renameErrorFileExists.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093: \u6307\u5B9A\u3057\u305F\u540D\u524D\u306E\u30D5\u30A1\u30A4\u30EB\u306F\u3059\u3067\u306B\u5B58\u5728\u3057\u307E\u3059\u3002\u5225\u306E\u30D5\u30A1\u30A4\u30EB\u540D\u3092\u6307\u5B9A\u3057\u3066\u304F\u3060\u3055\u3044\u3002\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Ett fel intr\u00E4ffade vid f\u00F6rs\u00F6k att \u00E4ndra namn p\u00E5 fil eller mapp
> 66: FileChooser.renameError.textAndMnemonic=Kan inte namn\u00E4ndra {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Kan inte namn\u00E4ndra {0}: En fil med angivet namn finns redan. Ange ett annat filnamn.\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 44:

> 42: cachedrowsetimpl.floatfail = getFloat failed on value ( {0} ) in column {1}
> 43: cachedrowsetimpl.doublefail = getDouble failed on value ( {0} ) in column {1}
> 44: cachedrowsetimpl.dtypemismt = Data Type Mismatch\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 73:

> 71: cachedrowsetimpl.numrows = Number of rows is less than zero or less than fetch size
> 72: cachedrowsetimpl.startpos = Start position cannot be negative
> 73: cachedrowsetimpl.nextpage = Populate data before calling\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 87:

> 85: 
> 86: #FilteredRowSetImpl exceptions
> 87: filteredrowsetimpl.relative = relative : Invalid cursor operation\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 128:

> 126: crswriter.params1 = Value of params1 : {0}\u0020
> 127: crswriter.params2 = Value of params2 : {0}\u0020
> 128: crswriter.conflictsno =  conflicts while synchronizing\u0020

this is tricky.  if this value is a part of a sentence (i.e. something like "5 conflicts..."), the localization is likely to be wrong.  it's hard to tell without looking further into the code.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134:

> 132: 
> 133: #SyncResolverImpl exceptions
> 134: syncrsimpl.indexval = Index value out of range\u0020\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 44:

> 42: cachedrowsetimpl.floatfail = getFloat bei Wert ( {0} ) in Spalte {1} nicht erfolgreich
> 43: cachedrowsetimpl.doublefail = getDouble bei Wert ( {0} ) in Spalte {1} nicht erfolgreich
> 44: cachedrowsetimpl.dtypemismt = Keine Datentyp\u00FCbereinstimmung\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 73:

> 71: cachedrowsetimpl.numrows = Zeilenanzahl ist kleiner als null oder kleiner als Abrufgr\u00F6\u00DFe
> 72: cachedrowsetimpl.startpos = Startposition darf keinen Negativwert aufweisen
> 73: cachedrowsetimpl.nextpage = Daten m\u00FCssen vor dem Aufruf ausgef\u00FCllt werden\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 87:

> 85: 
> 86: #FilteredRowSetImpl exceptions
> 87: filteredrowsetimpl.relative = relative: Ung\u00FCltiger Cursorvorgang\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 134:

> 132: 
> 133: #SyncResolverImpl exceptions
> 134: syncrsimpl.indexval = Indexwert liegt au\u00DFerhalb des Bereichs\u0020\u0020

prob. unnecessary

-------------

Marked as reviewed by angorya (no project role).

PR: https://git.openjdk.org/jdk/pull/10792


From ihse at openjdk.org  Mon Oct 24 19:45:01 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed. I did not think it was a good idea to hold this PR, waiting for component teams to do the whitespace check first, for two reasons:

1) Now the trailing whitespace will be obvious, and any intended whitespace will not be accidentally stripped by an editor, so it will be easier for engineers to fix any problems.

2) I know from experience that this kind of cleaning-up has a very low priority for many engineers. If this PR were dependent on all JDK groups going through their properties files, it would basically never be closed.

And finally: Here is a complete list of the files which has trailing "unicode whitespace" in values. I will try to figure out to which components these belongs and open corresponding bugs.


src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties
src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_TW.properties
src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties
src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties
src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_TW.properties
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_ja.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_zh_CN.properties
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties
src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties
src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_de.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_ja.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_zh_CN.properties
src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties
src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_de.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_es.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_fr.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_it.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ja.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_pt_BR.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_sv.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_CN.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_TW.properties
test/jdk/javax/net/ssl/Stapling/TEST.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/FileChooserDemo.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/TableDemo.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/togglebutton/resources/ToggleButtonDemo.properties
test/jdk/tools/jmod/src/foo/jdk/test/foo/resources/foo.properties

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From jjg at openjdk.org  Mon Oct 24 19:45:01 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order.

Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From angorya at openjdk.org  Mon Oct 24 19:45:01 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>
Message-ID: <cuJYgquzi3I4fULUZZz_G_ZjmEd_wDsUPw2mzCceM_w=.ad366bc4-db7f-48ad-9d3f-a8d0ba9e1820@github.com>

On Mon, 24 Oct 2022 19:34:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed.

probably not needed - if nobody noticed anything until now we have no problem.  the solution to escape whitespace in values is the right solution, solves both the jcheck and WS visibility issues.

good job!

(and we can ignore my "prob. unnecessary" comments)

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From angorya at openjdk.org  Mon Oct 24 19:45:02 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:02 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
Message-ID: <cRpIep8vLpUKvRQH3e_vwTIqVChg5uSLhFH4sSCbmOQ=.9c8e6492-c665-4666-bba9-4947cd6059b1@github.com>

On Mon, 24 Oct 2022 19:23:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "Remove check for .properties from jcheck"
>>    
>>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>>  - Change trailing space and tab in values to unicode encoding
>
> src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187:
> 
>> 185: ### Button Demo ###
>> 186: 
>> 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020
> 
> trailing whitespace looks unnecessary (accessible description?)

although this is in demo...

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From naoto at openjdk.org  Mon Oct 24 20:02:54 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 20:02:54 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

The problem here is that all those (unnecessary) trailing spaces are appended by the external translators, who are not aware those spaces should not be at the end. I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From ihse at openjdk.org  Mon Oct 24 20:10:37 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:10:37 GMT
Subject: RFR: 8295847: slow debug build error after JDK-8294466
Message-ID: <VULVvQOFDUv8pyKsFSyKAt6oREnekM8nYok3cDFvM8s=.d1efbd0d-81ad-421b-beb2-fe6519ef1944@github.com>

[JDK-8294466](https://bugs.openjdk.org/browse/JDK-8294466) trimmed down the set of disabled warnings. Unfortunately it turned out that running slowdebug on linux on Oracle's CI triggered yet another warning in libsplashscreen.

-------------

Commit messages:
 - 8295847: slow debug build error after JDK-8294466

Changes: https://git.openjdk.org/jdk/pull/10840/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10840&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295847
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10840.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10840/head:pull/10840

PR: https://git.openjdk.org/jdk/pull/10840


From angorya at openjdk.org  Mon Oct 24 20:12:02 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 20:12:02 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
Message-ID: <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>

On Mon, 24 Oct 2022 19:58:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles.

Good idea! I wonder if this should be done as a unit test.  go through all the bundles and check leading/trailing whitespace.

in my experience, the translators also (unintentionally) change the quotes and other symbols, sometimes breaking the code.  I assume the JDK has been exhaustively tested and we have no such problems.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From serb at openjdk.org  Mon Oct 24 20:13:56 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 24 Oct 2022 20:13:56 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <ycafUWpULayyM3u5G4rWqfUNbqlVJlHErqaL174ZsZE=.6e8de870-8781-480e-acb1-fb2eb4c9b62d@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

I suggest to disable that test, if it builds during the jdk build as part of test bundle it may cause the whole jdk build to fail in mach5.

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From naoto at openjdk.org  Mon Oct 24 20:16:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 20:16:56 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
 <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>
Message-ID: <go6bwGp8ro_LeVwOJyBes4PXwMBEGNyPvq43vxGmmLU=.ed6bfa15-4664-41ab-87a9-51609382b9cf@github.com>

On Mon, 24 Oct 2022 20:08:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Good idea! I wonder if this should be done as a unit test. go through all the bundles and check leading/trailing whitespace.

Right. Definitely not a job for `jcheck`, but it should be considered somewhere in the l10n process.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From erikj at openjdk.org  Mon Oct 24 20:20:58 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 24 Oct 2022 20:20:58 GMT
Subject: RFR: 8295847: slow debug build error after JDK-8294466
In-Reply-To: <VULVvQOFDUv8pyKsFSyKAt6oREnekM8nYok3cDFvM8s=.d1efbd0d-81ad-421b-beb2-fe6519ef1944@github.com>
References: <VULVvQOFDUv8pyKsFSyKAt6oREnekM8nYok3cDFvM8s=.d1efbd0d-81ad-421b-beb2-fe6519ef1944@github.com>
Message-ID: <OahuneiEPxvykhKOspYH6VTgNvvQa9armHvAOl34Ajk=.541a6a0f-b488-4360-b3bf-c0db456ce397@github.com>

On Mon, 24 Oct 2022 20:01:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8294466](https://bugs.openjdk.org/browse/JDK-8294466) trimmed down the set of disabled warnings. Unfortunately it turned out that running slowdebug on linux on Oracle's CI triggered yet another warning in libsplashscreen.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10840


From dcubed at openjdk.org  Mon Oct 24 20:20:58 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 24 Oct 2022 20:20:58 GMT
Subject: RFR: 8295847: slow debug build error after JDK-8294466
In-Reply-To: <VULVvQOFDUv8pyKsFSyKAt6oREnekM8nYok3cDFvM8s=.d1efbd0d-81ad-421b-beb2-fe6519ef1944@github.com>
References: <VULVvQOFDUv8pyKsFSyKAt6oREnekM8nYok3cDFvM8s=.d1efbd0d-81ad-421b-beb2-fe6519ef1944@github.com>
Message-ID: <fqR_eIlJQpQHtmRTQqUNrRxak0WejFYbE7TvlsXrfUs=.de887f6f-986f-437e-a367-569ada77fd12@github.com>

On Mon, 24 Oct 2022 20:01:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8294466](https://bugs.openjdk.org/browse/JDK-8294466) trimmed down the set of disabled warnings. Unfortunately it turned out that running slowdebug on linux on Oracle's CI triggered yet another warning in libsplashscreen.

Thumbs up. This is a trivial fix.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10840


From ihse at openjdk.org  Mon Oct 24 20:36:28 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:36:28 GMT
Subject: Integrated: 8295847: slow debug build error after JDK-8294466
In-Reply-To: <VULVvQOFDUv8pyKsFSyKAt6oREnekM8nYok3cDFvM8s=.d1efbd0d-81ad-421b-beb2-fe6519ef1944@github.com>
References: <VULVvQOFDUv8pyKsFSyKAt6oREnekM8nYok3cDFvM8s=.d1efbd0d-81ad-421b-beb2-fe6519ef1944@github.com>
Message-ID: <pFJrBbU11AVF22fQCKF68NHFYZ9sh5JDiZladv4sD_w=.56f3d4ea-c5d5-4907-8d52-443770e01090@github.com>

On Mon, 24 Oct 2022 20:01:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8294466](https://bugs.openjdk.org/browse/JDK-8294466) trimmed down the set of disabled warnings. Unfortunately it turned out that running slowdebug on linux on Oracle's CI triggered yet another warning in libsplashscreen.

This pull request has now been integrated.

Changeset: 8c86e925
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c86e92535afa52c4d454a3b8cc59ee5f8bb6477
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8295847: slow debug build error after JDK-8294466

Reviewed-by: erikj, dcubed

-------------

PR: https://git.openjdk.org/jdk/pull/10840


From ihse at openjdk.org  Mon Oct 24 20:39:57 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:39:57 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>
Message-ID: <HMdFi0RZ9_Jhobfq_DLpJY4wycMf6qXcIHo90U8sq80=.4a035bff-b633-400b-bbf4-c3e7111385f3@github.com>

On Mon, 24 Oct 2022 19:39:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order.

I respectfully disagree. I think changing a trailing " " into a "\u0020" is the opposite of hiding it; it is making it plainly visible. In fact, I believe most of these trailing spaces are the result of them not being visible enough (and the tooling not warning).

Secondly, there are a lot of definitely unintentional trailing spaces, in comments and blank lines. I'd say there is factor 10:1 more of these. Getting these out of the way allows developers to focus more clearly on the trailing whitespace that matters: those in the key-value pairs.

And as I said, I intend to file follow-up issues for all files where there is a trailing unicode-sequence whitespace, so it will definitely not be lost on the respective component teams that they have something they need to address.

> Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version.

That's probably a good idea, but I think we should leave that to each respective team. Just like Andy's and Naoto's suggestion of improving i18n tooling to detect issues like this earlier on. Good idea, but I'd like to see that implemented separated from this PR. This PR is already large. The only reason it makes sense is because all changes (except the one to jcheck) are automatically generated and trivial to verify correctness of. If we were to start adding individual, manual changes into this PR, it would be just a huge mess.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From prr at openjdk.org  Mon Oct 24 20:43:56 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 20:43:56 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <_lQB8faV1GqMi881H0wr45_2kkYS3j9xQRD3oao2N2k=.4f81ca75-b27c-4c7b-a5fc-c5d378058901@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <_lQB8faV1GqMi881H0wr45_2kkYS3j9xQRD3oao2N2k=.4f81ca75-b27c-4c7b-a5fc-c5d378058901@github.com>
Message-ID: <uJ8FpaN9cfXAspUsvs1ljSXIm6XgBJHOpp3X1NnQE6Q=.82c3cb2e-7d59-4a24-bee7-9628ade26674@github.com>

On Mon, 24 Oct 2022 10:15:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".
>
> Marked as reviewed by aivanov (Reviewer).

@aivanov-jdk has prepared a patch which will be pushed to fix this up but I agree the timing needs to be perfect to be safe here ..  if you can't co-ordinate a time with him then he would need to disable it now and re-enable it later.

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From prr at openjdk.org  Mon Oct 24 20:52:52 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 20:52:52 GMT
Subject: RFR: 8295323: Unnecessary HashTable usage in StyleSheet
In-Reply-To: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
References: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
Message-ID: <6geCFH1wy3tj2sIatGq9JoqGaacpOEafvGRLWuOc6EA=.8e6fba31-f0a9-474c-91f5-886d8b51bae1@github.com>

On Sat, 1 Oct 2022 16:53:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Hashtable was used only from single thread. And only non-null key/values added to it. We can safely replace it with HashSet.

So I think this is OK, but please be sure you have run at least the related Swing jtreg tests

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10522


From ihse at openjdk.org  Mon Oct 24 20:53:54 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:53:54 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <9qWFsNtQRgE6Darx7iMV5vWtKPwVf5TV3455NEau7sQ=.2deebcb6-ed17-4c18-86bc-800e0a347a69@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

Thank you for waiting while we sorted out the details. This looks good to push. However, as prrace says, we have a corresponding closed part that needs to go in at the same time. One way to solve this is that you give the `/integrate defer` PR command. Then any jdk committer can *actually* integrate the PR later, and make sure it is coordinated with our closed counterpart.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10757


From cjplummer at openjdk.org  Tue Oct 25 03:16:49 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Oct 2022 03:16:49 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <qb_ryMLGem495x0rBbOxd4vVGYPmnRiOkynx6AmvZVE=.5c5d3ee8-8498-4d6d-bfec-04a075ab085c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Changes requested by cjplummer (Reviewer).

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties line 27:

> 25: 
> 26: agent.err.error			   = Error
> 27: agent.err.exception                = Exception thrown by the agent\u0020

I believe this space was just a typo and should be removed. Same for `agent.err.agentclass.failed` below and in all the other management property files.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From dnguyen at openjdk.org  Tue Oct 25 05:07:33 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 25 Oct 2022 05:07:33 GMT
Subject: RFR: 8295248: JEditorPane HTML form with multi-selection broke
 data after resetting [v3]
In-Reply-To: <ONuUz9De4hGoEk8j-OYAXn8G_4Hl3QMScNEIcSf5aQE=.9b6b0c16-9d96-4899-805d-a90f6aed2722@github.com>
References: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
 <XJ54TYURwthQqWedWpAuAGeRuDqq043NdAQRcucAWpc=.6160f318-c362-4788-909e-7f9932ee99fb@github.com>
 <ONuUz9De4hGoEk8j-OYAXn8G_4Hl3QMScNEIcSf5aQE=.9b6b0c16-9d96-4899-805d-a90f6aed2722@github.com>
Message-ID: <i3zV8XQjOzg_XskSe21gPLr8g6ePBRzjrNrF7FDTQcE=.d3e131ee-67ad-4da3-8b91-088f439c1a38@github.com>

On Mon, 24 Oct 2022 04:27:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed space
>
> Can you try again to describe the issue ? 
> The bug summary is misleading I'm sure. "Drawing" as in RENDERING is NOT broken.
> I think you are trying to say something about expectations for what item(s) are selected .. 
> Perhaps what is missing is a PROPER explanation of what you think reset and submit should do and so forth.
> And this looks like one of those "tiny" changes which are "completely harmless" but you have said NOTHING about what wider testing you've done on other cases. Fix one case != make things uniformly better ..

@prrace has a good point here. I had to review the JBS and changes to really understand the issue. I guess the point is, why does model's removeIndexInterval not do what it should do here? 

Visually clearSelection fixes the issue, but removeIndexInterval explicitly updates the states of the indexes in the method's body. clearSelection instead calls removeSelectionInterval which might do the same in a roundabout way.

I ran some tests on my end, and I still believe this fix is probably OK. It's just maybe better to explain more in depth why clearSelection is a suitable replacement for the removeIndexInterval block.

-------------

PR: https://git.openjdk.org/jdk/pull/10685


From aturbanov at openjdk.org  Tue Oct 25 07:08:02 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 25 Oct 2022 07:08:02 GMT
Subject: RFR: 8295323: Unnecessary HashTable usage in StyleSheet [v2]
In-Reply-To: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
References: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
Message-ID: <QPqHLGWMONVV6rwy-hL04rCeg_7Y8aTjy8mLl2D0oiE=.08ff54b7-babb-419c-873a-85dba7fb835d@github.com>

> Hashtable was used only from single thread. And only non-null key/values added to it. We can safely replace it with HashSet.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8295323: Unnecessary HashTable usage in StyleSheet
  
  rename tempHashSet to alreadyChecked

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10522/files
  - new: https://git.openjdk.org/jdk/pull/10522/files/ee8cbfd5..f89a85c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10522&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10522&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10522.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10522/head:pull/10522

PR: https://git.openjdk.org/jdk/pull/10522


From aturbanov at openjdk.org  Tue Oct 25 07:08:02 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 25 Oct 2022 07:08:02 GMT
Subject: RFR: 8295323: Unnecessary HashTable usage in StyleSheet [v2]
In-Reply-To: <6geCFH1wy3tj2sIatGq9JoqGaacpOEafvGRLWuOc6EA=.8e6fba31-f0a9-474c-91f5-886d8b51bae1@github.com>
References: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
 <6geCFH1wy3tj2sIatGq9JoqGaacpOEafvGRLWuOc6EA=.8e6fba31-f0a9-474c-91f5-886d8b51bae1@github.com>
Message-ID: <ZpLGMPVnYc_85J_xHz1hMt_sCb7942n5sbvC10TLrYc=.20962ce4-ac16-4e01-9c7b-eca00070a75a@github.com>

On Mon, 24 Oct 2022 20:50:22 GMT, Phil Race <prr at openjdk.org> wrote:

>So I think this is OK, but please be sure you have run at least the related Swing jtreg tests

Run tests from `test/jdk/javax/swing/text`. All green.

-------------

PR: https://git.openjdk.org/jdk/pull/10522


From aturbanov at openjdk.org  Tue Oct 25 07:08:03 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 25 Oct 2022 07:08:03 GMT
Subject: RFR: 8295323: Unnecessary HashTable usage in StyleSheet [v2]
In-Reply-To: <Rr3nBvYFHbgzmu6rL2prNrTSqgF7fCs4y8GTtasoOl4=.8d807eb5-d057-4366-8adb-5852c03a1703@github.com>
References: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
 <Rr3nBvYFHbgzmu6rL2prNrTSqgF7fCs4y8GTtasoOl4=.8d807eb5-d057-4366-8adb-5852c03a1703@github.com>
Message-ID: <LUD5NpIbZf5gr8GXusPYTxQyeFICtJV0nkrqg9H51k0=.85ec3269-a360-482c-bf70-cd0eec6b63a1@github.com>

On Mon, 24 Oct 2022 15:47:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8295323: Unnecessary HashTable usage in StyleSheet
>>   
>>   rename tempHashSet to alreadyChecked
>
> src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 1424:
> 
>> 1422:         @SuppressWarnings("unchecked")
>> 1423:         Vector<SelectorMapping> tempVector = sb.getVector();
>> 1424:         HashSet<SelectorMapping> tempHashSet = sb.getHashSet();
> 
> Rename variable to `alreadyChecked`?

renamed

-------------

PR: https://git.openjdk.org/jdk/pull/10522


From tnakamura at openjdk.org  Tue Oct 25 07:30:36 2022
From: tnakamura at openjdk.org (Toshio Nakamura)
Date: Tue, 25 Oct 2022 07:30:36 GMT
Subject: RFR: 8295248: JEditorPane HTML form with multi-selection broke
 data after resetting [v3]
In-Reply-To: <ONuUz9De4hGoEk8j-OYAXn8G_4Hl3QMScNEIcSf5aQE=.9b6b0c16-9d96-4899-805d-a90f6aed2722@github.com>
References: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
 <XJ54TYURwthQqWedWpAuAGeRuDqq043NdAQRcucAWpc=.6160f318-c362-4788-909e-7f9932ee99fb@github.com>
 <ONuUz9De4hGoEk8j-OYAXn8G_4Hl3QMScNEIcSf5aQE=.9b6b0c16-9d96-4899-805d-a90f6aed2722@github.com>
Message-ID: <4fubBjxIwjogZD6hznT7QffvW750PoAD2lOW5zDc7Yk=.6d63c22e-3fe3-4baa-86ff-1ab342689ca7@github.com>

On Mon, 24 Oct 2022 04:27:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed space
>
> Can you try again to describe the issue ? 
> The bug summary is misleading I'm sure. "Drawing" as in RENDERING is NOT broken.
> I think you are trying to say something about expectations for what item(s) are selected .. 
> Perhaps what is missing is a PROPER explanation of what you think reset and submit should do and so forth.
> And this looks like one of those "tiny" changes which are "completely harmless" but you have said NOTHING about what wider testing you've done on other cases. Fix one case != make things uniformly better ..

> @prrace has a good point here. I had to review the JBS and changes to really understand the issue. I guess the point is, why does model's removeIndexInterval not do what it should do here?
> 
> Visually clearSelection fixes the issue, but removeIndexInterval explicitly updates the states of the indexes in the method's body. clearSelection instead calls removeSelectionInterval which might do the same in a roundabout way.
> 
> I ran some tests on my end, and I still believe this fix is probably OK. It's just maybe better to explain more in depth why clearSelection is a suitable replacement for the removeIndexInterval block.

@DamonGuy 
Sorry I misunderstood at first.
OptionListModel.removeIndexInterval() and removeSelectionInterval() are completely different.
removeIndexInterval(i, i) *deletes* the indexed item, not unset.
removeSelectionInterval(i, i) *unsets* the indexed item.

To change to removeSelectionInterval() is also ok, but clearSelection() calls remoteSelectionInterval() more effectively. So, clearSelection() is suitable, I think.

-------------

PR: https://git.openjdk.org/jdk/pull/10685


From serb at openjdk.org  Tue Oct 25 09:49:57 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 25 Oct 2022 09:49:57 GMT
Subject: Integrated: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <GJxA0j9dhKofslUGNSXAwm9FkBFlCzwegbw0vU5vNco=.cc88f358-72c4-4070-a8d9-ed0243b2f7a9@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

This pull request has now been integrated.

Changeset: 6673cd85
Author:    Sergey Bylokhov <serb at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6673cd857722d117b108590ba7f7c02f8622fc3b
Stats:     7 lines in 3 files changed: 3 ins; 3 del; 1 mod

8295554: Move the "sizecalc.h" to the correct location

Reviewed-by: erikj, ihse, prr, kizune, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From shade at openjdk.org  Tue Oct 25 10:49:32 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Oct 2022 10:49:32 GMT
Subject: RFR: 8295868: 32-bit Windows build failures after JDK-8294466
Message-ID: <RfMXMt16m2IYqJjUkKvciC8oTPFLRoTiZaDQOBnGxNY=.fcab2e1c-b813-4480-80a1-1201c088f06b@github.com>

Fails like this:


* For target support_native_java.desktop_libsplashscreen_splashscreen_impl.obj:
splashscreen_impl.c
c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): error C2220: the following warning is treated as an error
c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): warning C4018: '>': signed/unsigned mismatch
c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(444): warning C4018: '>': signed/unsigned mismatch
c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(466): warning C4018: '>': signed/unsigned mismatch
c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(467): warning C4018: '>': signed/unsigned mismatch
``` 

I just added the disabled warning for that file. 

Additional testing:
 - [x] Windows x86_32 release (now builds)
 - [ ] Windows x86_32 fastdebug (now builds)
 - [ ] Windows x86_32 slowdebug (now builds)

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/10848/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10848&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295868
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10848.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10848/head:pull/10848

PR: https://git.openjdk.org/jdk/pull/10848


From erikj at openjdk.org  Tue Oct 25 12:48:53 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Oct 2022 12:48:53 GMT
Subject: RFR: 8295868: 32-bit Windows build failures after JDK-8294466
In-Reply-To: <RfMXMt16m2IYqJjUkKvciC8oTPFLRoTiZaDQOBnGxNY=.fcab2e1c-b813-4480-80a1-1201c088f06b@github.com>
References: <RfMXMt16m2IYqJjUkKvciC8oTPFLRoTiZaDQOBnGxNY=.fcab2e1c-b813-4480-80a1-1201c088f06b@github.com>
Message-ID: <aHolgcC9noS7_3404mYCdRXRwM5pJRhssghlCLb1m3E=.bdaeb45c-4b87-4917-9701-46bd3e6be990@github.com>

On Tue, 25 Oct 2022 10:40:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> * For target support_native_java.desktop_libsplashscreen_splashscreen_impl.obj:
> splashscreen_impl.c
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): error C2220: the following warning is treated as an error
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(444): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(466): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(467): warning C4018: '>': signed/unsigned mismatch
> ``` 
> 
> I just added the disabled warning for that file. 
> 
> Additional testing:
>  - [x] Windows x86_32 release (now builds)
>  - [x] Windows x86_32 fastdebug (now builds)
>  - [x] Windows x86_32 slowdebug (now builds)

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10848


From weijun at openjdk.org  Tue Oct 25 13:30:53 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 13:30:53 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <c28cQxkcVp8YCkAe0wDP4b7cUvb424JsH9ls5bR3m48=.31cad672-bef6-4d55-983d-2cb32a0cafea@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

test/jdk/javax/net/ssl/Stapling/TEST.properties line 5:

> 3:     java.base/sun.security.util \
> 4:     java.base/sun.security.validator \
> 5:     java.base/sun.security.x509\u0020

I'm quite sure this space can be safely removed.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From weijun at openjdk.org  Tue Oct 25 13:47:02 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 13:47:02 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I noticed another problem. In some English properties files (Ex: `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`), `\u0020` is already used today but it turns into a whitespace in the translated files. It looks like the translation tool (most likely written in Java) decoded it while reading the English file but was not able to encode it back in a translation. I wonder if this means even if we get everything right now the tool might add trailing spaces again later.

I suggest we focus on the English files this time and file a bug to the translation tool.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From aivanov at openjdk.org  Tue Oct 25 15:40:57 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 25 Oct 2022 15:40:57 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <9qWFsNtQRgE6Darx7iMV5vWtKPwVf5TV3455NEau7sQ=.2deebcb6-ed17-4c18-86bc-800e0a347a69@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <9qWFsNtQRgE6Darx7iMV5vWtKPwVf5TV3455NEau7sQ=.2deebcb6-ed17-4c18-86bc-800e0a347a69@github.com>
Message-ID: <YBum-IgeUsA5lZIbOG0vnTos_MeBC92k-0ilLKEwOGM=.a6479662-fde6-4896-ac7f-e8c9a808cfaf@github.com>

On Mon, 24 Oct 2022 20:50:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".
>
> Thank you for waiting while we sorted out the details. This looks good to push. However, as prrace says, we have a corresponding closed part that needs to go in at the same time. One way to solve this is that you give the `/integrate defer` PR command. Then any jdk committer can *actually* integrate the PR later, and make sure it is coordinated with our closed counterpart.

Thanks, @magicus, for the suggestion of using `/integrate defer`, it worked like a charm. Both changes went into the same build.

Thanks, @mrserb, for catching and resolving the issue and for cooperating.

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From naoto at openjdk.org  Tue Oct 25 17:31:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Oct 2022 17:31:52 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>
Message-ID: <CWhtHdVfwiBt9m16ZvVgfFbu-h9bRwVLYmwORiLTSVA=.210b4cf3-7f67-4f32-9983-b9fe54bd1571@github.com>

On Tue, 25 Oct 2022 13:43:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I wonder if this means even if we get everything right now the tool might add trailing spaces again later.

Good catch, Max. Yes, that should be dealt with in the translation process.

> I suggest we focus on the English files this time and file a bug to the translation tool.

Agree.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From duke at openjdk.org  Tue Oct 25 19:09:30 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Tue, 25 Oct 2022 19:09:30 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v14]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <dzW-iKpag5KyyaSSIxmx1qzeQMfB2C4zyeonFLMN2S4=.0e7bb31c-79f0-4e37-86c1-c595c58ee562@github.com>

> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
> It includes:
> - Bitmap glyph loading via Freetype
> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
> - Small fixes in related code like null-checks which could cause NPE & comment typos

Nikita Gubarkov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into JDK-8269806
 - Fix italic and bold styles for colored outline glyphs
 - Fix rotated text metrics
 - Disable colored outlines on Linux to be able to build with old system Freetype
 - Merge master
 - Optimize bitmap creation in GlyphRenderData
   
   Get rid of unneeded abstract methods
   
   Use SSIM for OutlineTextRendererEmoji test
 - Fix pointer to long conversion
 - Fix other CRLF
 - Fix GlyphRenderData CRLF
 - 8269806: Fix emoji, ZWJ, variation selectors and font fallback
   
   Also implement unacached rendering of colored outlines and bitmap glyphs
 - ... and 7 more: https://git.openjdk.org/jdk/compare/0caea818...ed774234

-------------

Changes: https://git.openjdk.org/jdk/pull/4798/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=13
  Stats: 2522 lines in 54 files changed: 2084 ins; 140 del; 298 mod
  Patch: https://git.openjdk.org/jdk/pull/4798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/4798/head:pull/4798

PR: https://git.openjdk.org/jdk/pull/4798


From dnguyen at openjdk.org  Tue Oct 25 21:29:47 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 25 Oct 2022 21:29:47 GMT
Subject: RFR: 8295248: JEditorPane HTML form with multi-selection broke
 data after resetting [v3]
In-Reply-To: <XJ54TYURwthQqWedWpAuAGeRuDqq043NdAQRcucAWpc=.6160f318-c362-4788-909e-7f9932ee99fb@github.com>
References: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
 <XJ54TYURwthQqWedWpAuAGeRuDqq043NdAQRcucAWpc=.6160f318-c362-4788-909e-7f9932ee99fb@github.com>
Message-ID: <Ony35IbSWnOi4DnCZu5UeyorxQx13_nv1ke1NfiHXHM=.c2406b58-a1d7-4aae-bf41-f233859f4abd@github.com>

On Mon, 24 Oct 2022 02:06:23 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> When JEditorPane shown HTML form with multi-selection, the reset operation broke its data.
>> 
>> The sample testcase were attached in JBS. The recreate steps are below:
>> 1. The sample shows a multi-selection form with 5 items.
>> 2. Select the 4th item.
>> 3. Press the reset button.
>> Actual: The 4th item is still selected.
>> Expect: No item should be selected. Resetting operation may move to the initial state. The sample doesn't use 'selected' property in each option tag.
>> 4. Just after the step 3, move the focus to outside of the application and back.
>> Actual: The 2nd item is selected. It means inside data indicates so.
>> Expect: No item is selected.
>> 
>> There are two issues. The current method `OptionListModel.removeIndexInterval()` disabled selections, but it didn't fire the change. Then, no re-drawing. Another issue is the method works as remove and shift. Then, selection values were corrupted.
>> I think the clear method `OptionListModel.clearSelection()` is suitable here.
>> 
>> Test: jdk_desktop on macOS (x64, Monterey), Linux (x64, RHEL8), and Windows (x64, 2012R2).
>>       No regression found
>
> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed space

Marked as reviewed by dnguyen (Author).

-------------

PR: https://git.openjdk.org/jdk/pull/10685


From psadhukhan at openjdk.org  Wed Oct 26 04:05:54 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 26 Oct 2022 04:05:54 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v8]
In-Reply-To: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
Message-ID: <jA6hVbeFGjA36-4LOcEiczAl4ebQlrfBXlDv4AcgYHI=.c919764a-8012-4033-aecf-228cb88ae750@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.

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/10409/files
  - new: https://git.openjdk.org/jdk/pull/10409/files/ee02dc45..89b9e86c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10409&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10409&range=06-07

  Stats: 15 lines in 1 file changed: 2 ins; 7 del; 6 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 psadhukhan at openjdk.org  Wed Oct 26 04:24:40 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 26 Oct 2022 04:24:40 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors
In-Reply-To: <xJRbKyTl3LEZwOja3hVl8_efF6-LPpfRrLR6YLK9qlU=.025791ed-212b-4e72-949c-48d98b853022@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
 <xJRbKyTl3LEZwOja3hVl8_efF6-LPpfRrLR6YLK9qlU=.025791ed-212b-4e72-949c-48d98b853022@github.com>
Message-ID: <nhAEJFxyu097JrZcQXLcUbdvVXivaTsby5ntCPpHrY8=.d6996e9c-8eb6-48b5-983d-189911f8d997@github.com>

On Thu, 20 Oct 2022 23:47:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> It seems the same issue exists in other methods, like getBorderInsets?

OK. javadoc updated for that method too

-------------

PR: https://git.openjdk.org/jdk/pull/10740


From psadhukhan at openjdk.org  Wed Oct 26 04:24:39 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 26 Oct 2022 04:24:39 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors [v2]
In-Reply-To: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
Message-ID: <6NKWCWUFCq7wkJrSe5Eq4lt-Og4YXi9Cmtio-OzPgVk=.3fd345f3-4d8a-49f3-a08b-231e12158994@github.com>

> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec.

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/10740/files
  - new: https://git.openjdk.org/jdk/pull/10740/files/6b82bab3..dd44d401

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10740&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10740&range=00-01

  Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10740.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10740/head:pull/10740

PR: https://git.openjdk.org/jdk/pull/10740


From duke at openjdk.org  Wed Oct 26 05:18:58 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 26 Oct 2022 05:18:58 GMT
Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel
Message-ID: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>

While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF.

The condition check has been modified when multiselection is enabled and user has selected single directory.
After the fix the behavior of JFileChooser is similar to other LAFs.

An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented and checked in CI pipeline. Link is attached in JBS.

-------------

Commit messages:
 - Whitespace error fix
 - Single directory selection fix

Changes: https://git.openjdk.org/jdk/pull/10866/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10866&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6972078
  Stats: 122 lines in 2 files changed: 121 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10866.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10866/head:pull/10866

PR: https://git.openjdk.org/jdk/pull/10866


From aturbanov at openjdk.org  Wed Oct 26 06:11:28 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 26 Oct 2022 06:11:28 GMT
Subject: Integrated: 8295767: Remove unused fields in sun.awt.geom.Edge
In-Reply-To: <Hf8VzgFNka7JbpjDTh4_eDbKPqmSwp3f7zM8ximg-0E=.771f0e85-5add-4f65-b5bc-90c62b423b5f@github.com>
References: <Hf8VzgFNka7JbpjDTh4_eDbKPqmSwp3f7zM8ximg-0E=.771f0e85-5add-4f65-b5bc-90c62b423b5f@github.com>
Message-ID: <_iSWPlAmG8429QA9PudKnqZDPtHvMLyPNpNCGxxAUwY=.e36a039a-0892-45cc-a3f3-ed32b521738e@github.com>

On Sun, 16 Oct 2022 21:30:47 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Remove couple of unused `static` fields in `sun.awt.geom.Edge` class.

This pull request has now been integrated.

Changeset: e3a5a34c
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3a5a34c4d18375a310212da2e52a8ad85a3f556
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8295767: Remove unused fields in sun.awt.geom.Edge

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/10720


From duke at openjdk.org  Wed Oct 26 07:19:14 2022
From: duke at openjdk.org (basix86)
Date: Wed, 26 Oct 2022 07:19:14 GMT
Subject: RFR: 8236907: JTable added to nested panels does not paint last
 visible row [v6]
In-Reply-To: <jah2oFNSLMeHahABUYh03HJQ35JI0aN0M_76t8rDI7Q=.9f27f09b-a826-4f29-a292-29d1fdfaa634@github.com>
References: <Xwc58NmkbNIShAkXmFRyiZrdhN-4EHh-r-FwswcULWw=.666e1d7b-b978-4dfb-8dc1-3dcf85f72cf8@github.com>
 <jah2oFNSLMeHahABUYh03HJQ35JI0aN0M_76t8rDI7Q=.9f27f09b-a826-4f29-a292-29d1fdfaa634@github.com>
Message-ID: <jqb8WdyBmWdzBvLPLHMK5LaX3s4xQGDGeLg3VXSsRAw=.b2721fef-3a0b-4362-a2f8-ec08b5dd8906@github.com>

On Tue, 22 Feb 2022 04:38:21 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Issue in painting last row of JTable due to decrement in `MaxRow `during computation. Differences in `MaxRow `computation between `TablePrintable` and `BasicTableUI `class. The Bug is fixed in both the classes. Test Case added to validate the same.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8236907: JTable added to nested panels does not paint last

Is planned to port the bug fix JDK-8236907 to the last LTS JDK (17)?

Thank you in advance

-------------

PR: https://git.openjdk.org/jdk/pull/7422


From shade at openjdk.org  Wed Oct 26 08:11:23 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Oct 2022 08:11:23 GMT
Subject: RFR: 8295868: 32-bit Windows build failures after JDK-8294466
In-Reply-To: <RfMXMt16m2IYqJjUkKvciC8oTPFLRoTiZaDQOBnGxNY=.fcab2e1c-b813-4480-80a1-1201c088f06b@github.com>
References: <RfMXMt16m2IYqJjUkKvciC8oTPFLRoTiZaDQOBnGxNY=.fcab2e1c-b813-4480-80a1-1201c088f06b@github.com>
Message-ID: <yqA6CQT-Qlnq9uAjJxeQHp3B5juKcEnfanuul52_mZ0=.a3d82a13-821f-460a-9bb4-e7af234b4af1@github.com>

On Tue, 25 Oct 2022 10:40:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> * For target support_native_java.desktop_libsplashscreen_splashscreen_impl.obj:
> splashscreen_impl.c
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): error C2220: the following warning is treated as an error
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(444): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(466): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(467): warning C4018: '>': signed/unsigned mismatch
> ``` 
> 
> I just added the disabled warning for that file. 
> 
> Additional testing:
>  - [x] Windows x86_32 release (now builds)
>  - [x] Windows x86_32 fastdebug (now builds)
>  - [x] Windows x86_32 slowdebug (now builds)

Thanks, I am going to integrate to unbreak my CI.

-------------

PR: https://git.openjdk.org/jdk/pull/10848


From shade at openjdk.org  Wed Oct 26 08:14:25 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Oct 2022 08:14:25 GMT
Subject: Integrated: 8295868: 32-bit Windows build failures after JDK-8294466
In-Reply-To: <RfMXMt16m2IYqJjUkKvciC8oTPFLRoTiZaDQOBnGxNY=.fcab2e1c-b813-4480-80a1-1201c088f06b@github.com>
References: <RfMXMt16m2IYqJjUkKvciC8oTPFLRoTiZaDQOBnGxNY=.fcab2e1c-b813-4480-80a1-1201c088f06b@github.com>
Message-ID: <nqGYEIH5n0BInxVl06jAUJKV7CFdByZ1xXwr-sLc5Mg=.bb88f236-9487-40f6-8f0b-597986d4d872@github.com>

On Tue, 25 Oct 2022 10:40:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> * For target support_native_java.desktop_libsplashscreen_splashscreen_impl.obj:
> splashscreen_impl.c
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): error C2220: the following warning is treated as an error
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(444): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(466): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(467): warning C4018: '>': signed/unsigned mismatch
> ``` 
> 
> I just added the disabled warning for that file. 
> 
> Additional testing:
>  - [x] Windows x86_32 release (now builds)
>  - [x] Windows x86_32 fastdebug (now builds)
>  - [x] Windows x86_32 slowdebug (now builds)

This pull request has now been integrated.

Changeset: 772be2e0
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/772be2e02b7bb1089116c0debb514154489cfa81
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8295868: 32-bit Windows build failures after JDK-8294466

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/10848


From tr at openjdk.org  Wed Oct 26 10:29:21 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 26 Oct 2022 10:29:21 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors [v2]
In-Reply-To: <6NKWCWUFCq7wkJrSe5Eq4lt-Og4YXi9Cmtio-OzPgVk=.3fd345f3-4d8a-49f3-a08b-231e12158994@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
 <6NKWCWUFCq7wkJrSe5Eq4lt-Og4YXi9Cmtio-OzPgVk=.3fd345f3-4d8a-49f3-a08b-231e12158994@github.com>
Message-ID: <1gAO14zDhQ3F-SmiJ5DcEovloT56Ddtn3_1NehAqWt0=.8b28d05b-e0a7-4e9a-aea1-1a51975b51ba@github.com>

On Wed, 26 Oct 2022 04:24:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

src/java.desktop/share/classes/javax/swing/border/MatteBorder.java line 172:

> 170:      * Reinitialize the insets parameter with this Border's current Insets.
> 171:      * @param c the component for which this border insets value applies
> 172:      * @param insets the object to be

_reinitialized_ is removed. Is it a typo?

-------------

PR: https://git.openjdk.org/jdk/pull/10740


From tr at openjdk.org  Wed Oct 26 10:35:54 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 26 Oct 2022 10:35:54 GMT
Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel
In-Reply-To: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>
References: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>
Message-ID: <G8fyyPqLUlr1vDewrqDARqJD1nlEWH8rR3dP7W997mE=.7deaf84c-ef50-44e3-a2e9-6da76ccaba3a@github.com>

On Wed, 26 Oct 2022 04:34:24 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF.
> 
> The condition check has been modified when multiselection is enabled and user has selected single directory.
> After the fix the behavior of JFileChooser is similar to other LAFs.
> 
> An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented and checked in CI pipeline. Link is attached in JBS.

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 73:

> 71:             robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
> 72:             robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
> 73:             robot.delay(100);

robot.mouseMove(pt.x + getSelectedFilesButton.getWidth() / 2,
                            pt.y + getSelectedFilesButton.getHeight() / 2);
            robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
            robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
            robot.delay(100);

`ClickMouse` method can be reused instead.

-------------

PR: https://git.openjdk.org/jdk/pull/10866


From duke at openjdk.org  Wed Oct 26 10:35:54 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 26 Oct 2022 10:35:54 GMT
Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel
In-Reply-To: <G8fyyPqLUlr1vDewrqDARqJD1nlEWH8rR3dP7W997mE=.7deaf84c-ef50-44e3-a2e9-6da76ccaba3a@github.com>
References: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>
 <G8fyyPqLUlr1vDewrqDARqJD1nlEWH8rR3dP7W997mE=.7deaf84c-ef50-44e3-a2e9-6da76ccaba3a@github.com>
Message-ID: <0rYxvaeSfJq4JRpIlsFY-OFp9PFW3VyXCAKHzBTWb0U=.4dcfca4e-0080-4e6f-b768-902eecaf9653@github.com>

On Wed, 26 Oct 2022 10:30:48 GMT, Tejesh R <tr at openjdk.org> wrote:

>> While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF.
>> 
>> The condition check has been modified when multiselection is enabled and user has selected single directory.
>> After the fix the behavior of JFileChooser is similar to other LAFs.
>> 
>> An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented and checked in CI pipeline. Link is attached in JBS.
>
> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 73:
> 
>> 71:             robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
>> 72:             robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
>> 73:             robot.delay(100);
> 
> robot.mouseMove(pt.x + getSelectedFilesButton.getWidth() / 2,
>                             pt.y + getSelectedFilesButton.getHeight() / 2);
>             robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
>             robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
>             robot.delay(100);
> 
> `ClickMouse` method can be reused instead.

There is an offset added in x-position. That's why `ClickMouse ` is not reused.

-------------

PR: https://git.openjdk.org/jdk/pull/10866


From tr at openjdk.org  Wed Oct 26 10:42:48 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 26 Oct 2022 10:42:48 GMT
Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel
In-Reply-To: <0rYxvaeSfJq4JRpIlsFY-OFp9PFW3VyXCAKHzBTWb0U=.4dcfca4e-0080-4e6f-b768-902eecaf9653@github.com>
References: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>
 <G8fyyPqLUlr1vDewrqDARqJD1nlEWH8rR3dP7W997mE=.7deaf84c-ef50-44e3-a2e9-6da76ccaba3a@github.com>
 <0rYxvaeSfJq4JRpIlsFY-OFp9PFW3VyXCAKHzBTWb0U=.4dcfca4e-0080-4e6f-b768-902eecaf9653@github.com>
Message-ID: <E3lMNi6VT_UxM__2bM2svFRyiJOAg-nwmwuLkSV3Beg=.c3fc73e0-ea2b-4189-bc50-d5d27dd81e15@github.com>

On Wed, 26 Oct 2022 10:33:49 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 73:
>> 
>>> 71:             robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
>>> 72:             robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
>>> 73:             robot.delay(100);
>> 
>> robot.mouseMove(pt.x + getSelectedFilesButton.getWidth() / 2,
>>                             pt.y + getSelectedFilesButton.getHeight() / 2);
>>             robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
>>             robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
>>             robot.delay(100);
>> 
>> `ClickMouse` method can be reused instead.
>
> There is an offset added in x-position. That's why `ClickMouse ` is not reused.

Yeah, compute the offset in main method and just pass the point. So that whole method can be reused.

-------------

PR: https://git.openjdk.org/jdk/pull/10866


From psadhukhan at openjdk.org  Wed Oct 26 10:46:03 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 26 Oct 2022 10:46:03 GMT
Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException
Message-ID: <ABJ79VQJ9Z_V9wB6JJTykhwJlGXac6aKHoe0Tdc5PNI=.bba61627-c1bc-40b0-a039-ac1bf918d22c@github.com>

If getDefaultEditor() is called before the JTable model is setup, it results in NPE.

This is because when JTable sets its model, which ends up firing a table changed event. The testcase is listening for tableChanged events and querying the editor. But the editor isn't installed until after the model is set which results in NPE.
Fix is to ensure initializeLocalVars() which initializes default editor is setup before JTable sets its model.

No regression is observed in jtreg/jck testsuite with this change.

-------------

Commit messages:
 - 6257207: JTable.getDefaultEditor throws NullPointerException
 - 6257207: JTable.getDefaultEditor throws NullPointerException
 - 6257207: JTable.getDefaultEditor throws NullPointerException

Changes: https://git.openjdk.org/jdk/pull/10871/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10871&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6257207
  Stats: 134 lines in 2 files changed: 133 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10871.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10871/head:pull/10871

PR: https://git.openjdk.org/jdk/pull/10871


From psadhukhan at openjdk.org  Wed Oct 26 10:48:48 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 26 Oct 2022 10:48:48 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors [v3]
In-Reply-To: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
Message-ID: <ZmHtPJKur7MkameLduqQk-sjbaHats_UbQjn9v3kC0w=.cbd5f716-1795-4acd-b426-c01c2e8b5af0@github.com>

> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  revert typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10740/files
  - new: https://git.openjdk.org/jdk/pull/10740/files/dd44d401..389c7c4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10740&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10740&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10740.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10740/head:pull/10740

PR: https://git.openjdk.org/jdk/pull/10740


From tr at openjdk.org  Wed Oct 26 10:48:48 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 26 Oct 2022 10:48:48 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors [v3]
In-Reply-To: <ZmHtPJKur7MkameLduqQk-sjbaHats_UbQjn9v3kC0w=.cbd5f716-1795-4acd-b426-c01c2e8b5af0@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
 <ZmHtPJKur7MkameLduqQk-sjbaHats_UbQjn9v3kC0w=.cbd5f716-1795-4acd-b426-c01c2e8b5af0@github.com>
Message-ID: <Y0jwlkMcb0oNBdEQtUQ0biHsh2ovJKsjksLfKThnb8k=.a09be161-26bc-4e25-aacf-5a0647415284@github.com>

On Wed, 26 Oct 2022 10:44:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert typo

Marked as reviewed by tr (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/10740


From psadhukhan at openjdk.org  Wed Oct 26 10:48:49 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 26 Oct 2022 10:48:49 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors [v2]
In-Reply-To: <1gAO14zDhQ3F-SmiJ5DcEovloT56Ddtn3_1NehAqWt0=.8b28d05b-e0a7-4e9a-aea1-1a51975b51ba@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
 <6NKWCWUFCq7wkJrSe5Eq4lt-Og4YXi9Cmtio-OzPgVk=.3fd345f3-4d8a-49f3-a08b-231e12158994@github.com>
 <1gAO14zDhQ3F-SmiJ5DcEovloT56Ddtn3_1NehAqWt0=.8b28d05b-e0a7-4e9a-aea1-1a51975b51ba@github.com>
Message-ID: <lkcCy-ASp7fH_bJIepj7ujBufLS6znLFxIpygPs4Vpg=.cb51df34-4d13-4981-b044-bc47f1448fb1@github.com>

On Wed, 26 Oct 2022 10:27:10 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fix
>
> src/java.desktop/share/classes/javax/swing/border/MatteBorder.java line 172:
> 
>> 170:      * Reinitialize the insets parameter with this Border's current Insets.
>> 171:      * @param c the component for which this border insets value applies
>> 172:      * @param insets the object to be
> 
> _reinitialized_ is removed. Is it a typo?

yes..rectified.

-------------

PR: https://git.openjdk.org/jdk/pull/10740


From psadhukhan at openjdk.org  Wed Oct 26 11:13:25 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 26 Oct 2022 11:13:25 GMT
Subject: RFR: 6244831: JFileChooser does not have tooltip for Desktop,
 Recent etc ToggleButton on Windows Look and feel
In-Reply-To: <1yxgaZjxkI6-vUTqgVLXOyt-a8GmnpDi45mZdFBsZGI=.793f8299-6c5d-48e3-9e96-44f337e7388d@github.com>
References: <1yxgaZjxkI6-vUTqgVLXOyt-a8GmnpDi45mZdFBsZGI=.793f8299-6c5d-48e3-9e96-44f337e7388d@github.com>
Message-ID: <HUyASFwKzfu89lCO57rLZjG4wqJsBkbaSJkBu5harn4=.30e9b994-f615-46cf-8622-7fd5fcda022b@github.com>

On Fri, 21 Oct 2022 16:04:14 GMT, Tejesh R <tr at openjdk.org> wrote:

> Tooltip is not shown for the buttons placed in left side of JFileChooser(In Windows Look And Feel), namely the shellFolder like (Recent Items, Desktop, Documents). Hence the tooltip is added for those shell folders/WindowBar when they are constructed. The Automatic test is added.

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10819


From dfuchs at openjdk.org  Wed Oct 26 16:11:27 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Oct 2022 16:11:27 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
Message-ID: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>

Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.

The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 

This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.

In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.

In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.

Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.

The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

-------------

Commit messages:
 - Fix whitespace issues
 - 8294241

Changes: https://git.openjdk.org/jdk/pull/10874/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294241
  Stats: 849 lines in 82 files changed: 701 ins; 2 del; 146 mod
  Patch: https://git.openjdk.org/jdk/pull/10874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874

PR: https://git.openjdk.org/jdk/pull/10874


From duke at openjdk.org  Wed Oct 26 16:26:24 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 26 Oct 2022 16:26:24 GMT
Subject: RFR: 6244831: JFileChooser does not have tooltip for Desktop,
 Recent etc ToggleButton on Windows Look and feel
In-Reply-To: <1yxgaZjxkI6-vUTqgVLXOyt-a8GmnpDi45mZdFBsZGI=.793f8299-6c5d-48e3-9e96-44f337e7388d@github.com>
References: <1yxgaZjxkI6-vUTqgVLXOyt-a8GmnpDi45mZdFBsZGI=.793f8299-6c5d-48e3-9e96-44f337e7388d@github.com>
Message-ID: <_jwagg9FOBfc_vhi0vMgzyFNMqnRjSbGVeOmw6UUnJI=.bdd080d9-2b3c-42fa-a74f-1def29bbeebc@github.com>

On Fri, 21 Oct 2022 16:04:14 GMT, Tejesh R <tr at openjdk.org> wrote:

> Tooltip is not shown for the buttons placed in left side of JFileChooser(In Windows Look And Feel), namely the shellFolder like (Recent Items, Desktop, Documents). Hence the tooltip is added for those shell folders/WindowBar when they are constructed. The Automatic test is added.

Fix looks good to me.

-------------

Marked as reviewed by kumarabhi006 at github.com (no known OpenJDK username).

PR: https://git.openjdk.org/jdk/pull/10819


From duke at openjdk.org  Wed Oct 26 16:26:33 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 26 Oct 2022 16:26:33 GMT
Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel
 [v2]
In-Reply-To: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>
References: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>
Message-ID: <8eobdmVaHGFsFgaL6oyv193K0AKZcJ2EDmN1JPJyRyY=.490d48e5-6033-4de5-b455-dbd8affcd1b7@github.com>

> While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF.
> 
> The condition check has been modified when multiselection is enabled and user has selected single directory.
> After the fix the behavior of JFileChooser is similar to other LAFs.
> 
> An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented and checked in CI pipeline. Link is attached in JBS.

Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Review comment fix
 - Merge
 - Whitespace error fix
 - Single directory selection fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10866/files
  - new: https://git.openjdk.org/jdk/pull/10866/files/551a790b..c129d187

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10866&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10866&range=00-01

  Stats: 128073 lines in 785 files changed: 71055 ins; 27973 del; 29045 mod
  Patch: https://git.openjdk.org/jdk/pull/10866.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10866/head:pull/10866

PR: https://git.openjdk.org/jdk/pull/10866


From duke at openjdk.org  Wed Oct 26 16:26:34 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 26 Oct 2022 16:26:34 GMT
Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel
 [v2]
In-Reply-To: <E3lMNi6VT_UxM__2bM2svFRyiJOAg-nwmwuLkSV3Beg=.c3fc73e0-ea2b-4189-bc50-d5d27dd81e15@github.com>
References: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>
 <G8fyyPqLUlr1vDewrqDARqJD1nlEWH8rR3dP7W997mE=.7deaf84c-ef50-44e3-a2e9-6da76ccaba3a@github.com>
 <0rYxvaeSfJq4JRpIlsFY-OFp9PFW3VyXCAKHzBTWb0U=.4dcfca4e-0080-4e6f-b768-902eecaf9653@github.com>
 <E3lMNi6VT_UxM__2bM2svFRyiJOAg-nwmwuLkSV3Beg=.c3fc73e0-ea2b-4189-bc50-d5d27dd81e15@github.com>
Message-ID: <_gfVO52f9euPbMOXGNSmYl6Tv_JytkhYZ2VQh0CIP-Y=.5995c481-dcef-44d3-a12b-75ff0826de3c@github.com>

On Wed, 26 Oct 2022 10:39:51 GMT, Tejesh R <tr at openjdk.org> wrote:

>> There is an offset added in x-position. That's why `ClickMouse ` is not reused.
>
> Yeah, compute the offset in main method and just pass the point. So that whole method can be reused.

Updated.

-------------

PR: https://git.openjdk.org/jdk/pull/10866


From michaelm at openjdk.org  Wed Oct 26 16:45:22 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 26 Oct 2022 16:45:22 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

src/java.base/share/classes/java/net/JarURLConnection.java line 177:

> 175:         @SuppressWarnings("deprecation")
> 176:         var tmp = jarFileURL = new URL(spec.substring(0, separator++));
> 177: 

I realise that @SuppressWarnings needs a declaration here. I wonder if we could agree a better name for the unused variable name though, like `unusedSW` or something better?

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From weijun at openjdk.org  Wed Oct 26 16:48:22 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Oct 2022 16:48:22 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <6CBNoueQtp5P8wa0FuOCHQtmw9610BdOrP7pvhg1g70=.6cc91f26-df33-4722-9c49-f390ed6387aa@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

The change to security-related code looks fine to me.

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From xuelei at openjdk.org  Wed Oct 26 17:11:27 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 26 Oct 2022 17:11:27 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

src/java.base/share/classes/java/net/URL.java line 852:

> 850:      * @since 20
> 851:      */
> 852:     public static URL fromURI(URI uri, URLStreamHandler streamHandler)

What do you think to have this method in URI instead: URI.toURL(URLStreamHandler), as there is an URI.toURL() method already?

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From dfuchs at openjdk.org  Wed Oct 26 17:29:01 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Oct 2022 17:29:01 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
Message-ID: <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>

On Wed, 26 Oct 2022 17:09:20 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> src/java.base/share/classes/java/net/URL.java line 852:
> 
>> 850:      * @since 20
>> 851:      */
>> 852:     public static URL fromURI(URI uri, URLStreamHandler streamHandler)
> 
> What do you think to have this method in URI instead: URI.toURL(URLStreamHandler), as there is an URI.toURL() method already?

`URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent.

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From aivanov at openjdk.org  Wed Oct 26 17:39:31 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 26 Oct 2022 17:39:31 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v8]
In-Reply-To: <jA6hVbeFGjA36-4LOcEiczAl4ebQlrfBXlDv4AcgYHI=.c919764a-8012-4033-aecf-228cb88ae750@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <jA6hVbeFGjA36-4LOcEiczAl4ebQlrfBXlDv4AcgYHI=.c919764a-8012-4033-aecf-228cb88ae750@github.com>
Message-ID: <XQOUvb9CyUysCQrkYtURZ-qI8fAlTMRLCOqIvA-t4Fs=.f85caeff-507f-4155-aade-161c8828999b@github.com>

On Wed, 26 Oct 2022 04:05:54 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.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

I already mentioned that I wrote a comprehensive unit-test to test the changes to `removeIndexInterval` and `insertIndexInterval`. The latest version of my test [`SelectionModelTest.java`](https://github.com/aivanov-jdk/jdk/blob/f9e8bf592125419d117bd1d6318f9ce909a1dcc1/test/jdk/javax/swing/JList/SelectionModelTest.java).

With the current code in the PR, six (6) test cases still _fail_. The changes I've suggested should resolve those failures. (I've been testing and proposing fixes to resolve test failures since the start of this code review.)

The test can be run as a jtreg test or as a standalone app. Depending on the hardware, it may take up to 10 minutes; the more cores the system has, the faster the test completes as all the test cases are run in parallel. (The minimum time I've ever seen is around 2?3 minutes.)

I can contribute the test to OpenJDK if deemed useful. I believe such a fix can't be done without extensive testing which verifies all the values in the object remain correct.

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 452:

> 450:                 clear(i);
> 451:             }
> 452:             // Integer overlfow

Typo:
Suggestion:

            // Integer overflow

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 453:

> 451:             }
> 452:             // Integer overlfow
> 453:             if (i + 1 < i) {

Suggestion:

            if (i == Integer.MAX_VALUE) {

Will it be clearer this way? (And one less operation: no addition.)

As I mentioned before, I would prefer reversing the loop and iterating from `max` to `min` instead. But it causes a failure in JCK which I can't explain because the effective result is the same. Moreover, I believe iterating from `max` to `min` is more efficient as touching the maximum index will ensure the internal storage in the underlying `BitSet` is allocated right away to fit all the bits whereas the storage gets continuously re-allocated and copied as the accessed indexes grow.

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 651:

> 649:     {
> 650:         if (length < 0 || index < 0) {
> 651:             throw new IndexOutOfBoundsException("index or length is negative");

I suggest updating the spec to state this explicitly. The current implementation throws IOOBE if `index` is negative and if `index + length` is negative. It doesn't throw the exception if `length` is negative but the sum of `index` and `length` remains positive, which doesn't make sense ? the updated model becomes corrupted.

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 653:

> 651:             throw new IndexOutOfBoundsException("index or length is negative");
> 652:         }
> 653:         if (index + length < 0) {

I suggested handling the case where `index == Integer.MAX_VALUE  || length == 0` as a special case because there's nothing to update. It's a little optimisation.

If `index == Integer.MAX_VALUE`, there's only one index which can possibly be inserted, that is at `Integer.MAX_VALUE`. By the spec, the inserted index will have the same value which had the index before insertion. So no change occurs.

In addition to the above, special handling of `index == Integer.MAX_VALUE` prevents integer overflow in `insMinIndex` if `before` is `false`.

If `length == 0`, no new indexes are inserted irrespective of the value of `index`. Thus nothing changes in the object state.

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 666:

> 664:          * insMinIndex).
> 665:          */
> 666:         for(int i = maxIndex; (i+length) >= 0 && i >= insMinIndex; i--) {

You break from the loop prematurely and perhaps never enter the loop. The chances for `(i + length)` to be negative are much higher for larger indexes closer to `maxIndex`.

The iteration is to start at the index which ensures `i + length <= Integer.MAX_VALUE`. That is

        int startIndex = maxIndex <= Integer.MAX_VALUE - length
                         ? maxIndex
                         : Integer.MAX_VALUE - length;
        for(int i = startIndex; i >= insMinIndex; i--) {

which can be simplified to

        for(int i = Math.min(maxIndex, Integer.MAX_VALUE - length); i >= insMinIndex; i--) {

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 673:

> 671:          */
> 672:         boolean setInsertedValues = ((getSelectionMode() == SINGLE_SELECTION) ?
> 673:                                         false : value.get(index));

I propose resolving an IDE warning and simplify this condition:
Suggestion:

        boolean setInsertedValues = (getSelectionMode() != SINGLE_SELECTION
                                     && value.get(index));

Although this change is unrelated.

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 674:

> 672:         boolean setInsertedValues = ((getSelectionMode() == SINGLE_SELECTION) ?
> 673:                                         false : value.get(index));
> 674:         for(int i = insMinIndex; i >=0 && i <= insMaxIndex; i++) {

Suggestion:

        for(int i = insMaxIndex; i >= insMinIndex; i--) {

This loop can be reversed to avoid adding `i >= 0` to the condition. (I tested it and it doesn't lead to any failures in JCK as it does when the same is done in the loop in `changeSelection`.)

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 711:

> 709:         int rmMaxIndex = Math.max(index0, index1);
> 710: 
> 711: 

Is one blank line enough?

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 734:

> 732:         }
> 733: 
> 734: 

Not needed?

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 758:

> 756: 
> 757:         fireValueChanged();
> 758: 

Not needed?

test/jdk/javax/swing/TestDefListModelException.java line 32:

> 30: import javax.swing.DefaultListSelectionModel;
> 31: 
> 32: public class TestDefListModelException {

I propose moving this test to `JList` folder which already contains several tests which use `ListSelectionModel` via `JList`.

-------------

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10409


From xuelei at openjdk.org  Wed Oct 26 17:42:31 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 26 Oct 2022 17:42:31 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
Message-ID: <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>

On Wed, 26 Oct 2022 17:24:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/URL.java line 852:
>> 
>>> 850:      * @since 20
>>> 851:      */
>>> 852:     public static URL fromURI(URI uri, URLStreamHandler streamHandler)
>> 
>> What do you think to have this method in URI instead: URI.toURL(URLStreamHandler), as there is an URI.toURL() method already?
>
> `URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent.

I see your point.  It may be more appropriate if URI.toURL was designed as URL.fromURL.

I was wondering to have application developers a consistent way to get an URL instance.  Now there are two methods in different classes URI.toURL and URL.fromURI.  It might be easier to use the old URI.toURL form.

Never mind, it is just my personal preference.  It is fine to me to have a new URL.fromURI method.

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From dfuchs at openjdk.org  Wed Oct 26 17:57:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Oct 2022 17:57:40 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
Message-ID: <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>

On Wed, 26 Oct 2022 17:39:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> `URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent.
>
> I see your point.  It may be more appropriate if URI.toURL was designed as URL.fromURL.
> 
> I was wondering to have application developers a consistent way to get an URL instance.  Now there are two methods in different classes URI.toURL and URL.fromURI.  It might be easier to use the old URI.toURL form.
> 
> Never mind, it is just my personal preference.  It is fine to me to have a new URL.fromURI method.

One thing we might do is change the name of the method into `URL.of(URI, StreamHandler)`. It's named `fromURI` merely because there was a pre-existing package protected `fromURI` method. However since we're making it public now, it could be fair game to change its name. Possibly adding an overload `URL::of(URI)` method could be considered, but then there really would be two paths to do the same thing - so I'd rather not add such an overload - unless I get some more feedback on that from the CSR/PR review.

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From aivanov at openjdk.org  Wed Oct 26 18:24:32 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 26 Oct 2022 18:24:32 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v8]
In-Reply-To: <XQOUvb9CyUysCQrkYtURZ-qI8fAlTMRLCOqIvA-t4Fs=.f85caeff-507f-4155-aade-161c8828999b@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <jA6hVbeFGjA36-4LOcEiczAl4ebQlrfBXlDv4AcgYHI=.c919764a-8012-4033-aecf-228cb88ae750@github.com>
 <XQOUvb9CyUysCQrkYtURZ-qI8fAlTMRLCOqIvA-t4Fs=.f85caeff-507f-4155-aade-161c8828999b@github.com>
Message-ID: <HxTUZsu-qFJmuKJztp6l_M2Iq6FSMu4A_isxAvaABQE=.30a79fc2-b0c5-4c7d-8a66-366382ce09c2@github.com>

On Wed, 26 Oct 2022 17:34:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> With the current code in the PR, six (6) test cases still _fail_.

The failure of `test10` is expected: you adjust the value of `length` so that `insMaxIndex` can't be greater than `Integer.MAX_VALUE`. It is a valid failure, the test needs changing: `lead` should be become `Integer.MAX_VALUE + 1 = -2147483648 (0x80000000)`.

Other five failures are valid ones, `minIndex` and `maxIndex` in the object don't have the expected values.

-------------

PR: https://git.openjdk.org/jdk/pull/10409


From prr at openjdk.org  Wed Oct 26 19:43:54 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 26 Oct 2022 19:43:54 GMT
Subject: RFR: 8282463: javax/sound/sampled/Clip/DataPusherThreadCheck.java
 fails
In-Reply-To: <myMXcksU12EK7xpYDTIW7PWDv2Gl1pftNHFeQzGrU8Q=.79d47610-3fb8-416a-961d-dc22f6c92480@github.com>
References: <myMXcksU12EK7xpYDTIW7PWDv2Gl1pftNHFeQzGrU8Q=.79d47610-3fb8-416a-961d-dc22f6c92480@github.com>
Message-ID: <_ToCOr-0dgf2O1ktQHOJBSKA3msOWE3neikal-yIjK8=.08d3d3d6-d700-4b9c-b84a-b209489385ea@github.com>

On Sat, 15 Oct 2022 13:03:26 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Test failed on Ubuntu, because both implementations of `MixerProvider` have no devices:
> 1. com.sun.media.sound.DirectAudioDeviceProvider#nGetNumDevices returns `0`
>  ![DirectAudioDeviceProvider init](https://user-images.githubusercontent.com/741251/195988216-aa86da0f-739b-433f-87e2-86c2d6904a0d.png)
> 2. com.sun.media.sound.PortMixerProvider#nGetNumDevices returns `0`
>  ![PortMixerProvider init](https://user-images.githubusercontent.com/741251/195988239-59678e0c-be7b-43ff-b02a-9abb2392e8f9.png)
> 
> 
> It leads to `javax.sound.sampled.spi.MixerProvider#getMixerInfo` returns empty array.
> ![AudioSystem getMixedInfoList](https://user-images.githubusercontent.com/741251/195988266-1656e6d3-de4a-4e53-a613-415f60075726.png)
> 
> And DataPusher thread is not created, because of AudioSystem.isLineSupported returns false in the method `com.sun.media.sound.JavaSoundAudioClip#createSourceDataLine`.
> I propose to perform the same check in test code and skip it.

So I have no real objection to this check because it will solve something - more on that at the end.
1) On my Ubuntu 22.04 system it passes this new condition you added - ie the device is present.
2) This test has been failing only very intermittently, which points to the failure mode in the test being that the DataPusher thread is created but is terminated before it can be observed.

Where I've seen the device not present is when running on some VM configs where there is no audio support - there the test will fail every time.
For that I think your check should cure the 100% failure, but will do nothing about the 1% (or less) failure.

That said .. the test doesn't call clip.stop() until after the verification, so perhaps there's something else going on.

-------------

PR: https://git.openjdk.org/jdk/pull/10717


From psadhukhan at openjdk.org  Thu Oct 27 04:04:33 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 27 Oct 2022 04:04:33 GMT
Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel
 [v2]
In-Reply-To: <8eobdmVaHGFsFgaL6oyv193K0AKZcJ2EDmN1JPJyRyY=.490d48e5-6033-4de5-b455-dbd8affcd1b7@github.com>
References: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>
 <8eobdmVaHGFsFgaL6oyv193K0AKZcJ2EDmN1JPJyRyY=.490d48e5-6033-4de5-b455-dbd8affcd1b7@github.com>
Message-ID: <tv3agevGXrOEOYakLvPERGOeaTMSI9Gc62NZ48mcquY=.2e47afdc-2b6d-46b3-ad06-03c9c2fa3b3e@github.com>

On Wed, 26 Oct 2022 16:26:33 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF.
>> 
>> The condition check has been modified when multiselection is enabled and user has selected single directory.
>> After the fix the behavior of JFileChooser is similar to other LAFs.
>> 
>> An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented and checked in CI pipeline. Link is attached in JBS.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Review comment fix
>  - Merge
>  - Whitespace error fix
>  - Single directory selection fix

Can you also please test it works ok (or atleast not regress) for other selection mode FILES_ONLY, DIRECTORIES_ONLY in the test?

> After the fix the behavior of JFileChooser is similar to other LAFs.

Can you then please enhance the test to iterate for all installed L&Fs?

-------------

PR: https://git.openjdk.org/jdk/pull/10866


From tr at openjdk.org  Thu Oct 27 04:41:30 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 27 Oct 2022 04:41:30 GMT
Subject: Integrated: 6244831: JFileChooser does not have tooltip for Desktop, 
 Recent etc ToggleButton on Windows Look and feel
In-Reply-To: <1yxgaZjxkI6-vUTqgVLXOyt-a8GmnpDi45mZdFBsZGI=.793f8299-6c5d-48e3-9e96-44f337e7388d@github.com>
References: <1yxgaZjxkI6-vUTqgVLXOyt-a8GmnpDi45mZdFBsZGI=.793f8299-6c5d-48e3-9e96-44f337e7388d@github.com>
Message-ID: <QmGUPbbpgzeeaPxalCDgi4zOi0W776QhxSWCAyEsNrg=.c4377180-6b00-493b-9c45-a5d710af2e66@github.com>

On Fri, 21 Oct 2022 16:04:14 GMT, Tejesh R <tr at openjdk.org> wrote:

> Tooltip is not shown for the buttons placed in left side of JFileChooser(In Windows Look And Feel), namely the shellFolder like (Recent Items, Desktop, Documents). Hence the tooltip is added for those shell folders/WindowBar when they are constructed. The Automatic test is added.

This pull request has now been integrated.

Changeset: 210fe49e
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/210fe49e25da0ed6f3d3799ed253d9374568b89e
Stats:     112 lines in 2 files changed: 112 ins; 0 del; 0 mod

6244831: JFileChooser does not have tooltip for Desktop, Recent etc ToggleButton on Windows Look and feel

Reviewed-by: psadhukhan

-------------

PR: https://git.openjdk.org/jdk/pull/10819


From duke at openjdk.org  Thu Oct 27 05:16:38 2022
From: duke at openjdk.org (ExE Boss)
Date: Thu, 27 Oct 2022 05:16:38 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
Message-ID: <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>

On Wed, 26 Oct 2022 16:41:29 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> src/java.base/share/classes/java/net/JarURLConnection.java line 177:
> 
>> 175:         @SuppressWarnings("deprecation")
>> 176:         var tmp = jarFileURL = new URL(spec.substring(0, separator++));
>> 177: 
> 
> I realise that @SuppressWarnings needs a declaration here. I wonder if we could agree a better name for the unused variable name though, like `unusedSW` or something better?

Having?unnamed local?variables[^1] would?probably be?best for?this.

[^1]: https://openjdk.org/jeps/8294349

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From psadhukhan at openjdk.org  Thu Oct 27 05:52:26 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 27 Oct 2022 05:52:26 GMT
Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel
 [v2]
In-Reply-To: <8eobdmVaHGFsFgaL6oyv193K0AKZcJ2EDmN1JPJyRyY=.490d48e5-6033-4de5-b455-dbd8affcd1b7@github.com>
References: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>
 <8eobdmVaHGFsFgaL6oyv193K0AKZcJ2EDmN1JPJyRyY=.490d48e5-6033-4de5-b455-dbd8affcd1b7@github.com>
Message-ID: <JPh_CovhKDisRTKc1Y_otnXfjwsdCCgkjS2Iif4fPvk=.b435d7b5-ed54-448d-ad41-228af9a47876@github.com>

On Wed, 26 Oct 2022 16:26:33 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF.
>> 
>> The condition check has been modified when multiselection is enabled and user has selected single directory.
>> After the fix the behavior of JFileChooser is similar to other LAFs.
>> 
>> An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented and checked in CI pipeline. Link is attached in JBS.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Review comment fix
>  - Merge
>  - Whitespace error fix
>  - Single directory selection fix

Also, please see if [JDK-4912623](https://bugs.openjdk.org/browse/JDK-4912623) is related and fixed by this?

-------------

PR: https://git.openjdk.org/jdk/pull/10866


From mvs at openjdk.org  Thu Oct 27 06:54:22 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Thu, 27 Oct 2022 06:54:22 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
References: <vZKXQIaTVZcTkukcvqitssia2wTbdU-3JkNkZiWtCII=.d44d70b1-8703-49cf-8f17-22f9bf61784c@github.com>
Message-ID: <pnRAmDj9o5zhIWKtMGxokvgj3riQLjIYsaaBKD3cFRE=.fa8fc843-adac-4e46-a9b4-6adf51fc5fe6@github.com>

On Tue, 11 Oct 2022 14:17:42 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same.
> 
> Fix:
> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
> Also updated the screen capture code, made frame undecorated, added some prints for better debugging.

Any volunteers please.

-------------

PR: https://git.openjdk.org/jdk/pull/10655


From duke at openjdk.org  Thu Oct 27 08:38:35 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 27 Oct 2022 08:38:35 GMT
Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel
 [v3]
In-Reply-To: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>
References: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>
Message-ID: <hUAr1PB0-rzehP2j7SEtIiDNJwlHDMSvadoLEoyb7W8=.0f18dfb2-c09f-4673-a7a5-5a86545ebcd9@github.com>

> While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF.
> 
> The condition check has been modified when multiselection is enabled and user has selected single directory.
> After the fix the behavior of JFileChooser is similar to other LAFs.
> 
> An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented 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:

  Test for all installed LAF

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10866/files
  - new: https://git.openjdk.org/jdk/pull/10866/files/c129d187..970eca4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10866&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10866&range=01-02

  Stats: 45 lines in 1 file changed: 21 ins; 4 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/10866.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10866/head:pull/10866

PR: https://git.openjdk.org/jdk/pull/10866


From duke at openjdk.org  Thu Oct 27 08:40:07 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 27 Oct 2022 08:40:07 GMT
Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel
 [v2]
In-Reply-To: <tv3agevGXrOEOYakLvPERGOeaTMSI9Gc62NZ48mcquY=.2e47afdc-2b6d-46b3-ad06-03c9c2fa3b3e@github.com>
References: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>
 <8eobdmVaHGFsFgaL6oyv193K0AKZcJ2EDmN1JPJyRyY=.490d48e5-6033-4de5-b455-dbd8affcd1b7@github.com>
 <tv3agevGXrOEOYakLvPERGOeaTMSI9Gc62NZ48mcquY=.2e47afdc-2b6d-46b3-ad06-03c9c2fa3b3e@github.com>
Message-ID: <3C2MgF_7g8dIAAwmHVMFT6kyzuFZRcWec0TseTNlJs0=.f5cba3e2-dfd2-4f6f-b400-da80601a259b@github.com>

On Thu, 27 Oct 2022 04:00:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Can you also please test it works ok (or atleast not regress) for other selection mode FILES_ONLY, DIRECTORIES_ONLY in the test?

Verified for file selection mode of `DIRECTORIES_ONLY`, test passed for all LAFs.

In case of selection mode of `FILES_ONLY`, test is failing for all LAFs. The reason behind this is we are trying to select `Directory `when selection mode is set to `FILES_ONLY`. 

> Can you then please enhance the test to iterate for all installed L&Fs?

Updated for all installed LAFs.

-------------

PR: https://git.openjdk.org/jdk/pull/10866


From duke at openjdk.org  Thu Oct 27 08:52:28 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 27 Oct 2022 08:52:28 GMT
Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel
 [v2]
In-Reply-To: <JPh_CovhKDisRTKc1Y_otnXfjwsdCCgkjS2Iif4fPvk=.b435d7b5-ed54-448d-ad41-228af9a47876@github.com>
References: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>
 <8eobdmVaHGFsFgaL6oyv193K0AKZcJ2EDmN1JPJyRyY=.490d48e5-6033-4de5-b455-dbd8affcd1b7@github.com>
 <JPh_CovhKDisRTKc1Y_otnXfjwsdCCgkjS2Iif4fPvk=.b435d7b5-ed54-448d-ad41-228af9a47876@github.com>
Message-ID: <ULkEdL6yooYPUE9dexRdOVNiBgnSMaJP-YOY-HsWRK0=.5f6fa812-00f0-45c1-9511-3af94ded4f46@github.com>

On Thu, 27 Oct 2022 05:48:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Also, please see if [JDK-4912623](https://bugs.openjdk.org/browse/JDK-4912623) is related and fixed by this?

Ok, I will check.

-------------

PR: https://git.openjdk.org/jdk/pull/10866


From michaelm at openjdk.org  Thu Oct 27 09:21:35 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 27 Oct 2022 09:21:35 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
 <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
Message-ID: <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>

On Thu, 27 Oct 2022 05:14:19 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/JarURLConnection.java line 177:
>> 
>>> 175:         @SuppressWarnings("deprecation")
>>> 176:         var tmp = jarFileURL = new URL(spec.substring(0, separator++));
>>> 177: 
>> 
>> I realise that @SuppressWarnings needs a declaration here. I wonder if we could agree a better name for the unused variable name though, like `unusedSW` or something better?
>
> Having?unnamed local?variables[^1] would?probably be?best for?this.
> 
> [^1]: https://openjdk.org/jeps/8294349

How about `_unused` or `_unused1`, `_unused2` then in the meantime?

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From psadhukhan at openjdk.org  Thu Oct 27 09:29:24 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 27 Oct 2022 09:29:24 GMT
Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel
 [v2]
In-Reply-To: <3C2MgF_7g8dIAAwmHVMFT6kyzuFZRcWec0TseTNlJs0=.f5cba3e2-dfd2-4f6f-b400-da80601a259b@github.com>
References: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>
 <8eobdmVaHGFsFgaL6oyv193K0AKZcJ2EDmN1JPJyRyY=.490d48e5-6033-4de5-b455-dbd8affcd1b7@github.com>
 <tv3agevGXrOEOYakLvPERGOeaTMSI9Gc62NZ48mcquY=.2e47afdc-2b6d-46b3-ad06-03c9c2fa3b3e@github.com>
 <3C2MgF_7g8dIAAwmHVMFT6kyzuFZRcWec0TseTNlJs0=.f5cba3e2-dfd2-4f6f-b400-da80601a259b@github.com>
Message-ID: <zY1XMji0UOPWASuKiyLKpe92OB22bLR-1I7iLBLAGp8=.7963df2e-3bf5-4448-957c-1a96f9d8cad3@github.com>

On Thu, 27 Oct 2022 08:37:48 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> > Can you also please test it works ok (or atleast not regress) for other selection mode FILES_ONLY, DIRECTORIES_ONLY in the test?
> 
> Verified for file selection mode of `DIRECTORIES_ONLY`, test passed for all LAFs.
> 
> In case of selection mode of `FILES_ONLY`, test is failing for all LAFs. The reason behind this is we are trying to select `Directory `when selection mode is set to `FILES_ONLY`.

I guess you can see in folders where you have only files...Testwise, maybe use File.createTempFile for creating files and see..

-------------

PR: https://git.openjdk.org/jdk/pull/10866


From duke at openjdk.org  Thu Oct 27 09:39:27 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 27 Oct 2022 09:39:27 GMT
Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel
 [v2]
In-Reply-To: <zY1XMji0UOPWASuKiyLKpe92OB22bLR-1I7iLBLAGp8=.7963df2e-3bf5-4448-957c-1a96f9d8cad3@github.com>
References: <o_MnHDbIknOh9iQTaUk05TigChRCZAehVHzz8_RHXOo=.87ff0f18-2250-427c-844c-81c59b38d7f3@github.com>
 <8eobdmVaHGFsFgaL6oyv193K0AKZcJ2EDmN1JPJyRyY=.490d48e5-6033-4de5-b455-dbd8affcd1b7@github.com>
 <tv3agevGXrOEOYakLvPERGOeaTMSI9Gc62NZ48mcquY=.2e47afdc-2b6d-46b3-ad06-03c9c2fa3b3e@github.com>
 <3C2MgF_7g8dIAAwmHVMFT6kyzuFZRcWec0TseTNlJs0=.f5cba3e2-dfd2-4f6f-b400-da80601a259b@github.com>
 <zY1XMji0UOPWASuKiyLKpe92OB22bLR-1I7iLBLAGp8=.7963df2e-3bf5-4448-957c-1a96f9d8cad3@github.com>
Message-ID: <NfzPXsIUE1-lVw6wFXYhZa1mpQvpTBafRkBvLm10R4g=.ecfd8b89-5e21-4526-a637-d8af6df479a5@github.com>

On Thu, 27 Oct 2022 09:27:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > Can you also please test it works ok (or atleast not regress) for other selection mode FILES_ONLY, DIRECTORIES_ONLY in the test?
> > 
> > 
> > Verified for file selection mode of `DIRECTORIES_ONLY`, test passed for all LAFs.
> > In case of selection mode of `FILES_ONLY`, test is failing for all LAFs. The reason behind this is we are trying to select `Directory `when selection mode is set to `FILES_ONLY`.
> 
> I guess you can see in folders where you have only files...Testwise, maybe use File.createTempFile for creating files and see..

I have checked manually, it is possible to select single or multiple file when selection mode is `FILES_ONLY` for all LAFs. 

I will try to update test file.

-------------

PR: https://git.openjdk.org/jdk/pull/10866


From asemenov at openjdk.org  Thu Oct 27 11:22:31 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 27 Oct 2022 11:22:31 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: <LwmEav6LCJh5Fb3p6bt9oka7KS3cVXXF2i6wvsKLUA8=.0e002da5-0ce9-41f7-a542-801be5bc4ce8@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 dfuchs at openjdk.org  Thu Oct 27 11:28:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Oct 2022 11:28:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
 <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
 <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>
Message-ID: <JMZ_-77lTdemvfC3K54z8FRMXEuYGV44PHhjhPBnZFk=.e732f51f-7d8c-4ad0-980f-6e93946d43b8@github.com>

On Thu, 27 Oct 2022 09:17:29 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Having?unnamed local?variables[^1] would?probably be?best for?this.
>> 
>> [^1]: https://openjdk.org/jeps/8294349
>
> How about `_unused` or `_unused1`, `_unused2` then in the meantime?

I'd be happy to make the change. Let's wait to see if anybody has a better naming suggestion.

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From prr at openjdk.org  Thu Oct 27 15:00:10 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 27 Oct 2022 15:00:10 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors [v3]
In-Reply-To: <ZmHtPJKur7MkameLduqQk-sjbaHats_UbQjn9v3kC0w=.cbd5f716-1795-4acd-b426-c01c2e8b5af0@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
 <ZmHtPJKur7MkameLduqQk-sjbaHats_UbQjn9v3kC0w=.cbd5f716-1795-4acd-b426-c01c2e8b5af0@github.com>
Message-ID: <TXkfeFBpZtPACXyW5Ks7JAjdtwL48tkrtN08-SLITFo=.61493761-5331-4a0f-b68d-2bdc5cc70389@github.com>

On Wed, 26 Oct 2022 10:48:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert typo

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10740


From aivanov at openjdk.org  Thu Oct 27 16:13:23 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 27 Oct 2022 16:13:23 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors [v3]
In-Reply-To: <ZmHtPJKur7MkameLduqQk-sjbaHats_UbQjn9v3kC0w=.cbd5f716-1795-4acd-b426-c01c2e8b5af0@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
 <ZmHtPJKur7MkameLduqQk-sjbaHats_UbQjn9v3kC0w=.cbd5f716-1795-4acd-b426-c01c2e8b5af0@github.com>
Message-ID: <s3m-PoBUEkEuLe5e0KFo9RZUMQifPFVbWE-cUz86Buw=.7778cc40-6c83-4390-9f52-1e4a703302eb@github.com>

On Wed, 26 Oct 2022 10:48:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert typo

src/java.desktop/share/classes/javax/swing/border/MatteBorder.java line 79:

> 77:      * @param matteColor the color rendered for the border
> 78:      * @throws {@code NullPointerException} if {@code borderInsets}
> 79:      *          is {@code null}

Would `@inheritDoc` work in this case? The message is the same as in its super class.
Suggestion:

     * @throws {@inheritDoc}

-------------

PR: https://git.openjdk.org/jdk/pull/10740


From joehw at openjdk.org  Thu Oct 27 17:22:26 2022
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 27 Oct 2022 17:22:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <tBh10CShbGx1KeYJZdDhGauxqCtbde8z-jJzR3hLQy8=.98f3f0b3-a2e4-4b90-b91a-a2d3e7fb4727@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

Hi Daniel, if it's not a major improvement, we'd like to keep the java.xml module at the JDK 8 code level. Can we remove the 'var' usage in a few java.xml classes?

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From dfuchs at openjdk.org  Thu Oct 27 17:38:24 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Oct 2022 17:38:24 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <tBh10CShbGx1KeYJZdDhGauxqCtbde8z-jJzR3hLQy8=.98f3f0b3-a2e4-4b90-b91a-a2d3e7fb4727@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <tBh10CShbGx1KeYJZdDhGauxqCtbde8z-jJzR3hLQy8=.98f3f0b3-a2e4-4b90-b91a-a2d3e7fb4727@github.com>
Message-ID: <9IeUomzE_jMjeWk2jrzY5-1W8n2JhijVyCPO2mQJrtI=.82a69e23-ccae-43a4-988c-5de54e4aad07@github.com>

On Thu, 27 Oct 2022 17:20:04 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Hi Daniel, if it's not a major improvement, we'd like to keep the java.xml module at the JDK 8 code level. Can we remove the 'var' usage in a few java.xml classes?

No problem - I will make this change when we have settled on a name for the variable `tmp` vs `_unused` (proposed by Michael).

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From aturbanov at openjdk.org  Thu Oct 27 17:54:31 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 27 Oct 2022 17:54:31 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <o0OnSoBYaxEbOk2xXfpzH5EDpT_EZhI0ghk7XjEpg14=.de307c7f-daaa-49fb-96d2-9b7f36ca30bb@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

test/jdk/java/net/URL/URLFromURITest.java line 268:

> 266:             // - URL authority is null or empty depending on the protocol
> 267:             //   and on whether the URL is hierarchical or not.
> 268:             if (isFileBased  && authority == null) {

Suggestion:

            if (isFileBased && authority == null) {

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From dfuchs at openjdk.org  Thu Oct 27 18:08:34 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Oct 2022 18:08:34 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <o0OnSoBYaxEbOk2xXfpzH5EDpT_EZhI0ghk7XjEpg14=.de307c7f-daaa-49fb-96d2-9b7f36ca30bb@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <o0OnSoBYaxEbOk2xXfpzH5EDpT_EZhI0ghk7XjEpg14=.de307c7f-daaa-49fb-96d2-9b7f36ca30bb@github.com>
Message-ID: <VjAEpSLjpUPyUQcaxoONq7Y6zCqP7glgi8QikqXkakI=.689b7ff2-596a-4a87-ba02-b9c1f1c15c64@github.com>

On Thu, 27 Oct 2022 17:50:37 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> test/jdk/java/net/URL/URLFromURITest.java line 268:
> 
>> 266:             // - URL authority is null or empty depending on the protocol
>> 267:             //   and on whether the URL is hierarchical or not.
>> 268:             if (isFileBased  && authority == null) {
> 
> Suggestion:
> 
>             if (isFileBased && authority == null) {

Thanks - I will apply this suggestion.

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From aturbanov at openjdk.org  Thu Oct 27 19:03:34 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 27 Oct 2022 19:03:34 GMT
Subject: Integrated: 8295323: Unnecessary HashTable usage in StyleSheet
In-Reply-To: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
References: <_bCtfNKiq4bp595w1PBfN74xfoobhAVYx58ntgrVGug=.bc7397a2-9b9e-44e8-b5f2-4058828f0c50@github.com>
Message-ID: <kULqBynw1q1exn43F7joSjHOq6_02Xxs5j6obbzERMM=.d7809c46-59dd-47ea-934b-37ebda9dbfd9@github.com>

On Sat, 1 Oct 2022 16:53:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Hashtable was used only from single thread. And only non-null key/values added to it. We can safely replace it with HashSet.

This pull request has now been integrated.

Changeset: 907d5833
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/907d583376dfab269ea25a6c036e390f3484065e
Stats:     18 lines in 1 file changed: 0 ins; 2 del; 16 mod

8295323: Unnecessary HashTable usage in StyleSheet

Reviewed-by: aivanov, prr

-------------

PR: https://git.openjdk.org/jdk/pull/10522


From aivanov at openjdk.org  Thu Oct 27 19:47:53 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 27 Oct 2022 19:47:53 GMT
Subject: RFR: 8282958: Rendering issues of borders,
 TextFields on Windows High-DPI systems
In-Reply-To: <K017iqdcECzNK9JlZU_Li549-fSzgqYdmg3reHdhg3A=.0dbb6742-95cd-4886-a94f-4b02781165e5@github.com>
References: <K017iqdcECzNK9JlZU_Li549-fSzgqYdmg3reHdhg3A=.0dbb6742-95cd-4886-a94f-4b02781165e5@github.com>
Message-ID: <Ge9W5T56hGPqbxlTCKurmP-Rug19cEVOSdG1-UQCqe8=.e8906001-754a-4c9f-8932-3ddf12cef22d@github.com>

On Wed, 12 Oct 2022 16:41:52 GMT, Rajat Mahajan <duke at openjdk.org> wrote:

> This fix is based on a similar approach as described here  https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648.
> We rescale the line border to render the Textfield border correctly, so that all sides of the Textfield border are of same thickness.

Looks good to me.

test/jdk/javax/swing/border/LineBorder/ScaledLineBorderTest.java line 259:

> 257: 
> 258:     private static void showFrame(JComponent content) {
> 259:         JFrame frame = new JFrame("Scaled Etched Border Test");

Suggestion:

        JFrame frame = new JFrame("Scaled Line Border Test");

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10681


From duke at openjdk.org  Thu Oct 27 22:19:26 2022
From: duke at openjdk.org (Rob Leland)
Date: Thu, 27 Oct 2022 22:19:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <RaFx3blIdoBXwF7RjK7TFIuqHSxTNk9-C94QaPKmEeg=.118063ff-f956-427a-a2f6-a87fc85dc601@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

Why not go ahead and replace all the usages with fromURI(} to start  with.where possible ?

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From serb at openjdk.org  Thu Oct 27 22:24:17 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Oct 2022 22:24:17 GMT
Subject: RFR: 8295812: Skip the "half float" support in LittleCMS during the
 build
Message-ID: <F9XVuZZYovezop61nzuHLN6OKXlzp4hv4cme84f2aRg=.7966ac12-b6a3-49d1-bbfc-0fefccb5ba90@github.com>

The Java2d do not use "half" float in the image layouts, so we can disable it in the LittleCMS library during the build. It is possible to do using [this](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/liblcms/lcms2.h#L85) public option:


// Uncomment to get rid of the tables for "half" float support
// #define CMS_NO_HALF_SUPPORT 1


This change cuts not only the unused by java2d functions but also [such](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/native/liblcms/cmshalf.c#L63) tables.

The size of liblcms decreased by 20 kB on Linux(536024 vs 515152) and 15 kB on windows(246784 vs 231424). On macOS the  win is only 300 bytes.

-------------

Commit messages:
 - 8295812: Skip the "half float" support in LittleCMS during the build

Changes: https://git.openjdk.org/jdk/pull/10830/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10830&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295812
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10830.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10830/head:pull/10830

PR: https://git.openjdk.org/jdk/pull/10830


From duke at openjdk.org  Thu Oct 27 22:31:19 2022
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Thu, 27 Oct 2022 22:31:19 GMT
Subject: RFR: JDK-8252075: Documentation error in LayoutManager2 interface
Message-ID: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>

Updated the documentation with proper meaningful message for better understanding.

-------------

Commit messages:
 - JDK-8252075 : Documentation error in LayoutManager2 interface

Changes: https://git.openjdk.org/jdk/pull/10549/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10549&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8252075
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10549.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10549/head:pull/10549

PR: https://git.openjdk.org/jdk/pull/10549


From duke at openjdk.org  Thu Oct 27 22:31:19 2022
From: duke at openjdk.org (SWinxy)
Date: Thu, 27 Oct 2022 22:31:19 GMT
Subject: RFR: JDK-8252075: Documentation error in LayoutManager2 interface
In-Reply-To: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
References: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
Message-ID: <E9KF3Mv7rBXqCURX7_rDpLORbJYGWdJ-T-Qb7NYRkH0=.3ea83704-9205-405e-9218-ed41bf3d0fb6@github.com>

On Tue, 4 Oct 2022 07:00:04 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> wrote:

> Updated the documentation with proper meaningful message for better understanding.

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

@Renjithkannath you need to begin the comment with `/covered`. Could you also change the vague title in JBS to something more descriptive? Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10549


From serb at openjdk.org  Thu Oct 27 22:45:28 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Oct 2022 22:45:28 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors [v3]
In-Reply-To: <s3m-PoBUEkEuLe5e0KFo9RZUMQifPFVbWE-cUz86Buw=.7778cc40-6c83-4390-9f52-1e4a703302eb@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
 <ZmHtPJKur7MkameLduqQk-sjbaHats_UbQjn9v3kC0w=.cbd5f716-1795-4acd-b426-c01c2e8b5af0@github.com>
 <s3m-PoBUEkEuLe5e0KFo9RZUMQifPFVbWE-cUz86Buw=.7778cc40-6c83-4390-9f52-1e4a703302eb@github.com>
Message-ID: <rY5OgbZ8LAUzdYsQTgmymweUJ_y3p1Lprf0NUaaO7xQ=.788b361a-e4a9-4cdb-b648-b4b30ec11811@github.com>

On Thu, 27 Oct 2022 16:05:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert typo
>
> src/java.desktop/share/classes/javax/swing/border/MatteBorder.java line 79:
> 
>> 77:      * @param matteColor the color rendered for the border
>> 78:      * @throws {@code NullPointerException} if {@code borderInsets}
>> 79:      *          is {@code null}
> 
> Would `@inheritDoc` work in this case? The message is the same as in its super class.
> Suggestion:
> 
>      * @throws {@inheritDoc}

If we updated the parent class should not we do the same for all upto AbstractBorder?

-------------

PR: https://git.openjdk.org/jdk/pull/10740


From serb at openjdk.org  Thu Oct 27 22:49:04 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Oct 2022 22:49:04 GMT
Subject: RFR: 8282463: javax/sound/sampled/Clip/DataPusherThreadCheck.java
 fails
In-Reply-To: <myMXcksU12EK7xpYDTIW7PWDv2Gl1pftNHFeQzGrU8Q=.79d47610-3fb8-416a-961d-dc22f6c92480@github.com>
References: <myMXcksU12EK7xpYDTIW7PWDv2Gl1pftNHFeQzGrU8Q=.79d47610-3fb8-416a-961d-dc22f6c92480@github.com>
Message-ID: <9dNRD259pbZdd5viVrz4HKLyzRbBjYUhhmQyLTA7wP8=.2ee9df51-6da3-4e88-8c72-5f73c10800d0@github.com>

On Sat, 15 Oct 2022 13:03:26 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Test failed on Ubuntu, because both implementations of `MixerProvider` have no devices:
> 1. com.sun.media.sound.DirectAudioDeviceProvider#nGetNumDevices returns `0`
>  ![DirectAudioDeviceProvider init](https://user-images.githubusercontent.com/741251/195988216-aa86da0f-739b-433f-87e2-86c2d6904a0d.png)
> 2. com.sun.media.sound.PortMixerProvider#nGetNumDevices returns `0`
>  ![PortMixerProvider init](https://user-images.githubusercontent.com/741251/195988239-59678e0c-be7b-43ff-b02a-9abb2392e8f9.png)
> 
> 
> It leads to `javax.sound.sampled.spi.MixerProvider#getMixerInfo` returns empty array.
> ![AudioSystem getMixedInfoList](https://user-images.githubusercontent.com/741251/195988266-1656e6d3-de4a-4e53-a613-415f60075726.png)
> 
> And DataPusher thread is not created, because of AudioSystem.isLineSupported returns false in the method `com.sun.media.sound.JavaSoundAudioClip#createSourceDataLine`.
> I propose to perform the same check in test code and skip it.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10717


From serb at openjdk.org  Thu Oct 27 23:01:30 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Oct 2022 23:01:30 GMT
Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and
 radio button with GTK LAF for bug4314194. [v2]
In-Reply-To: <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
References: <ZDowzVwzGP3Tp6NwubhgnSWa_ZToy1-a63pnm3lU3T4=.4709c578-2053-4e93-ae3d-015b58a0d820@github.com>
 <HE8cJ9al1-9bFdbFqTZxhhq9AFrPV-IdQrI4t9wB_1Y=.ac721ba8-7b0a-4823-85b6-c52bb29673f3@github.com>
Message-ID: <32Y1LH9-ZiTRp_DK9nPK4hp3ncR4o4YobG2ySV9ayNU=.385056e5-e809-4d74-8149-372f58b79a92@github.com>

On Wed, 19 Oct 2022 07:13:44 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF.
>> 
>> The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. 
>> 
>> Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - ProblemList.txt file merge resolved
>  - 8295006 entry removed from problem lists
>  - Fix for disabled checkbox and radiobutton colored text

The similar fix https://github.com/openjdk/jdk/pull/9900, as in this one we should check is it necessary to support the property expected by the test or the property from the "Nimbus list" above should be supported.

-------------

PR: https://git.openjdk.org/jdk/pull/10755


From cjplummer at openjdk.org  Fri Oct 28 00:55:44 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 28 Oct 2022 00:55:44 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com>
Message-ID: <DIScQIcbKFsercPkoaABYXSmJznKrSSnJwhL-kJDSDU=.5be8456a-ce87-4b56-83f9-b397e2785402@github.com>

On Fri, 7 Oct 2022 12:51:26 GMT, Alan Bateman <alanb 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
>
> src/java.se/share/data/jdwp/jdwp.spec line 101:
> 
>> 99:         "<a href=../../api/java.base/java/lang/Thread.html#platform-threads>platform thread</a> "
>> 100:         "in the target VM. This includes platform threads created with the Thread "
>> 101:         "API and all native threads attached to the target VM with JNI code."
> 
> The spec for the JDWP AllThreads command was significantly reworded in Java 19 so this is where this typo crept in. We have JDK-8294672 tracking it to fix for Java 20, maybe you should take it?

Since this PR has gone stale, I'll be fixing this typo in jdwp.spec via [JDK-8294672](https://bugs.openjdk.org/browse/JDK-8294672).

-------------

PR: https://git.openjdk.org/jdk/pull/10029


From psadhukhan at openjdk.org  Fri Oct 28 03:32:18 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Oct 2022 03:32:18 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v9]
In-Reply-To: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
Message-ID: <Z5aH4dx5JUWRlpc8NUZnIoBR1ewhTq2B4IEvlP9E2Ms=.995d0d96-c397-4395-881c-e42a34a86a74@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.

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Review fix
 - Review fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10409/files
  - new: https://git.openjdk.org/jdk/pull/10409/files/89b9e86c..fce8c56b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10409&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10409&range=07-08

  Stats: 16 lines in 1 file changed: 6 ins; 3 del; 7 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 psadhukhan at openjdk.org  Fri Oct 28 03:35:21 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Oct 2022 03:35:21 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v9]
In-Reply-To: <Z5aH4dx5JUWRlpc8NUZnIoBR1ewhTq2B4IEvlP9E2Ms=.995d0d96-c397-4395-881c-e42a34a86a74@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <Z5aH4dx5JUWRlpc8NUZnIoBR1ewhTq2B4IEvlP9E2Ms=.995d0d96-c397-4395-881c-e42a34a86a74@github.com>
Message-ID: <N0RGrT9dWbIC7cz3TiEV_lo_5PCwpxyariXaMpjv6mk=.022317e0-387a-4ab3-81ec-d04c8a8e04c7@github.com>

On Fri, 28 Oct 2022 03:32:18 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.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review fix
>  - Review fix

I guess it's good idea to add your test into jtreg..

-------------

PR: https://git.openjdk.org/jdk/pull/10409


From psadhukhan at openjdk.org  Fri Oct 28 03:42:05 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Oct 2022 03:42:05 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors [v4]
In-Reply-To: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
Message-ID: <nya7UqvvVSkJ2ORNUwGpI0BFKkDFX7vDqYjQQRkvZtk=.864dadcb-aa60-47f8-bc45-89bcee55142d@github.com>

> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10740/files
  - new: https://git.openjdk.org/jdk/pull/10740/files/389c7c4c..391bf7f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10740&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10740&range=02-03

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10740.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10740/head:pull/10740

PR: https://git.openjdk.org/jdk/pull/10740


From psadhukhan at openjdk.org  Fri Oct 28 03:42:07 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Oct 2022 03:42:07 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors [v3]
In-Reply-To: <rY5OgbZ8LAUzdYsQTgmymweUJ_y3p1Lprf0NUaaO7xQ=.788b361a-e4a9-4cdb-b648-b4b30ec11811@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
 <ZmHtPJKur7MkameLduqQk-sjbaHats_UbQjn9v3kC0w=.cbd5f716-1795-4acd-b426-c01c2e8b5af0@github.com>
 <s3m-PoBUEkEuLe5e0KFo9RZUMQifPFVbWE-cUz86Buw=.7778cc40-6c83-4390-9f52-1e4a703302eb@github.com>
 <rY5OgbZ8LAUzdYsQTgmymweUJ_y3p1Lprf0NUaaO7xQ=.788b361a-e4a9-4cdb-b648-b4b30ec11811@github.com>
Message-ID: <_jOjEr107uJK3dxdzFFxUDRtfXjQby20E1UWPcXhGFg=.67e6b9c4-2446-4bb4-b932-02a540fc5454@github.com>

On Thu, 27 Oct 2022 22:41:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/border/MatteBorder.java line 79:
>> 
>>> 77:      * @param matteColor the color rendered for the border
>>> 78:      * @throws {@code NullPointerException} if {@code borderInsets}
>>> 79:      *          is {@code null}
>> 
>> Would `@inheritDoc` work in this case? The message is the same as in its super class.
>> Suggestion:
>> 
>>      * @throws {@inheritDoc}
>
> If we updated the parent class should not we do the same for all upto AbstractBorder?

I guess we should..updated..

-------------

PR: https://git.openjdk.org/jdk/pull/10740


From tr at openjdk.org  Fri Oct 28 04:34:20 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 28 Oct 2022 04:34:20 GMT
Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException
In-Reply-To: <ABJ79VQJ9Z_V9wB6JJTykhwJlGXac6aKHoe0Tdc5PNI=.bba61627-c1bc-40b0-a039-ac1bf918d22c@github.com>
References: <ABJ79VQJ9Z_V9wB6JJTykhwJlGXac6aKHoe0Tdc5PNI=.bba61627-c1bc-40b0-a039-ac1bf918d22c@github.com>
Message-ID: <mM5AbyBavx7OXnAuWIrxULgj-bzckNme84oHvZ0nFjI=.605a4916-7860-457a-9122-94f685dbb936@github.com>

On Wed, 26 Oct 2022 10:28:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> If getDefaultEditor() is called before the JTable model is setup, it results in NPE.
> 
> This is because when JTable sets its model, which ends up firing a table changed event. The testcase is listening for tableChanged events and querying the editor. But the editor isn't installed until after the model is set which results in NPE.
> Fix is to ensure initializeLocalVars() which initializes default editor is setup before JTable sets its model.
> 
> No regression is observed in jtreg/jck testsuite with this change.

Marked as reviewed by tr (Committer).

The fix looks good to me and is working fine.

-------------

PR: https://git.openjdk.org/jdk/pull/10871


From duke at openjdk.org  Fri Oct 28 10:33:59 2022
From: duke at openjdk.org (ravi gupta)
Date: Fri, 28 Oct 2022 10:33:59 GMT
Subject: RFR: 8295774 : Write a test to verify that List Item selection events.
Message-ID: <FSyEfibGCwPDFUHTXYBCLWKRi1hrVLgcdiArJaWVL3M=.4ab0216a-d9f5-41e3-9f55-8eddbc7dcdb1@github.com>

This testcase verify that List Item selection via mouse/keys generates ItemEvent/ActionEvent appropriately.

a. Single click on the list generate ItemEvent and double click on item generates ActionEvent.
b. UP/DOWN keys on the list generate ItemEvent and enter key on item generates ActionEvent.

Testing:
Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

-------------

Commit messages:
 - 8295774 : Write a test to verify that List Item selection events.

Changes: https://git.openjdk.org/jdk/pull/10899/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10899&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295774
  Stats: 193 lines in 1 file changed: 193 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10899.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10899/head:pull/10899

PR: https://git.openjdk.org/jdk/pull/10899


From erikj at openjdk.org  Fri Oct 28 13:46:25 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 28 Oct 2022 13:46:25 GMT
Subject: RFR: 8295812: Skip the "half float" support in LittleCMS during
 the build
In-Reply-To: <F9XVuZZYovezop61nzuHLN6OKXlzp4hv4cme84f2aRg=.7966ac12-b6a3-49d1-bbfc-0fefccb5ba90@github.com>
References: <F9XVuZZYovezop61nzuHLN6OKXlzp4hv4cme84f2aRg=.7966ac12-b6a3-49d1-bbfc-0fefccb5ba90@github.com>
Message-ID: <fzPiKkEBnm3Kuq7-txl6edDTKjclS6W6_-ps92w9MHk=.d6c456ad-051a-4a04-9170-b4f73b8c3379@github.com>

On Sun, 23 Oct 2022 20:10:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The Java2d do not use "half" float in the image layouts, so we can disable it in the LittleCMS library during the build. It is possible to do using [this](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/liblcms/lcms2.h#L85) public option:
> 
> 
> // Uncomment to get rid of the tables for "half" float support
> // #define CMS_NO_HALF_SUPPORT 1
> 
> 
> This change cuts not only the unused by java2d functions but also [such](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/native/liblcms/cmshalf.c#L63) tables.
> 
> The size of liblcms decreased by 20 kB on Linux(536024 vs 515152) and 15 kB on windows(246784 vs 231424). On macOS the  win is only 300 bytes.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10830


From dfuchs at openjdk.org  Fri Oct 28 14:54:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Oct 2022 14:54:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
 - Merge branch 'master' into deprecate-url-ctor-8294241
 - Fix whitespace issues
 - 8294241

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10874/files
  - new: https://git.openjdk.org/jdk/pull/10874/files/25a0188c..fd4ca287

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=00-01

  Stats: 25761 lines in 392 files changed: 1581 ins; 23649 del; 531 mod
  Patch: https://git.openjdk.org/jdk/pull/10874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874

PR: https://git.openjdk.org/jdk/pull/10874


From aivanov at openjdk.org  Fri Oct 28 15:21:23 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 28 Oct 2022 15:21:23 GMT
Subject: RFR: JDK-8252075: Documentation error in LayoutManager2 interface
In-Reply-To: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
References: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
Message-ID: <lOFJoBXRwxw8AHunxKO0hu0yPkjnfQ7vacMJE8529p8=.f28ed595-d99c-4d4d-97a9-12a11fac7bcc@github.com>

On Tue, 4 Oct 2022 07:00:04 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> wrote:

> Updated the documentation with proper meaningful message for better understanding.

This looks good.

Let's mark up `{@code Container}s` and `{@code LayoutManager}` in the description like it's done in `LayoutManager` interface. https://github.com/openjdk/jdk/blob/3789983e89c9de252ef546a1b98a732a7d066650/src/java.desktop/share/classes/java/awt/LayoutManager.java#L28-L33

Please update the copyright year.

-------------

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10549


From duke at openjdk.org  Fri Oct 28 16:00:10 2022
From: duke at openjdk.org (Rajat Mahajan)
Date: Fri, 28 Oct 2022 16:00:10 GMT
Subject: RFR: 8282958: Rendering issues of borders,
 TextFields on Windows High-DPI systems [v2]
In-Reply-To: <K017iqdcECzNK9JlZU_Li549-fSzgqYdmg3reHdhg3A=.0dbb6742-95cd-4886-a94f-4b02781165e5@github.com>
References: <K017iqdcECzNK9JlZU_Li549-fSzgqYdmg3reHdhg3A=.0dbb6742-95cd-4886-a94f-4b02781165e5@github.com>
Message-ID: <JaPmig_KaRjsE2VAKtKzWFHd5EQvUisssShkSSP2KtA=.38a47916-21db-4a2f-89f6-a603e84f7423@github.com>

> This fix is based on a similar approach as described here  https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648.
> We rescale the line border to render the Textfield border correctly, so that all sides of the Textfield border are of same thickness.

Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/javax/swing/border/LineBorder/ScaledLineBorderTest.java
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10681/files
  - new: https://git.openjdk.org/jdk/pull/10681/files/4fca8476..0e8fb4e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10681&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10681&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10681.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10681/head:pull/10681

PR: https://git.openjdk.org/jdk/pull/10681


From aivanov at openjdk.org  Fri Oct 28 16:41:21 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 28 Oct 2022 16:41:21 GMT
Subject: RFR: 8282958: Rendering issues of borders,
 TextFields on Windows High-DPI systems [v2]
In-Reply-To: <JaPmig_KaRjsE2VAKtKzWFHd5EQvUisssShkSSP2KtA=.38a47916-21db-4a2f-89f6-a603e84f7423@github.com>
References: <K017iqdcECzNK9JlZU_Li549-fSzgqYdmg3reHdhg3A=.0dbb6742-95cd-4886-a94f-4b02781165e5@github.com>
 <JaPmig_KaRjsE2VAKtKzWFHd5EQvUisssShkSSP2KtA=.38a47916-21db-4a2f-89f6-a603e84f7423@github.com>
Message-ID: <J-P_QzRGNGQXaHIooVrxlXgSSB7jTAHURmN79z1ZSeA=.55e99bed-bb43-40e9-82a6-bc6f527ece82@github.com>

On Fri, 28 Oct 2022 16:00:10 GMT, Rajat Mahajan <duke at openjdk.org> wrote:

>> This fix is based on a similar approach as described here  https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648.
>> We rescale the line border to render the Textfield border correctly, so that all sides of the Textfield border are of same thickness.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/javax/swing/border/LineBorder/ScaledLineBorderTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10681


From joehw at openjdk.org  Fri Oct 28 16:43:23 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 28 Oct 2022 16:43:23 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <4ThJRTvihtvhX_xBjaCTHOL4w-VHDJuXTUkvtfRVPvY=.ad69332e-e7a2-43fc-9893-3a27f7ca4d5c@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

Thanks Daniel. The java.xml part looks good to me.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10874


From aivanov at openjdk.org  Fri Oct 28 17:45:31 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 28 Oct 2022 17:45:31 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors [v4]
In-Reply-To: <nya7UqvvVSkJ2ORNUwGpI0BFKkDFX7vDqYjQQRkvZtk=.864dadcb-aa60-47f8-bc45-89bcee55142d@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
 <nya7UqvvVSkJ2ORNUwGpI0BFKkDFX7vDqYjQQRkvZtk=.864dadcb-aa60-47f8-bc45-89bcee55142d@github.com>
Message-ID: <5R_pNlw1UpRTUSIN8BKZOCSw4IX6oKEdSiK-bpk8pvU=.5212eef8-e559-42f0-9834-c048dc77739e@github.com>

On Fri, 28 Oct 2022 03:42:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

In addition to the comments in the code, could you please update the copyright year and remove `Rectangle` from imports in `EmptyBorder`?

src/java.desktop/share/classes/javax/swing/border/AbstractBorder.java line 89:

> 87:      * @return the <code>insets</code> object
> 88:      * @throws {@code NullPointerException} if {@code insets}
> 89:      *         is {@code null}

This does not compile, `@throws` expects a ?plain? class name, monospaced font is applied automatically to `NullPointerException`.

src/java.desktop/share/classes/javax/swing/border/AbstractBorder.java line 91:

> 89:      *         is {@code null}
> 90:      */
> 91:     public Insets getBorderInsets(Component c, Insets insets) {

Should the specification be clarified here? The method `getBorderInsets(Component c)` above says the fields of the returned `Insets` object are set to 0. The implementation of `getBorderInsets(Component c, Insets insets)` sets the fields of `Insets` to zero ? because it has no other insets.

Should the specification state that this *default implementation* sets the fields of the `Insets` object to zero?

src/java.desktop/share/classes/javax/swing/border/EmptyBorder.java line 108:

> 106:      * @param insets the object to be reinitialized
> 107:      * @throws {@code NullPointerException} if {@code insets}
> 108:      *          is {@code null}

Suggestion:

     * @throws NullPointerException {@inheritDoc}

I suggest using `{@inheritDoc}` to copy the exception description from the super class for both `EmptyBorder` and `MatteBorder`. (It cannot be used for constructors though.)

-------------

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10740


From aivanov at openjdk.org  Fri Oct 28 17:54:17 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 28 Oct 2022 17:54:17 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors [v4]
In-Reply-To: <nya7UqvvVSkJ2ORNUwGpI0BFKkDFX7vDqYjQQRkvZtk=.864dadcb-aa60-47f8-bc45-89bcee55142d@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
 <nya7UqvvVSkJ2ORNUwGpI0BFKkDFX7vDqYjQQRkvZtk=.864dadcb-aa60-47f8-bc45-89bcee55142d@github.com>
Message-ID: <pWwHBKAOqtr0tnYSP3zPWswKe2Jo1qsBgMS1GPshSa4=.9259e3b6-4f25-44fe-b7bd-4887c7de05fe@github.com>

On Fri, 28 Oct 2022 03:42:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

Does it make sense to update the subject to _?Document NPE for passing null insets?_ or a similar? It would carry more meaning. At this time, ?underfined behavior? sounds frightening.

-------------

PR: https://git.openjdk.org/jdk/pull/10740


From jjg at openjdk.org  Sat Oct 29 00:05:32 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 29 Oct 2022 00:05:32 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <r_58JHoKmjUmSoO1PboxKdQoV8yJ3nwjDn_KIIr5o7k=.13c13918-f42e-4f5b-9557-6894e2b301fb@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

The changes in `jdk.compiler` and `jdk.javadoc` seem innocuous enough.  Because of the bootstrap issue/latency, we'll have to wait before we can update to non-deprecated code.

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From prr at openjdk.org  Sat Oct 29 01:24:30 2022
From: prr at openjdk.org (Phil Race)
Date: Sat, 29 Oct 2022 01:24:30 GMT
Subject: RFR: 8295812: Skip the "half float" support in LittleCMS during
 the build
In-Reply-To: <F9XVuZZYovezop61nzuHLN6OKXlzp4hv4cme84f2aRg=.7966ac12-b6a3-49d1-bbfc-0fefccb5ba90@github.com>
References: <F9XVuZZYovezop61nzuHLN6OKXlzp4hv4cme84f2aRg=.7966ac12-b6a3-49d1-bbfc-0fefccb5ba90@github.com>
Message-ID: <5UbDD-wSvZrHljXyriangpq6bHln-qdNtTucLF2omA0=.fdde0d6e-7377-4813-92b3-37fe67cb06dd@github.com>

On Sun, 23 Oct 2022 20:10:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The Java2d do not use "half" float in the image layouts, so we can disable it in the LittleCMS library during the build. It is possible to do using [this](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/liblcms/lcms2.h#L85) public option:
> 
> 
> // Uncomment to get rid of the tables for "half" float support
> // #define CMS_NO_HALF_SUPPORT 1
> 
> 
> This change cuts not only the unused by java2d functions but also [such](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/native/liblcms/cmshalf.c#L63) tables.
> 
> The size of liblcms decreased by 20 kB on Linux(536024 vs 515152) and 15 kB on windows(246784 vs 231424). On macOS the  win is only 300 bytes.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10830


From dnguyen at openjdk.org  Sat Oct 29 01:51:33 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Sat, 29 Oct 2022 01:51:33 GMT
Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException
In-Reply-To: <ABJ79VQJ9Z_V9wB6JJTykhwJlGXac6aKHoe0Tdc5PNI=.bba61627-c1bc-40b0-a039-ac1bf918d22c@github.com>
References: <ABJ79VQJ9Z_V9wB6JJTykhwJlGXac6aKHoe0Tdc5PNI=.bba61627-c1bc-40b0-a039-ac1bf918d22c@github.com>
Message-ID: <rqJNDkyLjl9lSOHHFDDFIxIwqvWJkp6Pko8bQ8-ucyI=.f482d9df-dfa8-4775-b48f-da6ae7312e0c@github.com>

On Wed, 26 Oct 2022 10:28:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> If getDefaultEditor() is called before the JTable model is setup, it results in NPE.
> 
> This is because when JTable sets its model, which ends up firing a table changed event. The testcase is listening for tableChanged events and querying the editor. But the editor isn't installed until after the model is set which results in NPE.
> Fix is to ensure initializeLocalVars() which initializes default editor is setup before JTable sets its model.
> 
> No regression is observed in jtreg/jck testsuite with this change.

The fix makes sense. Applied the fix and tested on my end. Looks good to me.

-------------

Marked as reviewed by dnguyen (Author).

PR: https://git.openjdk.org/jdk/pull/10871


From prr at openjdk.org  Sat Oct 29 02:13:26 2022
From: prr at openjdk.org (Phil Race)
Date: Sat, 29 Oct 2022 02:13:26 GMT
Subject: RFR: 8282463: javax/sound/sampled/Clip/DataPusherThreadCheck.java
 fails
In-Reply-To: <myMXcksU12EK7xpYDTIW7PWDv2Gl1pftNHFeQzGrU8Q=.79d47610-3fb8-416a-961d-dc22f6c92480@github.com>
References: <myMXcksU12EK7xpYDTIW7PWDv2Gl1pftNHFeQzGrU8Q=.79d47610-3fb8-416a-961d-dc22f6c92480@github.com>
Message-ID: <H1wV3L0ElzImToRH3f3rJGeY-RDXhb2LakLpHzLLXHI=.2419649f-3a92-4df5-b11c-b9faf99fa494@github.com>

On Sat, 15 Oct 2022 13:03:26 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Test failed on Ubuntu, because both implementations of `MixerProvider` have no devices:
> 1. com.sun.media.sound.DirectAudioDeviceProvider#nGetNumDevices returns `0`
>  ![DirectAudioDeviceProvider init](https://user-images.githubusercontent.com/741251/195988216-aa86da0f-739b-433f-87e2-86c2d6904a0d.png)
> 2. com.sun.media.sound.PortMixerProvider#nGetNumDevices returns `0`
>  ![PortMixerProvider init](https://user-images.githubusercontent.com/741251/195988239-59678e0c-be7b-43ff-b02a-9abb2392e8f9.png)
> 
> 
> It leads to `javax.sound.sampled.spi.MixerProvider#getMixerInfo` returns empty array.
> ![AudioSystem getMixedInfoList](https://user-images.githubusercontent.com/741251/195988266-1656e6d3-de4a-4e53-a613-415f60075726.png)
> 
> And DataPusher thread is not created, because of AudioSystem.isLineSupported returns false in the method `com.sun.media.sound.JavaSoundAudioClip#createSourceDataLine`.
> I propose to perform the same check in test code and skip it.

I remain un-convinced this has got to the bottom of the original reason for the bug but OK to push this and see what happens.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10717


From jpai at openjdk.org  Sat Oct 29 11:58:26 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 29 Oct 2022 11:58:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <JMZ_-77lTdemvfC3K54z8FRMXEuYGV44PHhjhPBnZFk=.e732f51f-7d8c-4ad0-980f-6e93946d43b8@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
 <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
 <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>
 <JMZ_-77lTdemvfC3K54z8FRMXEuYGV44PHhjhPBnZFk=.e732f51f-7d8c-4ad0-980f-6e93946d43b8@github.com>
Message-ID: <FfQ1_F-GP2tNy3JiwtPN-BLBK6E8b636tX8T1Vfl_5U=.a3f9410a-72fd-4dc2-87d8-35bf91897af9@github.com>

On Thu, 27 Oct 2022 11:24:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> How about `_unused` or `_unused1`, `_unused2` then in the meantime?
>
> I'd be happy to make the change. Let's wait to see if anybody has a better naming suggestion.

Hello Daniel, I think calling it `unused` is fine. I did a quick search in the JDK code and we already have places where we use such a variable name for similar usecase. I don't see the need for using an underscore as a prefix, but it is OK with me if you and others prefer to use it.

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From jpai at openjdk.org  Sat Oct 29 12:05:07 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 29 Oct 2022 12:05:07 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
 <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
Message-ID: <zzbb3oae_BJ3Xn5x5xJB3tfugG41Om9Mv6LhbXOKH1c=.9ac9052a-8d9f-4450-95df-599ebabc6476@github.com>

On Wed, 26 Oct 2022 17:51:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I see your point.  It may be more appropriate if URI.toURL was designed as URL.fromURL.
>> 
>> I was wondering to have application developers a consistent way to get an URL instance.  Now there are two methods in different classes URI.toURL and URL.fromURI.  It might be easier to use the old URI.toURL form.
>> 
>> Never mind, it is just my personal preference.  It is fine to me to have a new URL.fromURI method.
>
> One thing we might do is change the name of the method into `URL.of(URI, StreamHandler)`. It's named `fromURI` merely because there was a pre-existing package protected `fromURI` method. However since we're making it public now, it could be fair game to change its name. Possibly adding an overload `URL::of(URI)` method could be considered, but then there really would be two paths to do the same thing - so I'd rather not add such an overload - unless I get some more feedback on that from the CSR/PR review.

I think `URL.of(URI, URLStreamHandler)` is fine.

As for `URL.of(URI)`, whose implementation I suspect will just do `uri.toURL()` on the passed `URI`, I don't think we need it. It might add to unnecesary confusion on whether/when to use `URL.of(URI)` and when to use `URI.toURL()`

In the case of `URL.of(URI, URLStreamHandler)` it's pretty clear that you use it (only) when you have a specific `URLStreamHandler` to use for the constructed `URL`.

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From aivanov at openjdk.org  Sat Oct 29 12:14:25 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 29 Oct 2022 12:14:25 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
Message-ID: <rzIw7fkMmSiQ4HJygtWh3SxVIIZg4QY0nvByxOYUyGs=.b878366e-a60f-410f-94ae-47b486f4e7b5@github.com>

On Mon, 24 Oct 2022 19:29:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "Remove check for .properties from jcheck"
>>    
>>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>>  - Change trailing space and tab in values to unicode encoding
>
> src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134:
> 
>> 132: 
>> 133: #SyncResolverImpl exceptions
>> 134: syncrsimpl.indexval = Index value out of range\u0020\u0020
> 
> prob. unnecessary

This case is similar the one you mentioned below. If this value is used in a string template or concatenation, the trailing white-space could be necessary; however, one space is probably enough.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From aivanov at openjdk.org  Sat Oct 29 13:22:09 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 29 Oct 2022 13:22:09 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <4Npxj4pEaiqkJ2UBTsYb3xTHYseNBoj_3yshwocOIxw=.c701af52-62db-40c2-b3a3-90e47c44ed76@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Trailing spaces in `LocaleNames_*` are only in two files:

- `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties`
- `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties`

It is very unlikely these spaces are part of a country or language name. The former file contains a few trailing spaces, the latter ? only one.

src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties line 238:

> 236: cpp=Kreolisch-Portugiesische Sprache
> 237: crh=Krimtatarisch
> 238: crp=Kreolische Sprache\u0020

I'm pretty sure locale names shouldn't contain trailing spaces.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792


From alanb at openjdk.org  Sat Oct 29 14:28:07 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 29 Oct 2022 14:28:07 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

src/java.base/share/classes/java/net/URL.java line 133:

> 131:  * specified. The optional fragment is not inherited.
> 132:  *
> 133:  * <h2><a id="constructor-deprecation"></a>Constructing instances of {@code URL}</h2>

Would it be better to move the anchor to line 164 (the line where it says that the URL constructors are deprecated?

src/java.base/share/classes/java/net/URL.java line 157:

> 155:  * The URL constructors are specified to throw
> 156:  * {@link MalformedURLException} but the actual parsing/validation
> 157:  * that are performed is implementation dependent. Some parsing/validation

"the ... are performed" -> "the ... is performed".

src/java.base/share/classes/java/net/URL.java line 166:

> 164:  * The {@code java.net.URL} constructors are deprecated.
> 165:  * Developers are encouraged to use {@link URI java.net.URI} to parse
> 166:  * or construct any {@code URL}. In cases where an instance of {@code

"any URL" -> "a URL" or "all URLs".

src/java.base/share/classes/java/net/URL.java line 168:

> 166:  * or construct any {@code URL}. In cases where an instance of {@code
> 167:  * java.net.URL} is needed to open a connection, {@link URI} can be used
> 168:  * to construct or parse the URL string, possibly calling {@link

I wonder if it might be clearer to say "url string", only to avoid anyone thinking they call URL::toString.

src/java.base/share/classes/java/net/URL.java line 852:

> 850:      * @since 20
> 851:      */
> 852:     public static URL of(URI uri, URLStreamHandler streamHandler)

The parameter is named "handler" rather than "streamHandler" in constructors so we should probably keep it the same to avoid any confusion.

src/java.base/share/classes/java/net/URL.java line 885:

> 883: 
> 884:             @SuppressWarnings("deprecation")
> 885:             var result = new URL("jrt", host, port, file, null);

The URL scheme for jrt does have a port so we should look at that some time.

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From aivanov at openjdk.org  Sat Oct 29 17:30:15 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 29 Oct 2022 17:30:15 GMT
Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException
In-Reply-To: <ABJ79VQJ9Z_V9wB6JJTykhwJlGXac6aKHoe0Tdc5PNI=.bba61627-c1bc-40b0-a039-ac1bf918d22c@github.com>
References: <ABJ79VQJ9Z_V9wB6JJTykhwJlGXac6aKHoe0Tdc5PNI=.bba61627-c1bc-40b0-a039-ac1bf918d22c@github.com>
Message-ID: <t9bmizxH_WwzMcF3gUDzHPwWrI1LMYKfP2NwtpILaEQ=.58da1eca-1804-46d6-8b03-6cf21f7d4c89@github.com>

On Wed, 26 Oct 2022 10:28:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> If getDefaultEditor() is called before the JTable model is setup, it results in NPE.
> 
> This is because when JTable sets its model, which ends up firing a table changed event. The testcase is listening for tableChanged events and querying the editor. But the editor isn't installed until after the model is set which results in NPE.
> Fix is to ensure initializeLocalVars() which initializes default editor is setup before JTable sets its model.
> 
> No regression is observed in jtreg/jck testsuite with this change.

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JTable/JTableBugTest.java line 41:

> 39: import javax.swing.SwingUtilities;
> 40: 
> 41: public class JTableBugTest {

Can the test name be more specific?

test/jdk/javax/swing/JTable/JTableBugTest.java line 83:

> 81:                 resizeAll();
> 82:             else
> 83:                 resize(column);

Could you please update the code to follow the Java Code Style Guidelines? I mean, the braces, the spaces after keywords and opening parenthesis and around binary operators?

-------------

PR: https://git.openjdk.org/jdk/pull/10871


From serb at openjdk.org  Sat Oct 29 21:30:27 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 29 Oct 2022 21:30:27 GMT
Subject: RFR: 6201035: Undefined behavior of MatteBorder Ctors [v4]
In-Reply-To: <5R_pNlw1UpRTUSIN8BKZOCSw4IX6oKEdSiK-bpk8pvU=.5212eef8-e559-42f0-9834-c048dc77739e@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
 <nya7UqvvVSkJ2ORNUwGpI0BFKkDFX7vDqYjQQRkvZtk=.864dadcb-aa60-47f8-bc45-89bcee55142d@github.com>
 <5R_pNlw1UpRTUSIN8BKZOCSw4IX6oKEdSiK-bpk8pvU=.5212eef8-e559-42f0-9834-c048dc77739e@github.com>
Message-ID: <pM5qzQ9uAQ-CpAfXYQM8K13qh4XyE5yirZ0MT3Oxu8E=.b6ca89ae-244d-4206-be57-8d42fa1e3d85@github.com>

On Fri, 28 Oct 2022 16:48:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/javax/swing/border/AbstractBorder.java line 91:
> 
>> 89:      *         is {@code null}
>> 90:      */
>> 91:     public Insets getBorderInsets(Component c, Insets insets) {
> 
> Should the specification be clarified here? The method `getBorderInsets(Component c)` above says the fields of the returned `Insets` object are set to 0. The implementation of `getBorderInsets(Component c, Insets insets)` sets the fields of `Insets` to zero ? because it has no other insets.
> 
> Should the specification state that this *default implementation* sets the fields of the `Insets` object to zero?

Did we cover all the subclasses?

-------------

PR: https://git.openjdk.org/jdk/pull/10740


From serb at openjdk.org  Sat Oct 29 23:16:23 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 29 Oct 2022 23:16:23 GMT
Subject: RFR: 8295774 : Write a test to verify that List Item selection
 events.
In-Reply-To: <FSyEfibGCwPDFUHTXYBCLWKRi1hrVLgcdiArJaWVL3M=.4ab0216a-d9f5-41e3-9f55-8eddbc7dcdb1@github.com>
References: <FSyEfibGCwPDFUHTXYBCLWKRi1hrVLgcdiArJaWVL3M=.4ab0216a-d9f5-41e3-9f55-8eddbc7dcdb1@github.com>
Message-ID: <d3VM4oXzVFhHwHPkOZVK4vCcDNPTKd4HQnPqkhDM0Ag=.1c6bb0aa-83b2-4d27-a19a-e874f50c7db1@github.com>

On Fri, 28 Oct 2022 09:01:53 GMT, ravi gupta <duke at openjdk.org> wrote:

> This testcase verify that List Item selection via mouse/keys generates ItemEvent/ActionEvent appropriately.
> 
> a. Single click on the list generate ItemEvent and double click on item generates ActionEvent.
> b. UP/DOWN keys on the list generate ItemEvent and enter key on item generates ActionEvent.
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10899


From aivanov at openjdk.org  Sun Oct 30 13:06:35 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sun, 30 Oct 2022 13:06:35 GMT
Subject: RFR: 8295774 : Write a test to verify that List Item selection
 events.
In-Reply-To: <FSyEfibGCwPDFUHTXYBCLWKRi1hrVLgcdiArJaWVL3M=.4ab0216a-d9f5-41e3-9f55-8eddbc7dcdb1@github.com>
References: <FSyEfibGCwPDFUHTXYBCLWKRi1hrVLgcdiArJaWVL3M=.4ab0216a-d9f5-41e3-9f55-8eddbc7dcdb1@github.com>
Message-ID: <gPnzVicNzZjmhmaahUgdcFi-aA0uAUVdK4ktC7fAUo0=.d5e33610-b2d3-4f76-a2d7-e0de54ec3386@github.com>

On Fri, 28 Oct 2022 09:01:53 GMT, ravi gupta <duke at openjdk.org> wrote:

> This testcase verify that List Item selection via mouse/keys generates ItemEvent/ActionEvent appropriately.
> 
> a. Single click on the list generate ItemEvent and double click on item generates ActionEvent.
> b. UP/DOWN keys on the list generate ItemEvent and enter key on item generates ActionEvent.
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 50:

> 48:     private static final int waitDelay = 1000;
> 49: 
> 50:     private volatile static Frame frame;

`frame` is used only from the EDT, thus it doesn't need to be `volatile`.

test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 54:

> 52:     private volatile static boolean actionPerformed = false;
> 53:     private volatile static boolean itemStateChanged = false;
> 54:     private volatile static Robot robot;

`robot` is used from the main thread only, therefore it doesn't need to be `volatile` either.

test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 55:

> 53:     private volatile static boolean itemStateChanged = false;
> 54:     private volatile static Robot robot;
> 55:     private volatile static CountDownLatch latch;

Should rather be `final` than `volatile`.

test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 100:

> 98:             Point listAt = list.getLocationOnScreen();
> 99:             // get bounds of button
> 100:             Rectangle bounds = list.getBounds();

What button? Better remove the comment.

Since you need only the size, use [`getSize()`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Component.html#getSize())

test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 111:

> 109:                 throw new RuntimeException(
> 110:                     "Fail: Timed out waiting for list to gain focus, test cannot proceed!!");
> 111:             }

Since `list` is the only focusable component in the `frame`, it gets focus before `robot.waitForIdle()` returns. So, this along with `FocusListener` could be dropped.

test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 140:

> 138:             }
> 139: 
> 140:             robot.setAutoDelay(waitDelay);

Why is delay increased here?

test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 189:

> 187:     }
> 188: 
> 189:     private static void keyType(int key) throws Exception {

Suggestion:

    private static void typeKey(int key) throws Exception {

Method names usually start with verbs.

-------------

PR: https://git.openjdk.org/jdk/pull/10899


From aivanov at openjdk.org  Sun Oct 30 14:05:32 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sun, 30 Oct 2022 14:05:32 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v9]
In-Reply-To: <Z5aH4dx5JUWRlpc8NUZnIoBR1ewhTq2B4IEvlP9E2Ms=.995d0d96-c397-4395-881c-e42a34a86a74@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <Z5aH4dx5JUWRlpc8NUZnIoBR1ewhTq2B4IEvlP9E2Ms=.995d0d96-c397-4395-881c-e42a34a86a74@github.com>
Message-ID: <GHuVZnTUjXoTd3zdUBNmSZpaw9DfTj6JSn-g95TNX9E=.b4a43e3c-6c69-4a28-a817-fea7465c24e3@github.com>

On Fri, 28 Oct 2022 03:32:18 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.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review fix
>  - Review fix

This looks good now. All the tests pass successfully.

Could you optimise the imports, please? To eliminate the wildcard import.

Could you also update the copyright year?

Would you mind adding the `final` modifier to parameters and local variables in `insertIndexInterval` and `removeIndexInterval` to _explicitly_ declare that they're not modified in the method? That is to `index`, `length`, `before` and `insMinIndex`, `insMaxIndex`; and `index0`, `index1` and `rmMinIndex`, `rmMaxIndex`, `gapLength` correspondingly.

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 452:

> 450:                 clear(i);
> 451:             }
> 452:             // Integer overflow

Would _?Prevent integer overflow?_ sound even better?

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 654:

> 652:     {
> 653:         if (length < 0 || index < 0) {
> 654:             throw new IndexOutOfBoundsException("index or length is negative");

In fact, I also thought about modifying `length` but I didn't figure it out ? you did.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10409


From aturbanov at openjdk.org  Sun Oct 30 17:33:27 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 30 Oct 2022 17:33:27 GMT
Subject: RFR: 8282463: javax/sound/sampled/Clip/DataPusherThreadCheck.java
 fails
In-Reply-To: <myMXcksU12EK7xpYDTIW7PWDv2Gl1pftNHFeQzGrU8Q=.79d47610-3fb8-416a-961d-dc22f6c92480@github.com>
References: <myMXcksU12EK7xpYDTIW7PWDv2Gl1pftNHFeQzGrU8Q=.79d47610-3fb8-416a-961d-dc22f6c92480@github.com>
Message-ID: <EYTQQo2oNy392Pkt1Uo0yL7-GdbYiaTyUk09z5qTFn8=.b44d6de2-aba8-4bef-96ba-e101405089dc@github.com>

On Sat, 15 Oct 2022 13:03:26 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Test failed on Ubuntu, because both implementations of `MixerProvider` have no devices:
> 1. com.sun.media.sound.DirectAudioDeviceProvider#nGetNumDevices returns `0`
>  ![DirectAudioDeviceProvider init](https://user-images.githubusercontent.com/741251/195988216-aa86da0f-739b-433f-87e2-86c2d6904a0d.png)
> 2. com.sun.media.sound.PortMixerProvider#nGetNumDevices returns `0`
>  ![PortMixerProvider init](https://user-images.githubusercontent.com/741251/195988239-59678e0c-be7b-43ff-b02a-9abb2392e8f9.png)
> 
> 
> It leads to `javax.sound.sampled.spi.MixerProvider#getMixerInfo` returns empty array.
> ![AudioSystem getMixedInfoList](https://user-images.githubusercontent.com/741251/195988266-1656e6d3-de4a-4e53-a613-415f60075726.png)
> 
> And DataPusher thread is not created, because of AudioSystem.isLineSupported returns false in the method `com.sun.media.sound.JavaSoundAudioClip#createSourceDataLine`.
> I propose to perform the same check in test code and skip it.

I wasn't able to reproduce failure after the fix.

-------------

PR: https://git.openjdk.org/jdk/pull/10717


From aturbanov at openjdk.org  Sun Oct 30 17:37:06 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 30 Oct 2022 17:37:06 GMT
Subject: Integrated: 8282463:
 javax/sound/sampled/Clip/DataPusherThreadCheck.java fails
In-Reply-To: <myMXcksU12EK7xpYDTIW7PWDv2Gl1pftNHFeQzGrU8Q=.79d47610-3fb8-416a-961d-dc22f6c92480@github.com>
References: <myMXcksU12EK7xpYDTIW7PWDv2Gl1pftNHFeQzGrU8Q=.79d47610-3fb8-416a-961d-dc22f6c92480@github.com>
Message-ID: <-RCIXFr0Ov_xScK5c7GOO_AFL2FRz5qteIxlbliYIJ0=.5561fab0-2e10-465d-aa3a-8a0401a93c84@github.com>

On Sat, 15 Oct 2022 13:03:26 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Test failed on Ubuntu, because both implementations of `MixerProvider` have no devices:
> 1. com.sun.media.sound.DirectAudioDeviceProvider#nGetNumDevices returns `0`
>  ![DirectAudioDeviceProvider init](https://user-images.githubusercontent.com/741251/195988216-aa86da0f-739b-433f-87e2-86c2d6904a0d.png)
> 2. com.sun.media.sound.PortMixerProvider#nGetNumDevices returns `0`
>  ![PortMixerProvider init](https://user-images.githubusercontent.com/741251/195988239-59678e0c-be7b-43ff-b02a-9abb2392e8f9.png)
> 
> 
> It leads to `javax.sound.sampled.spi.MixerProvider#getMixerInfo` returns empty array.
> ![AudioSystem getMixedInfoList](https://user-images.githubusercontent.com/741251/195988266-1656e6d3-de4a-4e53-a613-415f60075726.png)
> 
> And DataPusher thread is not created, because of AudioSystem.isLineSupported returns false in the method `com.sun.media.sound.JavaSoundAudioClip#createSourceDataLine`.
> I propose to perform the same check in test code and skip it.

This pull request has now been integrated.

Changeset: 2e716375
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e7163759c75cab6ab5ffa04c13d32ccc95f9719
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8282463: javax/sound/sampled/Clip/DataPusherThreadCheck.java fails

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/10717


From prr at openjdk.org  Sun Oct 30 18:47:12 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 30 Oct 2022 18:47:12 GMT
Subject: RFR: 8296087: Problem list headful tests which may fail on Linux VMs
Message-ID: <a1PG9I2T5AOkvA-akTBFoAW-RqEv5K6pRNnSqsmRxBc=.aaf2d942-1e35-4a6e-b43f-b3fafbbfdec5@github.com>

Problem list 2 tests which fail on Linux VMs.

-------------

Commit messages:
 - 8296087
 - 8296087

Changes: https://git.openjdk.org/jdk/pull/10911/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10911&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296087
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10911.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10911/head:pull/10911

PR: https://git.openjdk.org/jdk/pull/10911


From duke at openjdk.org  Mon Oct 31 05:00:57 2022
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 31 Oct 2022 05:00:57 GMT
Subject: RFR: JDK-8252075: Documentation error in LayoutManager2 interface
 [v2]
In-Reply-To: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
References: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
Message-ID: <z2FEfZD2WOExA7YEEFix3kGOE8qWgV1Cb0UxV31lKKM=.7ef28386-c0fc-44b8-940e-312ff35128e0@github.com>

> Updated the documentation with proper meaningful message for better understanding.

Renjith Kannath Pariyangad 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 'openjdk:master' into 8252075-v2
 - JDK-8252075 : Documentation error in LayoutManager2 interface

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10549/files
  - new: https://git.openjdk.org/jdk/pull/10549/files/e7986971..e7073216

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10549&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10549&range=00-01

  Stats: 178967 lines in 2330 files changed: 104211 ins; 38707 del; 36049 mod
  Patch: https://git.openjdk.org/jdk/pull/10549.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10549/head:pull/10549

PR: https://git.openjdk.org/jdk/pull/10549


From jdv at openjdk.org  Mon Oct 31 05:13:09 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 31 Oct 2022 05:13:09 GMT
Subject: RFR: 8296087: Problem list headful tests which may fail on Linux
 VMs
In-Reply-To: <a1PG9I2T5AOkvA-akTBFoAW-RqEv5K6pRNnSqsmRxBc=.aaf2d942-1e35-4a6e-b43f-b3fafbbfdec5@github.com>
References: <a1PG9I2T5AOkvA-akTBFoAW-RqEv5K6pRNnSqsmRxBc=.aaf2d942-1e35-4a6e-b43f-b3fafbbfdec5@github.com>
Message-ID: <dZChuTZ51EqM34DkCBW-bHupsNPNetlTAF1MJHqjdf8=.cefa0479-f712-4006-93e8-c68ab740b13b@github.com>

On Sun, 30 Oct 2022 16:30:37 GMT, Phil Race <prr at openjdk.org> wrote:

> Problem list 2 tests which fail on Linux VMs.

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10911


From prr at openjdk.org  Mon Oct 31 05:23:15 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 31 Oct 2022 05:23:15 GMT
Subject: Integrated: 8296087: Problem list headful tests which may fail on
 Linux VMs
In-Reply-To: <a1PG9I2T5AOkvA-akTBFoAW-RqEv5K6pRNnSqsmRxBc=.aaf2d942-1e35-4a6e-b43f-b3fafbbfdec5@github.com>
References: <a1PG9I2T5AOkvA-akTBFoAW-RqEv5K6pRNnSqsmRxBc=.aaf2d942-1e35-4a6e-b43f-b3fafbbfdec5@github.com>
Message-ID: <aHUlgsKWnQZyGY0HpXxg0kg6OYIJYZPCsa6RdOF4ZhA=.7ef7e8eb-849a-4d2b-9e86-78a330d4b52a@github.com>

On Sun, 30 Oct 2022 16:30:37 GMT, Phil Race <prr at openjdk.org> wrote:

> Problem list 2 tests which fail on Linux VMs.

This pull request has now been integrated.

Changeset: f8cc0677
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f8cc067792ca8be1426ba6ae97968efa91c71db7
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8296087: Problem list headful tests which may fail on Linux VMs

Reviewed-by: jdv

-------------

PR: https://git.openjdk.org/jdk/pull/10911


From duke at openjdk.org  Mon Oct 31 06:55:56 2022
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 31 Oct 2022 06:55:56 GMT
Subject: RFR: JDK-8252075: Documentation error in LayoutManager2 interface
 [v3]
In-Reply-To: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
References: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
Message-ID: <olz77JA0cGtWAdA7NtxZRztmaCgxPkKjdZ7nzQ3TA9Y=.cef34a28-8128-4697-8d18-6f3f355b957d@github.com>

> Updated the documentation with proper meaningful message for better understanding.

Renjith Kannath Pariyangad has updated the pull request with a new target base due to a merge or a rebase.

-------------

Changes: https://git.openjdk.org/jdk/pull/10549/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10549&range=02
  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10549.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10549/head:pull/10549

PR: https://git.openjdk.org/jdk/pull/10549


From duke at openjdk.org  Mon Oct 31 06:55:58 2022
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 31 Oct 2022 06:55:58 GMT
Subject: Withdrawn: JDK-8252075: Documentation error in LayoutManager2
 interface
In-Reply-To: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
References: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
Message-ID: <9hdlXa3Sn4XQfohyN7AYePVNMRmcjoZTZfx8HoBWN-k=.e5f71b82-d5e7-43a9-bc12-5c6138a184a2@github.com>

On Tue, 4 Oct 2022 07:00:04 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> wrote:

> Updated the documentation with proper meaningful message for better understanding.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10549


From duke at openjdk.org  Mon Oct 31 07:17:39 2022
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 31 Oct 2022 07:17:39 GMT
Subject: RFR: 8252075: Documentation error in LayoutManager2 interface [v4]
In-Reply-To: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
References: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
Message-ID: <cK1erm2gFJWjK27c_0WHaNVDA1ypJupgoOkvix8R_Zc=.e4c44f44-68df-4efb-9ed0-6982d81b8c28@github.com>

> Updated the documentation with proper meaningful message for better understanding.

Renjith Kannath Pariyangad 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 one additional commit since the last revision:

  Updated documentation section with suggested mark up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10549/files
  - new: https://git.openjdk.org/jdk/pull/10549/files/ae79af2a..616943dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10549&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10549&range=02-03

  Stats: 179134 lines in 2337 files changed: 104294 ins; 38740 del; 36100 mod
  Patch: https://git.openjdk.org/jdk/pull/10549.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10549/head:pull/10549

PR: https://git.openjdk.org/jdk/pull/10549


From psadhukhan at openjdk.org  Mon Oct 31 07:48:38 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 31 Oct 2022 07:48:38 GMT
Subject: RFR: 6201035: Document NPE for passing null insets to constructors
 and methods of several Border classes [v5]
In-Reply-To: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
Message-ID: <QJ_7wtNPog50L4oxYA8RNkJNTYeuJO9axRuyo1ErdwA=.ad78d858-6f09-49dd-b677-3312f039dc7c@github.com>

> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Rectify javadoc of more border classes/methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10740/files
  - new: https://git.openjdk.org/jdk/pull/10740/files/391bf7f3..e7081b0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10740&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10740&range=03-04

  Stats: 22 lines in 9 files changed: 12 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10740.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10740/head:pull/10740

PR: https://git.openjdk.org/jdk/pull/10740


From psadhukhan at openjdk.org  Mon Oct 31 07:48:39 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 31 Oct 2022 07:48:39 GMT
Subject: RFR: 6201035: Document NPE for passing null insets to constructors
 and methods of several Border classes [v4]
In-Reply-To: <pM5qzQ9uAQ-CpAfXYQM8K13qh4XyE5yirZ0MT3Oxu8E=.b6ca89ae-244d-4206-be57-8d42fa1e3d85@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
 <nya7UqvvVSkJ2ORNUwGpI0BFKkDFX7vDqYjQQRkvZtk=.864dadcb-aa60-47f8-bc45-89bcee55142d@github.com>
 <5R_pNlw1UpRTUSIN8BKZOCSw4IX6oKEdSiK-bpk8pvU=.5212eef8-e559-42f0-9834-c048dc77739e@github.com>
 <pM5qzQ9uAQ-CpAfXYQM8K13qh4XyE5yirZ0MT3Oxu8E=.b6ca89ae-244d-4206-be57-8d42fa1e3d85@github.com>
Message-ID: <bFhAFg9vIuL7Css28WnXD84V7o8hMfRD7kOCr_l2jbE=.023ed408-7cf2-4f28-a885-942b23594129@github.com>

On Sat, 29 Oct 2022 21:27:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/border/AbstractBorder.java line 91:
>> 
>>> 89:      *         is {@code null}
>>> 90:      */
>>> 91:     public Insets getBorderInsets(Component c, Insets insets) {
>> 
>> Should the specification be clarified here? The method `getBorderInsets(Component c)` above says the fields of the returned `Insets` object are set to 0. The implementation of `getBorderInsets(Component c, Insets insets)` sets the fields of `Insets` to zero ? because it has no other insets.
>> 
>> Should the specification state that this *default implementation* sets the fields of the `Insets` object to zero?
>
> Did we cover all the subclasses?

More classes added

-------------

PR: https://git.openjdk.org/jdk/pull/10740


From psadhukhan at openjdk.org  Mon Oct 31 07:50:20 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 31 Oct 2022 07:50:20 GMT
Subject: RFR: 6201035: Document NPE for passing null insets to constructors
 and methods of several Border classes [v4]
In-Reply-To: <nya7UqvvVSkJ2ORNUwGpI0BFKkDFX7vDqYjQQRkvZtk=.864dadcb-aa60-47f8-bc45-89bcee55142d@github.com>
References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com>
 <nya7UqvvVSkJ2ORNUwGpI0BFKkDFX7vDqYjQQRkvZtk=.864dadcb-aa60-47f8-bc45-89bcee55142d@github.com>
Message-ID: <3tlrIWTwZQqTtYM0uZFYqkGbRINFV3ADTMvvAvrCnWY=.4c4435bf-57d5-4859-a3ec-0edd040fe403@github.com>

On Fri, 28 Oct 2022 03:42:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

Changed subject and added more border classes/methods

-------------

PR: https://git.openjdk.org/jdk/pull/10740


From psadhukhan at openjdk.org  Mon Oct 31 08:59:31 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 31 Oct 2022 08:59:31 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v10]
In-Reply-To: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
Message-ID: <dDNMsroUmRgM-LitBnimoWYshMmIAU9yRzU_T0SFHBY=.b32e97e5-6b87-442f-8f15-4ad12c512292@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.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10409/files
  - new: https://git.openjdk.org/jdk/pull/10409/files/fce8c56b..b1857d3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10409&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10409&range=08-09

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 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 psadhukhan at openjdk.org  Mon Oct 31 08:59:32 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 31 Oct 2022 08:59:32 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails [v9]
In-Reply-To: <Z5aH4dx5JUWRlpc8NUZnIoBR1ewhTq2B4IEvlP9E2Ms=.995d0d96-c397-4395-881c-e42a34a86a74@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <Z5aH4dx5JUWRlpc8NUZnIoBR1ewhTq2B4IEvlP9E2Ms=.995d0d96-c397-4395-881c-e42a34a86a74@github.com>
Message-ID: <bBtWfUYXD4r0vE98J9tjn-68Ubh6S7C2LjP6snfNUF0=.efe2b3ec-0ba3-46d7-97d0-97116e3e5710@github.com>

On Fri, 28 Oct 2022 03:32:18 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.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review fix
>  - Review fix

CSR raised... https://bugs.openjdk.org/browse/JDK-8295329

-------------

PR: https://git.openjdk.org/jdk/pull/10409


From psadhukhan at openjdk.org  Mon Oct 31 09:11:21 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 31 Oct 2022 09:11:21 GMT
Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException
 [v2]
In-Reply-To: <ABJ79VQJ9Z_V9wB6JJTykhwJlGXac6aKHoe0Tdc5PNI=.bba61627-c1bc-40b0-a039-ac1bf918d22c@github.com>
References: <ABJ79VQJ9Z_V9wB6JJTykhwJlGXac6aKHoe0Tdc5PNI=.bba61627-c1bc-40b0-a039-ac1bf918d22c@github.com>
Message-ID: <eHoKUCcI5lBlmzwIKiGuMhpkZbnwJcH5Jk9aSTLKS-E=.1592c4d7-f8c4-48c0-894e-8226e6d5b2aa@github.com>

> If getDefaultEditor() is called before the JTable model is setup, it results in NPE.
> 
> This is because when JTable sets its model, which ends up firing a table changed event. The testcase is listening for tableChanged events and querying the editor. But the editor isn't installed until after the model is set which results in NPE.
> Fix is to ensure initializeLocalVars() which initializes default editor is setup before JTable sets its model.
> 
> No regression is observed in jtreg/jck testsuite with this change.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10871/files
  - new: https://git.openjdk.org/jdk/pull/10871/files/e2e5c38d..58c36915

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10871&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10871&range=00-01

  Stats: 268 lines in 2 files changed: 136 ins; 132 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10871.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10871/head:pull/10871

PR: https://git.openjdk.org/jdk/pull/10871


From psadhukhan at openjdk.org  Mon Oct 31 09:14:23 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 31 Oct 2022 09:14:23 GMT
Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException
 [v3]
In-Reply-To: <ABJ79VQJ9Z_V9wB6JJTykhwJlGXac6aKHoe0Tdc5PNI=.bba61627-c1bc-40b0-a039-ac1bf918d22c@github.com>
References: <ABJ79VQJ9Z_V9wB6JJTykhwJlGXac6aKHoe0Tdc5PNI=.bba61627-c1bc-40b0-a039-ac1bf918d22c@github.com>
Message-ID: <-_EIXOFFPEZ5uuvK42SJ4cNn_kA7k7rr6YOi8AY1M3M=.63eac53f-7abe-4f9d-8ecd-dcf06aadc762@github.com>

> If getDefaultEditor() is called before the JTable model is setup, it results in NPE.
> 
> This is because when JTable sets its model, which ends up firing a table changed event. The testcase is listening for tableChanged events and querying the editor. But the editor isn't installed until after the model is set which results in NPE.
> Fix is to ensure initializeLocalVars() which initializes default editor is setup before JTable sets its model.
> 
> No regression is observed in jtreg/jck testsuite with this change.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10871/files
  - new: https://git.openjdk.org/jdk/pull/10871/files/58c36915..7ac0d1e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10871&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10871&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10871.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10871/head:pull/10871

PR: https://git.openjdk.org/jdk/pull/10871


From tnakamura at openjdk.org  Mon Oct 31 09:15:24 2022
From: tnakamura at openjdk.org (Toshio Nakamura)
Date: Mon, 31 Oct 2022 09:15:24 GMT
Subject: RFR: 8295248: JEditorPane HTML form with multi-selection broke
 data after resetting [v3]
In-Reply-To: <XJ54TYURwthQqWedWpAuAGeRuDqq043NdAQRcucAWpc=.6160f318-c362-4788-909e-7f9932ee99fb@github.com>
References: <DMj2VWqEgCTRhpRkHF-76w6lKJXeXmZ5gLa9z_lX4JY=.59b03bc6-3564-4948-842b-8c7f13a6ea63@github.com>
 <XJ54TYURwthQqWedWpAuAGeRuDqq043NdAQRcucAWpc=.6160f318-c362-4788-909e-7f9932ee99fb@github.com>
Message-ID: <P3gHPbPqyUJKnABlOsUNKE8fR9z3PNUESzXMH6OpEpQ=.ccf52138-8046-4599-9edb-59c8f05e4496@github.com>

On Mon, 24 Oct 2022 02:06:23 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> When JEditorPane shown HTML form with multi-selection, the reset operation broke its data.
>> 
>> The sample testcase were attached in JBS. The recreate steps are below:
>> 1. The sample shows a multi-selection form with 5 items.
>> 2. Select the 4th item.
>> 3. Press the reset button.
>> Actual: The 4th item is still selected.
>> Expect: No item should be selected. Resetting operation may move to the initial state. The sample doesn't use 'selected' property in each option tag.
>> 4. Just after the step 3, move the focus to outside of the application and back.
>> Actual: The 2nd item is selected. It means inside data indicates so.
>> Expect: No item is selected.
>> 
>> There are two issues. The current method `OptionListModel.removeIndexInterval()` removed the indexed item, and shifted the rest. Then, selection values were corrupted.
>> I think the clear selection method `OptionListModel.clearSelection()` is suitable here.
>> 
>> Test: jdk_desktop on macOS (x64, Monterey), Linux (x64, RHEL8), and Windows (x64, 2012R2).
>>       No regression found
>
> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed space

Tested with jwebserver. It shows logs like `GET /test.html?select=1&subtmi=submit HTTP/1.1`, and the selected items can be identified.

Test1: 5 items in HTML select form without property. Like,

<select size="5" multiple>
 <option>1</option>
 <option>2</option>
 <option>3</option>
 <option>4</option>
 <option>5</option>
</select>


1.1 Select and submit
|selected item(s)|results w/o patch |results w/ patch |
| -------------- | ------- | ------ | 
|1               |1        |1       |
|2               |2        |2       |
|3               |3        |3       |
|4               |4        |4       |
|5               |5        |5       |
|1,2,3,4,5    |1,2,3,4,5 |1,2,3,4,5 |

1.2. Select, _reset_ and submit
|selected item(s)|w/o patch|w/ patch|
| -------------- | ------- | ------ | 
|1               |none     |none    |
|2               |**1**     |none    |
|3               |none     |none    |
|4               |**2**     |none    |
|5               |none     |none    |
|1,2,3,4,5    |**1,2**  |none    |

Test2: 5 items in HTML select form with 'selected' property at the first items. Like,

<select size="5" multiple>
 <option selected>1</option>
 <option>2</option>
 <option>3</option>
 <option>4</option>
 <option>5</option>
</select>


2.1 Select and submit
|selected item(s)|w/o patch|w/ patch|
| -------------- | ------- | ------ | 
|1               |1        |1       |
|2               |2        |2       |
|3               |3        |3       |
|4               |4        |4       |
|5               |5        |5       |
|1,2,3,4,5   |1,2,3,4,5 |1,2,3,4,5 |

2.2 Select, _reset_ and submit
|selected item(s)|w/o patch|w/ patch|
| -------------- | ------- | ------ | 
|1               |1        |1       |
|2               |1        |1       |
|3               |1        |1       |
|4               |**1,2**    |1       |
|5               |1        |1       |
|1,2,3,4,5    |**1,2**    |1       |

Bold marked cases have the problem, and this patch can solve it.

-------------

PR: https://git.openjdk.org/jdk/pull/10685


From psadhukhan at openjdk.org  Mon Oct 31 09:58:30 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 31 Oct 2022 09:58:30 GMT
Subject: RFR: 5074006: Swing JOptionPane shows </html> tag as a string
 after newline [v3]
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: <_mgeEbP43jqpl4IXkFSlxbd2nL_XT3TiGsCz0c1i9fU=.21d87275-3b71-4633-a2a3-34b192f36c9d@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:

  Add comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10081/files
  - new: https://git.openjdk.org/jdk/pull/10081/files/2b00d425..c6901154

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10081&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10081&range=01-02

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 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 Oct 31 10:09:19 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 31 Oct 2022 10:09:19 GMT
Subject: RFR: 5074006: Swing JOptionPane shows </html> tag as a string
 after newline [v4]
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: <2ey8FsxjSLC7AjcpYExWnXf-en6Lz001e5k7Am3fbFM=.e19a71e8-0101-43e9-a58d-ec00ee9890c4@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:

  Add comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10081/files
  - new: https://git.openjdk.org/jdk/pull/10081/files/c6901154..00a7ddfe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10081&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10081&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 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 smandalika at openjdk.org  Mon Oct 31 11:44:13 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Mon, 31 Oct 2022 11:44:13 GMT
Subject: RFR: 8295707: Create a regression test for JDK-7184401
Message-ID: <vIN06D-gVbz3GLi_NQZIQkx57ZyCiCKZCVKqm62g9nw=.ccf472cd-6020-457d-af86-911f6f248cf9@github.com>

8295707: Create a regression test for JDK-7184401

JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144
As indicated in the above bug's description, it got introduced due to a fix for [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). The test below recreates a standalone test to mimic the failure reported in Netbeans in [JDK-7184401](https://bugs.openjdk.java.net/browse/JDK-7184401) and verifies that it is working as expected after it got fixed.( Via [JDK-7189350](https://bugs.openjdk.java.net/browse/JDK-7189350))

The Test attempts to reproduce specific behavior of NetBeans at the certain toolbar creation stage. Widgets are created on EDT; Another code posts some events to them on EDT; From another thread some code calls explicitlyedt.interrupt().
Before this got fixed, events from a second code got lost.

This review is for migrating tests from a closed test suite to open.
Testing:
1.Tested the code on jdk7u6 to reproduce the issue - the UI hangs when run on this build.
2. Tested the code on jdk7u361 b01 to validate the fix - the test passed.
3.Mach5 Testing(40 times per platform) in macos x64, linux x64 and windows x64 - the .results are clean

-------------

Commit messages:
 - Minor Code Cleanups
 - 8295707: Create a regression test for JDK-7184401

Changes: https://git.openjdk.org/jdk/pull/10784/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10784&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295707
  Stats: 107 lines in 1 file changed: 107 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10784.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10784/head:pull/10784

PR: https://git.openjdk.org/jdk/pull/10784


From psadhukhan at openjdk.org  Mon Oct 31 12:34:38 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 31 Oct 2022 12:34:38 GMT
Subject: Integrated: 5074006: Swing JOptionPane shows </html> tag as a string
 after newline
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: <GlEAuJOjSXTgqoNTYojqu2O1Md6sqxlbzEGC9_yPP_A=.a5e95852-0441-4408-b50f-11fa437a0a82@github.com>

On Tue, 30 Aug 2022 12:36:49 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.

This pull request has now been integrated.

Changeset: 91072ee3
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91072ee3934616ab2edc4850a59c0a25fd0de3b4
Stats:     158 lines in 2 files changed: 118 ins; 26 del; 14 mod

5074006: Swing JOptionPane shows </html> tag as a string after newline
8042134: JOptionPane bungles HTML messages

Reviewed-by: jdv, tr

-------------

PR: https://git.openjdk.org/jdk/pull/10081


From aivanov at openjdk.org  Mon Oct 31 12:57:27 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 31 Oct 2022 12:57:27 GMT
Subject: RFR: 8252075: Documentation error in LayoutManager2 interface [v4]
In-Reply-To: <cK1erm2gFJWjK27c_0WHaNVDA1ypJupgoOkvix8R_Zc=.e4c44f44-68df-4efb-9ed0-6982d81b8c28@github.com>
References: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
 <cK1erm2gFJWjK27c_0WHaNVDA1ypJupgoOkvix8R_Zc=.e4c44f44-68df-4efb-9ed0-6982d81b8c28@github.com>
Message-ID: <fEaWsy-QwjN4N0EirmUDzGkkP6pRLLnT9g-2I07UEdg=.37fdd3b8-5cb5-47b5-8747-07e69c66d2fa@github.com>

On Mon, 31 Oct 2022 07:17:39 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> wrote:

>> Updated the documentation with proper meaningful message for better understanding.
>
> Renjith Kannath Pariyangad 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 one additional commit since the last revision:
> 
>   Updated documentation section with suggested mark up

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/LayoutManager2.java line 36:

> 34:  * <p>
> 35:  * This minimal extension to {@code LayoutManager} is intended for tool
> 36:  * providers who wish to the creation of constraint-based layouts.

Where did your first change disappear now?

-------------

PR: https://git.openjdk.org/jdk/pull/10549


From duke at openjdk.org  Mon Oct 31 13:24:30 2022
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 31 Oct 2022 13:24:30 GMT
Subject: RFR: 8252075: Documentation error in LayoutManager2 interface [v5]
In-Reply-To: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
References: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
Message-ID: <nEbec3LQDdP7q-IDWyzeDrzaGULp-moMF4iFaXTT2Yc=.34fc8dd0-346c-4091-8004-c5873c79d02c@github.com>

> Updated the documentation with proper meaningful message for better understanding.

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Updated documentation content which missed in previous check-in

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10549/files
  - new: https://git.openjdk.org/jdk/pull/10549/files/616943dd..8af0e857

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10549&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10549&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10549.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10549/head:pull/10549

PR: https://git.openjdk.org/jdk/pull/10549


From duke at openjdk.org  Mon Oct 31 13:25:44 2022
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 31 Oct 2022 13:25:44 GMT
Subject: RFR: 8252075: Documentation error in LayoutManager2 interface [v4]
In-Reply-To: <fEaWsy-QwjN4N0EirmUDzGkkP6pRLLnT9g-2I07UEdg=.37fdd3b8-5cb5-47b5-8747-07e69c66d2fa@github.com>
References: <eu-FwHFV5WuswlOFmGpv6Xc2s-oc4_itSMFMhi7aiXk=.ea4f169c-77fa-4e05-b58b-1a33c3cd1fb0@github.com>
 <cK1erm2gFJWjK27c_0WHaNVDA1ypJupgoOkvix8R_Zc=.e4c44f44-68df-4efb-9ed0-6982d81b8c28@github.com>
 <fEaWsy-QwjN4N0EirmUDzGkkP6pRLLnT9g-2I07UEdg=.37fdd3b8-5cb5-47b5-8747-07e69c66d2fa@github.com>
Message-ID: <2cfcJeoa7FdQ4b1zJ2sV7SozbDrNZwr5aiaHc5r0tQY=.6e2c9e29-72d2-4cea-8398-f2ef0fff2c98@github.com>

On Mon, 31 Oct 2022 12:53:39 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Renjith Kannath Pariyangad 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 one additional commit since the last revision:
>> 
>>   Updated documentation section with suggested mark up
>
> src/java.desktop/share/classes/java/awt/LayoutManager2.java line 36:
> 
>> 34:  * <p>
>> 35:  * This minimal extension to {@code LayoutManager} is intended for tool
>> 36:  * providers who wish to the creation of constraint-based layouts.
> 
> Where did your first change disappear now?

Sorry while updating I have missed it.

-------------

PR: https://git.openjdk.org/jdk/pull/10549


From honkar at openjdk.org  Mon Oct 31 16:41:43 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 31 Oct 2022 16:41:43 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <zFlPWHcSwIfXlnTeEXtv3YohImvHSGjdgQXvaqAcsGY=.6d908441-d787-48b7-86ef-2d200d92c049@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
 <0SIw07r--T4zF6fgkVRw0UY9qv0duIELblGCuxqcuZc=.f0d01224-6d2b-4e25-882b-cf0f0205004f@github.com>
 <UemCGrDaiy4osk-rRrilEZG-HpCu9bN9Q_sHztLpdyU=.49fe52f2-1306-45f2-a455-f8c627d1ae31@github.com>
 <VdrfTNGNyvcyE7teukQrl1ATUAKGEN4Nrzsinr5ipQI=.9013c0e0-d93f-455e-bfb7-e088fd95bd42@github.com>
 <hnlpIVPe1vxw8KeulUxLSmEYiGgMQIIkTKv00KF-oFk=.eaa9e60b-f77e-4c4d-a6b1-cfb59f8642fe@github.com>
 <zFlPWHcSwIfXlnTeEXtv3YohImvHSGjdgQXvaqAcsGY=.6d908441-d787-48b7-86ef-2d200d92c049@github.com>
Message-ID: <aY81AnJ5pagleSBS4v_6LiYH1mmCEGYrziXvjH6jtOM=.5eabf612-faff-40c5-a4c0-7ab0391b6dbd@github.com>

On Wed, 5 Oct 2022 16:28:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> @aivanov-jdk Regarding saving the screen capture -
>>> 
>>> When JIF bounds are used, a partial image of JInternalFrame (JIF) is saved. Hence I'm using the entire outer JFrame bounds to capture the screenshot.
>> 
>> Could be? It shouldn't. Anyway, I have no problem with capturing the entire `JFrame`.
>> 
>>> 
>>> For the screenCapture I wanted to use **BufferedImage's getScaledInstance()** to create the scaled version (code snippet below), but experiencing issues while saving it. Currently I'm scaling the original image and re-drawing it using graphics object.
>>  
>> This is definitely not what we want. It just up-scales or down-scales the current image stored in `BufferedImage`.
>> 
>> When you run in a HiDPI environment or with `uiScale` set explicitly to a value greater than 1.0, the number of pixels is higher. `Robot.createScreenCapture` up-scales the passed in rectangle, captures all the pixels and then down-scales the captured screenshot to the user's space coordinates.
>> 
>> At the same time, [`createMultiResolutionScreenCapture`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Robot.html#createScreenCapture(java.awt.Rectangle)) returns a `MultiResolutionImage` which contains two variants: (1) the base image with the user specified size, down-scaled from the screen; (2) native resolution image with the device size pixels. The second variant will preserve all the pixels seen on the screen.
>
>> @aivanov-jdk The extra pixel seems to be added due to JInternalFrame titlebar and not from the paintBorder() code changes.
> 
> Good then. It's not from the border.

@aivanov-jdk Fix has been updated since last approval. Can you please re-review.

-------------

PR: https://git.openjdk.org/jdk/pull/10274


From prr at openjdk.org  Mon Oct 31 22:02:15 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 31 Oct 2022 22:02:15 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

Deprecate URL constructors.
Developers are encouraged to use java.net.URI to parse or construct any URL.
...
To construct a URL, using URI::toURL should be preferred.

You have jumped through some refactoring hoops to be able to apply the deprecation suppression
to as little code as possible .. having made such changes, then why didn't you just make the
recommended change instead ?

Should I presume that the recommended route will have some nasty little incompatibilities
we will need to be careful of first ?

And what about Peter Firmstone's comment
"We stopped using java.net.URI some years ago as it's obsolete.?"

I can't reconcile that with the recommendation to use it ..

-------------

PR: https://git.openjdk.org/jdk/pull/10874


From magare31 at gmail.com  Tue Oct 11 01:36:13 2022
From: magare31 at gmail.com (magare31 at gmail.com)
Date: Tue, 11 Oct 2022 01:36:13 -0000
Subject: professional (24-bit) sampled audio support in the Windows native
 implementation of libjsound
In-Reply-To: <5ca697e2-fd4f-8a4b-9f98-b536ed5bb2a7@oracle.com>
References: <02e901d8d4c0$7dd12ee0$79738ca0$@gmail.com>
 <506f19c5-28ae-e606-e7f1-22464793afcb@oracle.com>
 <028e01d8dbef$69b25070$3d16f150$@gmail.com>
 <5ca697e2-fd4f-8a4b-9f98-b536ed5bb2a7@oracle.com>
Message-ID: <036c01d8dd11$d637e700$82a7b500$@gmail.com>

I understand that my bug submission was not clear.  Here are most of the things you requested.  Let me know if you need more.  Thank you again.

 

*	Test: See the attached Java code with two simple tests.  The code is very short and I think I put sufficient comments to make these clear.  But let me know if you need more.  (See below on regression testing).

*	On Windows, with the current jdk, both tests fail.  I am testing on an audio device that supports 24-bit audio resolution.  The code: 1) shows that the audio device does NOT supports 24-bit; 2) cannot get a 24-bit line to the audio device.
*	With the two minor changes below, the code will succeed in both tests (see more on testing below).

*	Fix: See the attached C++ code with the fix (the diff is below).  In the JDK source, this file is in src/java.desktop/windows/native/libjsound.  The fix is in the native Windows code only.
*	Diff:  There are changes to two lines only in the Windows native C++ code.

*	Line 282 changes from 

 

static INT32 bitsArray[] = { 8, 16};

 

to

 

static INT32 bitsArray[] = { 8, 16, 24};

 

*	Line 643 changes from

    

if (channels <= 2 && bits <= 16) {

 

to

 

if (channels <= 2 && bits <= 24) {

 

*	Explanation: The first change allows the native implementation to recognize 24 bit as a format that an audio device may support.  The second change allows the native code to treat the 24-bit signed integer representation of sampled audio data as pulse code modulation (PCM) audio data.  This is the correct way to treat such data.

*	JDK 19 without the fix, treats 24-bit audio data as one that needs the extensible wave format.  This is not correct (see lines 643 to 653 of the code).  In fact, the extensible wave format probably does not belong at all in a communication with an audio device, but I don't want to venture that far in changing the code.

*	Regression testing is limited: First, I admit that I do not have a full range of tests.  Second, I am testing as part of a larger piece of sound production software that I cannot share.  Unfortunately, at this point, I can only confirm the following:

*	On Windows, a full build of the jdk, with these changes, from a recent clone of the repository (from Sep 27) works as intended.  It permits 24-bit playback and recording at various sampling rates.
*	Importantly, on Windows, the native query in the JDK of what audio formats are supported by the audio hardware was never fully implemented in JDK 19 or previous.  Whatever bit resolution is included in line 282 of the C++ code will be shown as "supported" (the first test).  This is not ideal, but it is the same as the current implementation.  
*	JDK 19 on Mac OS (Mojave) supports 24 bit playback (I have not tested recording yet).
*	JDK 19 on Ubuntu 20 supports 24 bit playback and 24 bit recording.

 

 

 

 

From: Aleksei Ivanov <alexey.ivanov at oracle.com> 
Sent: Monday, October 10, 2022 5:03 PM
To: magare31 at gmail.com <mailto:magare31 at gmail.com> ; client-libs-dev at openjdk.org <mailto:client-libs-dev at openjdk.org> 
Subject: Re: professional (24-bit) sampled audio support in the Windows native implementation of libjsound

 

Hi,

JDK-8294904 [1] was resolved as Incomplete because there's no sample code which demonstrates the problem. A comment was added:

Mail to submitter: 
============= 
Please share standalone test case/ reproducible step/ scenario to analyze the issue better.

I should have received an email with request for clarification.

I looked through the description but it's still unclear to me how to reproduce the problem and how to incorporate the fix you're proposing and what the fix is. If you could provide the test case and better yet the fix along with a regression test, it would be greatly appreciated.

The fix in the form of the diff would also help.

-- 
Regards,
Alexey

[1] https://bugs.openjdk.org/browse/JDK-8294904

On 09/10/2022 15:57, magare31 at gmail.com <mailto:magare31 at gmail.com>  wrote:

Since I am new to this, and apologies for the broad email, could someone explain the following for the corresponding bug (JDK-8294904)?

 

1.	This bug is listed as one for a generic OS, whereas I specified Windows (I can confirm that it is Windows only).
2.	This bug is listed as "resolved" with an "incomplete resolution".  I did provide the full solution, so I am not sure what this means.  (Also, Oracle asked for a standalone test, which I also provided over email)

 

And thanks.

 

From: Kevin Rushforth  <mailto:kevin.rushforth at oracle.com> <kevin.rushforth at oracle.com> 
Sent: Friday, September 30, 2022 8:29 AM
To: magare31 at gmail.com <mailto:magare31 at gmail.com> ; client-libs-dev at openjdk.org <mailto:client-libs-dev at openjdk.org> ; core-libs-dev at openjdk.org <mailto: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/20221011/6147c553/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main.java
Type: application/octet-stream
Size: 2488 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221011/6147c553/Main.java>
-------------- next part --------------
/*
 * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.  Oracle designates this
 * particular file as subject to the "Classpath" exception as provided
 * by Oracle in the LICENSE file that accompanied this code.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

#define USE_ERROR
#define USE_TRACE

/* define this for the silencing/servicing code. Requires USE_TRACE */
//#define USE_DEBUG_SILENCING

#ifndef WIN32_EXTRA_LEAN
#define WIN32_EXTRA_LEAN
#endif
#ifndef WIN32_LEAN_AND_MEAN
#define WIN32_LEAN_AND_MEAN
#endif

#include <windows.h>
#include <mmsystem.h>
#include <string.h>

/* include DirectSound headers */
#include <dsound.h>

/* include Java Sound specific headers as C code */
#ifdef __cplusplus
extern "C" {
#endif
 #include "DirectAudio.h"
#ifdef __cplusplus
}
#endif

/* include to prevent charset problem */
#include "PLATFORM_API_WinOS_Charset_Util.h"

#ifdef USE_DEBUG_SILENCING
#define DEBUG_SILENCING0(p) TRACE0(p)
#define DEBUG_SILENCING1(p1,p2) TRACE1(p1,p2)
#define DEBUG_SILENCING2(p1,p2,p3) TRACE2(p1,p2,p3)
#else
#define DEBUG_SILENCING0(p)
#define DEBUG_SILENCING1(p1,p2)
#define DEBUG_SILENCING2(p1,p2,p3)
#endif


//cak #if USE_DAUDIO == TRUE

/* 3 seconds to wait before device list is re-read */
#define WAIT_BETWEEN_CACHE_REFRESH_MILLIS 3000

/* maximum number of supported devices, playback+capture */
#define MAX_DS_DEVICES 60

typedef struct {
    INT32 mixerIndex;
    BOOL isSource;
    /* either LPDIRECTSOUND or LPDIRECTSOUNDCAPTURE */
    void* dev;
    /* how many instances use the dev */
    INT32 refCount;
    GUID guid;
} DS_AudioDeviceCache;

static DS_AudioDeviceCache g_audioDeviceCache[MAX_DS_DEVICES];
static INT32 g_cacheCount = 0;
static UINT64 g_lastCacheRefreshTime = 0;
static INT32 g_mixerCount = 0;

BOOL DS_lockCache() {
    /* dummy implementation for now, Java does locking */
    return TRUE;
}

void DS_unlockCache() {
    /* dummy implementation for now */
}

static GUID CLSID_DAUDIO_Zero = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};

BOOL isEqualGUID(LPGUID lpGuid1, LPGUID lpGuid2) {
    if (lpGuid1 == NULL || lpGuid2 == NULL) {
        if (lpGuid1 == lpGuid2) {
            return TRUE;
        }
        if (lpGuid1 == NULL) {
            lpGuid1 = (LPGUID) (&CLSID_DAUDIO_Zero);
        } else {
            lpGuid2 = (LPGUID) (&CLSID_DAUDIO_Zero);
        }
    }
    return memcmp(lpGuid1, lpGuid2, sizeof(GUID)) == 0;
}

INT32 findCacheItemByGUID(LPGUID lpGuid, BOOL isSource) {
    int i;
    for (i = 0; i < g_cacheCount; i++) {
        if (isSource == g_audioDeviceCache[i].isSource
            && isEqualGUID(lpGuid, &(g_audioDeviceCache[i].guid))) {
            return i;
        }
    }
    return -1;
}

INT32 findCacheItemByMixerIndex(INT32 mixerIndex) {
    int i;
    for (i = 0; i < g_cacheCount; i++) {
        if (g_audioDeviceCache[i].mixerIndex == mixerIndex) {
            return i;
        }
    }
    return -1;
}

typedef struct {
    INT32 currMixerIndex;
    BOOL isSource;
} DS_RefreshCacheStruct;


BOOL CALLBACK DS_RefreshCacheEnum(LPGUID lpGuid,
                                  LPCSTR lpstrDescription,
                                  LPCSTR lpstrModule,
                                  DS_RefreshCacheStruct* rs) {
    INT32 cacheIndex = findCacheItemByGUID(lpGuid, rs->isSource);
    /*TRACE3("Enumerating %d: %s (%s)\n", cacheIndex, lpstrDescription, lpstrModule);*/
    if (cacheIndex == -1) {
        /* add this device */
        if (g_cacheCount < MAX_DS_DEVICES-1) {
            g_audioDeviceCache[g_cacheCount].mixerIndex = rs->currMixerIndex;
            g_audioDeviceCache[g_cacheCount].isSource = rs->isSource;
            g_audioDeviceCache[g_cacheCount].dev = NULL;
            g_audioDeviceCache[g_cacheCount].refCount = 0;
            if (lpGuid == NULL) {
                memset(&(g_audioDeviceCache[g_cacheCount].guid), 0, sizeof(GUID));
            } else {
                memcpy(&(g_audioDeviceCache[g_cacheCount].guid), lpGuid, sizeof(GUID));
            }
            g_cacheCount++;
            rs->currMixerIndex++;
        } else {
            /* failure case: more than MAX_DS_DEVICES available... */
        }
    } else {
        /* device already exists in cache... update mixer number */
        g_audioDeviceCache[cacheIndex].mixerIndex = rs->currMixerIndex;
        rs->currMixerIndex++;
    }
    /* continue enumeration */
    return TRUE;
}

///// implemented functions of DirectAudio.h

INT32 DAUDIO_GetDirectAudioDeviceCount() {
    DS_RefreshCacheStruct rs;
    INT32 oldCount;
    INT32 cacheIndex;

    if (!DS_lockCache()) {
        return 0;
    }

    if (g_lastCacheRefreshTime == 0
        || (UINT64) timeGetTime() > (UINT64) (g_lastCacheRefreshTime + WAIT_BETWEEN_CACHE_REFRESH_MILLIS)) {
        /* first, initialize any old cache items */
        for (cacheIndex = 0; cacheIndex < g_cacheCount; cacheIndex++) {
            g_audioDeviceCache[cacheIndex].mixerIndex = -1;
        }

        /* enumerate all devices and either add them to the device cache,
         * or refresh the mixer number
         */
        rs.currMixerIndex = 0;
        rs.isSource = TRUE;
        DirectSoundEnumerate((LPDSENUMCALLBACK) DS_RefreshCacheEnum, &rs);
        /* if we only got the Primary Sound Driver (GUID=NULL),
         * then there aren't any playback devices installed */
        if (rs.currMixerIndex == 1) {
            cacheIndex = findCacheItemByGUID(NULL, TRUE);
            if (cacheIndex == 0) {
                rs.currMixerIndex = 0;
                g_audioDeviceCache[0].mixerIndex = -1;
                TRACE0("Removing stale Primary Sound Driver from list.\n");
            }
        }
        oldCount = rs.currMixerIndex;
        rs.isSource = FALSE;
        DirectSoundCaptureEnumerate((LPDSENUMCALLBACK) DS_RefreshCacheEnum, &rs);
        /* if we only got the Primary Sound Capture Driver (GUID=NULL),
         * then there aren't any capture devices installed */
        if ((rs.currMixerIndex - oldCount) == 1) {
            cacheIndex = findCacheItemByGUID(NULL, FALSE);
            if (cacheIndex != -1) {
                rs.currMixerIndex = oldCount;
                g_audioDeviceCache[cacheIndex].mixerIndex = -1;
                TRACE0("Removing stale Primary Sound Capture Driver from list.\n");
            }
        }
        g_mixerCount = rs.currMixerIndex;

        g_lastCacheRefreshTime = (UINT64) timeGetTime();
    }
    DS_unlockCache();
    /*TRACE1("DirectSound: %d installed devices\n", g_mixerCount);*/
    return g_mixerCount;
}

BOOL CALLBACK DS_GetDescEnum(LPGUID lpGuid,
                             LPCWSTR lpstrDescription,
                             LPCWSTR lpstrModule,
                             DirectAudioDeviceDescription* desc) {

    INT32 cacheIndex = findCacheItemByGUID(lpGuid, g_audioDeviceCache[desc->deviceID].isSource);
    if (cacheIndex == desc->deviceID) {
        UnicodeToUTF8AndCopy(desc->name, lpstrDescription, DAUDIO_STRING_LENGTH);
        //strncpy(desc->description, lpstrModule, DAUDIO_STRING_LENGTH);
        desc->maxSimulLines = -1;
        /* do not continue enumeration */
        return FALSE;
    }
    return TRUE;
}


INT32 DAUDIO_GetDirectAudioDeviceDescription(INT32 mixerIndex, DirectAudioDeviceDescription* desc) {

    if (!DS_lockCache()) {
        return FALSE;
    }

    /* set the deviceID field to the cache index */
    desc->deviceID = findCacheItemByMixerIndex(mixerIndex);
    if (desc->deviceID < 0) {
        DS_unlockCache();
        return FALSE;
    }
    desc->maxSimulLines = 0;
    if (g_audioDeviceCache[desc->deviceID].isSource) {
        DirectSoundEnumerateW((LPDSENUMCALLBACKW) DS_GetDescEnum, desc);
        strncpy(desc->description, "DirectSound Playback", DAUDIO_STRING_LENGTH);
    } else {
        DirectSoundCaptureEnumerateW((LPDSENUMCALLBACKW) DS_GetDescEnum, desc);
        strncpy(desc->description, "DirectSound Capture", DAUDIO_STRING_LENGTH);
    }

    /*desc->vendor;
    desc->version;*/

    DS_unlockCache();
    return (desc->maxSimulLines == -1)?TRUE:FALSE;
}

/* multi-channel info: http://www.microsoft.com/whdc/hwdev/tech/audio/multichaud.mspx */

//static UINT32 sampleRateArray[] = { 8000, 11025, 16000, 22050, 32000, 44100, 48000, 56000, 88000, 96000, 172000, 192000 };
static INT32 sampleRateArray[] = { -1 };
static INT32 channelsArray[] = { 1, 2};
static INT32 bitsArray[] = { 8, 16, 24};

#define SAMPLERATE_COUNT sizeof(sampleRateArray)/sizeof(INT32)
#define CHANNELS_COUNT sizeof(channelsArray)/sizeof(INT32)
#define BITS_COUNT sizeof(bitsArray)/sizeof(INT32)

void DAUDIO_GetFormats(INT32 mixerIndex, INT32 deviceID, int isSource, void* creator) {

    int rateIndex, channelIndex, bitIndex;

    /* no need to lock, since deviceID identifies the device sufficiently */

    /* sanity */
    if (deviceID >= g_cacheCount) {
        return;
    }
    if ((g_audioDeviceCache[deviceID].isSource && !isSource)
        || (!g_audioDeviceCache[deviceID].isSource && isSource)) {
        /* only support Playback or Capture */
        return;
    }

    for (rateIndex = 0; rateIndex < SAMPLERATE_COUNT; rateIndex++) {
        for (channelIndex = 0; channelIndex < CHANNELS_COUNT; channelIndex++) {
            for (bitIndex = 0; bitIndex < BITS_COUNT; bitIndex++) {
                DAUDIO_AddAudioFormat(creator, bitsArray[bitIndex],
                                      ((bitsArray[bitIndex] + 7) / 8) * channelsArray[channelIndex],
                                      channelsArray[channelIndex],
                                      (float) sampleRateArray[rateIndex],
                                      DAUDIO_PCM,
                                      (bitsArray[bitIndex]==8)?FALSE:TRUE,  /* signed */
                                      (bitsArray[bitIndex]==8)?FALSE:
#ifndef _LITTLE_ENDIAN
                                      TRUE /* big endian */
#else
                                      FALSE /* little endian */
#endif
                                      );
            }
        }
    }
}

typedef struct {
    int deviceID;
    /* for convenience */
    BOOL isSource;
    /* the secondary buffer (Playback) */
    LPDIRECTSOUNDBUFFER playBuffer;
    /* the secondary buffer (Capture) */
    LPDIRECTSOUNDCAPTUREBUFFER captureBuffer;

    /* size of the directsound buffer, usually 2 seconds */
    int dsBufferSizeInBytes;

    /* size of the read/write-ahead, as specified by Java */
    int bufferSizeInBytes;
    int bitsPerSample;
    int frameSize; // storage size in Bytes

    UINT64 framePos;
    /* where to write into the buffer.
     * -1 if at current position (Playback)
     * For Capture, this is the read position
     */
    int writePos;

    /* if start() had been called */
    BOOL started;

    /* how many bytes there is silence from current write position */
    int silencedBytes;

    BOOL underrun;

} DS_Info;


LPCSTR TranslateDSError(HRESULT hr) {
    switch(hr) {
        case DSERR_ALLOCATED:
            return "DSERR_ALLOCATED";

        case DSERR_CONTROLUNAVAIL:
            return "DSERR_CONTROLUNAVAIL";

        case DSERR_INVALIDPARAM:
            return "DSERR_INVALIDPARAM";

        case DSERR_INVALIDCALL:
            return "DSERR_INVALIDCALL";

        case DSERR_GENERIC:
            return "DSERR_GENERIC";

        case DSERR_PRIOLEVELNEEDED:
            return "DSERR_PRIOLEVELNEEDED";

        case DSERR_OUTOFMEMORY:
            return "DSERR_OUTOFMEMORY";

        case DSERR_BADFORMAT:
            return "DSERR_BADFORMAT";

        case DSERR_UNSUPPORTED:
            return "DSERR_UNSUPPORTED";

        case DSERR_NODRIVER:
            return "DSERR_NODRIVER";

        case DSERR_ALREADYINITIALIZED:
            return "DSERR_ALREADYINITIALIZED";

        case DSERR_NOAGGREGATION:
            return "DSERR_NOAGGREGATION";

        case DSERR_BUFFERLOST:
            return "DSERR_BUFFERLOST";

        case DSERR_OTHERAPPHASPRIO:
            return "DSERR_OTHERAPPHASPRIO";

        case DSERR_UNINITIALIZED:
            return "DSERR_UNINITIALIZED";

        default:
            return "Unknown HRESULT";
        }
}

/*
** data/routines for starting DS buffers by separate thread
** (joint into DS_StartBufferHelper class)
** see cr6372428: playback fails after exiting from thread that has started it
** due IDirectSoundBuffer8::Play() description:
** http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c
**       /directx/htm/idirectsoundbuffer8play.asp
** (remark section): If the application is multithreaded, the thread that plays
** the buffer must continue to exist as long as the buffer is playing.
** Buffers created on WDM drivers stop playing when the thread is terminated.
** IDirectSoundCaptureBuffer8::Start() has the same remark:
** http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c
**       /directx/htm/idirectsoundcapturebuffer8start.asp
*/
class DS_StartBufferHelper {
public:
    /* starts DirectSound buffer (playback or capture) */
    static HRESULT StartBuffer(DS_Info* info);
    /* checks for initialization success */
    static inline BOOL isInitialized() { return data.threadHandle != NULL; }
protected:
    DS_StartBufferHelper() {}  // no need to create an instance

    /* data class */
    class Data {
    public:
        Data();
        ~Data();
        // public data to access from parent class
        CRITICAL_SECTION crit_sect;
        volatile HANDLE threadHandle;
        volatile HANDLE startEvent;
        volatile HANDLE startedEvent;
        volatile DS_Info* line2Start;
        volatile HRESULT startResult;
    } static data;

    /* StartThread function */
    static DWORD WINAPI __stdcall ThreadProc(void *param);
};

/* StartBufferHelper class implementation
*/
DS_StartBufferHelper::Data DS_StartBufferHelper::data;

DS_StartBufferHelper::Data::Data() {
    threadHandle = NULL;
    ::InitializeCriticalSection(&crit_sect);
    startEvent = ::CreateEvent(NULL, FALSE, FALSE, NULL);
    startedEvent = ::CreateEvent(NULL, FALSE, FALSE, NULL);
    if (startEvent != NULL && startedEvent != NULL)
        threadHandle = ::CreateThread(NULL, 0, ThreadProc, NULL, 0, NULL);
}

DS_StartBufferHelper::Data::~Data() {
    ::EnterCriticalSection(&crit_sect);
    if (threadHandle != NULL) {
        // terminate thread
        line2Start = NULL;
        ::SetEvent(startEvent);
        ::CloseHandle(threadHandle);
        threadHandle = NULL;
    }
    ::LeaveCriticalSection(&crit_sect);
    // won't delete startEvent/startedEvent/crit_sect
    // - Windows will do during process shutdown
}

DWORD WINAPI __stdcall DS_StartBufferHelper::ThreadProc(void *param)
{
    ::CoInitialize(NULL);
    while (1) {
        // wait for something to do
        ::WaitForSingleObject(data.startEvent, INFINITE);
        if (data.line2Start == NULL) {
            // (data.line2Start == NULL) is a signal to terminate thread
            break;
        }
        if (data.line2Start->isSource) {
            data.startResult =
                data.line2Start->playBuffer->Play(0, 0, DSBPLAY_LOOPING);
        } else {
            data.startResult =
                data.line2Start->captureBuffer->Start(DSCBSTART_LOOPING);
        }
        ::SetEvent(data.startedEvent);
    }
    ::CoUninitialize();
    return 0;
}

HRESULT DS_StartBufferHelper::StartBuffer(DS_Info* info) {
    HRESULT hr;
    ::EnterCriticalSection(&data.crit_sect);
    if (!isInitialized()) {
        ::LeaveCriticalSection(&data.crit_sect);
        return E_FAIL;
    }
    data.line2Start = info;
    ::SetEvent(data.startEvent);
    ::WaitForSingleObject(data.startedEvent, INFINITE);
    hr = data.startResult;
    ::LeaveCriticalSection(&data.crit_sect);
    return hr;
}


/* helper routines for DS buffer positions */
/* returns distance from pos1 to pos2
 */
inline int DS_getDistance(DS_Info* info, int pos1, int pos2) {
    int distance = pos2 - pos1;
    while (distance < 0)
        distance += info->dsBufferSizeInBytes;
    return distance;
}

/* adds 2 positions
 */
inline int DS_addPos(DS_Info* info, int pos1, int pos2) {
    int result = pos1 + pos2;
    while (result >= info->dsBufferSizeInBytes)
        result -= info->dsBufferSizeInBytes;
    return result;
}


BOOL DS_addDeviceRef(INT32 deviceID) {
    HWND ownerWindow;
    HRESULT res = DS_OK;
    LPDIRECTSOUND devPlay;
    LPDIRECTSOUNDCAPTURE devCapture;
    LPGUID lpGuid = NULL;


    if (g_audioDeviceCache[deviceID].dev == NULL) {
        /* Create DirectSound */
        TRACE1("Creating DirectSound object for device %d\n", deviceID);
        lpGuid = &(g_audioDeviceCache[deviceID].guid);
        if (isEqualGUID(lpGuid, NULL)) {
            lpGuid = NULL;
        }
        if (g_audioDeviceCache[deviceID].isSource) {
            res = DirectSoundCreate(lpGuid, &devPlay, NULL);
            g_audioDeviceCache[deviceID].dev = (void*) devPlay;
        } else {
            res = DirectSoundCaptureCreate(lpGuid, &devCapture, NULL);
            g_audioDeviceCache[deviceID].dev = (void*) devCapture;
        }
        g_audioDeviceCache[deviceID].refCount = 0;
        if (FAILED(res)) {
            ERROR1("DAUDIO_Open: ERROR: Failed to create DirectSound: %s", TranslateDSError(res));
            g_audioDeviceCache[deviceID].dev = NULL;
            return FALSE;
        }
        if (g_audioDeviceCache[deviceID].isSource) {
            ownerWindow = GetForegroundWindow();
            if (ownerWindow == NULL) {
                ownerWindow = GetDesktopWindow();
            }
            TRACE0("DAUDIO_Open: Setting cooperative level\n");
            res = devPlay->SetCooperativeLevel(ownerWindow, DSSCL_NORMAL);
            if (FAILED(res)) {
                ERROR1("DAUDIO_Open: ERROR: Failed to set cooperative level: %s", TranslateDSError(res));
                return FALSE;
            }
        }
    }
    g_audioDeviceCache[deviceID].refCount++;
    return TRUE;
}

#define DEV_PLAY(devID)    ((LPDIRECTSOUND) g_audioDeviceCache[devID].dev)
#define DEV_CAPTURE(devID) ((LPDIRECTSOUNDCAPTURE) g_audioDeviceCache[devID].dev)

void DS_removeDeviceRef(INT32 deviceID) {

    if (g_audioDeviceCache[deviceID].refCount) {
        g_audioDeviceCache[deviceID].refCount--;
    }
    if (g_audioDeviceCache[deviceID].refCount == 0) {
        if (g_audioDeviceCache[deviceID].dev != NULL) {
            if (g_audioDeviceCache[deviceID].isSource) {
                DEV_PLAY(deviceID)->Release();
            } else {
                DEV_CAPTURE(deviceID)->Release();
            }
            g_audioDeviceCache[deviceID].dev = NULL;
        }
    }
}

#ifndef _WAVEFORMATEXTENSIBLE_
#define _WAVEFORMATEXTENSIBLE_
typedef struct {
    WAVEFORMATEX    Format;
    union {
        WORD wValidBitsPerSample;       /* bits of precision  */
        WORD wSamplesPerBlock;          /* valid if wBitsPerSample==0 */
        WORD wReserved;                 /* If neither applies, set to zero. */
    } Samples;
    DWORD           dwChannelMask;      /* which channels are */
                                        /* present in stream  */
    GUID            SubFormat;
} WAVEFORMATEXTENSIBLE, *PWAVEFORMATEXTENSIBLE;
#endif // !_WAVEFORMATEXTENSIBLE_

#if !defined(WAVE_FORMAT_EXTENSIBLE)
#define  WAVE_FORMAT_EXTENSIBLE                 0xFFFE
#endif // !defined(WAVE_FORMAT_EXTENSIBLE)

#if !defined(DEFINE_WAVEFORMATEX_GUID)
#define DEFINE_WAVEFORMATEX_GUID(x) (USHORT)(x), 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71
#endif
#ifndef STATIC_KSDATAFORMAT_SUBTYPE_PCM
#define STATIC_KSDATAFORMAT_SUBTYPE_PCM\
    DEFINE_WAVEFORMATEX_GUID(WAVE_FORMAT_PCM)
#endif


void createWaveFormat(WAVEFORMATEXTENSIBLE* format,
                      int sampleRate,
                      int channels,
                      int bits,
                      int significantBits) {
    GUID subtypePCM = {STATIC_KSDATAFORMAT_SUBTYPE_PCM};
    format->Format.nSamplesPerSec = (DWORD)sampleRate;
    format->Format.nChannels = (WORD) channels;
    /* do not support useless padding, like 24-bit samples stored in 32-bit containers */
    format->Format.wBitsPerSample = (WORD) ((bits + 7) & 0xFFF8);

    if (channels <= 2 && bits <= 24) {
        format->Format.wFormatTag = WAVE_FORMAT_PCM;
        format->Format.cbSize = 0;
    } else {
        format->Format.wFormatTag = WAVE_FORMAT_EXTENSIBLE;
        format->Format.cbSize = 22;
        format->Samples.wValidBitsPerSample = bits;
        /* no way to specify speaker locations */
        format->dwChannelMask = 0xFFFFFFFF;
        format->SubFormat = subtypePCM;
    }
    format->Format.nBlockAlign = (WORD)((format->Format.wBitsPerSample * format->Format.nChannels) / 8);
    format->Format.nAvgBytesPerSec = format->Format.nSamplesPerSec * format->Format.nBlockAlign;
}

/* fill buffer with silence
 */
void DS_clearBuffer(DS_Info* info, BOOL fromWritePos) {
    UBYTE* pb1=NULL, *pb2=NULL;
    DWORD  cb1=0, cb2=0;
    DWORD flags = 0;
    int start, count;
    TRACE1("> DS_clearBuffer for device %d\n", info->deviceID);
    if (info->isSource)  {
        if (fromWritePos) {
                DWORD playCursor, writeCursor;
                int end;
                if (FAILED(info->playBuffer->GetCurrentPosition(&playCursor, &writeCursor))) {
                    ERROR0("  DS_clearBuffer: ERROR: Failed to get current position.");
                    TRACE0("< DS_clearbuffer\n");
                    return;
                }
                DEBUG_SILENCING2("  DS_clearBuffer: DS playPos=%d  myWritePos=%d", (int) playCursor, (int) info->writePos);
                if (info->writePos >= 0) {
                    start = info->writePos + info->silencedBytes;
                } else {
                    start = writeCursor + info->silencedBytes;
                    //flags |= DSBLOCK_FROMWRITECURSOR;
                }
                while (start >= info->dsBufferSizeInBytes) {
                    start -= info->dsBufferSizeInBytes;
                }

                // fix for bug 6251460 (REGRESSION: short sounds do not play)
                // for unknown reason with hardware DS buffer playCursor sometimes
                // jumps back for little interval (mostly 2-8 bytes) (writeCursor moves forward as usual)
                // The issue happens right after start playing and for short sounds only (less then DS buffer,
                // when whole sound written into the buffer and remaining space filled by silence)
                // the case doesn't produce any audible aftifacts so just catch it to prevent filling
                // whole buffer by silence.
                if (((int)playCursor <= start && start < (int)writeCursor)
                    || (writeCursor < playCursor    // buffer bound is between playCursor & writeCursor
                        && (start < (int)writeCursor || (int)playCursor <= start))) {
                    return;
                }

                count = info->dsBufferSizeInBytes - info->silencedBytes;
                // why / 4?
                //if (count > info->dsBufferSizeInBytes / 4) {
                //    count = info->dsBufferSizeInBytes / 4;
                //}
                end = start + count;
                if ((int) playCursor < start) {
                    playCursor += (DWORD) info->dsBufferSizeInBytes;
                }
                if (start <= (int) playCursor && end > (int) playCursor) {
                    /* at maximum, silence until play cursor */
                    count = (int) playCursor - start;
#ifdef USE_TRACE
                    if ((int) playCursor >= info->dsBufferSizeInBytes) playCursor -= (DWORD) info->dsBufferSizeInBytes;
                    TRACE3("\n  DS_clearBuffer: Start Writing from %d, "
                           "would overwrite playCursor=%d, so reduce count to %d\n",
                           start, playCursor, count);
#endif
                }
                DEBUG_SILENCING2("  clearing buffer from %d, count=%d. ", (int)start, (int) count);
                if (count <= 0) {
                    DEBUG_SILENCING0("\n");
                    TRACE1("< DS_clearBuffer: no need to clear, silencedBytes=%d\n", info->silencedBytes);
                    return;
                }
        } else {
                start = 0;
                count = info->dsBufferSizeInBytes;
                flags |= DSBLOCK_ENTIREBUFFER;
        }
        if (FAILED(info->playBuffer->Lock(start,
                                          count,
                                          (LPVOID*) &pb1, &cb1,
                                          (LPVOID*) &pb2, &cb2, flags))) {
            ERROR0("\n  DS_clearBuffer: ERROR: Failed to lock sound buffer.\n");
            TRACE0("< DS_clearbuffer\n");
            return;
        }
    } else {
        if (FAILED(info->captureBuffer->Lock(0,
                                             info->dsBufferSizeInBytes,
                                             (LPVOID*) &pb1, &cb1,
                                             (LPVOID*) &pb2, &cb2, DSCBLOCK_ENTIREBUFFER))) {
            ERROR0("  DS_clearBuffer: ERROR: Failed to lock sound buffer.\n");
            TRACE0("< DS_clearbuffer\n");
            return;
        }
    }
    if (pb1!=NULL) {
        memset(pb1, (info->bitsPerSample == 8)?128:0, cb1);
    }
    if (pb2!=NULL) {
        memset(pb2, (info->bitsPerSample == 8)?128:0, cb2);
    }
    if (info->isSource)  {
        info->playBuffer->Unlock( pb1, cb1, pb2, cb2 );
        if (!fromWritePos) {
            /* doesn't matter where to start writing next time */
            info->writePos = -1;
            info->silencedBytes = info->dsBufferSizeInBytes;
        } else {
            info->silencedBytes += (cb1+cb2);
            if (info->silencedBytes > info->dsBufferSizeInBytes) {
                ERROR1("  DS_clearbuffer: ERROR: silencedBytes=%d exceeds buffer size!\n",
                       info->silencedBytes);
                info->silencedBytes = info->dsBufferSizeInBytes;
            }
        }
        DEBUG_SILENCING2("  silencedBytes=%d, my writePos=%d\n", (int)info->silencedBytes, (int)info->writePos);
    } else {
        info->captureBuffer->Unlock( pb1, cb1, pb2, cb2 );
    }
    TRACE0("< DS_clearbuffer\n");
}

/* returns pointer to buffer */
void* DS_createSoundBuffer(DS_Info* info,
                          float sampleRate,
                          int sampleSizeInBits,
                          int channels,
                          int bufferSizeInBytes) {
    DSBUFFERDESC dsbdesc;
    DSCBUFFERDESC dscbdesc;
    HRESULT res;
    WAVEFORMATEXTENSIBLE format;
    void* buffer;

    TRACE1("Creating secondary buffer for device %d\n", info->deviceID);
    createWaveFormat(&format,
                     (int) sampleRate,
                     channels,
                     info->frameSize / channels * 8,
                     sampleSizeInBits);

    /* 2 second secondary buffer */
    info->dsBufferSizeInBytes = 2 * ((int) sampleRate) * info->frameSize;

    if (bufferSizeInBytes > info->dsBufferSizeInBytes / 2) {
        bufferSizeInBytes = info->dsBufferSizeInBytes / 2;
    }
    bufferSizeInBytes = (bufferSizeInBytes / info->frameSize) * info->frameSize;
    info->bufferSizeInBytes = bufferSizeInBytes;

    if (info->isSource) {
        memset(&dsbdesc, 0, sizeof(DSBUFFERDESC));
        dsbdesc.dwSize = sizeof(DSBUFFERDESC);
        dsbdesc.dwFlags = DSBCAPS_GETCURRENTPOSITION2
                    | DSBCAPS_GLOBALFOCUS;

        dsbdesc.dwBufferBytes = info->dsBufferSizeInBytes;
        dsbdesc.lpwfxFormat = (WAVEFORMATEX*) &format;
        res = DEV_PLAY(info->deviceID)->CreateSoundBuffer
            (&dsbdesc, (LPDIRECTSOUNDBUFFER*) &buffer, NULL);
    } else {
        memset(&dscbdesc, 0, sizeof(DSCBUFFERDESC));
        dscbdesc.dwSize = sizeof(DSCBUFFERDESC);
        dscbdesc.dwFlags = 0;
        dscbdesc.dwBufferBytes = info->dsBufferSizeInBytes;
        dscbdesc.lpwfxFormat = (WAVEFORMATEX*) &format;
        res = DEV_CAPTURE(info->deviceID)->CreateCaptureBuffer
            (&dscbdesc, (LPDIRECTSOUNDCAPTUREBUFFER*) &buffer, NULL);
    }
    if (FAILED(res)) {
        ERROR1("DS_createSoundBuffer: ERROR: Failed to create sound buffer: %s", TranslateDSError(res));
        return NULL;
    }
    return buffer;
}

void DS_destroySoundBuffer(DS_Info* info) {
    if (info->playBuffer != NULL) {
        info->playBuffer->Release();
        info->playBuffer = NULL;
    }
    if (info->captureBuffer != NULL) {
        info->captureBuffer->Release();
        info->captureBuffer = NULL;
    }
}


void* DAUDIO_Open(INT32 mixerIndex, INT32 deviceID, int isSource,
                  int encoding, float sampleRate, int sampleSizeInBits,
                  int frameSize, int channels,
                  int isSigned, int isBigEndian, int bufferSizeInBytes) {

    DS_Info* info;
    void* buffer;

    TRACE0("> DAUDIO_Open\n");

    /* some sanity checks */
    if (deviceID >= g_cacheCount) {
        ERROR1("DAUDIO_Open: ERROR: cannot open the device with deviceID=%d!\n", deviceID);
        return NULL;
    }
    if ((g_audioDeviceCache[deviceID].isSource && !isSource)
        || (!g_audioDeviceCache[deviceID].isSource && isSource)) {
        /* only support Playback or Capture */
        ERROR0("DAUDIO_Open: ERROR: Cache is corrupt: cannot open the device in specified isSource mode!\n");
        return NULL;
    }
    if (encoding != DAUDIO_PCM) {
        ERROR1("DAUDIO_Open: ERROR: cannot open the device with encoding=%d!\n", encoding);
        return NULL;
    }
    if (channels <= 0) {
        ERROR1("DAUDIO_Open: ERROR: Invalid number of channels=%d!\n", channels);
        return NULL;
    }
    if (sampleSizeInBits > 8 &&
#ifdef _LITTLE_ENDIAN
        isBigEndian
#else
        !isBigEndian
#endif
        ) {
        ERROR1("DAUDIO_Open: ERROR: wrong endianness: isBigEndian==%d!\n", isBigEndian);
        return NULL;
    }
    if (sampleSizeInBits == 8 && isSigned) {
        ERROR0("DAUDIO_Open: ERROR: wrong signed'ness: with 8 bits, data must be unsigned!\n");
        return NULL;
    }
    if (!DS_StartBufferHelper::isInitialized()) {
        ERROR0("DAUDIO_Open: ERROR: StartBufferHelper initialization was failed!\n");
        return NULL;
    }

    info = (DS_Info*) malloc(sizeof(DS_Info));
    if (!info) {
        ERROR0("DAUDIO_Open: ERROR: Out of memory\n");
        return NULL;
    }
    memset(info, 0, sizeof(DS_Info));

    info->deviceID = deviceID;
    info->isSource = isSource;
    info->bitsPerSample = sampleSizeInBits;
    info->frameSize = frameSize;
    info->framePos = 0;
    info->started = FALSE;
    info->underrun = FALSE;

    if (!DS_addDeviceRef(deviceID)) {
        DS_removeDeviceRef(deviceID);
        free(info);
        return NULL;
    }

    buffer = DS_createSoundBuffer(info,
                                  sampleRate,
                                  sampleSizeInBits,
                                  channels,
                                  bufferSizeInBytes);
    if (!buffer) {
        DS_removeDeviceRef(deviceID);
        free(info);
        return NULL;
    }

    if (info->isSource) {
        info->playBuffer = (LPDIRECTSOUNDBUFFER) buffer;
    } else {
        info->captureBuffer = (LPDIRECTSOUNDCAPTUREBUFFER) buffer;
    }
    DS_clearBuffer(info, FALSE /* entire buffer */);

    /* use writepos of device */
    if (info->isSource) {
        info->writePos = -1;
    } else {
        info->writePos = 0;
    }

    TRACE0("< DAUDIO_Open: Opened device successfully.\n");
    return (void*) info;
}

int DAUDIO_Start(void* id, int isSource) {
    DS_Info* info = (DS_Info*) id;
    HRESULT res = DS_OK;
    DWORD status;

    TRACE0("> DAUDIO_Start\n");

    if (info->isSource)  {
        res = info->playBuffer->GetStatus(&status);
        if (res == DS_OK) {
            if (status & DSBSTATUS_LOOPING) {
                ERROR0("DAUDIO_Start: ERROR: Already started!");
                return TRUE;
            }

            /* only start buffer if already something written to it */
            if (info->writePos >= 0) {
                res = DS_StartBufferHelper::StartBuffer(info);
                if (res == DSERR_BUFFERLOST) {
                    res = info->playBuffer->Restore();
                    if (res == DS_OK) {
                        DS_clearBuffer(info, FALSE /* entire buffer */);
                        /* write() will trigger actual device start */
                    }
                } else {
                    /* make sure that we will have silence after
                       the currently valid audio data */
                    DS_clearBuffer(info, TRUE /* from write position */);
                }
            }
        }
    } else {
        if (info->captureBuffer->GetStatus(&status) == DS_OK) {
            if (status & DSCBSTATUS_LOOPING) {
                ERROR0("DAUDIO_Start: ERROR: Already started!");
                return TRUE;
            }
        }
        res = DS_StartBufferHelper::StartBuffer(info);
    }
    if (FAILED(res)) {
        ERROR1("DAUDIO_Start: ERROR: Failed to start: %s", TranslateDSError(res));
        return FALSE;
    }
    info->started = TRUE;
    return TRUE;
}

int DAUDIO_Stop(void* id, int isSource) {
    DS_Info* info = (DS_Info*) id;

    TRACE0("> DAUDIO_Stop\n");

    info->started = FALSE;
    if (info->isSource)  {
        info->playBuffer->Stop();
    } else {
        info->captureBuffer->Stop();
    }

    TRACE0("< DAUDIO_Stop\n");
    return TRUE;
}


void DAUDIO_Close(void* id, int isSource) {
    DS_Info* info = (DS_Info*) id;

    TRACE0("DAUDIO_Close\n");

    if (info != NULL) {
        DS_destroySoundBuffer(info);
        DS_removeDeviceRef(info->deviceID);
        free(info);
    }
}

/* Check buffer for underrun
 * This method is only meaningful for Output devices (write devices).
 */
void DS_CheckUnderrun(DS_Info* info, DWORD playCursor, DWORD writeCursor) {
    TRACE5("DS_CheckUnderrun: playCursor=%d, writeCursor=%d, "
           "info->writePos=%d  silencedBytes=%d  dsBufferSizeInBytes=%d\n",
           (int) playCursor, (int) writeCursor, (int) info->writePos,
           (int) info->silencedBytes, (int) info->dsBufferSizeInBytes);
    if (info->underrun || info->writePos < 0) return;
    int writeAhead = DS_getDistance(info, writeCursor, info->writePos);
    if (writeAhead > info->bufferSizeInBytes) {
        // this may occur after Stop(), when writeCursor decreases (real valid data size > bufferSizeInBytes)
        // But the case can occur only when we have more then info->bufferSizeInBytes valid bytes
        // (and less then (info->dsBufferSizeInBytes - info->bufferSizeInBytes) silenced bytes)
        // If we already have a lot of silencedBytes after valid data (written by
        // DAUDIO_StillDraining() or DAUDIO_Service()) then it's underrun
        if (info->silencedBytes >= info->dsBufferSizeInBytes - info->bufferSizeInBytes) {
            // underrun!
            ERROR0("DS_CheckUnderrun: ERROR: underrun detected!\n");
            info->underrun = TRUE;
        }
    }
}

/* For source (playback) line:
 *   (a) if (fromPlayCursor == FALSE), returns number of bytes available
 *     for writing: bufferSize - (info->writePos - writeCursor);
 *   (b) if (fromPlayCursor == TRUE), playCursor is used instead writeCursor
 *     and returned value can be used for play position calculation (see also
 *     note about bufferSize)
 * For destination (capture) line:
 *   (c) if (fromPlayCursor == FALSE), returns number of bytes available
 *     for reading from the buffer: readCursor - info->writePos;
 *   (d) if (fromPlayCursor == TRUE), captureCursor is used instead readCursor
 *     and returned value can be used for capture position calculation (see
 *     note about bufferSize)
 * bufferSize parameter are filled by "actual" buffer size:
 *   if (fromPlayCursor == FALSE), bufferSize = info->bufferSizeInBytes
 *   otherwise it increase by number of bytes currently processed by DirectSound
 *     (writeCursor - playCursor) or (captureCursor - readCursor)
 */
int DS_GetAvailable(DS_Info* info,
                    DWORD* playCursor, DWORD* writeCursor,
                    int* bufferSize, BOOL fromPlayCursor) {
    int available;
    int newReadPos;

    TRACE2("DS_GetAvailable: fromPlayCursor=%d,  deviceID=%d\n", fromPlayCursor, info->deviceID);
    if (!info->playBuffer && !info->captureBuffer) {
        ERROR0("DS_GetAvailable: ERROR: buffer not yet created");
        return 0;
    }

    if (info->isSource)  {
        if (FAILED(info->playBuffer->GetCurrentPosition(playCursor, writeCursor))) {
            ERROR0("DS_GetAvailable: ERROR: Failed to get current position.\n");
            return 0;
        }
        int processing = DS_getDistance(info, (int)*playCursor, (int)*writeCursor);
        // workaround: sometimes DirectSound report writeCursor is less (for several bytes) then playCursor
        if (processing > info->dsBufferSizeInBytes / 2) {
            *writeCursor = *playCursor;
            processing = 0;
        }
        TRACE3("   playCursor=%d, writeCursor=%d, info->writePos=%d\n",
               *playCursor, *writeCursor, info->writePos);
        *bufferSize = info->bufferSizeInBytes;
        if (fromPlayCursor) {
            *bufferSize += processing;
        }
        DS_CheckUnderrun(info, *playCursor, *writeCursor);
        if (info->writePos == -1 || (info->underrun && !fromPlayCursor)) {
                /* always full buffer if at beginning */
                available = *bufferSize;
        } else {
            int currWriteAhead = DS_getDistance(info, fromPlayCursor ? (int)*playCursor : (int)*writeCursor, info->writePos);
            if (currWriteAhead > *bufferSize) {
                if (info->underrun) {
                    // playCursor surpassed writePos - no valid data, whole buffer available
                    available = *bufferSize;
                } else {
                    // the case may occur after stop(), when writeCursor jumps back to playCursor
                    // so "actual" buffer size has grown
                    *bufferSize = currWriteAhead;
                    available = 0;
                }
            } else {
                available = *bufferSize - currWriteAhead;
            }
        }
    } else {
        if (FAILED(info->captureBuffer->GetCurrentPosition(playCursor, writeCursor))) {
            ERROR0("DS_GetAvailable: ERROR: Failed to get current position.\n");
            return 0;
        }
        *bufferSize = info->bufferSizeInBytes;
        if (fromPlayCursor) {
            *bufferSize += DS_getDistance(info, (int)*playCursor, (int)*writeCursor);
        }
        TRACE4("   captureCursor=%d, readCursor=%d, info->readPos=%d  refBufferSize=%d\n",
               *playCursor, *writeCursor, info->writePos, *bufferSize);
        if (info->writePos == -1) {
            /* always empty buffer if at beginning */
            info->writePos = (int) (*writeCursor);
        }
        if (fromPlayCursor) {
            available = ((int) (*playCursor) - info->writePos);
        } else {
            available = ((int) (*writeCursor) - info->writePos);
        }
        if (available < 0) {
            available += info->dsBufferSizeInBytes;
        }
        if (!fromPlayCursor && available > info->bufferSizeInBytes) {
            /* overflow */
            ERROR2("DS_GetAvailable: ERROR: overflow detected: "
                   "DirectSoundBufferSize=%d, bufferSize=%d, ",
                   info->dsBufferSizeInBytes, info->bufferSizeInBytes);
            ERROR3("captureCursor=%d, readCursor=%d, info->readPos=%d\n",
                   *playCursor, *writeCursor, info->writePos);
            /* advance read position, to allow exactly one buffer worth of data */
            newReadPos = (int) (*writeCursor) - info->bufferSizeInBytes;
            if (newReadPos < 0) {
                newReadPos += info->dsBufferSizeInBytes;
            }
            info->writePos = newReadPos;
            available = info->bufferSizeInBytes;
        }
    }
    available = (available / info->frameSize) * info->frameSize;

    TRACE1("DS_available: Returning %d available bytes\n", (int) available);
    return available;
}

// returns -1 on error, otherwise bytes written
int DAUDIO_Write(void* id, char* data, int byteSize) {
    DS_Info* info = (DS_Info*) id;
    int available;
    int thisWritePos;
    DWORD playCursor, writeCursor;
    HRESULT res;
    void* buffer1, *buffer2;
    DWORD buffer1len, buffer2len;
    BOOL needRestart = FALSE;
    int bufferLostTrials = 2;
    int bufferSize;

    TRACE1("> DAUDIO_Write %d bytes\n", byteSize);

    while (--bufferLostTrials > 0) {
        available = DS_GetAvailable(info, &playCursor, &writeCursor, &bufferSize, FALSE /* fromPlayCursor */);
        if (byteSize > available) byteSize = available;
        if (byteSize == 0) break;
        thisWritePos = info->writePos;
        if (thisWritePos == -1 || info->underrun) {
            // play from current write cursor after flush, etc.
            needRestart = TRUE;
            thisWritePos = writeCursor;
            info->underrun = FALSE;
        }
        DEBUG_SILENCING2("DAUDIO_Write: writing from %d, count=%d\n", (int) thisWritePos, (int) byteSize);
        res = info->playBuffer->Lock(thisWritePos, byteSize,
                                     (LPVOID *) &buffer1, &buffer1len,
                                     (LPVOID *) &buffer2, &buffer2len,
                                     0);
        if (res != DS_OK) {
            /* some DS failure */
            if (res == DSERR_BUFFERLOST) {
                ERROR0("DAUDIO_write: ERROR: Restoring lost Buffer.");
                if (info->playBuffer->Restore() == DS_OK) {
                    DS_clearBuffer(info, FALSE /* entire buffer */);
                    info->writePos = -1;
                    /* try again */
                    continue;
                }
            }
            /* can't recover from error */
            byteSize = 0;
            break;
        }
        /* buffer could be locked successfully */
        /* first fill first buffer */
        if (buffer1) {
            memcpy(buffer1, data, buffer1len);
            data = (char*) (((UINT_PTR) data) + buffer1len);
        } else buffer1len = 0;
        if (buffer2) {
            memcpy(buffer2, data, buffer2len);
        } else buffer2len = 0;
        byteSize = buffer1len + buffer2len;

        /* update next write pos */
        thisWritePos += byteSize;
        while (thisWritePos >= info->dsBufferSizeInBytes) {
            thisWritePos -= info->dsBufferSizeInBytes;
        }
        /* commit data to directsound */
        info->playBuffer->Unlock(buffer1, buffer1len, buffer2, buffer2len);

        info->writePos = thisWritePos;

        /* update position
         * must be AFTER updating writePos,
         * so that getSvailable doesn't return too little,
         * so that getFramePos doesn't jump
         */
        info->framePos += (byteSize / info->frameSize);

        /* decrease silenced bytes */
        if (info->silencedBytes > byteSize) {
            info->silencedBytes -= byteSize;
        } else {
            info->silencedBytes = 0;
        }
        break;
    } /* while */

    /* start the device, if necessary */
    if (info->started && needRestart && (info->writePos >= 0)) {
        DS_StartBufferHelper::StartBuffer(info);
    }

    TRACE1("< DAUDIO_Write: returning %d bytes.\n", byteSize);
    return byteSize;
}

// returns -1 on error
int DAUDIO_Read(void* id, char* data, int byteSize) {
    DS_Info* info = (DS_Info*) id;
    int available;
    int thisReadPos;
    DWORD captureCursor, readCursor;
    HRESULT res;
    void* buffer1, *buffer2;
    DWORD buffer1len, buffer2len;
    int bufferSize;

    TRACE1("> DAUDIO_Read %d bytes\n", byteSize);

    available = DS_GetAvailable(info, &captureCursor, &readCursor, &bufferSize, FALSE /* fromCaptureCursor? */);
    if (byteSize > available) byteSize = available;
    if (byteSize > 0) {
        thisReadPos = info->writePos;
        if (thisReadPos == -1) {
            /* from beginning */
            thisReadPos = 0;
        }
        res = info->captureBuffer->Lock(thisReadPos, byteSize,
                                        (LPVOID *) &buffer1, &buffer1len,
                                        (LPVOID *) &buffer2, &buffer2len,
                                        0);
        if (res != DS_OK) {
            /* can't recover from error */
            byteSize = 0;
        } else {
            /* buffer could be locked successfully */
            /* first fill first buffer */
            if (buffer1) {
                memcpy(data, buffer1, buffer1len);
                data = (char*) (((UINT_PTR) data) + buffer1len);
            } else buffer1len = 0;
            if (buffer2) {
                memcpy(data, buffer2, buffer2len);
            } else buffer2len = 0;
            byteSize = buffer1len + buffer2len;

            /* update next read pos */
            thisReadPos = DS_addPos(info, thisReadPos, byteSize);
            /* commit data to directsound */
            info->captureBuffer->Unlock(buffer1, buffer1len, buffer2, buffer2len);

            /* update position
             * must be BEFORE updating readPos,
             * so that getAvailable doesn't return too much,
             * so that getFramePos doesn't jump
             */
            info->framePos += (byteSize / info->frameSize);

            info->writePos = thisReadPos;
        }
    }

    TRACE1("< DAUDIO_Read: returning %d bytes.\n", byteSize);
    return byteSize;
}


int DAUDIO_GetBufferSize(void* id, int isSource) {
    DS_Info* info = (DS_Info*) id;
    return info->bufferSizeInBytes;
}

int DAUDIO_StillDraining(void* id, int isSource) {
    DS_Info* info = (DS_Info*) id;
    BOOL draining = FALSE;
    int available, bufferSize;
    DWORD playCursor, writeCursor;

    DS_clearBuffer(info, TRUE /* from write position */);
    available = DS_GetAvailable(info, &playCursor, &writeCursor, &bufferSize, TRUE /* fromPlayCursor */);
    draining = (available < bufferSize);

    TRACE3("DAUDIO_StillDraining: available=%d  silencedBytes=%d  Still draining: %s\n",
           available, info->silencedBytes, draining?"TRUE":"FALSE");
    return draining;
}


int DAUDIO_Flush(void* id, int isSource) {
    DS_Info* info = (DS_Info*) id;

    TRACE0("DAUDIO_Flush\n");

    if (info->isSource)  {
        info->playBuffer->Stop();
        DS_clearBuffer(info, FALSE /* entire buffer */);
    } else {
        DWORD captureCursor, readCursor;
        /* set the read pointer to the current read position */
        if (FAILED(info->captureBuffer->GetCurrentPosition(&captureCursor, &readCursor))) {
            ERROR0("DAUDIO_Flush: ERROR: Failed to get current position.");
            return FALSE;
        }
        DS_clearBuffer(info, FALSE /* entire buffer */);
        /* SHOULD set to *captureCursor*,
         * but that would be detected as overflow
         * in a subsequent GetAvailable() call.
         */
        info->writePos = (int) readCursor;
    }
    return TRUE;
}

int DAUDIO_GetAvailable(void* id, int isSource) {
    DS_Info* info = (DS_Info*) id;
    DWORD playCursor, writeCursor;
    int ret, bufferSize;

    ret = DS_GetAvailable(info, &playCursor, &writeCursor, &bufferSize, /*fromPlayCursor?*/ FALSE);

    TRACE1("DAUDIO_GetAvailable returns %d bytes\n", ret);
    return ret;
}

INT64 estimatePositionFromAvail(DS_Info* info, INT64 javaBytePos, int bufferSize, int availInBytes) {
    // estimate the current position with the buffer size and
    // the available bytes to read or write in the buffer.
    // not an elegant solution - bytePos will stop on xruns,
    // and in race conditions it may jump backwards
    // Advantage is that it is indeed based on the samples that go through
    // the system (rather than time-based methods)
    if (info->isSource) {
        // javaBytePos is the position that is reached when the current
        // buffer is played completely
        return (INT64) (javaBytePos - bufferSize + availInBytes);
    } else {
        // javaBytePos is the position that was when the current buffer was empty
        return (INT64) (javaBytePos + availInBytes);
    }
}

INT64 DAUDIO_GetBytePosition(void* id, int isSource, INT64 javaBytePos) {
    DS_Info* info = (DS_Info*) id;
    int available, bufferSize;
    DWORD playCursor, writeCursor;
    INT64 result = javaBytePos;

    available = DS_GetAvailable(info, &playCursor, &writeCursor, &bufferSize, /*fromPlayCursor?*/ TRUE);
    result = estimatePositionFromAvail(info, javaBytePos, bufferSize, available);
    return result;
}


void DAUDIO_SetBytePosition(void* id, int isSource, INT64 javaBytePos) {
    /* save to ignore, since GetBytePosition
     * takes the javaBytePos param into account
     */
}

int DAUDIO_RequiresServicing(void* id, int isSource) {
    // need servicing on for SourceDataLines
    return isSource?TRUE:FALSE;
}

void DAUDIO_Service(void* id, int isSource) {
    DS_Info* info = (DS_Info*) id;
    if (isSource) {
        if (info->silencedBytes < info->dsBufferSizeInBytes) {
            // clear buffer
            TRACE0("DAUDIO_Service\n");
            DS_clearBuffer(info, TRUE /* from write position */);
        }
        if (info->writePos >= 0
            && info->started
            && !info->underrun
            && info->silencedBytes >= info->dsBufferSizeInBytes) {
            // if we're currently playing, and the entire buffer is silenced...
            // then we are underrunning!
            info->underrun = TRUE;
            ERROR0("DAUDIO_Service: ERROR: DirectSound: underrun detected!\n");
        }
    }
}


//cak #endif // USE_DAUDIO

From tamasflaviu at gmail.com  Wed Oct 19 04:08:58 2022
From: tamasflaviu at gmail.com (Flaviu Tamas)
Date: Wed, 19 Oct 2022 04:08:58 -0000
Subject: [PATCH] Paste fails when X clipboard is in a certain state
Message-ID: <CAKCn7JEV5ydg_cttOGJ808MUbSAScCGaa1994F9sjYCu5z5DrQ@mail.gmail.com>

Sometimes, the X clipboard is in some state that causes pastes to fail
with the following, or similar, stack traces:

java.lang.NullPointerException: Failed to retrieve atom name.
    at java.desktop/sun.awt.X11.XlibWrapper.XGetAtomName(Native Method)
    at java.desktop/sun.awt.X11.XAtom.getName(XAtom.java:189)
    at java.desktop/sun.awt.X11.XDataTransferer.getTargetNameForAtom(XDataTransferer.java:172)
    at java.desktop/sun.awt.X11.XDataTransferer.getNativeForFormat(XDataTransferer.java:161)
    at java.desktop/sun.awt.datatransfer.DataTransferer.getFlavorsForFormatsAsSet(DataTransferer.java:487)
    at java.desktop/sun.awt.datatransfer.SunClipboard.formatArrayAsDataFlavorSet(SunClipboard.java:342)
    at java.desktop/sun.awt.datatransfer.SunClipboard.isDataFlavorAvailable(SunClipboard.java:185)

This is a widespread issue and very frustrating issue, see:

- https://youtrack.jetbrains.com/issue/JBR-438/Clipboard-operations-arent-working-in-certain-state-of-Xorg-selection-buffers
- https://www.google.com/search?q="Failed+to+retrieve+atom+name"+"DataTransferer"

Frankly, I don't understand how X works at all, or how this issue
arises. However, this same workaround was applied to Mozilla in 2010:
https://hg.mozilla.org/releases/mozilla-1.9.1/rev/62f3d28797e2, and I
don't see any reasonable behavior that having this workaround in place
would break. The workaround works by simply skipping native formats
that don't have a name.

Verified to work by running IntelliJ Clion under the modified VM and
verifying that paste from my terminal, which previously did not work,
now works. I'm not familiar with OpenJDK unit testing conventions, but
I believe this change falls under the "highly platform-dependent"
exception.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fixes-failed-paste-when-X-clipboard-is-in-a-certain-.patch
Type: text/x-patch
Size: 2723 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221019/2f786588/0001-Fixes-failed-paste-when-X-clipboard-is-in-a-certain-.patch>

From peter.firmstone at zeus.net.au  Wed Oct 26 22:53:52 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 27 Oct 2022 08:53:52 +1000
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
 <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
Message-ID: <521dafd5-5e43-6f0d-dae2-5e4daa0fd55d@zeus.net.au>

Interesting.? Is this RFR a done deal?

While I like the concept and and understand the reasoning of URL not 
having a public constructor, I think this may have been thought of in 
isolation, I'm not sure how a custom URI, that strictly complies with 
RFC 3986 will behave, if it must also be parsed by java.net.URI, which 
is loosely compliant with RFC 2396 and RFC 2732.? Has anyone done any 
investigation?? We stopped using java.net.URI some years ago as it's 
obsolete.? The change will have some performance impact, by requiring 
redundant parsing.

Just thought I'd mention it, in case it hasn't been thought of. If you 
do an internet search there are other implementations of RFC3986 in java 
also.

https://github.com/pfirmstone/JGDMS/blob/e4a5012e71fd9a61b6e1e505f07e6c5358a4ccbc/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L1966

We have a strict URI 3986 implementation, which we use to create all URL 
instances from.

This is how we avoid unnecessarily incurring accesses to file systems 
and DNS, this implementation had a massive performance and scalability 
improvement for us.

/**
 ?* This class represents an immutable instance of a URI as defined by 
RFC 3986.
 ?* <p>
 ?* This class replaces java.net.URI functionality.
 ?* <p>
 ?* Unlike java.net.URI this class is not Serializable and hashCode and
 ?* equality is governed by strict RFC3986 normalisation. In addition 
"other"
 ?* characters allowed in java.net.URI as specified by javadoc, not 
specifically
 ?* allowed by RFC3986 are illegal and must be escaped.? This strict 
adherence
 ?* is essential to eliminate false negative or positive matches.
 ?* <p>
 ?* In addition to RFC3896 normalisation, on OS platforms with a \ file 
separator
 ?* the path is converted to UPPER CASE for comparison for file: schema, 
during
 ?* equals and hashCode calls.
 ?* <p>
 ?* IPv6 and IPvFuture host addresses must be enclosed in square 
brackets as per
 ?* RFC3986.? A zone delimiter %, if present, must be represented in 
escaped %25
 ?* form.
 ?* <p>
 ?* In addition to RFC3896 normalization, IPv6 host addresses will be 
normalized
 ?* to comply with RFC 5952 A Recommendation for IPv6 Address Text 
Representation.
 ?* This is to ensure consistent equality between identical IPv6 addresses.
 ?*
 ?* @since 3.0.0
 ?*/


Regards,
Peter.

On 27/10/2022 3:57 am, Daniel Fuchs wrote:
> On Wed, 26 Oct 2022 17:39:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:
>
>>> `URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent.
>> I see your point.  It may be more appropriate if URI.toURL was designed as URL.fromURL.
>>
>> I was wondering to have application developers a consistent way to get an URL instance.  Now there are two methods in different classes URI.toURL and URL.fromURI.  It might be easier to use the old URI.toURL form.
>>
>> Never mind, it is just my personal preference.  It is fine to me to have a new URL.fromURI method.
> One thing we might do is change the name of the method into `URL.of(URI, StreamHandler)`. It's named `fromURI` merely because there was a pre-existing package protected `fromURI` method. However since we're making it public now, it could be fair game to change its name. Possibly adding an overload `URL::of(URI)` method could be considered, but then there really would be two paths to do the same thing - so I'd rather not add such an overload - unless I get some more feedback on that from the CSR/PR review.
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/10874