From psadhukhan at openjdk.org  Thu Dec  1 08:00:01 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 1 Dec 2022 08:00:01 GMT
Subject: Integrated: 8296660: Swing HTML table with omitted closing tags
 misparsed
In-Reply-To: <8QRoaTYNsQAZoB6Kcj1Duyk1dxtcvDiGz5HR0-7TEIA=.0dcf5cc8-5b92-40bf-ab57-670a1e020f62@github.com>
References: <8QRoaTYNsQAZoB6Kcj1Duyk1dxtcvDiGz5HR0-7TEIA=.0dcf5cc8-5b92-40bf-ab57-670a1e020f62@github.com>
Message-ID: <E_SY14k1NHIHRzQEuGyMNbiPDGcAFKTZ_jd8uEd-T1o=.77f1ed92-0f76-4670-8489-4c1ea8148302@github.com>

On Thu, 24 Nov 2022 14:59:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This is in continuation with https://github.com/openjdk/jdk/commit/7133fc93e168f3671d048b2ae654f84ec289b98d fix done for [JDK-7172359](https://bugs.openjdk.org/browse/JDK-7172359) issue where fix was done to rectify invalid tag causing StackOverflowError but it caused alignment issue if the closing tags are optional, so the fix is modified to check for optional closing tag in which case dont return false for legalElementContext()
> 
> JDK-7172359 fix and other CI regression tests are fine.

This pull request has now been integrated.

Changeset: c6125120
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c61251201402f15bf0795564bf31545d9c72ee41
Stats:     75 lines in 2 files changed: 74 ins; 0 del; 1 mod

8296660: Swing HTML table with omitted closing tags misparsed

Reviewed-by: prr, jdv

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

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


From abhiscxk at openjdk.org  Thu Dec  1 08:11:31 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 1 Dec 2022 08:11:31 GMT
Subject: Integrated: 8295006: Colored text is not shown on disabled checkbox
 and radio button 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: <IPJPoaQl-5E7rVdfMr84SUJLDc2p6T263ReFwtkHEQg=.3f502fdf-698b-45e0-b7f1-92a796e71e94@github.com>

On Wed, 19 Oct 2022 04:25:42 GMT, Abhishek Kumar <abhiscxk 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.

This pull request has now been integrated.

Changeset: ce048e7c
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ce048e7cb55517e2710dfe4e802602869d8c5cb8
Stats:     13 lines in 2 files changed: 12 ins; 1 del; 0 mod

8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194.

Reviewed-by: prr, tr

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

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


From aturbanov at openjdk.org  Thu Dec  1 08:19:51 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 1 Dec 2022 08:19:51 GMT
Subject: Integrated: 8297750: Unnecessary Vector usage in IIORegistry
In-Reply-To: <PE3PMTZP28KoFuXYIfVxzqfPkr3oGDYHxNMLRqvy07g=.c9bfa020-0493-4e7a-b1cd-974403e64d0e@github.com>
References: <PE3PMTZP28KoFuXYIfVxzqfPkr3oGDYHxNMLRqvy07g=.c9bfa020-0493-4e7a-b1cd-974403e64d0e@github.com>
Message-ID: <52a--1lIV04dYl_3NYV4XdJSbAR7H_SszOggvA91JM8=.b724316d-45e3-451d-9d75-56bb817c6c75@github.com>

On Sun, 27 Nov 2022 17:51:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Field `javax.imageio.spi.IIORegistry#initialCategories` is modified only in `static {}` block, which makes it effectively final. Instead of legacy synchronized `Vector` we can use non-threadsafe `ArrayList` here.

This pull request has now been integrated.

Changeset: fa0c599a
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa0c599a003962cf3457bb49b9f771659532b5c3
Stats:     17 lines in 1 file changed: 1 ins; 7 del; 9 mod

8297750: Unnecessary Vector usage in IIORegistry

Reviewed-by: prr, serb

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

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


From jdv at openjdk.org  Thu Dec  1 08:47:36 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 1 Dec 2022 08:47:36 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <Sq19Xptu7KJqz715FuOTnqGqTO32G9WgsxE7bd5Lqg8=.bba56751-62f7-4517-ac6a-30d78d318e9d@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
 <KOWLHbOsuTOTatNbamvhzHtB3vuiUi9s3790VwhwSR4=.ce916861-224f-4ee1-a9bf-24778eddd9c2@github.com>
 <Sq19Xptu7KJqz715FuOTnqGqTO32G9WgsxE7bd5Lqg8=.bba56751-62f7-4517-ac6a-30d78d318e9d@github.com>
Message-ID: <aSlBVSP1G6Qa0-tZbQDoKrHnC8Gb_7QPps-6_R4t9K8=.0d4268ca-ba93-4dd4-a554-397bfc45169b@github.com>

On Tue, 27 Sep 2022 10:03:30 GMT, Tejesh R <tr at openjdk.org> wrote:

>>> 
>> 
>> There are multiple ImageCache/ImageBuffer pointers, Please point to github source code. I think we should find how this ImageCache knows why it should use "blue" colored bitmap and try to replicate the same for interiorBackgroundColor property. Since we don't have such property in other LAF's, we should avoid replicating same behaviour(of returning null) in Windows LAF.
>
>> > 
>> 
>> There are multiple ImageCache/ImageBuffer pointers, Please point to github source code. I think we should find how this ImageCache knows why it should use "blue" colored bitmap and try to replicate the same for interiorBackgroundColor property. Since we don't have such property in other LAF's, we should avoid replicating same behaviour(of returning null) in Windows LAF.
> 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L205
> Here in `Image image = cache.getImage(key, config, w, h, args);` the image is been returned.

@TejeshR13 I see that this is PR is withdrawn because it was inactive. Are you working on it or is it on hold?

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

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


From tr at openjdk.org  Thu Dec  1 11:34:25 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 1 Dec 2022 11:34:25 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <Sq19Xptu7KJqz715FuOTnqGqTO32G9WgsxE7bd5Lqg8=.bba56751-62f7-4517-ac6a-30d78d318e9d@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
 <KOWLHbOsuTOTatNbamvhzHtB3vuiUi9s3790VwhwSR4=.ce916861-224f-4ee1-a9bf-24778eddd9c2@github.com>
 <Sq19Xptu7KJqz715FuOTnqGqTO32G9WgsxE7bd5Lqg8=.bba56751-62f7-4517-ac6a-30d78d318e9d@github.com>
Message-ID: <0PF8fkS9gAgvBfrQzvl_wfV5P0BNOncgW98jgBdnRKE=.3afa457e-4b44-47b8-8922-6841c10aa7c2@github.com>

On Tue, 27 Sep 2022 10:03:30 GMT, Tejesh R <tr at openjdk.org> wrote:

>>> 
>> 
>> There are multiple ImageCache/ImageBuffer pointers, Please point to github source code. I think we should find how this ImageCache knows why it should use "blue" colored bitmap and try to replicate the same for interiorBackgroundColor property. Since we don't have such property in other LAF's, we should avoid replicating same behaviour(of returning null) in Windows LAF.
>
>> > 
>> 
>> There are multiple ImageCache/ImageBuffer pointers, Please point to github source code. I think we should find how this ImageCache knows why it should use "blue" colored bitmap and try to replicate the same for interiorBackgroundColor property. Since we don't have such property in other LAF's, we should avoid replicating same behaviour(of returning null) in Windows LAF.
> 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L205
> Here in `Image image = cache.getImage(key, config, w, h, args);` the image is been returned.

> @TejeshR13 I see that this is PR is withdrawn because it was inactive. Are you working on it or is it on hold?

I have put this on hold and will raise a new PR as the fix for this will take time.

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

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


From duke at openjdk.org  Thu Dec  1 14:50:31 2022
From: duke at openjdk.org (ravi gupta)
Date: Thu, 1 Dec 2022 14:50:31 GMT
Subject: RFR: 8297489: Modify TextAreaTextEventTest.java as to verify the
 content change of TextComponent sends TextEvent [v6]
In-Reply-To: <H7m1aUX465moo8YgQxlbd2dhpY4oOXP5b1pEYGY-iSA=.4e625467-97db-473e-af11-f26c4015d284@github.com>
References: <H7m1aUX465moo8YgQxlbd2dhpY4oOXP5b1pEYGY-iSA=.4e625467-97db-473e-af11-f26c4015d284@github.com>
Message-ID: <1TajU2sJd_RsaSDVvdUVY7MqjLQ9eGJTj19347Rm-rI=.a8d47114-90b6-4962-b871-367954d4564f@github.com>

> Modify TextAreaTextEventTest.java as to verify the content changes of a both TextComponent(TextField,TextArea) for the following assertions.
> 
> a. TextListener get invoked when the content of a TextField gets changed.
> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed.
> 
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

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

  Review Comments Fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11326/files
  - new: https://git.openjdk.org/jdk/pull/11326/files/10d2e42b..a676c424

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

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

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


From aivanov at openjdk.org  Thu Dec  1 14:53:30 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 1 Dec 2022 14:53:30 GMT
Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code [v4]
In-Reply-To: <rYmDZU7ox836oMFSVvSMWNM2hv-fBXSORFhSUBDtXqM=.59cec254-d6ea-4c19-9616-df5eb4d6dfe4@github.com>
References: <yeaLofn9-LhJex_2PYyHa3QrO2tiTNgkwVi_E-9MEic=.70f77ac3-1cc6-4563-a22c-9a1435dbc227@github.com>
 <rYmDZU7ox836oMFSVvSMWNM2hv-fBXSORFhSUBDtXqM=.59cec254-d6ea-4c19-9616-df5eb4d6dfe4@github.com>
Message-ID: <sdV43qmWUyT3rfNwCg1RI6IPr5y3c1abwLVOPV-Vg-g=.fcf57cd4-f65c-45e8-a281-6139584b00e9@github.com>

On Tue, 29 Nov 2022 21:42:02 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Updated Metal Border code for JInternalFrame. 
>> 
>> - Added instanceof check before casting Graphics to G2D.
>> - Replaced roundHalfDown with Region.clipRound()
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review changes

Marked as reviewed by aivanov (Reviewer).

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

> 290:             int height;
> 291:             int xtranslation;
> 292:             int ytranslation;

I wonder why you changed the order of declaration.

Is it for consistency with the `else`-block? What about the `if` itself then?

It's very minor though.

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

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


From aivanov at openjdk.org  Thu Dec  1 15:21:26 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 1 Dec 2022 15:21:26 GMT
Subject: RFR: 8297489: Modify TextAreaTextEventTest.java as to verify the
 content change of TextComponent sends TextEvent [v6]
In-Reply-To: <1TajU2sJd_RsaSDVvdUVY7MqjLQ9eGJTj19347Rm-rI=.a8d47114-90b6-4962-b871-367954d4564f@github.com>
References: <H7m1aUX465moo8YgQxlbd2dhpY4oOXP5b1pEYGY-iSA=.4e625467-97db-473e-af11-f26c4015d284@github.com>
 <1TajU2sJd_RsaSDVvdUVY7MqjLQ9eGJTj19347Rm-rI=.a8d47114-90b6-4962-b871-367954d4564f@github.com>
Message-ID: <NUqoJJwtedJPwAVb1A-9ocV0CNcDfN-asjqxt2ZdHbc=.70cb9707-9a34-4952-a398-26f486d5f5b7@github.com>

On Thu, 1 Dec 2022 14:50:31 GMT, ravi gupta <duke at openjdk.org> wrote:

>> Modify TextAreaTextEventTest.java as to verify the content changes of a both TextComponent(TextField,TextArea) for the following assertions.
>> 
>> a. TextListener get invoked when the content of a TextField gets changed.
>> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed.
>> 
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
>
> ravi gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixes

Marked as reviewed by aivanov (Reviewer).

test/jdk/java/awt/event/ComponentEvent/TextComponentTextEventTest.java line 113:

> 111:                 if (textComp instanceof TextField && textChanged) {
> 112:                     throw new RuntimeException(
> 113:                         "FAIL: TextEvent triggered when Enter pressed on "+ textComp);

Suggestion:

                        "FAIL: TextEvent triggered when Enter pressed on " + textComp);

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

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


From psadhukhan at openjdk.org  Thu Dec  1 15:38:48 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 1 Dec 2022 15:38:48 GMT
Subject: RFR: 8296084: javax/swing/JSpinner/4788637/bug4788637.java fails
 intermittently on a VM
Message-ID: <653WUNsoUVvZqZJJ7rFXP0Sm4635kChU8PsqUqM9Dco=.bfad888b-b624-4096-bb46-d8f14e57c6a1@github.com>

Test seems to fail intermittently in ubuntu OCI VM although it passes locally and in other physical system. 
Although I am not able to reproduce it on VM, tried some robot safeguards used in other tests.
Modified tests passed several iterations in couple of OCI VM hosts and other physical systems , link of whose jobs are in JBS
so we can deproblemlist it.

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

Commit messages:
 - 8296084: javax/swing/JSpinner/4788637/bug4788637.java fails intermittently on a VM

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

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


From tr at openjdk.org  Thu Dec  1 16:39:00 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 1 Dec 2022 16:39:00 GMT
Subject: RFR: 8296084: javax/swing/JSpinner/4788637/bug4788637.java fails
 intermittently on a VM
In-Reply-To: <653WUNsoUVvZqZJJ7rFXP0Sm4635kChU8PsqUqM9Dco=.bfad888b-b624-4096-bb46-d8f14e57c6a1@github.com>
References: <653WUNsoUVvZqZJJ7rFXP0Sm4635kChU8PsqUqM9Dco=.bfad888b-b624-4096-bb46-d8f14e57c6a1@github.com>
Message-ID: <vBhrjipk299v53vhr7Bds5aB3WVssyRUgmY9Baofb68=.61eb48fc-b1c4-4ee1-87fe-4ad9eddc16e6@github.com>

On Thu, 1 Dec 2022 15:29:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seems to fail intermittently in ubuntu OCI VM although it passes locally and in other physical system. 
> Although I am not able to reproduce it on VM, tried some robot safeguards used in other tests.
> Modified tests passed several iterations in couple of OCI VM hosts and other physical systems , link of whose jobs are in JBS
> so we can deproblemlist it.

Looks fine to me.

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

Marked as reviewed by tr (Committer).

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


From duke at openjdk.org  Thu Dec  1 17:09:07 2022
From: duke at openjdk.org (ravi gupta)
Date: Thu, 1 Dec 2022 17:09:07 GMT
Subject: RFR: 8297489: Modify TextAreaTextEventTest.java as to verify the
 content change of TextComponent sends TextEvent [v7]
In-Reply-To: <H7m1aUX465moo8YgQxlbd2dhpY4oOXP5b1pEYGY-iSA=.4e625467-97db-473e-af11-f26c4015d284@github.com>
References: <H7m1aUX465moo8YgQxlbd2dhpY4oOXP5b1pEYGY-iSA=.4e625467-97db-473e-af11-f26c4015d284@github.com>
Message-ID: <m4b51RUvu5G1I_0smAsGTbjOkZdpExJB9WnSyRCdZ2s=.221449b9-83f7-43bb-9638-6e0dcce7a2b2@github.com>

> Modify TextAreaTextEventTest.java as to verify the content changes of a both TextComponent(TextField,TextArea) for the following assertions.
> 
> a. TextListener get invoked when the content of a TextField gets changed.
> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed.
> 
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

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

  Review & code optimization Comments Fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11326/files
  - new: https://git.openjdk.org/jdk/pull/11326/files/a676c424..d3f70e98

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

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

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


From aivanov at openjdk.org  Thu Dec  1 17:19:02 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 1 Dec 2022 17:19:02 GMT
Subject: RFR: 8297489: Modify TextAreaTextEventTest.java as to verify the
 content change of TextComponent sends TextEvent [v7]
In-Reply-To: <m4b51RUvu5G1I_0smAsGTbjOkZdpExJB9WnSyRCdZ2s=.221449b9-83f7-43bb-9638-6e0dcce7a2b2@github.com>
References: <H7m1aUX465moo8YgQxlbd2dhpY4oOXP5b1pEYGY-iSA=.4e625467-97db-473e-af11-f26c4015d284@github.com>
 <m4b51RUvu5G1I_0smAsGTbjOkZdpExJB9WnSyRCdZ2s=.221449b9-83f7-43bb-9638-6e0dcce7a2b2@github.com>
Message-ID: <0NK5ojHeYLyKe1weKpo3nt8Kkgw2MmHf6l8Wl2Lchyo=.90eaa133-3907-4f6d-bfa9-77cf51141a52@github.com>

On Thu, 1 Dec 2022 17:09:07 GMT, ravi gupta <duke at openjdk.org> wrote:

>> Modify TextAreaTextEventTest.java as to verify the content changes of a both TextComponent(TextField,TextArea) for the following assertions.
>> 
>> a. TextListener get invoked when the content of a TextField gets changed.
>> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed.
>> 
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
>
> ravi gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review & code optimization Comments Fixes

Changes requested by aivanov (Reviewer).

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

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


From aivanov at openjdk.org  Thu Dec  1 17:19:07 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 1 Dec 2022 17:19:07 GMT
Subject: RFR: 8297489: Modify TextAreaTextEventTest.java as to verify the
 content change of TextComponent sends TextEvent [v6]
In-Reply-To: <NUqoJJwtedJPwAVb1A-9ocV0CNcDfN-asjqxt2ZdHbc=.70cb9707-9a34-4952-a398-26f486d5f5b7@github.com>
References: <H7m1aUX465moo8YgQxlbd2dhpY4oOXP5b1pEYGY-iSA=.4e625467-97db-473e-af11-f26c4015d284@github.com>
 <1TajU2sJd_RsaSDVvdUVY7MqjLQ9eGJTj19347Rm-rI=.a8d47114-90b6-4962-b871-367954d4564f@github.com>
 <NUqoJJwtedJPwAVb1A-9ocV0CNcDfN-asjqxt2ZdHbc=.70cb9707-9a34-4952-a398-26f486d5f5b7@github.com>
Message-ID: <Ar3NBpz_9qUHk5Sv8tOTX3dH59_ZD4TdcesGC3f7ax0=.d39a1a5c-184f-4e21-9549-185f75498743@github.com>

On Thu, 1 Dec 2022 15:11:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ravi gupta has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Comments Fixes
>
> test/jdk/java/awt/event/ComponentEvent/TextComponentTextEventTest.java line 113:
> 
>> 111:                 if (textComp instanceof TextField && textChanged) {
>> 112:                     throw new RuntimeException(
>> 113:                         "FAIL: TextEvent triggered when Enter pressed on "+ textComp);
> 
> Suggestion:
> 
>                         "FAIL: TextEvent triggered when Enter pressed on " + textComp);

It's not resolved: there's still no space before `+` operator.

And you removed it from other places for some reason where they were present.

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

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


From duke at openjdk.org  Thu Dec  1 17:27:52 2022
From: duke at openjdk.org (ravi gupta)
Date: Thu, 1 Dec 2022 17:27:52 GMT
Subject: RFR: 8297489: Modify TextAreaTextEventTest.java as to verify the
 content change of TextComponent sends TextEvent [v8]
In-Reply-To: <H7m1aUX465moo8YgQxlbd2dhpY4oOXP5b1pEYGY-iSA=.4e625467-97db-473e-af11-f26c4015d284@github.com>
References: <H7m1aUX465moo8YgQxlbd2dhpY4oOXP5b1pEYGY-iSA=.4e625467-97db-473e-af11-f26c4015d284@github.com>
Message-ID: <LJHqMbRa4ppaEgOciQ_y0KB_Su-3xpg0ga7SkMhmEDc=.627d058a-f1e2-4009-8e7a-471ce4dc9941@github.com>

> Modify TextAreaTextEventTest.java as to verify the content changes of a both TextComponent(TextField,TextArea) for the following assertions.
> 
> a. TextListener get invoked when the content of a TextField gets changed.
> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed.
> 
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

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

  Review Comments Fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11326/files
  - new: https://git.openjdk.org/jdk/pull/11326/files/d3f70e98..cac4d372

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

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

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


From aivanov at openjdk.org  Thu Dec  1 17:33:48 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 1 Dec 2022 17:33:48 GMT
Subject: RFR: 8297489: Modify TextAreaTextEventTest.java as to verify the
 content change of TextComponent sends TextEvent [v8]
In-Reply-To: <LJHqMbRa4ppaEgOciQ_y0KB_Su-3xpg0ga7SkMhmEDc=.627d058a-f1e2-4009-8e7a-471ce4dc9941@github.com>
References: <H7m1aUX465moo8YgQxlbd2dhpY4oOXP5b1pEYGY-iSA=.4e625467-97db-473e-af11-f26c4015d284@github.com>
 <LJHqMbRa4ppaEgOciQ_y0KB_Su-3xpg0ga7SkMhmEDc=.627d058a-f1e2-4009-8e7a-471ce4dc9941@github.com>
Message-ID: <-Z9rhM5ubxGSzc-Dbq4M9ZeL1Ov1G3GMeDPrpJuP7wQ=.ece2cbff-a68e-429a-ba1e-c02ea56d3581@github.com>

On Thu, 1 Dec 2022 17:27:52 GMT, ravi gupta <duke at openjdk.org> wrote:

>> Modify TextAreaTextEventTest.java as to verify the content changes of a both TextComponent(TextField,TextArea) for the following assertions.
>> 
>> a. TextListener get invoked when the content of a TextField gets changed.
>> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed.
>> 
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
>
> ravi gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixes

Marked as reviewed by aivanov (Reviewer).

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

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


From honkar at openjdk.org  Thu Dec  1 18:11:20 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 1 Dec 2022 18:11:20 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds
Message-ID: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>

The above test was failing due to incorrect pixel color and wrong window bounds on Mac-ARM, Windows and Linux platforms.

The following changes have been made:
- Correct window bounds are obtained using the screen device being tested (this test checks FullScreen functionality on multiple screen devices).
- Color tolerance has been added for color check
- Instead of scanning the full screen to check pixel color, the scan is done at the far right and bottom end to ensure that window is in full screen mode w.r.t to screen device and the window bounds are as expected.

CI testing passes on all platforms (tested 50 times per platform).

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

Commit messages:
 - FullScreenInsets changes, initial commit

Changes: https://git.openjdk.org/jdk/pull/11462/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11462&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8266245
  Stats: 70 lines in 2 files changed: 35 ins; 3 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/11462.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11462/head:pull/11462

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


From azvegint at openjdk.org  Thu Dec  1 18:13:33 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 1 Dec 2022 18:13:33 GMT
Subject: Integrated: 8271519:
 java/awt/event/SequencedEvent/MultipleContextsFunctionalTest.java failed with
 "Total [200] - Expected [400]"
In-Reply-To: <-eww7dB2tL0Mg7Q57P8Ncfm9i84sEU3wkOvGH9QlOUY=.888b31b2-441b-4077-874c-bcba2caa611b@github.com>
References: <-eww7dB2tL0Mg7Q57P8Ncfm9i84sEU3wkOvGH9QlOUY=.888b31b2-441b-4077-874c-bcba2caa611b@github.com>
Message-ID: <WG6aWDE_S3DeVEMQuzULuyMHLrMvQYOOoUeE_1twKgU=.43609f37-177a-4254-b2fb-acd372b6e311@github.com>

On Tue, 29 Nov 2022 21:36:31 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test was trying to add windows to `ArrayList` instance from two different threads without any synchronization. 
> 
> So the reported test failure happens when the `WINDOWS` list contains only one windows instead of expected two.
> 
> Another possible failure is:
> 
> Exception in thread "AWT-EventQueue-1" java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0
>         at java.base/java.util.ArrayList.add(ArrayList.java:455)
>         at java.base/java.util.ArrayList.add(ArrayList.java:467)
>         at MultipleContextsFunctionalTest$1$1.run(MultipleContextsFunctionalTest.java:107)
>         at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
>         at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
>         at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
>         at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
>         at java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
>         at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)
>         at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
>         at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
>         at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
>         at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
>         at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
>         at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
>         at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
> Total [200] - Expected [400]
> Test FAILED
> 
> 
> The test fails in about 8 out of 100 runs in a cycle for me.
> 
> Changing `ArrayList` to `CopyOnWriteArrayList` solves the issue. Didn't fail once after modification and 300 runs.

This pull request has now been integrated.

Changeset: 9f94cbec
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f94cbec51df7556d34fffa810e59dd9eb8521df
Stats:     5 lines in 1 file changed: 1 ins; 1 del; 3 mod

8271519: java/awt/event/SequencedEvent/MultipleContextsFunctionalTest.java failed with "Total [200] - Expected [400]"

Reviewed-by: serb

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

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


From honkar at openjdk.org  Thu Dec  1 18:15:04 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 1 Dec 2022 18:15:04 GMT
Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code [v5]
In-Reply-To: <yeaLofn9-LhJex_2PYyHa3QrO2tiTNgkwVi_E-9MEic=.70f77ac3-1cc6-4563-a22c-9a1435dbc227@github.com>
References: <yeaLofn9-LhJex_2PYyHa3QrO2tiTNgkwVi_E-9MEic=.70f77ac3-1cc6-4563-a22c-9a1435dbc227@github.com>
Message-ID: <h6f7Lqm5ZMkg99g8slDLv9Q7cWVXgfLjeksvzTkIHSo=.c26720af-9774-4d75-a700-1378b515bfe7@github.com>

> Updated Metal Border code for JInternalFrame. 
> 
> - Added instanceof check before casting Graphics to G2D.
> - Replaced roundHalfDown with Region.clipRound()

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

  minor change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11305/files
  - new: https://git.openjdk.org/jdk/pull/11305/files/b1e3557a..042f9491

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

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

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


From honkar at openjdk.org  Thu Dec  1 18:15:07 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 1 Dec 2022 18:15:07 GMT
Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code [v4]
In-Reply-To: <sdV43qmWUyT3rfNwCg1RI6IPr5y3c1abwLVOPV-Vg-g=.fcf57cd4-f65c-45e8-a281-6139584b00e9@github.com>
References: <yeaLofn9-LhJex_2PYyHa3QrO2tiTNgkwVi_E-9MEic=.70f77ac3-1cc6-4563-a22c-9a1435dbc227@github.com>
 <rYmDZU7ox836oMFSVvSMWNM2hv-fBXSORFhSUBDtXqM=.59cec254-d6ea-4c19-9616-df5eb4d6dfe4@github.com>
 <sdV43qmWUyT3rfNwCg1RI6IPr5y3c1abwLVOPV-Vg-g=.fcf57cd4-f65c-45e8-a281-6139584b00e9@github.com>
Message-ID: <A19Wsyy7DMa2Xxm-9E659x49KOz6hfCnUNReNnXuEqU=.a2320c79-8692-477f-98a6-acbd33f48b6c@github.com>

On Thu, 1 Dec 2022 14:48:38 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
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 292:
> 
>> 290:             int height;
>> 291:             int xtranslation;
>> 292:             int ytranslation;
> 
> I wonder why you changed the order of declaration.
> 
> Is it for consistency with the `else`-block? What about the `if` itself then?
> 
> It's very minor though.

Updated

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

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


From omikhaltcova at openjdk.org  Thu Dec  1 18:22:57 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Thu, 1 Dec 2022 18:22:57 GMT
Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if
 TextAttribute.TRACKING is set. [v2]
In-Reply-To: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
References: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
Message-ID: <Twoosf6HJsMM0N8ZKcPPuu7OiieEDE1yzbnYwkdbE6s=.290f505b-a132-43ab-bb49-a3a0f2e8d5ae@github.com>

> This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks.
> 
> Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests:
> `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font`

Olga Mikhaltsova has updated the pull request incrementally with two additional commits since the last revision:

 - Fix tracking for CJK, Arabic and Hebrew
 - Manual test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10289/files
  - new: https://git.openjdk.org/jdk/pull/10289/files/3564751d..1818c7d5

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

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

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


From aivanov at openjdk.org  Thu Dec  1 18:56:13 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 1 Dec 2022 18:56:13 GMT
Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code [v5]
In-Reply-To: <h6f7Lqm5ZMkg99g8slDLv9Q7cWVXgfLjeksvzTkIHSo=.c26720af-9774-4d75-a700-1378b515bfe7@github.com>
References: <yeaLofn9-LhJex_2PYyHa3QrO2tiTNgkwVi_E-9MEic=.70f77ac3-1cc6-4563-a22c-9a1435dbc227@github.com>
 <h6f7Lqm5ZMkg99g8slDLv9Q7cWVXgfLjeksvzTkIHSo=.c26720af-9774-4d75-a700-1378b515bfe7@github.com>
Message-ID: <A3SuEoPKBWY49HwZzVbTsWhmbFlVDEG6L_jMXTw2K-0=.14bf8e1c-6c2e-4d83-b9cb-ceebee779dbc@github.com>

On Thu, 1 Dec 2022 18:15:04 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Updated Metal Border code for JInternalFrame. 
>> 
>> - Added instanceof check before casting Graphics to G2D.
>> - Replaced roundHalfDown with Region.clipRound()
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor change

Marked as reviewed by aivanov (Reviewer).

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

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


From honkar at openjdk.org  Thu Dec  1 19:02:00 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 1 Dec 2022 19:02:00 GMT
Subject: Integrated: JDK-8297449: Update JInternalFrame Metal Border code
In-Reply-To: <yeaLofn9-LhJex_2PYyHa3QrO2tiTNgkwVi_E-9MEic=.70f77ac3-1cc6-4563-a22c-9a1435dbc227@github.com>
References: <yeaLofn9-LhJex_2PYyHa3QrO2tiTNgkwVi_E-9MEic=.70f77ac3-1cc6-4563-a22c-9a1435dbc227@github.com>
Message-ID: <ui1jzay8nlpLv5toR2uWZi97a6OK2d7VexEvo17hgmw=.3899609c-d1c3-4137-bff1-15da7143e78b@github.com>

On Wed, 23 Nov 2022 00:46:57 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Updated Metal Border code for JInternalFrame. 
> 
> - Added instanceof check before casting Graphics to G2D.
> - Replaced roundHalfDown with Region.clipRound()

This pull request has now been integrated.

Changeset: 09629570
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/09629570f5d064dc2a5cd670de8d648156ac3991
Stats:     55 lines in 1 file changed: 17 ins; 22 del; 16 mod

8297449: Update JInternalFrame Metal Border code

Reviewed-by: aivanov, kizune

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

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


From honkar at openjdk.org  Thu Dec  1 19:16:25 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 1 Dec 2022 19:16:25 GMT
Subject: RFR: 8297489: Modify TextAreaTextEventTest.java as to verify the
 content change of TextComponent sends TextEvent [v8]
In-Reply-To: <LJHqMbRa4ppaEgOciQ_y0KB_Su-3xpg0ga7SkMhmEDc=.627d058a-f1e2-4009-8e7a-471ce4dc9941@github.com>
References: <H7m1aUX465moo8YgQxlbd2dhpY4oOXP5b1pEYGY-iSA=.4e625467-97db-473e-af11-f26c4015d284@github.com>
 <LJHqMbRa4ppaEgOciQ_y0KB_Su-3xpg0ga7SkMhmEDc=.627d058a-f1e2-4009-8e7a-471ce4dc9941@github.com>
Message-ID: <XPWfyGdqpO_8PQGo7_tFTPe-DpqCH2Z-x6707gssYSk=.2b5451bb-795c-4303-b2c1-651a75b3a5b0@github.com>

On Thu, 1 Dec 2022 17:27:52 GMT, ravi gupta <duke at openjdk.org> wrote:

>> Modify TextAreaTextEventTest.java as to verify the content changes of a both TextComponent(TextField,TextArea) for the following assertions.
>> 
>> a. TextListener get invoked when the content of a TextField gets changed.
>> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed.
>> 
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
>
> ravi gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixes

The combined test looks good.

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

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


From jjg at openjdk.org  Thu Dec  1 19:36:16 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 19:36:16 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com>

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

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

 - Change ietf.org URLs to use rfc-editor.org
 - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags
 - Remove updates from unexported files
 - Prefix RFC titles with `RFC NNNN:`
 - JDK-8296547: Add @spec tags to API

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11073/files
  - new: https://git.openjdk.org/jdk/pull/11073/files/3905ac83..07882ffc

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

  Stats: 83309 lines in 1834 files changed: 38491 ins; 27762 del; 17056 mod
  Patch: https://git.openjdk.org/jdk/pull/11073.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073

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


From duke at openjdk.org  Thu Dec  1 19:38:44 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Thu, 1 Dec 2022 19:38:44 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>

> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
> It includes:
> - Bitmap glyph loading via Freetype
> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
> - Small fixes in related code like null-checks which could cause NPE & comment typos

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

  Fix pointer to jlong conversion on x86

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/4798/files
  - new: https://git.openjdk.org/jdk/pull/4798/files/8c5b2850..4c078054

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=14-15

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 aivanov at openjdk.org  Thu Dec  1 19:40:16 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 1 Dec 2022 19:40:16 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <D1DOLLXwcictjqWFMlcQ8_xJWLnQOhxJBS-716UnafM=.2fd2b9a3-e7bf-4f26-a15b-2767987cfa66@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <ry0IIjcxmW_Lo7wI0-nRof9kg5LkLeh-i0zNhrEEdTg=.dcaef664-765e-4f53-8516-47ba3595ecb0@github.com>
 <D1DOLLXwcictjqWFMlcQ8_xJWLnQOhxJBS-716UnafM=.2fd2b9a3-e7bf-4f26-a15b-2767987cfa66@github.com>
Message-ID: <m3I7nZheq3J6lIN0UlEnQrsLEaPKBqQgMnBvBKlTrZM=.4e3dcb57-f4a1-4443-a308-3beea1160cfc@github.com>

On Wed, 30 Nov 2022 10:16:57 GMT, Tejesh R <tr at openjdk.org> wrote:

> > Do we need to wait a bit longer after creating JFileChooser as the test immediately ends after instantiating it? Also, doesn't JFileChooser needs headful keyword as it needs to show a file dialog? Does it work more reliably if its to run in headful CI systems?
> 
> Should the test be headful even if we instantiate JFileChooser without showing the dialog.? I can check with a delay after its instantiated, but no sure if that might be causing the issue. Because the same issue is observed in another bug also which instantiates JFileChooser and does some tasks after that.

It doesn't need to be. It would've failed if it had required a headful system.

However, it may still be a valid concern. I faced some obscure failures on headless systems running Windows.

The exception is thrown on EDT when `JFileChooser` calculates its preferred size, so the test seem to work correctly. As such, I don't think the failure is related to the fact that the test exits after creating `JFileChooser`.

One of the options to fix the test is to add `@key headful`.

I wonder if the _Downloads_ folder is the first folder for which the icon is requested. Does fetching icons for other folders also fail? Does the host where the test fails have Windows Explorer? Windows Server systems can have minimal UI, if Windows Explorer is not available, then the `headful` keyword is the way to go.

So, we need to collect more data why it fails, why the icon of a folder is `null`.

In addition to that, we have to ensure `null` is returned directly to the caller rather than creating a `MultiResolutionImage` which doesn't even contain a base image.

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

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


From jjg at openjdk.org  Thu Dec  1 19:40:16 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 19:40:16 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>
Message-ID: <q9avJLkpJ4wgyuswrLm_YSdqUD_5GNnWYPEux_Xy7OI=.cb1704f2-7452-435e-984e-1aeb917ac907@github.com>

On Thu, 10 Nov 2022 23:51:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Change ietf.org URLs to use rfc-editor.org
>>  - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags
>>  - Remove updates from unexported files
>>  - Prefix RFC titles with `RFC NNNN:`
>>  - JDK-8296547: Add @spec tags to API
>
> src/java.base/share/classes/java/lang/Character.java line 172:
> 
>> 170:  * occur. For example, in a future release, synchronization may fail.
>> 171:  *
>> 172:  * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0
> 
> This should probably be removed, as the original link (explaining `U+n` notation) is broken.

@naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards.

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

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


From jjg at openjdk.org  Thu Dec  1 19:57:33 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 19:57:33 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <Y0Qj1qIytaKulH9059ekA6usyUpypf7mVymxst4jwDs=.bb77135a-cdf2-4d3e-9801-c417bdf53e37@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <Y0Qj1qIytaKulH9059ekA6usyUpypf7mVymxst4jwDs=.bb77135a-cdf2-4d3e-9801-c417bdf53e37@github.com>
Message-ID: <XVUIV3LMzWV4Y-0veldczkRr4bD_X-2JxbRLJRDikeI=.36f81c4a-f467-4352-90ba-cc3fc656791f@github.com>

On Wed, 23 Nov 2022 23:04:36 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove updates from unexported files
>
> src/java.xml/share/classes/javax/xml/XMLConstants.java line 35:
> 
>> 33:  * @spec https://www.w3.org/TR/REC-xml-names Namespaces in XML 1.0 (Third Edition)
>> 34:  * @spec https://www.w3.org/TR/xml-names11 Namespaces in XML 1.1 (Second Edition)
>> 35:  * @spec https://www.w3.org/TR/xmlschema-1 XML Schema Part 1: Structures Second Edition
> 
> Hi Jon,
> 
> I would agree with what Alan said earlier that the @see ref can be dropped. This particular class (XMLConstants.java [1]) is a good example for that argument: in the resulting javadoc, 5 specs were listed in the "External Specifications" section, 6 in "See Also:", and then they were listed again for each field. That's a lot of duplicates. Adding to the confusion was that the @spec and @see were not always the same, e.g. @spec XML 1.0.
> points to the fifth edition while @see second.
> 
> A minor comment is that the '@spec's were rendered in one line while the @see refs a list. I would see the later is easier to read.
> 
> [1] http://cr.openjdk.java.net/~jjg/8296546/api.00/java.xml/javax/xml/XMLConstants.html

The presentation of lists of `@spec` tags was fixed separately (JDK-8297802), and is incorporated into the latest docs that demo this work.   The same algorithm is now used for both `@see` and `@spec` tags ... if the links are short and do not contain commas, they will be displayed as an inline list; otherwise, they will be displayed in a bulleted list.

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

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


From prr at openjdk.org  Thu Dec  1 20:30:22 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Dec 2022 20:30:22 GMT
Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if
 TextAttribute.TRACKING is set. [v2]
In-Reply-To: <Twoosf6HJsMM0N8ZKcPPuu7OiieEDE1yzbnYwkdbE6s=.290f505b-a132-43ab-bb49-a3a0f2e8d5ae@github.com>
References: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
 <Twoosf6HJsMM0N8ZKcPPuu7OiieEDE1yzbnYwkdbE6s=.290f505b-a132-43ab-bb49-a3a0f2e8d5ae@github.com>
Message-ID: <Ig_EkpsCEqsg7iQ9K3k0rTwEYffOAh7hXmuaOkIM1Dc=.eb388cf6-f186-4f9f-9532-13172b9e591a@github.com>

On Thu, 1 Dec 2022 18:22:57 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks.
>> 
>> Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests:
>> `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font`
>
> Olga Mikhaltsova has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix tracking for CJK, Arabic and Hebrew
>  - Manual test

Changes requested by prr (Reviewer).

test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTracking.java line 27:

> 25:   @test
> 26:   @key headful
> 27:   @bug 8165943

headful isn't needed on manual tests.

Also whilst you can keep this manual test, I still think an automated test that verifies tracking is making a difference to the advance should be provided.

test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTracking.java line 76:

> 74:       Float regular = new Float(16.0);
> 75:       Float big = new Float(24.0);
> 76: 

LineBreakWithTracking.java:74: warning: [removal] Float(double) in Float has been deprecated and marked for removal
      Float regular = new Float(16.0);
                      ^
LineBreakWithTracking.java:75: warning: [removal] Float(double) in Float has been deprecated and marked for removal
      Float big = new Float(24.0);

Use Float.valueOf(float) instead

test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTracking.java line 138:

> 136:     btn.addActionListener(new ActionListener(){
> 137:       public void actionPerformed(ActionEvent e){
> 138:         System.exit(0);

Do not call System.exit() in jtreg tests - even manual ones or ones that run in their own VM. 
Instead dispose() the UI and then either let main() exit normally or throw RuntimeException() to indicate failure.

Also be sure that ALL exit paths clean up windows.

You may want to use PassFailJFrame.java to help you avoid writing the boilerplate and to get some of these things right

https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

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

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


From naoto at openjdk.org  Thu Dec  1 21:23:09 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 Dec 2022 21:23:09 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <q9avJLkpJ4wgyuswrLm_YSdqUD_5GNnWYPEux_Xy7OI=.cb1704f2-7452-435e-984e-1aeb917ac907@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>
 <q9avJLkpJ4wgyuswrLm_YSdqUD_5GNnWYPEux_Xy7OI=.cb1704f2-7452-435e-984e-1aeb917ac907@github.com>
Message-ID: <NzMOOFfncZ1U5XWrfhkWjwcvhKxiand9c5VfptjGehM=.9d78d127-3374-4c48-8a7d-614b64fcdb0a@github.com>

On Thu, 1 Dec 2022 19:37:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Character.java line 172:
>> 
>>> 170:  * occur. For example, in a future release, synchronization may fail.
>>> 171:  *
>>> 172:  * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0
>> 
>> This should probably be removed, as the original link (explaining `U+n` notation) is broken.
>
> @naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards.

Either way is fine with me. I will fix it up if you choose the latter.

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

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


From honkar at openjdk.org  Thu Dec  1 21:37:30 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 1 Dec 2022 21:37:30 GMT
Subject: RFR: 8297489: Modify TextAreaTextEventTest.java as to verify the
 content change of TextComponent sends TextEvent [v8]
In-Reply-To: <LJHqMbRa4ppaEgOciQ_y0KB_Su-3xpg0ga7SkMhmEDc=.627d058a-f1e2-4009-8e7a-471ce4dc9941@github.com>
References: <H7m1aUX465moo8YgQxlbd2dhpY4oOXP5b1pEYGY-iSA=.4e625467-97db-473e-af11-f26c4015d284@github.com>
 <LJHqMbRa4ppaEgOciQ_y0KB_Su-3xpg0ga7SkMhmEDc=.627d058a-f1e2-4009-8e7a-471ce4dc9941@github.com>
Message-ID: <huNXRCnjgwkrqJkFzThcgJPtu7r-WZq1DS7p-f6odMM=.75db8521-4042-4385-baac-8d087e23bc61@github.com>

On Thu, 1 Dec 2022 17:27:52 GMT, ravi gupta <duke at openjdk.org> wrote:

>> Modify TextAreaTextEventTest.java as to verify the content changes of a both TextComponent(TextField,TextArea) for the following assertions.
>> 
>> a. TextListener get invoked when the content of a TextField gets changed.
>> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed.
>> 
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
>
> ravi gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixes

Marked as reviewed by honkar (Committer).

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

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


From serb at openjdk.org  Fri Dec  2 03:50:42 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 2 Dec 2022 03:50:42 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds
In-Reply-To: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
Message-ID: <fsj_jPApqfIlcqYr7d0YE3_EEJsxk2mlzt8awAnryIY=.eb3a88a5-ba92-4e11-a5cc-6068facf3164@github.com>

On Thu, 1 Dec 2022 18:03:42 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> The above test was failing due to incorrect pixel color and wrong window bounds on Mac-ARM, Windows and Linux platforms.
> 
> The following changes have been made:
> - Correct window bounds are obtained using the screen device being tested (this test checks FullScreen functionality on multiple screen devices).
> - Color tolerance has been added for color check
> - Instead of scanning the full screen to check pixel color, vertical and horizontal scans are done at the far right and bottom end to ensure that window is in full screen mode w.r.t to screen device and the window bounds are as expected.
> 
> CI testing passes on all platforms (tested 50 times per platform).

test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 44:

> 42:  * @bug 8003173 7019055
> 43:  * @summary Full-screen windows should have the proper insets.
> 44:  * @run main FullScreenInsets

run main is not needed if no options are provided for the test. less one place to make a typo or copy-paste error in the name of the test.

test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 51:

> 49:     private static Robot robot = null;
> 50:     private static int deviceCount = 0;
> 51:     private static final float TOLERANCE = 10;

Are you sure that we need so big tolerance just to capture the green and red colors? We have CheckCommonColors which checks all our common colors via robot, and seems it works fine w/o tolerance.

test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 61:

> 59:         final Frame wGreen = new Frame();
> 60:         wGreen.setBackground(Color.GREEN);
> 61:         wGreen.setUndecorated(true);

Why did you make that frame undecorated? I think the decoration was one of the reasons why the bug was reproduced.

test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 89:

> 87:             device.setFullScreenWindow(wRed);
> 88:             sleep();
> 89:             testWindowBounds(device.getFullScreenWindow().getBounds(), wRed);

You changed the code
from:
   comparing the bounds of the display mode and the bounds of the window
to:
   comparing the bounds of the window and the bounds of the window
I do not think it is the right thing to do.

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

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


From serb at openjdk.org  Fri Dec  2 03:53:06 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 2 Dec 2022 03:53:06 GMT
Subject: RFR: 8296084: javax/swing/JSpinner/4788637/bug4788637.java fails
 intermittently on a VM
In-Reply-To: <653WUNsoUVvZqZJJ7rFXP0Sm4635kChU8PsqUqM9Dco=.bfad888b-b624-4096-bb46-d8f14e57c6a1@github.com>
References: <653WUNsoUVvZqZJJ7rFXP0Sm4635kChU8PsqUqM9Dco=.bfad888b-b624-4096-bb46-d8f14e57c6a1@github.com>
Message-ID: <-5Dqmj6VHywXQzvme_cS8arlwnVuXsJfXaXVuV6czm0=.1e2d458c-55a9-415a-9250-d2f837ebb6c6@github.com>

On Thu, 1 Dec 2022 15:29:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seems to fail intermittently in ubuntu OCI VM although it passes locally and in other physical system. 
> Although I am not able to reproduce it on VM, tried some robot safeguards used in other tests.
> Modified tests passed several iterations in couple of OCI VM hosts and other physical systems , link of whose jobs are in JBS
> so we can deproblemlist it.

The image from the failure handler attached to the issue shows that the screen was locked during test execution, could it be a root cause?

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

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


From serb at openjdk.org  Fri Dec  2 04:20:11 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 2 Dec 2022 04:20:11 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus
In-Reply-To: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
Message-ID: <e7ITSsOpcKtlC2bJNzIM3PFCUcoRZdfRi0mr1JxsgFE=.f37d4fe5-6a07-427c-b87f-b0ba50efcc6c@github.com>

On Tue, 29 Nov 2022 07:30:32 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Set the text caret to be visible but not blinking on the non-editable text area.

I wonder how other native applications handle this. Can the non-blinking cursor be considered a hang of the application?

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

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


From serb at openjdk.org  Fri Dec  2 04:24:03 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 2 Dec 2022 04:24:03 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
Message-ID: <zJ8NX17CjdyMAOOppmmAunZojfPsqj9YYvLiIn4d2_g=.3a664fd6-5262-4651-902a-19deb9d50c66@github.com>

On Fri, 11 Nov 2022 08:18:19 GMT, Tejesh R <tr at openjdk.org> wrote:

> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.

I suggest calling the FileSystemView API directly on that folder, I think that should work in headless and headfull systems.

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

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


From psadhukhan at openjdk.org  Fri Dec  2 04:25:12 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 2 Dec 2022 04:25:12 GMT
Subject: RFR: 8296084: javax/swing/JSpinner/4788637/bug4788637.java fails
 intermittently on a VM
In-Reply-To: <-5Dqmj6VHywXQzvme_cS8arlwnVuXsJfXaXVuV6czm0=.1e2d458c-55a9-415a-9250-d2f837ebb6c6@github.com>
References: <653WUNsoUVvZqZJJ7rFXP0Sm4635kChU8PsqUqM9Dco=.bfad888b-b624-4096-bb46-d8f14e57c6a1@github.com>
 <-5Dqmj6VHywXQzvme_cS8arlwnVuXsJfXaXVuV6czm0=.1e2d458c-55a9-415a-9250-d2f837ebb6c6@github.com>
Message-ID: <pRzlyB7DG2_Cn6sMPLyv-QREVZGN3QaCOxfjlhigPws=.4003e95a-43ef-4fc0-84d7-1589f3862b3d@github.com>

On Fri, 2 Dec 2022 03:50:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The image from the failure handler attached to the issue shows that the screen was locked during test execution, could it be a root cause?

Lock screen was a known issue with how this lot of OCI VMs are churned but strange thing was it did not affect any other test. We could just deproblemlist it citing this but thought of adding more safeguards and screenshot at actual time of failure to verify, if it fails again for some reason..

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

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


From serb at openjdk.org  Fri Dec  2 04:27:06 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 2 Dec 2022 04:27:06 GMT
Subject: RFR: 8296275: Write a test to verify setAccelerator method of
 JMenuItem [v6]
In-Reply-To: <Q957c8-nyOhidQ478zoe67NomvBhIAQgVqvODSSHH_M=.229c7272-cade-467b-9c30-da6f20b954a0@github.com>
References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
 <Q957c8-nyOhidQ478zoe67NomvBhIAQgVqvODSSHH_M=.229c7272-cade-467b-9c30-da6f20b954a0@github.com>
Message-ID: <3ssWCF8AFhR3SnI2o8l5Z-NIHwG9OCf9XQxjPWgIF_o=.eb35964e-bab0-4541-be6a-929bfa97a649@github.com>

On Mon, 21 Nov 2022 05:20:29 GMT, Naveen Narayanan <duke at openjdk.org> wrote:

>> This testcase will
>> 1) Verify setAccelerator method of JMenuitem.
>> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M.
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass.
>
> Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8296275: Review comments fixed.

test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 1:

> 1: /* Copyright (c) 2016, 2022, Oracle and/or its affiliates. All rights reserved.

I think that the first line usually just `/*`

test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 76:

> 74:     public static void main(String[] args) throws Exception {
> 75:         try {
> 76:             SwingUtilities.invokeAndWait(JMenuItemSetAcceleratorTest::createAndShow);

I suggest clicking on the frame to make sure it is in focus before pressing the shortcut.

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

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


From serb at openjdk.org  Fri Dec  2 04:33:04 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 2 Dec 2022 04:33:04 GMT
Subject: RFR: 8296084: javax/swing/JSpinner/4788637/bug4788637.java fails
 intermittently on a VM
In-Reply-To: <653WUNsoUVvZqZJJ7rFXP0Sm4635kChU8PsqUqM9Dco=.bfad888b-b624-4096-bb46-d8f14e57c6a1@github.com>
References: <653WUNsoUVvZqZJJ7rFXP0Sm4635kChU8PsqUqM9Dco=.bfad888b-b624-4096-bb46-d8f14e57c6a1@github.com>
Message-ID: <4gKQ0df8quhh0yP35a3cSP4UtHvVxuZDhRbksmWGzU4=.8932b3ec-e053-4a93-95c5-00d3fc4af85a@github.com>

On Thu, 1 Dec 2022 15:29:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seems to fail intermittently in ubuntu OCI VM although it passes locally and in other physical system. 
> Although I am not able to reproduce it on VM, tried some robot safeguards used in other tests.
> Modified tests passed several iterations in couple of OCI VM hosts and other physical systems , link of whose jobs are in JBS
> so we can deproblemlist it.

Marked as reviewed by serb (Reviewer).

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

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


From tr at openjdk.org  Fri Dec  2 04:44:11 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 2 Dec 2022 04:44:11 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <zJ8NX17CjdyMAOOppmmAunZojfPsqj9YYvLiIn4d2_g=.3a664fd6-5262-4651-902a-19deb9d50c66@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <zJ8NX17CjdyMAOOppmmAunZojfPsqj9YYvLiIn4d2_g=.3a664fd6-5262-4651-902a-19deb9d50c66@github.com>
Message-ID: <1XplxDGvXjnFMNiF_5_laHbNy8zyI5feJf0NkDIl6zA=.7f1bfa59-ec93-48cb-82ee-b606b6289659@github.com>

On Fri, 2 Dec 2022 04:20:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I suggest calling the FileSystemView API directly on that folder, I think that should work in headless and headfull systems.
@mrserb I didn't get you. Can you brief a little more w.r.t "calling the FileSystemView API"..?

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

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


From serb at openjdk.org  Fri Dec  2 05:09:54 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 2 Dec 2022 05:09:54 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
Message-ID: <OaejD7ICWuDawcFR296LTgk4UuQGrNhvs5l9GgDZ-4k=.11297ea2-7a92-41cc-b96c-737281d052a9@github.com>

On Fri, 11 Nov 2022 08:18:19 GMT, Tejesh R <tr at openjdk.org> wrote:

> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.

JFileChooser uses the FileSystemView API, you can call that directly to make sure that some UI things in JFileChooser do not affect the behavior of the test.

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

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


From serb at openjdk.org  Fri Dec  2 05:24:54 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 2 Dec 2022 05:24:54 GMT
Subject: RFR: 4677581: ColorModel.getComponentSize()-wrong conditions for
 ArrayIndexOutOfBoundsExceptio
Message-ID: <C2YzdBBLdjaVXPsMxf5pkLLMX0Y3E4__xTIvlZldeOA=.bb8eb3c6-8a93-42f5-9218-0da6da5bca16@github.com>

The specification for `java.awt.image.ColorModel#getComponentSize(int)` states that an ArrayIndexOutOfBoundsException is thrown "if componentIdx is greater than the number of components or less than zero". The condition should actually be "if componentIdx is greater than OR EQUAL TO the number of components or less than zero."

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

Commit messages:
 - 4677581: ColorModel.getComponentSize()-wrong conditions for ArrayIndexOutOfBoundsExceptio

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

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


From serb at openjdk.org  Fri Dec  2 05:46:05 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 2 Dec 2022 05:46:05 GMT
Subject: RFR: 8295707: Create a regression test for JDK-7184401 [v2]
In-Reply-To: <qzePcMoNyJaV9lH-HBbwPbu8Xw0SrZXIYjKG_6DGRjI=.8f00b927-c0b0-46d6-9ddf-8d91d8444cbc@github.com>
References: <vIN06D-gVbz3GLi_NQZIQkx57ZyCiCKZCVKqm62g9nw=.ccf472cd-6020-457d-af86-911f6f248cf9@github.com>
 <PY5VGkXX8T3KJbRwzjyRCh1dr_WGar_wie6_kzTjNHQ=.8950eb34-21bb-4f8e-8913-2b4124038be2@github.com>
 <vHEpPzcsOV5nw4xFBGJB954DeFLiL0u-HyS50XJPFZI=.81480b53-393a-4155-8cc9-3449289fa91e@github.com>
 <qzePcMoNyJaV9lH-HBbwPbu8Xw0SrZXIYjKG_6DGRjI=.8f00b927-c0b0-46d6-9ddf-8d91d8444cbc@github.com>
Message-ID: <1ISRCYpxtqmJwnLOVTQ6N33tLaKJGaH1VH8H68qRhew=.07203892-aff3-4bb8-b754-94e89cb4d13f@github.com>

On Wed, 23 Nov 2022 06:54:25 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> test/jdk/java/awt/EventDispatchThread/InterruptEDTTest.java line 66:
>> 
>>> 64:                 frame.setVisible(true);
>>> 65:             });
>>> 66:             ((sun.awt.SunToolkit) (Toolkit.getDefaultToolkit())).realSync();
>> 
>> You can use the Robot.waitForIdle instead of realSync since jdk9.
>
> There was a comment in the original code before the realSync() call that was removed, which perhaps should have been left as is. 
>         // cannot substitute with robot.waitForIdle() presumably because of flushPendingEvents() there
> My understanding of above is that for simulating the test scenario - which is - Events (on line 75,76,77) are triggered and while these are potentially not yet complete(as they are wrapped in an invokeLater), the edt is interrupted. 
> 
> When run on jdk7u6  - the UI hangs and SOP of line 59 is not invoked. 
> When run on jdk7u361 b01 the SOP on line 59 is printed and also the test passed.
> 
> waitForIdle here will trigger the flushPendingEvents internally before the edt interrupt call -and that would eliminate any possibility of simulating the above scenario.

Then please double-check how robot.waitForIdle() and realSync() affect the test, since both call the flushPendingEvents(), why there is a difference?
 * robot.waitForIdle()->SunToolkit.flushPendingEvents();
 * realSync()->waitForIdle()->flushPendingEvents

>> test/jdk/java/awt/EventDispatchThread/InterruptEDTTest.java line 80:
>> 
>>> 78:             });
>>> 79:         } catch (Exception e) {
>>> 80:             e.printStackTrace();
>> 
>> Why do we skip an exception here and in another place below?
>
> As described in the comment above, the intent of the test is to validate the absence of a failure via a test hang and not via an exception.

But if some exception will be thrown there it should not ignore it and just pass.

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

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


From tr at openjdk.org  Fri Dec  2 06:52:04 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 2 Dec 2022 06:52:04 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <OaejD7ICWuDawcFR296LTgk4UuQGrNhvs5l9GgDZ-4k=.11297ea2-7a92-41cc-b96c-737281d052a9@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <OaejD7ICWuDawcFR296LTgk4UuQGrNhvs5l9GgDZ-4k=.11297ea2-7a92-41cc-b96c-737281d052a9@github.com>
Message-ID: <9sN-uV7MIpgo94mEXKQqQRd8x2lA0Wcf7E1KanVHiH0=.ef5073fc-5627-42e7-ba5d-2d7e9bc8c7d5@github.com>

On Fri, 2 Dec 2022 05:07:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> JFileChooser uses the FileSystemView API, you can call that directly to make sure that some UI things in JFileChooser do not affect the behavior of the test.

The test only initializes JFileChooser instance, so calling FSV API directly means to explicitly mentioning FSV from test or from JFileChooser...?

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

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


From itakiguchi at openjdk.org  Fri Dec  2 08:50:30 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Fri, 2 Dec 2022 08:50:30 GMT
Subject: RFR: 8298006: Build failure by maybe-uninitialized error on Linux
 s390x GCC8
Message-ID: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>

I changed GCC toolchain from GCC6 to GCC8 on SLES12SP5 Linux s390x.
I could see following errors:

src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c: In function 'allocateRasterArray':
src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:2944:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
?????????????????????????????(((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])
?????????????????????????????????????????????????????????????????????~~~~^~~


According to error messages,
roff and loff may not be initialized.

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

Commit messages:
 - 8298006: Build failure by maybe-uninitialized error on Linux s390x GCC8

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

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


From psadhukhan at openjdk.org  Fri Dec  2 11:51:14 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 2 Dec 2022 11:51:14 GMT
Subject: Integrated: 8296084: javax/swing/JSpinner/4788637/bug4788637.java
 fails intermittently on a VM
In-Reply-To: <653WUNsoUVvZqZJJ7rFXP0Sm4635kChU8PsqUqM9Dco=.bfad888b-b624-4096-bb46-d8f14e57c6a1@github.com>
References: <653WUNsoUVvZqZJJ7rFXP0Sm4635kChU8PsqUqM9Dco=.bfad888b-b624-4096-bb46-d8f14e57c6a1@github.com>
Message-ID: <fCXSTBHcuAaFlcXb6KmCl8HauLu9f3b5jM3vZPWToPI=.b3469e1d-6015-4f9c-b29f-2ba605bb32c8@github.com>

On Thu, 1 Dec 2022 15:29:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seems to fail intermittently in ubuntu OCI VM although it passes locally and in other physical system. 
> Although I am not able to reproduce it on VM, tried some robot safeguards used in other tests.
> Modified tests passed several iterations in couple of OCI VM hosts and other physical systems , link of whose jobs are in JBS
> so we can deproblemlist it.

This pull request has now been integrated.

Changeset: 319faa5a
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/319faa5afc37df5fd9ce4305e6e38a7bd4b39c65
Stats:     30 lines in 2 files changed: 22 ins; 1 del; 7 mod

8296084: javax/swing/JSpinner/4788637/bug4788637.java fails intermittently on a VM

Reviewed-by: tr, serb

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

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


From dfuchs at openjdk.org  Fri Dec  2 12:15:23 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 2 Dec 2022 12:15:23 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com>
Message-ID: <4EIiX-uBShLoH1cl1MdngnvCc1HfVFXT_GJgFl5LoTE=.b07eefdf-8c2d-439e-a3c1-8ecfe323e2fd@github.com>

On Thu, 1 Dec 2022 19:36:16 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Change ietf.org URLs to use rfc-editor.org
>  - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags
>  - Remove updates from unexported files
>  - Prefix RFC titles with `RFC NNNN:`
>  - JDK-8296547: Add @spec tags to API

I have reviewed again the java.net, java.net.http, jdk.httpserver, java.naming, and javax.management changes - and I spotted a few places where the `@spec` duplicates an `@see` (noted below). I believe the duplicated `@see` should be removed now.

src/java.base/share/classes/java/net/StandardSocketOptions.java line 62:

> 60:      * @spec https://www.rfc-editor.org/info/rfc919 RFC 919: Broadcasting Internet Datagrams
> 61:      * @see <a href="http://www.ietf.org/rfc/rfc919.txt">RFC&nbsp;929:
> 62:      * Broadcasting Internet Datagrams</a>

This `@see` line should now be removed since it's referencing the exact same document.

src/java.base/share/classes/java/net/StandardSocketOptions.java line 83:

> 81:      * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers
> 82:      * @see <a href="http://www.ietf.org/rfc/rfc1122.txt">RFC&nbsp;1122
> 83:      * Requirements for Internet Hosts -- Communication Layers</a>

Same remark here: please remove the `@see`

src/java.base/share/classes/java/net/StandardSocketOptions.java line 154:

> 152:      * @spec https://www.rfc-editor.org/info/rfc1323 RFC 1323: TCP Extensions for High Performance
> 153:      * @see <a href="http://www.ietf.org/rfc/rfc1323.txt">RFC&nbsp;1323: TCP
> 154:      * Extensions for High Performance</a>

Remove the `@see`

src/java.base/share/classes/java/net/StandardSocketOptions.java line 186:

> 184:      *
> 185:      * @spec https://www.rfc-editor.org/info/rfc793 RFC 793: Transmission Control Protocol
> 186:      * @see <a href="http://www.ietf.org/rfc/rfc793.txt">RFC&nbsp;793: Transmission

Remove the @see

src/java.base/share/classes/java/net/StandardSocketOptions.java line 377:

> 375:      * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers
> 376:      * @see <a href="http://www.ietf.org/rfc/rfc1122.txt">RFC&nbsp;1122:
> 377:      * Requirements for Internet Hosts -- Communication Layers</a>

Remove the @see

src/java.management/share/classes/javax/management/remote/JMXServiceURL.java line 122:

> 120:  * @see <a
> 121:  * href="http://www.ietf.org/rfc/rfc2609.txt">RFC 2609,
> 122:  * "Service Templates and <code>Service:</code> Schemes"</a>

The two `@see` should now be removed

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

Changes requested by dfuchs (Reviewer).

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


From itakiguchi at openjdk.org  Fri Dec  2 12:31:08 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Fri, 2 Dec 2022 12:31:08 GMT
Subject: RFR: 8298006: Build failure by maybe-uninitialized error on Linux
 s390x GCC8
In-Reply-To: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
References: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
Message-ID: <lMfAMVlz7I6akRnAwItlVSx-8hfz5UQV9KEuaWbtGV0=.75d55984-0528-40d7-b964-1e960e275d1c@github.com>

On Fri, 2 Dec 2022 08:41:18 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> I changed GCC toolchain from GCC6 to GCC8 on SLES12SP5 Linux s390x.
> I could see following errors:
> 
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c: In function 'allocateRasterArray':
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:2944:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> ?????????????????????????????(((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])
> ?????????????????????????????????????????????????????????????????????~~~~^~~
> 
> 
> According to error messages,
> roff and loff may not be initialized.

`linux-x86 / test (langtools/tier1)` was failed, but it's not related this issue.

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

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


From lbourges at openjdk.org  Fri Dec  2 12:54:12 2022
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 2 Dec 2022 12:54:12 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
Message-ID: <sX-dos3ubJ5Ux0WIrt-PiPlbGT5OdsiR1ZP2HQgrkeg=.2718a5db-035b-4c55-80db-dcdca397535a@github.com>

On Thu, 1 Dec 2022 19:38:44 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix pointer to jlong conversion on x86

Still failing on x86? What are the 2 test failures?

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

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


From ihse at openjdk.org  Fri Dec  2 13:42:06 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 13:42:06 GMT
Subject: RFR: 8298006: Build failure by maybe-uninitialized error on Linux
 s390x GCC8
In-Reply-To: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
References: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
Message-ID: <KYb8vUnHwihJUgekC3c9drcncpys_PbwtY4OX2eM0Jo=.a3e6776f-c06f-4885-a9f7-48747383bfc0@github.com>

On Fri, 2 Dec 2022 08:41:18 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> I changed GCC toolchain from GCC6 to GCC8 on SLES12SP5 Linux s390x.
> I could see following errors:
> 
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c: In function 'allocateRasterArray':
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:2944:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> ?????????????????????????????(((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])
> ?????????????????????????????????????????????????????????????????????~~~~^~~
> 
> 
> According to error messages,
> roff and loff may not be initialized.

Just because you get a compilation error does not mean the issue belongs with the build group. This is just about the source code in AWT, so the client-libs team will handle this review.

That being said, I did have a look at the code and I think they might be skeptical. There seems to be no inherent s390x change here, rather the compiler you are using seem to be a bit trigger-happy on this analysis. 

Also, both gcc 6 and 8 are incredibly old. Gcc 6 is from 2016, and gcc 8 is from  2018. I would recommend you get a newer gcc version instead, or possibly build with `--disable-warnings-as-errors`.

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

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


From ihse at openjdk.org  Fri Dec  2 16:47:58 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 16:47:58 GMT
Subject: RFR: 8298042: Fix hidden but significant trailing whitespace in
 properties files for client code
Message-ID: <fHGFT7w4afEunhQKcP-Y6B6PKSczto3m4vqeWIzplME=.c2b40ecd-5f83-4adf-b07d-4d34d196ed24@github.com>

According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.

We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").

After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)

Doing so has a dual benefit:

1) It makes it clear to everyone reading the code that there is a trailing space and it is intended

2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.

Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the client-libs team.

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

Commit messages:
 - 8298042: Fix hidden but significant trailing whitespace in properties files for client code

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

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


From ihse at openjdk.org  Fri Dec  2 16:47:59 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 16:47:59 GMT
Subject: RFR: 8298042: Fix hidden but significant trailing whitespace in
 properties files for client code
In-Reply-To: <fHGFT7w4afEunhQKcP-Y6B6PKSczto3m4vqeWIzplME=.c2b40ecd-5f83-4adf-b07d-4d34d196ed24@github.com>
References: <fHGFT7w4afEunhQKcP-Y6B6PKSczto3m4vqeWIzplME=.c2b40ecd-5f83-4adf-b07d-4d34d196ed24@github.com>
Message-ID: <58Qy1fulIAiaXHKhM-UuUaxA5H3mHtg1zrB-fa01ZyE=.cc6ca5f8-3dc5-4533-b746-9b6f558e5bb5@github.com>

On Fri, 2 Dec 2022 16:38:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the client-libs team.

**A note to reviewers:**

This PR has been automatically generated by converting all trailing spaces in key-value lines (ignoring empty lines and comments) in the property files into unicode sequences.

In a way, this is a no-op, converting one representation of the already existing space into another. But I think that most of these instances are likely to be bugs, and should thus be fixed.

I think the easiest way to fix those instances is to use the Github "suggestion" review mechanism: 
If you see a value where the trailing space should be removed, press the blue `+` in the gutter as usual, and then in the comment box press the `+/-` icon (or press `ctrl-G`/`cmd-G`). Now you get a copy of the offending line, and can edit it to remove the trailing unicode sequence. I can then easily accept the suggestion into the PR.

But you can also come with review feedback like "remove trailing spaces for all files in directory XXX" and I'll fix that for you.

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

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


From ihse at openjdk.org  Fri Dec  2 17:12:37 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:12:37 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: <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@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

This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs:

[JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit.

[JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team.

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

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


From ihse at openjdk.org  Fri Dec  2 17:12:39 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:12:39 GMT
Subject: Withdrawn: 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: <FucejIc47XdfLlKe8MOVxYBnv1k7GvnH1TgHiinx9ak=.b06a548a-3575-4456-8df4-f8804114105b@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]*$//'`.

This pull request has been closed without being integrated.

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

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


From ihse at openjdk.org  Fri Dec  2 17:14:23 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:14:23 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files
Message-ID: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>

[JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.

To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).

That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.

When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.

The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

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

Commit messages:
 - 8298047: Remove all non-significant trailing whitespace from properties files

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

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


From angorya at openjdk.org  Fri Dec  2 17:15:19 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Dec 2022 17:15:19 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
Message-ID: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>

On Fri, 2 Dec 2022 17:10:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> and instead I have split up this work in five different bugs

would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource?

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

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


From honkar at openjdk.org  Fri Dec  2 18:16:13 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 2 Dec 2022 18:16:13 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds
In-Reply-To: <fsj_jPApqfIlcqYr7d0YE3_EEJsxk2mlzt8awAnryIY=.eb3a88a5-ba92-4e11-a5cc-6068facf3164@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <fsj_jPApqfIlcqYr7d0YE3_EEJsxk2mlzt8awAnryIY=.eb3a88a5-ba92-4e11-a5cc-6068facf3164@github.com>
Message-ID: <TDgRUsXr7wPzPRMUMDePMKSKuNVLPdSqrHZU9VmHJmE=.961aceb1-b396-41c0-a986-0cfe49256fc6@github.com>

On Fri, 2 Dec 2022 03:37:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The above test was failing due to incorrect pixel color and wrong window bounds on Mac-ARM, Windows and Linux platforms.
>> 
>> The following changes have been made:
>> - Correct window bounds are obtained using the screen device being tested (this test checks FullScreen functionality on multiple screen devices).
>> - Color tolerance has been added for color check
>> - Instead of scanning the full screen to check pixel color, vertical and horizontal scans are done at the far right and bottom end to ensure that window is in full screen mode w.r.t to screen device and the window bounds are as expected.
>> 
>> CI testing passes on all platforms (tested 50 times per platform).
>
> test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 44:
> 
>> 42:  * @bug 8003173 7019055
>> 43:  * @summary Full-screen windows should have the proper insets.
>> 44:  * @run main FullScreenInsets
> 
> run main is not needed if no options are provided for the test. less one place to make a typo or copy-paste error in the name of the test.

Added the @run tag to be consistent with other jtreg tests. I can remove it in the next update.

> test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 61:
> 
>> 59:         final Frame wGreen = new Frame();
>> 60:         wGreen.setBackground(Color.GREEN);
>> 61:         wGreen.setUndecorated(true);
> 
> Why did you make that frame undecorated? I think the decoration was one of the reasons why the bug was reproduced.

When testing on Win10, observed that for a decorated frame the title bar is retained in full screen mode unlike some of the other applications (eg. Chrome and IDE in full screen mode). 

When I checked the Javadocs for [setFullScreenWindow(Window w)](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/GraphicsDevice.html#setFullScreenWindow(java.awt.Window)), it states that - _"It is unspecified and platform-dependent how decorated windows operate in full-screen mode. For this reason, it is recommended to turn off the decorations in a Frame or Dialog object by using the setUndecorated method."_  

For the above reasons and to aid testing the pixel-color across full-screen window without having to account for different platform specific title bar sizes, the frame was set as undecorated.

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

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


From honkar at openjdk.org  Fri Dec  2 18:25:46 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 2 Dec 2022 18:25:46 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds
In-Reply-To: <fsj_jPApqfIlcqYr7d0YE3_EEJsxk2mlzt8awAnryIY=.eb3a88a5-ba92-4e11-a5cc-6068facf3164@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <fsj_jPApqfIlcqYr7d0YE3_EEJsxk2mlzt8awAnryIY=.eb3a88a5-ba92-4e11-a5cc-6068facf3164@github.com>
Message-ID: <W9ecnomRZ8x5zdwg-zjV17WOW8vnx9YP67VPlmeszaw=.14af461e-0162-4aa9-b22d-b6163fb0c981@github.com>

On Fri, 2 Dec 2022 03:47:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The above test was failing due to incorrect pixel color and wrong window bounds on Mac-ARM, Windows and Linux platforms.
>> 
>> The following changes have been made:
>> - Correct window bounds are obtained using the screen device being tested (this test checks FullScreen functionality on multiple screen devices).
>> - Color tolerance has been added for color check
>> - Instead of scanning the full screen to check pixel color, vertical and horizontal scans are done at the far right and bottom end to ensure that window is in full screen mode w.r.t to screen device and the window bounds are as expected.
>> 
>> CI testing passes on all platforms (tested 50 times per platform).
>
> test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 51:
> 
>> 49:     private static Robot robot = null;
>> 50:     private static int deviceCount = 0;
>> 51:     private static final float TOLERANCE = 10;
> 
> Are you sure that we need so big tolerance just to capture the green and red colors? We have CheckCommonColors which checks all our common colors via robot, and seems it works fine w/o tolerance.

I see your point. Thanks you for suggesting CheckCommonColors. I will recheck using `CheckCommonColors` test on all platforms and reduce the tolerance to a lower value so that it has more strict constraint on allowed colors.

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

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


From prr at openjdk.org  Fri Dec  2 19:30:09 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 2 Dec 2022 19:30:09 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
Message-ID: <rSVFT259_79nKt_l2RyIYS4_u4-WzGqtAREcs0lOaTQ=.7567c0fe-f72c-4f4e-ba88-74ffb1d7b6fa@github.com>

On Thu, 1 Dec 2022 19:38:44 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix pointer to jlong conversion on x86

I imported the changes and submitted to our CI test system. There seem to be a number of failures of the provided tests.
java/awt/font/MacEmoji.java : fails on x64 and aarch64 with Error: can't find Emoji in test directory or libraries

java/awt/font/EmojiVariation.java :
failed on linux-aarch64 with Exception: java.lang.Error: Required font not found: Noto Color Emoji

I don't think a test should fail just because there are no Emoji fonts installed.
Lots of system configs will run into this relatively bleeding edge reqt.

and windows-64 fails this test with a REALLY long message repeating lots of times a message like
0023-COLOR: Expected color but rendered mono

java/awt/font/ComplexEmoji.java failed on linux-aarch64 with Exception: java.lang.Error: Required font not found: Noto Color Emoji

and failed on windows-x64 with Exception: 3: Empty image

java/awt/font/OutlineTextRendererEmoji.java: failed on aarch64 with Exception: java.lang.Error: Required font not found: Noto Color Emoji 

I haven't yet looked at how this behaves when manually testing on current platforms. These are just automated tests.

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

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


From achung at openjdk.org  Fri Dec  2 19:53:14 2022
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 2 Dec 2022 19:53:14 GMT
Subject: RFR: 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java
 fails with "No MouseReleased event on label!" [v2]
In-Reply-To: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
References: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
Message-ID: <6LZ-N08qj1nHeB4PJusLBXDp1aNBw1K_xhuzA767Y4g=.b27fca5e-5c62-477b-bafa-24a7dd281e11@github.com>

> Test was run on mac, windows, linux 50 times and passed after change
> Before fix, test fails about once every 50 runs on linux and windows platforms

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

  fixed imports, changed robot autodelay and added delay after creating gui

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11425/files
  - new: https://git.openjdk.org/jdk/pull/11425/files/ff6713c3..0e69811d

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

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

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


From honkar at openjdk.org  Fri Dec  2 22:28:08 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 2 Dec 2022 22:28:08 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds
In-Reply-To: <fsj_jPApqfIlcqYr7d0YE3_EEJsxk2mlzt8awAnryIY=.eb3a88a5-ba92-4e11-a5cc-6068facf3164@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <fsj_jPApqfIlcqYr7d0YE3_EEJsxk2mlzt8awAnryIY=.eb3a88a5-ba92-4e11-a5cc-6068facf3164@github.com>
Message-ID: <3ej6ouaDitHUBSwEwhv7G6cc6q_bG10cvEuyWG0xjYU=.87d1cc6a-dc2e-4cb0-b1bb-fb92bc8a0f69@github.com>

On Fri, 2 Dec 2022 03:43:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The above test was failing due to incorrect pixel color and wrong window bounds on Mac-ARM, Windows and Linux platforms.
>> 
>> The following changes have been made:
>> - Correct window bounds are obtained using the screen device being tested (this test checks FullScreen functionality on multiple screen devices).
>> - Color tolerance has been added for color check
>> - Instead of scanning the full screen to check pixel color, vertical and horizontal scans are done at the far right and bottom end to ensure that window is in full screen mode w.r.t to screen device and the window bounds are as expected.
>> 
>> CI testing passes on all platforms (tested 50 times per platform).
>
> test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 89:
> 
>> 87:             device.setFullScreenWindow(wRed);
>> 88:             sleep();
>> 89:             testWindowBounds(device.getFullScreenWindow().getBounds(), wRed);
> 
> You changed the code
> from:
>    comparing the bounds of the display mode and the bounds of the window
> to:
>    comparing the bounds of the window and the bounds of the window
> I do not think it is the right thing to do.

It was a miss - I meant to use the current ScreenDevice's DefaultConfiguration bounds - `device.getDefaultConfiguration().getBounds()` instead of `device.getFullScreenWindow().getBounds()`

I was debugging this further and found that the displayMode's width and height differ from the actual size of the full-screen windows as shown below for 2 screen extended display setup. The actual width and height of full screen window seem to match with `device.getDefaultConfiguration().getBounds()` and not with the display mode's which is what is being set here - https://github.com/openjdk/jdk/blob/2821fa9883cc9687b53e3bb5655732a614cff8fc/src/java.desktop/share/classes/java/awt/GraphicsDevice.java#L321

I'm currently looking into the past issues associated with this test case to understand the context of comparing the full screen window size to the size of display mode (if it was part of test requirement or issue to be solved).

(Tested on Windows)


No. of Screen Devices: 2

Testing on Screen Device# 0
Screen Device Default Config Bounds  Width: 1280.0  Height: 720.0
 Wrong window bounds: Expected: width = 1920, height = 1080 Actual: java.awt.Dimension[width=1280,height=720]
 Wrong window bounds: Expected: width = 1920, height = 1080 Actual: java.awt.Dimension[width=1280,height=720]
 
Testing on Screen Device# 1
Screen Device Default Config Bounds Width: 2293.0  Height: 960.0
 Wrong window bounds: Expected: width = 3440, height = 1440 Actual: java.awt.Dimension[width=2293,height=960]
 Wrong window bounds: Expected: width = 3440, height = 1440 Actual: java.awt.Dimension[width=2293,height=960]

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

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


From duke at openjdk.org  Fri Dec  2 22:51:11 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 2 Dec 2022 22:51:11 GMT
Subject: RFR: 8298042: Fix hidden but significant trailing whitespace in
 properties files for client code
In-Reply-To: <fHGFT7w4afEunhQKcP-Y6B6PKSczto3m4vqeWIzplME=.c2b40ecd-5f83-4adf-b07d-4d34d196ed24@github.com>
References: <fHGFT7w4afEunhQKcP-Y6B6PKSczto3m4vqeWIzplME=.c2b40ecd-5f83-4adf-b07d-4d34d196ed24@github.com>
Message-ID: <Yk42WvQF4qlRvW_W3DEkGW5_r0A3F3uj-5UuoTZjAQ0=.af6b6c39-3944-46e7-b0ad-4fca20ddfab7@github.com>

On Fri, 2 Dec 2022 16:38:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the client-libs team.

These bring to light inconsistencies between locales.
All but a few don't need spaces afterwards. The line-by-line reviews apply to the same properties in other locales in the same path. I looked at all of the usages and similar properties, and most were either put in JLabels, tooltips, or alt texts. Some strings are concatenated in Java code and the space can be put there instead.
Since a lot of them are in the java.desktop package, would they require a CSR to bring in consistency between locales?

src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 51:

> 49: ### Status ###
> 50: 
> 51: Status.loading=\u8AAD\u8FBC\u307F\u4E2D:\u0020

ja and zh-CN both have spaces, but en and de don't. The string is concatenated without a space in between in the demo code, so this would be technically correct (and en and de incorrect). An example of the current behavior is producing `????: ????` (correct) or `Loading:Button Demo` (incorrect).

The proper solution would be to remove the space and the colon, putting them in the code.

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

Judging by the context of "accessible description," I'm guessing that there doesn't need to be a space afterwards. It's otherwise unused.

src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 214:

> 212: ButtonDemo.radioX=<html><font size=2 color=red>3<bold>(HTML)</bold></font></html>
> 213: 
> 214: ButtonDemo.check1=1\u0020

Used only in JLabels. Since 2 and 3 don't have spaces afterwards (the usages are identical afaict), and since other locales like en don't have the space, it's fine to remove.

src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 224:

> 222: ButtonDemo.phone=\u96FB\u8A71\u0020
> 223: ButtonDemo.write=\u66F8\u8FBC\u307F
> 224: ButtonDemo.peace=\u30D4\u30FC\u30B9

It's only here that the space is present, while `write` and `peace` don't, nor does the en locale. It goes into the alt text of an icon, so a space afterwards is unnecessary.

src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 454:

> 452: SliderDemo.name=Slider\u30C7\u30E2
> 453: 
> 454: SliderDemo.slidervalue=Slider\u306E\u5024:\u0020

Unsure. It's used in four places. The two that use it concatenated should probably have a space added in the code and this removed.

src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties line 67:

> 65: FileChooser.newFolderTitle.textAndMnemonic=\u65B0\u5EFA\u6587\u4EF6\u5939
> 66: FileChooser.fileNameLabel.textAndMnemonic=\u6587\u4EF6:
> 67: FileChooser.saveDialogFileNameLabel.textAndMnemonic=\u53E6\u5B58\u4E3A:\u0020

Unused, but other locales don't have the space. Dunno.

src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties line 178:

> 176: SplitPane.rightButton.textAndMnemonic=\u53F3\u952E
> 177: # Used for Isindex
> 178: IsindexView.prompt=\u8FD9\u662F\u53EF\u641C\u7D22\u7D22\u5F15\u3002\u8BF7\u8F93\u5165\u641C\u7D22\u5173\u952E\u5B57:\u0020

Inserted into a label. No use for a space afterwards. Other locales don't have it, but zh-TW does. Down further, there are identical-looking usages of `IsindexView.prompt`.

src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties line 11:

> 9: ImageUtil0=The supplied Raster does not represent a binary data set.
> 10: ImageUtil1=The provided sample model is null.
> 11: ImageUtil2=The provided image cannot be encoded using:\u0020

Already concatenated with a space in `ImageUtil.java`. Creates a double space.

src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties line 57:

> 55: FileChooser.acceptAllFileFilter.textAndMnemonic=\u6240\u6709\u6587\u4EF6
> 56: FileChooser.newFolderButton.textAndMnemonic=\u65B0\u6587\u4EF6\u5939(&N)
> 57: FileChooser.newFolderDialog.textAndMnemonic=\u6587\u4EF6\u5939\u540D:\u0020

Unused, and other locales don't have a space. Remove?

src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties line 68:

> 66: FileChooser.openDialogTitle.textAndMnemonic=\u6253\u5F00
> 67: FileChooser.pathLabel.textAndMnemonic=\u9009\u5B9A\u5185\u5BB9(&S):
> 68: FileChooser.filterLabel.textAndMnemonic=\u7B5B\u9009\u5668:\u0020

Unused, and other locales don't have a space. Also remove?

src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties line 58:

> 56: FileChooser.foldersLabel.textAndMnemonic=Car&telle
> 57: FileChooser.filesLabel.textAndMnemonic=F&ile
> 58: FileChooser.enterFileNameLabel.textAndMnemonic=Immettere il &nome file:\u0020

Unused, but most have the space included (except for en, oddly). Put a space in en?

src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 65:

> 63: label.size=\u5927\u5C0F(&Z):
> 64: label.source=\u6765\u6E90(&C):
> 65: label.status=\u72B6\u6001:\u0020

It is more consistent to have no spaces afterwards.

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties line 47:

> 45: 
> 46: FileChooser.lookInLabel.textAndMnemonic=\u67E5\u627E(&I):
> 47: FileChooser.saveInLabel.textAndMnemonic=\u4FDD\u5B58:\u0020

More consistent without the space.

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/FileChooserDemo.properties line 11:

> 9: FileChooserDemo.filter.blur = blur
> 10: FileChooserDemo.filter.edge = edge
> 11: FileChooserDemo.filter.sharpen = sharpen\u0020

Uh, remove? No other strings have a space.

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/FileChooserDemo.properties line 22:

> 20: FileChooserDemo.rotateright.tooltip = Rotate right\u0020
> 21: FileChooserDemo.fliphorizontal.tooltip = Flip horizontal\u0020
> 22: FileChooserDemo.flipvertical.tooltip = Flip vertical\u0020

Tooltips don't need a space.

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/TableDemo.properties line 12:

> 10: 
> 11: TableDemo.noDataStatusLabel=No data loaded
> 12: TableDemo.loadingStatusLabel=Loading data:\u0020

It might need a space? I can't tell.

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/TableDemo.properties line 14:

> 12: TableDemo.loadingStatusLabel=Loading data:\u0020
> 13: TableDemo.rowCountLabel=Showing\u0020
> 14: TableDemo.searchCountLabel=Search found\u0020

These are concatenated, so either keep the space or update the code to include the space.

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/togglebutton/resources/ToggleButtonDemo.properties line 3:

> 1: ### Button Demo ###
> 2: 
> 3: ToggleButtonDemo.accessible_description=The ButtonDemo shows examples of using JButton, JRadioButton, JToggleButton, and JCheckBox\u0020

Unused. Can be removed.

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/togglebutton/resources/ToggleButtonDemo.properties line 38:

> 36: ToggleButtonDemo.customcheck=A custom lightbulb checkbox.
> 37: 
> 38: ToggleButtonDemo.phone=Phone\u0020

Not necessary. All are just placed in labels.

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

Changes requested by SWinxy at github.com (no known OpenJDK username).

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


From ihse at openjdk.org  Fri Dec  2 23:06:08 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 23:06:08 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
 <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>
Message-ID: <BJDInfZQ8pfjgoiYRHsRTcw2dxBWSu4ZcsNC0wktKPM=.9fef5722-e842-4119-a380-46b5dd3bbc02@github.com>

On Fri, 2 Dec 2022 17:12:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs:
>> 
>> [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit.
>> 
>> [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team.
>
>> and instead I have split up this work in five different bugs
> 
> would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource?

@andy-goryachev-oracle No. Any such test is up to the component owners to write, if they deem it fitting.

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

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


From prr at openjdk.org  Fri Dec  2 23:16:31 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 2 Dec 2022 23:16:31 GMT
Subject: RFR: 8273357: SecurityManager deprecation warning from
 java/awt/regtesthelpers/Util.java
Message-ID: <BQDfdm36vDBLkBVERvrlpEOPSPWj7tPPkxEOtABojC4=.e139e472-d053-4cba-9d2d-9cdaeb361fbc@github.com>

The compilation of a number of tests that use regtesthelpers/Util.java are getting a warning about
the deprecation-for-removal of the SecurityManager.
This suppresses that warning.

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

Commit messages:
 - 8273357

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

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


From duke at openjdk.org  Fri Dec  2 23:46:49 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Fri, 2 Dec 2022 23:46:49 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
Message-ID: <_ThYQz3ZcgVHN34873INYiVEo_iozgCj84majQ3KHig=.91a9229c-cf04-4b81-af50-9be40363b875@github.com>

On Thu, 1 Dec 2022 19:38:44 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix pointer to jlong conversion on x86

Gosh these tests were OK last time ran them, maybe broke with master merging or something. Unfortunately I'll only have time to look at this next year, will let you know what I find.
If you gonna run the tests manually (and assuming there's no regression), it should work without any special configuration on any sane Windows & macOS. As for Linux, I tested this on a desktop Ubuntu 20.04-22.04, but note that minimal installation doesn't include `Noto Color Emoji`.

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

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


From kizune at openjdk.org  Fri Dec  2 23:52:55 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 2 Dec 2022 23:52:55 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus [v2]
In-Reply-To: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
Message-ID: <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>

> Set the text caret to be visible but not blinking on the non-editable text area.

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

  Handling the case when blink rate is set while component is unedited
  Test HidingSelectionTest.java is rewritten and corrected.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11408/files
  - new: https://git.openjdk.org/jdk/pull/11408/files/2f286343..97bf7c55

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

  Stats: 55 lines in 2 files changed: 13 ins; 34 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/11408.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11408/head:pull/11408

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


From kizune at openjdk.org  Fri Dec  2 23:52:55 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 2 Dec 2022 23:52:55 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus
In-Reply-To: <e7ITSsOpcKtlC2bJNzIM3PFCUcoRZdfRi0mr1JxsgFE=.f37d4fe5-6a07-427c-b87f-b0ba50efcc6c@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <e7ITSsOpcKtlC2bJNzIM3PFCUcoRZdfRi0mr1JxsgFE=.f37d4fe5-6a07-427c-b87f-b0ba50efcc6c@github.com>
Message-ID: <VUwbo01Ivv81AevheTugl-_xosvdnzR7jhFhJtdViaE=.493aee6b-d32a-4258-8271-b25a281273d8@github.com>

On Fri, 2 Dec 2022 04:16:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I wonder how other native applications handle this. Can the non-blinking cursor be considered a hang of the application?

Different application handle it differently but most os them do not claim to pass the VPAT certification. I do not think that non-blinking cursor can be treated as hanged application.

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

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


From kizune at openjdk.org  Fri Dec  2 23:58:11 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 2 Dec 2022 23:58:11 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus [v2]
In-Reply-To: <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
Message-ID: <UtmmDvuZenm-kNcGBUOCK792hLEI_NXsWg1yu5zSHBo=.7aa4dd3a-427a-4729-9e68-40c0a173465f@github.com>

On Fri, 2 Dec 2022 23:52:55 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Set the text caret to be visible but not blinking on the non-editable text area.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handling the case when blink rate is set while component is unedited
>   Test HidingSelectionTest.java is rewritten and corrected.

I added the setBlinkRate handling when component is unedited so the new rate is preserved.

Also setting blink rate to a negative value causes InvalidArgumentException because it is checked further down the line in javax.swing.Timer.checkDelay() method so it is a non-issue.

Finally the HidingSelectionTest had to be re-written because its logic is incorrect and it passes on MacOS and Windows only because of the flaw in the test that allows false positive.

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

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


From duke at openjdk.org  Sat Dec  3 00:29:05 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Sat, 3 Dec 2022 00:29:05 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <rSVFT259_79nKt_l2RyIYS4_u4-WzGqtAREcs0lOaTQ=.7567c0fe-f72c-4f4e-ba88-74ffb1d7b6fa@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
 <rSVFT259_79nKt_l2RyIYS4_u4-WzGqtAREcs0lOaTQ=.7567c0fe-f72c-4f4e-ba88-74ffb1d7b6fa@github.com>
Message-ID: <539TGFw7CDhYkouny4m5sZVdypJTrbxCAwkwRshQDOg=.f3494f47-ac04-4541-8f9c-11e70dfb88aa@github.com>

On Fri, 2 Dec 2022 19:27:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix pointer to jlong conversion on x86
>
> I imported the changes and submitted to our CI test system. There seem to be a number of failures of the provided tests.
> java/awt/font/MacEmoji.java : fails on x64 and aarch64 with Error: can't find Emoji in test directory or libraries
> 
> java/awt/font/EmojiVariation.java :
> failed on linux-aarch64 with Exception: java.lang.Error: Required font not found: Noto Color Emoji
> 
> I don't think a test should fail just because there are no Emoji fonts installed.
> Lots of system configs will run into this relatively bleeding edge reqt.
> 
> and windows-64 fails this test with a REALLY long message repeating lots of times a message like
> 0023-COLOR: Expected color but rendered mono
> 
> java/awt/font/ComplexEmoji.java failed on linux-aarch64 with Exception: java.lang.Error: Required font not found: Noto Color Emoji
> 
> and failed on windows-x64 with Exception: 3: Empty image
> 
> java/awt/font/OutlineTextRendererEmoji.java: failed on aarch64 with Exception: java.lang.Error: Required font not found: Noto Color Emoji 
> 
> I haven't yet looked at how this behaves when manually testing on current platforms. These are just automated tests.

@prrace just a few comments regarding your CI results:
1. I don't quite understand the error message for `MacEmoji`, but note that this test was renamed to `Emoji`
2. All Linux fails come from absent emoji font, it would probably work with installed font
3. Windows renders only monochrome emoji - may it be an old Windows where there's no color emoji font? (Win8 or older?)

So macOS seems to work and others may be just configuration problems, definitely worth trying to run manually on modern Windows & Linux.

And about failing from not found font: I will fix this. AFAIK currently if we gonna skip the test, we just pretend like it succeeded. There's no way to explicitly mark test as skipped, right?

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

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


From prr at openjdk.org  Sat Dec  3 01:34:10 2022
From: prr at openjdk.org (Phil Race)
Date: Sat, 3 Dec 2022 01:34:10 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <rSVFT259_79nKt_l2RyIYS4_u4-WzGqtAREcs0lOaTQ=.7567c0fe-f72c-4f4e-ba88-74ffb1d7b6fa@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
 <rSVFT259_79nKt_l2RyIYS4_u4-WzGqtAREcs0lOaTQ=.7567c0fe-f72c-4f4e-ba88-74ffb1d7b6fa@github.com>
Message-ID: <huZwHfNmEc67K01PB47ucGky-vUlSUnRRJuAs6qGstc=.dc636ea4-1457-4f8c-b516-8b05da8c1992@github.com>

On Fri, 2 Dec 2022 19:27:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix pointer to jlong conversion on x86
>
> I imported the changes and submitted to our CI test system. There seem to be a number of failures of the provided tests.
> java/awt/font/MacEmoji.java : fails on x64 and aarch64 with Error: can't find Emoji in test directory or libraries
> 
> java/awt/font/EmojiVariation.java :
> failed on linux-aarch64 with Exception: java.lang.Error: Required font not found: Noto Color Emoji
> 
> I don't think a test should fail just because there are no Emoji fonts installed.
> Lots of system configs will run into this relatively bleeding edge reqt.
> 
> and windows-64 fails this test with a REALLY long message repeating lots of times a message like
> 0023-COLOR: Expected color but rendered mono
> 
> java/awt/font/ComplexEmoji.java failed on linux-aarch64 with Exception: java.lang.Error: Required font not found: Noto Color Emoji
> 
> and failed on windows-x64 with Exception: 3: Empty image
> 
> java/awt/font/OutlineTextRendererEmoji.java: failed on aarch64 with Exception: java.lang.Error: Required font not found: Noto Color Emoji 
> 
> I haven't yet looked at how this behaves when manually testing on current platforms. These are just automated tests.

> @prrace just a few comments regarding your CI results:
> 
> 1. I don't quite understand the error message for `MacEmoji`, but note that this test was renamed to `Emoji`

Indeed the contents are a class called Emoji
I don't know why the patch still called it MacEmoji

Hmm I applied the patch skara generated and it looks like macOS's patch didn't do what it was asked

This is what was in the patch (diff) file -
diff --git a/test/jdk/java/awt/font/MacEmoji.java b/test/jdk/java/awt/font/Emoji.java
similarity index 91%
rename from test/jdk/java/awt/font/MacEmoji.java
rename to test/jdk/java/awt/font/Emoji.java
index 198db5c107fb..b44c68db7caa 100644
--- a/test/jdk/java/awt/font/MacEmoji.java
+++ b/test/jdk/java/awt/font/Emoji.java
 
> 2. All Linux fails come from absent emoji font, it would probably work with installed font

Yes, I expect that too, but the problem is we don't control all the systems used to test.

> 3. Windows renders only monochrome emoji - may it be an old Windows where there's no color emoji font? (Win8 or older?)

Not exactly its a server version of Windows 10. Today, all of the "headless" tests run on Windows Server.
Either the font isn't available for that OS, or quite possibly installing all the fonts isn't something that is done.
The test does need to be hardened against an absence of a font. Marking it headful isn't a guarantee either because they could still run on Windows Server.


> 
> So macOS seems to work and others may be just configuration problems, definitely worth trying to run manually on modern Windows & Linux.

This is largely outside of our control. They need to pass on supported configs.

> 
> And about failing from not found font: I will fix this. AFAIK currently if we gonna skip the test, we just pretend like it succeeded. There's no way to explicitly mark test as skipped, right?

Usually yes.

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

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


From prr at openjdk.org  Sat Dec  3 01:41:59 2022
From: prr at openjdk.org (Phil Race)
Date: Sat, 3 Dec 2022 01:41:59 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
Message-ID: <-IIk9-YpnFdXDep8NF264w5bAaGgY9hqO5qfgNkO120=.3eea29c9-84a8-4749-874f-f0c2f33fa17b@github.com>

On Thu, 1 Dec 2022 19:38:44 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix pointer to jlong conversion on x86

I submitted a skara bug about the rename https://bugs.openjdk.org/browse/SKARA-1711

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

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


From honkar at openjdk.org  Sat Dec  3 02:05:00 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Sat, 3 Dec 2022 02:05:00 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds
In-Reply-To: <fsj_jPApqfIlcqYr7d0YE3_EEJsxk2mlzt8awAnryIY=.eb3a88a5-ba92-4e11-a5cc-6068facf3164@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <fsj_jPApqfIlcqYr7d0YE3_EEJsxk2mlzt8awAnryIY=.eb3a88a5-ba92-4e11-a5cc-6068facf3164@github.com>
Message-ID: <WHwSAx7uiITjCyyesqeA_2AysPWFanwfq7qL15Fc1HM=.a9dba87a-373f-48e7-bc4f-e0e4b0a9d524@github.com>

On Fri, 2 Dec 2022 03:43:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The above test was failing due to incorrect pixel color and wrong window bounds on Mac-ARM, Windows and Linux platforms.
>> 
>> The following changes have been made:
>> - Correct window bounds are obtained using the current ScreenDevice's DefaultConfig bounds (this test checks FullScreen functionality on multiple screen devices).
>> - Color tolerance has been added for color check
>> - Instead of scanning the full screen to check pixel color, vertical and horizontal scans are done at the far right and bottom end to ensure that window is in full screen mode w.r.t to screen device and the window bounds are as expected.
>> 
>> CI testing passes on all platforms (tested 50 times per platform).
>
> test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 89:
> 
>> 87:             device.setFullScreenWindow(wRed);
>> 88:             sleep();
>> 89:             testWindowBounds(device.getFullScreenWindow().getBounds(), wRed);
> 
> You changed the code
> from:
>    comparing the bounds of the display mode and the bounds of the window
> to:
>    comparing the bounds of the window and the bounds of the window
> I do not think it is the right thing to do.

@mrserb I noticed that the difference in actual size vs display mode dimensions is because the actual size is scaled down by the device's current scale unlike display mode. This can be resolved by running the test at uiScale=1.

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

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


From kizune at openjdk.org  Sat Dec  3 02:57:04 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 3 Dec 2022 02:57:04 GMT
Subject: RFR: 8273357: SecurityManager deprecation warning from
 java/awt/regtesthelpers/Util.java
In-Reply-To: <BQDfdm36vDBLkBVERvrlpEOPSPWj7tPPkxEOtABojC4=.e139e472-d053-4cba-9d2d-9cdaeb361fbc@github.com>
References: <BQDfdm36vDBLkBVERvrlpEOPSPWj7tPPkxEOtABojC4=.e139e472-d053-4cba-9d2d-9cdaeb361fbc@github.com>
Message-ID: <CNaQumkmNCR97U5GPmoEEHetyGbUUQuuoW5fCX2ppt8=.495cfc88-002f-40ae-9265-1fa1936bf7ff@github.com>

On Fri, 2 Dec 2022 23:07:45 GMT, Phil Race <prr at openjdk.org> wrote:

> The compilation of a number of tests that use regtesthelpers/Util.java are getting a warning about
> the deprecation-for-removal of the SecurityManager.
> This suppresses that warning.

Marked as reviewed by kizune (Reviewer).

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

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


From dnguyen at openjdk.org  Sat Dec  3 05:28:09 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Sat, 3 Dec 2022 05:28:09 GMT
Subject: RFR: 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java
 fails with "No MouseReleased event on label!" [v2]
In-Reply-To: <6LZ-N08qj1nHeB4PJusLBXDp1aNBw1K_xhuzA767Y4g=.b27fca5e-5c62-477b-bafa-24a7dd281e11@github.com>
References: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
 <6LZ-N08qj1nHeB4PJusLBXDp1aNBw1K_xhuzA767Y4g=.b27fca5e-5c62-477b-bafa-24a7dd281e11@github.com>
Message-ID: <5_5ErBi8xfQ0LBeO7olfhQKvIQds1FVy9GfKpVUu5lY=.77ea50cc-0762-463b-954e-a0742bf6dba2@github.com>

On Fri, 2 Dec 2022 19:53:14 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Test was run on mac, windows, linux 50 times and passed after change
>> Before fix, test fails about once every 50 runs on linux and windows platforms
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed imports, changed robot autodelay and added delay after creating gui

test/jdk/java/awt/Mouse/EnterExitEvents/DragWindowTest.java line 81:

> 79: 
> 80:         robot.delay(250);
> 81:         robot.waitForIdle();

Not positive if it matters, but from what I've seen the delay usually comes after waitForIdle.

But I also ran the test and it seems to be OK.

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

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


From itakiguchi at openjdk.org  Sat Dec  3 08:14:01 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Sat, 3 Dec 2022 08:14:01 GMT
Subject: RFR: 8298006: Build failure by maybe-uninitialized error on Linux
 s390x GCC8
In-Reply-To: <KYb8vUnHwihJUgekC3c9drcncpys_PbwtY4OX2eM0Jo=.a3e6776f-c06f-4885-a9f7-48747383bfc0@github.com>
References: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
 <KYb8vUnHwihJUgekC3c9drcncpys_PbwtY4OX2eM0Jo=.a3e6776f-c06f-4885-a9f7-48747383bfc0@github.com>
Message-ID: <4v4hi71PiXE_VmYAZn-7eUlnd3SbjvwTueB8zAdrcxc=.fdc7ccf5-ccbf-478e-9add-ff892b2ca2d1@github.com>

On Fri, 2 Dec 2022 13:39:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I changed GCC toolchain from GCC6 to GCC8 on SLES12SP5 Linux s390x.
>> I could see following errors:
>> 
>> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c: In function 'allocateRasterArray':
>> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:2944:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> ?????????????????????????????(((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])
>> ?????????????????????????????????????????????????????????????????????~~~~^~~
>> 
>> 
>> According to error messages,
>> roff and loff may not be initialized.
>
> Just because you get a compilation error does not mean the issue belongs with the build group. This is just about the source code in AWT, so the client-libs team will handle this review.
> 
> That being said, I did have a look at the code and I think they might be skeptical. There seems to be no inherent s390x change here, rather the compiler you are using seem to be a bit trigger-happy on this analysis. 
> 
> Also, both gcc 6 and 8 are incredibly old. Gcc 6 is from 2016, and gcc 8 is from  2018. I would recommend you get a newer gcc version instead, or possibly build with `--disable-warnings-as-errors`.

Thanks @magicus .
`--disable-warnings-as-errors` option worked fine as expected

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

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


From duke at openjdk.org  Sat Dec  3 08:57:02 2022
From: duke at openjdk.org (ScientificWare)
Date: Sat, 3 Dec 2022 08:57:02 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v10]
In-Reply-To: <_29_WvWhzoaKDCRsAplWwmgW4bd2xP0t_PLx8MOhM-Y=.70319c16-3b88-46e0-9024-ac4f768e1ebb@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <_29_WvWhzoaKDCRsAplWwmgW4bd2xP0t_PLx8MOhM-Y=.70319c16-3b88-46e0-9024-ac4f768e1ebb@github.com>
Message-ID: <WHKlAMFWWiRY5McWCsCiQmuhg5qH6R1zB-LEYPLhj5U=.7f5abc27-4d32-4d3c-a9e7-4257ce113f5b@github.com>

On Tue, 27 Sep 2022 03:17:26 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
>> 
>> This is tracked in JBS as 
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
>> 
>> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
>> 
>> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrects a value in a message.
>   
>   A message is added to the result in case of failure only. The updated code does not output the actual value. The tested color is #f12a instead of #f00a.

Waiting a validation.

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

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


From aivanov at openjdk.org  Sat Dec  3 13:00:54 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 3 Dec 2022 13:00:54 GMT
Subject: RFR: 8273357: SecurityManager deprecation warning from
 java/awt/regtesthelpers/Util.java
In-Reply-To: <BQDfdm36vDBLkBVERvrlpEOPSPWj7tPPkxEOtABojC4=.e139e472-d053-4cba-9d2d-9cdaeb361fbc@github.com>
References: <BQDfdm36vDBLkBVERvrlpEOPSPWj7tPPkxEOtABojC4=.e139e472-d053-4cba-9d2d-9cdaeb361fbc@github.com>
Message-ID: <WX5-zYSvwJH6w5971cuWuw4Pj1z9eGfNvhDKDaCeMEs=.0072f4c0-c011-464f-ab47-6fb2c1d0784a@github.com>

On Fri, 2 Dec 2022 23:07:45 GMT, Phil Race <prr at openjdk.org> wrote:

> The compilation of a number of tests that use regtesthelpers/Util.java are getting a warning about
> the deprecation-for-removal of the SecurityManager.
> This suppresses that warning.

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.org  Sat Dec  3 13:01:51 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 3 Dec 2022 13:01:51 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus [v2]
In-Reply-To: <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
Message-ID: <kjwZwCz7Xk6aZUii34xNkE4MuTHFG_rAiTOIhF46A08=.dc303ef2-2250-46b5-b5b2-15a2f5190c64@github.com>

On Fri, 2 Dec 2022 23:52:55 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Set the text caret to be visible but not blinking on the non-editable text area.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handling the case when blink rate is set while component is unedited
>   Test HidingSelectionTest.java is rewritten and corrected.

At least on Windows, non-editable text controls have a blinking caret. Just open Properties of any file in Windows Explorer. All the information is displayed in non-editable text controls except for the file name which is in an editable one. The non-editable text controls in Properties dialog have no borders, so no other indication but the blinking caret indicates the control is focused. It is possible to add the border to a text control.

I don't think a non-blinking caret is a good idea.

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

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


From duke at openjdk.org  Sat Dec  3 13:11:49 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Sat, 3 Dec 2022 13:11:49 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
Message-ID: <TwYZeDMreV__UCy3KpmYzXmFYOo0pbfirO-XKk1ESYM=.d8158164-0bb3-4d61-a502-f7e55568c5c6@github.com>

On Thu, 1 Dec 2022 19:38:44 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix pointer to jlong conversion on x86

That's a real pain how skipped tests just silently pass. Regression tests should catch regressions, not pretend that everything is OK when they in fact didn't test anything. I believe skipping a test should be explicit, it's not a "Passed" nor "Failed" state, it's more like "Unknown". Would be very unfortunate to see green tests in CI and then find a regression which happened million years ago just because this test was skipped all the time but you never knew. Even agreeing on some special exit code for skipped tests would already be a good step forward. Just a point for a discussion.

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

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


From duke at openjdk.org  Sat Dec  3 22:19:48 2022
From: duke at openjdk.org (Rajat Mahajan)
Date: Sat, 3 Dec 2022 22:19:48 GMT
Subject: RFR: 8297450: ScaledTextFieldBorderTest.java fails when run with -show
 parameter
Message-ID: <DFCfeHM00dvRfICYgSRnY1t0zYN9UJHsCOyG6rKU4xU=.820d06c3-2815-4e8b-a3a9-e6ac73ddaea5@github.com>

Added createVerticalStrut in between textfields to fix this issue.

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

Commit messages:
 - 8297450: ScaledTextFieldBorderTest.java fails when run with -show parameter

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

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


From aivanov at openjdk.org  Sat Dec  3 23:41:54 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 3 Dec 2022 23:41:54 GMT
Subject: RFR: 8297450: ScaledTextFieldBorderTest.java fails when run with
 -show parameter
In-Reply-To: <DFCfeHM00dvRfICYgSRnY1t0zYN9UJHsCOyG6rKU4xU=.820d06c3-2815-4e8b-a3a9-e6ac73ddaea5@github.com>
References: <DFCfeHM00dvRfICYgSRnY1t0zYN9UJHsCOyG6rKU4xU=.820d06c3-2815-4e8b-a3a9-e6ac73ddaea5@github.com>
Message-ID: <zEfRVDECp5vM0OhGuTiGI_8uj6VG3ffAHzwLBLGgGwc=.74bff443-25e6-4b64-9702-7450d5e8b246@github.com>

On Sat, 3 Dec 2022 22:11:47 GMT, Rajat Mahajan <duke at openjdk.org> wrote:

> Added createVerticalStrut in between textfields to fix this issue.

Marked as reviewed by aivanov (Reviewer).

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

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


From kizune at openjdk.org  Sun Dec  4 22:13:04 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Sun, 4 Dec 2022 22:13:04 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip
In-Reply-To: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
Message-ID: <hjbwmU0nYwGP3H9HRGQrE3fwnDI_cmazC_hoOumqQVY=.7748bb21-cee3-4af1-bac7-595c8c7493a8@github.com>

On Fri, 3 Jun 2022 15:43:39 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add try/catch clause to ignore an exception since it is harmless for we isolated
> the massge data before passing it ro processor.
> Add test case.

Just uploaded the new version with proper length analysis so would be thankful for the continuation of the review.

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

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


From kizune at openjdk.org  Sun Dec  4 22:17:55 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Sun, 4 Dec 2022 22:17:55 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip [v2]
In-Reply-To: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
Message-ID: <6Y4AZanzqQvl5-du1LLmS3VG9tLYTbaQr1aRWx7XV3U=.7b428208-eb6e-4a94-ba34-2e22349201fd@github.com>

> Add try/catch clause to ignore an exception since it is harmless for we isolated
> the massge data before passing it ro processor.
> Add test case.

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

 - Got rid of the try/catch and using the proper per-case data length
   analysis.
 - Merge branch 'master' into JDK-8282578
 - Merge branch 'master' of https://github.com/azuev-java/jdk into JDK-8282578
 - Merge branch 'master'
 - 8282578: AIOOBE in javax.sound.sampled.Clip
   
   Surround SysEx message processing block with try/catch allowing MIDI subsystem to
   attempt to ingest the rest of the file.
   
   Added test case.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9016/files
  - new: https://git.openjdk.org/jdk/pull/9016/files/d085cfb1..f2ff2d14

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

  Stats: 687730 lines in 9247 files changed: 362349 ins; 221489 del; 103892 mod
  Patch: https://git.openjdk.org/jdk/pull/9016.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9016/head:pull/9016

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


From alexey.ushakov at jetbrains.com  Sun Dec  4 23:07:52 2022
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Mon, 5 Dec 2022 00:07:52 +0100
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <TwYZeDMreV__UCy3KpmYzXmFYOo0pbfirO-XKk1ESYM=.d8158164-0bb3-4d61-a502-f7e55568c5c6@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
 <TwYZeDMreV__UCy3KpmYzXmFYOo0pbfirO-XKk1ESYM=.d8158164-0bb3-4d61-a502-f7e55568c5c6@github.com>
Message-ID: <71A42B02-BF76-4F95-9FE5-F2179DEF09D7@jetbrains.com>

> That's a real pain how skipped tests just silently pass. Regression tests should catch regressions, not pretend that everything is OK when they in fact didn't test anything

There are several options to resolve this problem without failing the tests:
- you can provide diagnostic message, so passing for configurations missing necessary fonts won?t be silent
- create your own font with necessary properties and submit it within the fix

Best Regards,
Alexey


> On Dec 3, 2022, at 2:11 PM, Nikita Gubarkov <duke at openjdk.org> wrote:
> 
> On Thu, 1 Dec 2022 19:38:44 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:
> 
>>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>>> It includes:
>>> - Bitmap glyph loading via Freetype
>>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>> 
>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  Fix pointer to jlong conversion on x86
> 
> That's a real pain how skipped tests just silently pass. Regression tests should catch regressions, not pretend that everything is OK when they in fact didn't test anything. I believe skipping a test should be explicit, it's not a "Passed" nor "Failed" state, it's more like "Unknown". Would be very unfortunate to see green tests in CI and then find a regression which happened million years ago just because this test was skipped all the time but you never knew. Even agreeing on some special exit code for skipped tests would already be a good step forward. Just a point for a discussion.
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/4798



From kizune at openjdk.org  Sun Dec  4 23:29:44 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Sun, 4 Dec 2022 23:29:44 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus [v2]
In-Reply-To: <kjwZwCz7Xk6aZUii34xNkE4MuTHFG_rAiTOIhF46A08=.dc303ef2-2250-46b5-b5b2-15a2f5190c64@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
 <kjwZwCz7Xk6aZUii34xNkE4MuTHFG_rAiTOIhF46A08=.dc303ef2-2250-46b5-b5b2-15a2f5190c64@github.com>
Message-ID: <BYRO2l4rVgUl1fIXrLCiqdZPeQHyDJR6WQOgg6a3NDU=.be0a7781-513c-4396-b5d7-0bd5d45bb182@github.com>

On Sat, 3 Dec 2022 12:57:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> At least on Windows, non-editable text controls have a blinking caret.

Well, Windows is an important platform but it is not the only one we care about. On Ubuntu 22 the editable text field has the blinking cursor and non-editable has a non-blinking - to indicate that text can not be entered or changed but can be selected and copied and that's just one of examples of the difference in behaviour on different platforms. Based on that i would say that as a common ground i propose the non-blinking cursor on non-editable text components and if some platform needs an adjustments - we can always file a bug and override that in the platform-specific LaF like AquaCaret does.

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

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


From psadhukhan at openjdk.org  Mon Dec  5 04:14:39 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 5 Dec 2022 04:14:39 GMT
Subject: RFR: 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java
 fails with "No MouseReleased event on label!" [v2]
In-Reply-To: <EIzB-rTp4nCixEH4PXZXGobNojriwq_9sjnc9sexNPw=.0bfe74ab-b190-46e9-a3d8-5bb528644f04@github.com>
References: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
 <EIzB-rTp4nCixEH4PXZXGobNojriwq_9sjnc9sexNPw=.0bfe74ab-b190-46e9-a3d8-5bb528644f04@github.com>
Message-ID: <eiXE_NG-GTbzWiUbJdfKxlhQCa-5TEGjgrcPritFM-w=.44904d95-af67-4d5e-9b9e-d263173263e4@github.com>

On Wed, 30 Nov 2022 07:57:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed imports, changed robot autodelay and added delay after creating gui
>
> test/jdk/java/awt/Mouse/EnterExitEvents/DragWindowTest.java line 58:
> 
>> 56: 
>> 57:         Robot robot = new Robot();
>> 58:         robot.setAutoDelay(250);
> 
> We normally do not need so much delay for test to work, 100ms being the norm which has sufficed for other tests.
> Maybe you need to wait robot.delay after creating and showing the GUI which is not done here.
> Also, this test has heavyweight and lightweight mix, for ex. MyDragWindow class uses JPanel but not in EDT which can result in some timing issue you are seeing, either it needs to be in EDT or can it be changed to AWT Panel as done elsewhere in the test?
> 
> ALso, please change the wildcards imports while you are at it..

JPanel question is still unanswered/unchanged...

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

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


From psadhukhan at openjdk.org  Mon Dec  5 05:32:17 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 5 Dec 2022 05:32:17 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus [v2]
In-Reply-To: <UtmmDvuZenm-kNcGBUOCK792hLEI_NXsWg1yu5zSHBo=.7aa4dd3a-427a-4729-9e68-40c0a173465f@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
 <UtmmDvuZenm-kNcGBUOCK792hLEI_NXsWg1yu5zSHBo=.7aa4dd3a-427a-4729-9e68-40c0a173465f@github.com>
Message-ID: <wqFE72k3aqBWCwIoGYouYKkoOK3jyEbfE0ycX9slbt4=.3bc3085f-03ef-482c-bf6a-f2ff5e524ed3@github.com>

On Fri, 2 Dec 2022 23:54:21 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Finally the HidingSelectionTest had to be re-written because its logic is incorrect and it passes on MacOS and Windows only because of the flaw in the test that allows false positive.

The test is problemlisted for windows so not sure if the observation "passes on Windows" is correct..if it is, please deproblemlist it..

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

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


From serb at openjdk.org  Mon Dec  5 05:53:00 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 5 Dec 2022 05:53:00 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus
In-Reply-To: <VUwbo01Ivv81AevheTugl-_xosvdnzR7jhFhJtdViaE=.493aee6b-d32a-4258-8271-b25a281273d8@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <e7ITSsOpcKtlC2bJNzIM3PFCUcoRZdfRi0mr1JxsgFE=.f37d4fe5-6a07-427c-b87f-b0ba50efcc6c@github.com>
 <VUwbo01Ivv81AevheTugl-_xosvdnzR7jhFhJtdViaE=.493aee6b-d32a-4258-8271-b25a281273d8@github.com>
Message-ID: <xJz52QqQG3jjK_eODsEXefcjWz7dfCLa29VepSCwYtE=.1757660e-6211-4917-9a41-e9d5908ccecc@github.com>

On Fri, 2 Dec 2022 23:49:17 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Different application handle it differently but most os them do not claim to pass the VPAT certification. I do not think that non-blinking cursor can be treated as hanged application.

How that different applications handle that?

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

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


From serb at openjdk.org  Mon Dec  5 06:00:39 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 5 Dec 2022 06:00:39 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds
In-Reply-To: <TDgRUsXr7wPzPRMUMDePMKSKuNVLPdSqrHZU9VmHJmE=.961aceb1-b396-41c0-a986-0cfe49256fc6@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <fsj_jPApqfIlcqYr7d0YE3_EEJsxk2mlzt8awAnryIY=.eb3a88a5-ba92-4e11-a5cc-6068facf3164@github.com>
 <TDgRUsXr7wPzPRMUMDePMKSKuNVLPdSqrHZU9VmHJmE=.961aceb1-b396-41c0-a986-0cfe49256fc6@github.com>
Message-ID: <BGKfWQcI2x3D1plHBzxGKjtEbEDNccsgAjt8tmtygPw=.e2465d11-d5e9-40ec-8dae-8b4541135d80@github.com>

On Fri, 2 Dec 2022 18:13:43 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 61:
>> 
>>> 59:         final Frame wGreen = new Frame();
>>> 60:         wGreen.setBackground(Color.GREEN);
>>> 61:         wGreen.setUndecorated(true);
>> 
>> Why did you make that frame undecorated? I think the decoration was one of the reasons why the bug was reproduced.
>
> When testing on Win10, observed that for a decorated frame the title bar is retained in full screen mode unlike some of the other applications (eg. Chrome and IDE in full screen mode). 
> 
> When I checked the Javadocs for [setFullScreenWindow(Window w)](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/GraphicsDevice.html#setFullScreenWindow(java.awt.Window)), it states that - _"It is unspecified and platform-dependent how decorated windows operate in full-screen mode. For this reason, it is recommended to turn off the decorations in a Frame or Dialog object by using the setUndecorated method."_  
> 
> For the above reasons and to aid testing the pixel-color across full-screen window without having to account for different platform specific title bar sizes, the frame was set as undecorated.

You just uncover this bug https://bugs.openjdk.org/browse/JDK-7019055 referenced in the test, and one of the reasons why the specification is state what it states. SO it is better to not make the frame decorated but instead exclude it based on the current graphics device, OGL/D3D vs win32(or something like that)

>> test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 89:
>> 
>>> 87:             device.setFullScreenWindow(wRed);
>>> 88:             sleep();
>>> 89:             testWindowBounds(device.getFullScreenWindow().getBounds(), wRed);
>> 
>> You changed the code
>> from:
>>    comparing the bounds of the display mode and the bounds of the window
>> to:
>>    comparing the bounds of the window and the bounds of the window
>> I do not think it is the right thing to do.
>
> @mrserb I noticed that the difference in actual size vs display mode dimensions is because the actual size is scaled down by the device's current scale unlike display mode. This can be resolved by running the test at uiScale=1.

The usage of "device.getDefaultConfiguration().getBounds()' looks better.

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

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


From serb at openjdk.org  Mon Dec  5 06:03:04 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 5 Dec 2022 06:03:04 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <9sN-uV7MIpgo94mEXKQqQRd8x2lA0Wcf7E1KanVHiH0=.ef5073fc-5627-42e7-ba5d-2d7e9bc8c7d5@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <OaejD7ICWuDawcFR296LTgk4UuQGrNhvs5l9GgDZ-4k=.11297ea2-7a92-41cc-b96c-737281d052a9@github.com>
 <9sN-uV7MIpgo94mEXKQqQRd8x2lA0Wcf7E1KanVHiH0=.ef5073fc-5627-42e7-ba5d-2d7e9bc8c7d5@github.com>
Message-ID: <PrZbPL9utn0O_SmQQfjwbONqkghPD7Ffn2B4xGcoJ-A=.5f5fd27c-e711-4782-8daf-a2b78f91de5d@github.com>

On Fri, 2 Dec 2022 06:49:25 GMT, Tejesh R <tr at openjdk.org> wrote:

> The test only initializes JFileChooser instance, so calling FSV API directly means to explicitly mentioning FSV from test or from JFileChooser...?

No, just use that for debugging.

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

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


From tr at openjdk.org  Mon Dec  5 06:05:09 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 5 Dec 2022 06:05:09 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <PrZbPL9utn0O_SmQQfjwbONqkghPD7Ffn2B4xGcoJ-A=.5f5fd27c-e711-4782-8daf-a2b78f91de5d@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <OaejD7ICWuDawcFR296LTgk4UuQGrNhvs5l9GgDZ-4k=.11297ea2-7a92-41cc-b96c-737281d052a9@github.com>
 <9sN-uV7MIpgo94mEXKQqQRd8x2lA0Wcf7E1KanVHiH0=.ef5073fc-5627-42e7-ba5d-2d7e9bc8c7d5@github.com>
 <PrZbPL9utn0O_SmQQfjwbONqkghPD7Ffn2B4xGcoJ-A=.5f5fd27c-e711-4782-8daf-a2b78f91de5d@github.com>
Message-ID: <uesebheqquDvUwF_vfQq2EzObSiOd0bf3w4OwO9lyC8=.09d2fdd7-c906-4341-af43-7be34f5eaefc@github.com>

On Mon, 5 Dec 2022 05:59:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > The test only initializes JFileChooser instance, so calling FSV API directly means to explicitly mentioning FSV from test or from JFileChooser...?
> 
> No, just use that for debugging.

Ok, will try that, thank you for the pointers.

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

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


From serb at openjdk.org  Mon Dec  5 06:10:04 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 5 Dec 2022 06:10:04 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files
In-Reply-To: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
Message-ID: <WPo83xTHqjvUb3Gn342Yy6RUZUjWaFk5kLVV5oJkaoo=.9f954462-1def-40fd-a38a-c74533cee090@github.com>

On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
> 
> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
> 
> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
> 
> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
> 
> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

The client changes look fine.

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

Marked as reviewed by serb (Reviewer).

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


From kizune at openjdk.org  Mon Dec  5 07:28:56 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 5 Dec 2022 07:28:56 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus
In-Reply-To: <xJz52QqQG3jjK_eODsEXefcjWz7dfCLa29VepSCwYtE=.1757660e-6211-4917-9a41-e9d5908ccecc@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <e7ITSsOpcKtlC2bJNzIM3PFCUcoRZdfRi0mr1JxsgFE=.f37d4fe5-6a07-427c-b87f-b0ba50efcc6c@github.com>
 <VUwbo01Ivv81AevheTugl-_xosvdnzR7jhFhJtdViaE=.493aee6b-d32a-4258-8271-b25a281273d8@github.com>
 <xJz52QqQG3jjK_eODsEXefcjWz7dfCLa29VepSCwYtE=.1757660e-6211-4917-9a41-e9d5908ccecc@github.com>
Message-ID: <sl_FDZPPaLyWqv74FBu0aJwzSvRgIwrT_Lj8TF3AtpU=.1dddf19e-c2b6-48ba-b477-dc685bbc1efb@github.com>

On Mon, 5 Dec 2022 05:50:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> How that different applications handle that?

Chrome form editor hides cursor, Adobe Acrobat shows blinking cursor, Microsoft Office 2011 shows some custom cursor that appears to be grayed off or faded. Differently.

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

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


From mbaesken at openjdk.org  Mon Dec  5 09:58:28 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 5 Dec 2022 09:58:28 GMT
Subject: RFR: JDK-8298093: improve cleanup and error handling of
 awt_parseColorModel in awt_parseImage.c
Message-ID: <LJXA0GoYlzD_v4Gb9N0ytaim25_su2y8hAyWhx0hGKI=.5087cce4-07f1-446c-a389-d65334315f73@github.com>

The cleanup and error handling in function awt_parseColorModel in awt_parseImage.c could be improved.

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

Commit messages:
 - JDK-8298093

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

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


From jdv at openjdk.org  Mon Dec  5 10:55:03 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 5 Dec 2022 10:55:03 GMT
Subject: RFR: 8298027: Remove SCCS id's from awt jtreg tests
Message-ID: <lWFPbg2l8BHwEf7q6p3nt7lzHdBAf1RJ23za5VNij0I=.e1fba7b1-5b67-4c22-a57d-7949cd487bfe@github.com>

Noticed SCCS jtreg id's in 2 open awt tests. After jtreg 7.1 update, jtreg doesn't parse SCCS id's and it causes the tests with SCCS id's to fail.

As of now these 2 tests are ignored, but it is good to remove these SCCS id's.
If we don't need these 2 tests since they are ignored, then i will update the PR base on the review comments.

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

Commit messages:
 - 8298027: Remove SCCS id's from awt jtreg tests

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

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


From tr at openjdk.org  Mon Dec  5 11:42:02 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 5 Dec 2022 11:42:02 GMT
Subject: RFR: 8296198: JFileChooser throws InternalError
 java.lang.InternalError with Windows shortcuts
Message-ID: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>

When `JFileChooser` uses custom `FileSystemView`, traversing to link/shortcut to a folder throw `InternalError java.lang.InternalError ` in Windows. The issue found out to be in BasicFileChooserUI class which was unable to resolve the link path during directory setting. The `UsesShellFolder` check expects the FileSystemView to be of WindowsFileSystemView, which fails when custom FileSystemView is used.
The fix includes resolving the link folder when custom File System View is used and has manual test. (Fix is test in CI system and no regression caused).

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

Commit messages:
 - New Line
 - Fix

Changes: https://git.openjdk.org/jdk/pull/11510/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11510&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296198
  Stats: 256 lines in 2 files changed: 245 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11510.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11510/head:pull/11510

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


From ihse at openjdk.org  Mon Dec  5 13:28:12 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Dec 2022 13:28:12 GMT
Subject: RFR: 8298006: Build failure by maybe-uninitialized error on Linux
 s390x GCC8
In-Reply-To: <4v4hi71PiXE_VmYAZn-7eUlnd3SbjvwTueB8zAdrcxc=.fdc7ccf5-ccbf-478e-9add-ff892b2ca2d1@github.com>
References: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
 <KYb8vUnHwihJUgekC3c9drcncpys_PbwtY4OX2eM0Jo=.a3e6776f-c06f-4885-a9f7-48747383bfc0@github.com>
 <4v4hi71PiXE_VmYAZn-7eUlnd3SbjvwTueB8zAdrcxc=.fdc7ccf5-ccbf-478e-9add-ff892b2ca2d1@github.com>
Message-ID: <FLjno0ZztXSQMPPXtkNQbKKLPPsGV5sGCGi4B2KMeFk=.fd552851-c710-40b8-80ae-1040c8d52615@github.com>

On Sat, 3 Dec 2022 08:11:25 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> Just because you get a compilation error does not mean the issue belongs with the build group. This is just about the source code in AWT, so the client-libs team will handle this review.
>> 
>> That being said, I did have a look at the code and I think they might be skeptical. There seems to be no inherent s390x change here, rather the compiler you are using seem to be a bit trigger-happy on this analysis. 
>> 
>> Also, both gcc 6 and 8 are incredibly old. Gcc 6 is from 2016, and gcc 8 is from  2018. I would recommend you get a newer gcc version instead, or possibly build with `--disable-warnings-as-errors`.
>
> Thanks @magicus .
> `--disable-warnings-as-errors` option worked fine as expected

@takiguc Are you happy with that solution, so you can close the issue and this PR?

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

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


From alanb at openjdk.org  Mon Dec  5 13:40:48 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Dec 2022 13:40:48 GMT
Subject: RFR: 8298027: Remove SCCS id's from awt jtreg tests
In-Reply-To: <lWFPbg2l8BHwEf7q6p3nt7lzHdBAf1RJ23za5VNij0I=.e1fba7b1-5b67-4c22-a57d-7949cd487bfe@github.com>
References: <lWFPbg2l8BHwEf7q6p3nt7lzHdBAf1RJ23za5VNij0I=.e1fba7b1-5b67-4c22-a57d-7949cd487bfe@github.com>
Message-ID: <iwrWXKyNn8IQuZa1kA55o2TEMXSkku-MLxF10EYx8IU=.bec8c00d-f069-4720-93c1-a758f979b2de@github.com>

On Mon, 5 Dec 2022 10:47:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Noticed SCCS jtreg id's in 2 open awt tests. After jtreg 7.1 update, jtreg doesn't parse SCCS id's and it causes the tests with SCCS id's to fail.
> 
> As of now these 2 tests are ignored, but it is good to remove these SCCS id's.
> If we don't need these 2 tests since they are ignored, then i will update the PR base on the review comments.

test/jdk/java/awt/font/TextLayout/TestOldHangul.java line 27:

> 25:  * @summary Verify Old Hangul display
> 26:  * @bug 6886358
> 27:  * @ignore Requires a special font installed.

The removal of the SCCS ids looks fine but the change made me wonder how long they have been @ignore-ed. Are these really manual tests that need a special font config?

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

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


From aivanov at openjdk.org  Mon Dec  5 15:35:05 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 5 Dec 2022 15:35:05 GMT
Subject: RFR: 8298027: Remove SCCS id's from awt jtreg tests
In-Reply-To: <lWFPbg2l8BHwEf7q6p3nt7lzHdBAf1RJ23za5VNij0I=.e1fba7b1-5b67-4c22-a57d-7949cd487bfe@github.com>
References: <lWFPbg2l8BHwEf7q6p3nt7lzHdBAf1RJ23za5VNij0I=.e1fba7b1-5b67-4c22-a57d-7949cd487bfe@github.com>
Message-ID: <Mmz_NaBG2Rsn6YFJAfWcKAPod3czE8VvRnRXAOAxwk0=.31f0c1a0-6400-467d-8d7e-86c4ca5b5435@github.com>

On Mon, 5 Dec 2022 10:47:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Noticed SCCS jtreg id's in 2 open awt tests. After jtreg 7.1 update, jtreg doesn't parse SCCS id's and it causes the tests with SCCS id's to fail.
> 
> As of now these 2 tests are ignored, but it is good to remove these SCCS id's.
> If we don't need these 2 tests since they are ignored, then i will update the PR base on the review comments.

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.org  Mon Dec  5 15:38:13 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 5 Dec 2022 15:38:13 GMT
Subject: RFR: 8298027: Remove SCCS id's from awt jtreg tests
In-Reply-To: <iwrWXKyNn8IQuZa1kA55o2TEMXSkku-MLxF10EYx8IU=.bec8c00d-f069-4720-93c1-a758f979b2de@github.com>
References: <lWFPbg2l8BHwEf7q6p3nt7lzHdBAf1RJ23za5VNij0I=.e1fba7b1-5b67-4c22-a57d-7949cd487bfe@github.com>
 <iwrWXKyNn8IQuZa1kA55o2TEMXSkku-MLxF10EYx8IU=.bec8c00d-f069-4720-93c1-a758f979b2de@github.com>
Message-ID: <7SupTS9_WIf1o6mlleIDJ08b-FjOLKgDXVfqTXXimm4=.990887d6-5409-42be-a5ca-1d47a9da0afe@github.com>

On Mon, 5 Dec 2022 13:36:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The removal of the SCCS ids looks fine but the change made me wonder how long they have been @ignore-ed. Are these really manual tests that need a special font config?

I agree. Both tests have been `@ignored` for at least 12 years.

The required characters could be available in fonts installed with an OS. I think we should look at these tests and try to enable them. The links to the font files could be dead by now, which makes it harder to reproduce the original issue as well as ensuring the test remains useful.

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

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


From chen.j.patrick at gmail.com  Mon Dec  5 16:10:26 2022
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Mon, 5 Dec 2022 17:10:26 +0100
Subject: RFR: 8298027: Remove SCCS id's from awt jtreg tests
In-Reply-To: <7SupTS9_WIf1o6mlleIDJ08b-FjOLKgDXVfqTXXimm4=.990887d6-5409-42be-a5ca-1d47a9da0afe@github.com>
References: <lWFPbg2l8BHwEf7q6p3nt7lzHdBAf1RJ23za5VNij0I=.e1fba7b1-5b67-4c22-a57d-7949cd487bfe@github.com>
 <iwrWXKyNn8IQuZa1kA55o2TEMXSkku-MLxF10EYx8IU=.bec8c00d-f069-4720-93c1-a758f979b2de@github.com>
 <7SupTS9_WIf1o6mlleIDJ08b-FjOLKgDXVfqTXXimm4=.990887d6-5409-42be-a5ca-1d47a9da0afe@github.com>
Message-ID: <CANmuJ8sayBQ26FFZ2md7PN=4h_y_bYcNizkFQqU9Zj2YZRUcSQ@mail.gmail.com>

the last 12 years ?

Le lun. 5 d?c. 2022 ? 16:39, Alexey Ivanov <aivanov at openjdk.org> a ?crit :

> On Mon, 5 Dec 2022 13:36:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>
> > The removal of the SCCS ids looks fine but the change made me wonder how
> long they have been @ignore-ed. Are these really manual tests that need a
> special font config?
>
> I agree. Both tests have been `@ignored` for at least 12 years.
>
> The required characters could be available in fonts installed with an OS.
> I think we should look at these tests and try to enable them. The links to
> the font files could be dead by now, which makes it harder to reproduce the
> original issue as well as ensuring the test remains useful.
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/11509
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221205/e27817d8/attachment.htm>

From itakiguchi at openjdk.org  Mon Dec  5 16:13:01 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Mon, 5 Dec 2022 16:13:01 GMT
Subject: RFR: 8298006: Build failure by maybe-uninitialized error on Linux
 s390x GCC8
In-Reply-To: <FLjno0ZztXSQMPPXtkNQbKKLPPsGV5sGCGi4B2KMeFk=.fd552851-c710-40b8-80ae-1040c8d52615@github.com>
References: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
 <KYb8vUnHwihJUgekC3c9drcncpys_PbwtY4OX2eM0Jo=.a3e6776f-c06f-4885-a9f7-48747383bfc0@github.com>
 <4v4hi71PiXE_VmYAZn-7eUlnd3SbjvwTueB8zAdrcxc=.fdc7ccf5-ccbf-478e-9add-ff892b2ca2d1@github.com>
 <FLjno0ZztXSQMPPXtkNQbKKLPPsGV5sGCGi4B2KMeFk=.fd552851-c710-40b8-80ae-1040c8d52615@github.com>
Message-ID: <dDcNje9Hv6WsDao8S8kusEo6Mq8ZaIHgIHb-afY8PYk=.ab2c3047-0552-419c-9b3d-e64b4449cc28@github.com>

On Mon, 5 Dec 2022 13:25:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Thanks @magicus .
>> `--disable-warnings-as-errors` option worked fine as expected
>
> @takiguc Are you happy with that solution, so you can close the issue and this PR?

@magicus 
I don't think `--disable-warnings-as-errors` is the default, so I'd like to confirm if this kind of change to reduce errors/warnings is acceptable or not.

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

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


From aivanov at openjdk.org  Mon Dec  5 16:45:07 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 5 Dec 2022 16:45:07 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus [v2]
In-Reply-To: <BYRO2l4rVgUl1fIXrLCiqdZPeQHyDJR6WQOgg6a3NDU=.be0a7781-513c-4396-b5d7-0bd5d45bb182@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
 <kjwZwCz7Xk6aZUii34xNkE4MuTHFG_rAiTOIhF46A08=.dc303ef2-2250-46b5-b5b2-15a2f5190c64@github.com>
 <BYRO2l4rVgUl1fIXrLCiqdZPeQHyDJR6WQOgg6a3NDU=.be0a7781-513c-4396-b5d7-0bd5d45bb182@github.com>
Message-ID: <A6Pq2dPH3tIFgbAUW4SR0okCktA55UPjO29RdLgvAQY=.436fab72-39cd-462e-95ce-0f8f09a3d869@github.com>

On Sun, 4 Dec 2022 23:27:42 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> > At least on Windows, non-editable text controls have a blinking caret.
> 
> Well, Windows is an important platform but it is not the only one we care about.  
> On Ubuntu 22 the editable text field has the blinking cursor and non-editable has a non-blinking?

How do native apps on macOS handle the situation? Especially those developed by Apple?

If two platforms show blinking caret, then the caret should remain blinking by default.

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

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


From ihse at openjdk.org  Mon Dec  5 16:49:10 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Dec 2022 16:49:10 GMT
Subject: RFR: 8298006: Build failure by maybe-uninitialized error on Linux
 s390x GCC8
In-Reply-To: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
References: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
Message-ID: <Wpl1TTm1uITo9DBgx9_TLfcNwaXd68vTwbiyiO5_dBc=.105063fa-2393-4843-bab8-c62f082e9585@github.com>

On Fri, 2 Dec 2022 08:41:18 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> I changed GCC toolchain from GCC6 to GCC8 on SLES12SP5 Linux s390x.
> I could see following errors:
> 
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c: In function 'allocateRasterArray':
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:2944:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> ?????????????????????????????(((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])
> ?????????????????????????????????????????????????????????????????????~~~~^~~
> 
> 
> According to error messages,
> roff and loff may not be initialized.

Okay. I'll leave that over to the client team.

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

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


From duke at openjdk.org  Mon Dec  5 17:03:22 2022
From: duke at openjdk.org (Ravi Gupta)
Date: Mon, 5 Dec 2022 17:03:22 GMT
Subject: RFR: 8297489: Modify TextAreaTextEventTest.java as to verify the
 content change of TextComponent sends TextEvent [v8]
In-Reply-To: <LJHqMbRa4ppaEgOciQ_y0KB_Su-3xpg0ga7SkMhmEDc=.627d058a-f1e2-4009-8e7a-471ce4dc9941@github.com>
References: <H7m1aUX465moo8YgQxlbd2dhpY4oOXP5b1pEYGY-iSA=.4e625467-97db-473e-af11-f26c4015d284@github.com>
 <LJHqMbRa4ppaEgOciQ_y0KB_Su-3xpg0ga7SkMhmEDc=.627d058a-f1e2-4009-8e7a-471ce4dc9941@github.com>
Message-ID: <MBAKo83u4-pmd2qALbL37aieB8rsJ88ZLzUkkW3u4j8=.3478cec6-ce66-4503-bb0f-165029a8f6b4@github.com>

On Thu, 1 Dec 2022 17:27:52 GMT, Ravi Gupta <duke at openjdk.org> wrote:

>> Modify TextAreaTextEventTest.java as to verify the content changes of a both TextComponent(TextField,TextArea) for the following assertions.
>> 
>> a. TextListener get invoked when the content of a TextField gets changed.
>> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed.
>> 
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixes

Any volunteers for a sponsor?

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

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


From duke at openjdk.org  Mon Dec  5 17:44:15 2022
From: duke at openjdk.org (Rajat Mahajan)
Date: Mon, 5 Dec 2022 17:44:15 GMT
Subject: RFR: 8297450: ScaledTextFieldBorderTest.java fails when run with
 -show parameter
In-Reply-To: <DFCfeHM00dvRfICYgSRnY1t0zYN9UJHsCOyG6rKU4xU=.820d06c3-2815-4e8b-a3a9-e6ac73ddaea5@github.com>
References: <DFCfeHM00dvRfICYgSRnY1t0zYN9UJHsCOyG6rKU4xU=.820d06c3-2815-4e8b-a3a9-e6ac73ddaea5@github.com>
Message-ID: <KwJCdqok80oOLk64kd64GH0IYnaL2U1w7cifHGkwu_A=.d3988560-71b5-4842-a989-ce03a57b3dbc@github.com>

On Sat, 3 Dec 2022 22:11:47 GMT, Rajat Mahajan <duke at openjdk.org> wrote:

> Added createVerticalStrut in between textfields to fix this issue.

The test is failing because there was no gap between the Textfields.
 I fixed it by adding Vertical Struts in between Textfields.

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

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


From prr at openjdk.org  Mon Dec  5 17:57:10 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 5 Dec 2022 17:57:10 GMT
Subject: Integrated: 8273357: SecurityManager deprecation warning from
 java/awt/regtesthelpers/Util.java
In-Reply-To: <BQDfdm36vDBLkBVERvrlpEOPSPWj7tPPkxEOtABojC4=.e139e472-d053-4cba-9d2d-9cdaeb361fbc@github.com>
References: <BQDfdm36vDBLkBVERvrlpEOPSPWj7tPPkxEOtABojC4=.e139e472-d053-4cba-9d2d-9cdaeb361fbc@github.com>
Message-ID: <RCA9_lXZoH6h4Ns_hei0B9ny81KATFUpwfobXyDkPrY=.a26b5520-02bf-4b43-87e1-2034c2e9c0ee@github.com>

On Fri, 2 Dec 2022 23:07:45 GMT, Phil Race <prr at openjdk.org> wrote:

> The compilation of a number of tests that use regtesthelpers/Util.java are getting a warning about
> the deprecation-for-removal of the SecurityManager.
> This suppresses that warning.

This pull request has now been integrated.

Changeset: 601264d9
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/601264d97d5cb1a8feb4aebadcb58bf2364916b4
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8273357: SecurityManager deprecation warning from java/awt/regtesthelpers/Util.java

Reviewed-by: kizune, aivanov

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

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


From avu at openjdk.org  Mon Dec  5 18:23:20 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Mon, 5 Dec 2022 18:23:20 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
Message-ID: <ptoU_UWH6A6u9Mr3QMKDz_yU5-z-eEkpq9RpuBWwij4=.9675dd7f-46e8-48de-b297-b4ef52a54999@github.com>

On Thu, 1 Dec 2022 19:38:44 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix pointer to jlong conversion on x86

There are several options to resolve this problem without failing the tests:
- you can provide a diagnostic message, so passing for configurations missing necessary fonts won?t be silent
- create your own font with the necessary properties and submit it within the fix

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

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


From prr at openjdk.org  Mon Dec  5 18:24:22 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 5 Dec 2022 18:24:22 GMT
Subject: RFR: 8298006: Build failure by maybe-uninitialized error on Linux
 s390x GCC8
In-Reply-To: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
References: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
Message-ID: <G71lep3GeJwy4OMGWKrE7_kxeitheMbsrv0AdMNzJrc=.a5a8d15a-b2da-4999-80a9-6b8817cdac07@github.com>

On Fri, 2 Dec 2022 08:41:18 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c: In function 'allocateRasterArray':
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:2944:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> ?????????????????????????????(((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])

That's weird. allocateRasterArray is at lines 2360-2575 .. so why are you seeing it at line 2944 ????

src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c line 2919:

> 2917:     memset(roff, 0, sizeof(roff));
> 2918: #endif
> 2919: 

Of the various ways this could be fixed this is one of my least preferred.
Either 
1) Disable the warning for this file for this toolchain + platform in the makefile, or
2) Zero it out for all platforms. There's no platform-specific logic here.
Unless you think there's a compiler bug and these are all false positive in which case (1) is definitely the way to go.

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

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


From azvegint at openjdk.org  Mon Dec  5 18:30:04 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 5 Dec 2022 18:30:04 GMT
Subject: RFR: 8193547: Regression automated test
 '/open/test/jdk/java/awt/Toolkit/DesktopProperties/rfe4758438.java' fails
In-Reply-To: <gf-HxIx7BCd7Im-4QlW4RtT3mKJcUVQHI-sDHK5rrYs=.e28b0d52-9e3c-4402-8964-1351ce88375b@github.com>
References: <gf-HxIx7BCd7Im-4QlW4RtT3mKJcUVQHI-sDHK5rrYs=.e28b0d52-9e3c-4402-8964-1351ce88375b@github.com>
Message-ID: <AnZU2-mw19ApLVtRudgt1CvLzouOUPfClZPoTjna-ls=.5d0ecf12-a521-49a2-b06f-12f40b355773@github.com>

On Mon, 14 Nov 2022 00:03:51 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test has multiple issues:
> 
> * Test actually does nothing and passes as it is right now, but tests nothing
> * `pgrep gnome-session` may return multiple PIDs -> picking up only first one 
> * looks like jtreg does not pass GNOME_DESKTOP_SESSION_ID variable(it is deprecated, BTW), so used `XDG_CURRENT_DESKTOP` instead
> * removed leftovers from Solaris support
> * `org.gnome.settings-daemon.peripherals.mouse` is [deprecated](https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/master/data/org.gnome.settings-daemon.peripherals.gschema.xml.in#L46) and does not work on latest systems  <br> but newer `org.gnome.desktop.peripherals.mouse` works as expected<br>So the test modified to try new one and to check deprecated as a fallback
> 
> CI testing looks good.

Ping?

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

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


From kizune at openjdk.org  Mon Dec  5 18:41:08 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 5 Dec 2022 18:41:08 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus [v2]
In-Reply-To: <A6Pq2dPH3tIFgbAUW4SR0okCktA55UPjO29RdLgvAQY=.436fab72-39cd-462e-95ce-0f8f09a3d869@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
 <kjwZwCz7Xk6aZUii34xNkE4MuTHFG_rAiTOIhF46A08=.dc303ef2-2250-46b5-b5b2-15a2f5190c64@github.com>
 <BYRO2l4rVgUl1fIXrLCiqdZPeQHyDJR6WQOgg6a3NDU=.be0a7781-513c-4396-b5d7-0bd5d45bb182@github.com>
 <A6Pq2dPH3tIFgbAUW4SR0okCktA55UPjO29RdLgvAQY=.436fab72-39cd-462e-95ce-0f8f09a3d869@github.com>
Message-ID: <6aEsDl9hjTFpJ1wFMxqTtoAspMjuopuEawGqZe-oMio=.0a27c15e-6c21-4448-a61c-ce1820b18129@github.com>

On Mon, 5 Dec 2022 16:42:39 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> How do native apps on macOS handle the situation? Especially those developed by Apple?

It is quite hard to find a relevant case but so far it seems that it is all over the place on Mac OS - in majority of the apps where it allows selection in non-editable text components with keyboard it does not show the caret at all. I found only one place that shows caret in non-editable text field - in the project settings of XCode app - and the caret is blinking but i can not say if it is a normal behaviour or if it was somehow customized. My point is that if editable text component can not be visually distinguished from non-editable one it is also not helpful. Like on that XCode page - there are a set of text fields some of them are editable and some of them are not and the only way to distinguish between them is to attempt to type or delete text in them. Honestly so far Linux/Gnome approach just looks more coherent and logical.

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

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


From duke at openjdk.org  Mon Dec  5 18:45:37 2022
From: duke at openjdk.org (Ravi Gupta)
Date: Mon, 5 Dec 2022 18:45:37 GMT
Subject: Integrated: 8297489: Modify TextAreaTextEventTest.java as to verify
 the content change of TextComponent sends TextEvent
In-Reply-To: <H7m1aUX465moo8YgQxlbd2dhpY4oOXP5b1pEYGY-iSA=.4e625467-97db-473e-af11-f26c4015d284@github.com>
References: <H7m1aUX465moo8YgQxlbd2dhpY4oOXP5b1pEYGY-iSA=.4e625467-97db-473e-af11-f26c4015d284@github.com>
Message-ID: <L8JY-nMF5DTvgVJUPDNIwBatfc0cSON4zL_zPV2b-0M=.f4c16ab0-46a9-43d7-87d3-faead6b3598a@github.com>

On Wed, 23 Nov 2022 15:15:32 GMT, Ravi Gupta <duke at openjdk.org> wrote:

> Modify TextAreaTextEventTest.java as to verify the content changes of a both TextComponent(TextField,TextArea) for the following assertions.
> 
> a. TextListener get invoked when the content of a TextField gets changed.
> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed.
> 
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

This pull request has now been integrated.

Changeset: 7d20a60a
Author:    ravi.ra.gupta <ravi.ra.gupta at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7d20a60a983e459ea1c4e843fbde70fb796c6249
Stats:     302 lines in 2 files changed: 161 ins; 141 del; 0 mod

8297489: Modify TextAreaTextEventTest.java as to verify the content change of TextComponent sends TextEvent

Reviewed-by: honkar, aivanov

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

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


From kizune at openjdk.org  Mon Dec  5 18:58:42 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 5 Dec 2022 18:58:42 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus [v2]
In-Reply-To: <wqFE72k3aqBWCwIoGYouYKkoOK3jyEbfE0ycX9slbt4=.3bc3085f-03ef-482c-bf6a-f2ff5e524ed3@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
 <UtmmDvuZenm-kNcGBUOCK792hLEI_NXsWg1yu5zSHBo=.7aa4dd3a-427a-4729-9e68-40c0a173465f@github.com>
 <wqFE72k3aqBWCwIoGYouYKkoOK3jyEbfE0ycX9slbt4=.3bc3085f-03ef-482c-bf6a-f2ff5e524ed3@github.com>
Message-ID: <hegrGQUTzh1FINjDrdr2ytpJ71leUPqjNVmV7urnFwc=.ece8d79a-98ce-4e48-bfab-b46daf7c39e1@github.com>

On Mon, 5 Dec 2022 05:29:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The test is problemlisted for windows so not sure if the observation "passes on Windows" is correct..

When it failed on Linux on pre-submit task i ran it locally and deproblemlisted it on Windows. I haven't pushed the problemlist change but i found that on Windows it is unstable because of the way it was taking screenshots and it was passing because it compared the two screenshots that are not supposed to be the same and it passes because they are not but that is the false positive because the difference is not in the relevant part of the screenshot but in the border overlapped by the popup. Except this false positive is not a false positive because on Windows these components should be the same for the logic tested is only valid on Linux - selection of the text in the focused window does not clear selection in non-focused one on Windows or Mac. So in the similar fashion test "accidentally" passes on Mac but for different reason - the screenshots were different because on Mac the selection color in non-focused window is different so screenshot does not match while functionally select
 ion is not cleared so it is another "false but correctly positive".

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

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


From aivanov at openjdk.org  Mon Dec  5 19:14:59 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 5 Dec 2022 19:14:59 GMT
Subject: RFR: JDK-8296661 : Fix typo
In-Reply-To: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
Message-ID: <zbvDGc4EHbOQfvq8srOEeTwlyfraCuDbRYN0jXDo7RE=.dfa036b5-bebe-4d7c-af1a-ab8328184328@github.com>

On Fri, 4 Nov 2022 01:56:05 GMT, ScientificWare <duke at openjdk.org> wrote:

> This is referenced in Java Bug Database as
> - [JDK-8296661 : Fix typo](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8296661)
> 
> This is tracked in JBS as 
> - [JDK-8296661 : Fix typo](https://bugs.openjdk.java.net/browse/JDK-8296661)
> 
> I suspect a typo in the documentation comments.
> 
> Designed from : [ScientificWare JDK-8293776 : Fix typo](https://github.com/scientificware/jdk/issues/18)

Looks good to me.

In the description above: ??invoked one per property??, it shoud be ?once?.

I think there's room for improvement. However, this is an internal-only class.

You have to update the subject of the PR to match the JBS title which was edited by someone to be more specific.

src/java.desktop/share/classes/javax/swing/text/html/CSSParser.java line 53:

> 51:  * <p>
> 52:  * This will preserve case. If the callback wishes to treat certain portions
> 53:  * case insensitively (such as selectors), it should use toLowerCase, or

Should this be ?case-insensitively? with the hyphen?

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

Marked as reviewed by aivanov (Reviewer).

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


From aivanov at openjdk.org  Mon Dec  5 19:17:53 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 5 Dec 2022 19:17:53 GMT
Subject: RFR: 4668290: unclear spec for Polygon.bounds field [v2]
In-Reply-To: <tGt8IEe66tdrP8cHbwmQkTup1WB68ZuobVlLXPdmB_A=.205ea7a4-07dd-4fce-a33d-ccc9920d6cd8@github.com>
References: <jjzwWZJPW8Essivj9svlhO-LScPQV_TlMoC0GGOVgMY=.b5d5ced5-77af-4ce9-8214-10c1cc0392cb@github.com>
 <tGt8IEe66tdrP8cHbwmQkTup1WB68ZuobVlLXPdmB_A=.205ea7a4-07dd-4fce-a33d-ccc9920d6cd8@github.com>
Message-ID: <e4SqSFaLD9bRzsVtdQJMYvdbG0YtfLsDqqGPIzh9bPM=.4bdb5218-382e-4264-ad9d-5994fbc4b31b@github.com>

On Fri, 30 Sep 2022 21:30:25 GMT, SWinxy <duke at openjdk.org> wrote:

>> New documentation replaces the `This value can be null.`:
>> 
>> When created, {@link #invalidate() invalidated}, or {@link #reset() reset},
>> this becomes {@code null}. To get out of the null state,
>> {@link #getBounds()} called with {@link #npoints} being greater than
>> {@code 0} will transfer into a non-null {@link Rectangle}.
>> 
>> 
>> I think I've got the reason for why it can be `null` correct, but you never know.
>> 
>> In javax.swing.text.html.Map, I've replaced setting the field to null with the equivalent #invalidate(). This may mean we can make the field private in the future.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reword change based off of Phil's suggestion
>   
>   Thanks, Phil.

src/java.desktop/share/classes/java/awt/Polygon.java line 108:

> 106:      * <p>
> 107:      * The value of this field is updated by the implementation which
> 108:      * may set it to null and will reevaluate it as needed. Application

I'd use `{@code null}` syntax.

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

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


From honkar at openjdk.org  Mon Dec  5 19:50:13 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 5 Dec 2022 19:50:13 GMT
Subject: RFR: 8297450: ScaledTextFieldBorderTest.java fails when run with
 -show parameter
In-Reply-To: <DFCfeHM00dvRfICYgSRnY1t0zYN9UJHsCOyG6rKU4xU=.820d06c3-2815-4e8b-a3a9-e6ac73ddaea5@github.com>
References: <DFCfeHM00dvRfICYgSRnY1t0zYN9UJHsCOyG6rKU4xU=.820d06c3-2815-4e8b-a3a9-e6ac73ddaea5@github.com>
Message-ID: <i1N1Fg7s4hFH8LVTB2J3PF4-C6h1QiXzva4fi2hCC90=.a09b6815-b376-4893-99d5-3a1ee347885c@github.com>

On Sat, 3 Dec 2022 22:11:47 GMT, Rajat Mahajan <duke at openjdk.org> wrote:

> The test is failing because there was no gap between the Textfields.
> I fixed it by adding Vertical Struts in between Textfields.

Marked as reviewed by honkar (Committer).

Before the fix the test failed if both, showFrame and saveImages were hardcoded to true. With the fix test works fine.

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

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


From prr at openjdk.org  Mon Dec  5 19:50:14 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 5 Dec 2022 19:50:14 GMT
Subject: RFR: 8298006: Build failure by maybe-uninitialized error on Linux
 s390x GCC8
In-Reply-To: <G71lep3GeJwy4OMGWKrE7_kxeitheMbsrv0AdMNzJrc=.a5a8d15a-b2da-4999-80a9-6b8817cdac07@github.com>
References: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
 <G71lep3GeJwy4OMGWKrE7_kxeitheMbsrv0AdMNzJrc=.a5a8d15a-b2da-4999-80a9-6b8817cdac07@github.com>
Message-ID: <98CgDgBaduoqwc5ngRyAqB_OrwuAFZvaCKH_eJsUMGE=.bb97a8b9-8b60-4b54-b416-0aa04cce7fe9@github.com>

On Mon, 5 Dec 2022 18:19:55 GMT, Phil Race <prr at openjdk.org> wrote:

>> I changed GCC toolchain from GCC6 to GCC8 on SLES12SP5 Linux s390x.
>> I could see following errors:
>> 
>> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c: In function 'allocateRasterArray':
>> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:2944:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> ?????????????????????????????(((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])
>> ?????????????????????????????????????????????????????????????????????~~~~^~~
>> 
>> 
>> According to error messages,
>> roff and loff may not be initialized.
>
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c line 2919:
> 
>> 2917:     memset(roff, 0, sizeof(roff));
>> 2918: #endif
>> 2919: 
> 
> Of the various ways this could be fixed this is one of my least preferred.
> Either 
> 1) Disable the warning for this file for this toolchain + platform in the makefile, or
> 2) Zero it out for all platforms. There's no platform-specific logic here.
> Unless you think there's a compiler bug and these are all false positive in which case (1) is definitely the way to go.

I think it should be zeroed for all platforms. Its not easy to tell that these are all initialized before use.

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

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


From aivanov at openjdk.org  Mon Dec  5 19:51:18 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 5 Dec 2022 19:51:18 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus [v2]
In-Reply-To: <6aEsDl9hjTFpJ1wFMxqTtoAspMjuopuEawGqZe-oMio=.0a27c15e-6c21-4448-a61c-ce1820b18129@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
 <kjwZwCz7Xk6aZUii34xNkE4MuTHFG_rAiTOIhF46A08=.dc303ef2-2250-46b5-b5b2-15a2f5190c64@github.com>
 <BYRO2l4rVgUl1fIXrLCiqdZPeQHyDJR6WQOgg6a3NDU=.be0a7781-513c-4396-b5d7-0bd5d45bb182@github.com>
 <A6Pq2dPH3tIFgbAUW4SR0okCktA55UPjO29RdLgvAQY=.436fab72-39cd-462e-95ce-0f8f09a3d869@github.com>
 <6aEsDl9hjTFpJ1wFMxqTtoAspMjuopuEawGqZe-oMio=.0a27c15e-6c21-4448-a61c-ce1820b18129@github.com>
Message-ID: <NROecfDvKN8bKn49Hisi2Cw1uWsc7cBdumgDLPCfeUc=.960f3ee9-cf77-4ac7-b659-a06383da89f2@github.com>

On Mon, 5 Dec 2022 18:38:29 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> My point is that if editable text component can not be visually distinguished from non-editable one it is also not helpful.

Agreed.

Does the background colour* of non-editable text component change in Swing? If not, then non-blinking caret is the way to go so that it contrasts with the editable one.

* On Windows, such controls are usually displayed with darker background, like a static control which corresponds to `JLabel`. On macOS, the Info page displays data in non-editable text controls which match the background of the window.

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

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


From achung at openjdk.org  Mon Dec  5 19:52:00 2022
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 5 Dec 2022 19:52:00 GMT
Subject: RFR: 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java
 fails with "No MouseReleased event on label!" [v3]
In-Reply-To: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
References: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
Message-ID: <wk0pRR6VBbTKg7aen8zWLYa9KWMEitnkmSkAuoctO9s=.b7ffd66d-a3b3-4fe5-8785-6eb4ab009d84@github.com>

> Test was run on mac, windows, linux 50 times and passed after change
> Before fix, test fails about once every 50 runs on linux and windows platforms

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

 - Merge branch 'master' of https://github.com/openjdk/jdk into 8297296
 - fixed imports, changed robot autodelay and added delay after creating gui
 - changed robot autodelay to 250

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11425/files
  - new: https://git.openjdk.org/jdk/pull/11425/files/0e69811d..8f0e0e71

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

  Stats: 45484 lines in 1002 files changed: 17794 ins; 21203 del; 6487 mod
  Patch: https://git.openjdk.org/jdk/pull/11425.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11425/head:pull/11425

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


From kizune at openjdk.org  Mon Dec  5 20:38:16 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 5 Dec 2022 20:38:16 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus [v2]
In-Reply-To: <NROecfDvKN8bKn49Hisi2Cw1uWsc7cBdumgDLPCfeUc=.960f3ee9-cf77-4ac7-b659-a06383da89f2@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
 <kjwZwCz7Xk6aZUii34xNkE4MuTHFG_rAiTOIhF46A08=.dc303ef2-2250-46b5-b5b2-15a2f5190c64@github.com>
 <BYRO2l4rVgUl1fIXrLCiqdZPeQHyDJR6WQOgg6a3NDU=.be0a7781-513c-4396-b5d7-0bd5d45bb182@github.com>
 <A6Pq2dPH3tIFgbAUW4SR0okCktA55UPjO29RdLgvAQY=.436fab72-39cd-462e-95ce-0f8f09a3d869@github.com>
 <6aEsDl9hjTFpJ1wFMxqTtoAspMjuopuEawGqZe-oMio=.0a27c15e-6c21-4448-a61c-ce1820b18129@github.com>
 <NROecfDvKN8bKn49Hisi2Cw1uWsc7cBdumgDLPCfeUc=.960f3ee9-cf77-4ac7-b659-a06383da89f2@github.com>
Message-ID: <HyFErJAlw6BQCj9IX1ouh9SwsX9ULBSEJvvQVzC-tbc=.9d0393ba-a7a6-404f-9964-6758c9aaf983@github.com>

On Mon, 5 Dec 2022 19:44:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Does the background colour* of non-editable text component change in Swing?

It does not.

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

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


From honkar at openjdk.org  Mon Dec  5 20:44:02 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 5 Dec 2022 20:44:02 GMT
Subject: RFR: 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java
 fails with "No MouseReleased event on label!" [v3]
In-Reply-To: <wk0pRR6VBbTKg7aen8zWLYa9KWMEitnkmSkAuoctO9s=.b7ffd66d-a3b3-4fe5-8785-6eb4ab009d84@github.com>
References: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
 <wk0pRR6VBbTKg7aen8zWLYa9KWMEitnkmSkAuoctO9s=.b7ffd66d-a3b3-4fe5-8785-6eb4ab009d84@github.com>
Message-ID: <hwgbDBLtlxsEv-kUHKJlvNyq4B79wYLvtWKpNGahci4=.6c948283-4991-461a-9be9-f95b9b0c3066@github.com>

On Mon, 5 Dec 2022 19:52:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Test was run on mac, windows, linux 50 times and passed after change
>> Before fix, test fails about once every 50 runs on linux and windows platforms
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8297296
>  - fixed imports, changed robot autodelay and added delay after creating gui
>  - changed robot autodelay to 250

@alisenchung Was this an intermittent issue? If so it is better to run the entire test folder multiple times to catch any intermittent issue.

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

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


From prr at openjdk.org  Mon Dec  5 21:07:29 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 5 Dec 2022 21:07:29 GMT
Subject: RFR: 8298123: Problem List MaximizedToIconified.java on macOS
Message-ID: <ySaHI2pptwwfE1x_CIS1yRCZdbIeUjskvv23A5u2FtE=.7955b13d-7993-485d-9f7f-25291bd8812f@github.com>

Problem list this test failing on macOS 13

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

Commit messages:
 - 8298123

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

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


From dcubed at openjdk.org  Mon Dec  5 21:11:12 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 5 Dec 2022 21:11:12 GMT
Subject: RFR: 8298123: Problem List MaximizedToIconified.java on macOS
In-Reply-To: <ySaHI2pptwwfE1x_CIS1yRCZdbIeUjskvv23A5u2FtE=.7955b13d-7993-485d-9f7f-25291bd8812f@github.com>
References: <ySaHI2pptwwfE1x_CIS1yRCZdbIeUjskvv23A5u2FtE=.7955b13d-7993-485d-9f7f-25291bd8812f@github.com>
Message-ID: <bsVmqcOZ-SfuP2rxlnNNto3czxPyEGw-4lvjxKkSjdg=.f4e8c7e4-9091-4d54-809a-aa8deb6e7705@github.com>

On Mon, 5 Dec 2022 20:58:31 GMT, Phil Race <prr at openjdk.org> wrote:

> Problem list this test failing on macOS 13

Changes requested by dcubed (Reviewer).

test/jdk/ProblemList.txt line 122:

> 120: java/awt/Focus/AutoRequestFocusTest/AutoRequestFocusToFrontTest.java 6848406 generic-all
> 121: java/awt/Focus/AutoRequestFocusTest/AutoRequestFocusSetVisibleTest.java 6848407 generic-all
> 122: java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java 8296962 macosx-all

I think 8296962 is the wrong bug ID...

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

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


From dcubed at openjdk.org  Mon Dec  5 21:11:13 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 5 Dec 2022 21:11:13 GMT
Subject: RFR: 8298123: Problem List MaximizedToIconified.java on macOS
In-Reply-To: <bsVmqcOZ-SfuP2rxlnNNto3czxPyEGw-4lvjxKkSjdg=.f4e8c7e4-9091-4d54-809a-aa8deb6e7705@github.com>
References: <ySaHI2pptwwfE1x_CIS1yRCZdbIeUjskvv23A5u2FtE=.7955b13d-7993-485d-9f7f-25291bd8812f@github.com>
 <bsVmqcOZ-SfuP2rxlnNNto3czxPyEGw-4lvjxKkSjdg=.f4e8c7e4-9091-4d54-809a-aa8deb6e7705@github.com>
Message-ID: <fRSG0Q1JUtVE7qFh9q_bMyX1BHKxa3i3IMqc8edvi6U=.a0f3a26f-b218-4c6f-97cf-f8c714f6d881@github.com>

On Mon, 5 Dec 2022 21:06:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Problem list this test failing on macOS 13
>
> test/jdk/ProblemList.txt line 122:
> 
>> 120: java/awt/Focus/AutoRequestFocusTest/AutoRequestFocusToFrontTest.java 6848406 generic-all
>> 121: java/awt/Focus/AutoRequestFocusTest/AutoRequestFocusSetVisibleTest.java 6848407 generic-all
>> 122: java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java 8296962 macosx-all
> 
> I think 8296962 is the wrong bug ID...

Perhaps this one:
[JDK-8296972](https://bugs.openjdk.org/browse/JDK-8296972) [macos13] java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java: getExtendedState() != 6 as expected.

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

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


From prr at openjdk.org  Mon Dec  5 21:19:57 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 5 Dec 2022 21:19:57 GMT
Subject: RFR: 8298123: Problem List MaximizedToIconified.java on macOS [v2]
In-Reply-To: <ySaHI2pptwwfE1x_CIS1yRCZdbIeUjskvv23A5u2FtE=.7955b13d-7993-485d-9f7f-25291bd8812f@github.com>
References: <ySaHI2pptwwfE1x_CIS1yRCZdbIeUjskvv23A5u2FtE=.7955b13d-7993-485d-9f7f-25291bd8812f@github.com>
Message-ID: <dxwU7WKkuHhELFz6SM-SuIM2A01OdnNbleHuj594nTc=.5413ef50-bb07-4f96-a442-125fc0ba7a4c@github.com>

> Problem list this test failing on macOS 13

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

  8298123

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11519/files
  - new: https://git.openjdk.org/jdk/pull/11519/files/ac0b2f95..413477de

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

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

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


From prr at openjdk.org  Mon Dec  5 21:19:59 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 5 Dec 2022 21:19:59 GMT
Subject: RFR: 8298123: Problem List MaximizedToIconified.java on macOS [v2]
In-Reply-To: <fRSG0Q1JUtVE7qFh9q_bMyX1BHKxa3i3IMqc8edvi6U=.a0f3a26f-b218-4c6f-97cf-f8c714f6d881@github.com>
References: <ySaHI2pptwwfE1x_CIS1yRCZdbIeUjskvv23A5u2FtE=.7955b13d-7993-485d-9f7f-25291bd8812f@github.com>
 <bsVmqcOZ-SfuP2rxlnNNto3czxPyEGw-4lvjxKkSjdg=.f4e8c7e4-9091-4d54-809a-aa8deb6e7705@github.com>
 <fRSG0Q1JUtVE7qFh9q_bMyX1BHKxa3i3IMqc8edvi6U=.a0f3a26f-b218-4c6f-97cf-f8c714f6d881@github.com>
Message-ID: <PDoCe1SW6ptVjBm-Dfn7WsNuBwDL3IV4MOdLBUohBhQ=.015130c6-8d09-4640-9019-a7a79d7c57ec@github.com>

On Mon, 5 Dec 2022 21:07:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/jdk/ProblemList.txt line 122:
>> 
>>> 120: java/awt/Focus/AutoRequestFocusTest/AutoRequestFocusToFrontTest.java 6848406 generic-all
>>> 121: java/awt/Focus/AutoRequestFocusTest/AutoRequestFocusSetVisibleTest.java 6848407 generic-all
>>> 122: java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java 8296962 macosx-all
>> 
>> I think 8296962 is the wrong bug ID...
>
> Perhaps this one:
> [JDK-8296972](https://bugs.openjdk.org/browse/JDK-8296972) [macos13] java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java: getExtendedState() != 6 as expected.

oops one digit typo ! thanks for spotting. Fixed in commit just pushed

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

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


From dcubed at openjdk.org  Mon Dec  5 21:21:59 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 5 Dec 2022 21:21:59 GMT
Subject: RFR: 8298123: Problem List MaximizedToIconified.java on macOS [v2]
In-Reply-To: <dxwU7WKkuHhELFz6SM-SuIM2A01OdnNbleHuj594nTc=.5413ef50-bb07-4f96-a442-125fc0ba7a4c@github.com>
References: <ySaHI2pptwwfE1x_CIS1yRCZdbIeUjskvv23A5u2FtE=.7955b13d-7993-485d-9f7f-25291bd8812f@github.com>
 <dxwU7WKkuHhELFz6SM-SuIM2A01OdnNbleHuj594nTc=.5413ef50-bb07-4f96-a442-125fc0ba7a4c@github.com>
Message-ID: <JUHuPFMI4zzUQXpmBJukzDyUxUmPVqtbhLDSRTRmBXQ=.159f9ec7-b2ef-47f1-937c-70a7d10b902a@github.com>

On Mon, 5 Dec 2022 21:19:57 GMT, Phil Race <prr at openjdk.org> wrote:

>> Problem list this test failing on macOS 13
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8298123

Thumbs up. This is a trivial fix.

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

Marked as reviewed by dcubed (Reviewer).

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


From prr at openjdk.org  Mon Dec  5 21:29:29 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 5 Dec 2022 21:29:29 GMT
Subject: Integrated: 8298123: Problem List MaximizedToIconified.java on macOS
In-Reply-To: <ySaHI2pptwwfE1x_CIS1yRCZdbIeUjskvv23A5u2FtE=.7955b13d-7993-485d-9f7f-25291bd8812f@github.com>
References: <ySaHI2pptwwfE1x_CIS1yRCZdbIeUjskvv23A5u2FtE=.7955b13d-7993-485d-9f7f-25291bd8812f@github.com>
Message-ID: <Kcixs4JhY4_RK5TtZ-R7JcXOPQlvojZZ9j-NpP125Vs=.52212bcd-5d15-4b89-978b-c6d364ea5f35@github.com>

On Mon, 5 Dec 2022 20:58:31 GMT, Phil Race <prr at openjdk.org> wrote:

> Problem list this test failing on macOS 13

This pull request has now been integrated.

Changeset: 8af6e8a6
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8af6e8a67fc0355f11c270c3ea794366741856fa
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8298123: Problem List MaximizedToIconified.java on macOS

Reviewed-by: dcubed

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

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


From prr at openjdk.org  Mon Dec  5 21:44:00 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 5 Dec 2022 21:44:00 GMT
Subject: RFR: 4677581: ColorModel.getComponentSize()-wrong conditions for
 ArrayIndexOutOfBoundsExceptio
In-Reply-To: <C2YzdBBLdjaVXPsMxf5pkLLMX0Y3E4__xTIvlZldeOA=.bb8eb3c6-8a93-42f5-9218-0da6da5bca16@github.com>
References: <C2YzdBBLdjaVXPsMxf5pkLLMX0Y3E4__xTIvlZldeOA=.bb8eb3c6-8a93-42f5-9218-0da6da5bca16@github.com>
Message-ID: <JCBQ8gi59FWYaX-gATDruDN-Mugx82Tzbmqc6uKBT9o=.3e7d5ad4-edc8-46f3-a663-fd0c9147ff26@github.com>

On Fri, 2 Dec 2022 03:34:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The specification for `java.awt.image.ColorModel#getComponentSize(int)` states that an ArrayIndexOutOfBoundsException is thrown "if componentIdx is greater than the number of components or less than zero". The condition should actually be "if componentIdx is greater than OR EQUAL TO the number of components or less than zero."

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Mon Dec  5 22:04:10 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 5 Dec 2022 22:04:10 GMT
Subject: RFR: JDK-8298093: improve cleanup and error handling of
 awt_parseColorModel in awt_parseImage.c
In-Reply-To: <LJXA0GoYlzD_v4Gb9N0ytaim25_su2y8hAyWhx0hGKI=.5087cce4-07f1-446c-a389-d65334315f73@github.com>
References: <LJXA0GoYlzD_v4Gb9N0ytaim25_su2y8hAyWhx0hGKI=.5087cce4-07f1-446c-a389-d65334315f73@github.com>
Message-ID: <b_v0DR3kIkDasZCp52IzPAX_suQuAkSfxuRyqVdTc0E=.6c8d3949-6377-4dc7-b45e-2b633bc3b0a9@github.com>

On Mon, 5 Dec 2022 09:51:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The cleanup and error handling in function awt_parseColorModel in awt_parseImage.c could be improved.

src/java.desktop/share/native/libawt/awt/image/awt_parseImage.c line 104:

> 102:                                       cmP)) <= 0) {
> 103:         awt_freeParsedRaster(&imageP->raster, FALSE);
> 104:         if (cmP->nBits != NULL) free(cmP->nBits);

It seems wrong to me that awt_parseColorModel should return a failure code and not have cleaned up any storage it itself allocated.
In other words this clean up belongs in there.

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

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


From honkar at openjdk.org  Mon Dec  5 22:10:15 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 5 Dec 2022 22:10:15 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds [v2]
In-Reply-To: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
Message-ID: <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>

> The above test was failing due to incorrect pixel color and wrong window bounds on Mac-ARM, Windows and Linux platforms.
> 
> The following changes have been made:
> - Correct window bounds are obtained using the current ScreenDevice's DefaultConfig bounds (this test checks FullScreen functionality on multiple screen devices).
> - Color tolerance has been added for color check
> - Instead of scanning the full screen to check pixel color, vertical and horizontal scans are done at the far right and bottom end to ensure that window is in full screen mode w.r.t to screen device and the window bounds are as expected.
> 
> CI testing passes on all platforms (tested 50 times per platform).

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

  frame changed back to decorated and exclude on linux

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11462/files
  - new: https://git.openjdk.org/jdk/pull/11462/files/fc65d00e..a8f4452c

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

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

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


From honkar at openjdk.org  Mon Dec  5 22:28:45 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 5 Dec 2022 22:28:45 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds [v2]
In-Reply-To: <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
Message-ID: <SB6kP2fyenih7vP84Dc2onu5EUf6ZCY9WGUxRXMmLfc=.2742e7aa-2417-4857-b923-6a4bb04a4a64@github.com>

On Mon, 5 Dec 2022 22:10:15 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The above test was failing due to incorrect pixel color and wrong window bounds on Mac-ARM, Windows and Linux platforms.
>> 
>> The following changes have been made:
>> - Correct window bounds are obtained using the current ScreenDevice's DefaultConfig bounds (this test checks FullScreen functionality on multiple screen devices).
>> - Color tolerance has been added for color check
>> - Instead of scanning the full screen to check pixel color, vertical and horizontal scans are done at the far right and bottom end to ensure that window is in full screen mode w.r.t to screen device and the window bounds are as expected.
>> 
>> CI testing passes on all platforms (tested 50 times per platform).
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   frame changed back to decorated and exclude on linux

Updated changes -

- device.getDefaultConfiguration().getBounds() is used to compare with the full-screen window size instead of DisplayMode's bounds for reasons mentioned here [11462#](https://github.com/openjdk/jdk/pull/11462#discussion_r1038598610)

- Frames are reverted to be decorated. The test passes on all platforms except linux when decorated frames are used. On Linux, there is a height mismatch of the full-screen window and a black bar is seen at the top of full screen window as shown in the screenshots below. For the above reason and review suggestion mentioned here  [11462#](https://github.com/openjdk/jdk/pull/11462#discussion_r1039167448), the following test has been excluded on linux.

![image](https://user-images.githubusercontent.com/95945681/205755466-6a57098a-517b-4bb9-886a-ebb282a0e030.png)

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

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


From duke at openjdk.org  Tue Dec  6 01:18:24 2022
From: duke at openjdk.org (SWinxy)
Date: Tue, 6 Dec 2022 01:18:24 GMT
Subject: RFR: 4668290: unclear spec for Polygon.bounds field [v3]
In-Reply-To: <jjzwWZJPW8Essivj9svlhO-LScPQV_TlMoC0GGOVgMY=.b5d5ced5-77af-4ce9-8214-10c1cc0392cb@github.com>
References: <jjzwWZJPW8Essivj9svlhO-LScPQV_TlMoC0GGOVgMY=.b5d5ced5-77af-4ce9-8214-10c1cc0392cb@github.com>
Message-ID: <6zfZm8_c_WBTwtOa6YqlqdtxkYhoCR-Q2GcipOr5NAI=.56237225-ee07-466f-83eb-60bbef22845c@github.com>

> New documentation replaces the `This value can be null.`:
> 
> When created, {@link #invalidate() invalidated}, or {@link #reset() reset},
> this becomes {@code null}. To get out of the null state,
> {@link #getBounds()} called with {@link #npoints} being greater than
> {@code 0} will transfer into a non-null {@link Rectangle}.
> 
> 
> I think I've got the reason for why it can be `null` correct, but you never know.
> 
> In javax.swing.text.html.Map, I've replaced setting the field to null with the equivalent #invalidate(). This may mean we can make the field private in the future.

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

  Use javadoc code syntax for null

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10417/files
  - new: https://git.openjdk.org/jdk/pull/10417/files/7d2e36a6..9b6f7d91

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

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

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


From serb at openjdk.org  Tue Dec  6 02:06:38 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 Dec 2022 02:06:38 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus
In-Reply-To: <sl_FDZPPaLyWqv74FBu0aJwzSvRgIwrT_Lj8TF3AtpU=.1dddf19e-c2b6-48ba-b477-dc685bbc1efb@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <e7ITSsOpcKtlC2bJNzIM3PFCUcoRZdfRi0mr1JxsgFE=.f37d4fe5-6a07-427c-b87f-b0ba50efcc6c@github.com>
 <VUwbo01Ivv81AevheTugl-_xosvdnzR7jhFhJtdViaE=.493aee6b-d32a-4258-8271-b25a281273d8@github.com>
 <xJz52QqQG3jjK_eODsEXefcjWz7dfCLa29VepSCwYtE=.1757660e-6211-4917-9a41-e9d5908ccecc@github.com>
 <sl_FDZPPaLyWqv74FBu0aJwzSvRgIwrT_Lj8TF3AtpU=.1dddf19e-c2b6-48ba-b477-dc685bbc1efb@github.com>
Message-ID: <Pfc1L8tORSVPgNs51CRj0MkEF0EtbOIt7-gnmpswjDA=.1b49bc05-0a92-4c54-805d-54815983e2be@github.com>

On Mon, 5 Dec 2022 07:26:27 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Chrome form editor hides cursor, Adobe Acrobat shows blinking cursor, Microsoft Office 2011 shows some custom cursor that appears to be grayed off or faded. Differently.

Does any of them use non blinking cursor? it seems related to the application and not the library they use. The library provides a way to set different cursors and the application may use that. Maybe we can update the SwingSet2 which is used for testing to show that it is possible to do that in Swing?

We updated SwingSet2 in the past for a similar reason: https://bugs.openjdk.org/browse/JDK-8278604 and https://bugs.openjdk.org/browse/JDK-8278526

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

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


From serb at openjdk.org  Tue Dec  6 02:17:09 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 Dec 2022 02:17:09 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus [v2]
In-Reply-To: <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
Message-ID: <0W7udNXCwl40PgxUUUo-ZMm6nBwad7O4m08E5R-V1rI=.c1a542b9-0f5c-4f8c-810b-5f5d5e5fd862@github.com>

On Fri, 2 Dec 2022 23:52:55 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Set the text caret to be visible but not blinking on the non-editable text area.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handling the case when blink rate is set while component is unedited
>   Test HidingSelectionTest.java is rewritten and corrected.

BTW the description of this bug states: 
> A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus   changes.

I think that using the VoiceOver or JAWS will highlight the currently focused component since we should send that information to them, no?

And I do not think this statement in the bug description is true:
> A non-focusable JTextArea could be used instead, but this makes the instruction text unfocusable for screen readers as well. This setup would violate the second part of the 508 rule as quoted above.

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

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


From jdv at openjdk.org  Tue Dec  6 03:46:11 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 6 Dec 2022 03:46:11 GMT
Subject: Integrated: 8298027: Remove SCCS id's from awt jtreg tests
In-Reply-To: <lWFPbg2l8BHwEf7q6p3nt7lzHdBAf1RJ23za5VNij0I=.e1fba7b1-5b67-4c22-a57d-7949cd487bfe@github.com>
References: <lWFPbg2l8BHwEf7q6p3nt7lzHdBAf1RJ23za5VNij0I=.e1fba7b1-5b67-4c22-a57d-7949cd487bfe@github.com>
Message-ID: <7j35Bx1DprcPgn4kJIVoarDI698Xz9qvSZEpJRRpMnk=.a73c0690-9932-4463-9464-253707c62374@github.com>

On Mon, 5 Dec 2022 10:47:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Noticed SCCS jtreg id's in 2 open awt tests. After jtreg 7.1 update, jtreg doesn't parse SCCS id's and it causes the tests with SCCS id's to fail.
> 
> As of now these 2 tests are ignored, but it is good to remove these SCCS id's.
> If we don't need these 2 tests since they are ignored, then i will update the PR base on the review comments.

This pull request has now been integrated.

Changeset: ba2d28e9
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba2d28e911f4f523334f98fd0186680acafb6f0a
Stats:     4 lines in 2 files changed: 0 ins; 2 del; 2 mod

8298027: Remove SCCS id's from awt jtreg tests

Reviewed-by: aivanov

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

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


From serb at openjdk.org  Tue Dec  6 04:13:14 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 Dec 2022 04:13:14 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds [v2]
In-Reply-To: <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
Message-ID: <CUGEHLhq9stsvqPxzj58o9ngHDcGQBlOiHMyNqKfh48=.28a35c51-72ac-463c-8392-2037ea9c02db@github.com>

On Mon, 5 Dec 2022 22:10:15 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The above test was failing due to incorrect pixel color and wrong window bounds on Mac-ARM, Windows and Linux platforms.
>> 
>> The following changes have been made:
>> - Correct window bounds are obtained using the current ScreenDevice's DefaultConfig bounds (this test checks FullScreen functionality on multiple screen devices).
>> - Color tolerance has been added for color check
>> - Instead of scanning the full screen to check pixel color, vertical and horizontal scans are done at the far right and bottom end to ensure that window is in full screen mode w.r.t to screen device and the window bounds are as expected.
>> 
>> CI testing passes on all platforms (tested 50 times per platform).
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   frame changed back to decorated and exclude on linux

test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 44:

> 42:  * @bug 8003173 7019055
> 43:  * @summary Full-screen windows should have the proper insets.
> 44:  * @requires (os.family != "linux")

You should not exclude the test on the platform which has a bug in it. On Linux, this test fails if a non-accelerated java2d pipeline is used, and we just "maximize the frame", this problem is similar to Windows described in JDK-7019055.

Note that you deleted the reference to this bug https://bugs.openjdk.org/browse/JDK-8266245 from problem list, take a look at the images attached to that report, both of them have black/empty rectangle on the top. This looks similar to the initial bug this test was created https://bugs.openjdk.org/browse/JDK-8003173

So looks like this is not a test issue on all platforms, other than the  `device.getDefaultConfiguration().getBounds()` usage.

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

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


From honkar at openjdk.org  Tue Dec  6 06:17:10 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 6 Dec 2022 06:17:10 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds [v2]
In-Reply-To: <CUGEHLhq9stsvqPxzj58o9ngHDcGQBlOiHMyNqKfh48=.28a35c51-72ac-463c-8392-2037ea9c02db@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
 <CUGEHLhq9stsvqPxzj58o9ngHDcGQBlOiHMyNqKfh48=.28a35c51-72ac-463c-8392-2037ea9c02db@github.com>
Message-ID: <M0xzCzMOfO1Uk1FGaaF5v65YOx1HR5YIGmrsM5IE67A=.a8c89539-991b-4910-b5bb-1f427fa75099@github.com>

On Tue, 6 Dec 2022 04:07:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   frame changed back to decorated and exclude on linux
>
> test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 44:
> 
>> 42:  * @bug 8003173 7019055
>> 43:  * @summary Full-screen windows should have the proper insets.
>> 44:  * @requires (os.family != "linux")
> 
> You should not exclude the test on the platform which has a bug in it. On Linux, this test fails if a non-accelerated java2d pipeline is used, and we just "maximize the frame", this problem is similar to Windows described in JDK-7019055.
> 
> Note that you deleted the reference to this bug https://bugs.openjdk.org/browse/JDK-8266245 from problem list, take a look at the images attached to that report, both of them have black/empty rectangle on the top. This looks similar to the initial bug this test was created https://bugs.openjdk.org/browse/JDK-8003173
> 
> So looks like this is not a test issue on all platforms, other than the  `device.getDefaultConfiguration().getBounds()` usage.

@mrserb Since the current test fix works on other platforms (windows, mac) other than linux, can the other platforms be removed and the test be problemlisted only on linux platform until the product bug is fixed on linux then? Additionally the test was failing on Mac-ARM due to color mismatch that was fixed by adding tolerance.

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

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


From serb at openjdk.org  Tue Dec  6 09:36:12 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 Dec 2022 09:36:12 GMT
Subject: RFR: 8296198: JFileChooser throws InternalError
 java.lang.InternalError with Windows shortcuts
In-Reply-To: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>
References: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>
Message-ID: <olUy1qpMHs3VixfWHE88njdHTPL7hlkxXKhfacKnlJE=.74e043a8-a740-4f52-9b3e-1b528a9d5616@github.com>

On Mon, 5 Dec 2022 11:35:11 GMT, Tejesh R <tr at openjdk.org> wrote:

> When `JFileChooser` uses custom `FileSystemView`, traversing to link/shortcut to a folder throw `InternalError java.lang.InternalError ` in Windows. The issue found out to be in BasicFileChooserUI class which was unable to resolve the link path during directory setting. The `UsesShellFolder` check expects the FileSystemView to be of WindowsFileSystemView, which fails when custom FileSystemView is used.
> The fix includes resolving the link folder when custom File System View is used and has manual test. (Fix is test in CI system and no regression caused).

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 1433:

> 1431:                     return;
> 1432:                 }
> 1433:             } else if ( fc.getFileSystemView().isLink(dir)) {

Probably we can minimize the code duplication here?

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

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


From duke at openjdk.org  Tue Dec  6 09:52:12 2022
From: duke at openjdk.org (duke)
Date: Tue, 6 Dec 2022 09:52:12 GMT
Subject: Withdrawn: 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: <mh4kKV4Chmpz45GJjfuXUcbQRrUPFrVQ8SDMyLRIn6c=.1dac1293-199f-4248-abba-076a8cd83edc@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 pull request has been closed without being integrated.

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

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


From mbaesken at openjdk.org  Tue Dec  6 09:52:34 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 6 Dec 2022 09:52:34 GMT
Subject: RFR: JDK-8298093: improve cleanup and error handling of
 awt_parseColorModel in awt_parseImage.c [v2]
In-Reply-To: <LJXA0GoYlzD_v4Gb9N0ytaim25_su2y8hAyWhx0hGKI=.5087cce4-07f1-446c-a389-d65334315f73@github.com>
References: <LJXA0GoYlzD_v4Gb9N0ytaim25_su2y8hAyWhx0hGKI=.5087cce4-07f1-446c-a389-d65334315f73@github.com>
Message-ID: <WGbj-wl9h73Kar7V_yDeHXPWvYncAE_SfB5s-5ThwZ0=.983c2ef2-34b6-40c2-a13f-b44d70322e47@github.com>

> The cleanup and error handling in function awt_parseColorModel in awt_parseImage.c could be improved.

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

  move freeing into awt_parseColorModel

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11508/files
  - new: https://git.openjdk.org/jdk/pull/11508/files/a5de4c0a..9b9f56ea

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

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

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


From mbaesken at openjdk.org  Tue Dec  6 09:55:05 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 6 Dec 2022 09:55:05 GMT
Subject: RFR: JDK-8298093: improve cleanup and error handling of
 awt_parseColorModel in awt_parseImage.c [v2]
In-Reply-To: <b_v0DR3kIkDasZCp52IzPAX_suQuAkSfxuRyqVdTc0E=.6c8d3949-6377-4dc7-b45e-2b633bc3b0a9@github.com>
References: <LJXA0GoYlzD_v4Gb9N0ytaim25_su2y8hAyWhx0hGKI=.5087cce4-07f1-446c-a389-d65334315f73@github.com>
 <b_v0DR3kIkDasZCp52IzPAX_suQuAkSfxuRyqVdTc0E=.6c8d3949-6377-4dc7-b45e-2b633bc3b0a9@github.com>
Message-ID: <wb-SQ6Gxqzh6DZslxuqeOiuwCcaw1BPRkCuX4OgIhWg=.27c4c384-aef6-4894-bfbc-1f4be980ffa7@github.com>

On Mon, 5 Dec 2022 22:01:44 GMT, Phil Race <prr at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move freeing into awt_parseColorModel
>
> src/java.desktop/share/native/libawt/awt/image/awt_parseImage.c line 104:
> 
>> 102:                                       cmP)) <= 0) {
>> 103:         awt_freeParsedRaster(&imageP->raster, FALSE);
>> 104:         if (cmP->nBits != NULL) free(cmP->nBits);
> 
> It seems wrong to me that awt_parseColorModel should return a failure code and not have cleaned up any storage it itself allocated.
> In other words this clean up belongs in there.

Hi Phil, I moved the cleanup.

Another question - what do you think about introducting a macro JNU_CHECK_EXCEPTION_FREE_RETURN ? We have quite a number of places using this pattern (exception check , free and return)  , in this change now as well.  Might be worth having a macro for this.

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

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


From abhiscxk at openjdk.org  Tue Dec  6 10:05:28 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 6 Dec 2022 10:05:28 GMT
Subject: RFR: 8296198: JFileChooser throws InternalError
 java.lang.InternalError with Windows shortcuts
In-Reply-To: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>
References: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>
Message-ID: <j2P3pC1sQ8fbyy3-GUFLMbNv0LQDc4ib6y0jYJu_kDA=.5bd0683b-37a5-403f-9918-8be85d61e5c6@github.com>

On Mon, 5 Dec 2022 11:35:11 GMT, Tejesh R <tr at openjdk.org> wrote:

> When `JFileChooser` uses custom `FileSystemView`, traversing to link/shortcut to a folder throw `InternalError java.lang.InternalError ` in Windows. The issue found out to be in BasicFileChooserUI class which was unable to resolve the link path during directory setting. The `UsesShellFolder` check expects the FileSystemView to be of WindowsFileSystemView, which fails when custom FileSystemView is used.
> The fix includes resolving the link folder when custom File System View is used and has manual test. (Fix is test in CI system and no regression caused).

test/jdk/javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java line 131:

> 129:                 @Override
> 130:                 public Icon getSystemIcon(File f, int width, int height) {
> 131:                     return delegate.getSystemIcon(f, width, height);

Commented block of code can be removed.

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

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


From serb at openjdk.org  Tue Dec  6 10:23:02 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 Dec 2022 10:23:02 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds [v2]
In-Reply-To: <M0xzCzMOfO1Uk1FGaaF5v65YOx1HR5YIGmrsM5IE67A=.a8c89539-991b-4910-b5bb-1f427fa75099@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
 <CUGEHLhq9stsvqPxzj58o9ngHDcGQBlOiHMyNqKfh48=.28a35c51-72ac-463c-8392-2037ea9c02db@github.com>
 <M0xzCzMOfO1Uk1FGaaF5v65YOx1HR5YIGmrsM5IE67A=.a8c89539-991b-4910-b5bb-1f427fa75099@github.com>
Message-ID: <B1NZU42rDKaZPwvOEcv_mjwxPsXKOoKKZA4JlsBc3Ck=.75ce53cf-ac17-4eb5-b65d-4a7b62f6f485@github.com>

On Tue, 6 Dec 2022 06:14:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 44:
>> 
>>> 42:  * @bug 8003173 7019055
>>> 43:  * @summary Full-screen windows should have the proper insets.
>>> 44:  * @requires (os.family != "linux")
>> 
>> You should not exclude the test on the platform which has a bug in it. On Linux, this test fails if a non-accelerated java2d pipeline is used, and we just "maximize the frame", this problem is similar to Windows described in JDK-7019055.
>> 
>> Note that you deleted the reference to this bug https://bugs.openjdk.org/browse/JDK-8266245 from problem list, take a look at the images attached to that report, both of them have black/empty rectangle on the top. This looks similar to the initial bug this test was created https://bugs.openjdk.org/browse/JDK-8003173
>> 
>> So looks like this is not a test issue on all platforms, other than the  `device.getDefaultConfiguration().getBounds()` usage.
>
> @mrserb Since the current test fix works on other platforms (windows, mac) other than linux, can the other platforms be removed and the test be problemlisted only on linux platform until the product bug is fixed on linux then? Additionally the test was failing on Mac-ARM due to color mismatch that was fixed by adding tolerance.

It is still unclear why tolerance is needed in this test and is not needed in the CheckCommonColors?

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

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


From tr at openjdk.org  Tue Dec  6 11:59:17 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 6 Dec 2022 11:59:17 GMT
Subject: RFR: 8296198: JFileChooser throws InternalError
 java.lang.InternalError with Windows shortcuts [v2]
In-Reply-To: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>
References: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>
Message-ID: <FtfOKAoW1DejIqGkAO3Pajy1HH_GPSlS0DISIyp86CA=.a387a0a2-c92e-4543-9a7a-31c13edf3aa7@github.com>

> When `JFileChooser` uses custom `FileSystemView`, traversing to link/shortcut to a folder throw `InternalError java.lang.InternalError ` in Windows. The issue found out to be in BasicFileChooserUI class which was unable to resolve the link path during directory setting. The `UsesShellFolder` check expects the FileSystemView to be of WindowsFileSystemView, which fails when custom FileSystemView is used.
> The fix includes resolving the link folder when custom File System View is used and has manual test. (Fix is test in CI system and no regression caused).

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/11510/files
  - new: https://git.openjdk.org/jdk/pull/11510/files/764f35e9..4dd8cc71

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

  Stats: 36 lines in 2 files changed: 3 ins; 21 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/11510.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11510/head:pull/11510

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


From tr at openjdk.org  Tue Dec  6 11:59:18 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 6 Dec 2022 11:59:18 GMT
Subject: RFR: 8296198: JFileChooser throws InternalError
 java.lang.InternalError with Windows shortcuts [v2]
In-Reply-To: <olUy1qpMHs3VixfWHE88njdHTPL7hlkxXKhfacKnlJE=.74e043a8-a740-4f52-9b3e-1b528a9d5616@github.com>
References: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>
 <olUy1qpMHs3VixfWHE88njdHTPL7hlkxXKhfacKnlJE=.74e043a8-a740-4f52-9b3e-1b528a9d5616@github.com>
Message-ID: <yddlM64zzexTYLyFbDJn4Tzk6ial144f2q8RtA13w-U=.5e1cc82c-8541-4298-be8c-99ba5d003de2@github.com>

On Tue, 6 Dec 2022 09:32:18 GMT, Sergey Bylokhov <serb 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/basic/BasicFileChooserUI.java line 1433:
> 
>> 1431:                     return;
>> 1432:                 }
>> 1433:             } else if ( fc.getFileSystemView().isLink(dir)) {
> 
> Probably we can minimize the code duplication here?

Updated.

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

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


From tr at openjdk.org  Tue Dec  6 11:59:18 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 6 Dec 2022 11:59:18 GMT
Subject: RFR: 8296198: JFileChooser throws InternalError
 java.lang.InternalError with Windows shortcuts [v2]
In-Reply-To: <j2P3pC1sQ8fbyy3-GUFLMbNv0LQDc4ib6y0jYJu_kDA=.5bd0683b-37a5-403f-9918-8be85d61e5c6@github.com>
References: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>
 <j2P3pC1sQ8fbyy3-GUFLMbNv0LQDc4ib6y0jYJu_kDA=.5bd0683b-37a5-403f-9918-8be85d61e5c6@github.com>
Message-ID: <Ey9oyg87Xdssj38VitPaBgq9T0DITKgv0jYnWbCFV8w=.3aae155a-dbdf-4fdb-8109-8405410ef7c7@github.com>

On Tue, 6 Dec 2022 10:02:21 GMT, Abhishek Kumar <abhiscxk 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/FileSystemView/CustomFSVLinkTest.java line 131:
> 
>> 129:                 @Override
>> 130:                 public Icon getSystemIcon(File f, int width, int height) {
>> 131:                     return delegate.getSystemIcon(f, width, height);
> 
> Commented block of code can be removed.

Updated.

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

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


From kizune at openjdk.org  Tue Dec  6 12:08:20 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 6 Dec 2022 12:08:20 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus
In-Reply-To: <Pfc1L8tORSVPgNs51CRj0MkEF0EtbOIt7-gnmpswjDA=.1b49bc05-0a92-4c54-805d-54815983e2be@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <e7ITSsOpcKtlC2bJNzIM3PFCUcoRZdfRi0mr1JxsgFE=.f37d4fe5-6a07-427c-b87f-b0ba50efcc6c@github.com>
 <VUwbo01Ivv81AevheTugl-_xosvdnzR7jhFhJtdViaE=.493aee6b-d32a-4258-8271-b25a281273d8@github.com>
 <xJz52QqQG3jjK_eODsEXefcjWz7dfCLa29VepSCwYtE=.1757660e-6211-4917-9a41-e9d5908ccecc@github.com>
 <sl_FDZPPaLyWqv74FBu0aJwzSvRgIwrT_Lj8TF3AtpU=.1dddf19e-c2b6-48ba-b477-dc685bbc1efb@github.com>
 <Pfc1L8tORSVPgNs51CRj0MkEF0EtbOIt7-gnmpswjDA=.1b49bc05-0a92-4c54-805d-54815983e2be@github.com>
Message-ID: <2XePfo1gtNAWJvM5ECfg8Vkp8VObLOyQmM8WkQDiabM=.43f5d635-9352-4cc8-b9d9-e76aa710064d@github.com>

On Tue, 6 Dec 2022 02:00:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The library provides a way to set different cursors and the application may use that

The library does not provide an ability to set caret to visible permanently in case of text component being non-editable. Every time focus will change the caret will change too. One would have to implement a custom caret that overrides this logic.

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

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


From kizune at openjdk.org  Tue Dec  6 12:08:20 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 6 Dec 2022 12:08:20 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus [v2]
In-Reply-To: <0W7udNXCwl40PgxUUUo-ZMm6nBwad7O4m08E5R-V1rI=.c1a542b9-0f5c-4f8c-810b-5f5d5e5fd862@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
 <0W7udNXCwl40PgxUUUo-ZMm6nBwad7O4m08E5R-V1rI=.c1a542b9-0f5c-4f8c-810b-5f5d5e5fd862@github.com>
Message-ID: <9YKx-SCc_t4ADgmf8E07MpH46ZmOVinq4uVNuDkJ1NY=.fc8af01e-7c58-43b9-bb5b-1fcd949ac4d1@github.com>

On Tue, 6 Dec 2022 02:11:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I think that using the VoiceOver or JAWS will highlight the currently focused component since we should send that information to them, no?

That paragraph consists of two statements - first is that focus should be visible and one can tell which component has focus without the use of VO or JAWS. The second part is that it should be also exposed trough the assistive technology API is not related to the problem at hand.

> And I do not think this statement in the bug description is true:

It might have been true when the bug was submitted. I mean it is 21 years old, soon it might have its own small bugs.

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

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


From itakiguchi at openjdk.org  Tue Dec  6 14:14:33 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 6 Dec 2022 14:14:33 GMT
Subject: RFR: 8298006: Build failure by maybe-uninitialized error on Linux
 s390x GCC8
In-Reply-To: <G71lep3GeJwy4OMGWKrE7_kxeitheMbsrv0AdMNzJrc=.a5a8d15a-b2da-4999-80a9-6b8817cdac07@github.com>
References: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
 <G71lep3GeJwy4OMGWKrE7_kxeitheMbsrv0AdMNzJrc=.a5a8d15a-b2da-4999-80a9-6b8817cdac07@github.com>
Message-ID: <3Q3KzLvfQimK1mRjb7hHyWCki_Z0LqOkyOS5BoEqYHI=.3dd20205-1a70-47e8-906b-c05d4cfa4647@github.com>

On Mon, 5 Dec 2022 18:22:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> I changed GCC toolchain from GCC6 to GCC8 on SLES12SP5 Linux s390x.
>> I could see following errors:
>> 
>> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c: In function 'allocateRasterArray':
>> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:2944:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> ?????????????????????????????(((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])
>> ?????????????????????????????????????????????????????????????????????~~~~^~~
>> 
>> 
>> According to error messages,
>> roff and loff may not be initialized.
>
>> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c: In function 'allocateRasterArray':
>> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:2944:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> ?????????????????????????????(((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])
> 
> That's weird. allocateRasterArray is at lines 2360-2575 .. so why are you seeing it at line 2944 ????

Thanks @prrace .
>That's weird. allocateRasterArray is at lines 2360-2575 .. so why are you seeing it at line 2944 ????

Ummm, I could not determine the reason...

I assume AddressSanitizer detected memory errors because of following 2 codes:
https://github.com/openjdk/jdk/blob/1e468320dc6e495343dbdf392cbcbda79672c7ad/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c#L2937
https://github.com/openjdk/jdk/blob/1e468320dc6e495343dbdf392cbcbda79672c7ad/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c#L3118

So I'd like to put `memset()` on these parts.

But I checked `if` and `else` blocks on above part.
These are exactly the same.
https://github.com/openjdk/jdk/blob/1e468320dc6e495343dbdf392cbcbda79672c7ad/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c#L2937-L2965
https://github.com/openjdk/jdk/blob/1e468320dc6e495343dbdf392cbcbda79672c7ad/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c#L3118-L3153

I tried to modify from `if .. else` block to flat.
AddressSanitizer did not detect memory error.

Could you give me any advice ?

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

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


From mbaesken at openjdk.org  Tue Dec  6 15:30:08 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 6 Dec 2022 15:30:08 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
Message-ID: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>

We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

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

Commit messages:
 - JDK-8298170

Changes: https://git.openjdk.org/jdk/pull/11539/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11539&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298170
  Stats: 87 lines in 7 files changed: 32 ins; 39 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/11539.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11539/head:pull/11539

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


From prr at openjdk.org  Tue Dec  6 18:28:13 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 Dec 2022 18:28:13 GMT
Subject: RFR: 8298006: Build failure by maybe-uninitialized error on Linux
 s390x GCC8
In-Reply-To: <G71lep3GeJwy4OMGWKrE7_kxeitheMbsrv0AdMNzJrc=.a5a8d15a-b2da-4999-80a9-6b8817cdac07@github.com>
References: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
 <G71lep3GeJwy4OMGWKrE7_kxeitheMbsrv0AdMNzJrc=.a5a8d15a-b2da-4999-80a9-6b8817cdac07@github.com>
Message-ID: <LgRN1k1cK5qKTfV9fP5OeMkpapZO6UN1eWpZNZqO5mc=.ed27e8a1-e1cb-42ef-a390-70b9035bd7e3@github.com>

On Mon, 5 Dec 2022 18:22:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> I changed GCC toolchain from GCC6 to GCC8 on SLES12SP5 Linux s390x.
>> I could see following errors:
>> 
>> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c: In function 'allocateRasterArray':
>> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:2944:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> ?????????????????????????????(((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])
>> ?????????????????????????????????????????????????????????????????????~~~~^~~
>> 
>> 
>> According to error messages,
>> roff and loff may not be initialized.
>
>> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c: In function 'allocateRasterArray':
>> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:2944:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> ?????????????????????????????(((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])
> 
> That's weird. allocateRasterArray is at lines 2360-2575 .. so why are you seeing it at line 2944 ????

> Thanks @prrace .
> 
> > That's weird. allocateRasterArray is at lines 2360-2575 .. so why are you seeing it at line 2944 ????
> 
> Ummm, I could not determine the reason...
> 
> I assume AddressSanitizer detected memory errors because of following 2 codes:
> 
> https://github.com/openjdk/jdk/blob/1e468320dc6e495343dbdf392cbcbda79672c7ad/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c#L2937
> 
> 
> https://github.com/openjdk/jdk/blob/1e468320dc6e495343dbdf392cbcbda79672c7ad/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c#L3118
> 
> So I'd like to put `memset()` on these parts.
> 
> But I checked `if` and `else` blocks on above part. These are exactly the same.
> 
> https://github.com/openjdk/jdk/blob/1e468320dc6e495343dbdf392cbcbda79672c7ad/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c#L2937-L2965
> 
> 
> https://github.com/openjdk/jdk/blob/1e468320dc6e495343dbdf392cbcbda79672c7ad/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c#L3118-L3153
> 
> I tried to modify from `if .. else` block to flat. AddressSanitizer did not detect memory error.
> 
> Could you give me any advice ?

Oh you are running a tool to find these issues ? I thought it was supposed to be a build failure ?
Or are you running the tool to try to understand the build failure.
Tools are not always right in my experience.
I think there's just as much chance as both being false positives as both being correct.
I think at some point the tools arm-wave that this could be a problem but it is not provable. 
As Magnus pointed out "newer" compilers aren't complaining here. 

I don't know what kind of advice you are seeking. If you are asking me to somehow do better than the tools .. well I'd say its a whole lot easier to just memset these to zero. Zero may not be the correct offset either .. but it should be safer.

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

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


From prr at openjdk.org  Tue Dec  6 18:35:05 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 Dec 2022 18:35:05 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <P4RXObyKU5mTlOUCcSUCrvu4eDFBpoMIV6uJrwsQiwA=.715ee905-2079-446d-a4c6-e92af67f5bcf@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

I'm OK with the idea and the specific desktop change.
I'll leave the rest to the appropriate component teams.
Seems this needs > 1 reviewer tho' because of the different areas.

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

Marked as reviewed by prr (Reviewer).

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


From duke at openjdk.org  Tue Dec  6 18:46:27 2022
From: duke at openjdk.org (Rajat Mahajan)
Date: Tue, 6 Dec 2022 18:46:27 GMT
Subject: Integrated: 8297450: ScaledTextFieldBorderTest.java fails when run
 with -show parameter
In-Reply-To: <DFCfeHM00dvRfICYgSRnY1t0zYN9UJHsCOyG6rKU4xU=.820d06c3-2815-4e8b-a3a9-e6ac73ddaea5@github.com>
References: <DFCfeHM00dvRfICYgSRnY1t0zYN9UJHsCOyG6rKU4xU=.820d06c3-2815-4e8b-a3a9-e6ac73ddaea5@github.com>
Message-ID: <y9aTC1gw5SU3i-4eC5WuWL8i73dh8kwY3ekzO1DC4sY=.f2a4d956-d72d-44e9-920f-76cfcf7bd1d6@github.com>

On Sat, 3 Dec 2022 22:11:47 GMT, Rajat Mahajan <duke at openjdk.org> wrote:

> The test is failing because there was no gap between the Textfields.
> I fixed it by adding Vertical Struts in between Textfields.

This pull request has now been integrated.

Changeset: ea83cb96
Author:    Rajat Mahajan <rajat.m.mahajan at oracle.com>
Committer: Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea83cb960d07ffa9384aad6a1e2a0233e3ebbdd1
Stats:     8 lines in 1 file changed: 3 ins; 5 del; 0 mod

8297450: ScaledTextFieldBorderTest.java fails when run with -show parameter

Reviewed-by: aivanov, honkar

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

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


From honkar at openjdk.org  Tue Dec  6 19:03:18 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 6 Dec 2022 19:03:18 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds [v2]
In-Reply-To: <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
Message-ID: <SUJEpT_8CjxIhmYEBwmgbY5h-ldK7UsXdQZF15E2tA4=.07ea5074-afc9-4b6f-bac1-598506616f2f@github.com>

On Mon, 5 Dec 2022 22:10:15 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The above test was failing due to incorrect pixel color and wrong window bounds on Mac-ARM, Windows and Linux platforms.
>> 
>> The following changes have been made:
>> - Correct window bounds are obtained using the current ScreenDevice's DefaultConfig bounds (this test checks FullScreen functionality on multiple screen devices).
>> - Color tolerance has been added for color check
>> - Instead of scanning the full screen to check pixel color, vertical and horizontal scans are done at the far right and bottom end to ensure that window is in full screen mode w.r.t to screen device and the window bounds are as expected.
>> 
>> CI testing passes on all platforms (tested 50 times per platform).
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   frame changed back to decorated and exclude on linux

@mrserb When scanning across the Buffered Image, the RGB obtained at certain locations returned 00fe00 instead of 00ff00 for Green and fe0000 instead of ff0000 for Red, hence a low color tolerance value was added.

The first 2 letters represents alpha channel followed by RGB

Log -
Actual: ff00fe00 ,expected : ff00ff00
Actual: fffe0000 ,expected : ffff0000

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

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


From aivanov at openjdk.org  Tue Dec  6 20:00:09 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 6 Dec 2022 20:00:09 GMT
Subject: RFR: 4668290: unclear spec for Polygon.bounds field [v3]
In-Reply-To: <6zfZm8_c_WBTwtOa6YqlqdtxkYhoCR-Q2GcipOr5NAI=.56237225-ee07-466f-83eb-60bbef22845c@github.com>
References: <jjzwWZJPW8Essivj9svlhO-LScPQV_TlMoC0GGOVgMY=.b5d5ced5-77af-4ce9-8214-10c1cc0392cb@github.com>
 <6zfZm8_c_WBTwtOa6YqlqdtxkYhoCR-Q2GcipOr5NAI=.56237225-ee07-466f-83eb-60bbef22845c@github.com>
Message-ID: <B0-ZF_JX-HOZ68sCqEe_6LoFZVoIuhfwC5ZV2SUPctM=.e535e857-fa51-4374-9e9e-15519f39fe0f@github.com>

On Tue, 6 Dec 2022 01:18:24 GMT, SWinxy <duke at openjdk.org> wrote:

>> New documentation replaces the `This value can be null.`:
>> 
>> When created, {@link #invalidate() invalidated}, or {@link #reset() reset},
>> this becomes {@code null}. To get out of the null state,
>> {@link #getBounds()} called with {@link #npoints} being greater than
>> {@code 0} will transfer into a non-null {@link Rectangle}.
>> 
>> 
>> I think I've got the reason for why it can be `null` correct, but you never know.
>> 
>> In javax.swing.text.html.Map, I've replaced setting the field to null with the equivalent #invalidate(). This may mean we can make the field private in the future.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use javadoc code syntax for null

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.org  Tue Dec  6 20:05:45 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 6 Dec 2022 20:05:45 GMT
Subject: RFR: 4668290: unclear spec for Polygon.bounds field [v3]
In-Reply-To: <j-9daFz6k8o4wdaBG_HlldjUavIAPaCBdNmC558-RKI=.e1340f43-10cb-4138-85b9-e820ea38ea02@github.com>
References: <jjzwWZJPW8Essivj9svlhO-LScPQV_TlMoC0GGOVgMY=.b5d5ced5-77af-4ce9-8214-10c1cc0392cb@github.com>
 <j-9daFz6k8o4wdaBG_HlldjUavIAPaCBdNmC558-RKI=.e1340f43-10cb-4138-85b9-e820ea38ea02@github.com>
Message-ID: <833qckY2HWKCPR_uWWQNAkrWev58GfaNPczv9gvN_Vc=.6ee3a5d7-b6e3-4b96-888d-285b422adf73@github.com>

On Fri, 30 Sep 2022 21:18:45 GMT, Phil Race <prr at openjdk.org> wrote:

>> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use javadoc code syntax for null
>
> src/java.desktop/share/classes/java/awt/Polygon.java line 111:
> 
>> 109:      * {@link #getBounds()} called with {@link #npoints} being greater than
>> 110:      * {@code 0} will transfer into a non-null {@link Rectangle}.
>> 111:      *
> 
> Another dubious piece of design. This should never have been exposed in the API.
> What we need to say here is
> /*
>  * The value of this field is updated by the implementation which may set it to null and will
>  *   re-evaluate it as needed. Application sub-classes should never access this field.
>  */
> And leave it at that.

I noticed one thing: Phil suggested ?re-evaluate?, you used ?reevaluate? without the hyphen.

I tend to use the hyphened version; at the same time, articles in the internet suggest the hyphen is unneeded in such words.

I'm fine with either.

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

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


From rriggs at openjdk.org  Tue Dec  6 20:42:40 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 Dec 2022 20:42:40 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <by8PjHk056eNArwawtCAKY29CJNuEHDkGuDR3DeoeNE=.2c31ba49-5c88-477d-98a7-5b10dc51d702@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

The existing (and new) macro naming doesn't make clear that it always returns from the function.  The presence of "RETURN" in the name only means there is a return value.
The existing code more obviously handles memory deallocation.

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

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


From achung at openjdk.org  Tue Dec  6 20:57:05 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 6 Dec 2022 20:57:05 GMT
Subject: RFR: 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java
 fails with "No MouseReleased event on label!" [v3]
In-Reply-To: <eiXE_NG-GTbzWiUbJdfKxlhQCa-5TEGjgrcPritFM-w=.44904d95-af67-4d5e-9b9e-d263173263e4@github.com>
References: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
 <EIzB-rTp4nCixEH4PXZXGobNojriwq_9sjnc9sexNPw=.0bfe74ab-b190-46e9-a3d8-5bb528644f04@github.com>
 <eiXE_NG-GTbzWiUbJdfKxlhQCa-5TEGjgrcPritFM-w=.44904d95-af67-4d5e-9b9e-d263173263e4@github.com>
Message-ID: <K9KoZHrSv9-jTOqSBM9-qwbLQe79YaU1vnMLQ9b49yg=.ea793698-f807-454e-a399-7e5dca583a47@github.com>

On Mon, 5 Dec 2022 04:11:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/java/awt/Mouse/EnterExitEvents/DragWindowTest.java line 58:
>> 
>>> 56: 
>>> 57:         Robot robot = new Robot();
>>> 58:         robot.setAutoDelay(250);
>> 
>> We normally do not need so much delay for test to work, 100ms being the norm which has sufficed for other tests.
>> Maybe you need to wait robot.delay after creating and showing the GUI which is not done here.
>> Also, this test has heavyweight and lightweight mix, for ex. MyDragWindow class uses JPanel but not in EDT which can result in some timing issue you are seeing, either it needs to be in EDT or can it be changed to AWT Panel as done elsewhere in the test?
>> 
>> ALso, please change the wildcards imports while you are at it..
>
> JPanel question is still unanswered/unchanged...

If I change the JPanel in MyDragWindow to awt Panel, the test fails

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

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


From omikhaltcova at openjdk.org  Tue Dec  6 21:21:59 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Tue, 6 Dec 2022 21:21:59 GMT
Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if
 TextAttribute.TRACKING is set. [v3]
In-Reply-To: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
References: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
Message-ID: <khcW69W3isqPpREWZ2tNGJZS8oRNT11tDaP-lhsOVks=.d8ed0594-2596-49f4-aa8d-e3f3b55f63b8@github.com>

> This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks.
> 
> Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests:
> `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font`

Olga Mikhaltsova has updated the pull request incrementally with three additional commits since the last revision:

 - Added an automated test
 - Fix for negative tracking and float
 - Fix manual test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10289/files
  - new: https://git.openjdk.org/jdk/pull/10289/files/1818c7d5..b1b4b146

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

  Stats: 167 lines in 3 files changed: 132 ins; 20 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10289.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10289/head:pull/10289

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


From omikhaltcova at openjdk.org  Tue Dec  6 21:33:10 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Tue, 6 Dec 2022 21:33:10 GMT
Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if
 TextAttribute.TRACKING is set. [v3]
In-Reply-To: <khcW69W3isqPpREWZ2tNGJZS8oRNT11tDaP-lhsOVks=.d8ed0594-2596-49f4-aa8d-e3f3b55f63b8@github.com>
References: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
 <khcW69W3isqPpREWZ2tNGJZS8oRNT11tDaP-lhsOVks=.d8ed0594-2596-49f4-aa8d-e3f3b55f63b8@github.com>
Message-ID: <F1cxfO4uvXnmIRBaSYsHApOdQM3INU-YAHJOey-cbLQ=.a6f347da-0bd4-4741-a46d-1b50c5bf3781@github.com>

On Tue, 6 Dec 2022 21:21:59 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks.
>> 
>> Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests:
>> `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font`
>
> Olga Mikhaltsova has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Added an automated test
>  - Fix for negative tracking and float
>  - Fix manual test

The following fixes are made:
- fixed the lines breaks calculation for the negative tracking values;
- included an epsilon for floating point operation;
- fixed the manual test according to the above comments;
- added a simple automated test similar to TestLineBreakWithFontSub.

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

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


From duke at openjdk.org  Tue Dec  6 21:33:33 2022
From: duke at openjdk.org (SWinxy)
Date: Tue, 6 Dec 2022 21:33:33 GMT
Subject: RFR: 4668290: unclear spec for Polygon.bounds field [v4]
In-Reply-To: <jjzwWZJPW8Essivj9svlhO-LScPQV_TlMoC0GGOVgMY=.b5d5ced5-77af-4ce9-8214-10c1cc0392cb@github.com>
References: <jjzwWZJPW8Essivj9svlhO-LScPQV_TlMoC0GGOVgMY=.b5d5ced5-77af-4ce9-8214-10c1cc0392cb@github.com>
Message-ID: <Q7ndb_4xR2uvA6kmCxuc2dNDqbh-W3Yy0NoB7ILQ4bo=.9b6c4996-77f0-478e-bf29-25c3721c292d@github.com>

> New documentation replaces the `This value can be null.`:
> 
> When created, {@link #invalidate() invalidated}, or {@link #reset() reset},
> this becomes {@code null}. To get out of the null state,
> {@link #getBounds()} called with {@link #npoints} being greater than
> {@code 0} will transfer into a non-null {@link Rectangle}.
> 
> 
> I think I've got the reason for why it can be `null` correct, but you never know.
> 
> In javax.swing.text.html.Map, I've replaced setting the field to null with the equivalent #invalidate(). This may mean we can make the field private in the future.

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

  dash

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10417/files
  - new: https://git.openjdk.org/jdk/pull/10417/files/9b6f7d91..c62b8066

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

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

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


From prr at openjdk.org  Tue Dec  6 21:50:06 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 Dec 2022 21:50:06 GMT
Subject: RFR: 4668290: unclear spec for Polygon.bounds field [v4]
In-Reply-To: <Q7ndb_4xR2uvA6kmCxuc2dNDqbh-W3Yy0NoB7ILQ4bo=.9b6c4996-77f0-478e-bf29-25c3721c292d@github.com>
References: <jjzwWZJPW8Essivj9svlhO-LScPQV_TlMoC0GGOVgMY=.b5d5ced5-77af-4ce9-8214-10c1cc0392cb@github.com>
 <Q7ndb_4xR2uvA6kmCxuc2dNDqbh-W3Yy0NoB7ILQ4bo=.9b6c4996-77f0-478e-bf29-25c3721c292d@github.com>
Message-ID: <eKPQsK_n7ztFWkbqtSdR3qsDe7hI_coxd2ApAZctk0M=.bf86a593-d80b-4202-b947-87f1effca748@github.com>

On Tue, 6 Dec 2022 21:33:33 GMT, SWinxy <duke at openjdk.org> wrote:

>> New documentation replaces the `This value can be null.`:
>> 
>> When created, {@link #invalidate() invalidated}, or {@link #reset() reset},
>> this becomes {@code null}. To get out of the null state,
>> {@link #getBounds()} called with {@link #npoints} being greater than
>> {@code 0} will transfer into a non-null {@link Rectangle}.
>> 
>> 
>> I think I've got the reason for why it can be `null` correct, but you never know.
>> 
>> In javax.swing.text.html.Map, I've replaced setting the field to null with the equivalent #invalidate(). This may mean we can make the field private in the future.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dash

Need the CSR

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

Marked as reviewed by prr (Reviewer).

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


From dcubed at openjdk.org  Tue Dec  6 22:04:54 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 6 Dec 2022 22:04:54 GMT
Subject: Integrated: 8298214: ProblemList
 java/util/concurrent/forkjoin/AsyncShutdownNow.java
In-Reply-To: <v-6QFccVbI1L8n-p53Dcl8OwaZ6kF89uW_8lH4tSHPo=.eab68505-a4b0-44e7-88d4-a5202b3f803f@github.com>
References: <v-6QFccVbI1L8n-p53Dcl8OwaZ6kF89uW_8lH4tSHPo=.eab68505-a4b0-44e7-88d4-a5202b3f803f@github.com>
Message-ID: <vC0HOYy7qv_xqYJP_d1NQFQWDkXO-IqWnI5Mr6mFwmc=.fb5a3367-fd85-456d-b339-9ec5f928e5c5@github.com>

On Tue, 6 Dec 2022 21:38:45 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 4 different tests:
> [JDK-8298214](https://bugs.openjdk.org/browse/JDK-8298214) ProblemList java/util/concurrent/forkjoin/AsyncShutdownNow.java
> [JDK-8298218](https://bugs.openjdk.org/browse/JDK-8298218) ProblemList java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java on windows-x64
> [JDK-8298220](https://bugs.openjdk.org/browse/JDK-8298220) ProblemList java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java on windows-x64
> [JDK-8298222](https://bugs.openjdk.org/browse/JDK-8298222) ProblemList java/awt/Mixing/AWT_Mixing/ViewportOverlapping.java on windows-x64

This pull request has now been integrated.

Changeset: 16a59018
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16a5901845de170e2e6f9ea13f19bb2a34c1da85
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8298214: ProblemList java/util/concurrent/forkjoin/AsyncShutdownNow.java
8298218: ProblemList java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java on windows-x64
8298222: ProblemList java/awt/Mixing/AWT_Mixing/ViewportOverlapping.java on windows-x64
8298220: ProblemList java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java on windows-x64

Reviewed-by: rriggs

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

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


From achung at openjdk.org  Tue Dec  6 22:11:23 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 6 Dec 2022 22:11:23 GMT
Subject: RFR: 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java
 fails with "No MouseReleased event on label!" [v3]
In-Reply-To: <wk0pRR6VBbTKg7aen8zWLYa9KWMEitnkmSkAuoctO9s=.b7ffd66d-a3b3-4fe5-8785-6eb4ab009d84@github.com>
References: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
 <wk0pRR6VBbTKg7aen8zWLYa9KWMEitnkmSkAuoctO9s=.b7ffd66d-a3b3-4fe5-8785-6eb4ab009d84@github.com>
Message-ID: <nYOGJoz39rH7SNBtAo3h2w2hSCcpyt0Yb0SUqsHzfQ4=.f9464d80-4f73-46f6-9dc7-5adba282d350@github.com>

On Mon, 5 Dec 2022 19:52:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Test was run on mac, windows, linux 50 times and passed after change
>> Before fix, test fails about once every 50 runs on linux and windows platforms
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8297296
>  - fixed imports, changed robot autodelay and added delay after creating gui
>  - changed robot autodelay to 250

After pulling newest changes test is failing again... looking into issue

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

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


From omikhaltcova at openjdk.org  Tue Dec  6 22:13:47 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Tue, 6 Dec 2022 22:13:47 GMT
Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if
 TextAttribute.TRACKING is set. [v4]
In-Reply-To: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
References: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
Message-ID: <ro0nBIasGCNN0ECjC1loz4atucyIepqltdwp7RY6mrg=.052b1711-6e90-4742-a51c-e66ddc53cb14@github.com>

> This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks.
> 
> Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests:
> `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font`

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

  Deleted trailing whitespaces, added new line at the end

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10289/files
  - new: https://git.openjdk.org/jdk/pull/10289/files/b1b4b146..c136384f

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

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

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


From omikhaltcova at openjdk.org  Tue Dec  6 22:19:24 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Tue, 6 Dec 2022 22:19:24 GMT
Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if
 TextAttribute.TRACKING is set. [v2]
In-Reply-To: <Ig_EkpsCEqsg7iQ9K3k0rTwEYffOAh7hXmuaOkIM1Dc=.eb388cf6-f186-4f9f-9532-13172b9e591a@github.com>
References: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
 <Twoosf6HJsMM0N8ZKcPPuu7OiieEDE1yzbnYwkdbE6s=.290f505b-a132-43ab-bb49-a3a0f2e8d5ae@github.com>
 <Ig_EkpsCEqsg7iQ9K3k0rTwEYffOAh7hXmuaOkIM1Dc=.eb388cf6-f186-4f9f-9532-13172b9e591a@github.com>
Message-ID: <thgR42Q38AL8jRk28q6KrH6sGXpzc9M83quNmwoXVxg=.e07d099b-8a63-4e15-80cf-4d773a1aab7f@github.com>

On Thu, 1 Dec 2022 20:16:19 GMT, Phil Race <prr at openjdk.org> wrote:

>> Olga Mikhaltsova has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix tracking for CJK, Arabic and Hebrew
>>  - Manual test
>
> test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTracking.java line 27:
> 
>> 25:   @test
>> 26:   @key headful
>> 27:   @bug 8165943
> 
> headful isn't needed on manual tests.
> 
> Also whilst you can keep this manual test, I still think an automated test that verifies tracking is making a difference to the advance should be provided.

fixed

> test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTracking.java line 76:
> 
>> 74:       Float regular = new Float(16.0);
>> 75:       Float big = new Float(24.0);
>> 76: 
> 
> LineBreakWithTracking.java:74: warning: [removal] Float(double) in Float has been deprecated and marked for removal
>       Float regular = new Float(16.0);
>                       ^
> LineBreakWithTracking.java:75: warning: [removal] Float(double) in Float has been deprecated and marked for removal
>       Float big = new Float(24.0);
> 
> Use Float.valueOf(float) instead

fixed

> test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTracking.java line 138:
> 
>> 136:     btn.addActionListener(new ActionListener(){
>> 137:       public void actionPerformed(ActionEvent e){
>> 138:         System.exit(0);
> 
> Do not call System.exit() in jtreg tests - even manual ones or ones that run in their own VM. 
> Instead dispose() the UI and then either let main() exit normally or throw RuntimeException() to indicate failure.
> 
> Also be sure that ALL exit paths clean up windows.
> 
> You may want to use PassFailJFrame.java to help you avoid writing the boilerplate and to get some of these things right
> 
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

fixed

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

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


From prr at openjdk.org  Tue Dec  6 22:29:04 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 Dec 2022 22:29:04 GMT
Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if
 TextAttribute.TRACKING is set. [v4]
In-Reply-To: <ro0nBIasGCNN0ECjC1loz4atucyIepqltdwp7RY6mrg=.052b1711-6e90-4742-a51c-e66ddc53cb14@github.com>
References: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
 <ro0nBIasGCNN0ECjC1loz4atucyIepqltdwp7RY6mrg=.052b1711-6e90-4742-a51c-e66ddc53cb14@github.com>
Message-ID: <C6LPMazgEogSybpOezVkTbxdOg-Jp-7M4SRP7YYckq4=.8bf7b457-fbca-404a-a2b5-cb6749c51f10@github.com>

On Tue, 6 Dec 2022 22:13:47 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks.
>> 
>> Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests:
>> `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font`
>
> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Deleted trailing whitespaces, added new line at the end

test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTracking.java line 50:

> 48: 
> 49:   private float textTracking = 0.0f;
> 50:   private static String fontName = "Bitstream Cyberbit";

Did you previously use this font ? I must have over-looked that.
Do not use fonts that aren't available on the OS .. no SQE person will ever install - or even know a test uses it - and JDK will just use Dialog instead and people will get confused over why their experience is different than yours.
And of course each OS (desktop) will have different fonts. Overall best to just pick a logical font. If you want to know if the font supports all your code points you can iterate over your text using Font.canDisplay(int codePoint)

I'll submit a test job using your automated test.

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

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


From omikhaltcova at openjdk.org  Tue Dec  6 23:09:09 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Tue, 6 Dec 2022 23:09:09 GMT
Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if
 TextAttribute.TRACKING is set. [v4]
In-Reply-To: <C6LPMazgEogSybpOezVkTbxdOg-Jp-7M4SRP7YYckq4=.8bf7b457-fbca-404a-a2b5-cb6749c51f10@github.com>
References: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
 <ro0nBIasGCNN0ECjC1loz4atucyIepqltdwp7RY6mrg=.052b1711-6e90-4742-a51c-e66ddc53cb14@github.com>
 <C6LPMazgEogSybpOezVkTbxdOg-Jp-7M4SRP7YYckq4=.8bf7b457-fbca-404a-a2b5-cb6749c51f10@github.com>
Message-ID: <dEhBmL6Hk5h71CAMVxqHEAjU9MNlKxTQHyxsRNNUAcI=.e539ee44-4de7-4d7c-a5f4-935c63b067dd@github.com>

On Tue, 6 Dec 2022 22:26:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Deleted trailing whitespaces, added new line at the end
>
> test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTracking.java line 50:
> 
>> 48: 
>> 49:   private float textTracking = 0.0f;
>> 50:   private static String fontName = "Bitstream Cyberbit";
> 
> Did you previously use this font ? I must have over-looked that.
> Do not use fonts that aren't available on the OS .. no SQE person will ever install - or even know a test uses it - and JDK will just use Dialog instead and people will get confused over why their experience is different than yours.
> And of course each OS (desktop) will have different fonts. Overall best to just pick a logical font. If you want to know if the font supports all your code points you can iterate over your text using Font.canDisplay(int codePoint)
> 
> I'll submit a test job using your automated test.

I noticed the usage of this font "Bitstream Cyberbit" in TestJustification.java that was added by you. I used the test string from there because it includes Latin, Arabic, CJK and Hebrew. "Bitstream Cyberbit" has all nessesary symbols used in the test string. At the moment I have no idea what font I can use instead.

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

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


From prr at openjdk.org  Tue Dec  6 23:23:59 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 Dec 2022 23:23:59 GMT
Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if
 TextAttribute.TRACKING is set. [v4]
In-Reply-To: <dEhBmL6Hk5h71CAMVxqHEAjU9MNlKxTQHyxsRNNUAcI=.e539ee44-4de7-4d7c-a5f4-935c63b067dd@github.com>
References: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
 <ro0nBIasGCNN0ECjC1loz4atucyIepqltdwp7RY6mrg=.052b1711-6e90-4742-a51c-e66ddc53cb14@github.com>
 <C6LPMazgEogSybpOezVkTbxdOg-Jp-7M4SRP7YYckq4=.8bf7b457-fbca-404a-a2b5-cb6749c51f10@github.com>
 <dEhBmL6Hk5h71CAMVxqHEAjU9MNlKxTQHyxsRNNUAcI=.e539ee44-4de7-4d7c-a5f4-935c63b067dd@github.com>
Message-ID: <duW7VkW0Dg9hyzP4mNkUIIUtR6Wo8ABK6I62jgWdNb8=.d10df657-5680-4bbc-b90d-3420a9d08be1@github.com>

On Tue, 6 Dec 2022 23:06:25 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTracking.java line 50:
>> 
>>> 48: 
>>> 49:   private float textTracking = 0.0f;
>>> 50:   private static String fontName = "Bitstream Cyberbit";
>> 
>> Did you previously use this font ? I must have over-looked that.
>> Do not use fonts that aren't available on the OS .. no SQE person will ever install - or even know a test uses it - and JDK will just use Dialog instead and people will get confused over why their experience is different than yours.
>> And of course each OS (desktop) will have different fonts. Overall best to just pick a logical font. If you want to know if the font supports all your code points you can iterate over your text using Font.canDisplay(int codePoint)
>> 
>> I'll submit a test job using your automated test.
>
> I noticed the usage of this font "Bitstream Cyberbit" in TestJustification.java that was added by you. I used the test string from there because it includes Latin, Arabic, CJK and Hebrew. "Bitstream Cyberbit" has all nessesary symbols used in the test string. At the moment I have no idea what font I can use instead.

I'm pretty sure it wasn't me who created that.
I may have updated it at some point (actually I suspect what you see is that I moved
it from closed to open) but that test was created by someone else 23 years ago (1999).
Different world back then. Likely it should not use the font either.

Your best best is to use Dialog. On all platforms where a decent set of fonts is installed then all those scripts will be supported by Dialog.

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

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


From itakiguchi at openjdk.org  Wed Dec  7 02:42:33 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Wed, 7 Dec 2022 02:42:33 GMT
Subject: RFR: 8298006: Build failure by maybe-uninitialized error on Linux
 s390x GCC8 [v2]
In-Reply-To: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
References: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
Message-ID: <X2ND1s9g5drte5iDoCySAc2b9gEDVQfS91IdtkS6KGU=.5a62fcda-da0a-4905-ad2d-52e4d50d7612@github.com>

> I changed GCC toolchain from GCC6 to GCC8 on SLES12SP5 Linux s390x.
> I could see following errors:
> 
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c: In function 'allocateRasterArray':
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:2944:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> ?????????????????????????????(((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])
> ?????????????????????????????????????????????????????????????????????~~~~^~~
> 
> 
> 
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:3129:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>                              (((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])
>                                                                      ~~~~^~~
> 
> 
> According to error messages,
> roff and loff may not be initialized.

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

  8298006: Build failure by maybe-uninitialized error on Linux s390x GCC8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11475/files
  - new: https://git.openjdk.org/jdk/pull/11475/files/f690c6d3..6abf8221

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

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

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


From psadhukhan at openjdk.org  Wed Dec  7 03:55:09 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 7 Dec 2022 03:55:09 GMT
Subject: RFR: 8244400: MenuItem may cache the size and did not update it when
 the screen DPI is changed
Message-ID: <-uTiC-hv_VAqzznPs2lyYbPFmjJ06PIGZZCbEfuwPgE=.6d97f3a5-bd81-4697-9299-0e7039e2d9c2@github.com>

The MenuItemLayoutHelper.clearUsedParentClientProperties must be called automatically when the DPI was changed. 
Workaround added in the test for this bug is removed.

CI tests are ok.

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

Commit messages:
 - 8244400: MenuItem may cache the size and did not update it when the screen DPI is changed
 - 8244400: MenuItem may cache the size and did not update it when the screen DPI is changed

Changes: https://git.openjdk.org/jdk/pull/11551/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11551&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8244400
  Stats: 19 lines in 2 files changed: 8 ins; 6 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11551.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11551/head:pull/11551

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


From itakiguchi at openjdk.org  Wed Dec  7 05:26:09 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Wed, 7 Dec 2022 05:26:09 GMT
Subject: RFR: 8298006: Build failure by maybe-uninitialized error on Linux
 s390x GCC8
In-Reply-To: <LgRN1k1cK5qKTfV9fP5OeMkpapZO6UN1eWpZNZqO5mc=.ed27e8a1-e1cb-42ef-a390-70b9035bd7e3@github.com>
References: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
 <G71lep3GeJwy4OMGWKrE7_kxeitheMbsrv0AdMNzJrc=.a5a8d15a-b2da-4999-80a9-6b8817cdac07@github.com>
 <LgRN1k1cK5qKTfV9fP5OeMkpapZO6UN1eWpZNZqO5mc=.ed27e8a1-e1cb-42ef-a390-70b9035bd7e3@github.com>
Message-ID: <ESbc2pI52t-86_D0hYy7gXp-PWDEAseIypll_HQ_8KU=.87ccf940-138c-4f9f-9c2b-355ec67f1155@github.com>

On Tue, 6 Dec 2022 18:24:17 GMT, Phil Race <prr at openjdk.org> wrote:

>>> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c: In function 'allocateRasterArray':
>>> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:2944:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>> ?????????????????????????????(((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])
>> 
>> That's weird. allocateRasterArray is at lines 2360-2575 .. so why are you seeing it at line 2944 ????
>
>> Thanks @prrace .
>> 
>> > That's weird. allocateRasterArray is at lines 2360-2575 .. so why are you seeing it at line 2944 ????
>> 
>> Ummm, I could not determine the reason...
>> 
>> I assume AddressSanitizer detected memory errors because of following 2 codes:
>> 
>> https://github.com/openjdk/jdk/blob/1e468320dc6e495343dbdf392cbcbda79672c7ad/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c#L2937
>> 
>> 
>> https://github.com/openjdk/jdk/blob/1e468320dc6e495343dbdf392cbcbda79672c7ad/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c#L3118
>> 
>> So I'd like to put `memset()` on these parts.
>> 
>> But I checked `if` and `else` blocks on above part. These are exactly the same.
>> 
>> https://github.com/openjdk/jdk/blob/1e468320dc6e495343dbdf392cbcbda79672c7ad/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c#L2937-L2965
>> 
>> 
>> https://github.com/openjdk/jdk/blob/1e468320dc6e495343dbdf392cbcbda79672c7ad/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c#L3118-L3153
>> 
>> I tried to modify from `if .. else` block to flat. AddressSanitizer did not detect memory error.
>> 
>> Could you give me any advice ?
> 
> Oh you are running a tool to find these issues ? I thought it was supposed to be a build failure ?
> Or are you running the tool to try to understand the build failure.
> Tools are not always right in my experience.
> I think there's just as much chance as both being false positives as both being correct.
> I think at some point the tools arm-wave that this could be a problem but it is not provable. 
> As Magnus pointed out "newer" compilers aren't complaining here. 
> 
> I don't know what kind of advice you are seeking. If you are asking me to somehow do better than the tools .. well I'd say its a whole lot easier to just memset these to zero. Zero may not be the correct offset either .. but it should be safer.

Hello @prrace .
I applied minimum changes which is reported by SLES12's GCC8.

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

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


From tr at openjdk.org  Wed Dec  7 05:56:07 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 7 Dec 2022 05:56:07 GMT
Subject: RFR: 4365952: Cannot disable JFileChooser
Message-ID: <0Pc6eSRN_L1pKaaKHb3-af86bTOyMn6oJ9wfC1LOvjA=.a6aa5a9e-58bb-4ca3-847c-0d7ad1473faf@github.com>

Disable functionality not working for JFileChooser. `public void setEnabled(boolean enabled)` functionality is overridden in JFileChooser class which enable/disable each sub-component of FileChooser. 
The added functionality is tested in mach5 and no regression found. The fix includes automated test which clicks _home_ directory and then compares which default selectedDirectory to check if JFileChooser is disabled. This is tested in mach5 for all platforms with multiple test runs.

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

Commit messages:
 - Fix + Regression Test

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

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


From kizune at openjdk.org  Wed Dec  7 06:50:59 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 7 Dec 2022 06:50:59 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip [v2]
In-Reply-To: <6Y4AZanzqQvl5-du1LLmS3VG9tLYTbaQr1aRWx7XV3U=.7b428208-eb6e-4a94-ba34-2e22349201fd@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
 <6Y4AZanzqQvl5-du1LLmS3VG9tLYTbaQr1aRWx7XV3U=.7b428208-eb6e-4a94-ba34-2e22349201fd@github.com>
Message-ID: <cnNmiq1Lqi1iCQ8FHZWlIfVS7gFiMks4u05PrRzo2o0=.aca5793a-832e-47cf-a639-50569fd0feeb@github.com>

On Sun, 4 Dec 2022 22:17:55 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Add try/catch clause to ignore an exception since it is harmless for we isolated
>> the massge data before passing it ro processor.
>> Add test case.
>
> Alexander Zuev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Got rid of the try/catch and using the proper per-case data length
>    analysis.
>  - Merge branch 'master' into JDK-8282578
>  - Merge branch 'master' of https://github.com/azuev-java/jdk into JDK-8282578
>  - Merge branch 'master'
>  - 8282578: AIOOBE in javax.sound.sampled.Clip
>    
>    Surround SysEx message processing block with try/catch allowing MIDI subsystem to
>    attempt to ingest the rest of the file.
>    
>    Added test case.

@azvegint Can you please take a look?

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

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


From duke at openjdk.org  Wed Dec  7 07:42:13 2022
From: duke at openjdk.org (Yichen Yan)
Date: Wed, 7 Dec 2022 07:42:13 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17]
In-Reply-To: <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
Message-ID: <aAl1JS-JF6JXpXdiFyE7bOgOe46Y3pvApgtseKQSB_M=.45dcf873-8366-4a11-bc02-8c3d692e0a23@github.com>

On Tue, 29 Nov 2022 07:57:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment for snprintf_checked

Any update on this? xcode 14 build has been broken for a while.

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

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


From psadhukhan at openjdk.org  Wed Dec  7 07:43:08 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 7 Dec 2022 07:43:08 GMT
Subject: RFR: 4365952: Cannot disable JFileChooser
In-Reply-To: <0Pc6eSRN_L1pKaaKHb3-af86bTOyMn6oJ9wfC1LOvjA=.a6aa5a9e-58bb-4ca3-847c-0d7ad1473faf@github.com>
References: <0Pc6eSRN_L1pKaaKHb3-af86bTOyMn6oJ9wfC1LOvjA=.a6aa5a9e-58bb-4ca3-847c-0d7ad1473faf@github.com>
Message-ID: <AVxYIW81Q83k0QEvBOctgqafCkRPZu2WDllFW_MlV5U=.f1621855-515d-4181-b499-d2ec4cdbeff4@github.com>

On Wed, 7 Dec 2022 05:48:57 GMT, Tejesh R <tr at openjdk.org> wrote:

> Disable functionality not working for JFileChooser. `public void setEnabled(boolean enabled)` functionality is overridden in JFileChooser class which enable/disable each sub-component of FileChooser. 
> The added functionality is tested in mach5 and no regression found. The fix includes automated test which clicks _home_ directory and then compares which default selectedDirectory to check if JFileChooser is disabled. This is tested in mach5 for all platforms with multiple test runs.

Marked as reviewed by psadhukhan (Reviewer).

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

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


From xuelei at openjdk.org  Wed Dec  7 08:14:07 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 7 Dec 2022 08:14:07 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17]
In-Reply-To: <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
Message-ID: <yTZnKEPhgKZR7kJMf-ZJEC40yM1dFCHdTtfGgS6ezHI=.aee5aa13-7a92-4de1-a54d-89eef6fb2351@github.com>

On Tue, 29 Nov 2022 07:57:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment for snprintf_checked

Could I have the last update reviewed?

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

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


From mbaesken at openjdk.org  Wed Dec  7 08:45:01 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 7 Dec 2022 08:45:01 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <by8PjHk056eNArwawtCAKY29CJNuEHDkGuDR3DeoeNE=.2c31ba49-5c88-477d-98a7-5b10dc51d702@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
 <by8PjHk056eNArwawtCAKY29CJNuEHDkGuDR3DeoeNE=.2c31ba49-5c88-477d-98a7-5b10dc51d702@github.com>
Message-ID: <kdOQP_mWI4xmIwFRQXP46G_ZZPUQLGVwFZQSmWL3T4k=.5c28947e-a124-4f62-a2db-87018f6a5830@github.com>

On Tue, 6 Dec 2022 20:40:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The existing code more obviously handles memory deallocation.

Thomas Stuefe suggested something like this


JNU_CHECK_EXCEPTION_DO(env, action)
JNU_CHECK_EXCEPTION_DO_AND_RETURN(env, action, retval)


usage example: 
`JNU_CHECK_EXCEPTION_DO(env, { free(tab); })`

This would make the free-ing more clear, and should also work for 2 free-calls, we a have places like this in the codebase. What do you think about this?

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

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


From lbourges at openjdk.org  Wed Dec  7 08:49:04 2022
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 7 Dec 2022 08:49:04 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17]
In-Reply-To: <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
Message-ID: <cz_T0QQD9hZhfJK6lju8jzPJ1wWrrtmTzDftMcje9qQ=.bc2f89ff-da8c-48fd-805d-c5337d6571af@github.com>

On Tue, 29 Nov 2022 07:57:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment for snprintf_checked

I will have a look, I am affected too

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

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


From mbaesken at openjdk.org  Wed Dec  7 08:54:29 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 7 Dec 2022 08:54:29 GMT
Subject: RFR: JDK-8298093: improve cleanup and error handling of
 awt_parseColorModel in awt_parseImage.c [v3]
In-Reply-To: <LJXA0GoYlzD_v4Gb9N0ytaim25_su2y8hAyWhx0hGKI=.5087cce4-07f1-446c-a389-d65334315f73@github.com>
References: <LJXA0GoYlzD_v4Gb9N0ytaim25_su2y8hAyWhx0hGKI=.5087cce4-07f1-446c-a389-d65334315f73@github.com>
Message-ID: <2Dhk_nsd_PNixhUjUswA6uxE05Yn2hCHHLZX94DgDXA=.7f4c436c-0ab2-4037-a600-14c2b23ef830@github.com>

> The cleanup and error handling in function awt_parseColorModel in awt_parseImage.c could be improved.

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

  small adjustment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11508/files
  - new: https://git.openjdk.org/jdk/pull/11508/files/9b9f56ea..e7dee2a7

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

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

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


From mbaesken at openjdk.org  Wed Dec  7 08:54:30 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 7 Dec 2022 08:54:30 GMT
Subject: RFR: JDK-8298093: improve cleanup and error handling of
 awt_parseColorModel in awt_parseImage.c [v2]
In-Reply-To: <WGbj-wl9h73Kar7V_yDeHXPWvYncAE_SfB5s-5ThwZ0=.983c2ef2-34b6-40c2-a13f-b44d70322e47@github.com>
References: <LJXA0GoYlzD_v4Gb9N0ytaim25_su2y8hAyWhx0hGKI=.5087cce4-07f1-446c-a389-d65334315f73@github.com>
 <WGbj-wl9h73Kar7V_yDeHXPWvYncAE_SfB5s-5ThwZ0=.983c2ef2-34b6-40c2-a13f-b44d70322e47@github.com>
Message-ID: <IeGTRHru0fDTKP9CytYJ6actR_1gdRkkWGw7ozQGepQ=.1fde7429-3860-4fa4-a72f-551d1d90fa28@github.com>

On Tue, 6 Dec 2022 09:52:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The cleanup and error handling in function awt_parseColorModel in awt_parseImage.c could be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move freeing into awt_parseColorModel

Hi Phil, are you fine with the latest version ?

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

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


From serb at openjdk.org  Wed Dec  7 09:23:15 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Dec 2022 09:23:15 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds [v2]
In-Reply-To: <B1NZU42rDKaZPwvOEcv_mjwxPsXKOoKKZA4JlsBc3Ck=.75ce53cf-ac17-4eb5-b65d-4a7b62f6f485@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
 <CUGEHLhq9stsvqPxzj58o9ngHDcGQBlOiHMyNqKfh48=.28a35c51-72ac-463c-8392-2037ea9c02db@github.com>
 <M0xzCzMOfO1Uk1FGaaF5v65YOx1HR5YIGmrsM5IE67A=.a8c89539-991b-4910-b5bb-1f427fa75099@github.com>
 <B1NZU42rDKaZPwvOEcv_mjwxPsXKOoKKZA4JlsBc3Ck=.75ce53cf-ac17-4eb5-b65d-4a7b62f6f485@github.com>
Message-ID: <o2BJuYzPUEwRvdID4INEHQQhXl2jhvKyHUtZgIZYNDE=.c5971482-50fc-455c-8464-e2e70bc92b44@github.com>

On Tue, 6 Dec 2022 10:20:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @mrserb Since the current test fix works on other platforms (windows, mac) other than linux, can the other platforms be removed and the test be problemlisted only on linux platform until the product bug is fixed on linux then? Additionally the test was failing on Mac-ARM due to color mismatch that was fixed by adding tolerance.
>
> It is still unclear why tolerance is needed in this test and is not needed in the CheckCommonColors?

On Windows, it does not work as well if a non-accelerated java2d pipeline is selected. You can test that by using this option:
`-Dsun.java2d.d3d=false`

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

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


From serb at openjdk.org  Wed Dec  7 09:38:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Dec 2022 09:38:51 GMT
Subject: Integrated: 4677581: ColorModel.getComponentSize()-wrong conditions
 for ArrayIndexOutOfBoundsExceptio
In-Reply-To: <C2YzdBBLdjaVXPsMxf5pkLLMX0Y3E4__xTIvlZldeOA=.bb8eb3c6-8a93-42f5-9218-0da6da5bca16@github.com>
References: <C2YzdBBLdjaVXPsMxf5pkLLMX0Y3E4__xTIvlZldeOA=.bb8eb3c6-8a93-42f5-9218-0da6da5bca16@github.com>
Message-ID: <xLNWi6wvo8-EMLsh9WOJxvaMxw_jaSBsj9TQE8Z7-0k=.9380f7d8-4df9-4135-9a7a-5cc2fe86511f@github.com>

On Fri, 2 Dec 2022 03:34:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The specification for `java.awt.image.ColorModel#getComponentSize(int)` states that an ArrayIndexOutOfBoundsException is thrown "if componentIdx is greater than the number of components or less than zero". The condition should actually be "if componentIdx is greater than OR EQUAL TO the number of components or less than zero."

This pull request has now been integrated.

Changeset: 5a3439db
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a3439db9fef3e54650df4019e31311b60a0ec1d
Stats:     57 lines in 2 files changed: 54 ins; 1 del; 2 mod

4677581: ColorModel.getComponentSize()-wrong conditions for ArrayIndexOutOfBoundsExceptio

Reviewed-by: prr

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

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


From stuefe at openjdk.org  Wed Dec  7 09:41:18 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Dec 2022 09:41:18 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17]
In-Reply-To: <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
Message-ID: <wtfe3m7FrVWssfUYna5S0oWNL6Xhz4UQRb-4V2tvvmc=.3356deec-bbe2-4372-ac3a-2cdc620fae67@github.com>

On Tue, 29 Nov 2022 07:57:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment for snprintf_checked

I looked through all the code and found only some minor issues. I would appreciate more eyes on this, though.

I still think this would have been less work (for author and reviewers) had we converted the code to stringStream right away in the hotspot. stringStream takes care of a lot of this boilerplate stuff.

src/hotspot/os/bsd/attachListener_bsd.cpp line 260:

> 258:   // name ("load", "datadump", ...), and <arg> is an argument
> 259:   int expected_str_count = 2 + AttachOperation::arg_count_max;
> 260:   const int max_len = (ver_str_len + 1) + (AttachOperation::name_length_max + 1) +

This makes `max_len` a runtime variable, before it was a compile time constant. Below, we use it to create the buf array. IIRC creating an array with a variable runtime length is a non-standard compiler extension. I am surprised this even builds.

src/hotspot/share/adlc/output_c.cpp line 46:

> 44:   va_end(args);
> 45:   assert(result >= 0, "snprintf error");
> 46:   assert(static_cast<size_t>(result) < len, "snprintf truncated");

Question, what is this assert? The standard CRT assert? Will it fire always, or just in debug?

src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 311:

> 309:   for (int i = 0; i < len ; i++) {
> 310:     VMStructEntry vmField = JVMCIVMStructs::localHotSpotVMStructs[i];
> 311:     const size_t name_buf_size = strlen(vmField.typeName) + strlen(vmField.fieldName) + 3 /* "::" */;

nit, could you make this "+ 2 + 1" instead? That makes it a bit clearer that the last byte is for \0

src/hotspot/share/runtime/os.cpp line 102:

> 100: }
> 101: 
> 102: int os::snprintf_checked(char* buf, size_t len, const char* fmt, ...) {

Can you please assert for buffer len > 0 and < some reasonable max, e.g. 1 gb? Protects us against neg overflows and other errors.

src/hotspot/share/runtime/os.cpp line 108:

> 106:   va_end(args);
> 107:   assert(result >= 0, "os::snprintf error");
> 108:   assert(static_cast<size_t>(result) < len, "os::snprintf truncated");

Can you please provide a printout for the truncated string? Proposal:

```assert(static_cast<size_t>(result) < len, "os::snprintf truncated ("%.200s...")", buf);```

src/hotspot/share/utilities/utf8.cpp line 227:

> 225:     } else {
> 226:       if (p + 6 >= end) break;      // string is truncated
> 227:       os::snprintf_checked(p, 7, "\\u%04x", c);  // counting terminating zero in

I had to think a while until I was sure this is correct :-) 
We are sure that c can never be > 0xFFFFFF (6 digits), right? But if that is false, code had been wrong before too.

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

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


From serb at openjdk.org  Wed Dec  7 09:51:11 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Dec 2022 09:51:11 GMT
Subject: RFR: 8244400: MenuItem may cache the size and did not update it
 when the screen DPI is changed
In-Reply-To: <-uTiC-hv_VAqzznPs2lyYbPFmjJ06PIGZZCbEfuwPgE=.6d97f3a5-bd81-4697-9299-0e7039e2d9c2@github.com>
References: <-uTiC-hv_VAqzznPs2lyYbPFmjJ06PIGZZCbEfuwPgE=.6d97f3a5-bd81-4697-9299-0e7039e2d9c2@github.com>
Message-ID: <AhI-U6NSoe8pk5jg__SuVk4lmb4A-u81e7FKlIte62c=.2a8a3913-0662-456d-a00b-fffc52e8452e@github.com>

On Wed, 7 Dec 2022 03:48:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The MenuItemLayoutHelper.clearUsedParentClientProperties must be called automatically when the DPI was changed. 
> Workaround added in the test for this bug is removed.
> 
> CI tests are ok.

test/jdk/javax/swing/GraphicsConfigNotifier/StalePreferredSize.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved.

The date in the `BasicMenuItemUI.java` can be updated as well.

test/jdk/javax/swing/GraphicsConfigNotifier/StalePreferredSize.java line 99:

> 97:                 System.out.println("Skipped Motif");
> 98:                 continue;
> 99:             }

You do not need to ignore it since it is still supported and seems to work.

test/jdk/javax/swing/GraphicsConfigNotifier/StalePreferredSize.java line 187:

> 185:                 if (component instanceof JMenuItem) {
> 186:                     // TODO JDK-8244400
> 187:                     MenuItemLayoutHelper.clearUsedParentClientProperties((JMenuItem)component);

This call was the only reason to have " * @modules java.desktop/sun.swing" at the header of the test.

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

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


From serb at openjdk.org  Wed Dec  7 09:58:09 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Dec 2022 09:58:09 GMT
Subject: RFR: 8296198: JFileChooser throws InternalError
 java.lang.InternalError with Windows shortcuts [v2]
In-Reply-To: <FtfOKAoW1DejIqGkAO3Pajy1HH_GPSlS0DISIyp86CA=.a387a0a2-c92e-4543-9a7a-31c13edf3aa7@github.com>
References: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>
 <FtfOKAoW1DejIqGkAO3Pajy1HH_GPSlS0DISIyp86CA=.a387a0a2-c92e-4543-9a7a-31c13edf3aa7@github.com>
Message-ID: <hLVbuqJvouYWM6LHiBpjRVPvRaDdeZMZFYVSpfZEM78=.6f9d9776-e105-4170-ae7d-12761a503566@github.com>

On Tue, 6 Dec 2022 11:59:17 GMT, Tejesh R <tr at openjdk.org> wrote:

>> When `JFileChooser` uses custom `FileSystemView`, traversing to link/shortcut to a folder throw `InternalError java.lang.InternalError ` in Windows. The issue found out to be in BasicFileChooserUI class which was unable to resolve the link path during directory setting. The `UsesShellFolder` check expects the FileSystemView to be of WindowsFileSystemView, which fails when custom FileSystemView is used.
>> The fix includes resolving the link folder when custom File System View is used and has manual test. (Fix is test in CI system and no regression caused).
>
> 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 serb (Reviewer).

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

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


From psadhukhan at openjdk.org  Wed Dec  7 10:11:36 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 7 Dec 2022 10:11:36 GMT
Subject: RFR: 8244400: MenuItem may cache the size and did not update it
 when the screen DPI is changed [v2]
In-Reply-To: <-uTiC-hv_VAqzznPs2lyYbPFmjJ06PIGZZCbEfuwPgE=.6d97f3a5-bd81-4697-9299-0e7039e2d9c2@github.com>
References: <-uTiC-hv_VAqzznPs2lyYbPFmjJ06PIGZZCbEfuwPgE=.6d97f3a5-bd81-4697-9299-0e7039e2d9c2@github.com>
Message-ID: <QbvH43-Rtw22I1EybFpvk4cRsMTSQBvkWFZB_sCBFAg=.b0bf829a-630e-44bc-b7e5-5205a89f5bff@github.com>

> The MenuItemLayoutHelper.clearUsedParentClientProperties must be called automatically when the DPI was changed. 
> Workaround added in the test for this bug is removed.
> 
> CI tests are ok.

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

  Review update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11551/files
  - new: https://git.openjdk.org/jdk/pull/11551/files/98ec1e5d..51feefa5

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

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

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


From psadhukhan at openjdk.org  Wed Dec  7 10:13:17 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 7 Dec 2022 10:13:17 GMT
Subject: RFR: 8244400: MenuItem may cache the size and did not update it
 when the screen DPI is changed [v2]
In-Reply-To: <AhI-U6NSoe8pk5jg__SuVk4lmb4A-u81e7FKlIte62c=.2a8a3913-0662-456d-a00b-fffc52e8452e@github.com>
References: <-uTiC-hv_VAqzznPs2lyYbPFmjJ06PIGZZCbEfuwPgE=.6d97f3a5-bd81-4697-9299-0e7039e2d9c2@github.com>
 <AhI-U6NSoe8pk5jg__SuVk4lmb4A-u81e7FKlIte62c=.2a8a3913-0662-456d-a00b-fffc52e8452e@github.com>
Message-ID: <3aFE2O6L6E9PPnbErJagiIbaySaO8QNo4_fBv77S0Js=.c7faf30d-ac72-497d-89a0-36bfd9b9d9ae@github.com>

On Wed, 7 Dec 2022 09:45:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review update
>
> test/jdk/javax/swing/GraphicsConfigNotifier/StalePreferredSize.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved.
> 
> The date in the `BasicMenuItemUI.java` can be updated as well.

ok

> test/jdk/javax/swing/GraphicsConfigNotifier/StalePreferredSize.java line 99:
> 
>> 97:                 System.out.println("Skipped Motif");
>> 98:                 continue;
>> 99:             }
> 
> You do not need to ignore it since it is still supported and seems to work.

Yes, I "do not need to" but I chose to as it is deprecated and marked for removal and in future, if it starts to fail, then it will be a maintenance headache so I chose to ignore from now itself. Also, it's a heavy duty test and takes time so unnecessary it will consume more time in CI systems (which are heavily loaded anyways) for a L&F which we dont care about much nowadays!

> test/jdk/javax/swing/GraphicsConfigNotifier/StalePreferredSize.java line 187:
> 
>> 185:                 if (component instanceof JMenuItem) {
>> 186:                     // TODO JDK-8244400
>> 187:                     MenuItemLayoutHelper.clearUsedParentClientProperties((JMenuItem)component);
> 
> This call was the only reason to have " * @modules java.desktop/sun.swing" at the header of the test.

ok..removed..

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

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


From serb at openjdk.org  Wed Dec  7 10:16:46 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Dec 2022 10:16:46 GMT
Subject: RFR: 8298083: The
 "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working
Message-ID: <E_b75HPvqrnncD1Khq4tEIWWOweZmFtWBck2Gv7hYFs=.59719e7e-341a-4958-bc69-9ddb3c3c9eea@github.com>

We have two types of properties in Swing, the "basics": were implemented a long time ago. Some of that properties are tested by the bug4314194 test. And other properties implemented as part of the Synth L&F, and based on it - Nimbus/GTK. Attempt to fix the issue reported by bug4314194 added support of two "basic" options to the Nimbus/GTK but at the same time broke the Synth/Nimbus properties. It is unclear what is the root cause and how these properties should work together(should they? I assume each "basic"/"synth" should support its own) I suggest to revert the changes in 20 to prevent the regression and rethink the solution later.

In short, this is a request to revert the next fixes:
 * https://bugs.openjdk.org/browse/JDK-8075916 - for some reason broke the Synth/Nimbus properties
 * https://bugs.openjdk.org/browse/JDK-8295006 - This uses the same approach as the fix above
The next two issues created to redo both:
 * https://bugs.openjdk.org/browse/JDK-8298149
 * https://bugs.openjdk.org/browse/JDK-8298153

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

Commit messages:
 - the new JBS bugID
 - Revert "8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194."
 - 8298083: The "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working

Changes: https://git.openjdk.org/jdk/pull/11531/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11531&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298083
  Stats: 52 lines in 4 files changed: 18 ins; 21 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/11531.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11531/head:pull/11531

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


From serb at openjdk.org  Wed Dec  7 10:17:09 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Dec 2022 10:17:09 GMT
Subject: RFR: 8244400: MenuItem may cache the size and did not update it
 when the screen DPI is changed [v2]
In-Reply-To: <3aFE2O6L6E9PPnbErJagiIbaySaO8QNo4_fBv77S0Js=.c7faf30d-ac72-497d-89a0-36bfd9b9d9ae@github.com>
References: <-uTiC-hv_VAqzznPs2lyYbPFmjJ06PIGZZCbEfuwPgE=.6d97f3a5-bd81-4697-9299-0e7039e2d9c2@github.com>
 <AhI-U6NSoe8pk5jg__SuVk4lmb4A-u81e7FKlIte62c=.2a8a3913-0662-456d-a00b-fffc52e8452e@github.com>
 <3aFE2O6L6E9PPnbErJagiIbaySaO8QNo4_fBv77S0Js=.c7faf30d-ac72-497d-89a0-36bfd9b9d9ae@github.com>
Message-ID: <fIvIDsjjLISOJXBl15bUc_RuTkXvGdyX1FIlpNvXx0o=.7c6a8fef-09b4-4d12-9d2b-575402cb8418@github.com>

On Wed, 7 Dec 2022 10:10:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/GraphicsConfigNotifier/StalePreferredSize.java line 99:
>> 
>>> 97:                 System.out.println("Skipped Motif");
>>> 98:                 continue;
>>> 99:             }
>> 
>> You do not need to ignore it since it is still supported and seems to work.
>
> Yes, I "do not need to" but I chose to as it is deprecated and marked for removal and in future, if it starts to fail, then it will be a maintenance headache so I chose to ignore from now itself. Also, it's a heavy duty test and takes time so unnecessary it will consume more time in CI systems (which are heavily loaded anyways) for a L&F which we dont care about much nowadays!

But still, it is supported, and if it starts to fail before removal we will need to fix it. That also complicates the possibility to backport fix.

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

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


From serb at openjdk.org  Wed Dec  7 10:30:28 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Dec 2022 10:30:28 GMT
Subject: RFR: 4365952: Cannot disable JFileChooser
In-Reply-To: <0Pc6eSRN_L1pKaaKHb3-af86bTOyMn6oJ9wfC1LOvjA=.a6aa5a9e-58bb-4ca3-847c-0d7ad1473faf@github.com>
References: <0Pc6eSRN_L1pKaaKHb3-af86bTOyMn6oJ9wfC1LOvjA=.a6aa5a9e-58bb-4ca3-847c-0d7ad1473faf@github.com>
Message-ID: <qL0vp6t4z-C4FkX8nnZHeffTmIw2yyTQQ6toL2Sb1Lg=.f629cd98-3ccb-45da-8c90-8f8b13ce5300@github.com>

On Wed, 7 Dec 2022 05:48:57 GMT, Tejesh R <tr at openjdk.org> wrote:

> Disable functionality not working for JFileChooser. `public void setEnabled(boolean enabled)` functionality is overridden in JFileChooser class which enable/disable each sub-component of FileChooser. 
> The added functionality is tested in mach5 and no regression found. The fix includes automated test which clicks _home_ directory and then compares which default selectedDirectory to check if JFileChooser is disabled. This is tested in mach5 for all platforms with multiple test runs.

src/java.desktop/share/classes/javax/swing/JFileChooser.java line 420:

> 418: 
> 419:     @Override
> 420:     public void setEnabled(boolean enabled) {

Can you please check why a similar example using JFrame and button works fine, but the JFileChooser does not work?

        JFrame frame = new JFrame();
        JButton button = new JButton("1234567890");
        frame.add(button);
        frame.setVisible(true);
        frame.setEnabled(false);
        boolean enabled = button.isEnabled();
        System.out.println("enabled = " + enabled);

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

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


From abhiscxk at openjdk.org  Wed Dec  7 10:33:10 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 7 Dec 2022 10:33:10 GMT
Subject: RFR: 8296198: JFileChooser throws InternalError
 java.lang.InternalError with Windows shortcuts [v2]
In-Reply-To: <FtfOKAoW1DejIqGkAO3Pajy1HH_GPSlS0DISIyp86CA=.a387a0a2-c92e-4543-9a7a-31c13edf3aa7@github.com>
References: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>
 <FtfOKAoW1DejIqGkAO3Pajy1HH_GPSlS0DISIyp86CA=.a387a0a2-c92e-4543-9a7a-31c13edf3aa7@github.com>
Message-ID: <Tu4Cne-xO28mAYdlsqDZ25pkZE86X6NjdiYZiEFp_hQ=.e5e261d0-faff-40a7-9e0d-509737bf08fa@github.com>

On Tue, 6 Dec 2022 11:59:17 GMT, Tejesh R <tr at openjdk.org> wrote:

>> When `JFileChooser` uses custom `FileSystemView`, traversing to link/shortcut to a folder throw `InternalError java.lang.InternalError ` in Windows. The issue found out to be in BasicFileChooserUI class which was unable to resolve the link path during directory setting. The `UsesShellFolder` check expects the FileSystemView to be of WindowsFileSystemView, which fails when custom FileSystemView is used.
>> The fix includes resolving the link folder when custom File System View is used and has manual test. (Fix is test in CI system and no regression caused).
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review Comments

Verified the test. Looks good to me.

test/jdk/javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java line 35:

> 33: import java.util.Arrays;
> 34: 
> 35: import javax.swing.*;

The import's can be specific.

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

Marked as reviewed by abhiscxk (Author).

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


From abhiscxk at openjdk.org  Wed Dec  7 10:36:14 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 7 Dec 2022 10:36:14 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel
Message-ID: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>

In case of GTK LAF, the current selected element was not visible due to arrowbutton is rendered in entire display area of Combobox.

The proposed fix is to set the squareButton property of combobox to false so that the arrowbutton didn't take entire combobox display area for rendering. The getMinimumSize method is overridden in SynthComboBoxUI to consider arrowbutton insets for combobox minimum size. 

The JCK tests mentioned in JBS seems fine with the fix. An automated test case is implemented to test in Nimbus and GTK LAF.

When swing tests are run with LAF set to Nimbus and GTK LAF, few test failures observed. 

Although CI jobs looks ok with tests run in their default set LAFs.

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

Commit messages:
 - Combobox componnet rendering fix

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

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


From bourges.laurent at gmail.com  Wed Dec  7 10:37:26 2022
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 7 Dec 2022 11:37:26 +0100
Subject: Quick fix for openjdk20
Message-ID: <CAKjRUT4muRHUfd8zA0k8OpWLJJLtFmgfBwHA08njYPL3g4U8fA@mail.gmail.com>

Hi,

For years, JetBrains Runtime uses a larger render queue buffer size (32kb
to 6,400,000 bytes) in production, as it boosted many accelerated
pipelines: d3d, ogl, metal :
~ 10 to 20% on large fills...

JBR RenderQueue:
https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75

JDK RenderQueue:
https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75

I want to propose such quick fix in openjdk20 today, as a 1-line fix.

/** The size of the underlying buffer, in bytes. */
private static final int BUFFER_SIZE = 6400000;

To ensure a smooth transition, I prefer introducing a new
sun.java2d.render.queue system property to increase the default (32kb)
buffer capacity:

See in marlin:
https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78

So here is my current proposal:
[[[
/** The size of the underlying buffer, in bytes. */
private static final int BUFFER_SIZE;
static {
// Default 32K is too small for high-end GPU:
BUFFER_SIZE = align(getInteger("sun.java2d.render.bufferSize", 32 * 1024,
32 * 1024, 16 * 1024 * 1024), 1024);
// System.out.println("RenderQueue: sun.java2d.render.bufferSize = " +
BUFFER_SIZE);
}

    // system property utilities
    public static int getInteger(final String key, final int def,
                                 final int min, final int max)
    {
        final String property = AccessController.doPrivileged(
                                    new GetPropertyAction(key));

        int value = def;
        if (property != null) {
            try {
                value = Integer.decode(property);
            } catch (NumberFormatException e) {
                System.out.println("Invalid integer value for " + key + " =
" + property);
            }
        }

        // check for invalid values
        if ((value < min) || (value > max)) {
            System.out.println("Invalid value for " + key + " = " + value
                    + "; expected value in range[" + min + ", " + max + "]
!");
            value = def;
        }
        return value;
    }

    protected static int align(final int val, final int norm) {
        final int ceil = (int)Math.ceil( ((float) val) / norm);
        return ceil * norm;
    }
]]]

Would you accept such late change for openjdk20 ?

Cheers,
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221207/7895a769/attachment.htm>

From serb at openjdk.org  Wed Dec  7 10:44:11 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Dec 2022 10:44:11 GMT
Subject: RFR: 8298240: Replace the usage of ImageLayoutException by the
 CMMException
Message-ID: <MugzKoEie2il8Rn7Tp4oLM0N8zg-QtGh1gsQmPPX-lE=.66e63bba-76ef-4425-8aa6-6a2350d77c24@github.com>

ImageLayoutException is used to report any issues with image layout calculation. But since we cannot throw the unspecified exception to the application, all usages of ImageLayoutException are wrapped by the CMMException. And now if such CMMException occurs we have lost at what point the initial exception was raised.

We can pass some additional data around, but it looks like we can just delete the ImageLayoutException and use CMMException instead. 

Additionally:
 * The `public` keyword is removed in a few places if not needed.
 * The PT_XX flags are updated to make it clearly visible how they are related.

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

Commit messages:
 - Simplify rge PT_XXX and replace public
 - delete ImageLayoutException

Changes: https://git.openjdk.org/jdk/pull/11552/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11552&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298240
  Stats: 175 lines in 2 files changed: 13 ins; 79 del; 83 mod
  Patch: https://git.openjdk.org/jdk/pull/11552.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11552/head:pull/11552

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


From serb at openjdk.org  Wed Dec  7 10:54:12 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Dec 2022 10:54:12 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus
In-Reply-To: <2XePfo1gtNAWJvM5ECfg8Vkp8VObLOyQmM8WkQDiabM=.43f5d635-9352-4cc8-b9d9-e76aa710064d@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <e7ITSsOpcKtlC2bJNzIM3PFCUcoRZdfRi0mr1JxsgFE=.f37d4fe5-6a07-427c-b87f-b0ba50efcc6c@github.com>
 <VUwbo01Ivv81AevheTugl-_xosvdnzR7jhFhJtdViaE=.493aee6b-d32a-4258-8271-b25a281273d8@github.com>
 <xJz52QqQG3jjK_eODsEXefcjWz7dfCLa29VepSCwYtE=.1757660e-6211-4917-9a41-e9d5908ccecc@github.com>
 <sl_FDZPPaLyWqv74FBu0aJwzSvRgIwrT_Lj8TF3AtpU=.1dddf19e-c2b6-48ba-b477-dc685bbc1efb@github.com>
 <Pfc1L8tORSVPgNs51CRj0MkEF0EtbOIt7-gnmpswjDA=.1b49bc05-0a92-4c54-805d-54815983e2be@github.com>
 <2XePfo1gtNAWJvM5ECfg8Vkp8VObLOyQmM8WkQDiabM=.43f5d635-9352-4cc8-b9d9-e76aa710064d@github.com>
Message-ID: <bwZOldi_Ad40uVp3MIJTAqSJCztBfjVxsF8z661AN94=.5168abd0-a31d-4ae1-ad30-7ec2b620ad6e@github.com>

On Tue, 6 Dec 2022 12:01:13 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> The library does not provide an ability to set caret to visible permanently in case of text component being non-editable. Every time focus will change the caret will change too. One would have to implement a custom caret that overrides this logic.

If that is not possible I suggest providing that functionality so applications will be able to use that. Probably even provide some predefined cursors, like "faded"/"blurred"/nonblinked/etc. That could be configured per L&F as well.

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

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


From serb at openjdk.org  Wed Dec  7 11:01:14 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Dec 2022 11:01:14 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel
In-Reply-To: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
Message-ID: <bRaRY5COXrXecY_j2NX3pW1Yc_PkjxeKy-n2Z8Foc9Q=.5cc46753-6422-4439-b927-f55bdcf3f87a@github.com>

On Wed, 7 Dec 2022 10:25:31 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> In case of GTK LAF, the current selected element was not visible due to arrowbutton is rendered in entire display area of Combobox.
> 
> The proposed fix is to set the `squareButton `property of combobox to `false `so that the arrowbutton didn't take entire combobox display area for rendering. The `getMinimumSize `method is overridden in `SynthComboBoxUI `to consider **arrowbutton insets** for combobox minimum size. 
> 
> The JCK tests mentioned in JBS seems fine with the fix. An automated test case is implemented to test in Nimbus and GTK LAF.
> 
> When swing tests are run with LAF set to Nimbus and GTK LAF, few test failures observed. 
> 
> Although CI jobs looks ok with tests run in their default set LAFs.
> 
> `open/test/jdk/javax/swing/JComboBox/TestComboBoxHeight.java` test passes if run in GTK LAF with current fix.

Looks like the JBS issue is closed: 
    ?? Failed to retrieve information on issue 8218474.

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

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


From abhiscxk at openjdk.org  Wed Dec  7 11:04:02 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 7 Dec 2022 11:04:02 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel
In-Reply-To: <bRaRY5COXrXecY_j2NX3pW1Yc_PkjxeKy-n2Z8Foc9Q=.5cc46753-6422-4439-b927-f55bdcf3f87a@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
 <bRaRY5COXrXecY_j2NX3pW1Yc_PkjxeKy-n2Z8Foc9Q=.5cc46753-6422-4439-b927-f55bdcf3f87a@github.com>
Message-ID: <1j1a_9HEDc_psskVWTMuNajoGTap5ii6p-oVTk8ESiM=.32ba3ef6-e530-4e05-8649-e927a70ce3c9@github.com>

On Wed, 7 Dec 2022 10:59:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Looks like the JBS issue is closed: ?? Failed to retrieve information on issue 8218474.

https://bugs.openjdk.org/browse/JDK-8218474

It seems it is not closed.

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

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


From tr at openjdk.org  Wed Dec  7 11:40:07 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 7 Dec 2022 11:40:07 GMT
Subject: RFR: 4365952: Cannot disable JFileChooser
In-Reply-To: <qL0vp6t4z-C4FkX8nnZHeffTmIw2yyTQQ6toL2Sb1Lg=.f629cd98-3ccb-45da-8c90-8f8b13ce5300@github.com>
References: <0Pc6eSRN_L1pKaaKHb3-af86bTOyMn6oJ9wfC1LOvjA=.a6aa5a9e-58bb-4ca3-847c-0d7ad1473faf@github.com>
 <qL0vp6t4z-C4FkX8nnZHeffTmIw2yyTQQ6toL2Sb1Lg=.f629cd98-3ccb-45da-8c90-8f8b13ce5300@github.com>
Message-ID: <PUgQT39rFt8h5SeaWsB73msIGFlZPGqnQmhoZET0i5U=.8a1828e6-39ca-4267-9e72-1bf3c1c6a226@github.com>

On Wed, 7 Dec 2022 10:27:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Disable functionality not working for JFileChooser. `public void setEnabled(boolean enabled)` functionality is overridden in JFileChooser class which enable/disable each sub-component of FileChooser. 
>> The added functionality is tested in mach5 and no regression found. The fix includes automated test which clicks _home_ directory and then compares which default selectedDirectory to check if JFileChooser is disabled. This is tested in mach5 for all platforms with multiple test runs.
>
> src/java.desktop/share/classes/javax/swing/JFileChooser.java line 420:
> 
>> 418: 
>> 419:     @Override
>> 420:     public void setEnabled(boolean enabled) {
> 
> Can you please check why a similar example using JFrame and button works fine, but the JFileChooser does not work?
> 
>         JFrame frame = new JFrame();
>         JButton button = new JButton("1234567890");
>         frame.add(button);
>         frame.setVisible(true);
>         frame.setEnabled(false);
>         boolean enabled = button.isEnabled();
>         System.out.println("enabled = " + enabled);

JFileChooser added to a JFrame similar to the example also works, I guess it's because frame is made inaccessible. But when we try to disable JFileChooser alone, it's not working because we need to disable each sub-component in which JFileChooser is made up of. As per debugging I found out that peer component is showing null for JFileChooser.disable whereas for JFrame the disabling is taken care by peer component in Component class.

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

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


From aivanov at openjdk.org  Wed Dec  7 11:45:10 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 7 Dec 2022 11:45:10 GMT
Subject: RFR: 4668290: unclear spec for Polygon.bounds field [v4]
In-Reply-To: <Q7ndb_4xR2uvA6kmCxuc2dNDqbh-W3Yy0NoB7ILQ4bo=.9b6c4996-77f0-478e-bf29-25c3721c292d@github.com>
References: <jjzwWZJPW8Essivj9svlhO-LScPQV_TlMoC0GGOVgMY=.b5d5ced5-77af-4ce9-8214-10c1cc0392cb@github.com>
 <Q7ndb_4xR2uvA6kmCxuc2dNDqbh-W3Yy0NoB7ILQ4bo=.9b6c4996-77f0-478e-bf29-25c3721c292d@github.com>
Message-ID: <rI9xF0Y9bs3dFMufpucsTVmRMqJno9JRUG0gq_aFhxk=.7ca8b85a-930a-4629-b15c-2eae66c4b858@github.com>

On Tue, 6 Dec 2022 21:33:33 GMT, SWinxy <duke at openjdk.org> wrote:

>> New documentation replaces the `This value can be null.`:
>> 
>> When created, {@link #invalidate() invalidated}, or {@link #reset() reset},
>> this becomes {@code null}. To get out of the null state,
>> {@link #getBounds()} called with {@link #npoints} being greater than
>> {@code 0} will transfer into a non-null {@link Rectangle}.
>> 
>> 
>> I think I've got the reason for why it can be `null` correct, but you never know.
>> 
>> In javax.swing.text.html.Map, I've replaced setting the field to null with the equivalent #invalidate(). This may mean we can make the field private in the future.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dash

Marked as reviewed by aivanov (Reviewer).

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

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


From tr at openjdk.org  Wed Dec  7 11:50:39 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 7 Dec 2022 11:50:39 GMT
Subject: RFR: 8296198: JFileChooser throws InternalError
 java.lang.InternalError with Windows shortcuts [v3]
In-Reply-To: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>
References: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>
Message-ID: <od79uiZge-X_YiZGfIKXj6WQzambE04wdC674t8A2PY=.c6fe16e2-922b-4555-aa63-61b070cb57b6@github.com>

> When `JFileChooser` uses custom `FileSystemView`, traversing to link/shortcut to a folder throw `InternalError java.lang.InternalError ` in Windows. The issue found out to be in BasicFileChooserUI class which was unable to resolve the link path during directory setting. The `UsesShellFolder` check expects the FileSystemView to be of WindowsFileSystemView, which fails when custom FileSystemView is used.
> The fix includes resolving the link folder when custom File System View is used and has manual test. (Fix is test in CI system and no regression caused).

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/11510/files
  - new: https://git.openjdk.org/jdk/pull/11510/files/4dd8cc71..3bb397d5

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

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

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


From alexsch at openjdk.org  Wed Dec  7 13:26:51 2022
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Wed, 7 Dec 2022 13:26:51 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows
Message-ID: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>

**Environment**: 
GraalVM 22.3.0 with  jdk 19, Windows OS.

**Description**:
Create a native image of Swing application using GraalVM and run it with ` -Dsun.awt.fontconfig=fontconfig.properties.src` java property.
`java.lang.Error: java.home property not set` error is thrown.

For more details see https://github.com/oracle/graal/issues/4875.

**Solution**:
The error is thrown by the code from [FontConfiguration.findFontConfigFile()](https://github.com/openjdk/jdk19u/blob/c9d485792b99233f381dcdfd69838e7b973909bd/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L175) method.
GraalVM does not set `java.home`  property, that is why the `java.lang.Error: java.home property not set` is thrown.
`FontConfiguration.findFontConfigFile()` method compares `java.home` property to null before checking user provided `sun.awt.fontconfig` java property.

The proposed fix swaps the order of `java.home` and `sun.awt.fontconfig` properties checking to avoid using `java.home` property in case `sun.awt.fontconfig` is set.


**Steps to reproduce**:
- Download graal 22.3.0 jdk 19 for Windows from [GraalVM Community Edition 22.3.0](https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0) page.
- Install native-image

graalvm-ce-java19-22.3.0\bin\gu.cmd install native-image

- Create and compile `SwingSample.java` sample

import java.awt.*;
import javax.swing.*;

public class SwingSample {
    public static void main(String[] args) throws Exception {
        SwingUtilities.invokeAndWait(() -> {

            JFrame frame = new JFrame("Hello World");

            JButton button = new JButton("Hello");
            button.addActionListener(e -> {
                System.out.printf("Hello, World!%n");
            });

            JPanel panel = new JPanel(new FlowLayout());
            panel.add(button);

            frame.add(panel);
            frame.setSize(400, 300);
            frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
            frame.setVisible(true);
        });
    }
}

- Run native-image-agent to generate configuration files

graalvm-ce-java19-22.3.0\bin\java.cmd -agentlib:native-image-agent=config-output-dir=conf-dir SwingSample

- Copy `graalvm-ce-java19-22.3.0\lib\fontconfig.properties.src` file to the sample dir
- Generate native image with configuration files and `-Djava.awt.headless=false `, `-Dsun.awt.fontconfig=fontconfig.properties.src` java properties

call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64"
graalvm-ce-java19-22.3.0\bin\native-image.cmd --no-fallback -Djava.awt.headless=false -Dsun.awt.fontconfig=fontconfig.properties.src -H:ResourceConfigurationFiles=conf-dir/resource-config.json -H:SerializationConfigurationFiles=conf-dir/serialization-config.json -H:ReflectionConfigurationFiles=conf-dir/reflect-config.json -H:JNIConfigurationFiles=conf-dir/jni-config.json SwingSample

- Run the native image with `-Dsun.awt.fontconfig=fontconfig.properties.src` java property.

swingsample.exe  -Dsun.awt.fontconfig=fontconfig.properties.src

Exception in thread "main" java.lang.reflect.InvocationTargetException
        at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371)
        at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346)
        at java.desktop at 19.0.1/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480)
        at SwingSample.main(SwingSample.java:7)
Caused by: java.lang.Error: java.home property not set
        at java.desktop at 19.0.1/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
        at java.desktop at 19.0.1/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
        at java.desktop at 19.0.1/sun.awt.windows.WFontConfiguration.<init>(WFontConfiguration.java:41)

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

Commit messages:
 - 'java.home property not set' error in Graal when sun.awt.fontconfig java property is set on Windows

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

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


From mik3hall at gmail.com  Wed Dec  7 13:46:21 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 7 Dec 2022 07:46:21 -0600
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17]
In-Reply-To: <wtfe3m7FrVWssfUYna5S0oWNL6Xhz4UQRb-4V2tvvmc=.3356deec-bbe2-4372-ac3a-2cdc620fae67@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
 <wtfe3m7FrVWssfUYna5S0oWNL6Xhz4UQRb-4V2tvvmc=.3356deec-bbe2-4372-ac3a-2cdc620fae67@github.com>
Message-ID: <03051FCA-79CB-4488-85A0-C3084E1A6626@gmail.com>



> On Dec 7, 2022, at 3:41 AM, Thomas Stuefe <stuefe at openjdk.org> wrote:
> 
>  am surprised this even builds.

It builds for me?

* Toolchain:      clang (clang/LLVM from Xcode 14.1)

With the exception of these errors in cmstypes.c

/Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]
void *Type_ProfileSequenceId_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)
                                                                                                                                   ^
/Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]
void *Type_Dictionary_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)
                                                                                                                            ^
2 errors generated.

I had seen this sometime back. The same workaround of adding?

cmsUNUSED_PARAMETER(SizeOfTag);    // mjh

To the two methods, which I had noticed included elsewhere in the code, still appears to work.

I first noticed the sprintf issue in later releases of Xcode 13. It isn?t just Xcode 14.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221207/87ad1668/attachment.htm>

From tr at openjdk.org  Wed Dec  7 14:20:07 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 7 Dec 2022 14:20:07 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <m3I7nZheq3J6lIN0UlEnQrsLEaPKBqQgMnBvBKlTrZM=.4e3dcb57-f4a1-4443-a308-3beea1160cfc@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <ry0IIjcxmW_Lo7wI0-nRof9kg5LkLeh-i0zNhrEEdTg=.dcaef664-765e-4f53-8516-47ba3595ecb0@github.com>
 <D1DOLLXwcictjqWFMlcQ8_xJWLnQOhxJBS-716UnafM=.2fd2b9a3-e7bf-4f26-a15b-2767987cfa66@github.com>
 <m3I7nZheq3J6lIN0UlEnQrsLEaPKBqQgMnBvBKlTrZM=.4e3dcb57-f4a1-4443-a308-3beea1160cfc@github.com>
Message-ID: <9ejdReSOn_Aw7X5TSDec36gWGlv929241qmh0d_WseA=.f72c0217-9f1e-44fc-971a-4b4c82389fee@github.com>

On Thu, 1 Dec 2022 19:37:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Do we need to wait a bit longer after creating JFileChooser as the test immediately ends after instantiating it? Also, doesn't JFileChooser needs headful keyword as it needs to show a file dialog? Does it work more reliably if its to run in headful CI systems?
>> 
>> Should the test be headful even if we instantiate JFileChooser without showing the dialog.? I can check with a delay after its instantiated, but no sure if that might be causing the issue. Because the same issue is observed in another bug also which instantiates JFileChooser and does some tasks after that.
>
>> > Do we need to wait a bit longer after creating JFileChooser as the test immediately ends after instantiating it? Also, doesn't JFileChooser needs headful keyword as it needs to show a file dialog? Does it work more reliably if its to run in headful CI systems?
>> 
>> Should the test be headful even if we instantiate JFileChooser without showing the dialog.? I can check with a delay after its instantiated, but no sure if that might be causing the issue. Because the same issue is observed in another bug also which instantiates JFileChooser and does some tasks after that.
> 
> It doesn't need to be. It would've failed if it had required a headful system.
> 
> However, it may still be a valid concern. I faced some obscure failures on headless systems running Windows.
> 
> The exception is thrown on EDT when `JFileChooser` calculates its preferred size, so the test seem to work correctly. As such, I don't think the failure is related to the fact that the test exits after creating `JFileChooser`.
> 
> One of the options to fix the test is to add `@key headful`.
> 
> I wonder if the _Downloads_ folder is the first folder for which the icon is requested. Does fetching icons for other folders also fail? Does the host where the test fails have Windows Explorer? Windows Server systems can have minimal UI, if Windows Explorer is not available, then the `headful` keyword is the way to go.
> 
> So, we need to collect more data why it fails, why the icon of a folder is `null`.
> 
> In addition to that, we have to ensure `null` is returned directly to the caller rather than creating a `MultiResolutionImage` which doesn't even contain a base image.

@aivanov-jdk I just run some test samples by making the test as headful instead as headless as @prsadhuk suggested. I found out that making it as headful works just fine and no NPE occurred (Headless always showed issue, 8/200 test). And debugging to the root cause of Image not loading is also quite difficult. I guess it's better to modify the test as headful since the reliability of the test is better in it?

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

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


From abhiscxk at openjdk.org  Wed Dec  7 14:31:08 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 7 Dec 2022 14:31:08 GMT
Subject: RFR: 4365952: Cannot disable JFileChooser
In-Reply-To: <0Pc6eSRN_L1pKaaKHb3-af86bTOyMn6oJ9wfC1LOvjA=.a6aa5a9e-58bb-4ca3-847c-0d7ad1473faf@github.com>
References: <0Pc6eSRN_L1pKaaKHb3-af86bTOyMn6oJ9wfC1LOvjA=.a6aa5a9e-58bb-4ca3-847c-0d7ad1473faf@github.com>
Message-ID: <lj6mfmMD0U8OQkb3H0o5BUkbNtzOcD_B8HTuOJJafx0=.4eb5ab48-113c-403e-9acd-bce4eef9abc9@github.com>

On Wed, 7 Dec 2022 05:48:57 GMT, Tejesh R <tr at openjdk.org> wrote:

> Disable functionality not working for JFileChooser. `public void setEnabled(boolean enabled)` functionality is overridden in JFileChooser class which enable/disable each sub-component of FileChooser. 
> The added functionality is tested in mach5 and no regression found. The fix includes automated test which clicks _home_ directory and then compares which default selectedDirectory to check if JFileChooser is disabled. This is tested in mach5 for all platforms with multiple test runs.

Test Verified.

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

Marked as reviewed by abhiscxk (Author).

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


From abhiscxk at openjdk.org  Wed Dec  7 14:47:12 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 7 Dec 2022 14:47:12 GMT
Subject: RFR: 8296198: JFileChooser throws InternalError
 java.lang.InternalError with Windows shortcuts [v3]
In-Reply-To: <od79uiZge-X_YiZGfIKXj6WQzambE04wdC674t8A2PY=.c6fe16e2-922b-4555-aa63-61b070cb57b6@github.com>
References: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>
 <od79uiZge-X_YiZGfIKXj6WQzambE04wdC674t8A2PY=.c6fe16e2-922b-4555-aa63-61b070cb57b6@github.com>
Message-ID: <hiEJBwRJCuhsMzCVXllMVaFY7j0d4GYDNgtogAuxAPQ=.e2b0e289-7742-4ff8-9e5b-3990281b6d56@github.com>

On Wed, 7 Dec 2022 11:50:39 GMT, Tejesh R <tr at openjdk.org> wrote:

>> When `JFileChooser` uses custom `FileSystemView`, traversing to link/shortcut to a folder throw `InternalError java.lang.InternalError ` in Windows. The issue found out to be in BasicFileChooserUI class which was unable to resolve the link path during directory setting. The `UsesShellFolder` check expects the FileSystemView to be of WindowsFileSystemView, which fails when custom FileSystemView is used.
>> The fix includes resolving the link folder when custom File System View is used and has manual test. (Fix is test in CI system and no regression caused).
>
> 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 abhiscxk (Author).

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

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


From alexey.ushakov at jetbrains.com  Wed Dec  7 15:36:13 2022
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Wed, 7 Dec 2022 16:36:13 +0100
Subject: Quick fix for openjdk20
In-Reply-To: <CAKjRUT4muRHUfd8zA0k8OpWLJJLtFmgfBwHA08njYPL3g4U8fA@mail.gmail.com>
References: <CAKjRUT4muRHUfd8zA0k8OpWLJJLtFmgfBwHA08njYPL3g4U8fA@mail.gmail.com>
Message-ID: <7C1FA120-8A68-4805-A507-7D7ADF6BDBB1@jetbrains.com>

Yes, I confirm that we?ve been using such enlarged buffer for a long time in production. It helped us with scrolling performance on 4K monitors. The suggested property could help to adjust the buffer for the needs of particular application.

Best Regards,
Alexey

> On 7 Dec 2022, at 11:37, Laurent Bourg?s <bourges.laurent at gmail.com> wrote:
> 
> Hi,
> 
> For years, JetBrains Runtime uses a larger render queue buffer size (32kb to 6,400,000 bytes) in production, as it boosted many accelerated pipelines: d3d, ogl, metal :
> ~ 10 to 20% on large fills...
> 
> JBR RenderQueue:
> https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75 <https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75>
> 
> JDK RenderQueue:
> https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75 <https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75>
> 
> I want to propose such quick fix in openjdk20 today, as a 1-line fix.
> 
> /** The size of the underlying buffer, in bytes. */
> private static final int BUFFER_SIZE = 6400000;
> 
> To ensure a smooth transition, I prefer introducing a new sun.java2d.render.queue system property to increase the default (32kb) buffer capacity:
> 
> See in marlin:
> https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78 <https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78>
> 
> So here is my current proposal:
> [[[
> /** The size of the underlying buffer, in bytes. */
> private static final int BUFFER_SIZE;
> static {
> // Default 32K is too small for high-end GPU:
> BUFFER_SIZE = align(getInteger("sun.java2d.render.bufferSize", 32 * 1024, 32 * 1024, 16 * 1024 * 1024), 1024);
> // System.out.println("RenderQueue: sun.java2d.render.bufferSize = " + BUFFER_SIZE);
> }
> 
>     // system property utilities
>     public static int getInteger(final String key, final int def,
>                                  final int min, final int max)
>     {
>         final String property = AccessController.doPrivileged(
>                                     new GetPropertyAction(key));
> 
>         int value = def;
>         if (property != null) {
>             try {
>                 value = Integer.decode(property);
>             } catch (NumberFormatException e) {
>                 System.out.println("Invalid integer value for " + key + " = " + property);
>             }
>         }
> 
>         // check for invalid values
>         if ((value < min) || (value > max)) {
>             System.out.println("Invalid value for " + key + " = " + value
>                     + "; expected value in range[" + min + ", " + max + "] !");
>             value = def;
>         }
>         return value;
>     }
> 
>     protected static int align(final int val, final int norm) {
>         final int ceil = (int)Math.ceil( ((float) val) / norm);
>         return ceil * norm;
>     }
> ]]]
> 
> Would you accept such late change for openjdk20 ?
> 
> Cheers,
> Laurent Bourg?s 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221207/ebaed7cf/attachment.htm>

From azvegint at openjdk.org  Wed Dec  7 15:38:00 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 7 Dec 2022 15:38:00 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip [v2]
In-Reply-To: <6Y4AZanzqQvl5-du1LLmS3VG9tLYTbaQr1aRWx7XV3U=.7b428208-eb6e-4a94-ba34-2e22349201fd@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
 <6Y4AZanzqQvl5-du1LLmS3VG9tLYTbaQr1aRWx7XV3U=.7b428208-eb6e-4a94-ba34-2e22349201fd@github.com>
Message-ID: <sHhJUln007SZQWFqWlEYXZVUpSuv7fxMZW_OCNimrVg=.1229bcd8-debc-4bb3-a78a-09646b1c11ba@github.com>

On Sun, 4 Dec 2022 22:17:55 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Add try/catch clause to ignore an exception since it is harmless for we isolated
>> the massge data before passing it ro processor.
>> Add test case.
>
> Alexander Zuev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Got rid of the try/catch and using the proper per-case data length
>    analysis.
>  - Merge branch 'master' into JDK-8282578
>  - Merge branch 'master' of https://github.com/azuev-java/jdk into JDK-8282578
>  - Merge branch 'master'
>  - 8282578: AIOOBE in javax.sound.sampled.Clip
>    
>    Surround SysEx message processing block with try/catch allowing MIDI subsystem to
>    attempt to ingest the rest of the file.
>    
>    Added test case.

src/java.desktop/share/classes/com/sun/media/sound/SoftMainMixer.java line 166:

> 164:                                         break;
> 165:                                     }
> 166:                                     // http://www.midi.org/about-midi/tuning_extens.shtml

Unrelated to change, but looks like those links become unavailable years ago.

src/java.desktop/share/classes/com/sun/media/sound/SoftMainMixer.java line 406:

> 404:                                     int ix = 0;
> 405:                                     for (int j = 6; j < data.length - 1; j += 2) {
> 406:                                         destinations[ix] = data[j] & 0xFF;

Here is another possible AIOOOBE

e.g. if `data` length is 8, we will have `destination` and `ranges` length of 0:


int[] data = new int[8];

System.out.println("data len " + data.length);
if (data.length < 7) {
    System.out.println("Prevent");
    return;
}

int newSize = (data.length - 7) / 2;
System.out.println("new size " + newSize);

int[] destinations = new int[newSize];
int[] ranges = new int[newSize];
int ix = 0;
for (int j = 6; j < data.length - 1; j += 2) {
    System.out.println("index %d %d".formatted(j, ix) );
    destinations[ix] = data[j] & 0xFF;
    System.out.println("index " + (j + 1));
    ranges[ix] = data[j + 1] & 0xFF;
    ix++;
}


Same applies to similar cases below.

src/java.desktop/share/classes/com/sun/media/sound/SoftMainMixer.java line 462:

> 460:                         case 0x0A:  // Key Based Instrument Control
> 461:                         {
> 462:                             if (data.length < 7 || (data[4] & 0xFF) != 01) {

Neat: `0x01`

src/java.desktop/share/classes/com/sun/media/sound/SoftTuning.java line 114:

> 112:                     //if (!checksumOK2(data))
> 113:                     //    break;
> 114:                     if (data.length < 406) {

At first glance it looks like a magic numbers to me.<br>
for better readability we could declare `r` before this check and use `128*3 + r`

src/java.desktop/share/classes/com/sun/media/sound/SoftTuning.java line 136:

> 134:                     }
> 135:                     int ll = data[6] & 0xFF;
> 136:                     if (data.length < ll * 4 + 8) {

Shouldn't it be `ll * 4 + 7` == `ll * 4 + r`?

src/java.desktop/share/classes/com/sun/media/sound/SoftTuning.java line 231:

> 229:                 {
> 230:                     // http://www.midi.org/about-midi/tuning-scale.shtml
> 231:                     if (data.length < 21) {

`< 20`? 


int[] data = new int[20];
for (int i = 0; i < 12; i++) {
    System.out.println(data[i + 8]);
}

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

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


From lbourges at openjdk.org  Wed Dec  7 16:02:21 2022
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 7 Dec 2022 16:02:21 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17]
In-Reply-To: <wtfe3m7FrVWssfUYna5S0oWNL6Xhz4UQRb-4V2tvvmc=.3356deec-bbe2-4372-ac3a-2cdc620fae67@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
 <wtfe3m7FrVWssfUYna5S0oWNL6Xhz4UQRb-4V2tvvmc=.3356deec-bbe2-4372-ac3a-2cdc620fae67@github.com>
Message-ID: <D2GcLWUTfyqFoBuUa9JXarKRz_j1xwjNSoyBTfs6PE4=.b52f7b27-acf3-40c1-8fd1-8afa2003f9bd@github.com>

On Wed, 7 Dec 2022 08:35:52 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment for snprintf_checked
>
> src/hotspot/os/bsd/attachListener_bsd.cpp line 260:
> 
>> 258:   // name ("load", "datadump", ...), and <arg> is an argument
>> 259:   int expected_str_count = 2 + AttachOperation::arg_count_max;
>> 260:   const int max_len = (ver_str_len + 1) + (AttachOperation::name_length_max + 1) +
> 
> This makes `max_len` a runtime variable, before it was a compile time constant. Below, we use it to create the buf array. IIRC creating an array with a variable runtime length is a non-standard compiler extension. I am surprised this even builds.

better to keep sizeof(ver_str) here (const)

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

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


From omikhaltcova at openjdk.org  Wed Dec  7 16:04:07 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Wed, 7 Dec 2022 16:04:07 GMT
Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if
 TextAttribute.TRACKING is set. [v5]
In-Reply-To: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
References: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
Message-ID: <-ITFLZBJsoPsa7E7tyShyPAQWCQl7gBYkBm9joulx2Y=.cca61186-72b5-4804-93fb-34c02125eba0@github.com>

> This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks.
> 
> Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests:
> `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font`

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

  Replaced BitstreamCyberbit with Dialog

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10289/files
  - new: https://git.openjdk.org/jdk/pull/10289/files/c136384f..b0d44ce0

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

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

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


From lucy at openjdk.org  Wed Dec  7 16:07:55 2022
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 7 Dec 2022 16:07:55 GMT
Subject: RFR: JDK-8298093: improve cleanup and error handling of
 awt_parseColorModel in awt_parseImage.c [v3]
In-Reply-To: <2Dhk_nsd_PNixhUjUswA6uxE05Yn2hCHHLZX94DgDXA=.7f4c436c-0ab2-4037-a600-14c2b23ef830@github.com>
References: <LJXA0GoYlzD_v4Gb9N0ytaim25_su2y8hAyWhx0hGKI=.5087cce4-07f1-446c-a389-d65334315f73@github.com>
 <2Dhk_nsd_PNixhUjUswA6uxE05Yn2hCHHLZX94DgDXA=.7f4c436c-0ab2-4037-a600-14c2b23ef830@github.com>
Message-ID: <slKFJnMJmUdngbHRv_FRYb5jBdf9pPtVgH-1Q6uo5z4=.d723dfa9-a0f1-435f-a2d4-774119a2e84e@github.com>

On Wed, 7 Dec 2022 08:54:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The cleanup and error handling in function awt_parseColorModel in awt_parseImage.c could be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small adjustment

LGTM.
Thanks for fixing this.

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

Marked as reviewed by lucy (Reviewer).

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


From omikhaltcova at openjdk.org  Wed Dec  7 16:16:29 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Wed, 7 Dec 2022 16:16:29 GMT
Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if
 TextAttribute.TRACKING is set. [v6]
In-Reply-To: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
References: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
Message-ID: <mT1Be9CCNN-70QKH22TobbNDVxu2X8TkhB61iU35mNI=.fd44b495-ae35-42eb-8187-4cf89f1c0f70@github.com>

> This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks.
> 
> Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests:
> `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font`

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

  Deleted empty line inserted by mistake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10289/files
  - new: https://git.openjdk.org/jdk/pull/10289/files/b0d44ce0..34764d82

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

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

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


From rriggs at openjdk.org  Wed Dec  7 16:30:14 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Dec 2022 16:30:14 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <A1uT4hPZxgKW7wK02bmXt_NDnnUV-6coQ8Z1wtBKYjw=.10d27751-2aab-45c4-becf-974ed9f3e4fc@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

Good idea, though perhaps the return (and value if any) could be explicit in the macro invocation, instead of implicit (plus arg).  A single macro would suffice, instead of multiples.

Usage Example:

    JNU_CHECK_EXCEPTION_DO(env, { 
             free(tab); 
             return;
           })

Or put the invocation and return all on one line.

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

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


From prr at openjdk.org  Wed Dec  7 16:38:17 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 7 Dec 2022 16:38:17 GMT
Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if
 TextAttribute.TRACKING is set. [v6]
In-Reply-To: <mT1Be9CCNN-70QKH22TobbNDVxu2X8TkhB61iU35mNI=.fd44b495-ae35-42eb-8187-4cf89f1c0f70@github.com>
References: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
 <mT1Be9CCNN-70QKH22TobbNDVxu2X8TkhB61iU35mNI=.fd44b495-ae35-42eb-8187-4cf89f1c0f70@github.com>
Message-ID: <c9RBYubtv5XMq6ZwDW064FhYDf0z7ECUzNqT7OvntNw=.10fc10ac-5bf3-4bcc-b828-6a97cd990c4c@github.com>

On Wed, 7 Dec 2022 16:16:29 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks.
>> 
>> Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests:
>> `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font`
>
> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Deleted empty line inserted by mistake

This now is fine by me. It didn't break any of our automated tests.

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

Marked as reviewed by prr (Reviewer).

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


From psadhukhan at openjdk.org  Wed Dec  7 16:44:29 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 7 Dec 2022 16:44:29 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with JDK
 6
Message-ID: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>

The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
    javax.swing.text.html.parser.ParserDelegator
    javax.swing.LayoutComparator
They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.

Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
Added the warning..

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

Commit messages:
 - 7030853: JDK 7 Serializable Swing classes not compatible with JDK 6

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

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


From stuefe at openjdk.org  Wed Dec  7 16:45:02 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Dec 2022 16:45:02 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <A1uT4hPZxgKW7wK02bmXt_NDnnUV-6coQ8Z1wtBKYjw=.10d27751-2aab-45c4-becf-974ed9f3e4fc@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
 <A1uT4hPZxgKW7wK02bmXt_NDnnUV-6coQ8Z1wtBKYjw=.10d27751-2aab-45c4-becf-974ed9f3e4fc@github.com>
Message-ID: <4zHedrkH9jgKyqCdI__dW2Ce31J6K28vyXSzv3LFONY=.397d9792-06b8-4642-a7cf-6a43c7609cc1@github.com>

On Wed, 7 Dec 2022 16:27:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> 
> Good idea, though perhaps the return (and value if any) could be explicit in the macro invocation, instead of implicit (plus arg). A single macro would suffice, instead of multiples.
> 
> Usage Example:
> 
> ```
>     JNU_CHECK_EXCEPTION_DO(env, { 
>              free(tab); 
>              return;
>            })
> ```

Neat. I like that.

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

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


From bourges.laurent at gmail.com  Wed Dec  7 17:29:11 2022
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 7 Dec 2022 18:29:11 +0100
Subject: Quick fix for openjdk20
In-Reply-To: <7C1FA120-8A68-4805-A507-7D7ADF6BDBB1@jetbrains.com>
References: <CAKjRUT4muRHUfd8zA0k8OpWLJJLtFmgfBwHA08njYPL3g4U8fA@mail.gmail.com>
 <7C1FA120-8A68-4805-A507-7D7ADF6BDBB1@jetbrains.com>
Message-ID: <CAKjRUT6T5LjZm+EvzYFNNNdrnvL1hf7jnyAwRrSc1c9thy5D6Q@mail.gmail.com>

Hi again,

See first draft patch with new performance results on openjdk20 / linux /
opengl pipeline (same for d3d / metal):
https://github.com/openjdk/jdk/pull/11569

Cheers,
Laurent

Le mer. 7 d?c. 2022 ? 16:36, Alexey Ushakov <alexey.ushakov at jetbrains.com>
a ?crit :

> Yes, I confirm that we?ve been using such enlarged buffer for a long time
> in production. It helped us with scrolling performance on 4K monitors. The
> suggested property could help to adjust the buffer for the needs of
> particular application.
>
> Best Regards,
> Alexey
>
> On 7 Dec 2022, at 11:37, Laurent Bourg?s <bourges.laurent at gmail.com>
> wrote:
>
> Hi,
>
> For years, JetBrains Runtime uses a larger render queue buffer size (32kb
> to 6,400,000 bytes) in production, as it boosted many accelerated
> pipelines: d3d, ogl, metal :
> ~ 10 to 20% on large fills...
>
> JBR RenderQueue:
>
> https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75
>
> JDK RenderQueue:
>
> https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75
>
> I want to propose such quick fix in openjdk20 today, as a 1-line fix.
>
> /** The size of the underlying buffer, in bytes. */
> private static final int BUFFER_SIZE = 6400000;
>
> To ensure a smooth transition, I prefer introducing a new
> sun.java2d.render.queue system property to increase the default (32kb)
> buffer capacity:
>
> See in marlin:
>
> https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78
>
> So here is my current proposal:
> [[[
> /** The size of the underlying buffer, in bytes. */
> private static final int BUFFER_SIZE;
> static {
> // Default 32K is too small for high-end GPU:
> BUFFER_SIZE = align(getInteger("sun.java2d.render.bufferSize", 32 * 1024,
> 32 * 1024, 16 * 1024 * 1024), 1024);
> // System.out.println("RenderQueue: sun.java2d.render.bufferSize = " +
> BUFFER_SIZE);
> }
>
>     // system property utilities
>     public static int getInteger(final String key, final int def,
>                                  final int min, final int max)
>     {
>         final String property = AccessController.doPrivileged(
>                                     new GetPropertyAction(key));
>
>         int value = def;
>         if (property != null) {
>             try {
>                 value = Integer.decode(property);
>             } catch (NumberFormatException e) {
>                 System.out.println("Invalid integer value for " + key + "
> = " + property);
>             }
>         }
>
>         // check for invalid values
>         if ((value < min) || (value > max)) {
>             System.out.println("Invalid value for " + key + " = " + value
>                     + "; expected value in range[" + min + ", " + max + "]
> !");
>             value = def;
>         }
>         return value;
>     }
>
>     protected static int align(final int val, final int norm) {
>         final int ceil = (int)Math.ceil( ((float) val) / norm);
>         return ceil * norm;
>     }
> ]]]
>
> Would you accept such late change for openjdk20 ?
>
> Cheers,
> Laurent Bourg?s
>
>
>

-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221207/6b0b0315/attachment.htm>

From omikhaltcova at openjdk.org  Wed Dec  7 17:44:45 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Wed, 7 Dec 2022 17:44:45 GMT
Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if
 TextAttribute.TRACKING is set. [v6]
In-Reply-To: <mT1Be9CCNN-70QKH22TobbNDVxu2X8TkhB61iU35mNI=.fd44b495-ae35-42eb-8187-4cf89f1c0f70@github.com>
References: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
 <mT1Be9CCNN-70QKH22TobbNDVxu2X8TkhB61iU35mNI=.fd44b495-ae35-42eb-8187-4cf89f1c0f70@github.com>
Message-ID: <u30Kb7C_od_W36hZUiV2N9imR_b0B28y6ABgoJJYjiQ=.e2a74f6a-5c77-4210-b673-950e9936d355@github.com>

On Wed, 7 Dec 2022 16:16:29 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks.
>> 
>> Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests:
>> `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font`
>
> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Deleted empty line inserted by mistake

Thanks a lot for reviewing!

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

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


From omikhaltcova at openjdk.org  Wed Dec  7 18:05:23 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Wed, 7 Dec 2022 18:05:23 GMT
Subject: Integrated: 8165943: LineBreakMeasurer does not measure correctly if
 TextAttribute.TRACKING is set.
In-Reply-To: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
References: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>
Message-ID: <flFOfVseLCKuq0dOUFq-c3Dj6ZwT2Yw8kqlfja-9uxs=.f2b55dc0-d65f-4514-85ce-bcf4209daa7f@github.com>

On Thu, 15 Sep 2022 16:51:27 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

> This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks.
> 
> Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests:
> `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font`

This pull request has now been integrated.

Changeset: 8edb98df
Author:    Olga Mikhaltsova <omikhaltcova at openjdk.org>
Committer: Andrew Brygin <bae at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8edb98df3dd393103f2c80e929b011bc6b7993a3
Stats:     325 lines in 5 files changed: 315 ins; 3 del; 7 mod

8165943: LineBreakMeasurer does not measure correctly if TextAttribute.TRACKING is set.

Co-authored-by: Jason Fordham <jclf at azul.com>
Reviewed-by: prr

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

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


From philip.race at oracle.com  Wed Dec  7 18:22:22 2022
From: philip.race at oracle.com (Philip Race)
Date: Wed, 7 Dec 2022 10:22:22 -0800
Subject: Quick fix for openjdk20
In-Reply-To: <7C1FA120-8A68-4805-A507-7D7ADF6BDBB1@jetbrains.com>
References: <CAKjRUT4muRHUfd8zA0k8OpWLJJLtFmgfBwHA08njYPL3g4U8fA@mail.gmail.com>
 <7C1FA120-8A68-4805-A507-7D7ADF6BDBB1@jetbrains.com>
Message-ID: <ae90ff4d-bb8b-ec73-71ad-4c2c7394b032@oracle.com>

This is clearly too late for JDK 20 and JDK 21 will be just 6 months 
later so it is a better time for that.
FWIW we have just had at a report of a performance drop in JDK 20 from a 
b07 change to show how it takes
time for these things to be discovered.
Also I had a bug / rfe for this a while back : 
https://bugs.openjdk.org/browse/JDK-8233037
I closed it as WNF because I wasn't able to see a performance boost.

So the right way to do this is? to provide some solid evidence of what 
gets faster and what gets
slower with a range of different values (not just the JBR one) and 
re-open that bug and resolve early in 21.

-phil.


On 12/7/22 7:36 AM, Alexey Ushakov wrote:
> Yes, I confirm that we?ve been using such enlarged buffer for a long 
> time in production. It helped us with scrolling performance on 4K 
> monitors. The suggested property could help to adjust the buffer for 
> the needs of particular application.
>
> Best Regards,
> Alexey
>
>> On 7 Dec 2022, at 11:37, Laurent Bourg?s <bourges.laurent at gmail.com> 
>> wrote:
>>
>> Hi,
>>
>> For years, JetBrains Runtime uses a larger render queue buffer size 
>> (32kb to 6,400,000 bytes) in production, as it boosted many 
>> accelerated pipelines: d3d, ogl, metal :
>> ~ 10 to 20% on large fills...
>>
>> JBR RenderQueue:
>> https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75
>>
>> JDK RenderQueue:
>> https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75
>>
>> I want to propose such quick fix in openjdk20 today, as a 1-line fix.
>>
>>
>> /** The size of the underlying buffer, in bytes. */
>>
>> private static final int BUFFER_SIZE = 6400000;
>>
>>
>> To ensure a smooth transition, I prefer introducing a new 
>> sun.java2d.render.queue system property to increase the default 
>> (32kb) buffer capacity:
>>
>> See in marlin:
>> https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78
>>
>> So here is my current proposal:
>> [[[
>>
>> /** The size of the underlying buffer, in bytes. */
>>
>> private static final int BUFFER_SIZE;
>>
>>
>> static {
>>
>> // Default 32K is too small for high-end GPU:
>>
>> BUFFER_SIZE = align(getInteger("sun.java2d.render.bufferSize", 32 * 
>> 1024, 32 * 1024, 16 * 1024 * 1024), 1024);
>>
>>
>> // System.out.println("RenderQueue: sun.java2d.render.bufferSize = " 
>> + BUFFER_SIZE);
>>
>> }
>>
>>
>> ? ? // system property utilities
>> ? ? public static int getInteger(final String key, final int def,
>> ? ?final int min, final int max)
>> ? ? {
>> ? ? ? ? final String property = AccessController.doPrivileged(
>> ? ? ? new GetPropertyAction(key));
>>
>> ? ? ? ? int value = def;
>> ? ? ? ? if (property != null) {
>> ? ? ? ? ? ? try {
>> ? ? ? ? ? ? ? ? value = Integer.decode(property);
>> ? ? ? ? ? ? } catch (NumberFormatException e) {
>> System.out.println("Invalid integer value for " + key + " = " + 
>> property);
>> ? ? ? ? ? ? }
>> ? ? ? ? }
>>
>> ? ? ? ? // check for invalid values
>> ? ? ? ? if ((value < min) || (value > max)) {
>> System.out.println("Invalid value for " + key + " = " + value
>> ? ? ? ? ? ? ? ? ? ? + "; expected value in range[" + min + ", " + max 
>> + "] !");
>> ? ? ? ? ? ? value = def;
>> ? ? ? ? }
>> ? ? ? ? return value;
>> ? ? }
>>
>> ? ? protected static int align(final int val, final int norm) {
>> ? ? ? ? final int ceil = (int)Math.ceil( ((float) val) / norm);
>> ? ? ? ? return ceil * norm;
>> ? ? }
>> ]]]
>>
>> Would you accept such late change for openjdk20 ?
>>
>> Cheers,
>> Laurent Bourg?s
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221207/5aa3f1d2/attachment.htm>

From kizune at openjdk.org  Wed Dec  7 18:47:30 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 7 Dec 2022 18:47:30 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip [v2]
In-Reply-To: <sHhJUln007SZQWFqWlEYXZVUpSuv7fxMZW_OCNimrVg=.1229bcd8-debc-4bb3-a78a-09646b1c11ba@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
 <6Y4AZanzqQvl5-du1LLmS3VG9tLYTbaQr1aRWx7XV3U=.7b428208-eb6e-4a94-ba34-2e22349201fd@github.com>
 <sHhJUln007SZQWFqWlEYXZVUpSuv7fxMZW_OCNimrVg=.1229bcd8-debc-4bb3-a78a-09646b1c11ba@github.com>
Message-ID: <RVjsj75PeuTlrrXN1XlIsiWLHiOvuN_C2ELRv_ZG5_0=.aa656f7e-6c41-4d7b-b956-7403cf35686a@github.com>

On Wed, 7 Dec 2022 15:15:34 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Got rid of the try/catch and using the proper per-case data length
>>    analysis.
>>  - Merge branch 'master' into JDK-8282578
>>  - Merge branch 'master' of https://github.com/azuev-java/jdk into JDK-8282578
>>  - Merge branch 'master'
>>  - 8282578: AIOOBE in javax.sound.sampled.Clip
>>    
>>    Surround SysEx message processing block with try/catch allowing MIDI subsystem to
>>    attempt to ingest the rest of the file.
>>    
>>    Added test case.
>
> src/java.desktop/share/classes/com/sun/media/sound/SoftMainMixer.java line 406:
> 
>> 404:                                     int ix = 0;
>> 405:                                     for (int j = 6; j < data.length - 1; j += 2) {
>> 406:                                         destinations[ix] = data[j] & 0xFF;
> 
> Here is another possible AIOOOBE
> 
> e.g. if `data` length is 8, we will have `destination` and `ranges` length of 0:
> 
> 
> int[] data = new int[8];
> 
> System.out.println("data len " + data.length);
> if (data.length < 7) {
>     System.out.println("Prevent");
>     return;
> }
> 
> int newSize = (data.length - 7) / 2;
> System.out.println("new size " + newSize);
> 
> int[] destinations = new int[newSize];
> int[] ranges = new int[newSize];
> int ix = 0;
> for (int j = 6; j < data.length - 1; j += 2) {
>     System.out.println("index %d %d".formatted(j, ix) );
>     destinations[ix] = data[j] & 0xFF;
>     System.out.println("index " + (j + 1));
>     ranges[ix] = data[j + 1] & 0xFF;
>     ix++;
> }
> 
> 
> Same applies to similar cases below.

Ok, i think there are 3 places total with this possibility when increment goes by 2 so fixed them all.

> src/java.desktop/share/classes/com/sun/media/sound/SoftMainMixer.java line 462:
> 
>> 460:                         case 0x0A:  // Key Based Instrument Control
>> 461:                         {
>> 462:                             if (data.length < 7 || (data[4] & 0xFF) != 01) {
> 
> Neat: `0x01`

Ok.

> src/java.desktop/share/classes/com/sun/media/sound/SoftTuning.java line 114:
> 
>> 112:                     //if (!checksumOK2(data))
>> 113:                     //    break;
>> 114:                     if (data.length < 406) {
> 
> At first glance it looks like a magic numbers to me.<br>
> for better readability we could declare `r` before this check and use `128*3 + r`

Makes sense, fixed.

> src/java.desktop/share/classes/com/sun/media/sound/SoftTuning.java line 136:
> 
>> 134:                     }
>> 135:                     int ll = data[6] & 0xFF;
>> 136:                     if (data.length < ll * 4 + 8) {
> 
> Shouldn't it be `ll * 4 + 7` == `ll * 4 + r`?

Yes.

> src/java.desktop/share/classes/com/sun/media/sound/SoftTuning.java line 231:
> 
>> 229:                 {
>> 230:                     // http://www.midi.org/about-midi/tuning-scale.shtml
>> 231:                     if (data.length < 21) {
> 
> `< 20`? 
> 
> 
> int[] data = new int[20];
> for (int i = 0; i < 12; i++) {
>     System.out.println(data[i + 8]);
> }

Yes. Math is hard.

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

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


From kizune at openjdk.org  Wed Dec  7 18:56:11 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 7 Dec 2022 18:56:11 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip [v2]
In-Reply-To: <sHhJUln007SZQWFqWlEYXZVUpSuv7fxMZW_OCNimrVg=.1229bcd8-debc-4bb3-a78a-09646b1c11ba@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
 <6Y4AZanzqQvl5-du1LLmS3VG9tLYTbaQr1aRWx7XV3U=.7b428208-eb6e-4a94-ba34-2e22349201fd@github.com>
 <sHhJUln007SZQWFqWlEYXZVUpSuv7fxMZW_OCNimrVg=.1229bcd8-debc-4bb3-a78a-09646b1c11ba@github.com>
Message-ID: <w6yn3rj2BwZrOOjqUT0hHMKyHGj_jdIshYHBN-F5TjU=.abfb17a0-e141-4062-a713-a62d8166aba0@github.com>

On Wed, 7 Dec 2022 15:34:48 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Got rid of the try/catch and using the proper per-case data length
>>    analysis.
>>  - Merge branch 'master' into JDK-8282578
>>  - Merge branch 'master' of https://github.com/azuev-java/jdk into JDK-8282578
>>  - Merge branch 'master'
>>  - 8282578: AIOOBE in javax.sound.sampled.Clip
>>    
>>    Surround SysEx message processing block with try/catch allowing MIDI subsystem to
>>    attempt to ingest the rest of the file.
>>    
>>    Added test case.
>
> src/java.desktop/share/classes/com/sun/media/sound/SoftMainMixer.java line 166:
> 
>> 164:                                         break;
>> 165:                                     }
>> 166:                                     // http://www.midi.org/about-midi/tuning_extens.shtml
> 
> Unrelated to change, but looks like those links become unavailable years ago.

Yes. That's the problem referencing the external site for information. Unfortunately the documentation layout on midi site changed and one needs to read trough all of it to figure out the correct path that both relates to the midi-1.0 standard that we support and is not overwritten by some later addendum making it non-informative.

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

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


From kizune at openjdk.org  Wed Dec  7 19:02:43 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 7 Dec 2022 19:02:43 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip [v3]
In-Reply-To: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
Message-ID: <kUrnUASmXSr1kNGsnu152LBQ5ZkTNVGxwELq4ByYcH4=.4476cd43-97d2-4805-81a8-6d6ce068c187@github.com>

> Add try/catch clause to ignore an exception since it is harmless for we isolated
> the massge data before passing it ro processor.
> Add test case.

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

  Fixed length calculations in the array access checks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9016/files
  - new: https://git.openjdk.org/jdk/pull/9016/files/f2ff2d14..85c27f6f

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

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

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


From bourges.laurent at gmail.com  Wed Dec  7 19:13:16 2022
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 7 Dec 2022 20:13:16 +0100
Subject: Quick fix for openjdk20
In-Reply-To: <ae90ff4d-bb8b-ec73-71ad-4c2c7394b032@oracle.com>
References: <CAKjRUT4muRHUfd8zA0k8OpWLJJLtFmgfBwHA08njYPL3g4U8fA@mail.gmail.com>
 <7C1FA120-8A68-4805-A507-7D7ADF6BDBB1@jetbrains.com>
 <ae90ff4d-bb8b-ec73-71ad-4c2c7394b032@oracle.com>
Message-ID: <CAKjRUT5mvxr6m-Srfis302Wh5P9z-SgW0s6SCABdF37Hu32=OA@mail.gmail.com>

Thanks, Phil

I supposed it too late, no problem for openjdk21.

I made a draft PR and tested several sizes on 1 machine:
https://github.com/openjdk/jdk/pull/11569

Of course I can complete later with more tested machines & using j2dbench
if needed.

I can also give ratios... ie gains.

Cheers,
Laurent


Le mer. 7 d?c. 2022, 19:22, Philip Race <philip.race at oracle.com> a ?crit :

> This is clearly too late for JDK 20 and JDK 21 will be just 6 months later
> so it is a better time for that.
> FWIW we have just had at a report of a performance drop in JDK 20 from a
> b07 change to show how it takes
> time for these things to be discovered.
> Also I had a bug / rfe for this a while back :
> https://bugs.openjdk.org/browse/JDK-8233037
> I closed it as WNF because I wasn't able to see a performance boost.
>
> So the right way to do this is  to provide some solid evidence of what
> gets faster and what gets
> slower with a range of different values (not just the JBR one) and re-open
> that bug and resolve early in 21.
>
> -phil.
>
>
> On 12/7/22 7:36 AM, Alexey Ushakov wrote:
>
> Yes, I confirm that we?ve been using such enlarged buffer for a long time
> in production. It helped us with scrolling performance on 4K monitors. The
> suggested property could help to adjust the buffer for the needs of
> particular application.
>
> Best Regards,
> Alexey
>
> On 7 Dec 2022, at 11:37, Laurent Bourg?s <bourges.laurent at gmail.com>
> wrote:
>
> Hi,
>
> For years, JetBrains Runtime uses a larger render queue buffer size (32kb
> to 6,400,000 bytes) in production, as it boosted many accelerated
> pipelines: d3d, ogl, metal :
> ~ 10 to 20% on large fills...
>
> JBR RenderQueue:
>
> https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75
>
> JDK RenderQueue:
>
> https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75
>
> I want to propose such quick fix in openjdk20 today, as a 1-line fix.
>
>
> /** The size of the underlying buffer, in bytes. */
> private static final int BUFFER_SIZE = 6400000;
>
> To ensure a smooth transition, I prefer introducing a new
> sun.java2d.render.queue system property to increase the default (32kb)
> buffer capacity:
>
> See in marlin:
>
> https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78
>
> So here is my current proposal:
> [[[
>
> /** The size of the underlying buffer, in bytes. */
> private static final int BUFFER_SIZE;
>
> static {
> // Default 32K is too small for high-end GPU:
> BUFFER_SIZE = align(getInteger("sun.java2d.render.bufferSize", 32 * 1024,
> 32 * 1024, 16 * 1024 * 1024), 1024);
>
> // System.out.println("RenderQueue: sun.java2d.render.bufferSize = " +
> BUFFER_SIZE);
> }
>
>     // system property utilities
>     public static int getInteger(final String key, final int def,
>                                  final int min, final int max)
>     {
>         final String property = AccessController.doPrivileged(
>                                     new GetPropertyAction(key));
>
>         int value = def;
>         if (property != null) {
>             try {
>                 value = Integer.decode(property);
>             } catch (NumberFormatException e) {
>                 System.out.println("Invalid integer value for " + key + "
> = " + property);
>             }
>         }
>
>         // check for invalid values
>         if ((value < min) || (value > max)) {
>             System.out.println("Invalid value for " + key + " = " + value
>                     + "; expected value in range[" + min + ", " + max + "]
> !");
>             value = def;
>         }
>         return value;
>     }
>
>     protected static int align(final int val, final int norm) {
>         final int ceil = (int)Math.ceil( ((float) val) / norm);
>         return ceil * norm;
>     }
> ]]]
>
> Would you accept such late change for openjdk20 ?
>
> Cheers,
> Laurent Bourg?s
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221207/ec022b2d/attachment.htm>

From azvegint at openjdk.org  Wed Dec  7 19:46:06 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 7 Dec 2022 19:46:06 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip [v2]
In-Reply-To: <w6yn3rj2BwZrOOjqUT0hHMKyHGj_jdIshYHBN-F5TjU=.abfb17a0-e141-4062-a713-a62d8166aba0@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
 <6Y4AZanzqQvl5-du1LLmS3VG9tLYTbaQr1aRWx7XV3U=.7b428208-eb6e-4a94-ba34-2e22349201fd@github.com>
 <sHhJUln007SZQWFqWlEYXZVUpSuv7fxMZW_OCNimrVg=.1229bcd8-debc-4bb3-a78a-09646b1c11ba@github.com>
 <w6yn3rj2BwZrOOjqUT0hHMKyHGj_jdIshYHBN-F5TjU=.abfb17a0-e141-4062-a713-a62d8166aba0@github.com>
Message-ID: <6DD5aWK3tS7KNzuwvaDPlf89JKRoTiyhO1dxDSr-LcI=.9974da7c-4ab0-4e47-b5f0-e3798e0c4776@github.com>

On Wed, 7 Dec 2022 18:53:32 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/media/sound/SoftMainMixer.java line 166:
>> 
>>> 164:                                         break;
>>> 165:                                     }
>>> 166:                                     // http://www.midi.org/about-midi/tuning_extens.shtml
>> 
>> Unrelated to change, but looks like those links become unavailable years ago.
>
> Yes. That's the problem referencing the external site for information. Unfortunately the documentation layout on midi site changed and one needs to read trough all of it to figure out the correct path that both relates to the midi-1.0 standard that we support and is not overwritten by some later addendum making it non-informative.

We might want to track this under some issue, if not done already.

>> src/java.desktop/share/classes/com/sun/media/sound/SoftMainMixer.java line 406:
>> 
>>> 404:                                     int ix = 0;
>>> 405:                                     for (int j = 6; j < data.length - 1; j += 2) {
>>> 406:                                         destinations[ix] = data[j] & 0xFF;
>> 
>> Here is another possible AIOOOBE
>> 
>> e.g. if `data` length is 8, we will have `destination` and `ranges` length of 0:
>> 
>> 
>> int[] data = new int[8];
>> 
>> System.out.println("data len " + data.length);
>> if (data.length < 7) {
>>     System.out.println("Prevent");
>>     return;
>> }
>> 
>> int newSize = (data.length - 7) / 2;
>> System.out.println("new size " + newSize);
>> 
>> int[] destinations = new int[newSize];
>> int[] ranges = new int[newSize];
>> int ix = 0;
>> for (int j = 6; j < data.length - 1; j += 2) {
>>     System.out.println("index %d %d".formatted(j, ix) );
>>     destinations[ix] = data[j] & 0xFF;
>>     System.out.println("index " + (j + 1));
>>     ranges[ix] = data[j + 1] & 0xFF;
>>     ix++;
>> }
>> 
>> 
>> Same applies to similar cases below.
>
> Ok, i think there are 3 places total with this possibility when increment goes by 2 so fixed them all.

Length check won't help here:


  int[] data = new int[100];
  if (data.length < 8) {
      return;
  }
  int[] destinations = new int[(data.length - 7) / 2];
  int[] ranges = new int[(data.length - 7) / 2];
  int ix = 0;
  for (int j = 6; j < data.length - 1; j += 2) {
      destinations[ix] = data[j] & 0xFF;
      ranges[ix] = data[j + 1] & 0xFF;
      ix++;
  }

`Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 46 out of bounds for length 46`


We might want to add more test cases to the test.

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

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


From kizune at openjdk.org  Wed Dec  7 19:57:06 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 7 Dec 2022 19:57:06 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip [v2]
In-Reply-To: <6DD5aWK3tS7KNzuwvaDPlf89JKRoTiyhO1dxDSr-LcI=.9974da7c-4ab0-4e47-b5f0-e3798e0c4776@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
 <6Y4AZanzqQvl5-du1LLmS3VG9tLYTbaQr1aRWx7XV3U=.7b428208-eb6e-4a94-ba34-2e22349201fd@github.com>
 <sHhJUln007SZQWFqWlEYXZVUpSuv7fxMZW_OCNimrVg=.1229bcd8-debc-4bb3-a78a-09646b1c11ba@github.com>
 <w6yn3rj2BwZrOOjqUT0hHMKyHGj_jdIshYHBN-F5TjU=.abfb17a0-e141-4062-a713-a62d8166aba0@github.com>
 <6DD5aWK3tS7KNzuwvaDPlf89JKRoTiyhO1dxDSr-LcI=.9974da7c-4ab0-4e47-b5f0-e3798e0c4776@github.com>
Message-ID: <KCOMQbV1fZymqU2dWWThPOkuPtTA8Q5nOHTYwm9ZD3o=.1d29873a-8654-446e-b81e-d6b1e75f0e3b@github.com>

On Wed, 7 Dec 2022 19:40:45 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Yes. That's the problem referencing the external site for information. Unfortunately the documentation layout on midi site changed and one needs to read trough all of it to figure out the correct path that both relates to the midi-1.0 standard that we support and is not overwritten by some later addendum making it non-informative.
>
> We might want to track this under some issue, if not done already.

Created JDK-8298319 to track this issue.

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

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


From serb at openjdk.org  Wed Dec  7 20:30:07 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Dec 2022 20:30:07 GMT
Subject: RFR: 4365952: Cannot disable JFileChooser
In-Reply-To: <PUgQT39rFt8h5SeaWsB73msIGFlZPGqnQmhoZET0i5U=.8a1828e6-39ca-4267-9e72-1bf3c1c6a226@github.com>
References: <0Pc6eSRN_L1pKaaKHb3-af86bTOyMn6oJ9wfC1LOvjA=.a6aa5a9e-58bb-4ca3-847c-0d7ad1473faf@github.com>
 <qL0vp6t4z-C4FkX8nnZHeffTmIw2yyTQQ6toL2Sb1Lg=.f629cd98-3ccb-45da-8c90-8f8b13ce5300@github.com>
 <PUgQT39rFt8h5SeaWsB73msIGFlZPGqnQmhoZET0i5U=.8a1828e6-39ca-4267-9e72-1bf3c1c6a226@github.com>
Message-ID: <0TqJ4e6TSzKz0QgGNTdfAvjTKfXq969V95YyMq97_Xc=.abf8a67a-1be4-4464-afa7-401b7c963f72@github.com>

On Wed, 7 Dec 2022 11:37:30 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JFileChooser.java line 420:
>> 
>>> 418: 
>>> 419:     @Override
>>> 420:     public void setEnabled(boolean enabled) {
>> 
>> Can you please check why a similar example using JFrame and button works fine, but the JFileChooser does not work?
>> 
>>         JFrame frame = new JFrame();
>>         JButton button = new JButton("1234567890");
>>         frame.add(button);
>>         frame.setVisible(true);
>>         frame.setEnabled(false);
>>         boolean enabled = button.isEnabled();
>>         System.out.println("enabled = " + enabled);
>
> JFileChooser added to a JFrame similar to the example also works, I guess it's because frame is made inaccessible. But when we try to disable JFileChooser alone, it's not working because we need to disable each sub-component in which JFileChooser is made up of. As per debugging I found out that peer component is showing null for JFileChooser.disable whereas for JFrame the disabling is taken care by peer component in Component class.

Why we cannot make inaccessible JFileChooser same as JFrame? We do not need to mark disable all components inside the frame(I guess jdialog and windows as well). Both are top level components, and probably should work in the same way.

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

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


From duke at openjdk.org  Wed Dec  7 20:38:09 2022
From: duke at openjdk.org (SWinxy)
Date: Wed, 7 Dec 2022 20:38:09 GMT
Subject: RFR: 8298240: Replace the usage of ImageLayoutException by the
 CMMException
In-Reply-To: <MugzKoEie2il8Rn7Tp4oLM0N8zg-QtGh1gsQmPPX-lE=.66e63bba-76ef-4425-8aa6-6a2350d77c24@github.com>
References: <MugzKoEie2il8Rn7Tp4oLM0N8zg-QtGh1gsQmPPX-lE=.66e63bba-76ef-4425-8aa6-6a2350d77c24@github.com>
Message-ID: <1FegRM9GhEpeeW2Un71ErWVvsmksdzYkukMJEgzqJDA=.9bb558fa-b04e-4d3e-99b7-c54a082df77f@github.com>

On Wed, 7 Dec 2022 04:07:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> ImageLayoutException is used to report any issues with image layout calculation. But since we cannot throw the unspecified exception to the application, all usages of ImageLayoutException are wrapped by the CMMException. And now if such CMMException occurs we have lost at what point the initial exception was raised.
> 
> We can pass some additional data around, but it looks like we can just delete the ImageLayoutException and use CMMException instead. 
> 
> Additionally:
>  * The `public` keyword is removed in a few places if not needed.
>  * The PT_XX flags are updated to make it clearly visible how they are related.

In another PR, CMMException should have its documentation updated. It currently says `This exception is thrown if the native CMM returns an error.` But we are also throwing it with checks in Java.

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

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

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


From kizune at openjdk.org  Wed Dec  7 21:23:53 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 7 Dec 2022 21:23:53 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip [v4]
In-Reply-To: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
Message-ID: <RI5sg7RRZy0Xsgfw6bI8aOf2esZBm75xvxDmYtVF-sI=.94c876af-afa3-435a-a451-fd339bf326a0@github.com>

> Add try/catch clause to ignore an exception since it is harmless for we isolated
> the massge data before passing it ro processor.
> Add test case.

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

  Fix the buffers length

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9016/files
  - new: https://git.openjdk.org/jdk/pull/9016/files/85c27f6f..64868838

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

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

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


From kizune at openjdk.org  Wed Dec  7 21:23:54 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 7 Dec 2022 21:23:54 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip [v2]
In-Reply-To: <6DD5aWK3tS7KNzuwvaDPlf89JKRoTiyhO1dxDSr-LcI=.9974da7c-4ab0-4e47-b5f0-e3798e0c4776@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
 <6Y4AZanzqQvl5-du1LLmS3VG9tLYTbaQr1aRWx7XV3U=.7b428208-eb6e-4a94-ba34-2e22349201fd@github.com>
 <sHhJUln007SZQWFqWlEYXZVUpSuv7fxMZW_OCNimrVg=.1229bcd8-debc-4bb3-a78a-09646b1c11ba@github.com>
 <w6yn3rj2BwZrOOjqUT0hHMKyHGj_jdIshYHBN-F5TjU=.abfb17a0-e141-4062-a713-a62d8166aba0@github.com>
 <6DD5aWK3tS7KNzuwvaDPlf89JKRoTiyhO1dxDSr-LcI=.9974da7c-4ab0-4e47-b5f0-e3798e0c4776@github.com>
Message-ID: <339GAwKQmJtae1y6VNllBVQtWXhjyIvCz6wVNIK_lB8=.0197ba99-902e-46ee-b928-4e647fe8a0bd@github.com>

On Wed, 7 Dec 2022 19:29:32 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Length check won't help here:

I think the problem here is in the original code: the array allocation was reused across 3 places and it reserved buffers for ranges and destinations that should load up the remaining of data from the offset 7, but in first two places are trying to load data from offset 6, which causes buffer overflow. The idea of my new fix here is to create a proper buffers.

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

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


From kizune at openjdk.org  Wed Dec  7 21:23:55 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 7 Dec 2022 21:23:55 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip [v2]
In-Reply-To: <339GAwKQmJtae1y6VNllBVQtWXhjyIvCz6wVNIK_lB8=.0197ba99-902e-46ee-b928-4e647fe8a0bd@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
 <6Y4AZanzqQvl5-du1LLmS3VG9tLYTbaQr1aRWx7XV3U=.7b428208-eb6e-4a94-ba34-2e22349201fd@github.com>
 <sHhJUln007SZQWFqWlEYXZVUpSuv7fxMZW_OCNimrVg=.1229bcd8-debc-4bb3-a78a-09646b1c11ba@github.com>
 <w6yn3rj2BwZrOOjqUT0hHMKyHGj_jdIshYHBN-F5TjU=.abfb17a0-e141-4062-a713-a62d8166aba0@github.com>
 <6DD5aWK3tS7KNzuwvaDPlf89JKRoTiyhO1dxDSr-LcI=.9974da7c-4ab0-4e47-b5f0-e3798e0c4776@github.com>
 <339GAwKQmJtae1y6VNllBVQtWXhjyIvCz6wVNIK_lB8=.0197ba99-902e-46ee-b928-4e647fe8a0bd@github.com>
Message-ID: <5BRZwa3JxfQvJ3RK4gLIvWyjEJ4T1JPHt_op93DTBek=.21faf94b-40e7-4f7c-9dbf-5096117e08e8@github.com>

On Wed, 7 Dec 2022 21:15:30 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Length check won't help here:
>> 
>> 
>>   int[] data = new int[100];
>>   if (data.length < 8) {
>>       return;
>>   }
>>   int[] destinations = new int[(data.length - 7) / 2];
>>   int[] ranges = new int[(data.length - 7) / 2];
>>   int ix = 0;
>>   for (int j = 6; j < data.length - 1; j += 2) {
>>       destinations[ix] = data[j] & 0xFF;
>>       ranges[ix] = data[j + 1] & 0xFF;
>>       ix++;
>>   }
>> 
>> `Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 46 out of bounds for length 46`
>> 
>> 
>> We might want to add more test cases to the test.
>
>> Length check won't help here:
> 
> I think the problem here is in the original code: the array allocation was reused across 3 places and it reserved buffers for ranges and destinations that should load up the remaining of data from the offset 7, but in first two places are trying to load data from offset 6, which causes buffer overflow. The idea of my new fix here is to create a proper buffers.

> We might want to add more test cases to the test.

That would be an extensive task, there is a set of the tests being run by third party - and that's them who created the initial issue. I do not think it is practical to bring all the cases they test here. That testing takes a very long time.

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

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


From xuelei at openjdk.org  Wed Dec  7 21:25:11 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 7 Dec 2022 21:25:11 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v18]
In-Reply-To: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
Message-ID: <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  update on review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11115/files
  - new: https://git.openjdk.org/jdk/pull/11115/files/c7dd001b..c391535c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=16-17

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

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


From xuelei at openjdk.org  Wed Dec  7 21:25:11 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 7 Dec 2022 21:25:11 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17]
In-Reply-To: <D2GcLWUTfyqFoBuUa9JXarKRz_j1xwjNSoyBTfs6PE4=.b52f7b27-acf3-40c1-8fd1-8afa2003f9bd@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
 <wtfe3m7FrVWssfUYna5S0oWNL6Xhz4UQRb-4V2tvvmc=.3356deec-bbe2-4372-ac3a-2cdc620fae67@github.com>
 <D2GcLWUTfyqFoBuUa9JXarKRz_j1xwjNSoyBTfs6PE4=.b52f7b27-acf3-40c1-8fd1-8afa2003f9bd@github.com>
Message-ID: <PdDhXspwAJltsGlRzXfAjHTdiKrZ_zW-EtOlhb6jJ9k=.01c28967-4d6e-489b-a52a-df643e353680@github.com>

On Wed, 7 Dec 2022 16:00:04 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> src/hotspot/os/bsd/attachListener_bsd.cpp line 260:
>> 
>>> 258:   // name ("load", "datadump", ...), and <arg> is an argument
>>> 259:   int expected_str_count = 2 + AttachOperation::arg_count_max;
>>> 260:   const int max_len = (ver_str_len + 1) + (AttachOperation::name_length_max + 1) +
>> 
>> This makes `max_len` a runtime variable, before it was a compile time constant. Below, we use it to create the buf array. IIRC creating an array with a variable runtime length is a non-standard compiler extension. I am surprised this even builds.
>
> better to keep sizeof(ver_str) here (const)

Updated to use sizeof.

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

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


From xuelei at openjdk.org  Wed Dec  7 21:25:13 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 7 Dec 2022 21:25:13 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17]
In-Reply-To: <wtfe3m7FrVWssfUYna5S0oWNL6Xhz4UQRb-4V2tvvmc=.3356deec-bbe2-4372-ac3a-2cdc620fae67@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
 <wtfe3m7FrVWssfUYna5S0oWNL6Xhz4UQRb-4V2tvvmc=.3356deec-bbe2-4372-ac3a-2cdc620fae67@github.com>
Message-ID: <26aqt5pBpt8pWZs7EciRLqThpaxg8LpvYSSL4Dccw14=.cdfe05cc-919d-4fa8-a0bc-75a74d845209@github.com>

On Wed, 7 Dec 2022 08:46:45 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment for snprintf_checked
>
> src/hotspot/share/adlc/output_c.cpp line 46:
> 
>> 44:   va_end(args);
>> 45:   assert(result >= 0, "snprintf error");
>> 46:   assert(static_cast<size_t>(result) < len, "snprintf truncated");
> 
> Question, what is this assert? The standard CRT assert? Will it fire always, or just in debug?

The assert is defined in adlc.hpp, as follow:
`#define assert(cond, msg) { if (!(cond)) { fprintf(stderr, "assert fails %s %d: %s\n", __FILE__, __LINE__, msg); abort(); }}
`

I think it will fire always.

> src/hotspot/share/runtime/os.cpp line 102:
> 
>> 100: }
>> 101: 
>> 102: int os::snprintf_checked(char* buf, size_t len, const char* fmt, ...) {
> 
> Can you please assert for buffer len > 0 and < some reasonable max, e.g. 1 gb? Protects us against neg overflows and other errors.

I may be hesitate for the checking. The behavior maybe unclear if a size_t value could be negative and if it is possible the max limit is too small in practice.  If it is necessary, the svnprintf() could do that instead.

> src/hotspot/share/runtime/os.cpp line 108:
> 
>> 106:   va_end(args);
>> 107:   assert(result >= 0, "os::snprintf error");
>> 108:   assert(static_cast<size_t>(result) < len, "os::snprintf truncated");
> 
> Can you please provide a printout for the truncated string? Proposal:
> 
> ```assert(static_cast<size_t>(result) < len, "os::snprintf truncated ("%.200s...")", buf);```

I'm not sure if there is sensitive information in the buf.  Dumping the string may result in sensitive information leaking.

> src/hotspot/share/utilities/utf8.cpp line 227:
> 
>> 225:     } else {
>> 226:       if (p + 6 >= end) break;      // string is truncated
>> 227:       os::snprintf_checked(p, 7, "\\u%04x", c);  // counting terminating zero in
> 
> I had to think a while until I was sure this is correct :-) 
> We are sure that c can never be > 0xFFFFFF (6 digits), right? But if that is false, code had been wrong before too.

I think so as it used to work.

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

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


From honkar at openjdk.org  Wed Dec  7 21:44:30 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 7 Dec 2022 21:44:30 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering
Message-ID: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>

In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as parameter to method.  

The following steps are common for any border scaling -

- Resetting transform.
- Calculating new width, height, x & y-translations.
- Perform the required border rendering. 
- And at the end restore the previous transform.

To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.

1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java

The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.

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

Commit messages:
 - Refactoring changes
 - Merge branch 'master' into RefactorBorder_8294484
 - revert MetalBorder changes
 - merge master
 - refactoring changes - initial commit

Changes: https://git.openjdk.org/jdk/pull/11571/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11571&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294680
  Stats: 272 lines in 4 files changed: 94 ins; 146 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/11571.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11571/head:pull/11571

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


From javalists at cbfiddle.com  Wed Dec  7 21:53:06 2022
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 7 Dec 2022 13:53:06 -0800
Subject: RFR: JDK-8294680: Refactor scaled border rendering
In-Reply-To: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
Message-ID: <DDBA75B2-4BFA-4784-BC1B-6E1827ED6DBD@cbfiddle.com>

Is there some reason why this should not be a public API?

Do you believe that only JDK-implemented borders need this functionality?


> On Dec 7, 2022, at 1:44 PM, Harshitha Onkar <honkar at openjdk.org> wrote:
> 
> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as parameter to method.  
> 
> The following steps are common for any border scaling -
> 
> - Resetting transform.
> - Calculating new width, height, x & y-translations.
> - Perform the required border rendering. 
> - And at the end restore the previous transform.
> 
> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
> 
> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
> 
> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.
> 
> -------------
> 
> Commit messages:
> - Refactoring changes
> - Merge branch 'master' into RefactorBorder_8294484
> - revert MetalBorder changes
> - merge master
> - refactoring changes - initial commit
> 
> Changes: https://git.openjdk.org/jdk/pull/11571/files
> Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11571&range=00
>  Issue: https://bugs.openjdk.org/browse/JDK-8294680
>  Stats: 272 lines in 4 files changed: 94 ins; 146 del; 32 mod
>  Patch: https://git.openjdk.org/jdk/pull/11571.diff
>  Fetch: git fetch https://git.openjdk.org/jdk pull/11571/head:pull/11571
> 
> PR: https://git.openjdk.org/jdk/pull/11571
> 



From serb at openjdk.org  Wed Dec  7 21:58:12 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Dec 2022 21:58:12 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6
In-Reply-To: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
Message-ID: <wuZm1MIPtqXsINVi-jSrAe7zSBPF4Gq7NL3gVk_XIOU=.339130ab-f82d-4aab-b858-8fea0c4be246@github.com>

On Wed, 7 Dec 2022 16:35:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>     javax.swing.text.html.parser.ParserDelegator
>     javax.swing.LayoutComparator
> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
> 
> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
> Added the warning..

I think we will need a CSR for this change.  What people think about adding this note to the documentation of the swing package?

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

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


From serb at openjdk.org  Wed Dec  7 22:01:12 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Dec 2022 22:01:12 GMT
Subject: RFR: 8298240: Replace the usage of ImageLayoutException by the
 CMMException
In-Reply-To: <1FegRM9GhEpeeW2Un71ErWVvsmksdzYkukMJEgzqJDA=.9bb558fa-b04e-4d3e-99b7-c54a082df77f@github.com>
References: <MugzKoEie2il8Rn7Tp4oLM0N8zg-QtGh1gsQmPPX-lE=.66e63bba-76ef-4425-8aa6-6a2350d77c24@github.com>
 <1FegRM9GhEpeeW2Un71ErWVvsmksdzYkukMJEgzqJDA=.9bb558fa-b04e-4d3e-99b7-c54a082df77f@github.com>
Message-ID: <4KXuFOzQtqutJNNvkVLfop9-KVRo5Tu7gv0IA-7x8-Q=.922afc68-991b-45ab-a788-eb2998aa1564@github.com>

On Wed, 7 Dec 2022 20:36:04 GMT, SWinxy <duke at openjdk.org> wrote:

> In another PR, CMMException should have its documentation updated. It currently says `This exception is thrown if the native CMM returns an error.` But we are also throwing it with checks in Java.

We throw it from the "glue code" of the native library, it could be considered to be part of the native CMM engine.

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

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


From serb at openjdk.org  Wed Dec  7 22:02:16 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Dec 2022 22:02:16 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel
In-Reply-To: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
Message-ID: <Hxtdl5xVvpzHDuf5Yh4WOQ60nWF4_LL0_MEkgHQVriY=.6b64122e-2749-4b6c-b391-5312d697bcc9@github.com>

On Wed, 7 Dec 2022 10:25:31 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> In case of GTK LAF, the current selected element was not visible due to arrowbutton is rendered in entire display area of Combobox.
> 
> The proposed fix is to set the `squareButton `property of combobox to `false `so that the arrowbutton didn't take entire combobox display area for rendering. The `getMinimumSize `method is overridden in `SynthComboBoxUI `to consider **arrowbutton insets** for combobox minimum size. 
> 
> The JCK tests mentioned in JBS seems fine with the fix. An automated test case is implemented to test in Nimbus and GTK LAF.
> 
> When swing tests are run with LAF set to Nimbus and GTK LAF, few test failures observed. 
> 
> Although CI jobs looks ok with tests run in their default set LAFs.
> 
> `open/test/jdk/javax/swing/JComboBox/TestComboBoxHeight.java` test passes if run in GTK LAF with current fix.

No it is confidential or something like that. Cannot open/view it.

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

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


From prr at openjdk.org  Wed Dec  7 22:15:45 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 7 Dec 2022 22:15:45 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6
In-Reply-To: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
Message-ID: <QB-fvCjcx_AqoOAde_RuOhoBfkFzj_JDG5snpGg24-8=.27d119b1-1a86-4000-8ba6-f94c880370d1@github.com>

On Wed, 7 Dec 2022 16:35:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>     javax.swing.text.html.parser.ParserDelegator
>     javax.swing.LayoutComparator
> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
> 
> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
> Added the warning..

Is this something that should be handled like the threading policy where the javax.swing package doc spells it out for the entire API ?
Oh, I think that's what Sergey is suggesting too.

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

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


From duke at openjdk.org  Wed Dec  7 23:32:01 2022
From: duke at openjdk.org (duke)
Date: Wed, 7 Dec 2022 23:32:01 GMT
Subject: Withdrawn: 7175396: The text on label is not painted red for Nimbus
 LaF.
In-Reply-To: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
Message-ID: <xhQzLbWdQFaGW9i_9n7BAvSznTZTU2JPpgcz-WhXSD8=.86a7a22e-7510-4416-a108-7978da6f2436@github.com>

On Wed, 17 Aug 2022 10:46:07 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

This pull request has been closed without being integrated.

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

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


From azvegint at openjdk.org  Wed Dec  7 23:43:08 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 7 Dec 2022 23:43:08 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip [v4]
In-Reply-To: <RI5sg7RRZy0Xsgfw6bI8aOf2esZBm75xvxDmYtVF-sI=.94c876af-afa3-435a-a451-fd339bf326a0@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
 <RI5sg7RRZy0Xsgfw6bI8aOf2esZBm75xvxDmYtVF-sI=.94c876af-afa3-435a-a451-fd339bf326a0@github.com>
Message-ID: <YcsY3pwVd6dGo6_PYYtJ7zE3wB0TBEqy9pQMg3bav64=.f4a682ad-4d39-414e-b564-bca7252da0dc@github.com>

On Wed, 7 Dec 2022 21:23:53 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Add try/catch clause to ignore an exception since it is harmless for we isolated
>> the massge data before passing it ro processor.
>> Add test case.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the buffers length

Marked as reviewed by azvegint (Reviewer).

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

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


From kizune at openjdk.org  Thu Dec  8 00:34:57 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 8 Dec 2022 00:34:57 GMT
Subject: Integrated: 8282578: AIOOBE in javax.sound.sampled.Clip
In-Reply-To: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
Message-ID: <5w9jel-nlonyJ7XlqM1F6VLaiBlYNcUaT7ngJFTO0pg=.c978e90d-d3db-40c9-9366-4e73798a630b@github.com>

On Fri, 3 Jun 2022 15:43:39 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add try/catch clause to ignore an exception since it is harmless for we isolated
> the massge data before passing it ro processor.
> Add test case.

This pull request has now been integrated.

Changeset: af8fb7ee
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af8fb7eef7188ef762399cfb3faf5c8afd49efa7
Stats:     545 lines in 4 files changed: 295 ins; 105 del; 145 mod

8282578: AIOOBE in javax.sound.sampled.Clip

Reviewed-by: prr, aivanov, azvegint

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

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


From xuelei at openjdk.org  Thu Dec  8 03:23:04 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 8 Dec 2022 03:23:04 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v18]
In-Reply-To: <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
Message-ID: <v1J6TyDfIHfEuNV7RMx7hhK722imh9R3ZCYIUF_HOpE=.b267add0-86c2-4197-9e8c-81c32bcdd908@github.com>

On Wed, 7 Dec 2022 21:25:11 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update on review feedback

> With the exception of these errors in cmstypes.c
> 
> /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter] void *Type_ProfileSequenceId_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag) ^ /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter] void *Type_Dictionary_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag) ^ 2 errors generated.
> 
> I had seen this sometime back. The same workaround of adding?
> 
> cmsUNUSED_PARAMETER(SizeOfTag); // mjh
> 
> To the two methods, which I had noticed included elsewhere in the code, still appears to work.
> 

The SizeOfTag issue was tracked with https://bugs.openjdk.org/browse/JDK-8283221.

> I first noticed the sprintf issue in later releases of Xcode 13. It isn?t just Xcode 14.
> 

In the [Apple Developer Documentation](https://developer.apple.com/documentation/kernel/1441083-sprintf), there is a note for sprintf, "macOS 10.12?10.13.1 Deprecated".  It looks like that deprecation was backported.

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

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


From psadhukhan at openjdk.org  Thu Dec  8 03:30:54 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Dec 2022 03:30:54 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v2]
In-Reply-To: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
Message-ID: <yQQU4s_yWiqunO7oXEMNDGdiUu6EowQaYENe6e9lfgQ=.ea18abeb-8131-4a4a-8d5f-d9476bd9e07a@github.com>

> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>     javax.swing.text.html.parser.ParserDelegator
>     javax.swing.LayoutComparator
> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
> 
> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
> Added the warning..

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

 - Serialzation warning added in javax.swing package
 - Serialzation warning added in javax.swing package

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11565/files
  - new: https://git.openjdk.org/jdk/pull/11565/files/bbb0dfd0..1994358f

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

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

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


From psadhukhan at openjdk.org  Thu Dec  8 03:35:36 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Dec 2022 03:35:36 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v3]
In-Reply-To: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
Message-ID: <GCrCS28sHhTRu2AhNkS1EY1WYpxl3bCvIgCwiRg_ZWk=.aafb1f54-fea2-4f76-bfbf-c473caee9459@github.com>

> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>     javax.swing.text.html.parser.ParserDelegator
>     javax.swing.LayoutComparator
> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
> 
> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
> Added the warning..

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

 - Serialzation warning added in javax.swing package
 - Serialzation warning added in javax.swing package

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11565/files
  - new: https://git.openjdk.org/jdk/pull/11565/files/1994358f..22fb52f4

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

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

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


From psadhukhan at openjdk.org  Thu Dec  8 03:35:38 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Dec 2022 03:35:38 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v2]
In-Reply-To: <yQQU4s_yWiqunO7oXEMNDGdiUu6EowQaYENe6e9lfgQ=.ea18abeb-8131-4a4a-8d5f-d9476bd9e07a@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
 <yQQU4s_yWiqunO7oXEMNDGdiUu6EowQaYENe6e9lfgQ=.ea18abeb-8131-4a4a-8d5f-d9476bd9e07a@github.com>
Message-ID: <iSDSsl4vgprRsDZjQXLBqBYTykcTb8Ri05eW-awJNp4=.e275d980-6c85-440b-90c8-5a3e1b583385@github.com>

On Thu, 8 Dec 2022 03:30:54 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>>     javax.swing.text.html.parser.ParserDelegator
>>     javax.swing.LayoutComparator
>> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
>> 
>> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
>> Added the warning..
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Serialzation warning added in javax.swing package
>  - Serialzation warning added in javax.swing package

OK. Added the same in javax.swing package..
Retained individual class too as the warnings are present in other classes too

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

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


From psadhukhan at openjdk.org  Thu Dec  8 03:38:31 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Dec 2022 03:38:31 GMT
Subject: RFR: 8244400: MenuItem may cache the size and did not update it
 when the screen DPI is changed [v3]
In-Reply-To: <-uTiC-hv_VAqzznPs2lyYbPFmjJ06PIGZZCbEfuwPgE=.6d97f3a5-bd81-4697-9299-0e7039e2d9c2@github.com>
References: <-uTiC-hv_VAqzznPs2lyYbPFmjJ06PIGZZCbEfuwPgE=.6d97f3a5-bd81-4697-9299-0e7039e2d9c2@github.com>
Message-ID: <3PaNLLK-YJG2ccMZRXvhk7R_KsdTIBUX7jseDNo_BYU=.b1a73ab8-a80b-487b-9274-a2cd699ef815@github.com>

> The MenuItemLayoutHelper.clearUsedParentClientProperties must be called automatically when the DPI was changed. 
> Workaround added in the test for this bug is removed.
> 
> CI tests are ok.

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

  Revert Motif

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11551/files
  - new: https://git.openjdk.org/jdk/pull/11551/files/51feefa5..f4d23947

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

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

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


From mik3hall at gmail.com  Thu Dec  8 03:50:20 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 7 Dec 2022 21:50:20 -0600
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v18]
In-Reply-To: <v1J6TyDfIHfEuNV7RMx7hhK722imh9R3ZCYIUF_HOpE=.b267add0-86c2-4197-9e8c-81c32bcdd908@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
 <v1J6TyDfIHfEuNV7RMx7hhK722imh9R3ZCYIUF_HOpE=.b267add0-86c2-4197-9e8c-81c32bcdd908@github.com>
Message-ID: <ADEEF9C2-BBA4-41D8-9D64-0B5CD52D9862@gmail.com>



> On Dec 7, 2022, at 9:23 PM, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:
> 
> On Wed, 7 Dec 2022 21:25:11 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org <mailto:xuelei at openjdk.org>> wrote:
> 
>>> Hi,
>>> 
>>> May I have this update reviewed?
>>> 
>>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>>> 
>>> Thanks,
>>> Xuelei
>> 
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  update on review feedback
> 
>> With the exception of these errors in cmstypes.c
>> 
>> /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter] void *Type_ProfileSequenceId_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag) ^ /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter] void *Type_Dictionary_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag) ^ 2 errors generated.
>> 
>> I had seen this sometime back. The same workaround of adding?
>> 
>> cmsUNUSED_PARAMETER(SizeOfTag); // mjh
>> 
>> To the two methods, which I had noticed included elsewhere in the code, still appears to work.
>> 
> 
> The SizeOfTag issue was tracked with https://bugs.openjdk.org/browse/JDK-8283221 <https://bugs.openjdk.org/browse/JDK-8283221>.

Sorry, I should of mentioned that I had come across this bug report the first time I had this issue. I don?t think it was closed at the time. The --disable-warnings-as-errors seemed the only suggested workaround at the time. I thought mine was better. I?m not very familiar with these things but I assume that the fix for that bug hasn?t been merged into your pull request yet, but will be at some point.

> 
>> I first noticed the sprintf issue in later releases of Xcode 13. It isn?t just Xcode 14.
>> 
> 
> In the [Apple Developer Documentation](https://developer.apple.com/documentation/kernel/1441083-sprintf <https://developer.apple.com/documentation/kernel/1441083-sprintf>), there is a note for sprintf, "macOS 10.12?10.13.1 Deprecated".  It looks like that deprecation was backported.

I installed an old Xcode (13.1) version. Which wasn?t a very easy process and probably only was possible since I have an Apple developer account to get the download. The next time I had gone into Xcode it forced an update to 14. I have continued to use the 13.1 to allow jdk builds until trying yours with 14.1. It worked as indicated.

Thanks for the reply.
 
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/11115 <https://git.openjdk.org/jdk/pull/11115>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221207/f5f9a99a/attachment.htm>

From tr at openjdk.org  Thu Dec  8 04:38:54 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 8 Dec 2022 04:38:54 GMT
Subject: Integrated: 8296198: JFileChooser throws InternalError
 java.lang.InternalError with Windows shortcuts
In-Reply-To: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>
References: <6HjnmVSwd8FdUm4DZUkZA0a2XXt_rXMNk0R7j3fvwRk=.ce150227-07a6-4da1-a982-c4cfa9e142f5@github.com>
Message-ID: <BHP-ghPmz-zFGBohWs47S94IUbtSwvWTP2d0bwkhSoM=.6eb72553-e678-4933-93a6-bc875df6d8db@github.com>

On Mon, 5 Dec 2022 11:35:11 GMT, Tejesh R <tr at openjdk.org> wrote:

> When `JFileChooser` uses custom `FileSystemView`, traversing to link/shortcut to a folder throw `InternalError java.lang.InternalError ` in Windows. The issue found out to be in BasicFileChooserUI class which was unable to resolve the link path during directory setting. The `UsesShellFolder` check expects the FileSystemView to be of WindowsFileSystemView, which fails when custom FileSystemView is used.
> The fix includes resolving the link folder when custom File System View is used and has manual test. (Fix is test in CI system and no regression caused).

This pull request has now been integrated.

Changeset: d5cf18e7
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5cf18e7fb591185eecb042bfa015609ea7d15e0
Stats:     238 lines in 2 files changed: 225 ins; 4 del; 9 mod

8296198: JFileChooser throws InternalError java.lang.InternalError with Windows shortcuts

Reviewed-by: serb, abhiscxk

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

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


From psadhukhan at openjdk.org  Thu Dec  8 04:40:35 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Dec 2022 04:40:35 GMT
Subject: RFR: 8298323: trivial typo in JOptionPane.OK_OPTION
Message-ID: <NZhx6Y2vKFDaU_rdiyd0ciwpXrmhB_GbSC3sA8msK5E=.70a763b5-3e15-454c-b3dc-6ddb53f5cf15@github.com>

Typo rectified

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

Commit messages:
 - trivial typo in JOptionPane.OK_OPTION

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

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


From tr at openjdk.org  Thu Dec  8 05:06:04 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 8 Dec 2022 05:06:04 GMT
Subject: RFR: 4365952: Cannot disable JFileChooser
In-Reply-To: <0TqJ4e6TSzKz0QgGNTdfAvjTKfXq969V95YyMq97_Xc=.abf8a67a-1be4-4464-afa7-401b7c963f72@github.com>
References: <0Pc6eSRN_L1pKaaKHb3-af86bTOyMn6oJ9wfC1LOvjA=.a6aa5a9e-58bb-4ca3-847c-0d7ad1473faf@github.com>
 <qL0vp6t4z-C4FkX8nnZHeffTmIw2yyTQQ6toL2Sb1Lg=.f629cd98-3ccb-45da-8c90-8f8b13ce5300@github.com>
 <PUgQT39rFt8h5SeaWsB73msIGFlZPGqnQmhoZET0i5U=.8a1828e6-39ca-4267-9e72-1bf3c1c6a226@github.com>
 <0TqJ4e6TSzKz0QgGNTdfAvjTKfXq969V95YyMq97_Xc=.abf8a67a-1be4-4464-afa7-401b7c963f72@github.com>
Message-ID: <h22R-UBZ6rYPVM_NzfAxrL7O8VfO27Wibcp1tcF3hc4=.66183c3d-10fd-4dfa-849a-8a70d80803cf@github.com>

On Wed, 7 Dec 2022 20:27:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> JFileChooser added to a JFrame similar to the example also works, I guess it's because frame is made inaccessible. But when we try to disable JFileChooser alone, it's not working because we need to disable each sub-component in which JFileChooser is made up of. As per debugging I found out that peer component is showing null for JFileChooser.disable whereas for JFrame the disabling is taken care by peer component in Component class.
>
> Why we cannot make inaccessible JFileChooser same as JFrame? We do not need to mark disable all components inside the frame(I guess jdialog and windows as well). Both are top level components, and probably should work in the same way.

I guess for frame, the disable/enable functionality is handled by the peer (Windows it is `WFramePeer`), whereas for the swing components it should be the components itself like it is for all other components (Like in AbstractButton, JComboBox, JList).

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

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


From kizune at openjdk.org  Thu Dec  8 05:31:12 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 8 Dec 2022 05:31:12 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus
In-Reply-To: <bwZOldi_Ad40uVp3MIJTAqSJCztBfjVxsF8z661AN94=.5168abd0-a31d-4ae1-ad30-7ec2b620ad6e@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <e7ITSsOpcKtlC2bJNzIM3PFCUcoRZdfRi0mr1JxsgFE=.f37d4fe5-6a07-427c-b87f-b0ba50efcc6c@github.com>
 <VUwbo01Ivv81AevheTugl-_xosvdnzR7jhFhJtdViaE=.493aee6b-d32a-4258-8271-b25a281273d8@github.com>
 <xJz52QqQG3jjK_eODsEXefcjWz7dfCLa29VepSCwYtE=.1757660e-6211-4917-9a41-e9d5908ccecc@github.com>
 <sl_FDZPPaLyWqv74FBu0aJwzSvRgIwrT_Lj8TF3AtpU=.1dddf19e-c2b6-48ba-b477-dc685bbc1efb@github.com>
 <Pfc1L8tORSVPgNs51CRj0MkEF0EtbOIt7-gnmpswjDA=.1b49bc05-0a92-4c54-805d-54815983e2be@github.com>
 <2XePfo1gtNAWJvM5ECfg8Vkp8VObLOyQmM8WkQDiabM=.43f5d635-9352-4cc8-b9d9-e76aa710064d@github.com>
 <bwZOldi_Ad40uVp3MIJTAqSJCztBfjVxsF8z661AN94=.5168abd0-a31d-4ae1-ad30-7ec2b620ad6e@github.com>
Message-ID: <oCIy6x1tlZsFtQqokU5PVFFZcs0jOxccr8dYkyJ7uXE=.4d9fc026-99f2-4cfb-9cec-4facbed01226@github.com>

On Wed, 7 Dec 2022 10:52:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > The library does not provide an ability to set caret to visible permanently in case of text component being non-editable. Every time focus will change the caret will change too. One would have to implement a custom caret that overrides this logic.
> 
> If that is not possible I suggest providing that functionality so applications will be able to use that. Probably even provide some predefined cursors, like "faded"/"blurred"/nonblinked/etc. That could be configured per L&F as well.

That would be a nice feature to have but right now we have an issue where default behaviour of the component defies the VPAT guidelines. We can argue about the type of cursor to use but lack of caret makes focus invisible and keyboard selection - while possible - very clunky. So i stay by my decision to avoid hiding the caret and make it non-blinking so we can easily distinguish between editable and non-editable text components. If and when in the future we add the better caret support for text states we might make the default non-editable caret faded or dithered or something along the lines but for now i propose this.

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

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


From duke at openjdk.org  Thu Dec  8 05:38:58 2022
From: duke at openjdk.org (SWinxy)
Date: Thu, 8 Dec 2022 05:38:58 GMT
Subject: RFR: 8298323: trivial typo in JOptionPane.OK_OPTION
In-Reply-To: <NZhx6Y2vKFDaU_rdiyd0ciwpXrmhB_GbSC3sA8msK5E=.70a763b5-3e15-454c-b3dc-6ddb53f5cf15@github.com>
References: <NZhx6Y2vKFDaU_rdiyd0ciwpXrmhB_GbSC3sA8msK5E=.70a763b5-3e15-454c-b3dc-6ddb53f5cf15@github.com>
Message-ID: <eGmvZDTHDhhMDrViXPoAm5skIovX0W-C6R1PdTLekqY=.ea81e59f-b534-4931-a9d6-227c7fc5d206@github.com>

On Thu, 8 Dec 2022 04:31:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Typo rectified

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

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

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


From jwaters at openjdk.org  Thu Dec  8 05:55:45 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 8 Dec 2022 05:55:45 GMT
Subject: RFR: 4756278: RFE: Insufficient API documentation for
 java.awt.Polygon constructor
In-Reply-To: <9otBlr_WO5rFZBwviZn2QgLr9HonjWkVHYKpKlgwrFI=.ad0b8fd2-4890-4795-84c8-b21f6485d760@github.com>
References: <6ZyhGs5SlC42FDN3ToVFR1XybAsdWBTYzu3JBf_Pxsk=.1813b436-3c16-4686-bc0f-52b7039adb63@github.com>
 <9otBlr_WO5rFZBwviZn2QgLr9HonjWkVHYKpKlgwrFI=.ad0b8fd2-4890-4795-84c8-b21f6485d760@github.com>
Message-ID: <RUnFO2CIC6CBZV1VWPlOqQi1Hc_lFvIrbzyvcQuU3p0=.92c1b9df-1778-4880-aad8-ab12bc1a25df@github.com>

On Fri, 30 Sep 2022 22:28:40 GMT, SWinxy <duke at openjdk.org> wrote:

>> Appends: `, copying the array contents of {@code xpoints} and {@code ypoints}` to specify that the arrays in the constructor are explicitly copied.
>
> The projects page on openjdk.org says that two integrated PRs are required, but I only have one and I fear that I will waste Mark Reinhold's time asking for author permissions without meeting the criteria. I was hoping these two doc issues were small enough to get me there, but alas. And I agree that asking for others to be my proxy isn't a great balance--it sucks for them and sucks for me. I guess I'll find some other fixes in the meantime...

@SWinxy No worries, I've caught up to your CSR issues, this one is at https://bugs.openjdk.org/browse/JDK-8298351

Sorry for taking so long, I've been pretty busy

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

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


From jwaters at openjdk.org  Thu Dec  8 05:58:11 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 8 Dec 2022 05:58:11 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled
In-Reply-To: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
Message-ID: <VVEC1ZJgSA5skJ7MbZxF8Ve5O-s0cV94H44WsyBK_Hs=.288fd71f-c9ef-4293-bfe1-c0b07a365507@github.com>

On Tue, 4 Oct 2022 22:52:30 GMT, SWinxy <duke at openjdk.org> wrote:

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

CSR at https://bugs.openjdk.org/browse/JDK-8298350, no worries

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

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


From iris at openjdk.org  Thu Dec  8 06:56:59 2022
From: iris at openjdk.org (Iris Clark)
Date: Thu, 8 Dec 2022 06:56:59 GMT
Subject: RFR: 8298323: trivial typo in JOptionPane.OK_OPTION
In-Reply-To: <NZhx6Y2vKFDaU_rdiyd0ciwpXrmhB_GbSC3sA8msK5E=.70a763b5-3e15-454c-b3dc-6ddb53f5cf15@github.com>
References: <NZhx6Y2vKFDaU_rdiyd0ciwpXrmhB_GbSC3sA8msK5E=.70a763b5-3e15-454c-b3dc-6ddb53f5cf15@github.com>
Message-ID: <_qm7coSPOOvYmOWi1AcaY77c76HvWeuKjBliOp8pZY0=.1b440efa-3e2b-4916-88c4-1dd8ff8b7268@github.com>

On Thu, 8 Dec 2022 04:31:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Typo rectified

Marked as reviewed by iris (Reviewer).

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

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


From psadhukhan at openjdk.org  Thu Dec  8 07:19:34 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Dec 2022 07:19:34 GMT
Subject: Integrated: 8298323: trivial typo in JOptionPane.OK_OPTION
In-Reply-To: <NZhx6Y2vKFDaU_rdiyd0ciwpXrmhB_GbSC3sA8msK5E=.70a763b5-3e15-454c-b3dc-6ddb53f5cf15@github.com>
References: <NZhx6Y2vKFDaU_rdiyd0ciwpXrmhB_GbSC3sA8msK5E=.70a763b5-3e15-454c-b3dc-6ddb53f5cf15@github.com>
Message-ID: <JeZpJ9oTCjSQzXBwYLnFKpkdh_5PqQKL0_rUBLzCrDM=.c9b11bf8-65c4-42e5-ad8a-34d37a526b6f@github.com>

On Thu, 8 Dec 2022 04:31:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Typo rectified

This pull request has now been integrated.

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

8298323: trivial typo in JOptionPane.OK_OPTION

Reviewed-by: iris

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

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


From serb at openjdk.org  Thu Dec  8 07:54:01 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Dec 2022 07:54:01 GMT
Subject: RFR: 8244400: MenuItem may cache the size and did not update it
 when the screen DPI is changed [v3]
In-Reply-To: <3PaNLLK-YJG2ccMZRXvhk7R_KsdTIBUX7jseDNo_BYU=.b1a73ab8-a80b-487b-9274-a2cd699ef815@github.com>
References: <-uTiC-hv_VAqzznPs2lyYbPFmjJ06PIGZZCbEfuwPgE=.6d97f3a5-bd81-4697-9299-0e7039e2d9c2@github.com>
 <3PaNLLK-YJG2ccMZRXvhk7R_KsdTIBUX7jseDNo_BYU=.b1a73ab8-a80b-487b-9274-a2cd699ef815@github.com>
Message-ID: <eg1jRrXy1Yt-PPs374600Ji5knP5TgYRqmETYg64-Sg=.c213c7c2-5029-4150-82b2-863d45812d51@github.com>

On Thu, 8 Dec 2022 03:38:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The MenuItemLayoutHelper.clearUsedParentClientProperties must be called automatically when the DPI was changed. 
>> Workaround added in the test for this bug is removed.
>> 
>> CI tests are ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Motif

Marked as reviewed by serb (Reviewer).

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

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


From alexey.ushakov at jetbrains.com  Thu Dec  8 08:20:08 2022
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Thu, 8 Dec 2022 09:20:08 +0100
Subject: Quick fix for openjdk20
In-Reply-To: <ae90ff4d-bb8b-ec73-71ad-4c2c7394b032@oracle.com>
References: <CAKjRUT4muRHUfd8zA0k8OpWLJJLtFmgfBwHA08njYPL3g4U8fA@mail.gmail.com>
 <7C1FA120-8A68-4805-A507-7D7ADF6BDBB1@jetbrains.com>
 <ae90ff4d-bb8b-ec73-71ad-4c2c7394b032@oracle.com>
Message-ID: <C17B6F27-00B1-4026-8F2B-400E1F82E5A5@jetbrains.com>

> 
> FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes
> time for these things to be discovered.
Could you provide some more details concerning the regression? We also faced with a regression in metal rendering (https://youtrack.jetbrains.com/issue/JBR-4849 ). It was caused by https://bugs.openjdk.org/browse/JDK-8288948 (that we back ported into OpenJDK17 based runtime). 

Best Regards,
Alexey

> On Dec 7, 2022, at 7:22 PM, Philip Race <philip.race at oracle.com> wrote:
> 
> This is clearly too late for JDK 20 and JDK 21 will be just 6 months later so it is a better time for that.
> FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes
> time for these things to be discovered.
> Also I had a bug / rfe for this a while back : https://bugs.openjdk.org/browse/JDK-8233037
> I closed it as WNF because I wasn't able to see a performance boost.
> 
> So the right way to do this is  to provide some solid evidence of what gets faster and what gets
> slower with a range of different values (not just the JBR one) and re-open that bug and resolve early in 21.
> 
> -phil.
> 
> 
> On 12/7/22 7:36 AM, Alexey Ushakov wrote:
>> Yes, I confirm that we?ve been using such enlarged buffer for a long time in production. It helped us with scrolling performance on 4K monitors. The suggested property could help to adjust the buffer for the needs of particular application.
>> 
>> Best Regards,
>> Alexey
>> 
>>> On 7 Dec 2022, at 11:37, Laurent Bourg?s <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> For years, JetBrains Runtime uses a larger render queue buffer size (32kb to 6,400,000 bytes) in production, as it boosted many accelerated pipelines: d3d, ogl, metal :
>>> ~ 10 to 20% on large fills...
>>> 
>>> JBR RenderQueue:
>>> https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75
>>> 
>>> JDK RenderQueue:
>>> https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75
>>> 
>>> I want to propose such quick fix in openjdk20 today, as a 1-line fix.
>>> 
>>> 
>>> /** The size of the underlying buffer, in bytes. */
>>> private static final int BUFFER_SIZE = 6400000;
>>> 
>>> To ensure a smooth transition, I prefer introducing a new sun.java2d.render.queue system property to increase the default (32kb) buffer capacity:
>>> 
>>> See in marlin:
>>> https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78
>>> 
>>> So here is my current proposal:
>>> [[[
>>> 
>>> /** The size of the underlying buffer, in bytes. */
>>> private static final int BUFFER_SIZE;
>>> 
>>> static {
>>> // Default 32K is too small for high-end GPU:
>>> BUFFER_SIZE = align(getInteger("sun.java2d.render.bufferSize", 32 * 1024, 32 * 1024, 16 * 1024 * 1024), 1024);
>>> 
>>> // System.out.println("RenderQueue: sun.java2d.render.bufferSize = " + BUFFER_SIZE);
>>> }
>>> 
>>>     // system property utilities
>>>     public static int getInteger(final String key, final int def,
>>>                                  final int min, final int max)
>>>     {
>>>         final String property = AccessController.doPrivileged(
>>>                                     new GetPropertyAction(key));
>>> 
>>>         int value = def;
>>>         if (property != null) {
>>>             try {
>>>                 value = Integer.decode(property);
>>>             } catch (NumberFormatException e) {
>>>                 System.out.println("Invalid integer value for " + key + " = " + property);
>>>             }
>>>         }
>>> 
>>>         // check for invalid values
>>>         if ((value < min) || (value > max)) {
>>>             System.out.println("Invalid value for " + key + " = " + value
>>>                     + "; expected value in range[" + min + ", " + max + "] !");
>>>             value = def;
>>>         }
>>>         return value;
>>>     }
>>> 
>>>     protected static int align(final int val, final int norm) {
>>>         final int ceil = (int)Math.ceil( ((float) val) / norm);
>>>         return ceil * norm;
>>>     }
>>> ]]]
>>> 
>>> Would you accept such late change for openjdk20 ?
>>> 
>>> Cheers,
>>> Laurent Bourg?s 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221208/515f18af/attachment.htm>

From psadhukhan at openjdk.org  Thu Dec  8 08:29:05 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Dec 2022 08:29:05 GMT
Subject: RFR: 8298083: The
 "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working
In-Reply-To: <E_b75HPvqrnncD1Khq4tEIWWOweZmFtWBck2Gv7hYFs=.59719e7e-341a-4958-bc69-9ddb3c3c9eea@github.com>
References: <E_b75HPvqrnncD1Khq4tEIWWOweZmFtWBck2Gv7hYFs=.59719e7e-341a-4958-bc69-9ddb3c3c9eea@github.com>
Message-ID: <LhxtvKoMz3VmGibnkI_STW7RRFS7bSBMUHSjeGjP1Po=.85c1beb7-4dd5-4e5a-b39a-fcfe566f9669@github.com>

On Tue, 6 Dec 2022 09:18:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> We have two types of properties in Swing, the "basics": were implemented a long time ago. Some of that properties are tested by the bug4314194 test. And other properties implemented as part of the Synth L&F, and based on it - Nimbus/GTK. Attempt to fix the issue reported by bug4314194 added support of two "basic" options to the Nimbus/GTK but at the same time broke the Synth/Nimbus properties. It is unclear what is the root cause and how these properties should work together(should they? I assume each "basic"/"synth" should support its own) I suggest to revert the changes in 20 to prevent the regression and rethink the solution later.
> 
> In short, this is a request to revert the next fixes:
>  * https://bugs.openjdk.org/browse/JDK-8075916 - for some reason broke the Synth/Nimbus properties
>  * https://bugs.openjdk.org/browse/JDK-8295006 - This uses the same approach as the fix above
> The next two issues created to redo both:
>  * https://bugs.openjdk.org/browse/JDK-8298149
>  * https://bugs.openjdk.org/browse/JDK-8298153

Marked as reviewed by psadhukhan (Reviewer).

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

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


From serb at openjdk.org  Thu Dec  8 08:29:52 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Dec 2022 08:29:52 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus
In-Reply-To: <oCIy6x1tlZsFtQqokU5PVFFZcs0jOxccr8dYkyJ7uXE=.4d9fc026-99f2-4cfb-9cec-4facbed01226@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <e7ITSsOpcKtlC2bJNzIM3PFCUcoRZdfRi0mr1JxsgFE=.f37d4fe5-6a07-427c-b87f-b0ba50efcc6c@github.com>
 <VUwbo01Ivv81AevheTugl-_xosvdnzR7jhFhJtdViaE=.493aee6b-d32a-4258-8271-b25a281273d8@github.com>
 <xJz52QqQG3jjK_eODsEXefcjWz7dfCLa29VepSCwYtE=.1757660e-6211-4917-9a41-e9d5908ccecc@github.com>
 <sl_FDZPPaLyWqv74FBu0aJwzSvRgIwrT_Lj8TF3AtpU=.1dddf19e-c2b6-48ba-b477-dc685bbc1efb@github.com>
 <Pfc1L8tORSVPgNs51CRj0MkEF0EtbOIt7-gnmpswjDA=.1b49bc05-0a92-4c54-805d-54815983e2be@github.com>
 <2XePfo1gtNAWJvM5ECfg8Vkp8VObLOyQmM8WkQDiabM=.43f5d635-9352-4cc8-b9d9-e76aa710064d@github.com>
 <bwZOldi_Ad40uVp3MIJTAqSJCztBfjVxsF8z661AN94=.5168abd0-a31d-4ae1-ad30-7ec2b620ad6e@github.com>
 <oCIy6x1tlZsFtQqokU5PVFFZcs0jOxccr8dYkyJ7uXE=.4d9fc026-99f2-4cfb-9cec-4facbed01226@github.com>
Message-ID: <zlaK88xn6qUJ9vQlQlUQubxVkF6kqjoi5JOQ-f-h-QY=.f3dd2f94-94fc-47bd-950e-0cdc7b5968c5@github.com>

On Thu, 8 Dec 2022 05:28:31 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> > If that is not possible I suggest providing that functionality so applications will be able to use that. Probably even provide some predefined cursors, like "faded"/"blurred"/nonblinked/etc. That could be configured per L&F as well.

> That would be a nice feature to have but right now we have an issue where default behaviour of the component defies the VPAT guidelines.

I am not sure that changing the default behavior of all text components(including embedded to other components) to use a non-blinking cursor is a good idea, you can convince me if you find someone who uses the same approach, any applications? Probably at least for the native look&feels we can use the same behavior as the native default components win32/cocoa/gtk.

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

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


From stuefe at openjdk.org  Thu Dec  8 09:07:09 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 8 Dec 2022 09:07:09 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v18]
In-Reply-To: <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
Message-ID: <9SD4Q9Q0iaiFRmRKJg-BIvEnD2OOh24o--wyY5pz9hY=.fb56475d-230b-47e0-9044-42dd930338aa@github.com>

On Wed, 7 Dec 2022 21:25:11 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update on review feedback

Good from my side. But someone else should look as well. It's fiddly stuff.

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

Marked as reviewed by stuefe (Reviewer).

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


From serb at openjdk.org  Thu Dec  8 09:12:00 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Dec 2022 09:12:00 GMT
Subject: RFR: 4365952: Cannot disable JFileChooser
In-Reply-To: <h22R-UBZ6rYPVM_NzfAxrL7O8VfO27Wibcp1tcF3hc4=.66183c3d-10fd-4dfa-849a-8a70d80803cf@github.com>
References: <0Pc6eSRN_L1pKaaKHb3-af86bTOyMn6oJ9wfC1LOvjA=.a6aa5a9e-58bb-4ca3-847c-0d7ad1473faf@github.com>
 <qL0vp6t4z-C4FkX8nnZHeffTmIw2yyTQQ6toL2Sb1Lg=.f629cd98-3ccb-45da-8c90-8f8b13ce5300@github.com>
 <PUgQT39rFt8h5SeaWsB73msIGFlZPGqnQmhoZET0i5U=.8a1828e6-39ca-4267-9e72-1bf3c1c6a226@github.com>
 <0TqJ4e6TSzKz0QgGNTdfAvjTKfXq969V95YyMq97_Xc=.abf8a67a-1be4-4464-afa7-401b7c963f72@github.com>
 <h22R-UBZ6rYPVM_NzfAxrL7O8VfO27Wibcp1tcF3hc4=.66183c3d-10fd-4dfa-849a-8a70d80803cf@github.com>
Message-ID: <mL3XuLE5dmPwZqycm29mP3Pj1tVjKXMNnOPvk4VxSFA=.071dc2fc-95d8-4979-82de-e2eaccb8c1c3@github.com>

On Thu, 8 Dec 2022 05:03:45 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Why we cannot make inaccessible JFileChooser same as JFrame? We do not need to mark disable all components inside the frame(I guess jdialog and windows as well). Both are top level components, and probably should work in the same way.
>
> I guess for frame, the disable/enable functionality is handled by the peer (Windows it is `WFramePeer`), whereas for the swing components it should be the components itself like it is for all other components (Like in AbstractButton, JComboBox, JList).

The JFileChooser is also kind of top level component and it has the peer. Current patch does not work as intended. On macOS in Nimbus/Metal L&F the list of files looks disabled but scrolling works. On Aqua L&F the list of files does not look like disabled, accept scroll and double clicks, but does not accept single clicks.

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

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


From lbourges at openjdk.org  Thu Dec  8 09:47:14 2022
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 8 Dec 2022 09:47:14 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v18]
In-Reply-To: <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
Message-ID: <UkJ3bNkFSLgngGKNO4XnQP98wRfdMcxpWfIJ-OLg82M=.fb9dcc4d-1656-43f0-8465-a41fd678d5e7@github.com>

On Wed, 7 Dec 2022 21:25:11 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update on review feedback

I will try building openjdk20 with this patch tonight on mbp 2015, macos 13, xcode 14...

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

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


From ajit.ghaisas at oracle.com  Thu Dec  8 11:38:45 2022
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Thu, 8 Dec 2022 11:38:45 +0000
Subject: Quick fix for openjdk20
In-Reply-To: <C17B6F27-00B1-4026-8F2B-400E1F82E5A5@jetbrains.com>
References: <CAKjRUT4muRHUfd8zA0k8OpWLJJLtFmgfBwHA08njYPL3g4U8fA@mail.gmail.com>
 <7C1FA120-8A68-4805-A507-7D7ADF6BDBB1@jetbrains.com>
 <ae90ff4d-bb8b-ec73-71ad-4c2c7394b032@oracle.com>
 <C17B6F27-00B1-4026-8F2B-400E1F82E5A5@jetbrains.com>
Message-ID: <02889093-418B-4BF0-8920-DEC74EFC1751@oracle.com>



On 08-Dec-2022, at 1:50 PM, Alexey Ushakov <alexey.ushakov at jetbrains.com<mailto:alexey.ushakov at jetbrains.com>> wrote:


FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes
time for these things to be discovered.
Could you provide some more details concerning the regression? We also faced with a regression in metal rendering (https://youtrack.jetbrains.com/issue/JBR-4849 ). It was caused by https://bugs.openjdk.org/browse/JDK-8288948 (that we back ported into OpenJDK17 based runtime).

The details can be found at -
https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14504772<https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14504772>

Look at the last 3 lines of that comment & attached test results to  https://bugs.openjdk.org/browse/JDK-8288948.
In the screenshots for RenderPerf and SwingMark results - the rightmost column header should read ?Integrated graphics card."


Best Regards,
Alexey

On Dec 7, 2022, at 7:22 PM, Philip Race <philip.race at oracle.com<mailto:philip.race at oracle.com>> wrote:

This is clearly too late for JDK 20 and JDK 21 will be just 6 months later so it is a better time for that.
FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes
time for these things to be discovered.
Also I had a bug / rfe for this a while back : https://bugs.openjdk.org/browse/JDK-8233037
I closed it as WNF because I wasn't able to see a performance boost.

So the right way to do this is  to provide some solid evidence of what gets faster and what gets
slower with a range of different values (not just the JBR one) and re-open that bug and resolve early in 21.

-phil.


On 12/7/22 7:36 AM, Alexey Ushakov wrote:
Yes, I confirm that we?ve been using such enlarged buffer for a long time in production. It helped us with scrolling performance on 4K monitors. The suggested property could help to adjust the buffer for the needs of particular application.

Best Regards,
Alexey

On 7 Dec 2022, at 11:37, Laurent Bourg?s <bourges.laurent at gmail.com<mailto:bourges.laurent at gmail.com>> wrote:

Hi,

For years, JetBrains Runtime uses a larger render queue buffer size (32kb to 6,400,000 bytes) in production, as it boosted many accelerated pipelines: d3d, ogl, metal :
~ 10 to 20% on large fills...

JBR RenderQueue:
https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75

JDK RenderQueue:
https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75

I want to propose such quick fix in openjdk20 today, as a 1-line fix.


/** The size of the underlying buffer, in bytes. */
private static final int BUFFER_SIZE = 6400000;

To ensure a smooth transition, I prefer introducing a new sun.java2d.render.queue system property to increase the default (32kb) buffer capacity:

See in marlin:
https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78

So here is my current proposal:
[[[

/** The size of the underlying buffer, in bytes. */
private static final int BUFFER_SIZE;

static {
// Default 32K is too small for high-end GPU:
BUFFER_SIZE = align(getInteger("sun.java2d.render.bufferSize", 32 * 1024, 32 * 1024, 16 * 1024 * 1024), 1024);

// System.out.println("RenderQueue: sun.java2d.render.bufferSize = " + BUFFER_SIZE);
}

    // system property utilities
    public static int getInteger(final String key, final int def,
                                 final int min, final int max)
    {
        final String property = AccessController.doPrivileged(
                                    new GetPropertyAction(key));

        int value = def;
        if (property != null) {
            try {
                value = Integer.decode(property);
            } catch (NumberFormatException e) {
                System.out.println("Invalid integer value for " + key + " = " + property);
            }
        }

        // check for invalid values
        if ((value < min) || (value > max)) {
            System.out.println("Invalid value for " + key + " = " + value
                    + "; expected value in range[" + min + ", " + max + "] !");
            value = def;
        }
        return value;
    }

    protected static int align(final int val, final int norm) {
        final int ceil = (int)Math.ceil( ((float) val) / norm);
        return ceil * norm;
    }
]]]

Would you accept such late change for openjdk20 ?

Cheers,
Laurent Bourg?s




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221208/2e59cb08/attachment.htm>

From ajit.ghaisas at oracle.com  Thu Dec  8 11:53:17 2022
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Thu, 8 Dec 2022 11:53:17 +0000
Subject: Quick fix for openjdk20
In-Reply-To: <02889093-418B-4BF0-8920-DEC74EFC1751@oracle.com>
References: <CAKjRUT4muRHUfd8zA0k8OpWLJJLtFmgfBwHA08njYPL3g4U8fA@mail.gmail.com>
 <7C1FA120-8A68-4805-A507-7D7ADF6BDBB1@jetbrains.com>
 <ae90ff4d-bb8b-ec73-71ad-4c2c7394b032@oracle.com>
 <C17B6F27-00B1-4026-8F2B-400E1F82E5A5@jetbrains.com>
 <02889093-418B-4BF0-8920-DEC74EFC1751@oracle.com>
Message-ID: <9B7BC276-9C61-4693-8DB3-584AEA504B12@oracle.com>



On 08-Dec-2022, at 5:08 PM, Ajit Ghaisas <ajit.ghaisas at oracle.com<mailto:ajit.ghaisas at oracle.com>> wrote:



On 08-Dec-2022, at 1:50 PM, Alexey Ushakov <alexey.ushakov at jetbrains.com<mailto:alexey.ushakov at jetbrains.com>> wrote:


FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes
time for these things to be discovered.
Could you provide some more details concerning the regression? We also faced with a regression in metal rendering (https://youtrack.jetbrains.com/issue/JBR-4849 ). It was caused by https://bugs.openjdk.org/browse/JDK-8288948 (that we back ported into OpenJDK17 based runtime).

The details can be found at -
https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14504772<https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14504772>

Look at the last 3 lines of that comment & attached test results to  https://bugs.openjdk.org/browse/JDK-8288948.
In the screenshots for RenderPerf and SwingMark results - the rightmost column header should read ?Integrated graphics card."

The reported bug is - https://bugs.openjdk.org/browse/JDK-8298217


Best Regards,
Alexey

On Dec 7, 2022, at 7:22 PM, Philip Race <philip.race at oracle.com<mailto:philip.race at oracle.com>> wrote:

This is clearly too late for JDK 20 and JDK 21 will be just 6 months later so it is a better time for that.
FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes
time for these things to be discovered.
Also I had a bug / rfe for this a while back : https://bugs.openjdk.org/browse/JDK-8233037
I closed it as WNF because I wasn't able to see a performance boost.

So the right way to do this is  to provide some solid evidence of what gets faster and what gets
slower with a range of different values (not just the JBR one) and re-open that bug and resolve early in 21.

-phil.


On 12/7/22 7:36 AM, Alexey Ushakov wrote:
Yes, I confirm that we?ve been using such enlarged buffer for a long time in production. It helped us with scrolling performance on 4K monitors. The suggested property could help to adjust the buffer for the needs of particular application.

Best Regards,
Alexey

On 7 Dec 2022, at 11:37, Laurent Bourg?s <bourges.laurent at gmail.com<mailto:bourges.laurent at gmail.com>> wrote:

Hi,

For years, JetBrains Runtime uses a larger render queue buffer size (32kb to 6,400,000 bytes) in production, as it boosted many accelerated pipelines: d3d, ogl, metal :
~ 10 to 20% on large fills...

JBR RenderQueue:
https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75

JDK RenderQueue:
https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75

I want to propose such quick fix in openjdk20 today, as a 1-line fix.


/** The size of the underlying buffer, in bytes. */
private static final int BUFFER_SIZE = 6400000;

To ensure a smooth transition, I prefer introducing a new sun.java2d.render.queue system property to increase the default (32kb) buffer capacity:

See in marlin:
https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78

So here is my current proposal:
[[[

/** The size of the underlying buffer, in bytes. */
private static final int BUFFER_SIZE;

static {
// Default 32K is too small for high-end GPU:
BUFFER_SIZE = align(getInteger("sun.java2d.render.bufferSize", 32 * 1024, 32 * 1024, 16 * 1024 * 1024), 1024);

// System.out.println("RenderQueue: sun.java2d.render.bufferSize = " + BUFFER_SIZE);
}

    // system property utilities
    public static int getInteger(final String key, final int def,
                                 final int min, final int max)
    {
        final String property = AccessController.doPrivileged(
                                    new GetPropertyAction(key));

        int value = def;
        if (property != null) {
            try {
                value = Integer.decode(property);
            } catch (NumberFormatException e) {
                System.out.println("Invalid integer value for " + key + " = " + property);
            }
        }

        // check for invalid values
        if ((value < min) || (value > max)) {
            System.out.println("Invalid value for " + key + " = " + value
                    + "; expected value in range[" + min + ", " + max + "] !");
            value = def;
        }
        return value;
    }

    protected static int align(final int val, final int norm) {
        final int ceil = (int)Math.ceil( ((float) val) / norm);
        return ceil * norm;
    }
]]]

Would you accept such late change for openjdk20 ?

Cheers,
Laurent Bourg?s





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221208/34153add/attachment.htm>

From tr at openjdk.org  Thu Dec  8 12:07:05 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 8 Dec 2022 12:07:05 GMT
Subject: RFR: 4365952: Cannot disable JFileChooser
In-Reply-To: <mL3XuLE5dmPwZqycm29mP3Pj1tVjKXMNnOPvk4VxSFA=.071dc2fc-95d8-4979-82de-e2eaccb8c1c3@github.com>
References: <0Pc6eSRN_L1pKaaKHb3-af86bTOyMn6oJ9wfC1LOvjA=.a6aa5a9e-58bb-4ca3-847c-0d7ad1473faf@github.com>
 <qL0vp6t4z-C4FkX8nnZHeffTmIw2yyTQQ6toL2Sb1Lg=.f629cd98-3ccb-45da-8c90-8f8b13ce5300@github.com>
 <PUgQT39rFt8h5SeaWsB73msIGFlZPGqnQmhoZET0i5U=.8a1828e6-39ca-4267-9e72-1bf3c1c6a226@github.com>
 <0TqJ4e6TSzKz0QgGNTdfAvjTKfXq969V95YyMq97_Xc=.abf8a67a-1be4-4464-afa7-401b7c963f72@github.com>
 <h22R-UBZ6rYPVM_NzfAxrL7O8VfO27Wibcp1tcF3hc4=.66183c3d-10fd-4dfa-849a-8a70d80803cf@github.com>
 <mL3XuLE5dmPwZqycm29mP3Pj1tVjKXMNnOPvk4VxSFA=.071dc2fc-95d8-4979-82de-e2eaccb8c1c3@github.com>
Message-ID: <C0BwKiQGZ24tlUTn-gGQM8sTUuetXghMCe2p31grLP8=.7acff792-a7f3-412a-b807-31e687157693@github.com>

On Thu, 8 Dec 2022 09:09:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I guess for frame, the disable/enable functionality is handled by the peer (Windows it is `WFramePeer`), whereas for the swing components it should be the components itself like it is for all other components (Like in AbstractButton, JComboBox, JList).
>
> The JFileChooser is also kind of top level component and it has the peer. Current patch does not work as intended. On macOS in Nimbus/Metal L&F the list of files looks disabled but scrolling works. On Aqua L&F the list of files does not look like disabled, accept scroll and double clicks, but does not accept single clicks.

I missed checking the scrolling part in macos, will check and get back on it.

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

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


From stsypanov at openjdk.org  Thu Dec  8 12:45:29 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 8 Dec 2022 12:45:29 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base
Message-ID: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>

Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like

<T> void iterate(T[] items) {
  if (items.length == 0) {
    return;
  }
  for (T item : items) {
    //...
  }
}

Here

if (items.length == 0) {
  return;
}

is redundant and can be removed as length check is performed by for-each loop.

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

Commit messages:
 - 8298380: Clean up redundant array length checks in JDK code base

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

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


From kizune at openjdk.org  Thu Dec  8 12:49:11 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 8 Dec 2022 12:49:11 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus
In-Reply-To: <zlaK88xn6qUJ9vQlQlUQubxVkF6kqjoi5JOQ-f-h-QY=.f3dd2f94-94fc-47bd-950e-0cdc7b5968c5@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <e7ITSsOpcKtlC2bJNzIM3PFCUcoRZdfRi0mr1JxsgFE=.f37d4fe5-6a07-427c-b87f-b0ba50efcc6c@github.com>
 <VUwbo01Ivv81AevheTugl-_xosvdnzR7jhFhJtdViaE=.493aee6b-d32a-4258-8271-b25a281273d8@github.com>
 <xJz52QqQG3jjK_eODsEXefcjWz7dfCLa29VepSCwYtE=.1757660e-6211-4917-9a41-e9d5908ccecc@github.com>
 <sl_FDZPPaLyWqv74FBu0aJwzSvRgIwrT_Lj8TF3AtpU=.1dddf19e-c2b6-48ba-b477-dc685bbc1efb@github.com>
 <Pfc1L8tORSVPgNs51CRj0MkEF0EtbOIt7-gnmpswjDA=.1b49bc05-0a92-4c54-805d-54815983e2be@github.com>
 <2XePfo1gtNAWJvM5ECfg8Vkp8VObLOyQmM8WkQDiabM=.43f5d635-9352-4cc8-b9d9-e76aa710064d@github.com>
 <bwZOldi_Ad40uVp3MIJTAqSJCztBfjVxsF8z661AN94=.5168abd0-a31d-4ae1-ad30-7ec2b620ad6e@github.com>
 <oCIy6x1tlZsFtQqokU5PVFFZcs0jOxccr8dYkyJ7uXE=.4d9fc026-99f2-4cfb-9cec-4facbed01226@github.com>
 <zlaK88xn6qUJ9vQlQlUQubxVkF6kqjoi5JOQ-f-h-QY=.f3dd2f94-94fc-47bd-950e-0cdc7b5968c5@github.com>
Message-ID: <IbV9yqheiG_50Wo11dSqWs7tDqjF1Hcc8XqKnt2fSeE=.6bc1a4ae-c5aa-44e7-afac-0b938d7d6c0e@github.com>

On Thu, 8 Dec 2022 08:27:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> someone who uses the same approach, any applications

Gnome on Ubuntu 22, default applications. Editable text components have blinking carets, non-editable - non-blinking ones.

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

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


From kbarrett at openjdk.org  Thu Dec  8 17:49:17 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 8 Dec 2022 17:49:17 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v18]
In-Reply-To: <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
Message-ID: <WzB-dDx87yYUsyDI-yNxxLdlo_jgC80KfSuVtbh92r8=.e2595631-3427-4af5-8d1d-b8c613431a32@github.com>

On Wed, 7 Dec 2022 21:25:11 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update on review feedback

Looks good.  A couple of minor nits that you can address or not.

src/hotspot/share/adlc/formssel.cpp line 28:

> 26: #include "adlc.hpp"
> 27: 
> 28: #define remaining_buflen(buffer, position) (sizeof(buffer) - (position - buffer))

Consider additional parenthesis, e.g. `((position) - (buffer))`.

src/hotspot/share/adlc/formssel.cpp line 1538:

> 1536:       }
> 1537:       // Add predicate to working buffer
> 1538:       snprintf_checked(s, remaining_buflen(buf, s), "/*%s*/(",(char*)i._key);

[pre-existing] the result from this snprintf could be used instead of strlen in the next line.

src/hotspot/share/adlc/output_c.cpp line 546:

> 544:     char* args = new char [36 + 1];
> 545: 
> 546:     snprintf_checked(args, 37, "0x%x, 0x%x, %u",

Instead of 37, consider `36 + 1` to be clearly from the line above.  Or give that value a name.

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

Marked as reviewed by kbarrett (Reviewer).

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


From alexey.ushakov at jetbrains.com  Thu Dec  8 19:20:43 2022
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Thu, 8 Dec 2022 20:20:43 +0100
Subject: Quick fix for openjdk20
In-Reply-To: <02889093-418B-4BF0-8920-DEC74EFC1751@oracle.com>
References: <CAKjRUT4muRHUfd8zA0k8OpWLJJLtFmgfBwHA08njYPL3g4U8fA@mail.gmail.com>
 <7C1FA120-8A68-4805-A507-7D7ADF6BDBB1@jetbrains.com>
 <ae90ff4d-bb8b-ec73-71ad-4c2c7394b032@oracle.com>
 <C17B6F27-00B1-4026-8F2B-400E1F82E5A5@jetbrains.com>
 <02889093-418B-4BF0-8920-DEC74EFC1751@oracle.com>
Message-ID: <3DFFDD9C-5DB9-4398-9A72-6E1B045083AA@jetbrains.com>

Hi Ajit,

According to the tests you?ve mentioned it?s not a big difference. Looks like we?ve faced with completely different scenario. I?ll try to figure out the main reason of the failure.

Best Regards,
Alexey 

> On Dec 8, 2022, at 12:38 PM, Ajit Ghaisas <ajit.ghaisas at oracle.com> wrote:
> 
> 
> 
>> On 08-Dec-2022, at 1:50 PM, Alexey Ushakov <alexey.ushakov at jetbrains.com <mailto:alexey.ushakov at jetbrains.com>> wrote:
>> 
>>> 
>>> FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes
>>> time for these things to be discovered.
>> Could you provide some more details concerning the regression? We also faced with a regression in metal rendering (https://youtrack.jetbrains.com/issue/JBR-4849 ). It was caused by https://bugs.openjdk.org/browse/JDK-8288948 (that we back ported into OpenJDK17 based runtime). 
> 
> The details can be found at - 
> https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14504772 <https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14504772>
> 
> Look at the last 3 lines of that comment & attached test results to  https://bugs.openjdk.org/browse/JDK-8288948.
> In the screenshots for RenderPerf and SwingMark results - the rightmost column header should read ?Integrated graphics card."
> 
>> 
>> Best Regards,
>> Alexey
>> 
>>> On Dec 7, 2022, at 7:22 PM, Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> wrote:
>>> 
>>> This is clearly too late for JDK 20 and JDK 21 will be just 6 months later so it is a better time for that.
>>> FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes
>>> time for these things to be discovered.
>>> Also I had a bug / rfe for this a while back : https://bugs.openjdk.org/browse/JDK-8233037
>>> I closed it as WNF because I wasn't able to see a performance boost.
>>> 
>>> So the right way to do this is  to provide some solid evidence of what gets faster and what gets
>>> slower with a range of different values (not just the JBR one) and re-open that bug and resolve early in 21.
>>> 
>>> -phil.
>>> 
>>> 
>>> On 12/7/22 7:36 AM, Alexey Ushakov wrote:
>>>> Yes, I confirm that we?ve been using such enlarged buffer for a long time in production. It helped us with scrolling performance on 4K monitors. The suggested property could help to adjust the buffer for the needs of particular application.
>>>> 
>>>> Best Regards,
>>>> Alexey
>>>> 
>>>>> On 7 Dec 2022, at 11:37, Laurent Bourg?s <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> For years, JetBrains Runtime uses a larger render queue buffer size (32kb to 6,400,000 bytes) in production, as it boosted many accelerated pipelines: d3d, ogl, metal :
>>>>> ~ 10 to 20% on large fills...
>>>>> 
>>>>> JBR RenderQueue:
>>>>> https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75
>>>>> 
>>>>> JDK RenderQueue:
>>>>> https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75
>>>>> 
>>>>> I want to propose such quick fix in openjdk20 today, as a 1-line fix.
>>>>> 
>>>>> 
>>>>> /** The size of the underlying buffer, in bytes. */
>>>>> private static final int BUFFER_SIZE = 6400000;
>>>>> 
>>>>> To ensure a smooth transition, I prefer introducing a new sun.java2d.render.queue system property to increase the default (32kb) buffer capacity:
>>>>> 
>>>>> See in marlin:
>>>>> https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78
>>>>> 
>>>>> So here is my current proposal:
>>>>> [[[
>>>>> 
>>>>> /** The size of the underlying buffer, in bytes. */
>>>>> private static final int BUFFER_SIZE;
>>>>> 
>>>>> static {
>>>>> // Default 32K is too small for high-end GPU:
>>>>> BUFFER_SIZE = align(getInteger("sun.java2d.render.bufferSize", 32 * 1024, 32 * 1024, 16 * 1024 * 1024), 1024);
>>>>> 
>>>>> // System.out.println("RenderQueue: sun.java2d.render.bufferSize = " + BUFFER_SIZE);
>>>>> }
>>>>> 
>>>>>     // system property utilities
>>>>>     public static int getInteger(final String key, final int def,
>>>>>                                  final int min, final int max)
>>>>>     {
>>>>>         final String property = AccessController.doPrivileged(
>>>>>                                     new GetPropertyAction(key));
>>>>> 
>>>>>         int value = def;
>>>>>         if (property != null) {
>>>>>             try {
>>>>>                 value = Integer.decode(property);
>>>>>             } catch (NumberFormatException e) {
>>>>>                 System.out.println("Invalid integer value for " + key + " = " + property);
>>>>>             }
>>>>>         }
>>>>> 
>>>>>         // check for invalid values
>>>>>         if ((value < min) || (value > max)) {
>>>>>             System.out.println("Invalid value for " + key + " = " + value
>>>>>                     + "; expected value in range[" + min + ", " + max + "] !");
>>>>>             value = def;
>>>>>         }
>>>>>         return value;
>>>>>     }
>>>>> 
>>>>>     protected static int align(final int val, final int norm) {
>>>>>         final int ceil = (int)Math.ceil( ((float) val) / norm);
>>>>>         return ceil * norm;
>>>>>     }
>>>>> ]]]
>>>>> 
>>>>> Would you accept such late change for openjdk20 ?
>>>>> 
>>>>> Cheers,
>>>>> Laurent Bourg?s 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221208/2992e13e/attachment.htm>

From xuelei at openjdk.org  Thu Dec  8 19:41:16 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 8 Dec 2022 19:41:16 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v19]
In-Reply-To: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
Message-ID: <W8Ac5RQQcrQmv0Z_dU-lwhu1ny1MjgGq7xvnObMFTlU=.c4eeee8b-535e-4394-99db-10a7918e8733@github.com>

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan 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 24 additional commits since the last revision:

 - adlc update per review
 - Merge
 - update on review feedback
 - comment for snprintf_checked
 - use checked snprintf for adlc
 - use checked snprintf
 - no check on adlc
 - revert use of assert
 - extra sizeof typo
 - more size_t updare for windows build
 - ... and 14 more: https://git.openjdk.org/jdk/compare/bc6e44f6...49bb58fd

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11115/files
  - new: https://git.openjdk.org/jdk/pull/11115/files/c391535c..49bb58fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=17-18

  Stats: 67182 lines in 1253 files changed: 30641 ins; 21894 del; 14647 mod
  Patch: https://git.openjdk.org/jdk/pull/11115.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115

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


From xuelei at openjdk.org  Thu Dec  8 19:41:21 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 8 Dec 2022 19:41:21 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v18]
In-Reply-To: <WzB-dDx87yYUsyDI-yNxxLdlo_jgC80KfSuVtbh92r8=.e2595631-3427-4af5-8d1d-b8c613431a32@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
 <WzB-dDx87yYUsyDI-yNxxLdlo_jgC80KfSuVtbh92r8=.e2595631-3427-4af5-8d1d-b8c613431a32@github.com>
Message-ID: <0_3PyFqYlLwLgoa6GvDpc6MF__wWqCahDo0niQL7VCU=.3aa55141-e361-499e-b0d4-289c971e3fec@github.com>

On Thu, 8 Dec 2022 17:19:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update on review feedback
>
> src/hotspot/share/adlc/formssel.cpp line 28:
> 
>> 26: #include "adlc.hpp"
>> 27: 
>> 28: #define remaining_buflen(buffer, position) (sizeof(buffer) - (position - buffer))
> 
> Consider additional parenthesis, e.g. `((position) - (buffer))`.

It makes sense to me.  Thanks!

> src/hotspot/share/adlc/formssel.cpp line 1538:
> 
>> 1536:       }
>> 1537:       // Add predicate to working buffer
>> 1538:       snprintf_checked(s, remaining_buflen(buf, s), "/*%s*/(",(char*)i._key);
> 
> [pre-existing] the result from this snprintf could be used instead of strlen in the next line.

I'm not very sure of why "+=" is used yet.  I would like to leave as it is.

> src/hotspot/share/adlc/output_c.cpp line 546:
> 
>> 544:     char* args = new char [36 + 1];
>> 545: 
>> 546:     snprintf_checked(args, 37, "0x%x, 0x%x, %u",
> 
> Instead of 37, consider `36 + 1` to be clearly from the line above.  Or give that value a name.

Updated to use 36 + 1.

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

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


From rriggs at openjdk.org  Thu Dec  8 20:18:16 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 8 Dec 2022 20:18:16 GMT
Subject: [jdk20] RFR: 8298402: ProblemList
 javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64
In-Reply-To: <IDrzO0bn83BMGq2bbD45FoGLG8HFjFgY4_l1gB6_kFw=.db1ece05-a190-45ae-acbf-6b6af39b640e@github.com>
References: <IDrzO0bn83BMGq2bbD45FoGLG8HFjFgY4_l1gB6_kFw=.db1ece05-a190-45ae-acbf-6b6af39b640e@github.com>
Message-ID: <gw2JK2Z5pVya7JzkGKjQPoEsoU4hcZFKKqD2tNrPnAo=.342c2db1-a676-4bba-b359-6707d3a70275@github.com>

On Thu, 8 Dec 2022 18:06:58 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix for several ProblemListings:
> [JDK-8298402](https://bugs.openjdk.org/browse/JDK-8298402) ProblemList javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64
> [JDK-8298414](https://bugs.openjdk.org/browse/JDK-8298414) ProblemList gc/TestFullGCCount.java on linux-x64
> [JDK-8298417](https://bugs.openjdk.org/browse/JDK-8298417) ProblemList vmTestbase/nsk/stress/strace/strace004.java on 2 platforms
> [JDK-8298419](https://bugs.openjdk.org/browse/JDK-8298419) ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi005/TestDescription.java on windows-x64

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/1


From dcubed at openjdk.org  Thu Dec  8 20:20:26 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 8 Dec 2022 20:20:26 GMT
Subject: [jdk20] RFR: 8298402: ProblemList
 javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64
In-Reply-To: <gw2JK2Z5pVya7JzkGKjQPoEsoU4hcZFKKqD2tNrPnAo=.342c2db1-a676-4bba-b359-6707d3a70275@github.com>
References: <IDrzO0bn83BMGq2bbD45FoGLG8HFjFgY4_l1gB6_kFw=.db1ece05-a190-45ae-acbf-6b6af39b640e@github.com>
 <gw2JK2Z5pVya7JzkGKjQPoEsoU4hcZFKKqD2tNrPnAo=.342c2db1-a676-4bba-b359-6707d3a70275@github.com>
Message-ID: <wMQo5qYo8p6VR4FaADi-PRTSYi_TSRQvLjlYGHng8m8=.b773264a-44dc-4ee9-b0fc-024639d47558@github.com>

On Thu, 8 Dec 2022 20:16:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> A trivial fix for several ProblemListings:
>> [JDK-8298402](https://bugs.openjdk.org/browse/JDK-8298402) ProblemList javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64
>> [JDK-8298414](https://bugs.openjdk.org/browse/JDK-8298414) ProblemList gc/TestFullGCCount.java on linux-x64
>> [JDK-8298417](https://bugs.openjdk.org/browse/JDK-8298417) ProblemList vmTestbase/nsk/stress/strace/strace004.java on 2 platforms
>> [JDK-8298419](https://bugs.openjdk.org/browse/JDK-8298419) ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi005/TestDescription.java on windows-x64
>
> Marked as reviewed by rriggs (Reviewer).

@RogerRiggs - Thanks for the fast review!

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

PR: https://git.openjdk.org/jdk20/pull/1


From dcubed at openjdk.org  Thu Dec  8 20:24:18 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 8 Dec 2022 20:24:18 GMT
Subject: [jdk20] Integrated: 8298402: ProblemList
 javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64
In-Reply-To: <IDrzO0bn83BMGq2bbD45FoGLG8HFjFgY4_l1gB6_kFw=.db1ece05-a190-45ae-acbf-6b6af39b640e@github.com>
References: <IDrzO0bn83BMGq2bbD45FoGLG8HFjFgY4_l1gB6_kFw=.db1ece05-a190-45ae-acbf-6b6af39b640e@github.com>
Message-ID: <i8k4g5iYBHACemBsM1gGoC5ka28X4JA2jW6825S49Pk=.e216c3ab-b23c-4cec-9087-73d0a690ee33@github.com>

On Thu, 8 Dec 2022 18:06:58 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix for several ProblemListings:
> [JDK-8298402](https://bugs.openjdk.org/browse/JDK-8298402) ProblemList javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64
> [JDK-8298414](https://bugs.openjdk.org/browse/JDK-8298414) ProblemList gc/TestFullGCCount.java on linux-x64
> [JDK-8298417](https://bugs.openjdk.org/browse/JDK-8298417) ProblemList vmTestbase/nsk/stress/strace/strace004.java on 2 platforms
> [JDK-8298419](https://bugs.openjdk.org/browse/JDK-8298419) ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi005/TestDescription.java on windows-x64

This pull request has now been integrated.

Changeset: 553ba65d
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/553ba65dc44b601e048c53cd1c48d668de9dcf1e
Stats:     4 lines in 2 files changed: 4 ins; 0 del; 0 mod

8298402: ProblemList javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64
8298414: ProblemList gc/TestFullGCCount.java on linux-x64
8298417: ProblemList vmTestbase/nsk/stress/strace/strace004.java on 2 platforms
8298419: ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi005/TestDescription.java on windows-x64

Reviewed-by: rriggs

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

PR: https://git.openjdk.org/jdk20/pull/1


From serb at openjdk.org  Thu Dec  8 23:03:27 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Dec 2022 23:03:27 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip [v4]
In-Reply-To: <RI5sg7RRZy0Xsgfw6bI8aOf2esZBm75xvxDmYtVF-sI=.94c876af-afa3-435a-a451-fd339bf326a0@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
 <RI5sg7RRZy0Xsgfw6bI8aOf2esZBm75xvxDmYtVF-sI=.94c876af-afa3-435a-a451-fd339bf326a0@github.com>
Message-ID: <qjQR6ToIVvsP761COUv8NYZAts-kx3WCsnCHcHUEeU4=.d1fc19ca-d24b-433a-b628-6af036787d29@github.com>

On Wed, 7 Dec 2022 21:23:53 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Add try/catch clause to ignore an exception since it is harmless for we isolated
>> the massge data before passing it ro processor.
>> Add test case.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the buffers length

Thank you for removing that large try/catch block. Looks much better.

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

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


From serb at openjdk.org  Thu Dec  8 23:31:53 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Dec 2022 23:31:53 GMT
Subject: Integrated: 8298083: The
 "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working
In-Reply-To: <E_b75HPvqrnncD1Khq4tEIWWOweZmFtWBck2Gv7hYFs=.59719e7e-341a-4958-bc69-9ddb3c3c9eea@github.com>
References: <E_b75HPvqrnncD1Khq4tEIWWOweZmFtWBck2Gv7hYFs=.59719e7e-341a-4958-bc69-9ddb3c3c9eea@github.com>
Message-ID: <LEd73_jHPrqafyc9pIm4DiLfi2liB6S5sdEhfboXuKQ=.0fd2f20e-2f18-4717-beca-c9a7900c9c03@github.com>

On Tue, 6 Dec 2022 09:18:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> We have two types of properties in Swing, the "basics": were implemented a long time ago. Some of that properties are tested by the bug4314194 test. And other properties implemented as part of the Synth L&F, and based on it - Nimbus/GTK. Attempt to fix the issue reported by bug4314194 added support of two "basic" options to the Nimbus/GTK but at the same time broke the Synth/Nimbus properties. It is unclear what is the root cause and how these properties should work together(should they? I assume each "basic"/"synth" should support its own) I suggest to revert the changes in 20 to prevent the regression and rethink the solution later.
> 
> In short, this is a request to revert the next fixes:
>  * https://bugs.openjdk.org/browse/JDK-8075916 - for some reason broke the Synth/Nimbus properties
>  * https://bugs.openjdk.org/browse/JDK-8295006 - This uses the same approach as the fix above
> The next two issues created to redo both:
>  * https://bugs.openjdk.org/browse/JDK-8298149
>  * https://bugs.openjdk.org/browse/JDK-8298153

This pull request has now been integrated.

Changeset: 5540a8c5
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5540a8c5b7160ab5c67bb84631e3de54fa5aeceb
Stats:     52 lines in 4 files changed: 18 ins; 21 del; 13 mod

8298083: The "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working

Reviewed-by: psadhukhan

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

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


From dholmes at openjdk.org  Fri Dec  9 00:14:49 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 Dec 2022 00:14:49 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code
 base
In-Reply-To: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
Message-ID: <xSHUc8nAR_3ZshjMhKx9srjNV94mYeUhsAF_had2ESs=.2713d4f3-4580-43d0-a23f-a2ad650cb129@github.com>

On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
> 
> <T> void iterate(T[] items) {
>   if (items.length == 0) {
>     return;
>   }
>   for (T item : items) {
>     //...
>   }
> }
> 
> Here
> 
> if (items.length == 0) {
>   return;
> }
> 
> is redundant and can be removed as length check is performed by for-each loop.

These all seem fine to me.

You can count this as the review for hotspot and serviceability. :)

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

Marked as reviewed by dholmes (Reviewer).

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


From amenkov at openjdk.org  Fri Dec  9 00:14:50 2022
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 9 Dec 2022 00:14:50 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code
 base
In-Reply-To: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
Message-ID: <CMfo4XUsXp6Te2OussC0S1j_IVgbgo7WMfLRfttXsXs=.370474dd-2266-457f-b2b4-190c16d33b84@github.com>

On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
> 
> <T> void iterate(T[] items) {
>   if (items.length == 0) {
>     return;
>   }
>   for (T item : items) {
>     //...
>   }
> }
> 
> Here
> 
> if (items.length == 0) {
>   return;
> }
> 
> is redundant and can be removed as length check is performed by for-each loop.

Marked as reviewed by amenkov (Reviewer).

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

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


From serb at openjdk.org  Fri Dec  9 00:46:18 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 9 Dec 2022 00:46:18 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code
 base
In-Reply-To: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
Message-ID: <FkeOVEsqaMwj6vBM76Amoo2ejo-arcOiyXXbtQcEcY4=.1bb30137-ad97-45c0-8f46-1663d918270a@github.com>

On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
> 
> <T> void iterate(T[] items) {
>   if (items.length == 0) {
>     return;
>   }
>   for (T item : items) {
>     //...
>   }
> }
> 
> Here
> 
> if (items.length == 0) {
>   return;
> }
> 
> is redundant and can be removed as length check is performed by for-each loop.

The "client" changes in src/java.desktop looks fine

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

Marked as reviewed by serb (Reviewer).

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


From psadhukhan at openjdk.org  Fri Dec  9 03:32:55 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 9 Dec 2022 03:32:55 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v3]
In-Reply-To: <GCrCS28sHhTRu2AhNkS1EY1WYpxl3bCvIgCwiRg_ZWk=.aafb1f54-fea2-4f76-bfbf-c473caee9459@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
 <GCrCS28sHhTRu2AhNkS1EY1WYpxl3bCvIgCwiRg_ZWk=.aafb1f54-fea2-4f76-bfbf-c473caee9459@github.com>
Message-ID: <S74T-MqFl39D575cBFBSfTeTbm67RXkK47v03L_Z32U=.e74d3a77-a21f-41f0-8155-388a3c8ab196@github.com>

On Thu, 8 Dec 2022 03:35:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>>     javax.swing.text.html.parser.ParserDelegator
>>     javax.swing.LayoutComparator
>> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
>> 
>> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
>> Added the warning..
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Serialzation warning added in javax.swing package
>  - Serialzation warning added in javax.swing package

CSR https://bugs.openjdk.org/browse/JDK-8298431
Please review

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

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


From prr at openjdk.org  Fri Dec  9 03:54:53 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 Dec 2022 03:54:53 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v3]
In-Reply-To: <GCrCS28sHhTRu2AhNkS1EY1WYpxl3bCvIgCwiRg_ZWk=.aafb1f54-fea2-4f76-bfbf-c473caee9459@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
 <GCrCS28sHhTRu2AhNkS1EY1WYpxl3bCvIgCwiRg_ZWk=.aafb1f54-fea2-4f76-bfbf-c473caee9459@github.com>
Message-ID: <ReJolRIQAoK9oe-m_o2fWsCUpwkMNH1FZphSPi4Hr5Y=.b66e883e-f90a-4aa0-8e31-4bbc023831a6@github.com>

On Thu, 8 Dec 2022 03:35:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>>     javax.swing.text.html.parser.ParserDelegator
>>     javax.swing.LayoutComparator
>> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
>> 
>> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
>> Added the warning..
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Serialzation warning added in javax.swing package
>  - Serialzation warning added in javax.swing package

src/java.desktop/share/classes/javax/swing/package-info.java line 133:

> 131:  * <h2><a id="serialization">Swing's Serialization policy</a></h2>
> 132:  * <strong>Warning:</strong>
> 133:  * Serialized objects of any swing class will not be compatible with

capitalise swing

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

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


From psadhukhan at openjdk.org  Fri Dec  9 04:03:25 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 9 Dec 2022 04:03:25 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v4]
In-Reply-To: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
Message-ID: <zzy2jQ154Zxfu9cpVmly8jXDyRf4mbtdsJi9ytbI8CY=.7d9e4fb8-a9cb-43dc-aabb-6a54af4f9842@github.com>

> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>     javax.swing.text.html.parser.ParserDelegator
>     javax.swing.LayoutComparator
> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
> 
> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
> Added the warning..

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

  Capitalise swing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11565/files
  - new: https://git.openjdk.org/jdk/pull/11565/files/22fb52f4..2229baab

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

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

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


From ajit.ghaisas at oracle.com  Fri Dec  9 04:20:03 2022
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Fri, 9 Dec 2022 04:20:03 +0000
Subject: [External] : Re: Quick fix for openjdk20
In-Reply-To: <3DFFDD9C-5DB9-4398-9A72-6E1B045083AA@jetbrains.com>
References: <CAKjRUT4muRHUfd8zA0k8OpWLJJLtFmgfBwHA08njYPL3g4U8fA@mail.gmail.com>
 <7C1FA120-8A68-4805-A507-7D7ADF6BDBB1@jetbrains.com>
 <ae90ff4d-bb8b-ec73-71ad-4c2c7394b032@oracle.com>
 <C17B6F27-00B1-4026-8F2B-400E1F82E5A5@jetbrains.com>
 <02889093-418B-4BF0-8920-DEC74EFC1751@oracle.com>
 <3DFFDD9C-5DB9-4398-9A72-6E1B045083AA@jetbrains.com>
Message-ID: <87420CD5-0156-4528-92CF-8F78302C266F@oracle.com>

Hi Alexey,

   There could be other reasons as well, but - those recorded results were for x64 only at that time. Performance degradation is comparatively more when run on M1 systems.

Regards,
Ajit

On 09-Dec-2022, at 12:50 AM, Alexey Ushakov <alexey.ushakov at jetbrains.com<mailto:alexey.ushakov at jetbrains.com>> wrote:

Hi Ajit,

According to the tests you?ve mentioned it?s not a big difference. Looks like we?ve faced with completely different scenario. I?ll try to figure out the main reason of the failure.

Best Regards,
Alexey

On Dec 8, 2022, at 12:38 PM, Ajit Ghaisas <ajit.ghaisas at oracle.com<mailto:ajit.ghaisas at oracle.com>> wrote:



On 08-Dec-2022, at 1:50 PM, Alexey Ushakov <alexey.ushakov at jetbrains.com<mailto:alexey.ushakov at jetbrains.com>> wrote:


FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes
time for these things to be discovered.
Could you provide some more details concerning the regression? We also faced with a regression in metal rendering (https://youtrack.jetbrains.com/issue/JBR-4849<https://urldefense.com/v3/__https://youtrack.jetbrains.com/issue/JBR-4849__;!!ACWV5N9M2RV99hQ!IGt32jobqI206Dm2bA6yJfDrvnugMoQygowL66VIPXfegeFCuprHsXLVNZUDG7C_y1gzas0MW8u8hEEMAjvAoIMxls-dzg$> ). It was caused by https://bugs.openjdk.org/browse/JDK-8288948 (that we back ported into OpenJDK17 based runtime).

The details can be found at -
https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14504772<https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14504772>

Look at the last 3 lines of that comment & attached test results to  https://bugs.openjdk.org/browse/JDK-8288948.
In the screenshots for RenderPerf and SwingMark results - the rightmost column header should read ?Integrated graphics card."


Best Regards,
Alexey

On Dec 7, 2022, at 7:22 PM, Philip Race <philip.race at oracle.com<mailto:philip.race at oracle.com>> wrote:

This is clearly too late for JDK 20 and JDK 21 will be just 6 months later so it is a better time for that.
FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes
time for these things to be discovered.
Also I had a bug / rfe for this a while back : https://bugs.openjdk.org/browse/JDK-8233037
I closed it as WNF because I wasn't able to see a performance boost.

So the right way to do this is  to provide some solid evidence of what gets faster and what gets
slower with a range of different values (not just the JBR one) and re-open that bug and resolve early in 21.

-phil.


On 12/7/22 7:36 AM, Alexey Ushakov wrote:
Yes, I confirm that we?ve been using such enlarged buffer for a long time in production. It helped us with scrolling performance on 4K monitors. The suggested property could help to adjust the buffer for the needs of particular application.

Best Regards,
Alexey

On 7 Dec 2022, at 11:37, Laurent Bourg?s <bourges.laurent at gmail.com<mailto:bourges.laurent at gmail.com>> wrote:

Hi,

For years, JetBrains Runtime uses a larger render queue buffer size (32kb to 6,400,000 bytes) in production, as it boosted many accelerated pipelines: d3d, ogl, metal :
~ 10 to 20% on large fills...

JBR RenderQueue:
https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75<https://urldefense.com/v3/__https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java*L75__;Iw!!ACWV5N9M2RV99hQ!IGt32jobqI206Dm2bA6yJfDrvnugMoQygowL66VIPXfegeFCuprHsXLVNZUDG7C_y1gzas0MW8u8hEEMAjvAoIOFwmNyEA$>

JDK RenderQueue:
https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75<https://urldefense.com/v3/__https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java*L75__;Iw!!ACWV5N9M2RV99hQ!IGt32jobqI206Dm2bA6yJfDrvnugMoQygowL66VIPXfegeFCuprHsXLVNZUDG7C_y1gzas0MW8u8hEEMAjvAoINZwGQdSw$>

I want to propose such quick fix in openjdk20 today, as a 1-line fix.


/** The size of the underlying buffer, in bytes. */
private static final int BUFFER_SIZE = 6400000;

To ensure a smooth transition, I prefer introducing a new sun.java2d.render.queue system property to increase the default (32kb) buffer capacity:

See in marlin:
https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78<https://urldefense.com/v3/__https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java*L78__;Iw!!ACWV5N9M2RV99hQ!IGt32jobqI206Dm2bA6yJfDrvnugMoQygowL66VIPXfegeFCuprHsXLVNZUDG7C_y1gzas0MW8u8hEEMAjvAoIN2g-fa0g$>

So here is my current proposal:
[[[

/** The size of the underlying buffer, in bytes. */
private static final int BUFFER_SIZE;

static {
// Default 32K is too small for high-end GPU:
BUFFER_SIZE = align(getInteger("sun.java2d.render.bufferSize", 32 * 1024, 32 * 1024, 16 * 1024 * 1024), 1024);

// System.out.println("RenderQueue: sun.java2d.render.bufferSize = " + BUFFER_SIZE);
}

    // system property utilities
    public static int getInteger(final String key, final int def,
                                 final int min, final int max)
    {
        final String property = AccessController.doPrivileged(
                                    new GetPropertyAction(key));

        int value = def;
        if (property != null) {
            try {
                value = Integer.decode(property);
            } catch (NumberFormatException e) {
                System.out.println("Invalid integer value for " + key + " = " + property);
            }
        }

        // check for invalid values
        if ((value < min) || (value > max)) {
            System.out.println("Invalid value for " + key + " = " + value
                    + "; expected value in range[" + min + ", " + max + "] !");
            value = def;
        }
        return value;
    }

    protected static int align(final int val, final int norm) {
        final int ceil = (int)Math.ceil( ((float) val) / norm);
        return ceil * norm;
    }
]]]

Would you accept such late change for openjdk20 ?

Cheers,
Laurent Bourg?s






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221209/09759f49/attachment.htm>

From duke at openjdk.org  Fri Dec  9 05:22:56 2022
From: duke at openjdk.org (Naveen Narayanan)
Date: Fri, 9 Dec 2022 05:22:56 GMT
Subject: RFR: 8296275: Write a test to verify setAccelerator method of
 JMenuItem [v7]
In-Reply-To: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
Message-ID: <s3Dg2JR4Fxclcldua9KiAGGcNVRBBBwhZcMjQNMzGw8=.f70ef397-cfc5-4a57-8a98-73bda55bd4fd@github.com>

> This testcase will
> 1) Verify setAccelerator method of JMenuitem.
> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M.
> 
> Testing:
> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass.

Naveen Narayanan has updated the pull request incrementally with two additional commits since the last revision:

 - 8296275: Write a test to verify setAccelerator method of JMenuItem.
 - 8296275: Removing the file from incorrect folder.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11035/files
  - new: https://git.openjdk.org/jdk/pull/11035/files/a8e13a4c..2661e04e

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

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

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


From duke at openjdk.org  Fri Dec  9 05:26:40 2022
From: duke at openjdk.org (Naveen Narayanan)
Date: Fri, 9 Dec 2022 05:26:40 GMT
Subject: RFR: 8296275: Write a test to verify setAccelerator method of
 JMenuItem [v6]
In-Reply-To: <EtSyILAIY0F-wpz-VNyI2vfk4GSfbIzyvOnPVV_WezE=.d81ca068-99da-413c-ab38-629b3b6a09e3@github.com>
References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
 <Q957c8-nyOhidQ478zoe67NomvBhIAQgVqvODSSHH_M=.229c7272-cade-467b-9c30-da6f20b954a0@github.com>
 <EtSyILAIY0F-wpz-VNyI2vfk4GSfbIzyvOnPVV_WezE=.d81ca068-99da-413c-ab38-629b3b6a09e3@github.com>
Message-ID: <pCupb_077cB6Hmf4F8h_-bQqsTFmpfJiLe5XDs2uA4k=.e48d6f79-22e8-46cf-83df-97ef67a17bfd@github.com>

On Tue, 29 Nov 2022 16:04:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8296275: Review comments fixed.
>
> test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 48:
> 
>> 46:     private static JFrame frame;
>> 47:     private static final CountDownLatch actionLatch = new CountDownLatch(1);
>> 48:     private static Robot robot;
> 
> My IDE issues a warning, the `robot` field can be converted to local variable. Indeed, it isn't used outside of `main`.

Since the test checks functionality of JMenuItem, its moved to JMenuItem folder.

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

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


From duke at openjdk.org  Fri Dec  9 05:36:03 2022
From: duke at openjdk.org (Naveen Narayanan)
Date: Fri, 9 Dec 2022 05:36:03 GMT
Subject: RFR: 8296275: Write a test to verify setAccelerator method of
 JMenuItem [v8]
In-Reply-To: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
Message-ID: <8NYHld9tBOAyBPZk00A_73beOW6lj8a_w-9lJSthLJ8=.473b501e-38f6-4306-a11e-2970dbb87ac4@github.com>

> This testcase will
> 1) Verify setAccelerator method of JMenuitem.
> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M.
> 
> Testing:
> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass.

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

  8296275: Removing trailing whitespaces.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11035/files
  - new: https://git.openjdk.org/jdk/pull/11035/files/2661e04e..12cc8e4e

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

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

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


From vtewari at openjdk.org  Fri Dec  9 06:24:54 2022
From: vtewari at openjdk.org (Vyom Tewari)
Date: Fri, 9 Dec 2022 06:24:54 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code
 base
In-Reply-To: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
Message-ID: <QsE7sZ_-X1NMmYEgSE-TLq9lBXpTvkbC8DHnJjfbBIY=.9fd88818-1e40-4f99-926d-e339b0dc0082@github.com>

On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
> 
> <T> void iterate(T[] items) {
>   if (items.length == 0) {
>     return;
>   }
>   for (T item : items) {
>     //...
>   }
> }
> 
> Here
> 
> if (items.length == 0) {
>   return;
> }
> 
> is redundant and can be removed as length check is performed by for-each loop.

java.base changes looks ok to me.

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

Marked as reviewed by vtewari (Committer).

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


From aturbanov at openjdk.org  Fri Dec  9 06:50:39 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 9 Dec 2022 06:50:39 GMT
Subject: RFR: 8298447: Unnecessary Vector usage in DocPrintJob implementations
Message-ID: <JJ3LrpITZ7EaKjvUzOZH0s-dlR9JjZ02glhUVEWFrp8=.17a11333-83c9-4a52-a0e7-30052ecbebb6@github.com>

There are 3 implementations of javax.print.DocPrintJob in the JDK (It seems they were copy-pasted from each other):
1. PSStreamPrintJob
2. UnixPrintJob
3. Win32PrintJob

They have Vector fields 'jobListeners', 'attrListeners', 'listenedAttributeSets', but they are always accessed only under synchronized(this) blocks. It means we can safely replace them with ArrayList.

BTW. 'attrListeners' and 'listenedAttributeSets' seems unused.

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

Commit messages:
 - [PATCH] Unnecessary Vector usage in DocPrintJob implementations

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

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


From duke at openjdk.org  Fri Dec  9 06:50:40 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 9 Dec 2022 06:50:40 GMT
Subject: RFR: 8298447: Unnecessary Vector usage in DocPrintJob
 implementations
In-Reply-To: <JJ3LrpITZ7EaKjvUzOZH0s-dlR9JjZ02glhUVEWFrp8=.17a11333-83c9-4a52-a0e7-30052ecbebb6@github.com>
References: <JJ3LrpITZ7EaKjvUzOZH0s-dlR9JjZ02glhUVEWFrp8=.17a11333-83c9-4a52-a0e7-30052ecbebb6@github.com>
Message-ID: <oUqpcfI9FwNf8AIPpcjECldH5Lrg4t0Vzd9vXoYbpZ8=.a27b5e92-8a89-4e99-894f-01d60cdced7d@github.com>

On Mon, 5 Dec 2022 08:23:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There are 3 implementations of javax.print.DocPrintJob in the JDK (It seems they were copy-pasted from each other):
> 1. PSStreamPrintJob
> 2. UnixPrintJob
> 3. Win32PrintJob
> 
> They have Vector fields 'jobListeners', 'attrListeners', 'listenedAttributeSets', but they are always accessed only under synchronized(this) blocks. It means we can safely replace them with ArrayList.
> 
> BTW. 'attrListeners' and 'listenedAttributeSets' seems unused.

I would prefer if that the fields were of type `List` instead of `ArrayList`.

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

Changes requested by SWinxy at github.com (no known OpenJDK username).

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


From serb at openjdk.org  Fri Dec  9 06:50:41 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 9 Dec 2022 06:50:41 GMT
Subject: RFR: 8298447: Unnecessary Vector usage in DocPrintJob
 implementations
In-Reply-To: <JJ3LrpITZ7EaKjvUzOZH0s-dlR9JjZ02glhUVEWFrp8=.17a11333-83c9-4a52-a0e7-30052ecbebb6@github.com>
References: <JJ3LrpITZ7EaKjvUzOZH0s-dlR9JjZ02glhUVEWFrp8=.17a11333-83c9-4a52-a0e7-30052ecbebb6@github.com>
Message-ID: <Mny8dWLMCeuwwmOuMuV26c8ISU7ymj-AOrqebGC2FzA=.c26ad2e9-b967-4a3e-9600-42a25cdce3c8@github.com>

On Mon, 5 Dec 2022 08:23:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There are 3 implementations of javax.print.DocPrintJob in the JDK (It seems they were copy-pasted from each other):
> 1. PSStreamPrintJob
> 2. UnixPrintJob
> 3. Win32PrintJob
> 
> They have Vector fields 'jobListeners', 'attrListeners', 'listenedAttributeSets', but they are always accessed only under synchronized(this) blocks. It means we can safely replace them with ArrayList.
> 
> BTW. 'attrListeners' and 'listenedAttributeSets' seems unused.

looks fine.

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

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


From aturbanov at openjdk.org  Fri Dec  9 06:56:42 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 9 Dec 2022 06:56:42 GMT
Subject: RFR: 8298449: Unnecessary Vector usage in
 MetaData.ProxyPersistenceDelegate
Message-ID: <EuE_osZPhPoAjRSX6B_WMCzdf6NwjBARBLitLQIgeEQ=.37af7798-a198-4e7f-b5d5-4e6427b2057b@github.com>

`Vector<Object> args` is used only in single method and then it converted to `Object[]`.
So we can avoid usage of legacy synchronized `Vector` here and use `ArrayList` instead.

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

Commit messages:
 - [PATCH] Unnecessary Vector usage in MetaData.ProxyPersistenceDelegate

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

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


From serb at openjdk.org  Fri Dec  9 06:56:42 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 9 Dec 2022 06:56:42 GMT
Subject: RFR: 8298449: Unnecessary Vector usage in
 MetaData.ProxyPersistenceDelegate
In-Reply-To: <EuE_osZPhPoAjRSX6B_WMCzdf6NwjBARBLitLQIgeEQ=.37af7798-a198-4e7f-b5d5-4e6427b2057b@github.com>
References: <EuE_osZPhPoAjRSX6B_WMCzdf6NwjBARBLitLQIgeEQ=.37af7798-a198-4e7f-b5d5-4e6427b2057b@github.com>
Message-ID: <xX6UxctgdYrtd_vbvaWC0pyfF8u4bdqK7BK-QQ8ga1U=.e7eb72ca-4ece-489d-83c4-754ee15bd076@github.com>

On Fri, 11 Nov 2022 07:00:52 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Vector<Object> args` is used only in single method and then it converted to `Object[]`.
> So we can avoid usage of legacy synchronized `Vector` here and use `ArrayList` instead.

the patch looks fine.

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

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


From duke at openjdk.org  Fri Dec  9 06:56:44 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 9 Dec 2022 06:56:44 GMT
Subject: RFR: 8298449: Unnecessary Vector usage in
 MetaData.ProxyPersistenceDelegate
In-Reply-To: <EuE_osZPhPoAjRSX6B_WMCzdf6NwjBARBLitLQIgeEQ=.37af7798-a198-4e7f-b5d5-4e6427b2057b@github.com>
References: <EuE_osZPhPoAjRSX6B_WMCzdf6NwjBARBLitLQIgeEQ=.37af7798-a198-4e7f-b5d5-4e6427b2057b@github.com>
Message-ID: <zT3k1uusBJZurpVaTW1LGKY79UVVOCSgaix22SHfxL4=.a6127222-fb9c-4d4e-a80c-e6b3e62cc665@github.com>

On Fri, 11 Nov 2022 07:00:52 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Vector<Object> args` is used only in single method and then it converted to `Object[]`.
> So we can avoid usage of legacy synchronized `Vector` here and use `ArrayList` instead.

src/java.desktop/share/classes/java/beans/MetaData.java line 159:

> 157:         java.lang.reflect.InvocationHandler ih = java.lang.reflect.Proxy.getInvocationHandler(p);
> 158:         if (ih instanceof EventHandler eh) {
> 159:             ArrayList<Object> args = new ArrayList<>();

Suggestion:

            List<Object> args = new ArrayList<>();

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

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


From psadhukhan at openjdk.org  Fri Dec  9 08:16:52 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 9 Dec 2022 08:16:52 GMT
Subject: RFR: 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame
 throws a NPE.
Message-ID: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>

In Swingset2 JInternalFrame demo, focusing on any internalframes and pressing Ctrl+F7 and then any of up/down/left/arrow key to move the internal frames results in NPE in NimbusL&F.
It is because `JComponent.processKeyBinding() `calls `SwingUtilities.notifyAction` which calls `BasicDesktopPaneUI.actionPerformed` where it gets `Desktop.minOnScreenInsets` property to get the Insets and then uses insets.top/bottom/left/right value to move the internalframe but this property is not defined for Nimbus so deferencing Insets object results in NPE.

Fix is added to create a 0 insets incase some L&F do not define` Desktop.minOnScreenInsets` property.
No regression test is added as it can be easily checked by SwingSet2 JInternalFrame demo.

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

Commit messages:
 - 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame throws a NPE.

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

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


From abhiscxk at openjdk.org  Fri Dec  9 09:15:50 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 9 Dec 2022 09:15:50 GMT
Subject: RFR: 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame
 throws a NPE.
In-Reply-To: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
References: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
Message-ID: <55tk-P60C2VV9hrAI9_9YwUQeHEQrUsHsTJTgsWA4aE=.50405158-763e-4863-a6dc-2d3518e82c2d@github.com>

On Fri, 9 Dec 2022 08:06:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In Swingset2 JInternalFrame demo, focusing on any internalframes and pressing Ctrl+F7 and then any of up/down/left/arrow key to move the internal frames results in NPE in NimbusL&F.
> It is because `JComponent.processKeyBinding() `calls `SwingUtilities.notifyAction` which calls `BasicDesktopPaneUI.actionPerformed` where it gets `Desktop.minOnScreenInsets` property to get the Insets and then uses insets.top/bottom/left/right value to move the internalframe but this property is not defined for Nimbus so deferencing Insets object results in NPE.
> 
> Fix is added to create a 0 insets incase some L&F do not define` Desktop.minOnScreenInsets` property.
> No regression test is added as it can be easily checked by SwingSet2 JInternalFrame demo.

Verified in SwingSet2 demo.

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

Marked as reviewed by abhiscxk (Author).

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


From asemenov at openjdk.org  Fri Dec  9 11:10:40 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 9 Dec 2022 11:10:40 GMT
Subject: RFR: 8298457 Instructions in a11y manual tests need to be updated
Message-ID: <-krjPWn7QWUu4pMtvbAt8fHbzpCP6-dtTjgxg1e1KJE=.33721101-b475-4a78-823a-b1c6aa2f91bb@github.com>

Test instructions:
- Accessible Actions Test;
- AccessibleJTabbedPaneTest;
- Accessible Text Test.
contain inaccurate indications of actions in different screen readers.

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

Commit messages:
 - 8298457 Instructions in a11y manual tests need to be updated

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

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


From asemenov at openjdk.org  Fri Dec  9 11:10:40 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 9 Dec 2022 11:10:40 GMT
Subject: RFR: 8298457 Instructions in a11y manual tests need to be updated
In-Reply-To: <-krjPWn7QWUu4pMtvbAt8fHbzpCP6-dtTjgxg1e1KJE=.33721101-b475-4a78-823a-b1c6aa2f91bb@github.com>
References: <-krjPWn7QWUu4pMtvbAt8fHbzpCP6-dtTjgxg1e1KJE=.33721101-b475-4a78-823a-b1c6aa2f91bb@github.com>
Message-ID: <6R6fjyQxk6Oc2F7_3rcpfVL3oos5os5prrCt_NMcmhI=.bb53038a-4e73-4785-8931-c0b7347a5e6e@github.com>

On Fri, 9 Dec 2022 11:02:09 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> Test instructions:
> - Accessible Actions Test;
> - AccessibleJTabbedPaneTest;
> - Accessible Text Test.
> contain inaccurate indications of actions in different screen readers.

@azuev-java please review

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

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


From mbaesken at openjdk.org  Fri Dec  9 12:27:00 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 9 Dec 2022 12:27:00 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <_mmRgqh9oP4GNFQEsIHjRtYwzMekhI5GTq8b8URghEE=.540c993a-fa4e-4c8e-8f6c-5372e0c74d42@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

Hi Roger , the new proposed version  JNU_CHECK_EXCEPTION_DO  is now almost as lengthy as the original coding, Is it really worth it introducing a macro when it gets so lengthy ?

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

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


From stsypanov at openjdk.org  Fri Dec  9 12:54:50 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 9 Dec 2022 12:54:50 GMT
Subject: Integrated: 8298380: Clean up redundant array length checks in JDK
 code base
In-Reply-To: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
Message-ID: <b7nakxCOTmosMZCe5GtxG-oPMr25G3BPSaGDdza3-Fo=.22ac843f-949c-4c0d-b0cc-e81c129c7315@github.com>

On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
> 
> <T> void iterate(T[] items) {
>   if (items.length == 0) {
>     return;
>   }
>   for (T item : items) {
>     //...
>   }
> }
> 
> Here
> 
> if (items.length == 0) {
>   return;
> }
> 
> is redundant and can be removed as length check is performed by for-each loop.

This pull request has now been integrated.

Changeset: e3c6cf8e
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3c6cf8eaf931d9eb46b429a5ba8d3bbded3728a
Stats:     51 lines in 8 files changed: 0 ins; 14 del; 37 mod

8298380: Clean up redundant array length checks in JDK code base

Reviewed-by: dholmes, amenkov, serb, vtewari

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

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


From rriggs at openjdk.org  Fri Dec  9 14:38:03 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Dec 2022 14:38:03 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code
 base
In-Reply-To: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
Message-ID: <Dz0VbMxEcXZnFW0IC2vgWOGbtXJeSxcPFRhZBUp5Vsg=.d7bdff79-a2fc-4951-9981-6654853d2b92@github.com>

On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
> 
> <T> void iterate(T[] items) {
>   if (items.length == 0) {
>     return;
>   }
>   for (T item : items) {
>     //...
>   }
> }
> 
> Here
> 
> if (items.length == 0) {
>   return;
> }
> 
> is redundant and can be removed as length check is performed by for-each loop.

@stsypanov , @TheShermanTanker You jumped the gun a bit on the integration and sponsoring. There was no approval for the core-libs parts from a "R"eviewer.

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

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


From rriggs at openjdk.org  Fri Dec  9 14:43:49 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Dec 2022 14:43:49 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <_mmRgqh9oP4GNFQEsIHjRtYwzMekhI5GTq8b8URghEE=.540c993a-fa4e-4c8e-8f6c-5372e0c74d42@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
 <_mmRgqh9oP4GNFQEsIHjRtYwzMekhI5GTq8b8URghEE=.540c993a-fa4e-4c8e-8f6c-5372e0c74d42@github.com>
Message-ID: <YPj1ap6tA4UlYcuTzF7tfm1pqNC-03nnqR3Jaj-kEVY=.d7e1798a-0c84-4d8e-acb5-dff6f4d070da@github.com>

On Fri, 9 Dec 2022 12:23:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Roger , the new proposed version JNU_CHECK_EXCEPTION_DO is now almost as lengthy as the original coding, Is it really worth it introducing a macro when it gets so lengthy ?

Its easier to understand the flow and cleanup being done if its visible in the source. 
I (or new readers) don't have to go unwrap the macro to know what's going to happen.

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

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


From stsypanov at openjdk.org  Fri Dec  9 14:48:02 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 9 Dec 2022 14:48:02 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code
 base
In-Reply-To: <Dz0VbMxEcXZnFW0IC2vgWOGbtXJeSxcPFRhZBUp5Vsg=.d7bdff79-a2fc-4951-9981-6654853d2b92@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
 <Dz0VbMxEcXZnFW0IC2vgWOGbtXJeSxcPFRhZBUp5Vsg=.d7bdff79-a2fc-4951-9981-6654853d2b92@github.com>
Message-ID: <Bxyi6RsVLIF3CMzxULvqkw3hPPq3uL3HfLejuML4kAs=.9d6fc4b5-b3f6-4047-92be-16aeacb510ad@github.com>

On Fri, 9 Dec 2022 14:35:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
>> 
>> <T> void iterate(T[] items) {
>>   if (items.length == 0) {
>>     return;
>>   }
>>   for (T item : items) {
>>     //...
>>   }
>> }
>> 
>> Here
>> 
>> if (items.length == 0) {
>>   return;
>> }
>> 
>> is redundant and can be removed as length check is performed by for-each loop.
>
> @stsypanov , @TheShermanTanker You jumped the gun a bit on the integration and sponsoring. There was no approval for the core-libs parts from a "R"eviewer.

@RogerRiggs changes are trivial. Should I revert any of them?

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

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


From rriggs at openjdk.org  Fri Dec  9 15:54:00 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Dec 2022 15:54:00 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code
 base
In-Reply-To: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
Message-ID: <BwPdsqhPrg0_Pu-2vG9oeI57xDndYzFgYKJmIEIzNxk=.856d70e7-734c-47d9-a988-33521a665416@github.com>

On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
> 
> <T> void iterate(T[] items) {
>   if (items.length == 0) {
>     return;
>   }
>   for (T item : items) {
>     //...
>   }
> }
> 
> Here
> 
> if (items.length == 0) {
>   return;
> }
> 
> is redundant and can be removed as length check is performed by for-each loop.

No, just a reminder to be through in the process.

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

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


From kizune at openjdk.org  Fri Dec  9 16:08:04 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 9 Dec 2022 16:08:04 GMT
Subject: RFR: 8298457 Instructions in a11y manual tests need to be updated
In-Reply-To: <-krjPWn7QWUu4pMtvbAt8fHbzpCP6-dtTjgxg1e1KJE=.33721101-b475-4a78-823a-b1c6aa2f91bb@github.com>
References: <-krjPWn7QWUu4pMtvbAt8fHbzpCP6-dtTjgxg1e1KJE=.33721101-b475-4a78-823a-b1c6aa2f91bb@github.com>
Message-ID: <xk3befWQoTfHxFaHe3zdBds3NV0ROHjJgDXTm52DpiE=.039bc80b-6a45-4d61-ab50-eba32c23cd55@github.com>

On Fri, 9 Dec 2022 11:02:09 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> Test instructions:
> - Accessible Actions Test;
> - AccessibleJTabbedPaneTest;
> - Accessible Text Test.
> contain inaccurate indications of actions in different screen readers.

Looks good to me.

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

Marked as reviewed by kizune (Reviewer).

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


From lbourges at openjdk.org  Fri Dec  9 17:57:36 2022
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 9 Dec 2022 17:57:36 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v19]
In-Reply-To: <W8Ac5RQQcrQmv0Z_dU-lwhu1ny1MjgGq7xvnObMFTlU=.c4eeee8b-535e-4394-99db-10a7918e8733@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <W8Ac5RQQcrQmv0Z_dU-lwhu1ny1MjgGq7xvnObMFTlU=.c4eeee8b-535e-4394-99db-10a7918e8733@github.com>
Message-ID: <ZNMA7VkpPAMRNRlblkKI8VObwPEbwn-yHdwctV3SyDA=.7ea85145-1f37-4120-851d-bbc3d1e35332@github.com>

On Thu, 8 Dec 2022 19:41:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan 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 24 additional commits since the last revision:
> 
>  - adlc update per review
>  - Merge
>  - update on review feedback
>  - comment for snprintf_checked
>  - use checked snprintf for adlc
>  - use checked snprintf
>  - no check on adlc
>  - revert use of assert
>  - extra sizeof typo
>  - more size_t updare for windows build
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/2309602b...49bb58fd

LGTM, build on macos 13 + xcode 14.1 (x64): OK

I run successfully few applications with built jdk image...


Configuration summary:
* Name:           macosx-x86_64-server-release
* Debug level:    release
* HS debug level: product
* JVM variants:   server
* JVM features:   server: 'cds compiler1 compiler2 dtrace epsilongc g1gc jfr jni-check jvmci jvmti management parallelgc serialgc services shenandoahgc vm-structs zgc' 
* OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
* Version string: 20-internal-adhoc.jmmc.jdk-gh (20-internal)
* Source date:    1670605929 (2022-12-09T17:12:09Z)

Tools summary:
* Boot JDK:       openjdk version "20-ea" 2023-03-21 OpenJDK Runtime Environment (build 20-ea+26-2022) OpenJDK 64-Bit Server VM (build 20-ea+26-2022, mixed mode, sharing) (at /Users/jmmc/apps/jdk-20.jdk/Contents/Home)
* Toolchain:      clang (clang/LLVM from Xcode 14.1)
* Sysroot:        /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk
* C Compiler:     Version 14.0.0 (at /usr/bin/clang)
* C++ Compiler:   Version 14.0.0 (at /usr/bin/clang++)

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

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


From harshitha.onkar at oracle.com  Fri Dec  9 18:18:33 2022
From: harshitha.onkar at oracle.com (Harshitha Onkar)
Date: Fri, 9 Dec 2022 18:18:33 +0000
Subject: RFR: JDK-8294680: Refactor scaled border rendering
In-Reply-To: <DDBA75B2-4BFA-4784-BC1B-6E1827ED6DBD@cbfiddle.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <DDBA75B2-4BFA-4784-BC1B-6E1827ED6DBD@cbfiddle.com>
Message-ID: <BYAPR10MB3350EFED071DF1BBEF1572E7801C9@BYAPR10MB3350.namprd10.prod.outlook.com>

Hi Alan,

Thank you for the questions. Please find the answers below.

> Is there some reason why this should not be a public API?

We are still testing out this code. Since each border is different (apart from the common steps required for border scaling issue), the solution must be well-baked, 
tested thoroughly and extensively before it becomes a part of public API.
After more borders in JDK are updated and the refactored solution is considered robust & stable, the question of whether to make this utility
method a public API can be discussed again. At this time, it might be too early for it.

> Do you believe that only JDK-implemented borders need this functionality?

The current solution is in its initial stage and we haven't yet determined what applications may or may not need this functionality. 
Additionally we haven't updated all the JDK borders yet, so we might encounter changes (if any) that may require iterative update to the current solution.
Do you have a specific use case in mind?


Thanks & Regards,
Harshitha Onkar


-----Original Message-----
From: client-libs-dev <client-libs-dev-retn at openjdk.org> On Behalf Of Alan Snyder
Sent: Wednesday, December 7, 2022 1:53 PM
To: Harshitha Onkar <honkar at openjdk.org>
Cc: client-libs-dev at openjdk.org
Subject: Re: RFR: JDK-8294680: Refactor scaled border rendering

Is there some reason why this should not be a public API?

Do you believe that only JDK-implemented borders need this functionality?


> On Dec 7, 2022, at 1:44 PM, Harshitha Onkar <honkar at openjdk.org> wrote:
> 
> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as parameter to method.  
> 
> The following steps are common for any border scaling -
> 
> - Resetting transform.
> - Calculating new width, height, x & y-translations.
> - Perform the required border rendering. 
> - And at the end restore the previous transform.
> 
> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
> 
> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) 
> - Test: ScaledEtchedBorderTest.java 2. LineBorder - 
> [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: 
> ScaledLineBorderTest & ScaledTextFieldBorderTest.java 3. 
> JInternalFrame Border - 
> [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: 
> InternalFrameBorderTest.java
> 
> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.
> 
> -------------
> 
> Commit messages:
> - Refactoring changes
> - Merge branch 'master' into RefactorBorder_8294484
> - revert MetalBorder changes
> - merge master
> - refactoring changes - initial commit
> 
> Changes: https://git.openjdk.org/jdk/pull/11571/files
> Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11571&range=00
>  Issue: https://bugs.openjdk.org/browse/JDK-8294680
>  Stats: 272 lines in 4 files changed: 94 ins; 146 del; 32 mod
>  Patch: https://git.openjdk.org/jdk/pull/11571.diff
>  Fetch: git fetch https://git.openjdk.org/jdk 
> pull/11571/head:pull/11571
> 
> PR: https://git.openjdk.org/jdk/pull/11571
> 



From serb at openjdk.org  Fri Dec  9 19:39:29 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 9 Dec 2022 19:39:29 GMT
Subject: RFR: 8298457 Instructions in a11y manual tests need to be updated
In-Reply-To: <-krjPWn7QWUu4pMtvbAt8fHbzpCP6-dtTjgxg1e1KJE=.33721101-b475-4a78-823a-b1c6aa2f91bb@github.com>
References: <-krjPWn7QWUu4pMtvbAt8fHbzpCP6-dtTjgxg1e1KJE=.33721101-b475-4a78-823a-b1c6aa2f91bb@github.com>
Message-ID: <QEzAcp_8N1YnkJl0x_2f4Ok7jyutJTTxvrHsv1Gf6U8=.e2f6ce97-07b7-438c-8e56-6b6e4bad859c@github.com>

On Fri, 9 Dec 2022 11:02:09 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> Test instructions:
> - Accessible Actions Test;
> - AccessibleJTabbedPaneTest;
> - Accessible Text Test.
> contain inaccurate indications of actions in different screen readers.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.org  Fri Dec  9 19:39:41 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 9 Dec 2022 19:39:41 GMT
Subject: RFR: 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame
 throws a NPE.
In-Reply-To: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
References: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
Message-ID: <94q2edPe5cN5NoGNaNLiXKMTBhJYHsDnEfj59w0Kpgg=.1acee9aa-e345-4620-9314-827418b4eaf2@github.com>

On Fri, 9 Dec 2022 08:06:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In Swingset2 JInternalFrame demo, focusing on any internalframes and pressing Ctrl+F7 and then any of up/down/left/arrow key to move the internal frames results in NPE in NimbusL&F.
> It is because `JComponent.processKeyBinding() `calls `SwingUtilities.notifyAction` which calls `BasicDesktopPaneUI.actionPerformed` where it gets `Desktop.minOnScreenInsets` property to get the Insets and then uses insets.top/bottom/left/right value to move the internalframe but this property is not defined for Nimbus so deferencing Insets object results in NPE.
> 
> Fix is added to create a 0 insets incase some L&F do not define` Desktop.minOnScreenInsets` property.
> No regression test is added as it can be easily checked by SwingSet2 JInternalFrame demo.

It would be good to add a test case to make sure this bug will not happen someday again.

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

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


From asemenov at openjdk.org  Fri Dec  9 20:09:57 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 9 Dec 2022 20:09:57 GMT
Subject: Integrated: 8298457 Instructions in a11y manual tests need to be
 updated
In-Reply-To: <-krjPWn7QWUu4pMtvbAt8fHbzpCP6-dtTjgxg1e1KJE=.33721101-b475-4a78-823a-b1c6aa2f91bb@github.com>
References: <-krjPWn7QWUu4pMtvbAt8fHbzpCP6-dtTjgxg1e1KJE=.33721101-b475-4a78-823a-b1c6aa2f91bb@github.com>
Message-ID: <ajmqTkrYbs9-k5dg6_5ruYcbX6FGgpSmfLSm21myaDQ=.79a0734e-8849-407d-a3a8-bc17036d4530@github.com>

On Fri, 9 Dec 2022 11:02:09 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> Test instructions:
> - Accessible Actions Test;
> - AccessibleJTabbedPaneTest;
> - Accessible Text Test.
> contain inaccurate indications of actions in different screen readers.

This pull request has now been integrated.

Changeset: 9749a436
Author:    Artem Semenov <asemenov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9749a436418a2e2bcd1571e2fd6f16e3461cf883
Stats:     5 lines in 3 files changed: 0 ins; 0 del; 5 mod

8298457: Instructions in a11y manual tests need to be updated

Reviewed-by: kizune, serb

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

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


From mik3hall at gmail.com  Fri Dec  9 20:29:50 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 9 Dec 2022 14:29:50 -0600
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v19]
In-Reply-To: <ZNMA7VkpPAMRNRlblkKI8VObwPEbwn-yHdwctV3SyDA=.7ea85145-1f37-4120-851d-bbc3d1e35332@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <W8Ac5RQQcrQmv0Z_dU-lwhu1ny1MjgGq7xvnObMFTlU=.c4eeee8b-535e-4394-99db-10a7918e8733@github.com>
 <ZNMA7VkpPAMRNRlblkKI8VObwPEbwn-yHdwctV3SyDA=.7ea85145-1f37-4120-851d-bbc3d1e35332@github.com>
Message-ID: <D3AEDD57-7F25-4F04-8A85-26BE14F12EB9@gmail.com>



> On Dec 9, 2022, at 11:57 AM, Laurent Bourg?s <lbourges at openjdk.org> wrote:
> 
> On Thu, 8 Dec 2022 19:41:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:
> 
>>> Hi,
>>> 
>>> May I have this update reviewed?
>>> 
>>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>>> 
>>> Thanks,
>>> Xuelei
>> 
>> Xue-Lei Andrew Fan 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 24 additional commits since the last revision:
>> 
>> - adlc update per review
>> - Merge
>> - update on review feedback
>> - comment for snprintf_checked
>> - use checked snprintf for adlc
>> - use checked snprintf
>> - no check on adlc
>> - revert use of assert
>> - extra sizeof typo
>> - more size_t updare for windows build
>> - ... and 14 more: https://git.openjdk.org/jdk/compare/2309602b...49bb58fd
> 
> LGTM, build on macos 13 + xcode 14.1 (x64): OK
> 
> I run successfully few applications with built jdk image...
> 
> 
> Configuration summary:
> * Name:           macosx-x86_64-server-release
> * Debug level:    release
> * HS debug level: product
> * JVM variants:   server
> * JVM features:   server: 'cds compiler1 compiler2 dtrace epsilongc g1gc jfr jni-check jvmci jvmti management parallelgc serialgc services shenandoahgc vm-structs zgc' 
> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
> * Version string: 20-internal-adhoc.jmmc.jdk-gh (20-internal)
> * Source date:    1670605929 (2022-12-09T17:12:09Z)
> 
> Tools summary:
> * Boot JDK:       openjdk version "20-ea" 2023-03-21 OpenJDK Runtime Environment (build 20-ea+26-2022) OpenJDK 64-Bit Server VM (build 20-ea+26-2022, mixed mode, sharing) (at /Users/jmmc/apps/jdk-20.jdk/Contents/Home)
> * Toolchain:      clang (clang/LLVM from Xcode 14.1)
> * Sysroot:        /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk
> * C Compiler:     Version 14.0.0 (at /usr/bin/clang)
> * C++ Compiler:   Version 14.0.0 (at /usr/bin/clang++)
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/11115

Fwiw, Where I seem to differ?

macOS 12.6 

* Version string: 20-internal-adhoc.mjh.jdk (20-internal)
* Source date:    1668643046 (2022-11-16T23:57:26Z)

* Boot JDK:       openjdk version "19" 2022-09-20 OpenJDK Runtime Environment (build 19+36-2238) OpenJDK 64-Bit Server VM (build 19+36-2238, mixed mode, sharing) (at /Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home)

But it did build without the cmstypes errors.
Attempting tier 1 tests showed an sprintf deprecation error as follows?

=== Output from failing command(s) repeated here ===
* For target support_test_hotspot_jtreg_native_support_libAsyncExceptionOnMonitorEnter_libAsyncExceptionOnMonitorEnter.o:
/Users/mjh/Documents/GitHub/jdk/test/hotspot/jtreg/runtime/Thread/libAsyncExceptionOnMonitorEnter.cpp:37:3: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations]
  sprintf(name, "MyRawMonitor");
  ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/stdio.h:188:1: note: 'sprintf' has been explicitly marked deprecated here
__deprecated_msg("This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg'
        #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
                                                      ^
1 error generated.






From xuelei at openjdk.org  Fri Dec  9 22:41:54 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 9 Dec 2022 22:41:54 GMT
Subject: Integrated: 8296812: sprintf is deprecated in Xcode 14
In-Reply-To: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
Message-ID: <ao641OUbrIlOJ6DuQbB95Oh5lVN1V5lol1IE60A3Rr8=.6658bc07-ee13-4981-bc80-9990279ae6c8@github.com>

On Fri, 11 Nov 2022 22:41:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
> 
> Thanks,
> Xuelei

This pull request has now been integrated.

Changeset: 478ef389
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/478ef389dc3767edfbe21d10a7f7f1522c648c2e
Stats:     145 lines in 26 files changed: 45 ins; 4 del; 96 mod

8296812: sprintf is deprecated in Xcode 14

Reviewed-by: stuefe, prr, kbarrett, lucy

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

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


From duke at openjdk.org  Sat Dec 10 12:37:42 2022
From: duke at openjdk.org (ScientificWare)
Date: Sat, 10 Dec 2022 12:37:42 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v2]
In-Reply-To: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
Message-ID: <kMFEjsInGWE2lsPRjizAUe2O8z3vJ5EwxCNYM6NF21s=.2fba77fd-214e-4537-8718-3ed90281bd72@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8296661)
> 
> This is tracked in JBS as 
> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.openjdk.java.net/browse/JDK-8296661)
> 
> I suspect a typo in the documentation comments.
> 
> Designed from : [ScientificWare JDK-8296661 : Typo Found In CSSParser.java](https://github.com/scientificware/jdk/issues/18)

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

  Another type.
  
  Replace one by once.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10975/files
  - new: https://git.openjdk.org/jdk/pull/10975/files/9443d02a..4bfba96a

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

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

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


From javalists at cbfiddle.com  Sat Dec 10 16:48:01 2022
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sat, 10 Dec 2022 08:48:01 -0800
Subject: RFR: JDK-8294680: Refactor scaled border rendering
In-Reply-To: <BYAPR10MB3350EFED071DF1BBEF1572E7801C9@BYAPR10MB3350.namprd10.prod.outlook.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <DDBA75B2-4BFA-4784-BC1B-6E1827ED6DBD@cbfiddle.com>
 <BYAPR10MB3350EFED071DF1BBEF1572E7801C9@BYAPR10MB3350.namprd10.prod.outlook.com>
Message-ID: <8179DB02-30DE-4063-9A36-D0DDD2BFA733@cbfiddle.com>


On Dec 9, 2022, at 10:18 AM, Harshitha Onkar <harshitha.onkar at oracle.com> wrote:
> 
> Do you have a specific use case in mind?

No, but as a developer of a third party LAF and various custom Swing components I have had to duplicate ?private? Swing code multiple times, so I would like to encourage the view that Swing is an open set of components and LAFs and that the built in components and LAFs should not be considered special or privileged.

For amusement, see the JDK class AquaTabbedPaneCopyFromBasicUI where private Swing code was duplicated by Apple and remains.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221210/21b34089/attachment.htm>

From mik3hall at gmail.com  Sat Dec 10 19:17:30 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 10 Dec 2022 13:17:30 -0600
Subject: RFR: JDK-8294680: Refactor scaled border rendering
In-Reply-To: <8179DB02-30DE-4063-9A36-D0DDD2BFA733@cbfiddle.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <DDBA75B2-4BFA-4784-BC1B-6E1827ED6DBD@cbfiddle.com>
 <BYAPR10MB3350EFED071DF1BBEF1572E7801C9@BYAPR10MB3350.namprd10.prod.outlook.com>
 <8179DB02-30DE-4063-9A36-D0DDD2BFA733@cbfiddle.com>
Message-ID: <DC125E3B-0F1F-4EFD-838F-97A034CE8718@gmail.com>



> On Dec 10, 2022, at 10:48 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> 
> On Dec 9, 2022, at 10:18 AM, Harshitha Onkar <harshitha.onkar at oracle.com <mailto:harshitha.onkar at oracle.com>> wrote:
>> 
>> Do you have a specific use case in mind?
> 
> No, but as a developer of a third party LAF and various custom Swing components I have had to duplicate ?private? Swing code multiple times, so I would like to encourage the view that Swing is an open set of components and LAFs and that the built in components and LAFs should not be considered special or privileged.
> 
> For amusement, see the JDK class AquaTabbedPaneCopyFromBasicUI where private Swing code was duplicated by Apple and remains.
> 

As I remember a large part of the OS/X port project related to the Aqua LAF. A large undertaking where they probably made as minimal changes as possible and avoided re-inventing of wheels. 
So sort of ironic but not that hard to believe. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221210/773502bf/attachment.htm>

From duke at openjdk.org  Sat Dec 10 23:12:35 2022
From: duke at openjdk.org (Rajat Mahajan)
Date: Sat, 10 Dec 2022 23:12:35 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering
In-Reply-To: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
Message-ID: <mEHRRK-Qn1MbPW6Yp5gy6CAJ3v0suw1GlTMkVEh9Pa0=.be8cc27f-8c96-4aa7-a0eb-a08ca6def622@github.com>

On Wed, 7 Dec 2022 21:34:12 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as parameter to method.  
> 
> Following are the usual steps for any border scaling -
> 
> - Resetting transform.
> - Calculating new width, height, x & y-translations.
> - Perform the required border rendering.
> - And at the end restore the previous transform.
> 
> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
> 
> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
> 
> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.

Changes requested by rajamah at github.com (no known OpenJDK username).

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 174:

> 172: 
> 173:             if (resetTransform) {
> 174:                 g2d.setTransform(new AffineTransform());

Can we keep the original comment about this:
                /* Deactivate the HiDPI scaling transform,
                 * so we can do paint operations in the device
                 * pixel coordinate system instead of the logical coordinate system.
                 */

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 190:

> 188: 
> 189:         if (resetTransform) {
> 190:             double xx = at.getScaleX() * x + at.getTranslateX();

Can we combine this code block with the above if (resetTransform) at line 173 ? or did you keep it separate for a reason?

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

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


From serb at openjdk.org  Sun Dec 11 00:52:01 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 11 Dec 2022 00:52:01 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v4]
In-Reply-To: <zzy2jQ154Zxfu9cpVmly8jXDyRf4mbtdsJi9ytbI8CY=.7d9e4fb8-a9cb-43dc-aabb-6a54af4f9842@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
 <zzy2jQ154Zxfu9cpVmly8jXDyRf4mbtdsJi9ytbI8CY=.7d9e4fb8-a9cb-43dc-aabb-6a54af4f9842@github.com>
Message-ID: <J-JR11c5iNF0OzIkJBEfMt9su7EYkqeU9xd8i6gbRAg=.f4a7dd8a-286b-4273-be68-cf9735454508@github.com>

On Fri, 9 Dec 2022 04:03:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>>     javax.swing.text.html.parser.ParserDelegator
>>     javax.swing.LayoutComparator
>> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
>> 
>> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
>> Added the warning..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Capitalise swing

src/java.desktop/share/classes/javax/swing/text/html/parser/ParserDelegator.java line 51:

> 49:  *  the same version of Swing.  As of 1.4, support for long term storage
> 50:  *  of all JavaBeans
> 51:  *  has been added to the <code>java.beans</code> package

Looks like it has an unnecessary space after `*`

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

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


From serb at openjdk.org  Sun Dec 11 01:10:55 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 11 Dec 2022 01:10:55 GMT
Subject: RFR: 8193547: Regression automated test
 '/open/test/jdk/java/awt/Toolkit/DesktopProperties/rfe4758438.java' fails
In-Reply-To: <gf-HxIx7BCd7Im-4QlW4RtT3mKJcUVQHI-sDHK5rrYs=.e28b0d52-9e3c-4402-8964-1351ce88375b@github.com>
References: <gf-HxIx7BCd7Im-4QlW4RtT3mKJcUVQHI-sDHK5rrYs=.e28b0d52-9e3c-4402-8964-1351ce88375b@github.com>
Message-ID: <gFv9M33j9uaPuiL1cFah5HPRkjUOn3DG_3bsFyt6BT8=.f7af5a80-25fa-46a1-9d7d-1a99796d6186@github.com>

On Mon, 14 Nov 2022 00:03:51 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test has multiple issues:
> 
> * Test actually does nothing and passes as it is right now, but tests nothing
> * `pgrep gnome-session` may return multiple PIDs -> picking up only first one 
> * looks like jtreg does not pass GNOME_DESKTOP_SESSION_ID variable(it is deprecated, BTW), so used `XDG_CURRENT_DESKTOP` instead
> * removed leftovers from Solaris support
> * `org.gnome.settings-daemon.peripherals.mouse` is [deprecated](https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/master/data/org.gnome.settings-daemon.peripherals.gschema.xml.in#L46) and does not work on latest systems  <br> but newer `org.gnome.desktop.peripherals.mouse` works as expected<br>So the test modified to try new one and to check deprecated as a fallback
> 
> CI testing looks good.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.org  Sun Dec 11 01:11:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 11 Dec 2022 01:11:51 GMT
Subject: RFR: 8202931: [macos]
 java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java fails [v3]
In-Reply-To: <rTgkJ5GkjUUzcgAe7qGP7-vzijWpXpClg7jX06Z4WdE=.d7b1c7ad-e509-4ff2-a9ac-ca2d52b13dd2@github.com>
References: <lMoM5UnFcd2T8yHEY5lN7WFY2cSQL_18I6maJD6xxnw=.776f2663-c6a7-43ee-ab8c-c2210d95cee0@github.com>
 <rTgkJ5GkjUUzcgAe7qGP7-vzijWpXpClg7jX06Z4WdE=.d7b1c7ad-e509-4ff2-a9ac-ca2d52b13dd2@github.com>
Message-ID: <ep6PQAm8ch4-CHroOERj1mEoKztpFm7F_VCLeISdedA=.d6a104bd-c565-4407-b175-e65ddee41913@github.com>

On Wed, 30 Nov 2022 17:53:08 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Test ran on all OS 100 times and passed. Test previously failed on macOS but no longer reproducible. Added screen capture on moment of failure to have more evidence of failures in the future (previously a runtime exception was thrown only).
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra line

Marked as reviewed by serb (Reviewer).

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

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


From duke at openjdk.org  Sun Dec 11 20:03:46 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 11 Dec 2022 20:03:46 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v2]
In-Reply-To: <kMFEjsInGWE2lsPRjizAUe2O8z3vJ5EwxCNYM6NF21s=.2fba77fd-214e-4537-8718-3ed90281bd72@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
 <kMFEjsInGWE2lsPRjizAUe2O8z3vJ5EwxCNYM6NF21s=.2fba77fd-214e-4537-8718-3ed90281bd72@github.com>
Message-ID: <AMDjYuvaiODaZD5VyEVk5oCRXueq2xAXzeB0VPRWStc=.bcc9a6d2-893c-4331-ba33-79fc995c0441@github.com>

On Sat, 10 Dec 2022 12:37:42 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8296661)
>> 
>> This is tracked in JBS as 
>> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.openjdk.java.net/browse/JDK-8296661)
>> 
>> I suspect a typo in the documentation comments.
>> 
>> Designed from : [ScientificWare JDK-8296661 : Typo Found In CSSParser.java](https://github.com/scientificware/jdk/issues/18)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Another type.
>   
>   Replace one by once.

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

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

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


From duke at openjdk.org  Mon Dec 12 00:57:04 2022
From: duke at openjdk.org (ScientificWare)
Date: Mon, 12 Dec 2022 00:57:04 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v2]
In-Reply-To: <zbvDGc4EHbOQfvq8srOEeTwlyfraCuDbRYN0jXDo7RE=.dfa036b5-bebe-4d7c-af1a-ab8328184328@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
 <zbvDGc4EHbOQfvq8srOEeTwlyfraCuDbRYN0jXDo7RE=.dfa036b5-bebe-4d7c-af1a-ab8328184328@github.com>
Message-ID: <fl6SmgYdgQ1mgJ-8_RtaoeL_8Wozu27jMqOctHPUvvw=.7ad29a5d-9308-4030-910b-79eb7bde36ca@github.com>

On Mon, 5 Dec 2022 18:56:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Another type.
>>   
>>   Replace one by once.
>
> src/java.desktop/share/classes/javax/swing/text/html/CSSParser.java line 53:
> 
>> 51:  * <p>
>> 52:  * This will preserve case. If the callback wishes to treat certain portions
>> 53:  * case insensitively (such as selectors), it should use toLowerCase, or
> 
> Should this be ?case-insensitively? with the hyphen?

case-insensitively seems to be the most common usage in this repository.

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

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


From duke at openjdk.org  Mon Dec 12 01:07:17 2022
From: duke at openjdk.org (ScientificWare)
Date: Mon, 12 Dec 2022 01:07:17 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v3]
In-Reply-To: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
Message-ID: <T_n4F-WUYouM8APKbI1dQ5Om0WRwUEcJ8wFiISWQJ2E=.4278b2da-d25f-4273-8b2d-c7c301e30e74@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8296661)
> 
> This is tracked in JBS as 
> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.openjdk.java.net/browse/JDK-8296661)
> 
> I suspect a typo in the documentation comments.
> 
> Designed from : [ScientificWare JDK-8296661 : Typo Found In CSSParser.java](https://github.com/scientificware/jdk/issues/18)

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

  Another typo
  
  Add hyphen to "case insensitively". "case-insensitively" seems to be the common usage in the jdk repository.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10975/files
  - new: https://git.openjdk.org/jdk/pull/10975/files/4bfba96a..8b5eab5d

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

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

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


From psadhukhan at openjdk.org  Mon Dec 12 03:34:23 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 12 Dec 2022 03:34:23 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v5]
In-Reply-To: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
Message-ID: <986VElMBBNbPlH0FCPFcib3qApwF11IEOkHYsZpJz5E=.9cbb3b3b-de74-4b4d-8740-dbe2a34db5fd@github.com>

> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>     javax.swing.text.html.parser.ParserDelegator
>     javax.swing.LayoutComparator
> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
> 
> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
> Added the warning..

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

  Remove space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11565/files
  - new: https://git.openjdk.org/jdk/pull/11565/files/2229baab..3a229786

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

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

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


From psadhukhan at openjdk.org  Mon Dec 12 03:37:24 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 12 Dec 2022 03:37:24 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v6]
In-Reply-To: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
Message-ID: <GOnjn1otJM6CR6UhLCDU2HBQQ4udTis_wUvVQnDppe8=.bcee3e6d-6471-4efa-9f73-e8b687e07425@github.com>

> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>     javax.swing.text.html.parser.ParserDelegator
>     javax.swing.LayoutComparator
> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
> 
> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
> Added the warning..

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

  Remove space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11565/files
  - new: https://git.openjdk.org/jdk/pull/11565/files/3a229786..0147ee48

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

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

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


From abhiscxk at openjdk.org  Mon Dec 12 06:05:34 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 12 Dec 2022 06:05:34 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native
Message-ID: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>

It is not possible to select all files on press of Ctrl+A in JFileChooser for GTK LAF where as all folders can be selected. 
In native side on press of Ctrl+A, able to select all files as well as folders.

Proposed fix is to enable `multiselection `property by default for JFileChooser in GTK LAF to mimic native side behavior.

An automated test case is implemented and tested in CI. CI job links are attached in JBS.

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

Commit messages:
 - Select all files on CTrl+A fix

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

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


From serb at openjdk.org  Mon Dec 12 07:06:35 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 12 Dec 2022 07:06:35 GMT
Subject: RFR: 8280359: Try to remove duplicate code for coordinate calculation
Message-ID: <UwqaayGxh98sMkmmpxlYvwatXRmkqZ07HTsdL1P2GHg=.1dcd808f-7c2f-4a58-9290-dc1ff40f02ad@github.com>

The code from `AccessibilityGraphicsEnvironment` is moved/merged back to the `SunGraphicsEnvironment` from where it was initially [copied](https://github.com/openjdk/jdk18/pull/72#issuecomment-1001050200). The required API is exported from the `sun.java2d` to the `jdk.accessibility`(on WIndows only).

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

Commit messages:
 - 8280359: Try to remove duplicate code for coordinate calculation

Changes: https://git.openjdk.org/jdk/pull/11626/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11626&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8280359
  Stats: 307 lines in 3 files changed: 110 ins; 185 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/11626.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11626/head:pull/11626

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


From tr at openjdk.org  Mon Dec 12 07:29:02 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 12 Dec 2022 07:29:02 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel
In-Reply-To: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
Message-ID: <pYeCNRYHEcoZTKCzE-d1r0Uo6oDYmkiBsmQhCdJ6jig=.340ca791-e00c-4dcf-b8cf-819c5e193566@github.com>

On Wed, 7 Dec 2022 10:25:31 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> In case of GTK LAF, the current selected element was not visible due to arrowbutton is rendered in entire display area of Combobox.
> 
> The proposed fix is to set the `squareButton `property of combobox to `false `so that the arrowbutton didn't take entire combobox display area for rendering. The `getMinimumSize `method is overridden in `SynthComboBoxUI `to consider **arrowbutton insets** for combobox minimum size. 
> 
> The JCK tests mentioned in JBS seems fine with the fix. 
> An automated test case is implemented to test in Nimbus and GTK LAF. The text color check is to ensure the current selected item is visible.
> 
> When swing tests are run with LAF set to Nimbus and GTK LAF, few test failures observed. 
> 
> Although CI jobs looks ok with tests run in their default set LAFs.
> 
> `open/test/jdk/javax/swing/JComboBox/TestComboBoxHeight.java` test passes if run in GTK LAF with current fix.

_TestComboBoxComponentRendering.java_ test failed (Synth L&F) in Ubuntu_21 VM machine. .jtr file and Failure case screen captured shared.

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

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


From psadhukhan at openjdk.org  Mon Dec 12 07:32:26 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 12 Dec 2022 07:32:26 GMT
Subject: RFR: 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame
 throws a NPE.
In-Reply-To: <94q2edPe5cN5NoGNaNLiXKMTBhJYHsDnEfj59w0Kpgg=.1acee9aa-e345-4620-9314-827418b4eaf2@github.com>
References: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
 <94q2edPe5cN5NoGNaNLiXKMTBhJYHsDnEfj59w0Kpgg=.1acee9aa-e345-4620-9314-827418b4eaf2@github.com>
Message-ID: <WOwjAWwpry4ohQYXs_PUBzqNxuq3djUOXyzhxl6GUN4=.1d8438db-b13e-4b04-bc47-14fd92dfe3cb@github.com>

On Fri, 9 Dec 2022 19:20:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> It would be good to add a test case to make sure this bug will not happen someday again.

I tried but it seems AWT EventQueue is gobbling up the NPE and not throwing it to application which is why even though NPE is seen but test does not fail...


/*
 * Copyright (c) 2022, 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.
 *
 * 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.
 */
/*
 * @test
 * @key headful
 * @bug 6603771
 * @summary  Verifies Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame throws a NPE
 * @run main JInternalFrameTest
 */
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class JInternalFrameTest {
    static JFrame jFrame;
    static JInternalFrame iFrame;

     private static void setLookAndFeel(UIManager.LookAndFeelInfo laf) {
        try {
            UIManager.setLookAndFeel(laf.getClassName());
//	    UIManager.setLookAndFeel("javax.swing.plaf.nimbus.NimbusLookAndFeel");
        } catch (UnsupportedLookAndFeelException ignored) {
            System.out.println("Unsupported L&F: " + laf.getClassName());
        } catch (ClassNotFoundException | InstantiationException
                | IllegalAccessException e) {
            throw new RuntimeException(e);
        }
    }

    public static void main(String[] args) throws Exception {
        Robot robot = new Robot();
        for (UIManager.LookAndFeelInfo laf :
                 UIManager.getInstalledLookAndFeels()) {
            System.out.println("Testing L&F: " + laf.getClassName());
            SwingUtilities.invokeAndWait(() -> setLookAndFeel(laf));
            try {
                SwingUtilities.invokeAndWait(() -> createUI());
                robot.waitForIdle();
                robot.delay(1000);

                Point pt = iFrame.getLocationOnScreen();
                Rectangle dim = iFrame.getBounds();
                robot.mouseMove(pt.x + dim.width/3, pt.y);
                robot.waitForIdle();
                robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
                robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
                robot.waitForIdle();
                robot.delay(1000);
                robot.keyPress(KeyEvent.VK_CONTROL);
                robot.keyPress(KeyEvent.VK_F7);
                robot.keyRelease(KeyEvent.VK_F7);
                robot.keyRelease(KeyEvent.VK_CONTROL);
                robot.waitForIdle();
                robot.delay(1000);
                robot.keyPress(KeyEvent.VK_UP);
                robot.keyRelease(KeyEvent.VK_UP);
                robot.waitForIdle();
                robot.delay(1000);
            } catch (Exception e) {
                System.out.println("NPE");
		e.printStackTrace();
            }finally {
                if (jFrame != null) {
                    SwingUtilities.invokeAndWait(() -> jFrame.dispose());
                }
            }
        }
    }
   
    private static void createUI() {	
     	jFrame = new JFrame();

	JDesktopPane desktopPane = new JDesktopPane();

        iFrame =  new JInternalFrame("Test");

	iFrame.setTitle("InternalFrame");
	iFrame.setClosable(true);
	iFrame.setMaximizable(true);
	iFrame.setIconifiable(true);
	iFrame.setResizable(true);
	iFrame.setLocation(50, 50);
        iFrame.setSize(200, 200);
        iFrame.setVisible(true);

	desktopPane.add(iFrame);

	JPanel panel = new JPanel();
	panel.setLayout(new BorderLayout());
	panel.add(desktopPane, BorderLayout.CENTER);

	jFrame.add(panel, BorderLayout.CENTER);
        jFrame.setSize(400, 400);
	jFrame.setLocationRelativeTo(null);
        jFrame.setVisible(true);
	
    }
}

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

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


From abhiscxk at openjdk.org  Mon Dec 12 09:40:15 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 12 Dec 2022 09:40:15 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel
In-Reply-To: <Hxtdl5xVvpzHDuf5Yh4WOQ60nWF4_LL0_MEkgHQVriY=.6b64122e-2749-4b6c-b391-5312d697bcc9@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
 <Hxtdl5xVvpzHDuf5Yh4WOQ60nWF4_LL0_MEkgHQVriY=.6b64122e-2749-4b6c-b391-5312d697bcc9@github.com>
Message-ID: <31rB7g4kY5SaYjK90_PlgB_fBd2ejVvb3mhfRoWwDEw=.895557ab-4ad0-4fd4-9c5a-9514774f02d9@github.com>

On Wed, 7 Dec 2022 22:00:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> No it is confidential or something like that. Cannot open/view it.

The bug is open now. Please have a look.

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

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


From abhiscxk at openjdk.org  Mon Dec 12 10:31:13 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 12 Dec 2022 10:31:13 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel
In-Reply-To: <pYeCNRYHEcoZTKCzE-d1r0Uo6oDYmkiBsmQhCdJ6jig=.340ca791-e00c-4dcf-b8cf-819c5e193566@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
 <pYeCNRYHEcoZTKCzE-d1r0Uo6oDYmkiBsmQhCdJ6jig=.340ca791-e00c-4dcf-b8cf-819c5e193566@github.com>
Message-ID: <8FVGtWwcIbQMorFWYKtDGtEjTSN9VotwbjknJZMOKrw=.25b01ec0-aaea-479f-90b5-cebbcbc04d97@github.com>

On Mon, 12 Dec 2022 07:26:45 GMT, Tejesh R <tr at openjdk.org> wrote:

> _TestComboBoxComponentRendering.java_ test failed (Synth L&F) in Ubuntu_21 VM machine. .jtr file and Failure case screen captured shared.

Run the test in Ubuntu 20,21 and 22 in CI pipeline, test passed for all platform.

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

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


From azvegint at openjdk.org  Mon Dec 12 12:13:49 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 12 Dec 2022 12:13:49 GMT
Subject: RFR: 8193547: Regression automated test
 '/open/test/jdk/java/awt/Toolkit/DesktopProperties/rfe4758438.java' fails [v2]
In-Reply-To: <gf-HxIx7BCd7Im-4QlW4RtT3mKJcUVQHI-sDHK5rrYs=.e28b0d52-9e3c-4402-8964-1351ce88375b@github.com>
References: <gf-HxIx7BCd7Im-4QlW4RtT3mKJcUVQHI-sDHK5rrYs=.e28b0d52-9e3c-4402-8964-1351ce88375b@github.com>
Message-ID: <XOxwXUW7HLl-GyjCbdPA_j5O8ga43tXymalJHSUVT-Q=.b0e08be7-39fc-452b-a154-f232e731b972@github.com>

> This test has multiple issues:
> 
> * Test actually does nothing and passes as it is right now, but tests nothing
> * `pgrep gnome-session` may return multiple PIDs -> picking up only first one 
> * looks like jtreg does not pass GNOME_DESKTOP_SESSION_ID variable(it is deprecated, BTW), so used `XDG_CURRENT_DESKTOP` instead
> * removed leftovers from Solaris support
> * `org.gnome.settings-daemon.peripherals.mouse` is [deprecated](https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/master/data/org.gnome.settings-daemon.peripherals.gschema.xml.in#L46) and does not work on latest systems  <br> but newer `org.gnome.desktop.peripherals.mouse` works as expected<br>So the test modified to try new one and to check deprecated as a fallback
> 
> CI testing looks good.

Alexander Zvegintsev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge master
 - fix access rights
 - initial

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

Changes: https://git.openjdk.org/jdk/pull/11127/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11127&range=01
  Stats: 125 lines in 3 files changed: 72 ins; 22 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/11127.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11127/head:pull/11127

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


From aivanov at openjdk.org  Mon Dec 12 13:00:07 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Dec 2022 13:00:07 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v3]
In-Reply-To: <T_n4F-WUYouM8APKbI1dQ5Om0WRwUEcJ8wFiISWQJ2E=.4278b2da-d25f-4273-8b2d-c7c301e30e74@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
 <T_n4F-WUYouM8APKbI1dQ5Om0WRwUEcJ8wFiISWQJ2E=.4278b2da-d25f-4273-8b2d-c7c301e30e74@github.com>
Message-ID: <i_Fh5oi7793nWKPoy0lP5dba4NE8jUfg7OONDY5EfpY=.4f0e51c8-4254-4bcd-a6ef-41caf16ec498@github.com>

On Mon, 12 Dec 2022 01:07:17 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8296661)
>> 
>> This is tracked in JBS as 
>> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.openjdk.java.net/browse/JDK-8296661)
>> 
>> I suspect a typo in the documentation comments.
>> 
>> Designed from : [ScientificWare JDK-8296661 : Typo Found In CSSParser.java](https://github.com/scientificware/jdk/issues/18)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Another typo
>   
>   Add hyphen to "case insensitively". "case-insensitively" seems to be the common usage in the jdk repository.

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.org  Mon Dec 12 13:10:09 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Dec 2022 13:10:09 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v3]
In-Reply-To: <zbvDGc4EHbOQfvq8srOEeTwlyfraCuDbRYN0jXDo7RE=.dfa036b5-bebe-4d7c-af1a-ab8328184328@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
 <zbvDGc4EHbOQfvq8srOEeTwlyfraCuDbRYN0jXDo7RE=.dfa036b5-bebe-4d7c-af1a-ab8328184328@github.com>
Message-ID: <XQc1zO2_1zdGa9qZ7uI0V6EzSwf4CWw7hl2B4-d8Enc=.c2a9f7e8-03f8-4b02-b823-6385da2968b0@github.com>

On Mon, 5 Dec 2022 19:01:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I think there's room for improvement. However, this is an internal-only class.

This is what I have in mind. The list of callbacks is inconsistent in how the method and conditions when it's called are listed. One of the list items has no ending punctuation. Some portions of text should use `<code>` or `{@code}`, or even [`<samp>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/samp).

I think `<p>` should be added before this sentence, _?If an error results in parsing, a RuntimeException will be thrown.?_ The sentence itself requires re-writing: ?If parsing results in an error??

Both `RuntimeException` and `toLowerCase` below should be in `{@code}`.

The usage of `<code>` could be updated to `{@code}` which is the recommended way.

What do you think?

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

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


From duke at openjdk.org  Mon Dec 12 14:58:57 2022
From: duke at openjdk.org (Naveen Narayanan)
Date: Mon, 12 Dec 2022 14:58:57 GMT
Subject: RFR: 8296275: Write a test to verify setAccelerator method of
 JMenuItem [v6]
In-Reply-To: <EtSyILAIY0F-wpz-VNyI2vfk4GSfbIzyvOnPVV_WezE=.d81ca068-99da-413c-ab38-629b3b6a09e3@github.com>
References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
 <Q957c8-nyOhidQ478zoe67NomvBhIAQgVqvODSSHH_M=.229c7272-cade-467b-9c30-da6f20b954a0@github.com>
 <EtSyILAIY0F-wpz-VNyI2vfk4GSfbIzyvOnPVV_WezE=.d81ca068-99da-413c-ab38-629b3b6a09e3@github.com>
Message-ID: <n_Kc99m_tOwPNZnNVMn6xubrqc4F7BdsnUYa28y9t0k=.19faa36c-ac2c-4eee-9ad6-d1700db758e6@github.com>

On Tue, 29 Nov 2022 16:08:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8296275: Review comments fixed.
>
> I have to repeat a more serious problem:
> 
>> Since the test has nothing to do with `Desktop` class it should be moved to `JMenuItem` folder because it tests functionality of `JMenuItem`.
> 
> If it's supposed to test the Swing support for macOS global, then the test should do it.
> 
> Could you please clarify? If it's for regular  `JMenu` and `JMenuItem`, move the test; if it's for the global, then modify the test accordingly.

@aivanov-jdk, @mrserb all review comments addressed.

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

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


From aivanov at openjdk.org  Mon Dec 12 16:12:55 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Dec 2022 16:12:55 GMT
Subject: RFR: 8244400: MenuItem may cache the size and did not update it
 when the screen DPI is changed [v3]
In-Reply-To: <3PaNLLK-YJG2ccMZRXvhk7R_KsdTIBUX7jseDNo_BYU=.b1a73ab8-a80b-487b-9274-a2cd699ef815@github.com>
References: <-uTiC-hv_VAqzznPs2lyYbPFmjJ06PIGZZCbEfuwPgE=.6d97f3a5-bd81-4697-9299-0e7039e2d9c2@github.com>
 <3PaNLLK-YJG2ccMZRXvhk7R_KsdTIBUX7jseDNo_BYU=.b1a73ab8-a80b-487b-9274-a2cd699ef815@github.com>
Message-ID: <woftH72jVIoBDcUi52GVXkmxg5awa6CZCb-kuX1J8os=.1f22c8c8-20e0-4447-b7c3-a991a5ac36be@github.com>

On Thu, 8 Dec 2022 03:38:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The MenuItemLayoutHelper.clearUsedParentClientProperties must be called automatically when the DPI was changed. 
>> Workaround added in the test for this bug is removed.
>> 
>> CI tests are ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Motif

Marked as reviewed by aivanov (Reviewer).

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

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


From andy.goryachev at oracle.com  Mon Dec 12 17:06:44 2022
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 12 Dec 2022 17:06:44 +0000
Subject: RFR: JDK-8294680: Refactor scaled border rendering
In-Reply-To: <8179DB02-30DE-4063-9A36-D0DDD2BFA733@cbfiddle.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <DDBA75B2-4BFA-4784-BC1B-6E1827ED6DBD@cbfiddle.com>
 <BYAPR10MB3350EFED071DF1BBEF1572E7801C9@BYAPR10MB3350.namprd10.prod.outlook.com>
 <8179DB02-30DE-4063-9A36-D0DDD2BFA733@cbfiddle.com>
Message-ID: <DM5PR1001MB2172D3638814C569A8951E56E5E29@DM5PR1001MB2172.namprd10.prod.outlook.com>

I second Alan's sentiment.  If a helpful utility method is called multiple times from Swing code, it does make sense to make publicly available - chances are it is also useful to the application or third party component developers.

Copying code from Swing has a legal aspect - it probably makes the third party code GPL-d, which is probably not what the stakeholders want.

-andy


From: client-libs-dev <client-libs-dev-retn at openjdk.org> on behalf of Alan Snyder <javalists at cbfiddle.com>
Date: Saturday, 2022/12/10 at 08:48
To: Harshitha Onkar <harshitha.onkar at oracle.com>
Cc: client-libs-dev at openjdk.org <client-libs-dev at openjdk.org>
Subject: Re: RFR: JDK-8294680: Refactor scaled border rendering

On Dec 9, 2022, at 10:18 AM, Harshitha Onkar <harshitha.onkar at oracle.com<mailto:harshitha.onkar at oracle.com>> wrote:


Do you have a specific use case in mind?

No, but as a developer of a third party LAF and various custom Swing components I have had to duplicate ?private? Swing code multiple times, so I would like to encourage the view that Swing is an open set of components and LAFs and that the built in components and LAFs should not be considered special or privileged.

For amusement, see the JDK class AquaTabbedPaneCopyFromBasicUI where private Swing code was duplicated by Apple and remains.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221212/76a3131d/attachment.htm>

From aivanov at openjdk.org  Mon Dec 12 17:25:10 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Dec 2022 17:25:10 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip [v4]
In-Reply-To: <qjQR6ToIVvsP761COUv8NYZAts-kx3WCsnCHcHUEeU4=.d1fc19ca-d24b-433a-b628-6af036787d29@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
 <RI5sg7RRZy0Xsgfw6bI8aOf2esZBm75xvxDmYtVF-sI=.94c876af-afa3-435a-a451-fd339bf326a0@github.com>
 <qjQR6ToIVvsP761COUv8NYZAts-kx3WCsnCHcHUEeU4=.d1fc19ca-d24b-433a-b628-6af036787d29@github.com>
Message-ID: <lAf6RnJNt4IPnYAZZS5XTQuX8rBPrQjnT8gtq2nMGaw=.2a04dcfd-9fa9-48cd-8702-5de96f8d95f8@github.com>

On Thu, 8 Dec 2022 22:49:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Thank you for removing that large try/catch block. Looks much better.

I agree, the code is clearer now.

I started reviewing the updated code but I haven't finished it. It's _integrated_ now.

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

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


From aivanov at openjdk.org  Mon Dec 12 17:33:38 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Dec 2022 17:33:38 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <m3I7nZheq3J6lIN0UlEnQrsLEaPKBqQgMnBvBKlTrZM=.4e3dcb57-f4a1-4443-a308-3beea1160cfc@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <ry0IIjcxmW_Lo7wI0-nRof9kg5LkLeh-i0zNhrEEdTg=.dcaef664-765e-4f53-8516-47ba3595ecb0@github.com>
 <D1DOLLXwcictjqWFMlcQ8_xJWLnQOhxJBS-716UnafM=.2fd2b9a3-e7bf-4f26-a15b-2767987cfa66@github.com>
 <m3I7nZheq3J6lIN0UlEnQrsLEaPKBqQgMnBvBKlTrZM=.4e3dcb57-f4a1-4443-a308-3beea1160cfc@github.com>
Message-ID: <Ku3yP3_RG1rh0odByvvckH2HEleb_GrWGLXq7upcTVA=.44e24fc2-d6e5-45a7-b855-b666102ea0c7@github.com>

On Thu, 1 Dec 2022 19:37:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Do we need to wait a bit longer after creating JFileChooser as the test immediately ends after instantiating it? Also, doesn't JFileChooser needs headful keyword as it needs to show a file dialog? Does it work more reliably if its to run in headful CI systems?
>> 
>> Should the test be headful even if we instantiate JFileChooser without showing the dialog.? I can check with a delay after its instantiated, but no sure if that might be causing the issue. Because the same issue is observed in another bug also which instantiates JFileChooser and does some tasks after that.
>
>> > Do we need to wait a bit longer after creating JFileChooser as the test immediately ends after instantiating it? Also, doesn't JFileChooser needs headful keyword as it needs to show a file dialog? Does it work more reliably if its to run in headful CI systems?
>> 
>> Should the test be headful even if we instantiate JFileChooser without showing the dialog.? I can check with a delay after its instantiated, but no sure if that might be causing the issue. Because the same issue is observed in another bug also which instantiates JFileChooser and does some tasks after that.
> 
> It doesn't need to be. It would've failed if it had required a headful system.
> 
> However, it may still be a valid concern. I faced some obscure failures on headless systems running Windows.
> 
> The exception is thrown on EDT when `JFileChooser` calculates its preferred size, so the test seem to work correctly. As such, I don't think the failure is related to the fact that the test exits after creating `JFileChooser`.
> 
> One of the options to fix the test is to add `@key headful`.
> 
> I wonder if the _Downloads_ folder is the first folder for which the icon is requested. Does fetching icons for other folders also fail? Does the host where the test fails have Windows Explorer? Windows Server systems can have minimal UI, if Windows Explorer is not available, then the `headful` keyword is the way to go.
> 
> So, we need to collect more data why it fails, why the icon of a folder is `null`.
> 
> In addition to that, we have to ensure `null` is returned directly to the caller rather than creating a `MultiResolutionImage` which doesn't even contain a base image.

> @aivanov-jdk I just run some test samples by making the test as headful instead as headless as @prsadhuk suggested. I found out that making it as headful works just fine and no NPE occurred (Headless always showed issue, 8/200 test). And debugging to the root cause of Image not loading is also quite difficult. I guess it's better to modify the test as headful since the reliability of the test is better in it?

Let's go for it. A headless system could lack something that the test uses even though it doesn't show the UI.

If _headful_ systems never reproduce the problem, then it's _the fix_.

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

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


From aivanov at openjdk.org  Mon Dec 12 17:33:39 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Dec 2022 17:33:39 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
Message-ID: <ddjbSHKmT8CjLCSqK18vAfCREE3FHGTGDs7-gCkPll8=.9b04029f-ff3e-41cf-9417-72fac385f3bd@github.com>

On Fri, 11 Nov 2022 08:18:19 GMT, Tejesh R <tr at openjdk.org> wrote:

> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.

At the same time, I suggest filing another bug to track the issue where the code could return a `MultiResolutionImage` with no base image. It should never happen.

Or you can address it here along with making the test _headful_.

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

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


From prr at openjdk.org  Mon Dec 12 17:40:07 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 12 Dec 2022 17:40:07 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled
In-Reply-To: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
Message-ID: <J0qb6-O_Ivd6byKSOHoX_9H_61xC0XfkF9UJIY7u-iE=.df71eaab-4017-42a6-a8ea-dc025f8841d5@github.com>

On Tue, 4 Oct 2022 22:52:30 GMT, SWinxy <duke at openjdk.org> wrote:

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

I have made a number of edits to the CSR.
There is some rewording which you need to copy back to here.
Also I didn't see the need to include the @see changes in other methods in the CSR. They are not spec-relevant and clutter it

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

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


From duke at openjdk.org  Mon Dec 12 18:27:24 2022
From: duke at openjdk.org (SWinxy)
Date: Mon, 12 Dec 2022 18:27:24 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v2]
In-Reply-To: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
Message-ID: <KwuZH3CQlUiklf-h_yzbB1RzoXACnqXNjWX4RZjGCI0=.5651d65a-391c-4588-9037-4d78d2ae357e@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.

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

  Sync with CSR
  
  Only difference is that I added an Oxford comma

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10565/files
  - new: https://git.openjdk.org/jdk/pull/10565/files/c5b9b48d..009855eb

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

  Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 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 duke at openjdk.org  Mon Dec 12 18:29:29 2022
From: duke at openjdk.org (SWinxy)
Date: Mon, 12 Dec 2022 18:29:29 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled
In-Reply-To: <J0qb6-O_Ivd6byKSOHoX_9H_61xC0XfkF9UJIY7u-iE=.df71eaab-4017-42a6-a8ea-dc025f8841d5@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
 <J0qb6-O_Ivd6byKSOHoX_9H_61xC0XfkF9UJIY7u-iE=.df71eaab-4017-42a6-a8ea-dc025f8841d5@github.com>
Message-ID: <cH0BMcILtfMA5xnQh9PQLB43Hn3xGsTZrglKAaIdJ8E=.1bbc2ef5-d8af-4bd4-9a25-98d77daff1b5@github.com>

On Mon, 12 Dec 2022 17:37:24 GMT, Phil Race <prr at openjdk.org> wrote:

> I have made a number of edits to the CSR. There is some rewording which you need to copy back to here. Also I didn't see the need to include the @see changes in other methods in the CSR. They are not spec-relevant and clutter it

Done. The only thing I want is the oxford comma in the documentation to separate the background color and font wording.

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

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


From honkar at openjdk.org  Mon Dec 12 19:12:36 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 12 Dec 2022 19:12:36 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering
In-Reply-To: <mEHRRK-Qn1MbPW6Yp5gy6CAJ3v0suw1GlTMkVEh9Pa0=.be8cc27f-8c96-4aa7-a0eb-a08ca6def622@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <mEHRRK-Qn1MbPW6Yp5gy6CAJ3v0suw1GlTMkVEh9Pa0=.be8cc27f-8c96-4aa7-a0eb-a08ca6def622@github.com>
Message-ID: <EqwXPy5ojUzBW9L3qEX1D06C8_OPUwzXy6HEoYMYtMU=.2dfca9d9-66a9-470b-bd78-6511d6080da3@github.com>

On Sat, 10 Dec 2022 23:08:48 GMT, Rajat Mahajan <duke at openjdk.org> wrote:

>> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as parameter to method.  
>> 
>> Following are the usual steps for any border scaling -
>> 
>> - Resetting transform.
>> - Calculating new width, height, x & y-translations.
>> - Perform the required border rendering.
>> - And at the end restore the previous transform.
>> 
>> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
>> 
>> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
>> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
>> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
>> 
>> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.
>
> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 174:
> 
>> 172: 
>> 173:             if (resetTransform) {
>> 174:                 g2d.setTransform(new AffineTransform());
> 
> Can we keep the original comment about this:
>                 /* Deactivate the HiDPI scaling transform,
>                  * so we can do paint operations in the device
>                  * pixel coordinate system instead of the logical coordinate system.
>                  */

Sure. I can add it.

> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 190:
> 
>> 188: 
>> 189:         if (resetTransform) {
>> 190:             double xx = at.getScaleX() * x + at.getTranslateX();
> 
> Can we combine this code block with the above if (resetTransform) at line 173 ? or did you keep it separate for a reason?

@rajamah In-order to paint the border even when g is not a Graphics2D object I have added the `resetTransform` check here again and additionally to keep the if & else block close-by, which is easier to understand rather than having the blocks separated.

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

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


From aivanov at openjdk.org  Mon Dec 12 19:46:58 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Dec 2022 19:46:58 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus
In-Reply-To: <IbV9yqheiG_50Wo11dSqWs7tDqjF1Hcc8XqKnt2fSeE=.6bc1a4ae-c5aa-44e7-afac-0b938d7d6c0e@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <e7ITSsOpcKtlC2bJNzIM3PFCUcoRZdfRi0mr1JxsgFE=.f37d4fe5-6a07-427c-b87f-b0ba50efcc6c@github.com>
 <VUwbo01Ivv81AevheTugl-_xosvdnzR7jhFhJtdViaE=.493aee6b-d32a-4258-8271-b25a281273d8@github.com>
 <xJz52QqQG3jjK_eODsEXefcjWz7dfCLa29VepSCwYtE=.1757660e-6211-4917-9a41-e9d5908ccecc@github.com>
 <sl_FDZPPaLyWqv74FBu0aJwzSvRgIwrT_Lj8TF3AtpU=.1dddf19e-c2b6-48ba-b477-dc685bbc1efb@github.com>
 <Pfc1L8tORSVPgNs51CRj0MkEF0EtbOIt7-gnmpswjDA=.1b49bc05-0a92-4c54-805d-54815983e2be@github.com>
 <2XePfo1gtNAWJvM5ECfg8Vkp8VObLOyQmM8WkQDiabM=.43f5d635-9352-4cc8-b9d9-e76aa710064d@github.com>
 <bwZOldi_Ad40uVp3MIJTAqSJCztBfjVxsF8z661AN94=.5168abd0-a31d-4ae1-ad30-7ec2b620ad6e@github.com>
 <oCIy6x1tlZsFtQqokU5PVFFZcs0jOxccr8dYkyJ7uXE=.4d9fc026-99f2-4cfb-9cec-4facbed01226@github.com>
 <zlaK88xn6qUJ9vQlQlUQubxVkF6kqjoi5JOQ-f-h-QY=.f3dd2f94-94fc-47bd-950e-0cdc7b5968c5@github.com>
 <IbV9yqheiG_50Wo11dSqWs7tDqjF1Hcc8Xq
 Knt2fSeE=.6bc1a4ae-c5aa-44e7-afac-0b938d7d6c0e@github.com>
Message-ID: <6MgKYrMaEjtPvM5pSa8VoD6zt9zS9Cn_fGq5Par7168=.5533f66d-33e9-4f3c-972d-215a69925517@github.com>

On Thu, 8 Dec 2022 12:46:48 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>>> > If that is not possible I suggest providing that functionality so applications will be able to use that. Probably even provide some predefined cursors, like "faded"/"blurred"/nonblinked/etc. That could be configured per L&F as well.
>> 
>>> That would be a nice feature to have but right now we have an issue where default behaviour of the component defies the VPAT guidelines.
>> 
>> I am not sure that changing the default behavior of all text components(including embedded to other components) to use a non-blinking cursor is a good idea, you can convince me if you find someone who uses the same approach, any applications? Probably at least for the native look&feels we can use the same behavior as the native default components win32/cocoa/gtk.
>
>> someone who uses the same approach, any applications
> 
> Gnome on Ubuntu 22, default applications. Editable text components have blinking carets, non-editable - non-blinking ones.

I agree with @azuev-java. A caret ? blinking or not ? is better than no caret at all.

The caret not only visually shows the focus owner (a non-editable text component) but also facilitates text selection (with keyboard).

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

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


From serb at openjdk.org  Mon Dec 12 20:14:59 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 12 Dec 2022 20:14:59 GMT
Subject: RFR: 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame
 throws a NPE.
In-Reply-To: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
References: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
Message-ID: <Lv9JMqlsbn1huvP439AIo5oCZxNs4sk7d4bskddlR-c=.589eaaac-00b2-46c7-8f1b-6563fb6aac78@github.com>

On Fri, 9 Dec 2022 08:06:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In Swingset2 JInternalFrame demo, focusing on any internalframes and pressing Ctrl+F7 and then any of up/down/left/arrow key to move the internal frames results in NPE in NimbusL&F.
> It is because `JComponent.processKeyBinding() `calls `SwingUtilities.notifyAction` which calls `BasicDesktopPaneUI.actionPerformed` where it gets `Desktop.minOnScreenInsets` property to get the Insets and then uses insets.top/bottom/left/right value to move the internalframe but this property is not defined for Nimbus so deferencing Insets object results in NPE.
> 
> Fix is added to create a 0 insets incase some L&F do not define` Desktop.minOnScreenInsets` property.
> No regression test is added as it can be easily checked by SwingSet2 JInternalFrame demo.

You can install the `UncaughtExceptionHandler` on EDT to catch that exception:

    public static void main(String[] args) throws Exception {
        EventQueue.invokeAndWait(
                () -> Thread.currentThread().setUncaughtExceptionHandler(
                        (t, e) -> System.out.println("Error?")));

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

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


From duke at openjdk.org  Mon Dec 12 20:45:57 2022
From: duke at openjdk.org (Rajat Mahajan)
Date: Mon, 12 Dec 2022 20:45:57 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering
In-Reply-To: <EqwXPy5ojUzBW9L3qEX1D06C8_OPUwzXy6HEoYMYtMU=.2dfca9d9-66a9-470b-bd78-6511d6080da3@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <mEHRRK-Qn1MbPW6Yp5gy6CAJ3v0suw1GlTMkVEh9Pa0=.be8cc27f-8c96-4aa7-a0eb-a08ca6def622@github.com>
 <EqwXPy5ojUzBW9L3qEX1D06C8_OPUwzXy6HEoYMYtMU=.2dfca9d9-66a9-470b-bd78-6511d6080da3@github.com>
Message-ID: <r-fO1cAyEc9jKgiS-Ahp9vBTqhbGK8CHl9BNMTTp0vs=.a58fcf2b-3391-4399-99dc-c99a5f7b9d33@github.com>

On Mon, 12 Dec 2022 19:09:02 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 190:
>> 
>>> 188: 
>>> 189:         if (resetTransform) {
>>> 190:             double xx = at.getScaleX() * x + at.getTranslateX();
>> 
>> Can we combine this code block with the above if (resetTransform) at line 173 ? or did you keep it separate for a reason?
>
> @rajamah In-order to paint the border even when g is not a Graphics2D object I have added the `resetTransform` check here again and additionally to keep the if & else block close-by, which is easier to understand rather than having the blocks separated.

sure, makes sense. Thanks

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

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


From aivanov at openjdk.org  Mon Dec 12 21:05:22 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Dec 2022 21:05:22 GMT
Subject: RFR: 8296275: Write a test to verify setAccelerator method of
 JMenuItem [v8]
In-Reply-To: <8NYHld9tBOAyBPZk00A_73beOW6lj8a_w-9lJSthLJ8=.473b501e-38f6-4306-a11e-2970dbb87ac4@github.com>
References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
 <8NYHld9tBOAyBPZk00A_73beOW6lj8a_w-9lJSthLJ8=.473b501e-38f6-4306-a11e-2970dbb87ac4@github.com>
Message-ID: <I4vq-CSA3tFBc78r7E_QYZIL3fcIkMJP_yHRb__x_Pc=.ad504699-fe7a-47ea-bfbb-33c240af46df@github.com>

On Fri, 9 Dec 2022 05:36:03 GMT, Naveen Narayanan <duke at openjdk.org> wrote:

>> This testcase will
>> 1) Verify setAccelerator method of JMenuitem.
>> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M.
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass.
>
> Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8296275: Removing trailing whitespaces.

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JMenuItem/JMenuItemSetAcceleratorTest.java line 61:

> 59:         JMenuBar bar = new JMenuBar();
> 60:         JMenu menu = new JMenu("File Menu");
> 61:         JMenuItem menuItem = new JMenuItem("File Menu Item");

_File_ is much more standard than _File Menu_ unless you have a specific reason for a longer menu item.

test/jdk/javax/swing/JMenuItem/JMenuItemSetAcceleratorTest.java line 108:

> 106:             }
> 107:             System.out
> 108:                 .println("Test passed, received action event on menu item.");

Please, don't do it this way: it's better to wrap the `String` argument. We already [discussed it](https://github.com/openjdk/jdk/pull/11035#discussion_r1026888743).

If you want to strictly fit into 80-column limit, `"Test passed"` is enough for the message.

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

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


From aivanov at openjdk.org  Mon Dec 12 21:18:51 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Dec 2022 21:18:51 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus [v2]
In-Reply-To: <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
Message-ID: <TPRYLoGpgKeFcKOf_8K8dwzx4ljj2ux-aW2sqjYBv9Y=.b3376f94-686f-472c-8b15-b73a871d2ac2@github.com>

On Fri, 2 Dec 2022 23:52:55 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Set the text caret to be visible but not blinking on the non-editable text area.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handling the case when blink rate is set while component is unedited
>   Test HidingSelectionTest.java is rewritten and corrected.

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.org  Mon Dec 12 21:18:51 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Dec 2022 21:18:51 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus
In-Reply-To: <zlaK88xn6qUJ9vQlQlUQubxVkF6kqjoi5JOQ-f-h-QY=.f3dd2f94-94fc-47bd-950e-0cdc7b5968c5@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <e7ITSsOpcKtlC2bJNzIM3PFCUcoRZdfRi0mr1JxsgFE=.f37d4fe5-6a07-427c-b87f-b0ba50efcc6c@github.com>
 <VUwbo01Ivv81AevheTugl-_xosvdnzR7jhFhJtdViaE=.493aee6b-d32a-4258-8271-b25a281273d8@github.com>
 <xJz52QqQG3jjK_eODsEXefcjWz7dfCLa29VepSCwYtE=.1757660e-6211-4917-9a41-e9d5908ccecc@github.com>
 <sl_FDZPPaLyWqv74FBu0aJwzSvRgIwrT_Lj8TF3AtpU=.1dddf19e-c2b6-48ba-b477-dc685bbc1efb@github.com>
 <Pfc1L8tORSVPgNs51CRj0MkEF0EtbOIt7-gnmpswjDA=.1b49bc05-0a92-4c54-805d-54815983e2be@github.com>
 <2XePfo1gtNAWJvM5ECfg8Vkp8VObLOyQmM8WkQDiabM=.43f5d635-9352-4cc8-b9d9-e76aa710064d@github.com>
 <bwZOldi_Ad40uVp3MIJTAqSJCztBfjVxsF8z661AN94=.5168abd0-a31d-4ae1-ad30-7ec2b620ad6e@github.com>
 <oCIy6x1tlZsFtQqokU5PVFFZcs0jOxccr8dYkyJ7uXE=.4d9fc026-99f2-4cfb-9cec-4facbed01226@github.com>
 <zlaK88xn6qUJ9vQlQlUQubxVkF6kqjoi5JOQ-f-h-QY=.f3dd2f94-94fc-47bd-950e-0cdc7b5968c5@github.com>
Message-ID: <HAikifqAMJhjHyPEEk3KvXPIKsx9xXfJJ_h1ErJvCC8=.fbe39438-46af-4e13-b848-b6e74e1c6f8e@github.com>

On Thu, 8 Dec 2022 08:27:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > > If that is not possible I suggest providing that functionality so applications will be able to use that. Probably even provide some predefined cursors, like "faded"/"blurred"/nonblinked/etc. That could be configured per L&F as well.
> >
> > That would be a nice feature to have but right now we have an issue where default behaviour of the component defies the VPAT guidelines.
> 
> I am not sure that changing the default behavior of all text components(including embedded to other components) to use a non-blinking cursor is a good idea, you can convince me if you find someone who uses the same approach, any applications? Probably at least for the native look&feels we can use the same behavior as the native default components win32/cocoa/gtk.

I believe this has been discussed here:

* **Win32** displays a regular blinking caret for non-editable text controls;
* **macOS** (Cocoa) display no caret for non-editable text controls;
* **Ubuntu** (GNOME 3, GTK) displays a non-blinking caret for non-editable text controls;

The above observations are based on the File Properties dialog in each OS.

So, the app developer should have control over the behaviour. Then Look-and-Feel implementation could have its own defaults which match the platforms if applicable.

At the same time, I don't this limitation as a showstopper. As [I said above](https://github.com/openjdk/jdk/pull/11408#issuecomment-1347190978), a visible caret facilitates selecting text using keyboard; from this point of view, this fix is a step forward.

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

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


From kizune at openjdk.org  Mon Dec 12 21:42:34 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 12 Dec 2022 21:42:34 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus [v2]
In-Reply-To: <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
Message-ID: <YPVwaFwI5q4Eqx02dbUPcnzLQLRRtcO-ZopgdDUm45Q=.cde01b21-7bea-43f5-8660-1429d94c5389@github.com>

On Fri, 2 Dec 2022 23:52:55 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Set the text caret to be visible but not blinking on the non-editable text area.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handling the case when blink rate is set while component is unedited
>   Test HidingSelectionTest.java is rewritten and corrected.

I created an enhancement request JDK-8298602 to start a discussion about the state-aware caret implementation so we can come to a more flexible solution in the future. With that in mind can we come to some conclusion on this exact accessibility issue? I still thing it is beneficial to have a way to distinguish between focused/non-focused and editable/non-editable text components and the caret seems to be potentially less destructive change. I do not see any major UI element that has the text component embedded that is affected in the negative way by this change.

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

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


From kizune at openjdk.org  Mon Dec 12 22:38:07 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 12 Dec 2022 22:38:07 GMT
Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication
 of keyboard focus [v2]
In-Reply-To: <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
 <oqSjmXbL5N9D_fm2jgXnGHkBo8OGIVieUvyGBi4jPDU=.ecd5aa78-c151-4273-9f2b-f6f683b75851@github.com>
Message-ID: <9678fmXf301-hT6a2WNbVHjrKcRbJATj2FPrPDipVXw=.31396791-6875-48a4-a7af-ececd2cd7018@github.com>

On Fri, 2 Dec 2022 23:52:55 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Set the text caret to be visible but not blinking on the non-editable text area.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handling the case when blink rate is set while component is unedited
>   Test HidingSelectionTest.java is rewritten and corrected.

Since jdk20 branched out and we are trying to fix it for jdk20 the new PR is here: https://github.com/openjdk/jdk20/pull/21

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

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


From kizune at openjdk.org  Mon Dec 12 22:41:02 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 12 Dec 2022 22:41:02 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus
Message-ID: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>

Set the text caret to be visible but not blinking on the non-editable text area. Fix the regression test that becames unstable after the change.

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

Commit messages:
 - 4512626: Non-editable JTextArea provides no visual indication of keyboard focus

Changes: https://git.openjdk.org/jdk20/pull/21/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=21&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-4512626
  Stats: 68 lines in 2 files changed: 24 ins; 34 del; 10 mod
  Patch: https://git.openjdk.org/jdk20/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/21/head:pull/21

PR: https://git.openjdk.org/jdk20/pull/21


From kizune at openjdk.org  Mon Dec 12 22:41:04 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 12 Dec 2022 22:41:04 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus
In-Reply-To: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
Message-ID: <b9hfGQ8O2lvkxeKG6Ly3N0NfRhCFTXYDzWhtmAE5sZ0=.5c7ededd-9dc1-45fe-91c4-38eed5399846@github.com>

On Mon, 12 Dec 2022 22:33:51 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Set the text caret to be visible but not blinking on the non-editable text area. Fix the regression test that becames unstable after the change.

Continuation of https://github.com/openjdk/jdk/pull/11408 to be integrated into JDK20 workspace.

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

PR: https://git.openjdk.org/jdk20/pull/21


From honkar at openjdk.org  Mon Dec 12 22:43:08 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 12 Dec 2022 22:43:08 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v2]
In-Reply-To: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
Message-ID: <biffK-rMXKafRrrKPgT4rKrc_ZK_6EEbgw5NnO721P0=.db5323cc-6228-4cdc-80a0-b464d436b8e2@github.com>

> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as parameter to method.  
> 
> Following are the usual steps for any border scaling -
> 
> - Resetting transform.
> - Calculating new width, height, x & y-translations.
> - Perform the required border rendering.
> - And at the end restore the previous transform.
> 
> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
> 
> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
> 
> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.

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/11571/files
  - new: https://git.openjdk.org/jdk/pull/11571/files/19665a61..103ca437

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

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

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


From prr at openjdk.org  Mon Dec 12 23:26:37 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 12 Dec 2022 23:26:37 GMT
Subject: RFR: 8297191: [macos] printing page range "page 2 to 2" or
 "page 2 to 4" on macOS leads to not print
In-Reply-To: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
Message-ID: <M1bTI2j_Uf9zBk-RpTBuNe390HiRv7IFPA3Tzr_Eueg=.2bf1f65a-bb54-4fa8-ba14-531a470c6238@github.com>

On Mon, 21 Nov 2022 14:32:50 GMT, Christian Heilmann <duke at openjdk.org> wrote:

> 8297191: [macos] printing page range "page 2 to 2" or "page 2 to 4" on macOS leads to not print

So .. this looks and sounds reasonable except that I can't reproduce it.
I see the "0" there at least as far back as JDK 8 (so I guess forever), but I can't reproduce with any of JDK 8, 17 or 19.
I just ran you Test.java and selected page ranges 2-4 and I got the expected lines 20-39, 40-59, 60-79 on 3 pages.

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

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


From prr at openjdk.org  Mon Dec 12 23:48:14 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 12 Dec 2022 23:48:14 GMT
Subject: RFR: 8297191: [macos] printing page range "page 2 to 2" or
 "page 2 to 4" on macOS leads to not print
In-Reply-To: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
Message-ID: <GSgo-aSjC6sHPm8hLIfjh7KgId5cy2aldMoFWIeeuto=.480e663f-9598-46e2-99c0-3b3a73bfd03b@github.com>

On Mon, 21 Nov 2022 14:32:50 GMT, Christian Heilmann <duke at openjdk.org> wrote:

> 8297191: [macos] printing page range "page 2 to 2" or "page 2 to 4" on macOS leads to not print

This PR (and bug) could use a better title. I suggest : 
"[macos] pages are missing when printing using page ranges"

Of course it doesn't matter until we understand why it isn't reproducible.

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

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


From dnguyen at openjdk.org  Tue Dec 13 02:18:54 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 13 Dec 2022 02:18:54 GMT
Subject: RFR: 8202931: [macos]
 java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java fails [v3]
In-Reply-To: <rTgkJ5GkjUUzcgAe7qGP7-vzijWpXpClg7jX06Z4WdE=.d7b1c7ad-e509-4ff2-a9ac-ca2d52b13dd2@github.com>
References: <lMoM5UnFcd2T8yHEY5lN7WFY2cSQL_18I6maJD6xxnw=.776f2663-c6a7-43ee-ab8c-c2210d95cee0@github.com>
 <rTgkJ5GkjUUzcgAe7qGP7-vzijWpXpClg7jX06Z4WdE=.d7b1c7ad-e509-4ff2-a9ac-ca2d52b13dd2@github.com>
Message-ID: <paOpsSqh4QFbKQBzo5gCMMSR17Yzx763Vmtl-8gQhbk=.954a938b-af0b-41ff-b0d4-8d816a9b0931@github.com>

On Wed, 30 Nov 2022 17:53:08 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Test ran on all OS 100 times and passed. Test previously failed on macOS but no longer reproducible. Added screen capture on moment of failure to have more evidence of failures in the future (previously a runtime exception was thrown only).
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra line

Could I get an additional review? Maybe @alisenchung or @honkar-jdk ?

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

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


From psadhukhan at openjdk.org  Tue Dec 13 02:36:48 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 13 Dec 2022 02:36:48 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus
In-Reply-To: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
Message-ID: <-HhHQfNxcv4FE-h0n9X71n7R1-zRmQeEOC5D6obxaiE=.02362c0a-d84a-4576-b555-3e9c1be9fe02@github.com>

On Mon, 12 Dec 2022 22:33:51 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Set the text caret to be visible but not blinking on the non-editable text area. Fix the regression test that becames unstable after the change.

test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java line 120:

> 118:         robot.waitForIdle();
> 119:         robot.delay(200);
> 120:         if (!field2.getCaret().isSelectionVisible()) {

Does it need similar change in test/jdk/javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java
as well?
Since the logic is changed, I will still request to make this test stable on windows (now that we are not using screen capture) and then deproblemlist

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

PR: https://git.openjdk.org/jdk20/pull/21


From psadhukhan at openjdk.org  Tue Dec 13 02:39:08 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 13 Dec 2022 02:39:08 GMT
Subject: RFR: 8298618: Typo in JPEGImageReader and JPEGImageWriter
Message-ID: <XRbOs-MiogUbj4HoxFs18HdzwnwSsrEGFr1WRJCvhjQ=.33677315-40a2-4e7c-b3e7-40cd59c56302@github.com>

Fixed Typo "form" should be "from"

-------------

Commit messages:
 - Typo fix

Changes: https://git.openjdk.org/jdk/pull/11640/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11640&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298618
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11640.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11640/head:pull/11640

PR: https://git.openjdk.org/jdk/pull/11640


From iris at openjdk.org  Tue Dec 13 02:47:08 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 13 Dec 2022 02:47:08 GMT
Subject: RFR: 8298618: Typo in JPEGImageReader and JPEGImageWriter
In-Reply-To: <XRbOs-MiogUbj4HoxFs18HdzwnwSsrEGFr1WRJCvhjQ=.33677315-40a2-4e7c-b3e7-40cd59c56302@github.com>
References: <XRbOs-MiogUbj4HoxFs18HdzwnwSsrEGFr1WRJCvhjQ=.33677315-40a2-4e7c-b3e7-40cd59c56302@github.com>
Message-ID: <rnjnMxAbfLqTYeumBta5GBIYBMi3_Atu2oF6UHa88DI=.d3ea5a33-ec0a-41ab-93fa-cc3dfb20abe7@github.com>

On Tue, 13 Dec 2022 02:31:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fixed Typo "form" should be "from"

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11640


From serb at openjdk.org  Tue Dec 13 03:06:40 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 Dec 2022 03:06:40 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v6]
In-Reply-To: <GOnjn1otJM6CR6UhLCDU2HBQQ4udTis_wUvVQnDppe8=.bcee3e6d-6471-4efa-9f73-e8b687e07425@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
 <GOnjn1otJM6CR6UhLCDU2HBQQ4udTis_wUvVQnDppe8=.bcee3e6d-6471-4efa-9f73-e8b687e07425@github.com>
Message-ID: <ap5quuu_UOj9AbugC9SpCqgi3B2eoUiUmDrVYBQhyPA=.761e4384-a72d-4d81-a7c8-04e02a571c87@github.com>

On Mon, 12 Dec 2022 03:37:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>>     javax.swing.text.html.parser.ParserDelegator
>>     javax.swing.LayoutComparator
>> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
>> 
>> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
>> Added the warning..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove space

src/java.desktop/share/classes/javax/swing/text/html/parser/ParserDelegator.java line 50:

> 48:  * appropriate for short term storage or RMI between applications running
> 49:  * the same version of Swing.  As of 1.4, support for long term storage
> 50:  * of all JavaBeans has been added to the <code>java.beans</code> package

Just found that this line, unlike others, does not have a point at the end.

-------------

PR: https://git.openjdk.org/jdk/pull/11565


From psadhukhan at openjdk.org  Tue Dec 13 03:32:28 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 13 Dec 2022 03:32:28 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v7]
In-Reply-To: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
Message-ID: <G5TnquzWCKm_0X-RJbnzozH6hSATZO1neKkCm7wUfDM=.ed12384a-2ede-4e27-86a4-953438cd1638@github.com>

> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>     javax.swing.text.html.parser.ParserDelegator
>     javax.swing.LayoutComparator
> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
> 
> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
> Added the warning..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Add missing .

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11565/files
  - new: https://git.openjdk.org/jdk/pull/11565/files/0147ee48..6ac67d2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11565&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11565&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11565.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11565/head:pull/11565

PR: https://git.openjdk.org/jdk/pull/11565


From jdv at openjdk.org  Tue Dec 13 04:55:03 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 13 Dec 2022 04:55:03 GMT
Subject: RFR: 8298618: Typo in JPEGImageReader and JPEGImageWriter
In-Reply-To: <XRbOs-MiogUbj4HoxFs18HdzwnwSsrEGFr1WRJCvhjQ=.33677315-40a2-4e7c-b3e7-40cd59c56302@github.com>
References: <XRbOs-MiogUbj4HoxFs18HdzwnwSsrEGFr1WRJCvhjQ=.33677315-40a2-4e7c-b3e7-40cd59c56302@github.com>
Message-ID: <IL1jKcmAp1DFYj7bdljVWyYrh5ojjWcaMMYJ4eJNdAA=.51446cc8-2a51-49a0-82ac-8d12d0980726@github.com>

On Tue, 13 Dec 2022 02:31:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fixed Typo "form" should be "from"

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11640


From abhiscxk at openjdk.org  Tue Dec 13 05:19:03 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 13 Dec 2022 05:19:03 GMT
Subject: RFR: 8298618: Typo in JPEGImageReader and JPEGImageWriter
In-Reply-To: <XRbOs-MiogUbj4HoxFs18HdzwnwSsrEGFr1WRJCvhjQ=.33677315-40a2-4e7c-b3e7-40cd59c56302@github.com>
References: <XRbOs-MiogUbj4HoxFs18HdzwnwSsrEGFr1WRJCvhjQ=.33677315-40a2-4e7c-b3e7-40cd59c56302@github.com>
Message-ID: <Dau8MjudIZAAQ08GA8rsHR-TWWN7Rt_wZmR7OsCp5O4=.be9fad5b-5143-464b-afb0-6945adfa817a@github.com>

On Tue, 13 Dec 2022 02:31:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fixed Typo "form" should be "from"

Marked as reviewed by abhiscxk (Author).

-------------

PR: https://git.openjdk.org/jdk/pull/11640


From kizune at openjdk.org  Tue Dec 13 06:13:00 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 13 Dec 2022 06:13:00 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus
In-Reply-To: <-HhHQfNxcv4FE-h0n9X71n7R1-zRmQeEOC5D6obxaiE=.02362c0a-d84a-4576-b555-3e9c1be9fe02@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <-HhHQfNxcv4FE-h0n9X71n7R1-zRmQeEOC5D6obxaiE=.02362c0a-d84a-4576-b555-3e9c1be9fe02@github.com>
Message-ID: <yC-Fov5npCizRMQoj_j9KRbxKJe10dj4zWPxzrHJOsU=.64367fa6-7687-4ebf-bab2-a4c8872ef968@github.com>

On Tue, 13 Dec 2022 02:34:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Does it need similar change in test/jdk/javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java as well? Since the logic is changed, I will still request to make this test stable on windows (now that we are not using screen capture) and then deproblemlist

I haven't tested the MultiSelectionTest but since it is problemlisted on Linux similar change might make it more stable. As of this test - since you are the owner of JDK-8194048 i thought that you can review my changes and deproblemlist the test if it is stable on the rest of the platforms and if changes make sense. I definitely do not want to steal your thunder. As of MultiSelectionTest i can take care of it either here or in the original bug that is noted in ProblemList.txt since my fix does not affect it.

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From psadhukhan at openjdk.org  Tue Dec 13 08:31:51 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 13 Dec 2022 08:31:51 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus
In-Reply-To: <yC-Fov5npCizRMQoj_j9KRbxKJe10dj4zWPxzrHJOsU=.64367fa6-7687-4ebf-bab2-a4c8872ef968@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <-HhHQfNxcv4FE-h0n9X71n7R1-zRmQeEOC5D6obxaiE=.02362c0a-d84a-4576-b555-3e9c1be9fe02@github.com>
 <yC-Fov5npCizRMQoj_j9KRbxKJe10dj4zWPxzrHJOsU=.64367fa6-7687-4ebf-bab2-a4c8872ef968@github.com>
Message-ID: <X_sesedc1cr1kETxwY_v69GbE05lCcfGQqEbqq_pEPM=.eea15861-d89d-4c41-bc1d-541e009ce668@github.com>

On Tue, 13 Dec 2022 06:10:34 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java line 120:
>> 
>>> 118:         robot.waitForIdle();
>>> 119:         robot.delay(200);
>>> 120:         if (!field2.getCaret().isSelectionVisible()) {
>> 
>> Does it need similar change in test/jdk/javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java
>> as well?
>> Since the logic is changed, I will still request to make this test stable on windows (now that we are not using screen capture) and then deproblemlist
>
>> Does it need similar change in test/jdk/javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java as well? Since the logic is changed, I will still request to make this test stable on windows (now that we are not using screen capture) and then deproblemlist
> 
> I haven't tested the MultiSelectionTest but since it is problemlisted on Linux similar change might make it more stable. As of this test - since you are the owner of JDK-8194048 i thought that you can review my changes and deproblemlist the test if it is stable on the rest of the platforms and if changes make sense. I definitely do not want to steal your thunder. As of MultiSelectionTest i can take care of it either here or in the original bug that is noted in ProblemList.txt since my fix does not affect it.

I guess anyway one is supposed to do a CI job for the fix and test the regression test on all platforms, so if the modified test is problemlisted it will not be tested in CI job, so it's better to deproblemlist and test...
You can do /issue add of that problemlisted bug (it just happens to be in my name for the time being, nothing stopping you assigning to you since you did all the hard work)

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From serb at openjdk.org  Tue Dec 13 09:10:21 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 Dec 2022 09:10:21 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v7]
In-Reply-To: <G5TnquzWCKm_0X-RJbnzozH6hSATZO1neKkCm7wUfDM=.ed12384a-2ede-4e27-86a4-953438cd1638@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
 <G5TnquzWCKm_0X-RJbnzozH6hSATZO1neKkCm7wUfDM=.ed12384a-2ede-4e27-86a4-953438cd1638@github.com>
Message-ID: <zuTjh2G5kz6APLOWuohIMIxrnAbH3T7cDJGiAhPNQ5U=.5cb1cf5e-2382-4a59-bd1d-7b874559e897@github.com>

On Tue, 13 Dec 2022 03:32:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>>     javax.swing.text.html.parser.ParserDelegator
>>     javax.swing.LayoutComparator
>> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
>> 
>> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
>> Added the warning..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing .

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11565


From psadhukhan at openjdk.org  Tue Dec 13 09:58:21 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 13 Dec 2022 09:58:21 GMT
Subject: RFR: 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame
 throws a NPE. [v2]
In-Reply-To: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
References: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
Message-ID: <Q9YBI2qMJriQg-J6Zx_jTgf5i0Fsz39qTNqgmvoQcJE=.2c8ade07-301e-43d4-b515-34d9cc8d5344@github.com>

> In Swingset2 JInternalFrame demo, focusing on any internalframes and pressing Ctrl+F7 and then any of up/down/left/arrow key to move the internal frames results in NPE in NimbusL&F.
> It is because `JComponent.processKeyBinding() `calls `SwingUtilities.notifyAction` which calls `BasicDesktopPaneUI.actionPerformed` where it gets `Desktop.minOnScreenInsets` property to get the Insets and then uses insets.top/bottom/left/right value to move the internalframe but this property is not defined for Nimbus so deferencing Insets object results in NPE.
> 
> Fix is added to create a 0 insets incase some L&F do not define` Desktop.minOnScreenInsets` property.
> No regression test is added as it can be easily checked by SwingSet2 JInternalFrame demo.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Add test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11605/files
  - new: https://git.openjdk.org/jdk/pull/11605/files/051b325c..a4927f57

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11605&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11605&range=00-01

  Stats: 133 lines in 1 file changed: 133 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11605.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11605/head:pull/11605

PR: https://git.openjdk.org/jdk/pull/11605


From psadhukhan at openjdk.org  Tue Dec 13 10:05:09 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 13 Dec 2022 10:05:09 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install an
 entry for MetalMenuBarUI
Message-ID: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>

Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
says:
"...MetalLookAndFeel registers an entry for each of the classes
in the package javax.swing.plaf.metal that are named MetalXXXUI.
The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
that do not have a class in metal, the corresponding class in
javax.swing.plaf.basic is used. For example, metal does not
have a class named "MetalColorChooserUI", as such,
javax.swing.plaf.basic.BasicColorChooserUI is used".

There is class MetalMenuBarUI, but the method populates given defaults table with the value
"javax.swing.plaf.basic.BasicMenuBarUI".

Added entry for MetalMenuBarUI..
CI tests including JCK tests are ok.

-------------

Commit messages:
 - 6513512: MetalLookAndFeel.initClassDefaults does not install an entry for MetalMenuBarUI

Changes: https://git.openjdk.org/jdk/pull/11646/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11646&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6513512
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11646.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11646/head:pull/11646

PR: https://git.openjdk.org/jdk/pull/11646


From psadhukhan at openjdk.org  Tue Dec 13 10:25:45 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 13 Dec 2022 10:25:45 GMT
Subject: Integrated: 8298618: Typo in JPEGImageReader and JPEGImageWriter
In-Reply-To: <XRbOs-MiogUbj4HoxFs18HdzwnwSsrEGFr1WRJCvhjQ=.33677315-40a2-4e7c-b3e7-40cd59c56302@github.com>
References: <XRbOs-MiogUbj4HoxFs18HdzwnwSsrEGFr1WRJCvhjQ=.33677315-40a2-4e7c-b3e7-40cd59c56302@github.com>
Message-ID: <idJJ47XLSm5kvlAoA0t-MRS7s35r2KQYZAw_VIfJcKY=.33f53848-1463-463b-bbc8-576933278fc8@github.com>

On Tue, 13 Dec 2022 02:31:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fixed Typo "form" should be "from"

This pull request has now been integrated.

Changeset: 3b1142a2
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b1142a280d66b2f5f7b4afbc76e940fdc30b463
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8298618: Typo in JPEGImageReader and JPEGImageWriter

Reviewed-by: iris, jdv, abhiscxk

-------------

PR: https://git.openjdk.org/jdk/pull/11640


From aivanov at openjdk.org  Tue Dec 13 12:56:06 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 Dec 2022 12:56:06 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus
In-Reply-To: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
Message-ID: <vxVF6cCwFSs8LKdl10LoEL8vOlS0rXFDf5OmTQOHxKs=.7e5a1c9c-1f24-4e82-9b5e-be7c5ea223d7@github.com>

On Mon, 12 Dec 2022 22:33:51 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Set the text caret to be visible but not blinking on the non-editable text area. Fix the regression test that becames unstable after the change.

It would be better to verify the updated test passes on Windows. If so, remove it from the problem list.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/21


From asemenov at openjdk.org  Tue Dec 13 13:37:50 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 13 Dec 2022 13:37:50 GMT
Subject: RFR: 8298643 JNI call of getAccessibleRowWithIndex and
 getAccessibleColumnWithIndex on a wrong thread
Message-ID: <Jjl2XjvF1YJgjDuDAAOrnHWvxVDYprv6ntpqguD0yHc=.3bb98d77-4d42-4cbc-95fe-2febd5e95d2e@github.com>

[TableAccessibility accessibleRowWithIndex] and [TableAccessibility accessibleColumnWithIndex] defines the getAccessibleRowWithIndex and getAccessibleColumnWithIndex methods on the AccessibleContext instance of AccessibleJTable class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

-------------

Commit messages:
 - 8298643 JNI call of getAccessibleRowWithIndex and getAccessibleColumnWithIndex on a wrong thread ?

Changes: https://git.openjdk.org/jdk/pull/11649/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11649&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298643
  Stats: 18 lines in 1 file changed: 0 ins; 8 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/11649.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11649/head:pull/11649

PR: https://git.openjdk.org/jdk/pull/11649


From tr at openjdk.org  Tue Dec 13 13:45:13 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 13 Dec 2022 13:45:13 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
Message-ID: <BIp7a1oU3ONbVVR804kdbra9dUK1wtdXY-m7IZGiyBk=.49242328-1fe7-45e4-bfaf-75d858c01541@github.com>

On Fri, 11 Nov 2022 08:18:19 GMT, Tejesh R <tr at openjdk.org> wrote:

> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.

> 

Means checking for null when trying to insert null into MRI map?

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From psadhukhan at openjdk.org  Tue Dec 13 14:52:57 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 13 Dec 2022 14:52:57 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native
In-Reply-To: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
Message-ID: <g3qg0VmXk5kXgEl24cJv6-DTu4_qy7dGxosMZRhXPWM=.88775a70-317c-4e0f-8f60-2931d09fe2a7@github.com>

On Mon, 12 Dec 2022 05:56:38 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> It is not possible to select all files on press of Ctrl+A in JFileChooser for GTK LAF where as all folders can be selected. 
> In native side on press of Ctrl+A, able to select all files as well as folders.
> 
> Proposed fix is to enable `multiselection `property by default for JFileChooser in GTK LAF to mimic native side behavior.
> 
> An automated test case is implemented and tested in CI. CI job links are attached in JBS.

Marked as reviewed by psadhukhan (Reviewer).

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserCtrlASelection.java line 66:

> 64:             // Create a test directory that contains only folders
> 65:             testDir = new File(tmpDir, "testDir");
> 66:             if (!testDir.exists())

There should be braces here even for a single line as per coding convention...Also one more case down below..
please update before pushing..

-------------

PR: https://git.openjdk.org/jdk/pull/11627


From asemenov at openjdk.org  Tue Dec 13 16:07:31 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 13 Dec 2022 16:07:31 GMT
Subject: RFR: 8298645 JNI works with accessibleSelection on a wrong thread
Message-ID: <w3UAuIF1k3EhbKSCxEXQ_5g5S9mOaepbIf_x_PDpt9g=.694f5c75-8384-433c-9b65-75910f61be37@github.com>

[ComboBoxAccessibility accessibilityValue] works with the accessibleSelection object directly, however the work should go through CAccessibility so that it is executed on the Event Dispatch thread.

-------------

Commit messages:
 - 8298645 JNI works with accessibleSelection on a wrong thread

Changes: https://git.openjdk.org/jdk/pull/11653/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11653&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298645
  Stats: 53 lines in 2 files changed: 20 ins; 20 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/11653.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11653/head:pull/11653

PR: https://git.openjdk.org/jdk/pull/11653


From psadhukhan at openjdk.org  Tue Dec 13 16:24:55 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 13 Dec 2022 16:24:55 GMT
Subject: RFR: 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java
 fails with "No MouseReleased event on label!" [v3]
In-Reply-To: <wk0pRR6VBbTKg7aen8zWLYa9KWMEitnkmSkAuoctO9s=.b7ffd66d-a3b3-4fe5-8785-6eb4ab009d84@github.com>
References: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
 <wk0pRR6VBbTKg7aen8zWLYa9KWMEitnkmSkAuoctO9s=.b7ffd66d-a3b3-4fe5-8785-6eb4ab009d84@github.com>
Message-ID: <7XxzaToxcUQRf9FYB7oyuR0LDDWnN1-lcARsMenJr7g=.b55aed11-0ab2-4422-ab6a-c7eee4a52c52@github.com>

On Mon, 5 Dec 2022 19:52:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Test was run on mac, windows, linux 50 times and passed after change
>> Before fix, test fails about once every 50 runs on linux and windows platforms
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8297296
>  - fixed imports, changed robot autodelay and added delay after creating gui
>  - changed robot autodelay to 250

I guess it's better to use setLocationRelativeTo() to position the frame to middle of screen too to make it more stable..

-------------

Marked as reviewed by psadhukhan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11425


From duke at openjdk.org  Tue Dec 13 16:41:42 2022
From: duke at openjdk.org (Naveen Narayanan)
Date: Tue, 13 Dec 2022 16:41:42 GMT
Subject: RFR: 8296275: Write a test to verify setAccelerator method of
 JMenuItem [v9]
In-Reply-To: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
Message-ID: <ZtlhyvUh0vlB6Ykavy8msXpRKsSdEUwA43Y_Z7D2Nm8=.79608f12-4ea9-4e79-9d69-3ff74d7406a0@github.com>

> This testcase will
> 1) Verify setAccelerator method of JMenuitem.
> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M.
> 
> Testing:
> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass.

Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision:

  8296275: Review comments fixed.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11035/files
  - new: https://git.openjdk.org/jdk/pull/11035/files/12cc8e4e..fe62a7e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11035&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11035&range=07-08

  Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11035.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11035/head:pull/11035

PR: https://git.openjdk.org/jdk/pull/11035


From duke at openjdk.org  Tue Dec 13 16:41:44 2022
From: duke at openjdk.org (Naveen Narayanan)
Date: Tue, 13 Dec 2022 16:41:44 GMT
Subject: RFR: 8296275: Write a test to verify setAccelerator method of
 JMenuItem [v8]
In-Reply-To: <I4vq-CSA3tFBc78r7E_QYZIL3fcIkMJP_yHRb__x_Pc=.ad504699-fe7a-47ea-bfbb-33c240af46df@github.com>
References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
 <8NYHld9tBOAyBPZk00A_73beOW6lj8a_w-9lJSthLJ8=.473b501e-38f6-4306-a11e-2970dbb87ac4@github.com>
 <I4vq-CSA3tFBc78r7E_QYZIL3fcIkMJP_yHRb__x_Pc=.ad504699-fe7a-47ea-bfbb-33c240af46df@github.com>
Message-ID: <CHew1WjITsM4j1bKs053gJmPmZVM1W7SRmpYmoc6GYU=.0262ff9a-2fa7-4576-a9e9-f5c74b9ed98a@github.com>

On Mon, 12 Dec 2022 20:54:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8296275: Removing trailing whitespaces.
>
> test/jdk/javax/swing/JMenuItem/JMenuItemSetAcceleratorTest.java line 61:
> 
>> 59:         JMenuBar bar = new JMenuBar();
>> 60:         JMenu menu = new JMenu("File Menu");
>> 61:         JMenuItem menuItem = new JMenuItem("File Menu Item");
> 
> _File_ is much more standard than _File Menu_ unless you have a specific reason for a longer menu item.

Changed to File

-------------

PR: https://git.openjdk.org/jdk/pull/11035


From duke at openjdk.org  Tue Dec 13 16:43:47 2022
From: duke at openjdk.org (Naveen Narayanan)
Date: Tue, 13 Dec 2022 16:43:47 GMT
Subject: RFR: 8296275: Write a test to verify setAccelerator method of
 JMenuItem [v8]
In-Reply-To: <I4vq-CSA3tFBc78r7E_QYZIL3fcIkMJP_yHRb__x_Pc=.ad504699-fe7a-47ea-bfbb-33c240af46df@github.com>
References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
 <8NYHld9tBOAyBPZk00A_73beOW6lj8a_w-9lJSthLJ8=.473b501e-38f6-4306-a11e-2970dbb87ac4@github.com>
 <I4vq-CSA3tFBc78r7E_QYZIL3fcIkMJP_yHRb__x_Pc=.ad504699-fe7a-47ea-bfbb-33c240af46df@github.com>
Message-ID: <fcilsQC4ZtbQsh_mp_2Z18MzYLxtKOE80XM3QIZI8tQ=.b78ad19c-7934-490c-8ef4-82aac002a6ce@github.com>

On Mon, 12 Dec 2022 20:57:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8296275: Removing trailing whitespaces.
>
> test/jdk/javax/swing/JMenuItem/JMenuItemSetAcceleratorTest.java line 108:
> 
>> 106:             }
>> 107:             System.out
>> 108:                 .println("Test passed, received action event on menu item.");
> 
> Please, don't do it this way: it's better to wrap the `String` argument. We already [discussed it](https://github.com/openjdk/jdk/pull/11035#discussion_r1026888743).
> 
> If you want to strictly fit into 80-column limit, `"Test passed"` is enough for the message.

My IDE?s formatter auto wraps this line for 80 chars.
After every code change & formatting, I have to manually unwrap these lines.
There are 3 lines to  unwrap manually.

-------------

PR: https://git.openjdk.org/jdk/pull/11035


From serb at openjdk.org  Tue Dec 13 18:29:14 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 Dec 2022 18:29:14 GMT
Subject: RFR: 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame
 throws a NPE. [v2]
In-Reply-To: <Q9YBI2qMJriQg-J6Zx_jTgf5i0Fsz39qTNqgmvoQcJE=.2c8ade07-301e-43d4-b515-34d9cc8d5344@github.com>
References: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
 <Q9YBI2qMJriQg-J6Zx_jTgf5i0Fsz39qTNqgmvoQcJE=.2c8ade07-301e-43d4-b515-34d9cc8d5344@github.com>
Message-ID: <5nCnUdSWHgF8hhSx0yONZinvcqW4aRuKy_g-qF3hsgY=.e0e73a0c-f446-4e45-848a-b5541dd2367e@github.com>

On Tue, 13 Dec 2022 09:58:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In Swingset2 JInternalFrame demo, focusing on any internalframes and pressing Ctrl+F7 and then any of up/down/left/arrow key to move the internal frames results in NPE in NimbusL&F.
>> It is because `JComponent.processKeyBinding() `calls `SwingUtilities.notifyAction` which calls `BasicDesktopPaneUI.actionPerformed` where it gets `Desktop.minOnScreenInsets` property to get the Insets and then uses insets.top/bottom/left/right value to move the internalframe but this property is not defined for Nimbus so deferencing Insets object results in NPE.
>> 
>> Fix is added to create a 0 insets incase some L&F do not define` Desktop.minOnScreenInsets` property.
>> No regression test is added as it can be easily checked by SwingSet2 JInternalFrame demo.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Looks like there are many "Whitespace error" reported by jcheck in the test.

-------------

PR: https://git.openjdk.org/jdk/pull/11605


From serb at openjdk.org  Tue Dec 13 18:39:59 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 Dec 2022 18:39:59 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI
In-Reply-To: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
Message-ID: <qfN0MN7FhypwDnihm9LZFMAQasFxzsMAI9BTi32Vd2Y=.8469de92-225b-4b80-8846-0606a736dea5@github.com>

On Tue, 13 Dec 2022 09:56:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
> says:
> "...MetalLookAndFeel registers an entry for each of the classes
> in the package javax.swing.plaf.metal that are named MetalXXXUI.
> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
> that do not have a class in metal, the corresponding class in
> javax.swing.plaf.basic is used. For example, metal does not
> have a class named "MetalColorChooserUI", as such,
> javax.swing.plaf.basic.BasicColorChooserUI is used".
> 
> There is class MetalMenuBarUI, but the method populates given defaults table with the value
> "javax.swing.plaf.basic.BasicMenuBarUI".
> 
> Added entry for MetalMenuBarUI..
> CI tests including JCK tests are ok.

Probably we should follow this suggestion from the JBS:
> This class is only appropriate for Ocean. The spec needs to be updated to mention this.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java line 276:

> 274:                     "LabelUI", metalPackageName + "MetalLabelUI",
> 275:                   "MenuBarUI", metalPackageName + "MetalMenuBarUI",
> 276:        "PopupMenuSeparatorUI", metalPackageName + "MetalPopupMenuSeparatorUI",

I think it is installed by the Ocean theme, which is used by the Metal L&F by default.

-------------

PR: https://git.openjdk.org/jdk/pull/11646


From serb at openjdk.org  Tue Dec 13 18:41:13 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 Dec 2022 18:41:13 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native
In-Reply-To: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
Message-ID: <fY06lcX86VG3jPRLEwju0wVsWyDhB6UmyYgwIioQyhw=.f620909f-7bb0-4d09-a0ab-83360d96c6ae@github.com>

On Mon, 12 Dec 2022 05:56:38 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> It is not possible to select all files on press of Ctrl+A in JFileChooser for GTK LAF where as all folders can be selected. 
> In native side on press of Ctrl+A, able to select all files as well as folders.
> 
> Proposed fix is to enable `multiselection `property by default for JFileChooser in GTK LAF to mimic native side behavior.
> 
> An automated test case is implemented and tested in CI. CI job links are attached in JBS.

src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java line 567:

> 565:         fc.setLayout(new BorderLayout());
> 566:         fc.setAlignmentX(JComponent.CENTER_ALIGNMENT);
> 567:         fc.setMultiSelectionEnabled(true);

Please double check that this will not override what the user set

-------------

PR: https://git.openjdk.org/jdk/pull/11627


From honkar at openjdk.org  Tue Dec 13 19:10:11 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 13 Dec 2022 19:10:11 GMT
Subject: RFR: 8202931: [macos]
 java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java fails [v3]
In-Reply-To: <rTgkJ5GkjUUzcgAe7qGP7-vzijWpXpClg7jX06Z4WdE=.d7b1c7ad-e509-4ff2-a9ac-ca2d52b13dd2@github.com>
References: <lMoM5UnFcd2T8yHEY5lN7WFY2cSQL_18I6maJD6xxnw=.776f2663-c6a7-43ee-ab8c-c2210d95cee0@github.com>
 <rTgkJ5GkjUUzcgAe7qGP7-vzijWpXpClg7jX06Z4WdE=.d7b1c7ad-e509-4ff2-a9ac-ca2d52b13dd2@github.com>
Message-ID: <1Yr4hOUnb3Xh2aWjUEriD-H-Bilbjs96lDmLPjye75o=.6f52bc31-7cc1-4d0a-8091-3aa66d97e30b@github.com>

On Wed, 30 Nov 2022 17:53:08 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Test ran on all OS 100 times and passed. Test previously failed on macOS but no longer reproducible. Added screen capture on moment of failure to have more evidence of failures in the future (previously a runtime exception was thrown only).
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra line

Test changes look good. I believe it is tested on multi-screen setup scenario too?

-------------

Marked as reviewed by honkar (Committer).

PR: https://git.openjdk.org/jdk/pull/11277


From duke at openjdk.org  Tue Dec 13 19:29:07 2022
From: duke at openjdk.org (SWinxy)
Date: Tue, 13 Dec 2022 19:29:07 GMT
Subject: RFR: 8298645 JNI works with accessibleSelection on a wrong thread
In-Reply-To: <w3UAuIF1k3EhbKSCxEXQ_5g5S9mOaepbIf_x_PDpt9g=.694f5c75-8384-433c-9b65-75910f61be37@github.com>
References: <w3UAuIF1k3EhbKSCxEXQ_5g5S9mOaepbIf_x_PDpt9g=.694f5c75-8384-433c-9b65-75910f61be37@github.com>
Message-ID: <Rb9yXGwv0_zuh0bE8TWnxsaAkB5_HOUNmtSbgbdEhcU=.e5378483-434e-4da9-a15b-0545e43c83e8@github.com>

On Tue, 13 Dec 2022 15:59:53 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> [ComboBoxAccessibility accessibilityValue] works with the accessibleSelection object directly, however the work should go through CAccessibility so that it is executed on the Event Dispatch thread.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 821:

> 819: 
> 820: 
> 821:     private static Accessible getAccessibleComboboxValue(Accessible a, Component c) {

A comment or javadoc should mention that this is called from native code, specifically pointing to `ComboBoxAccessibility.m`.

-------------

PR: https://git.openjdk.org/jdk/pull/11653


From duke at openjdk.org  Tue Dec 13 19:43:37 2022
From: duke at openjdk.org (SWinxy)
Date: Tue, 13 Dec 2022 19:43:37 GMT
Subject: RFR: 8298352: apple.laf.JRSUIUtils class creates many indirections
Message-ID: <p7LTlpangyiscxAO3M7u4VVNNqFnOo8f8m1ZU62YyGw=.75a40977-d36d-46cb-a564-a28ffda89e0a@github.com>

`JRSUIUtils.java` structurally does things weirdly. The utility class mostly passes parameters from functions to other functions. The indirection makes things harder to understand the eventual purpose.

Take `AquaInternalFrameBorderMetrics.java`. It has a `static boolean` that caches a call to `shouldUseLegacyBorderMetrics()`, which returns `isSnowLeopardOrBelow`, itself a cached call to `isMacOSXSnowLeopardOrBelow()`, which is what finally calls `currentMacOSXVersionMatchesGivenVersionRange()`. When looking at the code, it takes time to unravel the path it takes. Instead of that, a `public static final boolean` can expose the cached value and, in doing so, exposes the *meaning* behind the check.

In `AquaLookAndFeel.java`, the value of `TabbedPaneUI` is calculated using `JRSUIUtils.TabbedPane.shouldUseTabbedPaneContrastUI()`, but that could mean any reason for why `"AquaTabbedPaneContrastUI"` may be the value as opposed to `"AquaTabbedPaneUI"`. Replacing it with `JRSUIUtils.isSnowLeopardOrBelow` reveals that it actually has to do with the OS version being, well, Snow Leopard or below.

These change makes understanding the code easier and quicker. Also more optimized.

Changes:
* add JRSUIConstants.ScrollBarPart.ordinal() to return the property's ordinal value, which is not public
* change 3 access modifiers in JRSUIControl to public allowing for access outside the package
* JRSUIConstants.NineSliceMetricsProvider changed to a normal Function<>
* cache `isMacOSXBigSurOrAbove` rather than calling it twice
* inline the functions for clarity
* change static initialization to group all version checks together
* document JRSUIUtils

-------------

Commit messages:
 - Group OSX version getting into one static block
 - Update copyright year
 - apple.laf.JRSUIUtils does not indicate what is checked, and passes things unnecessarily

Changes: https://git.openjdk.org/jdk/pull/10326/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10326&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298352
  Stats: 190 lines in 13 files changed: 19 ins; 89 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/10326.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10326/head:pull/10326

PR: https://git.openjdk.org/jdk/pull/10326


From jwaters at openjdk.org  Tue Dec 13 19:43:37 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 13 Dec 2022 19:43:37 GMT
Subject: RFR: 8298352: apple.laf.JRSUIUtils class creates many indirections
In-Reply-To: <p7LTlpangyiscxAO3M7u4VVNNqFnOo8f8m1ZU62YyGw=.75a40977-d36d-46cb-a564-a28ffda89e0a@github.com>
References: <p7LTlpangyiscxAO3M7u4VVNNqFnOo8f8m1ZU62YyGw=.75a40977-d36d-46cb-a564-a28ffda89e0a@github.com>
Message-ID: <q9KJ7Vbecvbns3ACRbnn13yKtVl935gGjCdb8zwZiP8=.94cd64ae-b3f4-4ba4-b389-a0d237a8e649@github.com>

On Sun, 18 Sep 2022 21:23:12 GMT, SWinxy <duke at openjdk.org> wrote:

> `JRSUIUtils.java` structurally does things weirdly. The utility class mostly passes parameters from functions to other functions. The indirection makes things harder to understand the eventual purpose.
> 
> Take `AquaInternalFrameBorderMetrics.java`. It has a `static boolean` that caches a call to `shouldUseLegacyBorderMetrics()`, which returns `isSnowLeopardOrBelow`, itself a cached call to `isMacOSXSnowLeopardOrBelow()`, which is what finally calls `currentMacOSXVersionMatchesGivenVersionRange()`. When looking at the code, it takes time to unravel the path it takes. Instead of that, a `public static final boolean` can expose the cached value and, in doing so, exposes the *meaning* behind the check.
> 
> In `AquaLookAndFeel.java`, the value of `TabbedPaneUI` is calculated using `JRSUIUtils.TabbedPane.shouldUseTabbedPaneContrastUI()`, but that could mean any reason for why `"AquaTabbedPaneContrastUI"` may be the value as opposed to `"AquaTabbedPaneUI"`. Replacing it with `JRSUIUtils.isSnowLeopardOrBelow` reveals that it actually has to do with the OS version being, well, Snow Leopard or below.
> 
> These change makes understanding the code easier and quicker. Also more optimized.
> 
> Changes:
> * add JRSUIConstants.ScrollBarPart.ordinal() to return the property's ordinal value, which is not public
> * change 3 access modifiers in JRSUIControl to public allowing for access outside the package
> * JRSUIConstants.NineSliceMetricsProvider changed to a normal Function<>
> * cache `isMacOSXBigSurOrAbove` rather than calling it twice
> * inline the functions for clarity
> * change static initialization to group all version checks together
> * document JRSUIUtils

https://bugs.openjdk.org/browse/JDK-8298352

I suggest you mark this as draft before linking it to the entry in the system though. Trust me when I say you do not want an unfinished change reaching the mailing lists, especially with so many test failures

-------------

PR: https://git.openjdk.org/jdk/pull/10326


From duke at openjdk.org  Tue Dec 13 19:43:38 2022
From: duke at openjdk.org (SWinxy)
Date: Tue, 13 Dec 2022 19:43:38 GMT
Subject: RFR: 8298352: apple.laf.JRSUIUtils class creates many indirections
In-Reply-To: <p7LTlpangyiscxAO3M7u4VVNNqFnOo8f8m1ZU62YyGw=.75a40977-d36d-46cb-a564-a28ffda89e0a@github.com>
References: <p7LTlpangyiscxAO3M7u4VVNNqFnOo8f8m1ZU62YyGw=.75a40977-d36d-46cb-a564-a28ffda89e0a@github.com>
Message-ID: <g-n7TOKWF71JKP0wQOIu8j9tgHlUwZAdhnfAYe7FNC4=.22c2a4e7-6d6b-4b01-aaa9-4518aa0a90ec@github.com>

On Sun, 18 Sep 2022 21:23:12 GMT, SWinxy <duke at openjdk.org> wrote:

> `JRSUIUtils.java` structurally does things weirdly. The utility class mostly passes parameters from functions to other functions. The indirection makes things harder to understand the eventual purpose.
> 
> Take `AquaInternalFrameBorderMetrics.java`. It has a `static boolean` that caches a call to `shouldUseLegacyBorderMetrics()`, which returns `isSnowLeopardOrBelow`, itself a cached call to `isMacOSXSnowLeopardOrBelow()`, which is what finally calls `currentMacOSXVersionMatchesGivenVersionRange()`. When looking at the code, it takes time to unravel the path it takes. Instead of that, a `public static final boolean` can expose the cached value and, in doing so, exposes the *meaning* behind the check.
> 
> In `AquaLookAndFeel.java`, the value of `TabbedPaneUI` is calculated using `JRSUIUtils.TabbedPane.shouldUseTabbedPaneContrastUI()`, but that could mean any reason for why `"AquaTabbedPaneContrastUI"` may be the value as opposed to `"AquaTabbedPaneUI"`. Replacing it with `JRSUIUtils.isSnowLeopardOrBelow` reveals that it actually has to do with the OS version being, well, Snow Leopard or below.
> 
> These change makes understanding the code easier and quicker. Also more optimized.
> 
> Changes:
> * add JRSUIConstants.ScrollBarPart.ordinal() to return the property's ordinal value, which is not public
> * change 3 access modifiers in JRSUIControl to public allowing for access outside the package
> * JRSUIConstants.NineSliceMetricsProvider changed to a normal Function<>
> * cache `isMacOSXBigSurOrAbove` rather than calling it twice
> * inline the functions for clarity
> * change static initialization to group all version checks together
> * document JRSUIUtils

Since it only concerns macOS, the Linux builds are irrelevant. The failures are due to toolchain dependencies and GitHub actions.

-------------

PR: https://git.openjdk.org/jdk/pull/10326


From duke at openjdk.org  Tue Dec 13 19:53:02 2022
From: duke at openjdk.org (Rajat Mahajan)
Date: Tue, 13 Dec 2022 19:53:02 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v2]
In-Reply-To: <biffK-rMXKafRrrKPgT4rKrc_ZK_6EEbgw5NnO721P0=.db5323cc-6228-4cdc-80a0-b464d436b8e2@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <biffK-rMXKafRrrKPgT4rKrc_ZK_6EEbgw5NnO721P0=.db5323cc-6228-4cdc-80a0-b464d436b8e2@github.com>
Message-ID: <l9iyervxoaiN2yhw33Bb3ja6SzULVtzVjhO-D99HtBI=.173401cb-1433-482e-85da-364d8c0c3268@github.com>

On Mon, 12 Dec 2022 22:43:08 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as parameter to method.  
>> 
>> Following are the usual steps for any border scaling -
>> 
>> - Resetting transform.
>> - Calculating new width, height, x & y-translations.
>> - Perform the required border rendering.
>> - And at the end restore the previous transform.
>> 
>> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
>> 
>> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
>> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
>> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
>> 
>> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review changes

Marked as reviewed by rajamah at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/11571


From serb at openjdk.org  Tue Dec 13 20:04:07 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 Dec 2022 20:04:07 GMT
Subject: [jdk20] RFR: 8298083: The
 "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working
Message-ID: <-w3q4N0YsCvrK9ano6m4zrujjksesyS1gg8v8gUSmmw=.ca5e26a5-1da9-4f39-9b7c-e7a08e6407d5@github.com>

Hi all,
This pull request contains a backport of commit [5540a8c5](https://github.com/openjdk/jdk/commit/5540a8c5b7160ab5c67bb84631e3de54fa5aeceb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Sergey Bylokhov on 8 Dec 2022 and was reviewed by Prasanta Sadhukhan.
Thanks!

-------------

Commit messages:
 - Backport 5540a8c5b7160ab5c67bb84631e3de54fa5aeceb

Changes: https://git.openjdk.org/jdk20/pull/17/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=17&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298083
  Stats: 52 lines in 4 files changed: 18 ins; 21 del; 13 mod
  Patch: https://git.openjdk.org/jdk20/pull/17.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/17/head:pull/17

PR: https://git.openjdk.org/jdk20/pull/17


From achung at openjdk.org  Tue Dec 13 21:10:51 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 13 Dec 2022 21:10:51 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v2]
In-Reply-To: <biffK-rMXKafRrrKPgT4rKrc_ZK_6EEbgw5NnO721P0=.db5323cc-6228-4cdc-80a0-b464d436b8e2@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <biffK-rMXKafRrrKPgT4rKrc_ZK_6EEbgw5NnO721P0=.db5323cc-6228-4cdc-80a0-b464d436b8e2@github.com>
Message-ID: <YIXpBkYg82Pvi5wsOQwxkO5GvCW8zMboxyN0o902X9s=.d2b5be0d-2172-4acc-85c5-f891e31fec71@github.com>

On Mon, 12 Dec 2022 22:43:08 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as parameter to method.  
>> 
>> Following are the usual steps for any border scaling -
>> 
>> - Resetting transform.
>> - Calculating new width, height, x & y-translations.
>> - Perform the required border rendering.
>> - And at the end restore the previous transform.
>> 
>> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
>> 
>> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
>> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
>> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
>> 
>> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review changes

Marked as reviewed by achung (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/11571


From achung at openjdk.org  Wed Dec 14 01:01:33 2022
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 14 Dec 2022 01:01:33 GMT
Subject: RFR: 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java
 fails with "No MouseReleased event on label!" [v4]
In-Reply-To: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
References: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
Message-ID: <VNBzNnAJq6Heb-7Khy6aFP9N8jmYJLcHF1kUFsqVYLo=.2f99a352-3070-4672-bfcc-785270b2d368@github.com>

> Test was run on mac, windows, linux 50 times and passed after change
> Before fix, test fails about once every 50 runs on linux and windows platforms

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  setLocationRelativeTo set to null

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11425/files
  - new: https://git.openjdk.org/jdk/pull/11425/files/8f0e0e71..fb846a79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11425&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11425&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11425.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11425/head:pull/11425

PR: https://git.openjdk.org/jdk/pull/11425


From serb at openjdk.org  Wed Dec 14 01:49:08 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 Dec 2022 01:49:08 GMT
Subject: [jdk20] RFR: 8298083: The
 "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working
In-Reply-To: <-w3q4N0YsCvrK9ano6m4zrujjksesyS1gg8v8gUSmmw=.ca5e26a5-1da9-4f39-9b7c-e7a08e6407d5@github.com>
References: <-w3q4N0YsCvrK9ano6m4zrujjksesyS1gg8v8gUSmmw=.ca5e26a5-1da9-4f39-9b7c-e7a08e6407d5@github.com>
Message-ID: <4bjVmG4iXY30JWJKycSaJckHiw-t7qxLD77fRRQZ8h4=.0f0ef410-3385-4b5a-a315-52d6df7e0ac9@github.com>

On Mon, 12 Dec 2022 09:37:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit [5540a8c5](https://github.com/openjdk/jdk/commit/5540a8c5b7160ab5c67bb84631e3de54fa5aeceb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> The commit being backported was authored by Sergey Bylokhov on 8 Dec 2022 and was reviewed by Prasanta Sadhukhan.
> Thanks!

@psadhukhan please take a look

-------------

PR: https://git.openjdk.org/jdk20/pull/17


From psadhukhan at openjdk.org  Wed Dec 14 03:21:57 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 14 Dec 2022 03:21:57 GMT
Subject: RFR: 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame
 throws a NPE. [v3]
In-Reply-To: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
References: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
Message-ID: <ERkChhOA2NvabEXdk-aPL3__EcRQprQqjLMQu9MGT7g=.953f7af9-eab4-4a2c-b60b-2ba5fcb6b3b7@github.com>

> In Swingset2 JInternalFrame demo, focusing on any internalframes and pressing Ctrl+F7 and then any of up/down/left/arrow key to move the internal frames results in NPE in NimbusL&F.
> It is because `JComponent.processKeyBinding() `calls `SwingUtilities.notifyAction` which calls `BasicDesktopPaneUI.actionPerformed` where it gets `Desktop.minOnScreenInsets` property to get the Insets and then uses insets.top/bottom/left/right value to move the internalframe but this property is not defined for Nimbus so deferencing Insets object results in NPE.
> 
> Fix is added to create a 0 insets incase some L&F do not define` Desktop.minOnScreenInsets` property.
> No regression test is added as it can be easily checked by SwingSet2 JInternalFrame demo.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix jcheck issues

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11605/files
  - new: https://git.openjdk.org/jdk/pull/11605/files/a4927f57..8368f130

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11605&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11605&range=01-02

  Stats: 17 lines in 1 file changed: 3 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/11605.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11605/head:pull/11605

PR: https://git.openjdk.org/jdk/pull/11605


From psadhukhan at openjdk.org  Wed Dec 14 03:50:54 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 14 Dec 2022 03:50:54 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v2]
In-Reply-To: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
Message-ID: <_KNiQ96NyPHL7dQDcea1f2YhIHNqfv3a4ZNJKTmAEik=.c7d97d75-09f7-4c8c-b433-5a030b12205c@github.com>

> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
> says:
> "...MetalLookAndFeel registers an entry for each of the classes
> in the package javax.swing.plaf.metal that are named MetalXXXUI.
> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
> that do not have a class in metal, the corresponding class in
> javax.swing.plaf.basic is used. For example, metal does not
> have a class named "MetalColorChooserUI", as such,
> javax.swing.plaf.basic.BasicColorChooserUI is used".
> 
> There is class MetalMenuBarUI, but the method populates given defaults table with the value
> "javax.swing.plaf.basic.BasicMenuBarUI".
> 
> Added entry for MetalMenuBarUI..
> CI tests including JCK tests are ok.

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Spec update
 - Spec update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11646/files
  - new: https://git.openjdk.org/jdk/pull/11646/files/acbf7776..2ea55a0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11646&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11646&range=00-01

  Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11646.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11646/head:pull/11646

PR: https://git.openjdk.org/jdk/pull/11646


From psadhukhan at openjdk.org  Wed Dec 14 04:02:08 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 14 Dec 2022 04:02:08 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v2]
In-Reply-To: <qfN0MN7FhypwDnihm9LZFMAQasFxzsMAI9BTi32Vd2Y=.8469de92-225b-4b80-8846-0606a736dea5@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <qfN0MN7FhypwDnihm9LZFMAQasFxzsMAI9BTi32Vd2Y=.8469de92-225b-4b80-8846-0606a736dea5@github.com>
Message-ID: <KiLvikKKKapuyc3FlYMIMT6MbMDhML5cJOADqaQ7bmw=.3c1571c6-a9be-496d-9b33-e837a28525a0@github.com>

On Tue, 13 Dec 2022 18:35:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Spec update
>>  - Spec update
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java line 276:
> 
>> 274:                     "LabelUI", metalPackageName + "MetalLabelUI",
>> 275:                   "MenuBarUI", metalPackageName + "MetalMenuBarUI",
>> 276:        "PopupMenuSeparatorUI", metalPackageName + "MetalPopupMenuSeparatorUI",
> 
> I think it is installed by the Ocean theme, which is used by the Metal L&F by default.

Spec updated

-------------

PR: https://git.openjdk.org/jdk/pull/11646


From psadhukhan at openjdk.org  Wed Dec 14 05:02:49 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 14 Dec 2022 05:02:49 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: <4K0UuXV-bC7kFAiF6Tjf0yVXgVrGsQIgKgEtM64cILI=.18486422-b42c-4134-98d4-3071ffbbc4e2@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

Carried forward in https://github.com/openjdk/jdk/pull/11660

-------------

PR: https://git.openjdk.org/jdk/pull/9900


From abhiscxk at openjdk.org  Wed Dec 14 05:05:21 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 14 Dec 2022 05:05:21 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel
In-Reply-To: <Hxtdl5xVvpzHDuf5Yh4WOQ60nWF4_LL0_MEkgHQVriY=.6b64122e-2749-4b6c-b391-5312d697bcc9@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
 <Hxtdl5xVvpzHDuf5Yh4WOQ60nWF4_LL0_MEkgHQVriY=.6b64122e-2749-4b6c-b391-5312d697bcc9@github.com>
Message-ID: <16SqlhKKcfUp423o4-vttZJUuRZmb8juDaE8L3uFdFQ=.ca7c59da-395f-484c-afb0-6e1071edb5aa@github.com>

On Wed, 7 Dec 2022 22:00:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> In case of GTK LAF, the current selected element was not visible due to arrowbutton is rendered in entire display area of Combobox.
>> 
>> The proposed fix is to set the `squareButton `property of combobox to `false `so that the arrowbutton didn't take entire combobox display area for rendering. The `getMinimumSize `method is overridden in `SynthComboBoxUI `to consider **arrowbutton insets** for combobox minimum size. 
>> 
>> The JCK tests mentioned in JBS seems fine with the fix. 
>> An automated test case is implemented to test in Nimbus and GTK LAF. The text color check is to ensure the current selected item is visible.
>> 
>> When swing tests are run with LAF set to Nimbus and GTK LAF, few test failures observed. 
>> 
>> Although CI jobs looks ok with tests run in their default set LAFs.
>> 
>> `open/test/jdk/javax/swing/JComboBox/TestComboBoxHeight.java` test passes if run in GTK LAF with current fix.
>
> No it is confidential or something like that. Cannot open/view it.

@mrserb Please have a look.

-------------

PR: https://git.openjdk.org/jdk/pull/11555


From psadhukhan at openjdk.org  Wed Dec 14 05:08:46 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 14 Dec 2022 05:08:46 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
Message-ID: <iYA9P9YljBfvinZEbBIF8tWJXtZLXgBxdcBmgLKb7CU=.79a7273a-cb2e-4a80-8c29-18347a9de767@github.com>

Label.foreground UIProperty is not honored by Nimbus L&F. It needs to be Label[Enabled].textForeground which is the corresponding Synth property
Added support for setting JLabel foreground color for Nimbus L&F

-------------

Commit messages:
 - 7175396: The text on label is not painted red for Nimbus LaF.
 - 7175396: The text on label is not painted red for Nimbus LaF.

Changes: https://git.openjdk.org/jdk/pull/11660/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11660&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7175396
  Stats: 146 lines in 2 files changed: 145 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11660.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11660/head:pull/11660

PR: https://git.openjdk.org/jdk/pull/11660


From jpai at openjdk.org  Wed Dec 14 06:10:35 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Dec 2022 06:10:35 GMT
Subject: RFR: 8298709: Fix typos in src/java.desktop/ and various test classes
 of client component
Message-ID: <YJvUtRHEi5wPVtlKX64yftCh1Bh7KlX5jrCtMUhNwOU=.3a6ab572-e423-4d41-b620-97f9b075e8a6@github.com>

Can I please get a review for this change which only fixes typos? The original PR for this change is https://github.com/openjdk/jdk/pull/10029. However, that PR included changes to multiple different files in different areas of the JDK and as a result didn't see progress.

This current PR splits off those changes and includes only client area related typo fixes.

-------------

Commit messages:
 - 8298709: Fix typos in src/java.desktop/ and various test classes of client component

Changes: https://git.openjdk.org/jdk/pull/11661/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11661&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298709
  Stats: 19 lines in 16 files changed: 0 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/11661.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11661/head:pull/11661

PR: https://git.openjdk.org/jdk/pull/11661


From tr at openjdk.org  Wed Dec 14 06:46:53 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 14 Dec 2022 06:46:53 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <ddjbSHKmT8CjLCSqK18vAfCREE3FHGTGDs7-gCkPll8=.9b04029f-ff3e-41cf-9417-72fac385f3bd@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <ddjbSHKmT8CjLCSqK18vAfCREE3FHGTGDs7-gCkPll8=.9b04029f-ff3e-41cf-9417-72fac385f3bd@github.com>
Message-ID: <3izbzkcKMwbewfAYqjBciua3KIDOO4pVl7mwUQTEOLY=.e829dd17-3ecb-4abd-a3b6-24430c9f40c7@github.com>

On Mon, 12 Dec 2022 17:30:14 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.
>
> At the same time, I suggest filing another bug to track the issue where the code could return a `MultiResolutionImage` with no base image. It should never happen.
> 
> Or you can address it here along with making the test _headful_.

> > @aivanov-jdk I just run some test samples by making the test as headful instead as headless as @prsadhuk suggested. I found out that making it as headful works just fine and no NPE occurred (Headless always showed issue, 8/200 test). And debugging to the root cause of Image not loading is also quite difficult. I guess it's better to modify the test as headful since the reliability of the test is better in it?
> 
> Let's go for it. A headless system could lack something that the test uses even though it doesn't show the UI.
> 
> If _headful_ systems never reproduce the problem, then it's _the fix_.

So far, from the analysis it is found that the backup mechanism to get default Icon is failing when icon extraction fails. Not able to get the trigger point for the failure since it is unpredictable. Failure rate also seems to be dependent on system, last week used to get consistent failures for every test run, this week the issue is not much. So I guess making the test headful is better option now.

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From abhiscxk at openjdk.org  Wed Dec 14 07:32:29 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 14 Dec 2022 07:32:29 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native [v2]
In-Reply-To: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
Message-ID: <Pjovs8SarwwB8xVZBtiowY8NflwPc3t6dfcmV0aKp8w=.75a93bad-1318-4edc-a675-617551666118@github.com>

> It is not possible to select all files on press of Ctrl+A in JFileChooser for GTK LAF where as all folders can be selected. 
> In native side on press of Ctrl+A, able to select all files as well as folders.
> 
> Proposed fix is to enable `multiselection `property by default for JFileChooser in GTK LAF to mimic native side behavior.
> 
> An automated test case is implemented and tested in CI. CI job links are attached in JBS.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Update for folder list and test review comment update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11627/files
  - new: https://git.openjdk.org/jdk/pull/11627/files/4c12d5ba..2a8f892d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11627&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11627&range=00-01

  Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11627.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11627/head:pull/11627

PR: https://git.openjdk.org/jdk/pull/11627


From abhiscxk at openjdk.org  Wed Dec 14 07:40:02 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 14 Dec 2022 07:40:02 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native [v2]
In-Reply-To: <g3qg0VmXk5kXgEl24cJv6-DTu4_qy7dGxosMZRhXPWM=.88775a70-317c-4e0f-8f60-2931d09fe2a7@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
 <g3qg0VmXk5kXgEl24cJv6-DTu4_qy7dGxosMZRhXPWM=.88775a70-317c-4e0f-8f60-2931d09fe2a7@github.com>
Message-ID: <nMlHTPFxoin_Qlsb36zs0htx8b6fn5aCLXPmdUptTcs=.232db9bc-8a3a-4f81-ad01-855b98e914f0@github.com>

On Tue, 13 Dec 2022 14:50:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update for folder list and test review comment update
>
> Marked as reviewed by psadhukhan (Reviewer).

@prsadhuk From the last fix, all folders can be selected even if `multiselection` is set to `false` which seems incorrect.  

Updated in the latest fix. CI jobs are Ok. 

Please review the latest changes.

-------------

PR: https://git.openjdk.org/jdk/pull/11627


From abhiscxk at openjdk.org  Wed Dec 14 07:40:03 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 14 Dec 2022 07:40:03 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native [v2]
In-Reply-To: <fY06lcX86VG3jPRLEwju0wVsWyDhB6UmyYgwIioQyhw=.f620909f-7bb0-4d09-a0ab-83360d96c6ae@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
 <fY06lcX86VG3jPRLEwju0wVsWyDhB6UmyYgwIioQyhw=.f620909f-7bb0-4d09-a0ab-83360d96c6ae@github.com>
Message-ID: <MOyim0FRTbJ_sWUhIxY96a9si-7pcjZTHL9Mih7v8BU=.da4ea8d3-162f-42a0-bdd2-351e3911a597@github.com>

On Tue, 13 Dec 2022 18:39:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update for folder list and test review comment update
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java line 567:
> 
>> 565:         fc.setLayout(new BorderLayout());
>> 566:         fc.setAlignmentX(JComponent.CENTER_ALIGNMENT);
>> 567:         fc.setMultiSelectionEnabled(true);
> 
> Please double check that this will not override what the user set

It will not override the user choice. If user has set `multiselection `to `false`, FileChooser won't allow to select all files or folders.

-------------

PR: https://git.openjdk.org/jdk/pull/11627


From serb at openjdk.org  Wed Dec 14 08:27:55 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 Dec 2022 08:27:55 GMT
Subject: RFR: 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame
 throws a NPE. [v3]
In-Reply-To: <ERkChhOA2NvabEXdk-aPL3__EcRQprQqjLMQu9MGT7g=.953f7af9-eab4-4a2c-b60b-2ba5fcb6b3b7@github.com>
References: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
 <ERkChhOA2NvabEXdk-aPL3__EcRQprQqjLMQu9MGT7g=.953f7af9-eab4-4a2c-b60b-2ba5fcb6b3b7@github.com>
Message-ID: <5qmrfbxyyhDwLN2OyjYZBcw-HeRfT-SZWsaeiVJHWFw=.1472a10c-938b-4ad2-9388-b4544d81bd08@github.com>

On Wed, 14 Dec 2022 03:21:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In Swingset2 JInternalFrame demo, focusing on any internalframes and pressing Ctrl+F7 and then any of up/down/left/arrow key to move the internal frames results in NPE in NimbusL&F.
>> It is because `JComponent.processKeyBinding() `calls `SwingUtilities.notifyAction` which calls `BasicDesktopPaneUI.actionPerformed` where it gets `Desktop.minOnScreenInsets` property to get the Insets and then uses insets.top/bottom/left/right value to move the internalframe but this property is not defined for Nimbus so deferencing Insets object results in NPE.
>> 
>> Fix is added to create a 0 insets incase some L&F do not define` Desktop.minOnScreenInsets` property.
>> No regression test is added as it can be easily checked by SwingSet2 JInternalFrame demo.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jcheck issues

test/jdk/javax/swing/JInternalFrame/JInternalFrameTest.java line 104:

> 102:                 }
> 103:             } finally {
> 104:                 if (jFrame != null) {

If `jFrame` is checked on the main thread it should be volatile as well.

-------------

PR: https://git.openjdk.org/jdk/pull/11605


From asemenov at openjdk.org  Wed Dec 14 09:26:09 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 14 Dec 2022 09:26:09 GMT
Subject: RFR: 8298645 JNI works with accessibleSelection on a wrong thread
 [v2]
In-Reply-To: <w3UAuIF1k3EhbKSCxEXQ_5g5S9mOaepbIf_x_PDpt9g=.694f5c75-8384-433c-9b65-75910f61be37@github.com>
References: <w3UAuIF1k3EhbKSCxEXQ_5g5S9mOaepbIf_x_PDpt9g=.694f5c75-8384-433c-9b65-75910f61be37@github.com>
Message-ID: <h5O1pwggmA5QGBoR5FGfpUnDCpbpWuVX2wiHnh1WEVg=.907269d9-0519-45a0-a44a-9fb6293c2e47@github.com>

> [ComboBoxAccessibility accessibilityValue] works with the accessibleSelection object directly, however the work should go through CAccessibility so that it is executed on the Event Dispatch thread.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  A comment or javadoc should mention that this is called from native code, specifically pointing to ComboBoxAccessibility.m.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11653/files
  - new: https://git.openjdk.org/jdk/pull/11653/files/077b215e..38319bf7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11653&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11653&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11653.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11653/head:pull/11653

PR: https://git.openjdk.org/jdk/pull/11653


From asemenov at openjdk.org  Wed Dec 14 09:26:09 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 14 Dec 2022 09:26:09 GMT
Subject: RFR: 8298645 JNI works with accessibleSelection on a wrong thread
 [v2]
In-Reply-To: <Rb9yXGwv0_zuh0bE8TWnxsaAkB5_HOUNmtSbgbdEhcU=.e5378483-434e-4da9-a15b-0545e43c83e8@github.com>
References: <w3UAuIF1k3EhbKSCxEXQ_5g5S9mOaepbIf_x_PDpt9g=.694f5c75-8384-433c-9b65-75910f61be37@github.com>
 <Rb9yXGwv0_zuh0bE8TWnxsaAkB5_HOUNmtSbgbdEhcU=.e5378483-434e-4da9-a15b-0545e43c83e8@github.com>
Message-ID: <tuGA1foDnk1EAkppSiE3CCrEIBUD6Vj9nzwM7l6Sujw=.8c5b2844-67a7-48d1-b7cf-c84fafd6cf44@github.com>

On Tue, 13 Dec 2022 19:26:37 GMT, SWinxy <duke at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   A comment or javadoc should mention that this is called from native code, specifically pointing to ComboBoxAccessibility.m.
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 821:
> 
>> 819: 
>> 820: 
>> 821:     private static Accessible getAccessibleComboboxValue(Accessible a, Component c) {
> 
> A comment or javadoc should mention that this is called from native code, specifically pointing to `ComboBoxAccessibility.m`.

Done

-------------

PR: https://git.openjdk.org/jdk/pull/11653


From tr at openjdk.org  Wed Dec 14 10:23:01 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 14 Dec 2022 10:23:01 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel
In-Reply-To: <8FVGtWwcIbQMorFWYKtDGtEjTSN9VotwbjknJZMOKrw=.25b01ec0-aaea-479f-90b5-cebbcbc04d97@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
 <pYeCNRYHEcoZTKCzE-d1r0Uo6oDYmkiBsmQhCdJ6jig=.340ca791-e00c-4dcf-b8cf-819c5e193566@github.com>
 <8FVGtWwcIbQMorFWYKtDGtEjTSN9VotwbjknJZMOKrw=.25b01ec0-aaea-479f-90b5-cebbcbc04d97@github.com>
Message-ID: <PE1a639NGReLm5fHMD8j5r1NPAsiUqZfaAXhTGBZfBc=.e79cd427-9753-49e7-806a-e3ee2fce5292@github.com>

On Mon, 12 Dec 2022 10:28:50 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> > _TestComboBoxComponentRendering.java_ test failed (Synth L&F) in Ubuntu_21 VM machine. .jtr file and Failure case screen captured shared.
> 
> Run the test in Ubuntu 20,21 and 22 in CI pipeline, test passed for all platform.

The issue was that I was running in wayland, not xorg. The fix is tested and works fine

-------------

PR: https://git.openjdk.org/jdk/pull/11555


From tr at openjdk.org  Wed Dec 14 10:23:01 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 14 Dec 2022 10:23:01 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel
In-Reply-To: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
Message-ID: <SCKTh6d1n3xWjyKZmYtHnp8OS49ys20QeqhNJ-7micA=.33b69fdb-5fa9-48c9-830b-6e740ca63303@github.com>

On Wed, 7 Dec 2022 10:25:31 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> In case of GTK LAF, the current selected element was not visible due to arrowbutton is rendered in entire display area of Combobox.
> 
> The proposed fix is to set the `squareButton `property of combobox to `false `so that the arrowbutton didn't take entire combobox display area for rendering. The `getMinimumSize `method is overridden in `SynthComboBoxUI `to consider **arrowbutton insets** for combobox minimum size. 
> 
> The JCK tests mentioned in JBS seems fine with the fix. 
> An automated test case is implemented to test in Nimbus and GTK LAF. The text color check is to ensure the current selected item is visible.
> 
> When swing tests are run with LAF set to Nimbus and GTK LAF, few test failures observed. 
> 
> Although CI jobs looks ok with tests run in their default set LAFs.
> 
> `open/test/jdk/javax/swing/JComboBox/TestComboBoxHeight.java` test passes if run in GTK LAF with current fix.

Marked as reviewed by tr (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/11555


From asemenov at openjdk.org  Wed Dec 14 10:57:07 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 14 Dec 2022 10:57:07 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
Message-ID: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>

[OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

-------------

Commit messages:
 - 8298644 JNI call of getCurrentComponent on a wrong thread

Changes: https://git.openjdk.org/jdk/pull/11670/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11670&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298644
  Stats: 99 lines in 6 files changed: 80 ins; 14 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11670.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11670/head:pull/11670

PR: https://git.openjdk.org/jdk/pull/11670


From psadhukhan at openjdk.org  Wed Dec 14 10:58:47 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 14 Dec 2022 10:58:47 GMT
Subject: RFR: 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame
 throws a NPE. [v4]
In-Reply-To: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
References: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
Message-ID: <7P2I0AigbPWt_LkGjlZs9N6YlbCgMUH-sWgj0IurRTo=.9035162c-e492-4b21-b346-5f48fa02123a@github.com>

> In Swingset2 JInternalFrame demo, focusing on any internalframes and pressing Ctrl+F7 and then any of up/down/left/arrow key to move the internal frames results in NPE in NimbusL&F.
> It is because `JComponent.processKeyBinding() `calls `SwingUtilities.notifyAction` which calls `BasicDesktopPaneUI.actionPerformed` where it gets `Desktop.minOnScreenInsets` property to get the Insets and then uses insets.top/bottom/left/right value to move the internalframe but this property is not defined for Nimbus so deferencing Insets object results in NPE.
> 
> Fix is added to create a 0 insets incase some L&F do not define` Desktop.minOnScreenInsets` property.
> No regression test is added as it can be easily checked by SwingSet2 JInternalFrame demo.

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/11605/files
  - new: https://git.openjdk.org/jdk/pull/11605/files/8368f130..c7fe6a4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11605&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11605&range=02-03

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11605.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11605/head:pull/11605

PR: https://git.openjdk.org/jdk/pull/11605


From psadhukhan at openjdk.org  Wed Dec 14 10:59:04 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 14 Dec 2022 10:59:04 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native [v2]
In-Reply-To: <Pjovs8SarwwB8xVZBtiowY8NflwPc3t6dfcmV0aKp8w=.75a93bad-1318-4edc-a675-617551666118@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
 <Pjovs8SarwwB8xVZBtiowY8NflwPc3t6dfcmV0aKp8w=.75a93bad-1318-4edc-a675-617551666118@github.com>
Message-ID: <E6udzqe0MgnIub2fuD98JxIqmEQ-SLsjPUeOuhDfFhM=.c1491a5d-c208-4d26-8f2b-a7c64b89168c@github.com>

On Wed, 14 Dec 2022 07:32:29 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> It is not possible to select all files on press of Ctrl+A in JFileChooser for GTK LAF where as all folders can be selected. 
>> In native side on press of Ctrl+A, able to select all files as well as folders.
>> 
>> Proposed fix is to enable `multiselection `property by default for JFileChooser in GTK LAF to mimic native side behavior.
>> 
>> An automated test case is implemented and tested in CI. CI job links are attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update for folder list and test review comment update

Ok with me..Probably better to add a subtest with setMultiSelectionEnabled(false) and check multiple files are not selected..

-------------

PR: https://git.openjdk.org/jdk/pull/11627


From psadhukhan at openjdk.org  Wed Dec 14 11:00:22 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 14 Dec 2022 11:00:22 GMT
Subject: [jdk20] RFR: 8298083: The
 "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working
In-Reply-To: <-w3q4N0YsCvrK9ano6m4zrujjksesyS1gg8v8gUSmmw=.ca5e26a5-1da9-4f39-9b7c-e7a08e6407d5@github.com>
References: <-w3q4N0YsCvrK9ano6m4zrujjksesyS1gg8v8gUSmmw=.ca5e26a5-1da9-4f39-9b7c-e7a08e6407d5@github.com>
Message-ID: <syGWaa_jjCSDyFGEoDLQhPyBzYs7dWfzjIff_xqG_8I=.ab3eb83a-d918-4c54-b04f-96c3ba0a45db@github.com>

On Mon, 12 Dec 2022 09:37:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit [5540a8c5](https://github.com/openjdk/jdk/commit/5540a8c5b7160ab5c67bb84631e3de54fa5aeceb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> The commit being backported was authored by Sergey Bylokhov on 8 Dec 2022 and was reviewed by Prasanta Sadhukhan.
> Thanks!

I guess for clean backport doesn't need a reviewer..

-------------

PR: https://git.openjdk.org/jdk20/pull/17


From abhiscxk at openjdk.org  Wed Dec 14 11:03:03 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 14 Dec 2022 11:03:03 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native [v2]
In-Reply-To: <E6udzqe0MgnIub2fuD98JxIqmEQ-SLsjPUeOuhDfFhM=.c1491a5d-c208-4d26-8f2b-a7c64b89168c@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
 <Pjovs8SarwwB8xVZBtiowY8NflwPc3t6dfcmV0aKp8w=.75a93bad-1318-4edc-a675-617551666118@github.com>
 <E6udzqe0MgnIub2fuD98JxIqmEQ-SLsjPUeOuhDfFhM=.c1491a5d-c208-4d26-8f2b-a7c64b89168c@github.com>
Message-ID: <aRaYCcI8-AUxzB9fwnXOMVk3FlaWfwYg7SLz0XNO4nU=.f5deacf5-fa45-4f57-b1e0-7126591dc3fc@github.com>

On Wed, 14 Dec 2022 10:56:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Ok with me..Probably better to add a subtest with setMultiSelectionEnabled(false) and check multiple files are not selected..

OK... I will try to update the test.

-------------

PR: https://git.openjdk.org/jdk/pull/11627


From abhiscxk at openjdk.org  Wed Dec 14 11:47:56 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 14 Dec 2022 11:47:56 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
In-Reply-To: <iYA9P9YljBfvinZEbBIF8tWJXtZLXgBxdcBmgLKb7CU=.79a7273a-cb2e-4a80-8c29-18347a9de767@github.com>
References: <iYA9P9YljBfvinZEbBIF8tWJXtZLXgBxdcBmgLKb7CU=.79a7273a-cb2e-4a80-8c29-18347a9de767@github.com>
Message-ID: <4gqr14XlcRb72oqMKCnMQuWGBPoNgJOLGjgAnMx7WnY=.776a4f31-56c0-4f5c-8911-d70d8f2c2635@github.com>

On Wed, 14 Dec 2022 04:59:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Label.foreground UIProperty is not honored by Nimbus L&F. It needs to be Label[Enabled].textForeground which is the corresponding Synth property
> Added support for setting JLabel foreground color for Nimbus L&F

test/jdk/javax/swing/plaf/nimbus/TestNimbusLabel.java line 77:

> 75:                                             java.awt.Color.red);
> 76:                 label =
> 77:                     //new JLabel("This text should be in red");

Commented code can be removed.

-------------

PR: https://git.openjdk.org/jdk/pull/11660


From abhiscxk at openjdk.org  Wed Dec 14 13:05:22 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 14 Dec 2022 13:05:22 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native [v3]
In-Reply-To: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
Message-ID: <JHzQbqzoZk-EpChKpjv8zoS_QZplL-HfTMO_wkf7NH4=.9b420462-ba1a-4912-8bd5-db95bb381e68@github.com>

> It is not possible to select all files on press of Ctrl+A in JFileChooser for GTK LAF where as all folders can be selected. 
> In native side on press of Ctrl+A, able to select all files as well as folders.
> 
> Proposed fix is to enable `multiselection `property by default for JFileChooser in GTK LAF to mimic native side behavior.
> 
> An automated test case is implemented and tested in CI. CI job links are 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:

 - Subtest added for multiselection disabled
 - Merge
 - Update for folder list and test review comment update
 - Select all files on CTrl+A fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11627/files
  - new: https://git.openjdk.org/jdk/pull/11627/files/2a8f892d..52fa7cba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11627&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11627&range=01-02

  Stats: 17027 lines in 441 files changed: 11687 ins; 3883 del; 1457 mod
  Patch: https://git.openjdk.org/jdk/pull/11627.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11627/head:pull/11627

PR: https://git.openjdk.org/jdk/pull/11627


From abhiscxk at openjdk.org  Wed Dec 14 13:05:23 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 14 Dec 2022 13:05:23 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native [v2]
In-Reply-To: <aRaYCcI8-AUxzB9fwnXOMVk3FlaWfwYg7SLz0XNO4nU=.f5deacf5-fa45-4f57-b1e0-7126591dc3fc@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
 <Pjovs8SarwwB8xVZBtiowY8NflwPc3t6dfcmV0aKp8w=.75a93bad-1318-4edc-a675-617551666118@github.com>
 <E6udzqe0MgnIub2fuD98JxIqmEQ-SLsjPUeOuhDfFhM=.c1491a5d-c208-4d26-8f2b-a7c64b89168c@github.com>
 <aRaYCcI8-AUxzB9fwnXOMVk3FlaWfwYg7SLz0XNO4nU=.f5deacf5-fa45-4f57-b1e0-7126591dc3fc@github.com>
Message-ID: <35VbSus7YBfoI7tsP_em5YmQpL-_CUuksbarxLN91jE=.570e953a-2a1f-43b8-9d6b-8ed0f4c34ecc@github.com>

On Wed, 14 Dec 2022 11:00:31 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Ok with me..Probably better to add a subtest with setMultiSelectionEnabled(false) and check multiple files are not selected..

Added the subtest with `setMultiSelectionEnabled(false)`.

-------------

PR: https://git.openjdk.org/jdk/pull/11627


From aivanov at openjdk.org  Wed Dec 14 15:53:45 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 14 Dec 2022 15:53:45 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <BIp7a1oU3ONbVVR804kdbra9dUK1wtdXY-m7IZGiyBk=.49242328-1fe7-45e4-bfaf-75d858c01541@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <BIp7a1oU3ONbVVR804kdbra9dUK1wtdXY-m7IZGiyBk=.49242328-1fe7-45e4-bfaf-75d858c01541@github.com>
Message-ID: <MQnPbu3cJp2WwjErMMQOWXRfbTVtRKcNNtKetsUIICw=.2fc92ce7-edff-472d-b280-2e97411e6d16@github.com>

On Tue, 13 Dec 2022 13:43:05 GMT, Tejesh R <tr at openjdk.org> wrote:

> Means checking for null when trying to insert null into MRI map?

Yes, because such an image is invalid ? it will produce the NPE when it's rendered. If icon isn't available, `null` is to be returned directly to the caller.

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From aivanov at openjdk.org  Wed Dec 14 15:57:03 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 14 Dec 2022 15:57:03 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <3izbzkcKMwbewfAYqjBciua3KIDOO4pVl7mwUQTEOLY=.e829dd17-3ecb-4abd-a3b6-24430c9f40c7@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <ddjbSHKmT8CjLCSqK18vAfCREE3FHGTGDs7-gCkPll8=.9b04029f-ff3e-41cf-9417-72fac385f3bd@github.com>
 <3izbzkcKMwbewfAYqjBciua3KIDOO4pVl7mwUQTEOLY=.e829dd17-3ecb-4abd-a3b6-24430c9f40c7@github.com>
Message-ID: <R0YD-SmeN5hDOm8HhHha0n14VjbNTa3rnqTyrg79w50=.b2faae9c-60a1-4eb4-93ee-b3cfbebe57ce@github.com>

On Wed, 14 Dec 2022 06:43:00 GMT, Tejesh R <tr at openjdk.org> wrote:

> So far, from the analysis it is found that the backup mechanism to get default Icon is failing when icon extraction fails.

These are the new details which you've never mentioned before.

The icon extraction of a folder (presumably _Downloads_ folder) fails. The fallback is to extract the default icon for a folder, which also fails.

Do I understand it correctly?

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From clanger at openjdk.org  Wed Dec 14 16:01:46 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 14 Dec 2022 16:01:46 GMT
Subject: RFR: JDK-8298093: improve cleanup and error handling of
 awt_parseColorModel in awt_parseImage.c [v3]
In-Reply-To: <2Dhk_nsd_PNixhUjUswA6uxE05Yn2hCHHLZX94DgDXA=.7f4c436c-0ab2-4037-a600-14c2b23ef830@github.com>
References: <LJXA0GoYlzD_v4Gb9N0ytaim25_su2y8hAyWhx0hGKI=.5087cce4-07f1-446c-a389-d65334315f73@github.com>
 <2Dhk_nsd_PNixhUjUswA6uxE05Yn2hCHHLZX94DgDXA=.7f4c436c-0ab2-4037-a600-14c2b23ef830@github.com>
Message-ID: <FMdnEdpTF8JvzOFO60WTmg0tZovN9glfkAuI4ItiHYw=.062a4da2-164f-4d0a-b6d5-fbd647951148@github.com>

On Wed, 7 Dec 2022 08:54:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The cleanup and error handling in function awt_parseColorModel in awt_parseImage.c could be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small adjustment

Marked as reviewed by clanger (Reviewer).

src/java.desktop/share/native/libawt/awt/image/awt_parseImage.c line 457:

> 455:     int i;
> 456:     static jobject s_jdefCM = NULL;
> 457:     cmP->nBits = NULL;

I think you could leave the cmP->nBits initialization where it was. But that's just a nit.

-------------

PR: https://git.openjdk.org/jdk/pull/11508


From tr at openjdk.org  Wed Dec 14 16:03:04 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 14 Dec 2022 16:03:04 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <R0YD-SmeN5hDOm8HhHha0n14VjbNTa3rnqTyrg79w50=.b2faae9c-60a1-4eb4-93ee-b3cfbebe57ce@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <ddjbSHKmT8CjLCSqK18vAfCREE3FHGTGDs7-gCkPll8=.9b04029f-ff3e-41cf-9417-72fac385f3bd@github.com>
 <3izbzkcKMwbewfAYqjBciua3KIDOO4pVl7mwUQTEOLY=.e829dd17-3ecb-4abd-a3b6-24430c9f40c7@github.com>
 <R0YD-SmeN5hDOm8HhHha0n14VjbNTa3rnqTyrg79w50=.b2faae9c-60a1-4eb4-93ee-b3cfbebe57ce@github.com>
Message-ID: <GfTT3TXEpEhzWpL9LSMH2tgoxo6BziUqbCJzxQE5IsE=.de00b608-7d5d-4f7b-8951-1006ce476e5f@github.com>

On Wed, 14 Dec 2022 15:53:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > So far, from the analysis it is found that the backup mechanism to get default Icon is failing when icon extraction fails.
> 
> These are the new details which you've never mentioned before.
> 
> The icon extraction of a folder (presumably _Downloads_ folder) fails. The fallback is to extract the default icon for a folder, which also fails.
> 
> Do I understand it correctly?

Yes. And the fall back is failing for small icon which has size 16. Last week issue was reproducible very frequently, but today didn't get any failure for test runs.

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From aivanov at openjdk.org  Wed Dec 14 16:04:39 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 14 Dec 2022 16:04:39 GMT
Subject: RFR: 8296275: Write a test to verify setAccelerator method of
 JMenuItem [v9]
In-Reply-To: <ZtlhyvUh0vlB6Ykavy8msXpRKsSdEUwA43Y_Z7D2Nm8=.79608f12-4ea9-4e79-9d69-3ff74d7406a0@github.com>
References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
 <ZtlhyvUh0vlB6Ykavy8msXpRKsSdEUwA43Y_Z7D2Nm8=.79608f12-4ea9-4e79-9d69-3ff74d7406a0@github.com>
Message-ID: <whKhLQRyTaNI3y-wmlcNp_wjIGrG68hCbSBnb2tfNw8=.9e0087d4-3135-4c2f-8e1c-f2afd508bb6e@github.com>

On Tue, 13 Dec 2022 16:41:42 GMT, Naveen Narayanan <duke at openjdk.org> wrote:

>> This testcase will
>> 1) Verify setAccelerator method of JMenuitem.
>> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M.
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass.
>
> Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8296275: Review comments fixed.

test/jdk/javax/swing/JMenuItem/JMenuItemSetAcceleratorTest.java line 61:

> 59:         JMenuBar bar = new JMenuBar();
> 60:         JMenu menu = new JMenu("File Menu");
> 61:         JMenuItem menuItem = new JMenuItem("File");

Suggestion:

        JMenu menu = new JMenu("File");
        JMenuItem menuItem = new JMenuItem("Menu Item");


These used to be _File_ ? _Menu Item_. I don't understand why you changed it.

-------------

PR: https://git.openjdk.org/jdk/pull/11035


From aivanov at openjdk.org  Wed Dec 14 16:04:40 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 14 Dec 2022 16:04:40 GMT
Subject: RFR: 8296275: Write a test to verify setAccelerator method of
 JMenuItem [v8]
In-Reply-To: <fcilsQC4ZtbQsh_mp_2Z18MzYLxtKOE80XM3QIZI8tQ=.b78ad19c-7934-490c-8ef4-82aac002a6ce@github.com>
References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
 <8NYHld9tBOAyBPZk00A_73beOW6lj8a_w-9lJSthLJ8=.473b501e-38f6-4306-a11e-2970dbb87ac4@github.com>
 <I4vq-CSA3tFBc78r7E_QYZIL3fcIkMJP_yHRb__x_Pc=.ad504699-fe7a-47ea-bfbb-33c240af46df@github.com>
 <fcilsQC4ZtbQsh_mp_2Z18MzYLxtKOE80XM3QIZI8tQ=.b78ad19c-7934-490c-8ef4-82aac002a6ce@github.com>
Message-ID: <7zEI6MIL9P1QlvO3f_mMVUFHxG5PUpzim05dM2ZWahs=.f9347428-a071-4fb0-a808-ecca58df8bb7@github.com>

On Tue, 13 Dec 2022 16:40:54 GMT, Naveen Narayanan <duke at openjdk.org> wrote:

> My IDE?s formatter auto wraps this line for 80 chars. After every code change & formatting, I have to manually unwrap these lines. There are 3 lines to unwrap manually.

Then disable automatic reformatting of the entire file. It won't do much good to you in the long term anyway because it may modify the lines you didn't touch and eventually introduce unnecessary noise into the changes. This is what we're seeing now.

-------------

PR: https://git.openjdk.org/jdk/pull/11035


From duke at openjdk.org  Wed Dec 14 16:36:59 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 14 Dec 2022 16:36:59 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: <BvLWFvqq3pWLZ7VlGd4dnP4W5j2WDo3jP3KXUisbgdU=.432be654-7d97-48f5-8862-5ceac9429a93@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 Can we dissociate the release of the code from the stringToColor specification update ? I not ready with [rgb implementation]( https://bugs.openjdk.org/browse/JDK-8292276) as described in this specifications.

-------------

PR: https://git.openjdk.org/jdk/pull/9825


From azvegint at openjdk.org  Wed Dec 14 16:54:53 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 14 Dec 2022 16:54:53 GMT
Subject: Integrated: 8193547: Regression automated test
 '/open/test/jdk/java/awt/Toolkit/DesktopProperties/rfe4758438.java' fails
In-Reply-To: <gf-HxIx7BCd7Im-4QlW4RtT3mKJcUVQHI-sDHK5rrYs=.e28b0d52-9e3c-4402-8964-1351ce88375b@github.com>
References: <gf-HxIx7BCd7Im-4QlW4RtT3mKJcUVQHI-sDHK5rrYs=.e28b0d52-9e3c-4402-8964-1351ce88375b@github.com>
Message-ID: <JYssbM2Dyqm2bsyb8hvFwsgGuo7J9d34odkktshtdrg=.c777118a-0b6f-4fd4-bdb6-e1f6ec3df8e8@github.com>

On Mon, 14 Nov 2022 00:03:51 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test has multiple issues:
> 
> * Test actually does nothing and passes as it is right now, but tests nothing
> * `pgrep gnome-session` may return multiple PIDs -> picking up only first one 
> * looks like jtreg does not pass GNOME_DESKTOP_SESSION_ID variable(it is deprecated, BTW), so used `XDG_CURRENT_DESKTOP` instead
> * removed leftovers from Solaris support
> * `org.gnome.settings-daemon.peripherals.mouse` is [deprecated](https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/master/data/org.gnome.settings-daemon.peripherals.gschema.xml.in#L46) and does not work on latest systems  <br> but newer `org.gnome.desktop.peripherals.mouse` works as expected<br>So the test modified to try new one and to check deprecated as a fallback
> 
> CI testing looks good.

This pull request has now been integrated.

Changeset: c05dbac3
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c05dbac3cbd8de3822191bcb5c34832c997bc4a9
Stats:     125 lines in 3 files changed: 72 ins; 22 del; 31 mod

8193547: Regression automated test '/open/test/jdk/java/awt/Toolkit/DesktopProperties/rfe4758438.java' fails

Reviewed-by: serb

-------------

PR: https://git.openjdk.org/jdk/pull/11127


From abhiscxk at openjdk.org  Wed Dec 14 17:05:31 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 14 Dec 2022 17:05:31 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native [v3]
In-Reply-To: <fY06lcX86VG3jPRLEwju0wVsWyDhB6UmyYgwIioQyhw=.f620909f-7bb0-4d09-a0ab-83360d96c6ae@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
 <fY06lcX86VG3jPRLEwju0wVsWyDhB6UmyYgwIioQyhw=.f620909f-7bb0-4d09-a0ab-83360d96c6ae@github.com>
Message-ID: <reXvSGPUq_3_5CIGsXm24xaX4CzEY2YbMM72MufI6M0=.aa65549e-f007-40f5-87ca-e343aab1bda2@github.com>

On Tue, 13 Dec 2022 18:39:00 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Subtest added for multiselection disabled
>>  - Merge
>>  - Update for folder list and test review comment update
>>  - Select all files on CTrl+A fix
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java line 567:
> 
>> 565:         fc.setLayout(new BorderLayout());
>> 566:         fc.setAlignmentX(JComponent.CENTER_ALIGNMENT);
>> 567:         fc.setMultiSelectionEnabled(true);
> 
> Please double check that this will not override what the user set

@mrserb Please have a look on latest changes.

-------------

PR: https://git.openjdk.org/jdk/pull/11627


From iris at openjdk.org  Wed Dec 14 17:18:50 2022
From: iris at openjdk.org (Iris Clark)
Date: Wed, 14 Dec 2022 17:18:50 GMT
Subject: RFR: 8298709: Fix typos in src/java.desktop/ and various test
 classes of client component
In-Reply-To: <YJvUtRHEi5wPVtlKX64yftCh1Bh7KlX5jrCtMUhNwOU=.3a6ab572-e423-4d41-b620-97f9b075e8a6@github.com>
References: <YJvUtRHEi5wPVtlKX64yftCh1Bh7KlX5jrCtMUhNwOU=.3a6ab572-e423-4d41-b620-97f9b075e8a6@github.com>
Message-ID: <4Vd_421bD0JM86O98XwJrPdE9vWqj--tVVa9Y7LfM7g=.2e4b2db8-05f1-4117-8d18-e1f87c4a5d43@github.com>

On Wed, 14 Dec 2022 06:00:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which only fixes typos? The original PR for this change is https://github.com/openjdk/jdk/pull/10029. However, that PR included changes to multiple different files in different areas of the JDK and as a result didn't see progress.
> 
> This current PR splits off those changes and includes only client area related typo fixes.

Thanks for the stutter elimination.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11661


From duke at openjdk.org  Wed Dec 14 18:33:43 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 14 Dec 2022 18:33:43 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v11]
In-Reply-To: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
Message-ID: <dEux_Es08tyTeky8S4X2wxjtvHXyDXDX5mgokgxPs0A=.381daabd-5105-40d5-b851-6b1cc37813c3@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
> 
> This is tracked in JBS as 
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
> 
> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
> 
> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)

ScientificWare has updated the pull request incrementally with one additional commit since the last revision:

  Performance improvement
  
  Performance results came from my repository I mentioned in the header.
  
      The code before this PR ran in 230ms.
      Our previous codes ran in 1 200ms to 1800 ms with String + formatted + %n$s usage.
      They ran in 350ms to 380ms with String + formatted + %s usage.
      And in 100ms to 110ms if we replace String + format with a string concatenation.
      Now the code below gives the same results in 36ms and with all our expected behaviors. Since we control notation length we
          can bypass some controls,
          directly generate the color value,
          without generate a new string,
          and reject a wrong number format without generate any exception.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10317/files
  - new: https://git.openjdk.org/jdk/pull/10317/files/b73bec53..8f65b852

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=09-10

  Stats: 67 lines in 1 file changed: 21 ins; 34 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10317.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10317/head:pull/10317

PR: https://git.openjdk.org/jdk/pull/10317


From dnguyen at openjdk.org  Wed Dec 14 19:06:06 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 14 Dec 2022 19:06:06 GMT
Subject: RFR: 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java
 fails with "No MouseReleased event on label!" [v4]
In-Reply-To: <VNBzNnAJq6Heb-7Khy6aFP9N8jmYJLcHF1kUFsqVYLo=.2f99a352-3070-4672-bfcc-785270b2d368@github.com>
References: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
 <VNBzNnAJq6Heb-7Khy6aFP9N8jmYJLcHF1kUFsqVYLo=.2f99a352-3070-4672-bfcc-785270b2d368@github.com>
Message-ID: <KdUppx17NfSoe_I3VcrQVnQ6sjHLKJlZ-07FpzAnjQc=.98faef4b-15b8-4c55-ac0b-7343c1887f8e@github.com>

On Wed, 14 Dec 2022 01:01:33 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Test was run on mac, windows, linux 50 times and passed after change
>> Before fix, test fails about once every 50 runs on linux and windows platforms
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   setLocationRelativeTo set to null

Marked as reviewed by dnguyen (Author).

-------------

PR: https://git.openjdk.org/jdk/pull/11425


From duke at openjdk.org  Wed Dec 14 20:13:52 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 14 Dec 2022 20:13:52 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v12]
In-Reply-To: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
Message-ID: <PyHPvsC1dCoNrM2H0WJxpyqFCrAd85tcM1nDQDQLTHQ=.b4b3b40a-ce82-4d78-8236-b72b63d155cf@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
> 
> This is tracked in JBS as 
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
> 
> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
> 
> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)

ScientificWare has updated the pull request incrementally with one additional commit since the last revision:

  Update imports
  
  Remove java.util.Pattern and add java.util.Map imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10317/files
  - new: https://git.openjdk.org/jdk/pull/10317/files/8f65b852..433e76f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10317.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10317/head:pull/10317

PR: https://git.openjdk.org/jdk/pull/10317


From aivanov at openjdk.org  Wed Dec 14 21:45:06 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 14 Dec 2022 21:45:06 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v2]
In-Reply-To: <KwuZH3CQlUiklf-h_yzbB1RzoXACnqXNjWX4RZjGCI0=.5651d65a-391c-4588-9037-4d78d2ae357e@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
 <KwuZH3CQlUiklf-h_yzbB1RzoXACnqXNjWX4RZjGCI0=.5651d65a-391c-4588-9037-4d78d2ae357e@github.com>
Message-ID: <YhS-pkykLDaNGlAiB-YDNyUkVYk-GceGszx7zvt6_aQ=.ad2efd92-6c58-4c45-9a54-6dad14eb42b3@github.com>

On Mon, 12 Dec 2022 18:27:24 GMT, SWinxy <duke at openjdk.org> wrote:

>> 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.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sync with CSR
>   
>   Only difference is that I added an Oxford comma

This change cause 23 test cases to fail across the platforms:

* `sanity/client/SwingSet/src/SwingSet2DemoTest.java`;
* `javax/swing/GraphicsConfigNotifier/StalePreferredSize.java`;
* two closed tests.

**One JCK test** fails; from a quick look, it's because the font is now uninstalled where it wasn't previously.

-------------

PR: https://git.openjdk.org/jdk/pull/10565


From achung at openjdk.org  Wed Dec 14 22:13:09 2022
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 14 Dec 2022 22:13:09 GMT
Subject: Integrated: 8297296:
 java/awt/Mouse/EnterExitEvents/DragWindowTest.java fails with
 "No MouseReleased event on label!"
In-Reply-To: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
References: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
Message-ID: <yB4pYuMMh2lq2TaBxSeFJxshrk1aLCtXfUgUqswc7eY=.076b24d7-1f89-422a-b81d-ff8cd520f1d0@github.com>

On Tue, 29 Nov 2022 23:10:56 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Test was run on mac, windows, linux 50 times and passed after change
> Before fix, test fails about once every 50 runs on linux and windows platforms

This pull request has now been integrated.

Changeset: 0ed6d0b4
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ed6d0b456e58e4122b97c3d12faabada0d8c530
Stats:     21 lines in 2 files changed: 14 ins; 1 del; 6 mod

8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java fails with "No MouseReleased event on label!"

Reviewed-by: psadhukhan, dnguyen

-------------

PR: https://git.openjdk.org/jdk/pull/11425


From dnguyen at openjdk.org  Wed Dec 14 23:47:55 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 14 Dec 2022 23:47:55 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop
 10
Message-ID: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>

Open l10n drop
All tests passed

-------------

Commit messages:
 - open l10n drop

Changes: https://git.openjdk.org/jdk20/pull/35/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298133
  Stats: 1177 lines in 110 files changed: 783 ins; 207 del; 187 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35


From achung at openjdk.org  Thu Dec 15 00:07:04 2022
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 15 Dec 2022 00:07:04 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <Sfe4uUeYHsI1HUSpkDyn-dbJiiReR3yQCyzrBo1H_7k=.52ee8dbe-28b5-4b59-a4d9-3b2dda6ac0b8@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

looks good

-------------

Marked as reviewed by achung (Committer).

PR: https://git.openjdk.org/jdk20/pull/35


From duke at openjdk.org  Thu Dec 15 01:01:05 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 15 Dec 2022 01:01:05 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188:

> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
> 187: 
> 188: main.plugin.category=\u7C7B\u522B 

As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From duke at openjdk.org  Thu Dec 15 01:07:14 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 15 Dec 2022 01:07:14 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26:

> 24: #
> 25: 
> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten

`jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now?

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From duke at openjdk.org  Thu Dec 15 01:16:13 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 15 Dec 2022 01:16:13 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>
Message-ID: <gt3H8LBSGCmyftDD3Oyzx_BXZgZzvQtJq4pDIWFQnQY=.fbc90067-e182-490f-85e4-f302ae7cfd64@github.com>

On Thu, 15 Dec 2022 00:58:06 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188:
> 
>> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
>> 187: 
>> 188: main.plugin.category=\u7C7B\u522B 
> 
> As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes.

Additionally, there were changes made to plugins.properties in October that were not translated in the translation drop

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Thu Dec 15 02:26:12 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 02:26:12 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>
Message-ID: <QB_rvT43I38Ksdn8YuHCvzPrTNTua2287iebkdsNakM=.0656bf7b-2eed-4858-ad71-a5ffecdad65b@github.com>

On Thu, 15 Dec 2022 01:04:12 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26:
> 
>> 24: #
>> 25: 
>> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten
> 
> `jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now?

I see the date of [that PR](https://github.com/openjdk/jdk/pull/8772) as well. Looks like it was integrated on May 19.

I'm contacting Kate Gavin to determine why some translations seem to sometimes be delayed. As you mentioned in the other comment, there are a few instances where text was added between the last drop & this drop, but weren't translated.

And as you showed here, this should have been translated in the last drop rather than this one, but showed up here. I need a response from Kate to clarify when these translations are generated.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Thu Dec 15 02:45:48 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 02:45:48 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Removed trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/39511b7a..54d2ec5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35


From tr at openjdk.org  Thu Dec 15 04:54:47 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 15 Dec 2022 04:54:47 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v2]
In-Reply-To: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
Message-ID: <IiZ0wMzN3QdnfcDoQPNydWR6A3-KAH2H62TgD5yjCSg=.f7f8f35f-23df-49f3-97b8-05ef73654f33@github.com>

> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11104/files
  - new: https://git.openjdk.org/jdk/pull/11104/files/ede337d1..bd951a1d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11104&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11104&range=00-01

  Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11104.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11104/head:pull/11104

PR: https://git.openjdk.org/jdk/pull/11104


From tr at openjdk.org  Thu Dec 15 04:57:06 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 15 Dec 2022 04:57:06 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
Message-ID: <HHzGD_XbS84khYzfak9P6B7Q2KL-QhrHauae5sk8jNI=.a60231dd-3fde-4677-9975-c3269074f0e9@github.com>

On Fri, 11 Nov 2022 08:18:19 GMT, Tejesh R <tr at openjdk.org> wrote:

> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.

Based on the analysis and test runs, I have added a null check to return null when _ImageIcon_ is null and added to the map. The test is made as headful since the occurrence of issue seems to be dependent on machine and is unpredictable. Headful test didn't cause any issue after multiple runs and iterations.

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From jdv at openjdk.org  Thu Dec 15 06:21:06 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 15 Dec 2022 06:21:06 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native [v3]
In-Reply-To: <reXvSGPUq_3_5CIGsXm24xaX4CzEY2YbMM72MufI6M0=.aa65549e-f007-40f5-87ca-e343aab1bda2@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
 <fY06lcX86VG3jPRLEwju0wVsWyDhB6UmyYgwIioQyhw=.f620909f-7bb0-4d09-a0ab-83360d96c6ae@github.com>
 <reXvSGPUq_3_5CIGsXm24xaX4CzEY2YbMM72MufI6M0=.aa65549e-f007-40f5-87ca-e343aab1bda2@github.com>
Message-ID: <p-5GEyBDhaOXv27nOQxgV7iP2F_lBmuA_GbLxUWFfd8=.b852b18d-78c7-4799-9d02-10340410a6fa@github.com>

On Wed, 14 Dec 2022 17:02:24 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java line 567:
>> 
>>> 565:         fc.setLayout(new BorderLayout());
>>> 566:         fc.setAlignmentX(JComponent.CENTER_ALIGNMENT);
>>> 567:         fc.setMultiSelectionEnabled(true);
>> 
>> Please double check that this will not override what the user set
>
> @mrserb Please have a look on latest changes.

Its better to add a comment which mentions why we enable MultiSelection by default in GTK LAF compared to other LAF's, since we are trying to match platform behaviour.

-------------

PR: https://git.openjdk.org/jdk/pull/11627


From dholmes at openjdk.org  Thu Dec 15 06:47:13 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Dec 2022 06:47:13 GMT
Subject: RFR: 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java
 fails with "No MouseReleased event on label!" [v3]
In-Reply-To: <nYOGJoz39rH7SNBtAo3h2w2hSCcpyt0Yb0SUqsHzfQ4=.f9464d80-4f73-46f6-9dc7-5adba282d350@github.com>
References: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com>
 <wk0pRR6VBbTKg7aen8zWLYa9KWMEitnkmSkAuoctO9s=.b7ffd66d-a3b3-4fe5-8785-6eb4ab009d84@github.com>
 <nYOGJoz39rH7SNBtAo3h2w2hSCcpyt0Yb0SUqsHzfQ4=.f9464d80-4f73-46f6-9dc7-5adba282d350@github.com>
Message-ID: <ndwbkjlNSVozj_5C86eOzdRZnUCpLJL5UrkLzJFqcMA=.de40298a-a97f-48bd-bafd-3fa4e8f3437f@github.com>

On Tue, 6 Dec 2022 22:09:04 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8297296
>>  - fixed imports, changed robot autodelay and added delay after creating gui
>>  - changed robot autodelay to 250
>
> After pulling newest changes test is failing again... looking into issue

@alisenchung this test continues to fail in our CI in tier4. I will file a new bug.

-------------

PR: https://git.openjdk.org/jdk/pull/11425


From abhiscxk at openjdk.org  Thu Dec 15 06:47:33 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 15 Dec 2022 06:47:33 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native [v4]
In-Reply-To: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
Message-ID: <xOcpuZQvcZc3HECZZCAIHWZd5zi0KqbvAMLQaLILG7E=.fe7ca755-acac-43d6-8946-1e8618105192@github.com>

> It is not possible to select all files on press of Ctrl+A in JFileChooser for GTK LAF where as all folders can be selected. 
> In native side on press of Ctrl+A, able to select all files as well as folders.
> 
> Proposed fix is to enable `multiselection `property by default for JFileChooser in GTK LAF to mimic native side behavior.
> 
> An automated test case is implemented and tested in CI. CI job links are attached in JBS.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Review comment update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11627/files
  - new: https://git.openjdk.org/jdk/pull/11627/files/52fa7cba..c2053565

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11627&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11627&range=02-03

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11627.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11627/head:pull/11627

PR: https://git.openjdk.org/jdk/pull/11627


From abhiscxk at openjdk.org  Thu Dec 15 06:47:34 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 15 Dec 2022 06:47:34 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native [v4]
In-Reply-To: <p-5GEyBDhaOXv27nOQxgV7iP2F_lBmuA_GbLxUWFfd8=.b852b18d-78c7-4799-9d02-10340410a6fa@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
 <fY06lcX86VG3jPRLEwju0wVsWyDhB6UmyYgwIioQyhw=.f620909f-7bb0-4d09-a0ab-83360d96c6ae@github.com>
 <reXvSGPUq_3_5CIGsXm24xaX4CzEY2YbMM72MufI6M0=.aa65549e-f007-40f5-87ca-e343aab1bda2@github.com>
 <p-5GEyBDhaOXv27nOQxgV7iP2F_lBmuA_GbLxUWFfd8=.b852b18d-78c7-4799-9d02-10340410a6fa@github.com>
Message-ID: <Zj3oCcBbyiaRDSt7tqbuTbrNmbLQzmF3JqESXEp8A7g=.7704d1ad-0377-46a4-a6c4-c8a7d520eefa@github.com>

On Thu, 15 Dec 2022 06:18:48 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> @mrserb Please have a look on latest changes.
>
> Its better to add a comment which mentions why we enable MultiSelection by default in GTK LAF compared to other LAF's, since we are trying to match platform behaviour.

Comment added.

-------------

PR: https://git.openjdk.org/jdk/pull/11627


From kizune at openjdk.org  Thu Dec 15 07:29:32 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 15 Dec 2022 07:29:32 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v2]
In-Reply-To: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
Message-ID: <7lRrGCopXc6TOhPxpp4O7YP5L_z09DHG6Pd0Tj8kjgg=.c2177cce-78d9-40fd-8073-36b2eff352da@github.com>

> Set the text caret to be visible but not blinking on the non-editable text area. Fix the regression test that becames unstable after the change.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Fixed MultiSelectionText so it is now stable on Linux
  Removed both fixed tests from ProblemList

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/21/files
  - new: https://git.openjdk.org/jdk20/pull/21/files/9463a0bb..70da8f6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=21&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=21&range=00-01

  Stats: 145 lines in 2 files changed: 29 ins; 42 del; 74 mod
  Patch: https://git.openjdk.org/jdk20/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/21/head:pull/21

PR: https://git.openjdk.org/jdk20/pull/21


From kizune at openjdk.org  Thu Dec 15 08:04:05 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 15 Dec 2022 08:04:05 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v2]
In-Reply-To: <X_sesedc1cr1kETxwY_v69GbE05lCcfGQqEbqq_pEPM=.eea15861-d89d-4c41-bc1d-541e009ce668@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <-HhHQfNxcv4FE-h0n9X71n7R1-zRmQeEOC5D6obxaiE=.02362c0a-d84a-4576-b555-3e9c1be9fe02@github.com>
 <yC-Fov5npCizRMQoj_j9KRbxKJe10dj4zWPxzrHJOsU=.64367fa6-7687-4ebf-bab2-a4c8872ef968@github.com>
 <X_sesedc1cr1kETxwY_v69GbE05lCcfGQqEbqq_pEPM=.eea15861-d89d-4c41-bc1d-541e009ce668@github.com>
Message-ID: <Kecvn-SszPGjeEbkAoeBdm5GcqkytBcbPIaoqIA3aMQ=.1a1cbebe-35b7-488b-b0a8-29a7af21a975@github.com>

On Tue, 13 Dec 2022 08:27:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> Does it need similar change in test/jdk/javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java as well? Since the logic is changed, I will still request to make this test stable on windows (now that we are not using screen capture) and then deproblemlist
>> 
>> I haven't tested the MultiSelectionTest but since it is problemlisted on Linux similar change might make it more stable. As of this test - since you are the owner of JDK-8194048 i thought that you can review my changes and deproblemlist the test if it is stable on the rest of the platforms and if changes make sense. I definitely do not want to steal your thunder. As of MultiSelectionTest i can take care of it either here or in the original bug that is noted in ProblemList.txt since my fix does not affect it.
>
> I guess anyway one is supposed to do a CI job for the fix and test the regression test on all platforms, so if the modified test is problemlisted it will not be tested in CI job, so it's better to deproblemlist and test...
> You can do /issue add of that problemlisted bug (it just happens to be in my name for the time being, nothing stopping you assigning to you since you did all the hard work)

I have fixed the second test and removed both of them from the problem list.

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From mbaesken at openjdk.org  Thu Dec 15 08:14:11 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 15 Dec 2022 08:14:11 GMT
Subject: RFR: JDK-8298093: improve cleanup and error handling of
 awt_parseColorModel in awt_parseImage.c [v3]
In-Reply-To: <2Dhk_nsd_PNixhUjUswA6uxE05Yn2hCHHLZX94DgDXA=.7f4c436c-0ab2-4037-a600-14c2b23ef830@github.com>
References: <LJXA0GoYlzD_v4Gb9N0ytaim25_su2y8hAyWhx0hGKI=.5087cce4-07f1-446c-a389-d65334315f73@github.com>
 <2Dhk_nsd_PNixhUjUswA6uxE05Yn2hCHHLZX94DgDXA=.7f4c436c-0ab2-4037-a600-14c2b23ef830@github.com>
Message-ID: <fBtVO_w1KpT8DtHWlOwvlEYYESq0XSEoHoymca8Z308=.01f73674-db43-4d97-b2c6-f18ee7aca362@github.com>

On Wed, 7 Dec 2022 08:54:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The cleanup and error handling in function awt_parseColorModel in awt_parseImage.c could be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small adjustment

Hi Christoph and Lutz, thanks for the reviews !

-------------

PR: https://git.openjdk.org/jdk/pull/11508


From mbaesken at openjdk.org  Thu Dec 15 08:14:12 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 15 Dec 2022 08:14:12 GMT
Subject: Integrated: JDK-8298093: improve cleanup and error handling of
 awt_parseColorModel in awt_parseImage.c
In-Reply-To: <LJXA0GoYlzD_v4Gb9N0ytaim25_su2y8hAyWhx0hGKI=.5087cce4-07f1-446c-a389-d65334315f73@github.com>
References: <LJXA0GoYlzD_v4Gb9N0ytaim25_su2y8hAyWhx0hGKI=.5087cce4-07f1-446c-a389-d65334315f73@github.com>
Message-ID: <t_7M3mHSF74DmeaIBtFCDwbzO5TYq8T_G9zVa9VfcG0=.a5cb7731-3e69-4f00-ac16-41d3cd2397cb@github.com>

On Mon, 5 Dec 2022 09:51:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The cleanup and error handling in function awt_parseColorModel in awt_parseImage.c could be improved.

This pull request has now been integrated.

Changeset: 98fa48c3
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98fa48c330941efe6588a907b383802a11ed0e6b
Stats:     22 lines in 1 file changed: 14 ins; 1 del; 7 mod

8298093: improve cleanup and error handling of awt_parseColorModel in awt_parseImage.c

Reviewed-by: lucy, clanger

-------------

PR: https://git.openjdk.org/jdk/pull/11508


From serb at openjdk.org  Thu Dec 15 10:00:11 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 15 Dec 2022 10:00:11 GMT
Subject: RFR: 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame
 throws a NPE. [v4]
In-Reply-To: <7P2I0AigbPWt_LkGjlZs9N6YlbCgMUH-sWgj0IurRTo=.9035162c-e492-4b21-b346-5f48fa02123a@github.com>
References: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
 <7P2I0AigbPWt_LkGjlZs9N6YlbCgMUH-sWgj0IurRTo=.9035162c-e492-4b21-b346-5f48fa02123a@github.com>
Message-ID: <T0RE-IJ_5Yz6mKLDLE5A8PbXr4NQu2HBy0ETMVBsCcY=.e4a86cb4-8128-4ffb-8f98-36c904bea046@github.com>

On Wed, 14 Dec 2022 10:58:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In Swingset2 JInternalFrame demo, focusing on any internalframes and pressing Ctrl+F7 and then any of up/down/left/arrow key to move the internal frames results in NPE in NimbusL&F.
>> It is because `JComponent.processKeyBinding() `calls `SwingUtilities.notifyAction` which calls `BasicDesktopPaneUI.actionPerformed` where it gets `Desktop.minOnScreenInsets` property to get the Insets and then uses insets.top/bottom/left/right value to move the internalframe but this property is not defined for Nimbus so deferencing Insets object results in NPE.
>> 
>> Fix is added to create a 0 insets incase some L&F do not define` Desktop.minOnScreenInsets` property.
>> No regression test is added as it can be easily checked by SwingSet2 JInternalFrame demo.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11605


From serb at openjdk.org  Thu Dec 15 10:54:09 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 15 Dec 2022 10:54:09 GMT
Subject: [jdk20] RFR: 8298083: The
 "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working
In-Reply-To: <syGWaa_jjCSDyFGEoDLQhPyBzYs7dWfzjIff_xqG_8I=.ab3eb83a-d918-4c54-b04f-96c3ba0a45db@github.com>
References: <-w3q4N0YsCvrK9ano6m4zrujjksesyS1gg8v8gUSmmw=.ca5e26a5-1da9-4f39-9b7c-e7a08e6407d5@github.com>
 <syGWaa_jjCSDyFGEoDLQhPyBzYs7dWfzjIff_xqG_8I=.ab3eb83a-d918-4c54-b04f-96c3ba0a45db@github.com>
Message-ID: <EeVfVj8wtRUTdGF4E86clwmRNHcqYZ-d-h8Sdr7aaKs=.34cd4c1f-be3f-4cf3-9d03-785ddd2a9da7@github.com>

On Wed, 14 Dec 2022 10:57:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I guess for clean backport doesn't need a reviewer.

@prrace can you please confirm that, so I can integrate

-------------

PR: https://git.openjdk.org/jdk20/pull/17


From duke at openjdk.org  Thu Dec 15 11:41:12 2022
From: duke at openjdk.org (duke)
Date: Thu, 15 Dec 2022 11:41:12 GMT
Subject: Withdrawn: 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: <k8SI8HkvTRK2PUwvVK4VNd4gTgjVyKhrDT6zJwpmWMI=.0842d7a7-e7de-46fd-aa88-1c5b498844a1@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.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10446


From dnguyen at openjdk.org  Thu Dec 15 12:06:10 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 12:06:10 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <gt3H8LBSGCmyftDD3Oyzx_BXZgZzvQtJq4pDIWFQnQY=.fbc90067-e182-490f-85e4-f302ae7cfd64@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>
 <gt3H8LBSGCmyftDD3Oyzx_BXZgZzvQtJq4pDIWFQnQY=.fbc90067-e182-490f-85e4-f302ae7cfd64@github.com>
Message-ID: <iBTNjKoPxhwIA8LhLguE4u7j67wbLJolkZ4jx-1uz5g=.be6291cd-2fd4-403a-bb37-1f88479f967e@github.com>

On Thu, 15 Dec 2022 01:13:32 GMT, Justin Lu <duke at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188:
>> 
>>> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
>>> 187: 
>>> 188: main.plugin.category=\u7C7B\u522B 
>> 
>> As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes.
>
> Additionally, there were changes made to plugins.properties in October that were not translated in the translation drop

In our discussion, Kate mentioned that some languages are double byte, so this extra space may be correct but she hasn't looked in detail yet. I looked through all of the changes and these two instances of trailing whitespaces were the only two. I removed the extra spaces to reduce the changes as it seems useless due to the previous version not having the whitespace.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From azvegint at openjdk.org  Thu Dec 15 12:45:47 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 15 Dec 2022 12:45:47 GMT
Subject: RFR: 8298859: ProblemList
 java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all
Message-ID: <lSkA2Yfq_vnEMgTzAslkL41TxxCYwDVNd11X51jeOIg=.5fa82e1c-5857-4d9c-9f5e-44b1be6d615e@github.com>

java/awt/Mouse/EnterExitEvents/DragWindowTest.java fails again in the CI

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.org/jdk/pull/11691/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11691&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298859
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11691.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11691/head:pull/11691

PR: https://git.openjdk.org/jdk/pull/11691


From jdv at openjdk.org  Thu Dec 15 16:35:07 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 15 Dec 2022 16:35:07 GMT
Subject: RFR: 8298859: ProblemList
 java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all
In-Reply-To: <lSkA2Yfq_vnEMgTzAslkL41TxxCYwDVNd11X51jeOIg=.5fa82e1c-5857-4d9c-9f5e-44b1be6d615e@github.com>
References: <lSkA2Yfq_vnEMgTzAslkL41TxxCYwDVNd11X51jeOIg=.5fa82e1c-5857-4d9c-9f5e-44b1be6d615e@github.com>
Message-ID: <Tv1fWysZCNDK4nll836xaWv2A_MIaTSk8FlCYBkPjAU=.b4239e76-9910-4b16-a19b-5e95c9e9d2be@github.com>

On Thu, 15 Dec 2022 12:38:17 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> java/awt/Mouse/EnterExitEvents/DragWindowTest.java fails again in the CI

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11691


From duke at openjdk.org  Thu Dec 15 16:35:38 2022
From: duke at openjdk.org (Naveen Narayanan)
Date: Thu, 15 Dec 2022 16:35:38 GMT
Subject: RFR: 8296275: Write a test to verify setAccelerator method of
 JMenuItem [v10]
In-Reply-To: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
Message-ID: <UddJ-Ik7hDA1XvhSD3dKKKJCADNhuvsBM9zbicN23wc=.ab7a6ac7-02bb-4fd2-97fd-b3d92806a691@github.com>

> This testcase will
> 1) Verify setAccelerator method of JMenuitem.
> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M.
> 
> Testing:
> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass.

Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision:

  8296275: Review comments fixed.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11035/files
  - new: https://git.openjdk.org/jdk/pull/11035/files/fe62a7e3..0fc8e25e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11035&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11035&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11035.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11035/head:pull/11035

PR: https://git.openjdk.org/jdk/pull/11035


From duke at openjdk.org  Thu Dec 15 16:40:06 2022
From: duke at openjdk.org (Naveen Narayanan)
Date: Thu, 15 Dec 2022 16:40:06 GMT
Subject: RFR: 8296275: Write a test to verify setAccelerator method of
 JMenuItem [v8]
In-Reply-To: <7zEI6MIL9P1QlvO3f_mMVUFHxG5PUpzim05dM2ZWahs=.f9347428-a071-4fb0-a808-ecca58df8bb7@github.com>
References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
 <8NYHld9tBOAyBPZk00A_73beOW6lj8a_w-9lJSthLJ8=.473b501e-38f6-4306-a11e-2970dbb87ac4@github.com>
 <I4vq-CSA3tFBc78r7E_QYZIL3fcIkMJP_yHRb__x_Pc=.ad504699-fe7a-47ea-bfbb-33c240af46df@github.com>
 <fcilsQC4ZtbQsh_mp_2Z18MzYLxtKOE80XM3QIZI8tQ=.b78ad19c-7934-490c-8ef4-82aac002a6ce@github.com>
 <7zEI6MIL9P1QlvO3f_mMVUFHxG5PUpzim05dM2ZWahs=.f9347428-a071-4fb0-a808-ecca58df8bb7@github.com>
Message-ID: <srrmDf35Rb1rD17HaTpzwKf_ZeqaP6q78HZvc_8Xod8=.63dc60d6-b268-4f15-a32a-2d5987d49a25@github.com>

On Wed, 14 Dec 2022 16:00:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> My IDE?s formatter auto wraps this line for 80 chars.
>> After every code change & formatting, I have to manually unwrap these lines.
>> There are 3 lines to  unwrap manually.
>
>> My IDE?s formatter auto wraps this line for 80 chars. After every code change & formatting, I have to manually unwrap these lines. There are 3 lines to unwrap manually.
> 
> Then disable automatic reformatting of the entire file. It won't do much good to you in the long term anyway because it may modify the lines you didn't touch and eventually introduce unnecessary noise into the changes. This is what we're seeing now.

The OpenJDK code style formatter takes care of? many aspects like Indentation, Parentheses positions, Whitespaces, Blank lines etc.
Someway It assists to prevent few of the jcheck failures. 
May be lessens a lot of manual formatting as well.

-------------

PR: https://git.openjdk.org/jdk/pull/11035


From azvegint at openjdk.org  Thu Dec 15 16:42:34 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 15 Dec 2022 16:42:34 GMT
Subject: RFR: 8298859: ProblemList
 java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all [v2]
In-Reply-To: <lSkA2Yfq_vnEMgTzAslkL41TxxCYwDVNd11X51jeOIg=.5fa82e1c-5857-4d9c-9f5e-44b1be6d615e@github.com>
References: <lSkA2Yfq_vnEMgTzAslkL41TxxCYwDVNd11X51jeOIg=.5fa82e1c-5857-4d9c-9f5e-44b1be6d615e@github.com>
Message-ID: <wBKjS3KZ1F1F95sdCCOI6Q1itiknZjOu6ipxGWf0ssE=.515840c2-ac77-4c7b-bbe9-69d8e7c500e7@github.com>

> java/awt/Mouse/EnterExitEvents/DragWindowTest.java fails again in the CI

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  fix bug id

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11691/files
  - new: https://git.openjdk.org/jdk/pull/11691/files/9e9828b3..4e8c1676

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11691&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11691&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11691.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11691/head:pull/11691

PR: https://git.openjdk.org/jdk/pull/11691


From azvegint at openjdk.org  Thu Dec 15 16:46:09 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 15 Dec 2022 16:46:09 GMT
Subject: Integrated: 8298859: ProblemList
 java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all
In-Reply-To: <lSkA2Yfq_vnEMgTzAslkL41TxxCYwDVNd11X51jeOIg=.5fa82e1c-5857-4d9c-9f5e-44b1be6d615e@github.com>
References: <lSkA2Yfq_vnEMgTzAslkL41TxxCYwDVNd11X51jeOIg=.5fa82e1c-5857-4d9c-9f5e-44b1be6d615e@github.com>
Message-ID: <nB3C2PuP0IhEMl7olZ121v26dnq8gLOVWpQn_zbiMhY=.b4e590bc-16dc-424a-b05e-81e395d6b7c5@github.com>

On Thu, 15 Dec 2022 12:38:17 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> java/awt/Mouse/EnterExitEvents/DragWindowTest.java fails again in the CI

This pull request has now been integrated.

Changeset: 0288210f
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0288210f25e3d56870d1aa58ad076c97aad1c232
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8298859: ProblemList java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all

Reviewed-by: jdv

-------------

PR: https://git.openjdk.org/jdk/pull/11691


From kizune at openjdk.org  Thu Dec 15 17:46:13 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 15 Dec 2022 17:46:13 GMT
Subject: Withdrawn: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus
In-Reply-To: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
References: <t58bziOa5237Z439JrX89u91y3ypVd4UNDiM4eUeGBo=.81a2f655-33dc-4350-869d-ca07d3a06ee9@github.com>
Message-ID: <FvDnHXPktm1qVW896VMHwMRDJgr4BJp_9ZAGBz9jJII=.2c47b1a7-64da-4ff1-9079-4b3b86901c5c@github.com>

On Tue, 29 Nov 2022 07:30:32 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Set the text caret to be visible but not blinking on the non-editable text area.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11408


From kizune at openjdk.org  Thu Dec 15 17:47:06 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 15 Dec 2022 17:47:06 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v2]
In-Reply-To: <vxVF6cCwFSs8LKdl10LoEL8vOlS0rXFDf5OmTQOHxKs=.7e5a1c9c-1f24-4e82-9b5e-be7c5ea223d7@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <vxVF6cCwFSs8LKdl10LoEL8vOlS0rXFDf5OmTQOHxKs=.7e5a1c9c-1f24-4e82-9b5e-be7c5ea223d7@github.com>
Message-ID: <dcUIalTObWV9-PdfG3Ai-i_nRWMZjV9BIjQQm8uODns=.e4c6875b-9e4d-42c3-97b3-f41ed2c5a51b@github.com>

On Tue, 13 Dec 2022 12:52:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> It would be better to verify the updated test passes on Windows. If so, remove it from the problem list.

Done and done.

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From dnguyen at openjdk.org  Thu Dec 15 18:54:09 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 18:54:09 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <QB_rvT43I38Ksdn8YuHCvzPrTNTua2287iebkdsNakM=.0656bf7b-2eed-4858-ad71-a5ffecdad65b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>
 <QB_rvT43I38Ksdn8YuHCvzPrTNTua2287iebkdsNakM=.0656bf7b-2eed-4858-ad71-a5ffecdad65b@github.com>
Message-ID: <YYf976GjBqhqZZlsCUy6oz6Tx_KLFXz7iCsU86GAKSM=.5bd572ce-1523-4b69-a17a-1a2b70c896f0@github.com>

On Thu, 15 Dec 2022 02:23:34 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26:
>> 
>>> 24: #
>>> 25: 
>>> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten
>> 
>> `jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now?
>
> I see the date of [that PR](https://github.com/openjdk/jdk/pull/8772) as well. Looks like it was integrated on May 19.
> 
> I'm contacting Kate Gavin to determine why some translations seem to sometimes be delayed. As you mentioned in the other comment, there are a few instances where text was added between the last drop & this drop, but weren't translated.
> 
> And as you showed here, this should have been translated in the last drop rather than this one, but showed up here. I need a response from Kate to clarify when these translations are generated.

I conversed with Kate and the problem seems to come from the extraction process. We went through the source files that were sent for translation as a zip, and some changes would be missing. We confirmed that everything in this zip was translated, so the issue was in the extraction to create the source files to send for translation.  

For example, the plugin.properties missing text didn't show in the source.zip but showed on my forked repo used in the extraction. I re-ran the extraction script but still did not see the new text in the generated zip.

Kate thinks a similar issue occurred in the previous drop and this jmod.properties change wasn't captured in the extraction process. So now it is captured in this drop and translated here. It could be syncing or branch issues, but while working with Kate, I learned to better see what files are pulled from the extraction script. So for future drops, I can better check to make sure changes I expect to be translated will appear.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From naoto at openjdk.org  Thu Dec 15 18:58:09 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 18:58:09 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>
Message-ID: <bxawN0XrRjf_HwocX3SD03ihnIENaEb6eqpuOx5KjwY=.265f097f-de75-474e-b835-ef067cb7afde@github.com>

On Thu, 15 Dec 2022 02:45:48 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed trailing whitespace

Changes requested by naoto (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties line 217:

> 215: javac.msg.usage.nonstandard.footer=Diese zus\u00E4tzlichen Optionen k\u00F6nnen jederzeit ohne vorherige Ank\u00FCndigung ge\u00E4ndert werden.
> 216: 
> 217: javac.msg.bug=Im Compiler ({0}) ist eine Ausnahme aufgetreten. Erstellen Sie auf der Java-Seite zum Melden von Bugs (http://bugreport.java.com) einen Bugbericht, nachdem Sie die Bugdatenbank (http://bugs.java.com) auf Duplikate gepr\u00FCft haben. Geben Sie in Ihrem Bericht Ihr Programm, die folgende Diagnose und die Parameter an, die Sie dem Java-Compiler \u00FCbergeben haben. Vielen Dank.

How come `https` turned into `http`? I see these happening all over the places other than this location as well.

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_de.properties line 134:

> 132: public.api.replacement.column.header=Vorgeschlagene Ersetzung
> 133: artifact.not.found=nicht gefunden
> 134: jdeps.wiki.url=https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

This seems to change backward. `openjdk.java.net` has changed to `openjdk.org` Same issues are observed in other locales.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Thu Dec 15 20:43:42 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 20:43:42 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Fix https and changed URL back

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/54d2ec5f..09140a05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=01-02

  Stats: 15 lines in 15 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Thu Dec 15 20:55:08 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 20:55:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <bxawN0XrRjf_HwocX3SD03ihnIENaEb6eqpuOx5KjwY=.265f097f-de75-474e-b835-ef067cb7afde@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>
 <bxawN0XrRjf_HwocX3SD03ihnIENaEb6eqpuOx5KjwY=.265f097f-de75-474e-b835-ef067cb7afde@github.com>
Message-ID: <Wq-WW8kfFkrS08vlPmgmD_ApiBVdboI6hEoARHr72zk=.7d3ca55c-db6e-4734-8724-75cb5d0a2f82@github.com>

On Thu, 15 Dec 2022 18:52:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed trailing whitespace
>
> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_de.properties line 134:
> 
>> 132: public.api.replacement.column.header=Vorgeschlagene Ersetzung
>> 133: artifact.not.found=nicht gefunden
>> 134: jdeps.wiki.url=https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
> 
> This seems to change backward. `openjdk.java.net` has changed to `openjdk.org` Same issues are observed in other locales.

This and the https->http differences seem to also be a part of the extraction issue. The resource generation files show "http" and "java.net", but I see differently on my local repo that I used for the extraction.

I will run a new extraction job on a fresh repo/branch to see if this issue is reproducible and narrow down the source of the extraction issue.

As discussed with Naoto, these are small edits, and they have been addressed in the latest PR.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From naoto at openjdk.org  Thu Dec 15 21:16:07 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 21:16:07 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
Message-ID: <pE7z2olK_Ec3qJO1w1KbXo55BIsYVK7Cu1_MPUMUmkg=.48f8c2f4-0b68-47ba-a46f-d8cb8d17d481@github.com>

On Thu, 15 Dec 2022 20:43:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix https and changed URL back

Thanks for the update, Damon. Looks good for this drop.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Thu Dec 15 23:01:35 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 23:01:35 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert double quote as well

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/09140a05..57c42206

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=02-03

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35


From naoto at openjdk.org  Thu Dec 15 23:12:06 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 23:12:06 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <orIjM2vHBgrTyKBL5fjG9TX1ZI8AuJ48PGF2nqlSip0=.7f9e9cb5-0cfa-4985-8bff-aa5ead6f1c6d@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

Marked as reviewed by naoto (Reviewer).

src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_de.properties line 26:

> 24: #
> 25: 
> 26: main.usage=Verwendung: jdeprscan [Optionen] '{dir|jar|class}' ...\n\nOptionen:\n        --class-path PATH\n        --for-removal\n        --full-version\n  -? -h --help\n  -l    --list\n        --release {0}\n  -v    --verbose\n        --version

Good catch!

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From prr at openjdk.org  Thu Dec 15 23:16:04 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Dec 2022 23:16:04 GMT
Subject: [jdk20] RFR: 8298083: The
 "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working
In-Reply-To: <-w3q4N0YsCvrK9ano6m4zrujjksesyS1gg8v8gUSmmw=.ca5e26a5-1da9-4f39-9b7c-e7a08e6407d5@github.com>
References: <-w3q4N0YsCvrK9ano6m4zrujjksesyS1gg8v8gUSmmw=.ca5e26a5-1da9-4f39-9b7c-e7a08e6407d5@github.com>
Message-ID: <438kOm_8IppDv91LG-YSyIoYcAv8sMHt0Tc7ZFgQBRw=.f8f89d7d-7454-4d41-b546-ff6145b8c6c9@github.com>

On Mon, 12 Dec 2022 09:37:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit [5540a8c5](https://github.com/openjdk/jdk/commit/5540a8c5b7160ab5c67bb84631e3de54fa5aeceb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> The commit being backported was authored by Sergey Bylokhov on 8 Dec 2022 and was reviewed by Prasanta Sadhukhan.
> Thanks!

It requires reviewer approval
"No reviewer for a clean backport" is allowed for update release backports,
which do however require the UR maintainer to approve,
This isn't an update release. It is a feature release and there's no maintainer/lead approval required before RDP2.
This came up once before and skara marking the PR as "ready" is a bug.
Actually filing a skara bug hasn't happened but I am assured it will be done.

-------------

PR: https://git.openjdk.org/jdk20/pull/17


From almatvee at openjdk.org  Thu Dec 15 23:17:12 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 15 Dec 2022 23:17:12 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
Message-ID: <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>

On Thu, 15 Dec 2022 20:43:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix https and changed URL back

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82:

> 80: 
> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0})
> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt

error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""?

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_ja.properties line 82:

> 80: 
> 81: error.foreign-app-image=\u30A8\u30E9\u30FC: app-image\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA({0})\u306B.jpackage.xml\u30D5\u30A1\u30A4\u30EB\u304C\u3042\u308A\u307E\u305B\u3093
> 82: error.invalid-app-image=\u30A8\u30E9\u30FC: app-image\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA({0})\u306F\u5225\u306Ejpackage\u30D0\u30FC\u30B8\u30E7\u30F3\u307E\u305F\u306F\u4E0D\u6B63\u306A.jpackage.xml\u3067\u751F\u6210\u3055\u308C\u307E\u3057\u305F

Same as "de" translation.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties line 82:

> 80: 
> 81: error.foreign-app-image=\u9519\u8BEF\uFF1Aapp-image \u76EE\u5F55 ({0}) \u4E2D\u7F3A\u5C11 .jpackage.xml \u6587\u4EF6
> 82: error.invalid-app-image=\u9519\u8BEF\uFF1A\u53E6\u4E00\u4E2A jpackage \u7248\u672C\u6216\u683C\u5F0F\u9519\u8BEF\u7684 .jpackage.xml \u751F\u6210\u4E86 app-image \u76EE\u5F55 ({0})

Same as "de" translation.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">

Why "de-de" was changed to "de"?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="ja" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="932">

Why "ja-jp" to "ja"?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 37:

> 35: resource.post-app-image-script=Auszuf\u00FChrendes Skript nach dem Auff\u00FCllen des Anwendungsimages
> 36: resource.post-msi-script=Auszuf\u00FChrendes Skript nach dem Erstellen der MSI-Datei f\u00FCr das EXE-Installationsprogramm
> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Why this was changed?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37:

> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Why this was changed?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 37:

> 35: resource.post-app-image-script=\u8981\u5728\u586B\u5145\u5E94\u7528\u7A0B\u5E8F\u6620\u50CF\u4E4B\u540E\u8FD0\u884C\u7684\u811A\u672C
> 36: resource.post-msi-script=\u5728\u4E3A exe \u5B89\u88C5\u7A0B\u5E8F\u521B\u5EFA msi \u6587\u4EF6\u4E4B\u540E\u8981\u8FD0\u884C\u7684\u811A\u672C
> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Same as above.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From almatvee at openjdk.org  Thu Dec 15 23:17:15 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 15 Dec 2022 23:17:15 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <yAXqJCyxsT6KgDaEqjCnsudaB4zIy8gvPnrQkUkNPCw=.d87796f7-1c29-41b4-9b16-86920924ebed@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 15:

> 13:   <String Id="ShortcutPromptDlgStartMenuShortcutControlLabel">????????????????????</String>
> 14:   <String Id="InstallDirNotEmptyDlg_Title">[ProductName]??????</String>
> 15:   <String Id="ContextMenuCommandLabel">Open with [ProductName]</String>

Why it was removed in all translations, except English?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 51:

> 49: error.msi-product-version-minor-out-of-range=Nebenversion muss im Bereich [0, 255] liegen
> 50: error.version-swap=Versionsinformationen f\u00FCr {0} konnten nicht aktualisiert werden
> 51: error.icon-swap=Failed to update icon for {0}

Why this was removed?

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From prr at openjdk.org  Thu Dec 15 23:25:05 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Dec 2022 23:25:05 GMT
Subject: [jdk20] RFR: 8298083: The
 "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working
In-Reply-To: <-w3q4N0YsCvrK9ano6m4zrujjksesyS1gg8v8gUSmmw=.ca5e26a5-1da9-4f39-9b7c-e7a08e6407d5@github.com>
References: <-w3q4N0YsCvrK9ano6m4zrujjksesyS1gg8v8gUSmmw=.ca5e26a5-1da9-4f39-9b7c-e7a08e6407d5@github.com>
Message-ID: <OQvwEa_Hbu3qOYOmMXjI3v5rjjThxtVlJ4UKFgqSpSc=.fc794400-3ee4-47fa-a410-66927dce2db6@github.com>

On Mon, 12 Dec 2022 09:37:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit [5540a8c5](https://github.com/openjdk/jdk/commit/5540a8c5b7160ab5c67bb84631e3de54fa5aeceb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> The commit being backported was authored by Sergey Bylokhov on 8 Dec 2022 and was reviewed by Prasanta Sadhukhan.
> Thanks!

OK. I see this would have gone into 20 directly but it missed the fork by just a little bit,
and it is a backout, so approving.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/17


From prr at openjdk.org  Thu Dec 15 23:33:08 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Dec 2022 23:33:08 GMT
Subject: RFR: 8298709: Fix typos in src/java.desktop/ and various test
 classes of client component
In-Reply-To: <YJvUtRHEi5wPVtlKX64yftCh1Bh7KlX5jrCtMUhNwOU=.3a6ab572-e423-4d41-b620-97f9b075e8a6@github.com>
References: <YJvUtRHEi5wPVtlKX64yftCh1Bh7KlX5jrCtMUhNwOU=.3a6ab572-e423-4d41-b620-97f9b075e8a6@github.com>
Message-ID: <n118Bp7L1rRetpWn-g9fD5zzL4g5ldVUQJC5OBJyjxk=.3f30b18f-d58a-4466-a7cf-61141c72adeb@github.com>

On Wed, 14 Dec 2022 06:00:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which only fixes typos? The original PR for this change is https://github.com/openjdk/jdk/pull/10029. However, that PR included changes to multiple different files in different areas of the JDK and as a result didn't see progress.
> 
> This current PR splits off those changes and includes only client area related typo fixes.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11661


From weijun at openjdk.org  Thu Dec 15 23:34:10 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 15 Dec 2022 23:34:10 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75:

> 73:                 "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey
> 74:         {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
> 75:         {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},

The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From prr at openjdk.org  Thu Dec 15 23:44:06 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Dec 2022 23:44:06 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v2]
In-Reply-To: <YhS-pkykLDaNGlAiB-YDNyUkVYk-GceGszx7zvt6_aQ=.ad2efd92-6c58-4c45-9a54-6dad14eb42b3@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
 <KwuZH3CQlUiklf-h_yzbB1RzoXACnqXNjWX4RZjGCI0=.5651d65a-391c-4588-9037-4d78d2ae357e@github.com>
 <YhS-pkykLDaNGlAiB-YDNyUkVYk-GceGszx7zvt6_aQ=.ad2efd92-6c58-4c45-9a54-6dad14eb42b3@github.com>
Message-ID: <0xRhqnSHTdlFswnkxX4GWQQAC_mB8pZXJoJEXuaszCE=.5b6e987a-40fd-4089-bddb-b79845ac212f@github.com>

On Wed, 14 Dec 2022 21:42:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This change cause 23 test cases to fail across the platforms:

So I thought we'd got past the testing since a CSR was proposed. The CSR should have waited.

> 
> * `sanity/client/SwingSet/src/SwingSet2DemoTest.java`;
> * `javax/swing/GraphicsConfigNotifier/StalePreferredSize.java`;
> * two closed tests.
> 
> **One JCK test** fails; from a quick look, it's because the font is now uninstalled where it wasn't previously.

So all the test failures are blocker problem .. @aivanov-jdk, do any of the jtreg test failures characterise the JCK failure ?
Meaning something the submitter can use as a proxy to understand the problem
Do these failures suggest that there's a good reason why these fonts and colors are not installed ? 
Or do we have 23 (!) tests which have an assumption they probably shouldn't have ?
Possible, but in that case, would apps have the same assumptions ?

-------------

PR: https://git.openjdk.org/jdk/pull/10565


From dnguyen at openjdk.org  Fri Dec 16 00:20:09 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 00:20:09 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
Message-ID: <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>

On Thu, 15 Dec 2022 22:57:31 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix https and changed URL back
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82:
> 
>> 80: 
>> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0})
>> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt
> 
> error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""?

I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted?

> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:
> 
>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>> 2: <WixLocalization Culture="de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">
> 
> Why "de-de" was changed to "de"?

Also not sure why this was changed in the translation. I'm reverting all instances of these language codes.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Fri Dec 16 00:28:14 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 00:28:14 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
Message-ID: <OBPofdj-HAyS2LOEYb9Di6foNnPm0PQYQoQ1AsyGD6o=.daf96361-fae0-488c-b400-6edea72cf6f9@github.com>

On Thu, 15 Dec 2022 23:13:22 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix https and changed URL back
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37:
> 
>> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl
> 
> Why this was changed?

Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From almatvee at openjdk.org  Fri Dec 16 00:55:07 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 16 Dec 2022 00:55:07 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
Message-ID: <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>

On Fri, 16 Dec 2022 00:15:51 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82:
>> 
>>> 80: 
>>> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0})
>>> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt
>> 
>> error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""?
>
> I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted?

Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From almatvee at openjdk.org  Fri Dec 16 00:59:08 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 16 Dec 2022 00:59:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <OBPofdj-HAyS2LOEYb9Di6foNnPm0PQYQoQ1AsyGD6o=.daf96361-fae0-488c-b400-6edea72cf6f9@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <OBPofdj-HAyS2LOEYb9Di6foNnPm0PQYQoQ1AsyGD6o=.daf96361-fae0-488c-b400-6edea72cf6f9@github.com>
Message-ID: <ybG8PSIdt0XyYOo4JF4ozp2yRpZDnPQUpDxoDeFTiCo=.fbe7a6d5-9bc3-4097-bd02-164f015bcaf6@github.com>

On Fri, 16 Dec 2022 00:24:26 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37:
>> 
>>> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>>> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>>> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl
>> 
>> Why this was changed?
>
> Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file.

Yes it needs to be correct. It was changed to _ja, etc with [commit](https://github.com/openjdk/jdk20/commit/543163a03b5f1af7a7e7af317a26eb8c5aa81c38#diff-afb8ea68d8b3e9be4bba1c417c82d2162eea9333a3157f05ef57c026af94eb3b). Which was done on Aug 10, 2022, so it seems message drop is based on old code.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Fri Dec 16 01:05:08 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 01:05:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
 <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>
Message-ID: <iqZK2YXVbWKWqoQkJhlwxX1sNPCdcJkRKjgWh51KiWg=.9bb3af83-561d-4711-8ec9-585adf10f676@github.com>

On Fri, 16 Dec 2022 00:51:55 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted?
>
> Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old.

I'll revert it, investigate the cause for the extraction issue in this drop, and try to have it translated by the next drop then.

>> Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file.
>
> Yes it needs to be correct. It was changed to _ja, etc with [commit](https://github.com/openjdk/jdk20/commit/543163a03b5f1af7a7e7af317a26eb8c5aa81c38#diff-afb8ea68d8b3e9be4bba1c417c82d2162eea9333a3157f05ef57c026af94eb3b). Which was done on Aug 10, 2022, so it seems message drop is based on old code.

This drop had some issues with the extraction which will be resolved. Some of the changes are correct while some seem to be old. It seems these jpackage files were are older? I can revert these changes for jpackage then.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From joehw at openjdk.org  Fri Dec 16 01:25:18 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 16 Dec 2022 01:25:18 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <ienEQpq9KGQ0-B04HBvRrPpNQDISigGzx4lTtzjuDVY=.7bcc0fd3-51c9-4e51-9684-266a98e521ec@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

The changes in the java.xml area look good to me.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35


From azvegint at openjdk.org  Fri Dec 16 01:33:06 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 16 Dec 2022 01:33:06 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v2]
In-Reply-To: <7lRrGCopXc6TOhPxpp4O7YP5L_z09DHG6Pd0Tj8kjgg=.c2177cce-78d9-40fd-8073-36b2eff352da@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <7lRrGCopXc6TOhPxpp4O7YP5L_z09DHG6Pd0Tj8kjgg=.c2177cce-78d9-40fd-8073-36b2eff352da@github.com>
Message-ID: <CZ-rPr-zEF9Htx7EhLj5SsWGtE_ejyoWJLzKPKt-55E=.708a04e7-e797-498b-aefd-1871f92ef41a@github.com>

On Thu, 15 Dec 2022 07:29:32 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Set the text caret to be visible but not blinking on the non-editable text area. Fix the regression test that becames unstable after the change.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed MultiSelectionText so it is now stable on Linux
>   Removed both fixed tests from ProblemList

src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 389:

> 387:             } else {
> 388:                 if (getBlinkRate() != 0) {
> 389:                     savedBlinkRate = getBlinkRate();

Look like this can override blink rate set by user:


import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JTextField;
import javax.swing.SwingUtilities;
import java.awt.BorderLayout;
import java.awt.Component;
import java.awt.Robot;
import java.lang.reflect.InvocationTargetException;

public class CaretThing {

    static JFrame frame;
    static JTextField textField;
    static Robot robot;
    static JButton button;

    static void printBlinkRate() {
        System.err.println("Caret blink rate: " + textField.getCaret().getBlinkRate());
    }

    static void requestFocus(Component component) throws InterruptedException, InvocationTargetException {
        robot.waitForIdle();
        robot.delay(300);

        SwingUtilities.invokeAndWait(() -> {
            System.err.println("Requesting focus on " + component);
            printBlinkRate();
            component.requestFocus();
            printBlinkRate();
        });
    }

    static void changeEditable() throws InterruptedException, InvocationTargetException {
        robot.waitForIdle();
        robot.delay(300);
        SwingUtilities.invokeAndWait(()-> {
            System.err.println("Changing editable");
            printBlinkRate();
            textField.setEditable(!textField.isEditable());
            printBlinkRate();
        });
    }

    public static void main(String[] args) throws Exception {
        robot = new Robot();
        robot.setAutoWaitForIdle(true);
        robot.setAutoDelay(50);

        SwingUtilities.invokeAndWait(() -> {
            frame = new JFrame("Hey");
            frame.setLocationRelativeTo(null);
            textField = new JTextField("Some long field value");

            textField.setEditable(false);
            frame.setLayout(new BorderLayout());
            frame.add(textField, BorderLayout.NORTH);

            button = new JButton("Button");
            button.addActionListener((e)-> printBlinkRate());

            frame.add(button, BorderLayout.CENTER);
            frame.pack();
            frame.setVisible(true);

            button.requestFocus();
            textField.getCaret().setBlinkRate(2500);
        });

        requestFocus(textField);

        requestFocus(button); // comment this to get 0 blink rate on editable field

        changeEditable();

        requestFocus(textField);

        SwingUtilities.invokeAndWait(CaretThing::printBlinkRate);
    }
}

Running the sample above at least two possible misbehaviors(tested on Linux):
* you will receive blink rate `500` instead of user set `2500`
* but if you comment `requestFocus(button);` line then blink rate will be `0` (it shows non-blinking cursor)

<hr>

Other than that I am worried about `getBlinkRate()` does not return the same value as passed to`setBlinkRate()` (e.g. case when component is not editable, possible JCK issue?)

src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 1050:

> 1048:                     flasher = new Timer(rate, handler);
> 1049:                 }
> 1050:                 flasher.setDelay(rate);

Coming back to negative rate, looks like this changes the previous behavior:

Before the fix it did throw IAE in all cases:

https://github.com/openjdk/jdk20/blob/ca39eb906692568347e7f264520593188f9276cf/src/java.desktop/share/classes/javax/swing/Timer.java#L397-L406

After the fix IAE is thrown only if component is editable<br>
In case of non-editable and may throw it way later after `setEditable(true)` call and focus gain.

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From duke at openjdk.org  Fri Dec 16 01:53:06 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 16 Dec 2022 01:53:06 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v2]
In-Reply-To: <0xRhqnSHTdlFswnkxX4GWQQAC_mB8pZXJoJEXuaszCE=.5b6e987a-40fd-4089-bddb-b79845ac212f@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
 <KwuZH3CQlUiklf-h_yzbB1RzoXACnqXNjWX4RZjGCI0=.5651d65a-391c-4588-9037-4d78d2ae357e@github.com>
 <YhS-pkykLDaNGlAiB-YDNyUkVYk-GceGszx7zvt6_aQ=.ad2efd92-6c58-4c45-9a54-6dad14eb42b3@github.com>
 <0xRhqnSHTdlFswnkxX4GWQQAC_mB8pZXJoJEXuaszCE=.5b6e987a-40fd-4089-bddb-b79845ac212f@github.com>
Message-ID: <lNeC-Axii4ApMAEoahqW2mUSDYXFpc5kf96yT0oxBnQ=.7779bec8-b220-49f3-bab8-43c3aa8bb79a@github.com>

On Thu, 15 Dec 2022 23:41:30 GMT, Phil Race <prr at openjdk.org> wrote:

> So all the test failures are blocker problem

100%. I'll see what I can learn from the failed tests, but my hunch is that many fail due to incorrect assumptions.

-------------

PR: https://git.openjdk.org/jdk/pull/10565


From dnguyen at openjdk.org  Fri Dec 16 03:38:54 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:38:54 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert old translation. Fix lang codes

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/57c42206..29880af9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=03-04

  Stats: 18 lines in 9 files changed: 6 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Fri Dec 16 03:38:56 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:38:56 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <iqZK2YXVbWKWqoQkJhlwxX1sNPCdcJkRKjgWh51KiWg=.9bb3af83-561d-4711-8ec9-585adf10f676@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
 <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>
 <iqZK2YXVbWKWqoQkJhlwxX1sNPCdcJkRKjgWh51KiWg=.9bb3af83-561d-4711-8ec9-585adf10f676@github.com>
Message-ID: <_Dir5hjsOpTXHLKfV6SM_6kUJfNcHSkgHjrRAHbGUfw=.db9fe398-4a22-4aab-90ef-72d67f5c708e@github.com>

On Fri, 16 Dec 2022 01:02:03 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old.
>
> I'll revert it, investigate the cause for the extraction issue in this drop, and try to have it translated by the next drop then.

The translated text here has been reverted to its original English. The same has been done for its locales.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Fri Dec 16 03:38:58 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:38:58 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
Message-ID: <AkPK7pgS3BMYAhNKSN0Xz0Jr0ey_vcQHGP8UmdXy1II=.9691952b-cf52-4724-8c48-3496dfa671c8@github.com>

On Fri, 16 Dec 2022 00:17:15 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:
>> 
>>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>>> 2: <WixLocalization Culture="de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">
>> 
>> Why "de-de" was changed to "de"?
>
> Also not sure why this was changed in the translation. I'm reverting all instances of these language codes.

This has been reverted as it was a regression for all locales of MsiInstallerStrings.wxl

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Fri Dec 16 03:39:01 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:39:01 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <yAXqJCyxsT6KgDaEqjCnsudaB4zIy8gvPnrQkUkNPCw=.d87796f7-1c29-41b4-9b16-86920924ebed@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <yAXqJCyxsT6KgDaEqjCnsudaB4zIy8gvPnrQkUkNPCw=.d87796f7-1c29-41b4-9b16-86920924ebed@github.com>
Message-ID: <bbvTT7_7dNA1j9sUSiPADGEnuneemJPFgiiIAI8SsxU=.7e1290eb-107a-458e-a4ee-2cab3b9e7fbf@github.com>

On Thu, 15 Dec 2022 23:12:58 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed trailing whitespace
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 51:
> 
>> 49: error.msi-product-version-build-out-of-range=Build-Teil der Version muss im Bereich [0, 65535] liegen
>> 50: error.msi-product-version-minor-out-of-range=Nebenversion muss im Bereich [0, 255] liegen
>> 51: error.version-swap=Versionsinformationen f\u00FCr {0} konnten nicht aktualisiert werden
> 
> Why this was removed?

This line was added back to all locales as it was a regression from the translation process.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Fri Dec 16 03:45:07 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:45:07 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
Message-ID: <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>

On Thu, 15 Dec 2022 23:30:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert double quote as well
>
> src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75:
> 
>> 73:                 "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey
>> 74:         {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
>> 75:         {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
> 
> The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file.

I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK?

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Fri Dec 16 03:58:08 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:58:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <uCw2LCc01qL0w9UYrWT7tMoQOhNIB_VaKm4kGc_Z9Vw=.e52a56bf-c4dc-454c-b2a2-e8796c284d66@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

@dfuch Could I get a review from you as well? I believe this translation covers some of the files for your team.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From cjplummer at openjdk.org  Fri Dec 16 04:12:17 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 16 Dec 2022 04:12:17 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <XK9d6e9V7rnGtOvMP2mHVDwxsaO_cQCWhnehjTarZ_w=.01c61275-fd0e-4532-8a17-a13c16734bb8@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

`src/jdk.jdi/share/classes/com/sun/tools` changes look good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35


From almatvee at openjdk.org  Fri Dec 16 05:17:11 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 16 Dec 2022 05:17:11 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <J3GyIIuioqw6EvIvhMXFm2MByz1cylrmF-jSJcyg3RM=.cd6f3f83-a261-4fa1-ab46-c7d017709595@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

jpackage changes looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35


From serb at openjdk.org  Fri Dec 16 06:36:04 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 16 Dec 2022 06:36:04 GMT
Subject: [jdk20] Integrated: 8298083: The
 "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working
In-Reply-To: <-w3q4N0YsCvrK9ano6m4zrujjksesyS1gg8v8gUSmmw=.ca5e26a5-1da9-4f39-9b7c-e7a08e6407d5@github.com>
References: <-w3q4N0YsCvrK9ano6m4zrujjksesyS1gg8v8gUSmmw=.ca5e26a5-1da9-4f39-9b7c-e7a08e6407d5@github.com>
Message-ID: <vVjc8xwBvzPwvMYu1tgbZyjOehbmgDza5j9Xs96sFpE=.bf8a91d0-5aa1-4e12-a852-fe3340305015@github.com>

On Mon, 12 Dec 2022 09:37:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit [5540a8c5](https://github.com/openjdk/jdk/commit/5540a8c5b7160ab5c67bb84631e3de54fa5aeceb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> The commit being backported was authored by Sergey Bylokhov on 8 Dec 2022 and was reviewed by Prasanta Sadhukhan.
> Thanks!

This pull request has now been integrated.

Changeset: 03a694af
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/03a694afda81f575f8a24e655d53b2b029e3d968
Stats:     52 lines in 4 files changed: 18 ins; 21 del; 13 mod

8298083: The "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working

Reviewed-by: prr
Backport-of: 5540a8c5b7160ab5c67bb84631e3de54fa5aeceb

-------------

PR: https://git.openjdk.org/jdk20/pull/17


From jpai at openjdk.org  Fri Dec 16 07:14:08 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 Dec 2022 07:14:08 GMT
Subject: RFR: 8298709: Fix typos in src/java.desktop/ and various test
 classes of client component
In-Reply-To: <YJvUtRHEi5wPVtlKX64yftCh1Bh7KlX5jrCtMUhNwOU=.3a6ab572-e423-4d41-b620-97f9b075e8a6@github.com>
References: <YJvUtRHEi5wPVtlKX64yftCh1Bh7KlX5jrCtMUhNwOU=.3a6ab572-e423-4d41-b620-97f9b075e8a6@github.com>
Message-ID: <uJiEjjleSxKfkLXP6hNajNLDcxN7UT1R1xgHbKxAGIY=.dd21403e-7c18-4f87-ad27-1019e3584ee3@github.com>

On Wed, 14 Dec 2022 06:00:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which only fixes typos? The original PR for this change is https://github.com/openjdk/jdk/pull/10029. However, that PR included changes to multiple different files in different areas of the JDK and as a result didn't see progress.
> 
> This current PR splits off those changes and includes only client area related typo fixes.

Thank you Iris and Phil for the reviews.

-------------

PR: https://git.openjdk.org/jdk/pull/11661


From jpai at openjdk.org  Fri Dec 16 07:14:08 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 Dec 2022 07:14:08 GMT
Subject: Integrated: 8298709: Fix typos in src/java.desktop/ and various test
 classes of client component
In-Reply-To: <YJvUtRHEi5wPVtlKX64yftCh1Bh7KlX5jrCtMUhNwOU=.3a6ab572-e423-4d41-b620-97f9b075e8a6@github.com>
References: <YJvUtRHEi5wPVtlKX64yftCh1Bh7KlX5jrCtMUhNwOU=.3a6ab572-e423-4d41-b620-97f9b075e8a6@github.com>
Message-ID: <7Tgg2V2pMcR_JLHfPkxTLY0E161MFjZKG9Zejrn3-aI=.7a5c65c5-e1a0-4713-a884-094b3312d812@github.com>

On Wed, 14 Dec 2022 06:00:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which only fixes typos? The original PR for this change is https://github.com/openjdk/jdk/pull/10029. However, that PR included changes to multiple different files in different areas of the JDK and as a result didn't see progress.
> 
> This current PR splits off those changes and includes only client area related typo fixes.

This pull request has now been integrated.

Changeset: fa322e40
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa322e40b68abf0a253040d14414d41f4e01e028
Stats:     19 lines in 16 files changed: 0 ins; 0 del; 19 mod

8298709: Fix typos in src/java.desktop/ and various test classes of client component

Co-authored-by: Michael Ernst <mernst at openjdk.org>
Reviewed-by: iris, prr

-------------

PR: https://git.openjdk.org/jdk/pull/11661


From dfuchs at openjdk.org  Fri Dec 16 09:22:29 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 16 Dec 2022 09:22:29 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34:

> 32: # Translators please note do not translate the options themselves
> 33: java.launcher.opt.footer = \    -cp <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    -classpath <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    --class-path <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n                  und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n    -p <Modulpfad>\n    --module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist.\n    --upgrade-module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n                  Module im Laufzeitimage ersetzen\n    --add-modules <Modulname>[,<Modulname>...]\n                  Root-Module, die zus\u00E4tzlich zum anf\u00E4n
 glichen Modul aufgel\u00F6st werden sollen.\n                  <Modulname> kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n                  ALL-MODULE-PATH.\n    --enable-native-access <Modulname>[,<Modulname>...]\n                  Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n                  <Modulname> kann auch ALL-UNNAMED lauten.\n    --list-modules\n                  Listet beobachtbare Module auf und beendet den Vorgang\n    -d <Modulname>\n    --describe-module <Modulname>\n                  Beschreibt ein Modul und beendet den Vorgang\n    --dry-run     Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n                  Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n                  Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n    --validate-modules\n                  Validiert alle Module und beendet den Vorgang\n                  Die Option "--vali
 date-modules" kann n\u00FCtzlich sein, um\n                  Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n    -D<Name>=<Wert>\n                  Legt eine Systemeigenschaft fest\n    -verbose:[class|module|gc|jni]\n                  Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n    -version      Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n    --version      Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n    -showversion  Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n    --show-version\n                  Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n    --show-module-resolution\n                  Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n    -? -h -help\n                  Gibt diese Hilfemeldung an den Fehlerstream aus\n    --help        Gibt diese Hilfemeldung an den Outputstream aus\n    -X            Gibt Hilfe
  zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n    --help-extra  Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n    -ea[:<packagename>...|:<classname>]\n    -enableassertions[:<packagename>...|:<classname>]\n                  Aktiviert Assertions mit angegebener Granularit\u00E4t\n    -da[:<packagename>...|:<classname>]\n    -disableassertions[:<packagename>...|:<classname>]\n                  Deaktiviert Assertions mit angegebener Granularit\u00E4t\n    -esa | -enablesystemassertions\n                  Aktiviert System-Assertions\n    -dsa | -disablesystemassertions\n                  Deaktiviert System-Assertions\n    -agentlib:<libname>[=<options>]\n                  L\u00E4dt die native Agent Library <libname>. Beispiel: -agentlib:jdwp\n                  siehe auch -agentlib:jdwp=help\n    -agentpath:<pathname>[=<options>]\n                  L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n    -javaagent:<jarpath>[=<options>]\n
                   \
> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n    -splash:<imagepath>\n                  Zeigt den Startbildschirm mit einem angegebenen Bild an\n                  Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n                  falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n                  muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n                  Das am besten geeignete angegebene skalierte Bild wird\n                  automatisch ausgew\u00E4hlt.\n                  Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n    @argument files\n                  Eine oder mehrere Argumentdateien mit Optionen\n    -disable- at files\n                  Verhindert die weitere Erweiterung von Argumentdateien\n    --enable-preview\n                  L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument f
 \u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --<Name>=<Wert> oder\n--<Name> <Wert> verwenden.\n

This change seems wrong, unless I'm mistaken the option name is `--disable- at files`, not `-disable- at files`

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From dfuchs at openjdk.org  Fri Dec 16 09:48:59 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 16 Dec 2022 09:48:59 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
 <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>
Message-ID: <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com>

On Fri, 16 Dec 2022 09:20:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert old translation. Fix lang codes
>
> src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34:
> 
>> 32: # Translators please note do not translate the options themselves
>> 33: java.launcher.opt.footer = \    -cp <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    -classpath <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    --class-path <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n                  und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n    -p <Modulpfad>\n    --module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist.\n    --upgrade-module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n                  Module im Laufzeitimage ersetzen\n    --add-modules <Modulname>[,<Modulname>...]\n                  Root-Module, die zus\u00E4tzlich zum anf\u00E4
 nglichen Modul aufgel\u00F6st werden sollen.\n                  <Modulname> kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n                  ALL-MODULE-PATH.\n    --enable-native-access <Modulname>[,<Modulname>...]\n                  Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n                  <Modulname> kann auch ALL-UNNAMED lauten.\n    --list-modules\n                  Listet beobachtbare Module auf und beendet den Vorgang\n    -d <Modulname>\n    --describe-module <Modulname>\n                  Beschreibt ein Modul und beendet den Vorgang\n    --dry-run     Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n                  Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n                  Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n    --validate-modules\n                  Validiert alle Module und beendet den Vorgang\n                  Die Option "--val
 idate-modules" kann n\u00FCtzlich sein, um\n                  Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n    -D<Name>=<Wert>\n                  Legt eine Systemeigenschaft fest\n    -verbose:[class|module|gc|jni]\n                  Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n    -version      Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n    --version      Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n    -showversion  Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n    --show-version\n                  Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n    --show-module-resolution\n                  Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n    -? -h -help\n                  Gibt diese Hilfemeldung an den Fehlerstream aus\n    --help        Gibt diese Hilfemeldung an den Outputstream aus\n    -X            Gibt Hilf
 e zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n    --help-extra  Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n    -ea[:<packagename>...|:<classname>]\n    -enableassertions[:<packagename>...|:<classname>]\n                  Aktiviert Assertions mit angegebener Granularit\u00E4t\n    -da[:<packagename>...|:<classname>]\n    -disableassertions[:<packagename>...|:<classname>]\n                  Deaktiviert Assertions mit angegebener Granularit\u00E4t\n    -esa | -enablesystemassertions\n                  Aktiviert System-Assertions\n    -dsa | -disablesystemassertions\n                  Deaktiviert System-Assertions\n    -agentlib:<libname>[=<options>]\n                  L\u00E4dt die native Agent Library <libname>. Beispiel: -agentlib:jdwp\n                  siehe auch -agentlib:jdwp=help\n    -agentpath:<pathname>[=<options>]\n                  L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n    -javaagent:<jarpath>[=<options>]\
 n                  \
>> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n    -splash:<imagepath>\n                  Zeigt den Startbildschirm mit einem angegebenen Bild an\n                  Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n                  falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n                  muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n                  Das am besten geeignete angegebene skalierte Bild wird\n                  automatisch ausgew\u00E4hlt.\n                  Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n    @argument files\n                  Eine oder mehrere Argumentdateien mit Optionen\n    -disable- at files\n                  Verhindert die weitere Erweiterung von Argumentdateien\n    --enable-preview\n                  L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument 
 f\u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --<Name>=<Wert> oder\n--<Name> <Wert> verwenden.\n
> 
> This change seems wrong, unless I'm mistaken the option name is still  `--disable- at files`, not `-disable- at files`

I'm unfortunately not familiar with any of these resources files,  and can't neither comment on any of the translated languages. I still had a look and spotted the glitch above - which seems to be an error introduced in the translation.
Find-in-files revealed that the source is still using --disable- at files. See:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/args.c#L131

https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L1377

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/resources/launcher.properties#L121

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From alanb at openjdk.org  Fri Dec 16 10:13:04 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Dec 2022 10:13:04 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <uCw2LCc01qL0w9UYrWT7tMoQOhNIB_VaKm4kGc_Z9Vw=.e52a56bf-c4dc-454c-b2a2-e8796c284d66@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
 <uCw2LCc01qL0w9UYrWT7tMoQOhNIB_VaKm4kGc_Z9Vw=.e52a56bf-c4dc-454c-b2a2-e8796c284d66@github.com>
Message-ID: <s7AGBhlHie3pq-e0NT_2pQ3hWQ15Oyt1dR_t2D9YM3g=.01648378-0fb2-4f51-a9bf-1f5066e40158@github.com>

On Fri, 16 Dec 2022 03:55:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert old translation. Fix lang codes
>
> @dfuch Could I get a review from you as well? I believe this translation covers some of the files for your team.

@DamonGuy There seems to be several glitches in this refresh. It's also surprising that the translations appear to be done on several out of date files. On the positive front, it's good to see this update has caught the attention of Naoto, Weijun, and others. Once the identified issues have been fixed then it would be good to try to get a review from someone that is native in each of the languages.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From aivanov at openjdk.org  Fri Dec 16 12:03:52 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 16 Dec 2022 12:03:52 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v7]
In-Reply-To: <G5TnquzWCKm_0X-RJbnzozH6hSATZO1neKkCm7wUfDM=.ed12384a-2ede-4e27-86a4-953438cd1638@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
 <G5TnquzWCKm_0X-RJbnzozH6hSATZO1neKkCm7wUfDM=.ed12384a-2ede-4e27-86a4-953438cd1638@github.com>
Message-ID: <yKjHCr6mNXjQYebAj6tHoBAfICpeeY7DX7_PflfucRM=.c2537a4e-3b82-492d-a0a6-be1c745b5fa4@github.com>

On Tue, 13 Dec 2022 03:32:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>>     javax.swing.text.html.parser.ParserDelegator
>>     javax.swing.LayoutComparator
>> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
>> 
>> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
>> Added the warning..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing .

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/LayoutComparator.java line 39:

> 37:  * position. Code adapted from original javax.swing.DefaultFocusManager
> 38:  * implementation.
> 39:  * <strong>Warning:</strong>

There should be a `<p>` tag before the Warning, otherwise, the warning will not start from a new line (paragraph), it will continue the previous paragraph. See `JComponent`, for example: https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/JComponent.java#L204-L205

src/java.desktop/share/classes/javax/swing/text/html/parser/ParserDelegator.java line 45:

> 43:  * each time its parse method is invoked. Stores a
> 44:  * reference to the dtd.
> 45:  * <strong>Warning:</strong>

Missing `<p>`.

-------------

PR: https://git.openjdk.org/jdk/pull/11565


From naoto at openjdk.org  Fri Dec 16 13:46:02 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Dec 2022 13:46:02 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <FkE6xWy1f_931bWkjLEGooZJgRw31mF1UNMMMjICFUQ=.90de6a4a-57c3-41c4-8c9c-2c582f4696c0@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

There is another translation drop scheduled in January, so our plan is to figure out why the source extraction in this drop mistakenly used old files till then, then address it in the January l10n drop.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From avu at openjdk.org  Fri Dec 16 15:37:54 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Fri, 16 Dec 2022 15:37:54 GMT
Subject: [jdk20] RFR: 8298217: Regressions 30-110% in SwingMark on MacOS, 
 more so on aarch64
In-Reply-To: <rUqDSIQtk_Gz6GhS7zXmSyTpO6Rxf3i8pfcx4gfKSJY=.12663f0d-ec12-4f8b-a310-58b883da4cc8@github.com>
References: <rUqDSIQtk_Gz6GhS7zXmSyTpO6Rxf3i8pfcx4gfKSJY=.12663f0d-ec12-4f8b-a310-58b883da4cc8@github.com>
Message-ID: <WTwKaYRlNMW20GK3c0EGqZ-eCw8v4tgHAv38phjOwBo=.a36887df-6399-429a-9040-46b1208ea15e@github.com>

On Fri, 16 Dec 2022 15:20:14 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> The nature of data plays an important part in rendering performance as noted in the comment made on [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) -
> https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14504772
> 
> Although the fix [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) is logical, it seems to have an adverse impact on SwingMark test numbers especially on aarch64.
> 
> The SwingMark tests closely depict the UI operations in real-world applications as compared to the J2DBench and RenderPerfTest tests. Hence, it is decided to revert the regression causing commits [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) (and dependent [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266)).
> 
> Metal rendering pipeline performance numbers before and after this PR are attached to the JBS.
> 
> Note : The fix for [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) has a good regression test - DrawPrimitivesTest.java. It passes even after reverting the said changes. This test will be added back once this PR is committed.

The rest of the code looks good

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderQueue.m line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2021, Oracle and/or its affiliates. All rights reserved.

I suppose we should leave 2022 here.

-------------

Marked as reviewed by avu (Committer).

PR: https://git.openjdk.org/jdk20/pull/47


From prr at openjdk.org  Fri Dec 16 15:55:49 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 Dec 2022 15:55:49 GMT
Subject: [jdk20] RFR: 8298217: Regressions 30-110% in SwingMark on MacOS, 
 more so on aarch64
In-Reply-To: <rUqDSIQtk_Gz6GhS7zXmSyTpO6Rxf3i8pfcx4gfKSJY=.12663f0d-ec12-4f8b-a310-58b883da4cc8@github.com>
References: <rUqDSIQtk_Gz6GhS7zXmSyTpO6Rxf3i8pfcx4gfKSJY=.12663f0d-ec12-4f8b-a310-58b883da4cc8@github.com>
Message-ID: <RFd-qbvMqgsVxh7UbcNVIPJWbwyYPlqcOaQvPW_Mxqw=.e5decce1-6234-41d8-9752-7fe4a70693f9@github.com>

On Fri, 16 Dec 2022 15:20:14 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> The nature of data plays an important part in rendering performance as noted in the comment made on [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) -
> https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14504772
> 
> Although the fix [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) is logical, it seems to have an adverse impact on SwingMark test numbers especially on aarch64.
> 
> The SwingMark tests closely depict the UI operations in real-world applications as compared to the J2DBench and RenderPerfTest tests. Hence, it is decided to revert the regression causing commits [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) (and dependent [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266)).
> 
> Metal rendering pipeline performance numbers before and after this PR are attached to the JBS.
> 
> Note : The fix for [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) has a good regression test - DrawPrimitivesTest.java. It passes even after reverting the said changes. This test will be added back once this PR is committed.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/47


From aghaisas at openjdk.org  Fri Dec 16 15:27:37 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 16 Dec 2022 15:27:37 GMT
Subject: [jdk20] RFR: 8298217: Regressions 30-110% in SwingMark on MacOS,
 more so on aarch64
Message-ID: <rUqDSIQtk_Gz6GhS7zXmSyTpO6Rxf3i8pfcx4gfKSJY=.12663f0d-ec12-4f8b-a310-58b883da4cc8@github.com>

The nature of data plays an important part in rendering performance as noted in the comment made on [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) -
https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14504772

Although the fix [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) is logical, it seems to have an adverse impact on SwingMark test numbers especially on aarch64.

The SwingMark tests closely depict the UI operations in real-world applications as compared to the J2DBench and RenderPerfTest tests. Hence, it is decided to revert the regression causing commits [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) (and dependent [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266)).

Metal rendering pipeline performance numbers before and after this PR are attached to the JBS.

Note : The fix for [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) has a good regression test - DrawPrimitivesTest.java. It passes even after reverting the said changes. This test will be added back once this PR is committed.

-------------

Commit messages:
 - Revert JDK-8288948 Fix
 - Revert JDK-8291266 Fix

Changes: https://git.openjdk.org/jdk20/pull/47/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=47&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298217
  Stats: 410 lines in 5 files changed: 27 ins; 302 del; 81 mod
  Patch: https://git.openjdk.org/jdk20/pull/47.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/47/head:pull/47

PR: https://git.openjdk.org/jdk20/pull/47


From azvegint at openjdk.org  Fri Dec 16 15:02:34 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 16 Dec 2022 15:02:34 GMT
Subject: [jdk20] RFR: 8298905: Test
 "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because
 the frames of instruction does not display
Message-ID: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>

openjdk/jdk#9525 has changed behavior of PassFailJFrame.
it doesn't call `setVisible()` from its constructor on instruction window anymore and some tests were not ready for that.

So adding `positionTestWindow()` fixes the issue.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.org/jdk20/pull/46/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=46&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298905
  Stats: 6 lines in 3 files changed: 4 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/46.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/46/head:pull/46

PR: https://git.openjdk.org/jdk20/pull/46


From duke at openjdk.org  Fri Dec 16 16:11:53 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Fri, 16 Dec 2022 16:11:53 GMT
Subject: [jdk20] RFR: 8298905: Test
 "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because
 the frames of instruction does not display
In-Reply-To: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
References: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
Message-ID: <7cJigfvFSV0qdaSezfLNDTn4jbpUsTqhreCGXCDraQk=.1e6005d7-cdd7-4dd7-a94c-284cf261e028@github.com>

On Fri, 16 Dec 2022 14:55:13 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> openjdk/jdk#9525 has changed behavior of PassFailJFrame.
> it doesn't call `setVisible()` from its constructor on instruction window anymore and some tests were not ready for that.
> 
> So adding `positionTestWindow()` fixes the issue.

Looks good to me.

-------------

PR: https://git.openjdk.org/jdk20/pull/46


From weijun at openjdk.org  Fri Dec 16 15:05:55 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Dec 2022 15:05:55 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
 <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
Message-ID: <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>

On Fri, 16 Dec 2022 03:41:09 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75:
>> 
>>> 73:                 "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey
>>> 74:         {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
>>> 75:         {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
>> 
>> The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file.
>
> I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK?

Yes, you can replace all "??????" (that is not after ""???") to "?????????".

There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From jdv at openjdk.org  Fri Dec 16 16:25:48 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 16 Dec 2022 16:25:48 GMT
Subject: [jdk20] RFR: 8298217: Regressions 30-110% in SwingMark on MacOS, 
 more so on aarch64
In-Reply-To: <rUqDSIQtk_Gz6GhS7zXmSyTpO6Rxf3i8pfcx4gfKSJY=.12663f0d-ec12-4f8b-a310-58b883da4cc8@github.com>
References: <rUqDSIQtk_Gz6GhS7zXmSyTpO6Rxf3i8pfcx4gfKSJY=.12663f0d-ec12-4f8b-a310-58b883da4cc8@github.com>
Message-ID: <oD1K-e7VUTj6mL0IeUqrtVkZuFiSezx9Rfb4CpHVHoU=.f717f10c-d7ac-4c98-a641-9a0cd92be0ad@github.com>

On Fri, 16 Dec 2022 15:20:14 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> The nature of data plays an important part in rendering performance as noted in the comment made on [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) -
> https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14504772
> 
> Although the fix [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) is logical, it seems to have an adverse impact on SwingMark test numbers especially on aarch64.
> 
> The SwingMark tests closely depict the UI operations in real-world applications as compared to the J2DBench and RenderPerfTest tests. Hence, it is decided to revert the regression causing commits [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) (and dependent [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266)).
> 
> Metal rendering pipeline performance numbers before and after this PR are attached to the JBS.
> 
> Note : The fix for [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) has a good regression test - DrawPrimitivesTest.java. It passes even after reverting the said changes. This test will be added back once this PR is committed.

We should keep latest updated year. Please update it before pushing.

-------------

Marked as reviewed by jdv (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/47


From aghaisas at openjdk.org  Fri Dec 16 16:49:11 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 16 Dec 2022 16:49:11 GMT
Subject: [jdk20] RFR: 8298217: Regressions 30-110% in SwingMark on MacOS, 
 more so on aarch64 [v2]
In-Reply-To: <rUqDSIQtk_Gz6GhS7zXmSyTpO6Rxf3i8pfcx4gfKSJY=.12663f0d-ec12-4f8b-a310-58b883da4cc8@github.com>
References: <rUqDSIQtk_Gz6GhS7zXmSyTpO6Rxf3i8pfcx4gfKSJY=.12663f0d-ec12-4f8b-a310-58b883da4cc8@github.com>
Message-ID: <3-LqzNNNTJcaCm09IxjqqxvlkqM4NlVgBwd9ZO_A6b0=.08e0c238-b99d-4dc7-9262-7d7a1fb3d6cb@github.com>

> The nature of data plays an important part in rendering performance as noted in the comment made on [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) -
> https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14504772
> 
> Although the fix [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) is logical, it seems to have an adverse impact on SwingMark test numbers especially on aarch64.
> 
> The SwingMark tests closely depict the UI operations in real-world applications as compared to the J2DBench and RenderPerfTest tests. Hence, it is decided to revert the regression causing commits [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) (and dependent [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266)).
> 
> Metal rendering pipeline performance numbers before and after this PR are attached to the JBS.
> 
> Note : The fix for [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) has a good regression test - DrawPrimitivesTest.java. It passes even after reverting the said changes. This test will be added back once this PR is committed.

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  Restore file modification year

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/47/files
  - new: https://git.openjdk.org/jdk20/pull/47/files/da8c8f50..5a4be5bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=47&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=47&range=00-01

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk20/pull/47.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/47/head:pull/47

PR: https://git.openjdk.org/jdk20/pull/47


From dnguyen at openjdk.org  Fri Dec 16 16:53:59 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 16:53:59 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <eKoHNhbn6nSejGumOAm87rtEJh5ZyQVEaFblB2t7jOA=.3366bc22-6709-479c-a23a-d41f1aa49b33@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

Right, Naoto's comment is correct. This time, the source extraction used some older files. To resolve this for this drop, I went through the files and reverted any changes that would be deemed as regressions or outdated files. Any other updates missed in this drop will be handled in the close upcoming drop in January.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Fri Dec 16 17:02:42 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:02:42 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v6]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Fix missing dash

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/29880af9..62a19a83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=04-05

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Fri Dec 16 17:02:44 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:02:44 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
 <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>
 <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com>
Message-ID: <uipT8s-ZFfoJgsIH3b7vP8Pgu15BiK3gx4EmIZ09pyQ=.c1ead06a-8b31-41d3-8601-52c4ed8d854e@github.com>

On Fri, 16 Dec 2022 09:46:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34:
>> 
>>> 32: # Translators please note do not translate the options themselves
>>> 33: java.launcher.opt.footer = \    -cp <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    -classpath <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    --class-path <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n                  und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n    -p <Modulpfad>\n    --module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist.\n    --upgrade-module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n                  Module im Laufzeitimage ersetzen\n    --add-modules <Modulname>[,<Modulname>...]\n                  Root-Module, die zus\u00E4tzlich zum anf\u00E
 4nglichen Modul aufgel\u00F6st werden sollen.\n                  <Modulname> kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n                  ALL-MODULE-PATH.\n    --enable-native-access <Modulname>[,<Modulname>...]\n                  Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n                  <Modulname> kann auch ALL-UNNAMED lauten.\n    --list-modules\n                  Listet beobachtbare Module auf und beendet den Vorgang\n    -d <Modulname>\n    --describe-module <Modulname>\n                  Beschreibt ein Modul und beendet den Vorgang\n    --dry-run     Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n                  Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n                  Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n    --validate-modules\n                  Validiert alle Module und beendet den Vorgang\n                  Die Option "--va
 lidate-modules" kann n\u00FCtzlich sein, um\n                  Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n    -D<Name>=<Wert>\n                  Legt eine Systemeigenschaft fest\n    -verbose:[class|module|gc|jni]\n                  Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n    -version      Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n    --version      Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n    -showversion  Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n    --show-version\n                  Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n    --show-module-resolution\n                  Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n    -? -h -help\n                  Gibt diese Hilfemeldung an den Fehlerstream aus\n    --help        Gibt diese Hilfemeldung an den Outputstream aus\n    -X            Gibt Hil
 fe zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n    --help-extra  Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n    -ea[:<packagename>...|:<classname>]\n    -enableassertions[:<packagename>...|:<classname>]\n                  Aktiviert Assertions mit angegebener Granularit\u00E4t\n    -da[:<packagename>...|:<classname>]\n    -disableassertions[:<packagename>...|:<classname>]\n                  Deaktiviert Assertions mit angegebener Granularit\u00E4t\n    -esa | -enablesystemassertions\n                  Aktiviert System-Assertions\n    -dsa | -disablesystemassertions\n                  Deaktiviert System-Assertions\n    -agentlib:<libname>[=<options>]\n                  L\u00E4dt die native Agent Library <libname>. Beispiel: -agentlib:jdwp\n                  siehe auch -agentlib:jdwp=help\n    -agentpath:<pathname>[=<options>]\n                  L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n    -javaagent:<jarpath>[=<options>]
 \n                  \
>>> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n    -splash:<imagepath>\n                  Zeigt den Startbildschirm mit einem angegebenen Bild an\n                  Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n                  falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n                  muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n                  Das am besten geeignete angegebene skalierte Bild wird\n                  automatisch ausgew\u00E4hlt.\n                  Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n    @argument files\n                  Eine oder mehrere Argumentdateien mit Optionen\n    -disable- at files\n                  Verhindert die weitere Erweiterung von Argumentdateien\n    --enable-preview\n                  L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument
  f\u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --<Name>=<Wert> oder\n--<Name> <Wert> verwenden.\n
>> 
>> This change seems wrong, unless I'm mistaken the option name is still  `--disable- at files`, not `-disable- at files`
>
> I'm unfortunately not familiar with any of these resources files,  and can't neither comment on any of the translated languages. I still had a look and spotted the glitch above - which seems to be an error introduced in the translation.
> Find-in-files revealed that the source is still using --disable- at files. See:
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/args.c#L131
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L1377
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/resources/launcher.properties#L121

Thanks for taking a look. I fixed this removed dash from the translation in the latest PR.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From honkar at openjdk.org  Fri Dec 16 17:25:53 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 16 Dec 2022 17:25:53 GMT
Subject: [jdk20] RFR: 8298905: Test
 "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because
 the frames of instruction does not display
In-Reply-To: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
References: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
Message-ID: <qfa9n-1ik4jPLlBu7NcISDTv1Dt9xl0eOtiLQ29XhxI=.eceaf8c3-2ee4-4dd5-bc35-95d94f9c6878@github.com>

On Fri, 16 Dec 2022 14:55:13 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> openjdk/jdk#9525 has changed behavior of PassFailJFrame.
> it doesn't call `setVisible()` from its constructor on instruction window anymore and some tests were not ready for that.
> 
> So adding `positionTestWindow()` fixes the issue.

Marked as reviewed by honkar (Committer).

Changes look good.

-------------

PR: https://git.openjdk.org/jdk20/pull/46


From prr at openjdk.org  Fri Dec 16 17:28:56 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 Dec 2022 17:28:56 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v6]
In-Reply-To: <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>
Message-ID: <FmlUsetmec4ajWf41qIKWiV_d6svun82djbObUKfyao=.bb2b49e5-3426-4d2d-9f8c-1167d867889d@github.com>

On Fri, 16 Dec 2022 17:02:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing dash

src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties line 430:

> 428: ProgressBarDemo.accessible_text_area_name=\u52A0\u8F7D\u7684\u6587\u672C\u6B63\u5728\u9010\u6E10\u589E\u591A
> 429: 
> 430: ProgressBarDemo.accessible_text_area_description=\u8FD9\u4E2A JTextArea \u7531\u6765\u81EA\u7F13\u51B2\u533A\u7684\u6587\u672C\u9010\u4E2A\u5B57\u7B26\u5730\u586B\u5145, \u540C\u65F6\u7A97\u53E3\u5E95\u90E8\u7684\u8FDB\u5EA6\u680F\u5C06\u663E\u793A\u52A0\u8F7D\u7684\u8FDB\u5EA6

I was asked to review SwingSet2 changes but this isn't code.
But apparently I am not the right person to review this since I cannot understand the changes (not a DE, CN, or JA language expert) nor the reason for them. If this is a change to a unicode comma (as implied in an off-review message), I have no idea why .. it seems to be just asking for trouble.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Fri Dec 16 17:42:17 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:42:17 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v7]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <joe6G_LIkLeUlpKw1IqhH00g23fEFnyi4ItJUUbQDxk=.89bfe214-866a-4e27-98eb-ba925b45dd05@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert swingset. Consistency in CN

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/62a19a83..fe18e4ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=05-06

  Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Fri Dec 16 17:45:05 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:45:05 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
 <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
 <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>
Message-ID: <ImfItIZ3kWNbX8DHMnA4-zo1_fkH8J_A6-1ZiRzRNR8=.fed31abb-ab70-440f-90ad-902588875929@github.com>

On Fri, 16 Dec 2022 15:02:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK?
>
> Yes, you can replace all "??????" (that is not after ""???") to "?????????".
> 
> There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`.

Hi @wangweij , I believe I fixed the occurrences of "??????" and replaced them with "?????????". This translation drop does not update `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. So, this may be a separate request. If that file is selected for extraction in the next drop in January, then it could also be fixed then. 

Could you re-review the current changes for this drop?

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From duke at openjdk.org  Fri Dec 16 17:46:52 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Fri, 16 Dec 2022 17:46:52 GMT
Subject: [jdk20] RFR: 8298905: Test
 "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because
 the frames of instruction does not display
In-Reply-To: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
References: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
Message-ID: <vDH4SD4w_6fZkYfoy3MYzvJ7pMxGZGJcnV_PpU1scvw=.6ea4fda2-5044-4b6d-adc8-d6a9cc07ac04@github.com>

On Fri, 16 Dec 2022 14:55:13 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> openjdk/jdk#9525 has changed behavior of PassFailJFrame.
> it doesn't call `setVisible()` from its constructor on instruction window anymore and some tests were not ready for that.
> 
> So adding `positionTestWindow()` fixes the issue.

Can you fix the summary of "Tests if JComboBox displays correctly when editable/non-editable" of ProgressTest.java

-------------

PR: https://git.openjdk.org/jdk20/pull/46


From dnguyen at openjdk.org  Fri Dec 16 17:51:19 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:51:19 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v8]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <HHXCd5IsWRZEjWoBRIxu95AEttEQXvgPx-uzGBjHn8I=.34a5040a-1cf9-4ac2-b664-b710cab2e7cf@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Swingset newline

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/fe18e4ea..f058a1de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=06-07

  Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35


From dnguyen at openjdk.org  Fri Dec 16 17:51:20 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:51:20 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <FmlUsetmec4ajWf41qIKWiV_d6svun82djbObUKfyao=.bb2b49e5-3426-4d2d-9f8c-1167d867889d@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>
 <FmlUsetmec4ajWf41qIKWiV_d6svun82djbObUKfyao=.bb2b49e5-3426-4d2d-9f8c-1167d867889d@github.com>
Message-ID: <Z2W3BZQLpjHfGyASnkwSyvXnU9U0eou4iovSpNWPrX8=.896c41fd-df2d-4cac-be80-7cb28c32959c@github.com>

On Fri, 16 Dec 2022 17:26:18 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert old translation. Fix lang codes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties line 430:
> 
>> 428: ProgressBarDemo.accessible_text_area_name=\u52A0\u8F7D\u7684\u6587\u672C\u6B63\u5728\u9010\u6E10\u589E\u591A
>> 429: 
>> 430: ProgressBarDemo.accessible_text_area_description=\u8FD9\u4E2A JTextArea \u7531\u6765\u81EA\u7F13\u51B2\u533A\u7684\u6587\u672C\u9010\u4E2A\u5B57\u7B26\u5730\u586B\u5145\uFF0C\u540C\u65F6\u7A97\u53E3\u5E95\u90E8\u7684\u8FDB\u5EA6\u680F\u5C06\u663E\u793A\u52A0\u8F7D\u7684\u8FDB\u5EA6
> 
> I was asked to review SwingSet2 changes but this isn't code.
> But apparently I am not the right person to review this since I cannot understand the changes (not a DE, CN, or JA language expert) nor the reason for them. If this is a change to a unicode comma (as implied in an off-review message), I have no idea why .. it seems to be just asking for trouble.

Thanks. I removed the changes to swingset's translation to avoid causing any issues.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From azvegint at openjdk.org  Fri Dec 16 17:54:35 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 16 Dec 2022 17:54:35 GMT
Subject: [jdk20] RFR: 8298970: Problem list
 java/awt/event/KeyEvent/KeyTyped/CtrlASCII.java
Message-ID: <MsXuBa8aCnzHnv2WhvowD-XqoC93npHIM5MJMnCmfOM=.5fe26553-7ee6-4ea7-9cf1-5f92bc01b41c@github.com>

This test was stabilized and removed from problemlist recently.
Looks like previous efforts of improving test stability was not enough to prevent crashed of a system.
It still may crash Xserver somehow(but never in single test run), this prevents normal ATR.

So problem listing the test.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.org/jdk20/pull/48/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=48&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298970
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/48.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/48/head:pull/48

PR: https://git.openjdk.org/jdk20/pull/48


From weijun at openjdk.org  Fri Dec 16 18:02:55 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Dec 2022 18:02:55 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <ImfItIZ3kWNbX8DHMnA4-zo1_fkH8J_A6-1ZiRzRNR8=.fed31abb-ab70-440f-90ad-902588875929@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
 <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
 <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>
 <ImfItIZ3kWNbX8DHMnA4-zo1_fkH8J_A6-1ZiRzRNR8=.fed31abb-ab70-440f-90ad-902588875929@github.com>
Message-ID: <szezmXXF_0qzSfcp7mcIRk885jnyJf63o7prZfi2VJ8=.e6528252-60de-45c9-9bbd-0157164d890f@github.com>

On Fri, 16 Dec 2022 17:41:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Yes, you can replace all "??????" (that is not after ""???") to "?????????".
>> 
>> There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`.
>
> Hi @wangweij , I believe I fixed the occurrences of "??????" and replaced them with "?????????". This translation drop does not update `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. So, this may be a separate request. If that file is selected for extraction in the next drop in January, then it could also be fixed then. 
> 
> Could you re-review the current changes for this drop?

The updated file looks fine to me. Thanks.

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From prr at openjdk.org  Fri Dec 16 18:38:52 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 Dec 2022 18:38:52 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
Message-ID: <bObcfMVaxCToOJcBgQ3TCPodNKgod65b2HohMsuNk9s=.bae92483-f3a2-4adf-bd71-3056ab59335e@github.com>

On Thu, 1 Dec 2022 19:38:44 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix pointer to jlong conversion on x86

src/java.desktop/share/native/libfreetype/src/base/ftcolor.c line 9:

> 7:  * Copyright (C) 2018-2022 by
> 8:  * David Turner, Robert Wilhelm, and Werner Lemberg.
> 9:  *

Per the above copyright appears neither you nor JetBrains have ownership of this file.
Therefore per the OCA you cannot contribute this file to OpenJDK.
If it is really needed, then as a pre-cursor step, it will need to be integrated as a 3rd party file as part of the freetype 3rd party library sources, and that will have to be done by an Oracle employee.

This is a blocker for moving forward.

-------------

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Fri Dec 16 18:49:55 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Fri, 16 Dec 2022 18:49:55 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <bObcfMVaxCToOJcBgQ3TCPodNKgod65b2HohMsuNk9s=.bae92483-f3a2-4adf-bd71-3056ab59335e@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
 <bObcfMVaxCToOJcBgQ3TCPodNKgod65b2HohMsuNk9s=.bae92483-f3a2-4adf-bd71-3056ab59335e@github.com>
Message-ID: <MSv3RbxPjfHQlAq4zu1uzs0Dc83rn5YDBuEXqI5uem4=.aef6fad5-3efd-4c72-9c2a-f97fe3aadabf@github.com>

On Fri, 16 Dec 2022 18:36:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix pointer to jlong conversion on x86
>
> src/java.desktop/share/native/libfreetype/src/base/ftcolor.c line 9:
> 
>> 7:  * Copyright (C) 2018-2022 by
>> 8:  * David Turner, Robert Wilhelm, and Werner Lemberg.
>> 9:  *
> 
> Per the above copyright appears neither you nor JetBrains have ownership of this file.
> Therefore per the OCA you cannot contribute this file to OpenJDK.
> If it is really needed, then as a pre-cursor step, it will need to be integrated as a 3rd party file as part of the freetype 3rd party library sources, and that will have to be done by an Oracle employee.
> 
> This is a blocker for moving forward.

Yes, I believe it is really needed. Extracting colored outlines wouldn't work without it.

-------------

PR: https://git.openjdk.org/jdk/pull/4798


From prr at openjdk.org  Fri Dec 16 19:41:53 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 Dec 2022 19:41:53 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <MSv3RbxPjfHQlAq4zu1uzs0Dc83rn5YDBuEXqI5uem4=.aef6fad5-3efd-4c72-9c2a-f97fe3aadabf@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
 <bObcfMVaxCToOJcBgQ3TCPodNKgod65b2HohMsuNk9s=.bae92483-f3a2-4adf-bd71-3056ab59335e@github.com>
 <MSv3RbxPjfHQlAq4zu1uzs0Dc83rn5YDBuEXqI5uem4=.aef6fad5-3efd-4c72-9c2a-f97fe3aadabf@github.com>
Message-ID: <R4t6-20S1hd8H71xGYByLoVWvmyqACdLB_2DUkbYhJw=.02c42d5c-e427-40d7-b1eb-2431dc349a85@github.com>

On Fri, 16 Dec 2022 18:46:59 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> src/java.desktop/share/native/libfreetype/src/base/ftcolor.c line 9:
>> 
>>> 7:  * Copyright (C) 2018-2022 by
>>> 8:  * David Turner, Robert Wilhelm, and Werner Lemberg.
>>> 9:  *
>> 
>> Per the above copyright appears neither you nor JetBrains have ownership of this file.
>> Therefore per the OCA you cannot contribute this file to OpenJDK.
>> If it is really needed, then as a pre-cursor step, it will need to be integrated as a 3rd party file as part of the freetype 3rd party library sources, and that will have to be done by an Oracle employee.
>> 
>> This is a blocker for moving forward.
>
> Yes, I believe it is really needed. Extracting colored outlines wouldn't work without it.

OK, I will submit a PR to take care of this soon.

-------------

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Fri Dec 16 19:50:54 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Fri, 16 Dec 2022 19:50:54 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <R4t6-20S1hd8H71xGYByLoVWvmyqACdLB_2DUkbYhJw=.02c42d5c-e427-40d7-b1eb-2431dc349a85@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
 <bObcfMVaxCToOJcBgQ3TCPodNKgod65b2HohMsuNk9s=.bae92483-f3a2-4adf-bd71-3056ab59335e@github.com>
 <MSv3RbxPjfHQlAq4zu1uzs0Dc83rn5YDBuEXqI5uem4=.aef6fad5-3efd-4c72-9c2a-f97fe3aadabf@github.com>
 <R4t6-20S1hd8H71xGYByLoVWvmyqACdLB_2DUkbYhJw=.02c42d5c-e427-40d7-b1eb-2431dc349a85@github.com>
Message-ID: <uSiS9dILM4zD8K1BZXguxHIMuK3DfEBqv_Yup3aVRIw=.ff39717c-2d8b-4e95-a8dd-43546cbd39c2@github.com>

On Fri, 16 Dec 2022 19:39:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> Yes, I believe it is really needed. Extracting colored outlines wouldn't work without it.
>
> OK, I will submit a PR to take care of this soon.

Thank you.

-------------

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Fri Dec 16 20:05:39 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Fri, 16 Dec 2022 20:05:39 GMT
Subject: [jdk20] RFR: 8298905: Test
 "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because
 the frames of instruction does not display [v2]
In-Reply-To: <vlSNk_qP1BZZ-_DcUmWV-UOkHRIMBxQLewKLYOYiR8g=.6cb36ed2-6355-4746-95a3-e1a23e2c6b8d@github.com>
References: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
 <vlSNk_qP1BZZ-_DcUmWV-UOkHRIMBxQLewKLYOYiR8g=.6cb36ed2-6355-4746-95a3-e1a23e2c6b8d@github.com>
Message-ID: <2mDN4lSRplZYh0AH1PszkIFF4G5vusCBzPuXiTe0zNY=.dc44222b-d3cb-486c-b4af-dac7760772d6@github.com>

On Fri, 16 Dec 2022 20:00:51 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> openjdk/jdk#9525 has changed behavior of PassFailJFrame.
>> it doesn't call `setVisible()` from its constructor on instruction window anymore and some tests were not ready for that.
>> 
>> So adding `positionTestWindow()` fixes the issue.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix bugid and summary for ProgressTest

test/jdk/javax/swing/ProgressMonitor/ProgressTest.java line 40:

> 38:     private static final String instructionsText =
> 39:             "A ProgressMonitor will be shown.\n" +
> 40:                     " If it shows blank progressbar after 2048MB bytes read,\n"+

Do you need this extra tab space?

-------------

PR: https://git.openjdk.org/jdk20/pull/46


From kizune at openjdk.org  Fri Dec 16 20:05:16 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 16 Dec 2022 20:05:16 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v3]
In-Reply-To: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
Message-ID: <NXcMk3wTplzKWLacaAQ0wJq-YKI73U3JJRSQEXcsYos=.bafc6435-0a7b-4de5-ada9-815f5dbb4d4f@github.com>

> Set the text caret to be visible but not blinking on the non-editable text area. Fix the regression test that becames unstable after the change.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Handle different cases where refresh rate can be set when component is in different states causing some confused result.
  Also added code that in case of non-editable text component reports the saved blink rate to avoid any problems with JCK testing.

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/21/files
  - new: https://git.openjdk.org/jdk20/pull/21/files/70da8f6a..3b9d9cfe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=21&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=21&range=01-02

  Stats: 21 lines in 1 file changed: 18 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/21/head:pull/21

PR: https://git.openjdk.org/jdk20/pull/21


From azvegint at openjdk.org  Fri Dec 16 20:05:37 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 16 Dec 2022 20:05:37 GMT
Subject: [jdk20] RFR: 8298905: Test
 "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because
 the frames of instruction does not display [v2]
In-Reply-To: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
References: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
Message-ID: <vlSNk_qP1BZZ-_DcUmWV-UOkHRIMBxQLewKLYOYiR8g=.6cb36ed2-6355-4746-95a3-e1a23e2c6b8d@github.com>

> openjdk/jdk#9525 has changed behavior of PassFailJFrame.
> it doesn't call `setVisible()` from its constructor on instruction window anymore and some tests were not ready for that.
> 
> So adding `positionTestWindow()` fixes the issue.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  fix bugid and summary for ProgressTest

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/46/files
  - new: https://git.openjdk.org/jdk20/pull/46/files/6ae5260e..8fbac73e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=46&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=46&range=00-01

  Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk20/pull/46.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/46/head:pull/46

PR: https://git.openjdk.org/jdk20/pull/46


From azvegint at openjdk.org  Fri Dec 16 20:05:38 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 16 Dec 2022 20:05:38 GMT
Subject: [jdk20] RFR: 8298905: Test
 "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because
 the frames of instruction does not display
In-Reply-To: <vDH4SD4w_6fZkYfoy3MYzvJ7pMxGZGJcnV_PpU1scvw=.6ea4fda2-5044-4b6d-adc8-d6a9cc07ac04@github.com>
References: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
 <vDH4SD4w_6fZkYfoy3MYzvJ7pMxGZGJcnV_PpU1scvw=.6ea4fda2-5044-4b6d-adc8-d6a9cc07ac04@github.com>
Message-ID: <w9AMhWV1Re0y2eJECqTxGLV3_ioL_07CNio1XZedQDQ=.e0471c4a-173b-4cbe-a4d7-3394ebc9e45e@github.com>

On Fri, 16 Dec 2022 17:44:32 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Can you fix the summary of "Tests if JComboBox displays correctly when editable/non-editable" of ProgressTest.java

Done, bug was also wrong

-------------

PR: https://git.openjdk.org/jdk20/pull/46


From kizune at openjdk.org  Fri Dec 16 20:05:17 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 16 Dec 2022 20:05:17 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v2]
In-Reply-To: <CZ-rPr-zEF9Htx7EhLj5SsWGtE_ejyoWJLzKPKt-55E=.708a04e7-e797-498b-aefd-1871f92ef41a@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <7lRrGCopXc6TOhPxpp4O7YP5L_z09DHG6Pd0Tj8kjgg=.c2177cce-78d9-40fd-8073-36b2eff352da@github.com>
 <CZ-rPr-zEF9Htx7EhLj5SsWGtE_ejyoWJLzKPKt-55E=.708a04e7-e797-498b-aefd-1871f92ef41a@github.com>
Message-ID: <3ujz2jiE8CXsCeSG3FgWf1TPv0xl2Fv7ltmWXXu5cWU=.662fd95b-11bd-41ed-8b40-2dfcc76da290@github.com>

On Fri, 16 Dec 2022 01:19:46 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed MultiSelectionText so it is now stable on Linux
>>   Removed both fixed tests from ProblemList
>
> src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 389:
> 
>> 387:             } else {
>> 388:                 if (getBlinkRate() != 0) {
>> 389:                     savedBlinkRate = getBlinkRate();
> 
> Look like this can override blink rate set by user:
> 
> 
> import javax.swing.JButton;
> import javax.swing.JFrame;
> import javax.swing.JTextField;
> import javax.swing.SwingUtilities;
> import java.awt.BorderLayout;
> import java.awt.Component;
> import java.awt.Robot;
> import java.lang.reflect.InvocationTargetException;
> 
> public class CaretThing {
> 
>     static JFrame frame;
>     static JTextField textField;
>     static Robot robot;
>     static JButton button;
> 
>     static void printBlinkRate() {
>         System.err.println("Caret blink rate: " + textField.getCaret().getBlinkRate());
>     }
> 
>     static void requestFocus(Component component) throws InterruptedException, InvocationTargetException {
>         robot.waitForIdle();
>         robot.delay(300);
> 
>         SwingUtilities.invokeAndWait(() -> {
>             System.err.println("Requesting focus on " + component);
>             printBlinkRate();
>             component.requestFocus();
>             printBlinkRate();
>         });
>     }
> 
>     static void changeEditable() throws InterruptedException, InvocationTargetException {
>         robot.waitForIdle();
>         robot.delay(300);
>         SwingUtilities.invokeAndWait(()-> {
>             System.err.println("Changing editable");
>             printBlinkRate();
>             textField.setEditable(!textField.isEditable());
>             printBlinkRate();
>         });
>     }
> 
>     public static void main(String[] args) throws Exception {
>         robot = new Robot();
>         robot.setAutoWaitForIdle(true);
>         robot.setAutoDelay(50);
> 
>         SwingUtilities.invokeAndWait(() -> {
>             frame = new JFrame("Hey");
>             frame.setLocationRelativeTo(null);
>             textField = new JTextField("Some long field value");
> 
>             textField.setEditable(false);
>             frame.setLayout(new BorderLayout());
>             frame.add(textField, BorderLayout.NORTH);
> 
>             button = new JButton("Button");
>             button.addActionListener((e)-> printBlinkRate());
> 
>             frame.add(button, BorderLayout.CENTER);
>             frame.pack();
>             frame.setVisible(true);
> 
>             button.requestFocus();
>             textField.getCaret().setBlinkRate(2500);
>         });
> 
>         requestFocus(textField);
> 
>         requestFocus(button); // comment this to get 0 blink rate on editable field
> 
>         changeEditable();
> 
>         requestFocus(textField);
> 
>         SwingUtilities.invokeAndWait(CaretThing::printBlinkRate);
>     }
> }
> 
> Running the sample above at least two possible misbehaviors(tested on Linux):
> * you will receive blink rate `500` instead of user set `2500`
> * but if you comment `requestFocus(button);` line then blink rate will be `0` (it shows non-blinking cursor)
> 
> <hr>
> 
> Other than that I am worried about `getBlinkRate()` does not return the same value as passed to`setBlinkRate()` (e.g. case when component is not editable, possible JCK issue?)

I updated the code now the behaviour is correct (as far as i tested) and the blink rate is reported as if it is set to the correct value even on non-editable text element.

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From kizune at openjdk.org  Fri Dec 16 21:12:58 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 16 Dec 2022 21:12:58 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v2]
In-Reply-To: <CZ-rPr-zEF9Htx7EhLj5SsWGtE_ejyoWJLzKPKt-55E=.708a04e7-e797-498b-aefd-1871f92ef41a@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <7lRrGCopXc6TOhPxpp4O7YP5L_z09DHG6Pd0Tj8kjgg=.c2177cce-78d9-40fd-8073-36b2eff352da@github.com>
 <CZ-rPr-zEF9Htx7EhLj5SsWGtE_ejyoWJLzKPKt-55E=.708a04e7-e797-498b-aefd-1871f92ef41a@github.com>
Message-ID: <jYR5H8P259BJpeq6uIpaA7wdCUYHBFsyVdIbeeI6Jgg=.9482f406-c559-4fd9-927e-ef6a9e1ee0c7@github.com>

On Thu, 15 Dec 2022 20:09:35 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed MultiSelectionText so it is now stable on Linux
>>   Removed both fixed tests from ProblemList
>
> src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 1050:
> 
>> 1048:                     flasher = new Timer(rate, handler);
>> 1049:                 }
>> 1050:                 flasher.setDelay(rate);
> 
> Coming back to negative rate, looks like this changes the previous behavior:
> 
> Before the fix it did throw IAE in all cases:
> 
> https://github.com/openjdk/jdk20/blob/ca39eb906692568347e7f264520593188f9276cf/src/java.desktop/share/classes/javax/swing/Timer.java#L397-L406
> 
> After the fix IAE is thrown only if component is editable<br>
> In case of non-editable and may throw it way later after `setEditable(true)` call and focus gain.

Fixed.

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From dnguyen at openjdk.org  Fri Dec 16 21:18:58 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 21:18:58 GMT
Subject: [jdk20] Integrated: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <3RA_5D04t20xCtp1jJI-KMZt7Ev8f7bJv2zlanOnE-E=.d82daa27-fd0d-4eca-88cd-61ace8ba0d4a@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

This pull request has now been integrated.

Changeset: c997b5bf
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/c997b5bffd0ebbd6d68332572639c8cea05ccdb1
Stats:     1128 lines in 99 files changed: 783 ins; 198 del; 147 mod

8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10

Reviewed-by: achung, naoto, joehw, cjplummer, almatvee

-------------

PR: https://git.openjdk.org/jdk20/pull/35


From azvegint at openjdk.org  Sat Dec 17 00:07:23 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 17 Dec 2022 00:07:23 GMT
Subject: [jdk20] RFR: 8298905: Test
 "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because
 the frames of instruction does not display [v3]
In-Reply-To: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
References: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
Message-ID: <vqMI4uMBhfx7MlyC1RcXKS6ziId2ymwijAXm0RfAnSI=.c6f08332-ebbd-4db2-9ea7-7d1cb0599726@github.com>

> openjdk/jdk#9525 has changed behavior of PassFailJFrame.
> it doesn't call `setVisible()` from its constructor on instruction window anymore and some tests were not ready for that.
> 
> So adding `positionTestWindow()` fixes the issue.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  fix spacing

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/46/files
  - new: https://git.openjdk.org/jdk20/pull/46/files/8fbac73e..eb179ee7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=46&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=46&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/46.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/46/head:pull/46

PR: https://git.openjdk.org/jdk20/pull/46


From duke at openjdk.org  Sat Dec 17 00:07:41 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Sat, 17 Dec 2022 00:07:41 GMT
Subject: [jdk20] RFR: 8298905: Test
 "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because
 the frames of instruction does not display [v2]
In-Reply-To: <vlSNk_qP1BZZ-_DcUmWV-UOkHRIMBxQLewKLYOYiR8g=.6cb36ed2-6355-4746-95a3-e1a23e2c6b8d@github.com>
References: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
 <vlSNk_qP1BZZ-_DcUmWV-UOkHRIMBxQLewKLYOYiR8g=.6cb36ed2-6355-4746-95a3-e1a23e2c6b8d@github.com>
Message-ID: <nLTzeCos46JvAkR9drCd5C1g0P8uRIWww2sYaR2DVdg=.b5d6082f-c87d-490e-97b4-fb3818f2896a@github.com>

On Fri, 16 Dec 2022 20:05:37 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> openjdk/jdk#9525 has changed behavior of PassFailJFrame.
>> it doesn't call `setVisible()` from its constructor on instruction window anymore and some tests were not ready for that.
>> 
>> So adding `positionTestWindow()` fixes the issue.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix bugid and summary for ProgressTest

Looks good to me.

-------------

PR: https://git.openjdk.org/jdk20/pull/46


From azvegint at openjdk.org  Sat Dec 17 01:17:51 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 17 Dec 2022 01:17:51 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v3]
In-Reply-To: <NXcMk3wTplzKWLacaAQ0wJq-YKI73U3JJRSQEXcsYos=.bafc6435-0a7b-4de5-ada9-815f5dbb4d4f@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <NXcMk3wTplzKWLacaAQ0wJq-YKI73U3JJRSQEXcsYos=.bafc6435-0a7b-4de5-ada9-815f5dbb4d4f@github.com>
Message-ID: <YgnDYmLWKVpu9WnBZJ3tWIV-K4dR8SOh3aNF0EY4zcI=.18365b2d-2ba4-4a22-91dc-300428c430b9@github.com>

On Fri, 16 Dec 2022 20:05:16 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Set the text caret to be visible but not blinking on the non-editable text area. Fix the regression test that becames unstable after the change.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handle different cases where refresh rate can be set when component is in different states causing some confused result.
>   Also added code that in case of non-editable text component reports the saved blink rate to avoid any problems with JCK testing.

src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 370:

> 368: 
> 369:     private int savedBlinkRate = 0;
> 370:     private boolean blinkRateSaved = false;

Naming of `savedBlinkRate` and `blinkRateSaved` looks almost the same and confusing for me.
Probably `isBlinkRateSaved` would be better to highlight boolean variable.

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From azvegint at openjdk.org  Sat Dec 17 01:17:53 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 17 Dec 2022 01:17:53 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v2]
In-Reply-To: <3ujz2jiE8CXsCeSG3FgWf1TPv0xl2Fv7ltmWXXu5cWU=.662fd95b-11bd-41ed-8b40-2dfcc76da290@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <7lRrGCopXc6TOhPxpp4O7YP5L_z09DHG6Pd0Tj8kjgg=.c2177cce-78d9-40fd-8073-36b2eff352da@github.com>
 <CZ-rPr-zEF9Htx7EhLj5SsWGtE_ejyoWJLzKPKt-55E=.708a04e7-e797-498b-aefd-1871f92ef41a@github.com>
 <3ujz2jiE8CXsCeSG3FgWf1TPv0xl2Fv7ltmWXXu5cWU=.662fd95b-11bd-41ed-8b40-2dfcc76da290@github.com>
Message-ID: <i9ki_jaoGPHJyKQW2PG-wrac22yJEMQ-ghWwK8cuYnM=.22e31d8c-f89b-4dd7-9f4b-5886ffcdd8fb@github.com>

On Fri, 16 Dec 2022 19:59:30 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 389:
>> 
>>> 387:             } else {
>>> 388:                 if (getBlinkRate() != 0) {
>>> 389:                     savedBlinkRate = getBlinkRate();
>> 
>> Look like this can override blink rate set by user:
>> 
>> 
>> import javax.swing.JButton;
>> import javax.swing.JFrame;
>> import javax.swing.JTextField;
>> import javax.swing.SwingUtilities;
>> import java.awt.BorderLayout;
>> import java.awt.Component;
>> import java.awt.Robot;
>> import java.lang.reflect.InvocationTargetException;
>> 
>> public class CaretThing {
>> 
>>     static JFrame frame;
>>     static JTextField textField;
>>     static Robot robot;
>>     static JButton button;
>> 
>>     static void printBlinkRate() {
>>         System.err.println("Caret blink rate: " + textField.getCaret().getBlinkRate());
>>     }
>> 
>>     static void requestFocus(Component component) throws InterruptedException, InvocationTargetException {
>>         robot.waitForIdle();
>>         robot.delay(300);
>> 
>>         SwingUtilities.invokeAndWait(() -> {
>>             System.err.println("Requesting focus on " + component);
>>             printBlinkRate();
>>             component.requestFocus();
>>             printBlinkRate();
>>         });
>>     }
>> 
>>     static void changeEditable() throws InterruptedException, InvocationTargetException {
>>         robot.waitForIdle();
>>         robot.delay(300);
>>         SwingUtilities.invokeAndWait(()-> {
>>             System.err.println("Changing editable");
>>             printBlinkRate();
>>             textField.setEditable(!textField.isEditable());
>>             printBlinkRate();
>>         });
>>     }
>> 
>>     public static void main(String[] args) throws Exception {
>>         robot = new Robot();
>>         robot.setAutoWaitForIdle(true);
>>         robot.setAutoDelay(50);
>> 
>>         SwingUtilities.invokeAndWait(() -> {
>>             frame = new JFrame("Hey");
>>             frame.setLocationRelativeTo(null);
>>             textField = new JTextField("Some long field value");
>> 
>>             textField.setEditable(false);
>>             frame.setLayout(new BorderLayout());
>>             frame.add(textField, BorderLayout.NORTH);
>> 
>>             button = new JButton("Button");
>>             button.addActionListener((e)-> printBlinkRate());
>> 
>>             frame.add(button, BorderLayout.CENTER);
>>             frame.pack();
>>             frame.setVisible(true);
>> 
>>             button.requestFocus();
>>             textField.getCaret().setBlinkRate(2500);
>>         });
>> 
>>         requestFocus(textField);
>> 
>>         requestFocus(button); // comment this to get 0 blink rate on editable field
>> 
>>         changeEditable();
>> 
>>         requestFocus(textField);
>> 
>>         SwingUtilities.invokeAndWait(CaretThing::printBlinkRate);
>>     }
>> }
>> 
>> Running the sample above at least two possible misbehaviors(tested on Linux):
>> * you will receive blink rate `500` instead of user set `2500`
>> * but if you comment `requestFocus(button);` line then blink rate will be `0` (it shows non-blinking cursor)
>> 
>> <hr>
>> 
>> Other than that I am worried about `getBlinkRate()` does not return the same value as passed to`setBlinkRate()` (e.g. case when component is not editable, possible JCK issue?)
>
> I updated the code now the behaviour is correct (as far as i tested) and the blink rate is reported as if it is set to the correct value even on non-editable text element.

I am still having issue with non-blinking cursor on editable field with the latest version of the fix.

Fails for me with test provided above and commented `requestFocus(button);` line.

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From serb at openjdk.org  Sat Dec 17 02:27:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 17 Dec 2022 02:27:51 GMT
Subject: [jdk20] RFR: 8298905: Test
 "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because
 the frames of instruction does not display [v3]
In-Reply-To: <vqMI4uMBhfx7MlyC1RcXKS6ziId2ymwijAXm0RfAnSI=.c6f08332-ebbd-4db2-9ea7-7d1cb0599726@github.com>
References: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
 <vqMI4uMBhfx7MlyC1RcXKS6ziId2ymwijAXm0RfAnSI=.c6f08332-ebbd-4db2-9ea7-7d1cb0599726@github.com>
Message-ID: <MDc64RSgFxlAzOFCX5BMg_9HIpPBRIxzSbU1Zk-DjTQ=.9b5ff29c-634f-454c-ab72-02fe82a3d4b9@github.com>

On Sat, 17 Dec 2022 00:07:23 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> openjdk/jdk#9525 has changed behavior of PassFailJFrame.
>> it doesn't call `setVisible()` from its constructor on instruction window anymore and some tests were not ready for that.
>> 
>> So adding `positionTestWindow()` fixes the issue.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix spacing

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/46


From serb at openjdk.org  Sat Dec 17 02:29:49 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 17 Dec 2022 02:29:49 GMT
Subject: [jdk20] RFR: 8298970: Problem list
 java/awt/event/KeyEvent/KeyTyped/CtrlASCII.java
In-Reply-To: <MsXuBa8aCnzHnv2WhvowD-XqoC93npHIM5MJMnCmfOM=.5fe26553-7ee6-4ea7-9cf1-5f92bc01b41c@github.com>
References: <MsXuBa8aCnzHnv2WhvowD-XqoC93npHIM5MJMnCmfOM=.5fe26553-7ee6-4ea7-9cf1-5f92bc01b41c@github.com>
Message-ID: <zzcmU0UIR64pPYQkVwJxh2LZ73O9UKxa84BqYwDS14Q=.6ffcd6b3-4ead-4301-a2a7-d1ce641517b7@github.com>

On Fri, 16 Dec 2022 17:48:27 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test was stabilized and removed from problemlist recently.
> Looks like previous efforts of improving test stability was not enough to prevent crashed of a system.
> It still may crash Xserver somehow(but never in single test run), this prevents normal ATR.
> 
> So problem listing the test.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/48


From aghaisas at openjdk.org  Sat Dec 17 06:40:55 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Sat, 17 Dec 2022 06:40:55 GMT
Subject: [jdk20] Integrated: 8298217: Regressions 30-110% in SwingMark on
 MacOS, more so on aarch64
In-Reply-To: <rUqDSIQtk_Gz6GhS7zXmSyTpO6Rxf3i8pfcx4gfKSJY=.12663f0d-ec12-4f8b-a310-58b883da4cc8@github.com>
References: <rUqDSIQtk_Gz6GhS7zXmSyTpO6Rxf3i8pfcx4gfKSJY=.12663f0d-ec12-4f8b-a310-58b883da4cc8@github.com>
Message-ID: <vKIV_nMYRwYsOjzDbtbH7jOPpDlWLN88r62EsX-5y_o=.f064cb25-2337-4ff8-b882-fc815d8958ca@github.com>

On Fri, 16 Dec 2022 15:20:14 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> The nature of data plays an important part in rendering performance as noted in the comment made on [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) -
> https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14504772
> 
> Although the fix [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) is logical, it seems to have an adverse impact on SwingMark test numbers especially on aarch64.
> 
> The SwingMark tests closely depict the UI operations in real-world applications as compared to the J2DBench and RenderPerfTest tests. Hence, it is decided to revert the regression causing commits [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) (and dependent [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266)).
> 
> Metal rendering pipeline performance numbers before and after this PR are attached to the JBS.
> 
> Note : The fix for [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) has a good regression test - DrawPrimitivesTest.java. It passes even after reverting the said changes. This test will be added back once this PR is committed.

This pull request has now been integrated.

Changeset: 3b7970ca
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/3b7970cab39a67eabcde331822f0432f71d9186b
Stats:     406 lines in 5 files changed: 27 ins; 302 del; 77 mod

8298217: Regressions 30-110% in SwingMark on MacOS, more so on aarch64

Reviewed-by: avu, prr, jdv

-------------

PR: https://git.openjdk.org/jdk20/pull/47


From azvegint at openjdk.org  Sat Dec 17 13:31:51 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 17 Dec 2022 13:31:51 GMT
Subject: [jdk20] Integrated: 8298970: Problem list
 java/awt/event/KeyEvent/KeyTyped/CtrlASCII.java
In-Reply-To: <MsXuBa8aCnzHnv2WhvowD-XqoC93npHIM5MJMnCmfOM=.5fe26553-7ee6-4ea7-9cf1-5f92bc01b41c@github.com>
References: <MsXuBa8aCnzHnv2WhvowD-XqoC93npHIM5MJMnCmfOM=.5fe26553-7ee6-4ea7-9cf1-5f92bc01b41c@github.com>
Message-ID: <MQ1_XtjopKTcixAI1Da-Htr6iyN29F8Ntz6AknNK98U=.7cc17718-ff65-46ad-82c9-4e5f145fe5b1@github.com>

On Fri, 16 Dec 2022 17:48:27 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test was stabilized and removed from problemlist recently.
> Looks like previous efforts of improving test stability was not enough to prevent crashed of a system.
> It still may crash Xserver somehow(but never in single test run), this prevents normal ATR.
> 
> So problem listing the test.

This pull request has now been integrated.

Changeset: 41cc0443
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/41cc04430ab9e6db31ea26b5254668c9ab18966d
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8298970: Problem list java/awt/event/KeyEvent/KeyTyped/CtrlASCII.java

Reviewed-by: serb

-------------

PR: https://git.openjdk.org/jdk20/pull/48


From azvegint at openjdk.org  Sat Dec 17 13:33:51 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 17 Dec 2022 13:33:51 GMT
Subject: [jdk20] Integrated: 8298905: Test
 "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because
 the frames of instruction does not display
In-Reply-To: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
References: <XTOONHNggKEVf2xkcwoBDSymAoqHeD3stlD8rt_uy7s=.56678ad1-02e4-460d-aeef-8bf226cd3eaf@github.com>
Message-ID: <xcjQt6AEZxgxtgdckh8W5spPwOvI1RF1gdXJkM3v9N8=.29ce7f03-1ec8-4042-a761-efb173874951@github.com>

On Fri, 16 Dec 2022 14:55:13 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> openjdk/jdk#9525 has changed behavior of PassFailJFrame.
> it doesn't call `setVisible()` from its constructor on instruction window anymore and some tests were not ready for that.
> 
> So adding `positionTestWindow()` fixes the issue.

This pull request has now been integrated.

Changeset: d1026720
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/d1026720d323d0acd9bd8d85d5caba7185107863
Stats:     12 lines in 3 files changed: 4 ins; 4 del; 4 mod

8298905: Test "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because the frames of instruction does not display

Reviewed-by: honkar, serb

-------------

PR: https://git.openjdk.org/jdk20/pull/46


From kizune at openjdk.org  Sat Dec 17 18:16:30 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 17 Dec 2022 18:16:30 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v4]
In-Reply-To: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
Message-ID: <NRfMMYYQnxZK2pDgsnNIHSO4zfgRAxpIjId9YTfPxyo=.406f49f6-ca85-4758-b9e3-314cd59c913e@github.com>

> Set the text caret to be visible but not blinking on the non-editable text area. Fix the regression test that becames unstable after the change.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Fixing situation where we can be stuck with non-blinking cursor after editable state switched on a focused text field

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/21/files
  - new: https://git.openjdk.org/jdk20/pull/21/files/3b9d9cfe..abf5d77d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=21&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=21&range=02-03

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/21/head:pull/21

PR: https://git.openjdk.org/jdk20/pull/21


From kizune at openjdk.org  Sat Dec 17 18:21:09 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 17 Dec 2022 18:21:09 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v5]
In-Reply-To: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
Message-ID: <DL1Kou1vfwENoSwDzsv5Bo6exW8hnRuf4hLjAB2-4qs=.a354de75-206f-4256-9f2f-395a20d5752f@github.com>

> Set the text caret to be visible but not blinking on the non-editable text area. Fix the regression test that becames unstable after the change.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Renamed blinkRateSaved to isBlinkRateSaved

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/21/files
  - new: https://git.openjdk.org/jdk20/pull/21/files/abf5d77d..e11d54b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=21&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=21&range=03-04

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk20/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/21/head:pull/21

PR: https://git.openjdk.org/jdk20/pull/21


From kizune at openjdk.org  Sat Dec 17 18:21:10 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 17 Dec 2022 18:21:10 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v3]
In-Reply-To: <YgnDYmLWKVpu9WnBZJ3tWIV-K4dR8SOh3aNF0EY4zcI=.18365b2d-2ba4-4a22-91dc-300428c430b9@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <NXcMk3wTplzKWLacaAQ0wJq-YKI73U3JJRSQEXcsYos=.bafc6435-0a7b-4de5-ada9-815f5dbb4d4f@github.com>
 <YgnDYmLWKVpu9WnBZJ3tWIV-K4dR8SOh3aNF0EY4zcI=.18365b2d-2ba4-4a22-91dc-300428c430b9@github.com>
Message-ID: <l1ZPb5TWUbT0cw9QF5fUf36vF51BH-x15WA5W0KHv-g=.b212c07c-ccd1-43b4-b870-f1cf4b1d35e8@github.com>

On Sat, 17 Dec 2022 01:08:12 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Handle different cases where refresh rate can be set when component is in different states causing some confused result.
>>   Also added code that in case of non-editable text component reports the saved blink rate to avoid any problems with JCK testing.
>
> src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 370:
> 
>> 368: 
>> 369:     private int savedBlinkRate = 0;
>> 370:     private boolean blinkRateSaved = false;
> 
> Naming of `savedBlinkRate` and `blinkRateSaved` looks almost the same and confusing for me.
> Probably `isBlinkRateSaved` would be better to highlight boolean variable.

Fixed.

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From kizune at openjdk.org  Sat Dec 17 18:22:50 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 17 Dec 2022 18:22:50 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v4]
In-Reply-To: <NRfMMYYQnxZK2pDgsnNIHSO4zfgRAxpIjId9YTfPxyo=.406f49f6-ca85-4758-b9e3-314cd59c913e@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <NRfMMYYQnxZK2pDgsnNIHSO4zfgRAxpIjId9YTfPxyo=.406f49f6-ca85-4758-b9e3-314cd59c913e@github.com>
Message-ID: <i3926sIgsivhMBwgf8PG3vAyDz3GNm4of_inyVXnXw4=.fc69fc3b-ed19-442a-8168-b1eb0ad4eaa0@github.com>

On Sat, 17 Dec 2022 18:16:30 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Set the text caret to be visible but not blinking on the non-editable text area. Fix the regression test that becames unstable after the change.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing situation where we can be stuck with non-blinking cursor after editable state switched on a focused text field

Ok, i fixed the permanent blinking caret glitch. Now it is non-blinking until the focus is lost and regained. Which is an improvement, without this fix the caret would be invisible until the focus lost.

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From tr at openjdk.org  Mon Dec 19 05:43:51 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 19 Dec 2022 05:43:51 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null'
In-Reply-To: <R0YD-SmeN5hDOm8HhHha0n14VjbNTa3rnqTyrg79w50=.b2faae9c-60a1-4eb4-93ee-b3cfbebe57ce@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <ddjbSHKmT8CjLCSqK18vAfCREE3FHGTGDs7-gCkPll8=.9b04029f-ff3e-41cf-9417-72fac385f3bd@github.com>
 <3izbzkcKMwbewfAYqjBciua3KIDOO4pVl7mwUQTEOLY=.e829dd17-3ecb-4abd-a3b6-24430c9f40c7@github.com>
 <R0YD-SmeN5hDOm8HhHha0n14VjbNTa3rnqTyrg79w50=.b2faae9c-60a1-4eb4-93ee-b3cfbebe57ce@github.com>
Message-ID: <NgxB2Wx9xaybJEI-4AmwOkSGpeXabMulXxEs0nVsng4=.c9ba92b0-0400-4dff-b3a3-21877e8c2341@github.com>

On Wed, 14 Dec 2022 15:53:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> > @aivanov-jdk I just run some test samples by making the test as headful instead as headless as @prsadhuk suggested. I found out that making it as headful works just fine and no NPE occurred (Headless always showed issue, 8/200 test). And debugging to the root cause of Image not loading is also quite difficult. I guess it's better to modify the test as headful since the reliability of the test is better in it?
>>> 
>>> Let's go for it. A headless system could lack something that the test uses even though it doesn't show the UI.
>>> 
>>> If _headful_ systems never reproduce the problem, then it's _the fix_.
>> 
>> So far, from the analysis it is found that the backup mechanism to get default Icon is failing when icon extraction fails. Not able to get the trigger point for the failure since it is unpredictable. Failure rate also seems to be dependent on system, last week used to get consistent failures for every test run, this week the issue is not much. So I guess making the test headful is better option now.
>
>> So far, from the analysis it is found that the backup mechanism to get default Icon is failing when icon extraction fails.
> 
> These are the new details which you've never mentioned before.
> 
> The icon extraction of a folder (presumably _Downloads_ folder) fails. The fallback is to extract the default icon for a folder, which also fails.
> 
> Do I understand it correctly?

@aivanov-jdk I have updated the PR with the above fix, can you please review and let me know if it's Ok.

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From tr at openjdk.org  Mon Dec 19 06:19:50 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 19 Dec 2022 06:19:50 GMT
Subject: RFR: 4365952: Cannot disable JFileChooser
In-Reply-To: <mL3XuLE5dmPwZqycm29mP3Pj1tVjKXMNnOPvk4VxSFA=.071dc2fc-95d8-4979-82de-e2eaccb8c1c3@github.com>
References: <0Pc6eSRN_L1pKaaKHb3-af86bTOyMn6oJ9wfC1LOvjA=.a6aa5a9e-58bb-4ca3-847c-0d7ad1473faf@github.com>
 <qL0vp6t4z-C4FkX8nnZHeffTmIw2yyTQQ6toL2Sb1Lg=.f629cd98-3ccb-45da-8c90-8f8b13ce5300@github.com>
 <PUgQT39rFt8h5SeaWsB73msIGFlZPGqnQmhoZET0i5U=.8a1828e6-39ca-4267-9e72-1bf3c1c6a226@github.com>
 <0TqJ4e6TSzKz0QgGNTdfAvjTKfXq969V95YyMq97_Xc=.abf8a67a-1be4-4464-afa7-401b7c963f72@github.com>
 <h22R-UBZ6rYPVM_NzfAxrL7O8VfO27Wibcp1tcF3hc4=.66183c3d-10fd-4dfa-849a-8a70d80803cf@github.com>
 <mL3XuLE5dmPwZqycm29mP3Pj1tVjKXMNnOPvk4VxSFA=.071dc2fc-95d8-4979-82de-e2eaccb8c1c3@github.com>
Message-ID: <ZN-_mP0kRWcA1lAZddczEF4VzvtHxAzX-jVUfrYxZ9k=.9c7d87fc-fc50-462f-a862-616e97efbd99@github.com>

On Thu, 8 Dec 2022 09:09:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I guess for frame, the disable/enable functionality is handled by the peer (Windows it is `WFramePeer`), whereas for the swing components it should be the components itself like it is for all other components (Like in AbstractButton, JComboBox, JList).
>
> The JFileChooser is also kind of top level component and it has the peer. Current patch does not work as intended. On macOS in Nimbus/Metal L&F the list of files looks disabled but scrolling works. On Aqua L&F the list of files does not look like disabled, accept scroll and double clicks, but does not accept single clicks.

@mrserb, you are right on double and scrolling still working after the fix. I'm working on debugging the root cause, which I think something to do with filepane class. Parallel to that I am working on your comment previous comments too.

-------------

PR: https://git.openjdk.org/jdk/pull/11553


From smandalika at openjdk.org  Mon Dec 19 08:37:30 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Mon, 19 Dec 2022 08:37:30 GMT
Subject: RFR: 8298921: Create a regression test for JDK-8139581
Message-ID: <lkasNa1F7wgDFUbBBlSzzve1p3DmJHqmyV6ELZd_BQs=.51d1cbf0-3c97-40d4-8892-d6c214674d94@github.com>

Create a regression test for JDK-8139581

As described in JDK-8139581, when an AWT panel with AWT components, for example "java.awt.Button", is removed from AWT frame and added again to the same frame, then some AWT components contained in the panel are not drawn, however, clicking in the area of not drawn button leads to drawing of the button.

Test has a swing and awt component in a panel. It then removes and adds back the panel from/into the frame, to verify that they are repainted back properly.

-------------

Commit messages:
 - 8298921: Create a regression test for JDK-8139581
 - Merge branch 'master' of github.com:openjdk/jdk
 - 8297481: Create a regression test for JDK-4424517

Changes: https://git.openjdk.org/jdk/pull/11707/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11707&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298921
  Stats: 203 lines in 1 file changed: 203 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11707.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11707/head:pull/11707

PR: https://git.openjdk.org/jdk/pull/11707


From smandalika at openjdk.org  Mon Dec 19 08:37:30 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Mon, 19 Dec 2022 08:37:30 GMT
Subject: RFR: 8298921: Create a regression test for JDK-8139581
In-Reply-To: <lkasNa1F7wgDFUbBBlSzzve1p3DmJHqmyV6ELZd_BQs=.51d1cbf0-3c97-40d4-8892-d6c214674d94@github.com>
References: <lkasNa1F7wgDFUbBBlSzzve1p3DmJHqmyV6ELZd_BQs=.51d1cbf0-3c97-40d4-8892-d6c214674d94@github.com>
Message-ID: <66uaW9Fm-TAQotzAZaOqhkEWh_5PrSBgjDA9RtjzxLs=.bf3e9077-0b35-464c-b59e-0f6689c524cf@github.com>

On Fri, 16 Dec 2022 10:21:35 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create a regression test for JDK-8139581
> 
> As described in JDK-8139581, when an AWT panel with AWT components, for example "java.awt.Button", is removed from AWT frame and added again to the same frame, then some AWT components contained in the panel are not drawn, however, clicking in the area of not drawn button leads to drawing of the button.
> 
> Test has a swing and awt component in a panel. It then removes and adds back the panel from/into the frame, to verify that they are repainted back properly.

This review is for migrating tests from a closed test suite to open.
Testing:
The test ran successfully on Mach5 with multiple runs (40) on windows-x64, linux-x64 and macos-x64.

-------------

PR: https://git.openjdk.org/jdk/pull/11707


From serb at openjdk.org  Mon Dec 19 09:02:49 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 Dec 2022 09:02:49 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows
In-Reply-To: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
Message-ID: <DG7aVT2gWQPqMNOKxS7aQrsdRBg5tl6qPLTvUll3KqI=.414b70c9-d47e-4338-af45-4b489ed01942@github.com>

On Wed, 7 Dec 2022 13:20:10 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> **Environment**: 
> GraalVM 22.3.0 with  jdk 19, Windows OS.
> 
> **Description**:
> Create a native image of Swing application using GraalVM and run it with ` -Dsun.awt.fontconfig=fontconfig.properties.src` java property.
> `java.lang.Error: java.home property not set` error is thrown.
> 
> For more details see https://github.com/oracle/graal/issues/4875.
> 
> **Solution**:
> The error is thrown by the code from [FontConfiguration.findFontConfigFile()](https://github.com/openjdk/jdk19u/blob/c9d485792b99233f381dcdfd69838e7b973909bd/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L175) method.
> GraalVM does not set `java.home`  property, that is why the `java.lang.Error: java.home property not set` is thrown.
> `FontConfiguration.findFontConfigFile()` method compares `java.home` property to null before checking user provided `sun.awt.fontconfig` java property.
> 
> The proposed fix swaps the order of `java.home` and `sun.awt.fontconfig` properties checking to avoid using `java.home` property in case `sun.awt.fontconfig` is set.
> 
> 
> **Steps to reproduce**:
> - Download graal 22.3.0 jdk 19 for Windows from [GraalVM Community Edition 22.3.0](https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0) page.
> - Install native-image
> 
> graalvm-ce-java19-22.3.0\bin\gu.cmd install native-image
> 
> - Create and compile `SwingSample.java` sample
> 
> import java.awt.*;
> import javax.swing.*;
> 
> public class SwingSample {
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeAndWait(() -> {
> 
>             JFrame frame = new JFrame("Hello World");
> 
>             JButton button = new JButton("Hello");
>             button.addActionListener(e -> {
>                 System.out.printf("Hello, World!%n");
>             });
> 
>             JPanel panel = new JPanel(new FlowLayout());
>             panel.add(button);
> 
>             frame.add(panel);
>             frame.setSize(400, 300);
>             frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>             frame.setVisible(true);
>         });
>     }
> }
> 
> - Run native-image-agent to generate configuration files
> 
> graalvm-ce-java19-22.3.0\bin\java.cmd -agentlib:native-image-agent=config-output-dir=conf-dir SwingSample
> 
> - Copy `graalvm-ce-java19-22.3.0\lib\fontconfig.properties.src` file to the sample dir
> - Generate native image with configuration files and `-Djava.awt.headless=false `, `-Dsun.awt.fontconfig=fontconfig.properties.src` java properties
> 
> call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64"
> graalvm-ce-java19-22.3.0\bin\native-image.cmd --no-fallback -Djava.awt.headless=false -Dsun.awt.fontconfig=fontconfig.properties.src -H:ResourceConfigurationFiles=conf-dir/resource-config.json -H:SerializationConfigurationFiles=conf-dir/serialization-config.json -H:ReflectionConfigurationFiles=conf-dir/reflect-config.json -H:JNIConfigurationFiles=conf-dir/jni-config.json SwingSample
> 
> - Run the native image with `-Dsun.awt.fontconfig=fontconfig.properties.src` java property.
> 
> swingsample.exe  -Dsun.awt.fontconfig=fontconfig.properties.src
> 
> Exception in thread "main" java.lang.reflect.InvocationTargetException
>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371)
>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346)
>         at java.desktop at 19.0.1/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480)
>         at SwingSample.main(SwingSample.java:7)
> Caused by: java.lang.Error: java.home property not set
>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
>         at java.desktop at 19.0.1/sun.awt.windows.WFontConfiguration.<init>(WFontConfiguration.java:41)

I can reproduce the bug and assume that this change will fix that exception. But after this change, we will skip initialization of the "javaLib" if the user config was passed, and as a result, we will skip initialization of the fallback fonts by the getInstalledFallbackFonts. I do not know should if fallback fonts are used if the user explicitly set config or not.

-------------

PR: https://git.openjdk.org/jdk/pull/11559


From aivanov at openjdk.org  Mon Dec 19 11:57:53 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 Dec 2022 11:57:53 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v2]
In-Reply-To: <IiZ0wMzN3QdnfcDoQPNydWR6A3-KAH2H62TgD5yjCSg=.f7f8f35f-23df-49f3-97b8-05ef73654f33@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <IiZ0wMzN3QdnfcDoQPNydWR6A3-KAH2H62TgD5yjCSg=.f7f8f35f-23df-49f3-97b8-05ef73654f33@github.com>
Message-ID: <BfVwl8jLaeobllwpjeEBya-JgQZYRyv942b0b5yTlSA=.c3298fa4-619d-40d4-a613-907428c98b80@github.com>

On Thu, 15 Dec 2022 04:54:47 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated fix

You may still add `assert` statements into `MultiResolutionIconImage` constructors which ensures `resolutionVariants` contains no `null` values.

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1444:

> 1442:                 }
> 1443:             }
> 1444:             if ((retVal != null) && (retVal.getWidth(null) != w)) {

I believe this change is not needed.

-------------

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11104


From azvegint at openjdk.org  Mon Dec 19 12:11:58 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 19 Dec 2022 12:11:58 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v2]
In-Reply-To: <i9ki_jaoGPHJyKQW2PG-wrac22yJEMQ-ghWwK8cuYnM=.22e31d8c-f89b-4dd7-9f4b-5886ffcdd8fb@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <7lRrGCopXc6TOhPxpp4O7YP5L_z09DHG6Pd0Tj8kjgg=.c2177cce-78d9-40fd-8073-36b2eff352da@github.com>
 <CZ-rPr-zEF9Htx7EhLj5SsWGtE_ejyoWJLzKPKt-55E=.708a04e7-e797-498b-aefd-1871f92ef41a@github.com>
 <3ujz2jiE8CXsCeSG3FgWf1TPv0xl2Fv7ltmWXXu5cWU=.662fd95b-11bd-41ed-8b40-2dfcc76da290@github.com>
 <i9ki_jaoGPHJyKQW2PG-wrac22yJEMQ-ghWwK8cuYnM=.22e31d8c-f89b-4dd7-9f4b-5886ffcdd8fb@github.com>
Message-ID: <NGs9NatXlhrjQZC35z63Xp02jv1c6fHrTVNAieHypuk=.1e217c47-8da7-4cd1-a4c6-6d6fcf004b6c@github.com>

On Sat, 17 Dec 2022 01:14:00 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> I updated the code now the behaviour is correct (as far as i tested) and the blink rate is reported as if it is set to the correct value even on non-editable text element.
>
> I am still having issue with non-blinking cursor on editable field with the latest version of the fix.
> 
> Fails for me with test provided above and commented `requestFocus(button);` line.

The latest version does not work good for me,
e.g. with the test above and `textField.getCaret().setBlinkRate(250)`(not `2500`):

1. with `requestFocus(button);`:
 caret blinks several times and stops
 on mouse move, focus gained on text field the caret blinks several times and stops again.
2. without `requestFocus(button);`:
 it doesn't blink until focus out / focus in on the text component
 after this blinks several times and stops.

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From tr at openjdk.org  Mon Dec 19 13:32:52 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 19 Dec 2022 13:32:52 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v2]
In-Reply-To: <BfVwl8jLaeobllwpjeEBya-JgQZYRyv942b0b5yTlSA=.c3298fa4-619d-40d4-a613-907428c98b80@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <IiZ0wMzN3QdnfcDoQPNydWR6A3-KAH2H62TgD5yjCSg=.f7f8f35f-23df-49f3-97b8-05ef73654f33@github.com>
 <BfVwl8jLaeobllwpjeEBya-JgQZYRyv942b0b5yTlSA=.c3298fa4-619d-40d4-a613-907428c98b80@github.com>
Message-ID: <50ZSW6tDA3NWcxmmTNzBSHVM1XsENBC69nMy3__P3AQ=.4aca9ff6-0ce9-4c50-99ca-47890ff29b99@github.com>

On Mon, 19 Dec 2022 11:49:42 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 fix
>
> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1444:
> 
>> 1442:                 }
>> 1443:             }
>> 1444:             if ((retVal != null) && (retVal.getWidth(null) != w)) {
> 
> I believe this change is not needed.

> You may still add `assert` statements into `MultiResolutionIconImage` constructors which ensures `resolutionVariants` contains no `null` values.

Will add assert statements in this `public MultiResolutionIconImage(int baseSize, Image image)` as null checks are handled in other constructor.

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From mbaesken at openjdk.org  Mon Dec 19 13:56:31 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 19 Dec 2022 13:56:31 GMT
Subject: RFR: JDK-8299025: BMPImageReader.java readColorPalette could use
 staggeredReadByteStream
Message-ID: <JaSzb-XKdFvFRpzSwyXQNk1UB3301QLDImDOt11i7iY=.54b7e8d3-bc4a-4013-9d96-fb6e89f81cbd@github.com>

Looks like the coding in jdk/src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java readColorPalette is rather close to what staggeredReadByteStream does, so we could instead use staggeredReadByteStream and do not duplicate the coding.

-------------

Commit messages:
 - JDK-8299025

Changes: https://git.openjdk.org/jdk/pull/11720/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11720&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299025
  Stats: 24 lines in 1 file changed: 0 ins; 23 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11720.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11720/head:pull/11720

PR: https://git.openjdk.org/jdk/pull/11720


From aivanov at openjdk.org  Mon Dec 19 14:16:50 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 Dec 2022 14:16:50 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v2]
In-Reply-To: <50ZSW6tDA3NWcxmmTNzBSHVM1XsENBC69nMy3__P3AQ=.4aca9ff6-0ce9-4c50-99ca-47890ff29b99@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <IiZ0wMzN3QdnfcDoQPNydWR6A3-KAH2H62TgD5yjCSg=.f7f8f35f-23df-49f3-97b8-05ef73654f33@github.com>
 <BfVwl8jLaeobllwpjeEBya-JgQZYRyv942b0b5yTlSA=.c3298fa4-619d-40d4-a613-907428c98b80@github.com>
 <50ZSW6tDA3NWcxmmTNzBSHVM1XsENBC69nMy3__P3AQ=.4aca9ff6-0ce9-4c50-99ca-47890ff29b99@github.com>
Message-ID: <P-VY7xnp0uxbjvaL6rChg1nCgtyEyIcFzvoWWPh_6o8=.32cac304-1627-4efe-9b6a-72dba208fb8e@github.com>

On Mon, 19 Dec 2022 13:29:46 GMT, Tejesh R <tr at openjdk.org> wrote:

> > You may still add `assert` statements into `MultiResolutionIconImage` constructors which ensures `resolutionVariants` contains no `null` values.
> 
> Will add assert statements in this `public MultiResolutionIconImage(int baseSize, Image image)` as null checks are handled in other constructor.

What do you mean?

There are no `null`-checks in the other constructor. Or do I miss anything?

It's just you don't call the other constructor any more if an icon fetched from the OS is `null`. (Perhaps, it's not the most effective way: if another icon size is extracted correctly, a non-null value could still be returned.)

The following statement


assert !resolutionVariants.containsValue(null) : "There are null icons in the variants map";


would still prevent a `MultiResolutionIconImage` from being created if any resolution variant contains `null`. The code above could change again and we may end up with the same problem again.

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From tr at openjdk.org  Mon Dec 19 14:27:53 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 19 Dec 2022 14:27:53 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v2]
In-Reply-To: <P-VY7xnp0uxbjvaL6rChg1nCgtyEyIcFzvoWWPh_6o8=.32cac304-1627-4efe-9b6a-72dba208fb8e@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <IiZ0wMzN3QdnfcDoQPNydWR6A3-KAH2H62TgD5yjCSg=.f7f8f35f-23df-49f3-97b8-05ef73654f33@github.com>
 <BfVwl8jLaeobllwpjeEBya-JgQZYRyv942b0b5yTlSA=.c3298fa4-619d-40d4-a613-907428c98b80@github.com>
 <50ZSW6tDA3NWcxmmTNzBSHVM1XsENBC69nMy3__P3AQ=.4aca9ff6-0ce9-4c50-99ca-47890ff29b99@github.com>
 <P-VY7xnp0uxbjvaL6rChg1nCgtyEyIcFzvoWWPh_6o8=.32cac304-1627-4efe-9b6a-72dba208fb8e@github.com>
Message-ID: <af6fz9huME6b6qwzscLToefcYWvdgg3VTMwmoGwLcNc=.a06de323-0d1a-48d6-89d0-16fd080e9ddb@github.com>

On Mon, 19 Dec 2022 14:14:14 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> You may still add `assert` statements into `MultiResolutionIconImage` constructors which ensures `resolutionVariants` contains no `null` values.
>> 
>> Will add assert statements in this `public MultiResolutionIconImage(int baseSize, Image image)` as null checks are handled in other constructor.
>
>> > You may still add `assert` statements into `MultiResolutionIconImage` constructors which ensures `resolutionVariants` contains no `null` values.
>> 
>> Will add assert statements in this `public MultiResolutionIconImage(int baseSize, Image image)` as null checks are handled in other constructor.
> 
> What do you mean?
> 
> There are no `null`-checks in the other constructor. Or do I miss anything?
> 
> It's just you don't call the other constructor any more if an icon fetched from the OS is `null`. (Perhaps, it's not the most effective way: if another icon size is extracted correctly, a non-null value could still be returned.)
> 
> The following statement
> 
> 
> assert !resolutionVariants.containsValue(null) : "There are null icons in the variants map";
> 
> 
> would still prevent a `MultiResolutionIconImage` from being created if any resolution variant contains `null`. The code above could change again and we may end up with the same problem again.

Means the other constructor is called in two places only and in those places null checks are done. So, even if we add assertion inside constructor, it will unreachable.

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From aivanov at openjdk.org  Mon Dec 19 14:34:49 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 Dec 2022 14:34:49 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v2]
In-Reply-To: <af6fz9huME6b6qwzscLToefcYWvdgg3VTMwmoGwLcNc=.a06de323-0d1a-48d6-89d0-16fd080e9ddb@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <IiZ0wMzN3QdnfcDoQPNydWR6A3-KAH2H62TgD5yjCSg=.f7f8f35f-23df-49f3-97b8-05ef73654f33@github.com>
 <BfVwl8jLaeobllwpjeEBya-JgQZYRyv942b0b5yTlSA=.c3298fa4-619d-40d4-a613-907428c98b80@github.com>
 <50ZSW6tDA3NWcxmmTNzBSHVM1XsENBC69nMy3__P3AQ=.4aca9ff6-0ce9-4c50-99ca-47890ff29b99@github.com>
 <P-VY7xnp0uxbjvaL6rChg1nCgtyEyIcFzvoWWPh_6o8=.32cac304-1627-4efe-9b6a-72dba208fb8e@github.com>
 <af6fz9huME6b6qwzscLToefcYWvdgg3VTMwmoGwLcNc=.a06de323-0d1a-48d6-89d0-16fd080e9ddb@github.com>
Message-ID: <ohESO1ScyakDsR62EmgqUwlzBlFfBazfpOPiuM8rcVE=.5c3f40e6-a8be-48a6-be12-feab2e4f8987@github.com>

On Mon, 19 Dec 2022 14:24:58 GMT, Tejesh R <tr at openjdk.org> wrote:

> Means the other constructor is called in two places only and in those places null checks are done. So, even if we add assertion inside constructor, it will unreachable.

It won't be unreachable, _it will prevent such a situation from happening again_. The code which calls the other constructor could be changed.

I still think it's reasonable to add the assertion. It's a no-op if assertions aren't enabled (the default), and it'll catch the broken invariant in testing since tests are (usually) run with assertions enabled.

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From tr at openjdk.org  Mon Dec 19 14:34:49 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 19 Dec 2022 14:34:49 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v2]
In-Reply-To: <ohESO1ScyakDsR62EmgqUwlzBlFfBazfpOPiuM8rcVE=.5c3f40e6-a8be-48a6-be12-feab2e4f8987@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <IiZ0wMzN3QdnfcDoQPNydWR6A3-KAH2H62TgD5yjCSg=.f7f8f35f-23df-49f3-97b8-05ef73654f33@github.com>
 <BfVwl8jLaeobllwpjeEBya-JgQZYRyv942b0b5yTlSA=.c3298fa4-619d-40d4-a613-907428c98b80@github.com>
 <50ZSW6tDA3NWcxmmTNzBSHVM1XsENBC69nMy3__P3AQ=.4aca9ff6-0ce9-4c50-99ca-47890ff29b99@github.com>
 <P-VY7xnp0uxbjvaL6rChg1nCgtyEyIcFzvoWWPh_6o8=.32cac304-1627-4efe-9b6a-72dba208fb8e@github.com>
 <af6fz9huME6b6qwzscLToefcYWvdgg3VTMwmoGwLcNc=.a06de323-0d1a-48d6-89d0-16fd080e9ddb@github.com>
 <ohESO1ScyakDsR62EmgqUwlzBlFfBazfpOPiuM8rcVE=.5c3f40e6-a8be-48a6-be12-feab2e4f8987@github.com>
Message-ID: <NdvQohWB7e2VO58A1B7hLDsigAtubQfYoEO-g7XGTpQ=.bb011aaa-195a-4a36-9bca-cc434d550971@github.com>

On Mon, 19 Dec 2022 14:29:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Means the other constructor is called in two places only and in those places null checks are done. So, even if we add assertion inside constructor, it will unreachable.
>
>> Means the other constructor is called in two places only and in those places null checks are done. So, even if we add assertion inside constructor, it will unreachable.
> 
> It won't be unreachable, _it will prevent such a situation from happening again_. The code which calls the other constructor could be changed.
> 
> I still think it's reasonable to add the assertion. It's a no-op if assertions aren't enabled (the default), and it'll catch the broken invariant in testing since tests are (usually) run with assertions enabled.

Yeah, got your point. It's better to add as a preventive measure.

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From kizune at openjdk.org  Mon Dec 19 17:38:54 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 19 Dec 2022 17:38:54 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v2]
In-Reply-To: <NGs9NatXlhrjQZC35z63Xp02jv1c6fHrTVNAieHypuk=.1e217c47-8da7-4cd1-a4c6-6d6fcf004b6c@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <7lRrGCopXc6TOhPxpp4O7YP5L_z09DHG6Pd0Tj8kjgg=.c2177cce-78d9-40fd-8073-36b2eff352da@github.com>
 <CZ-rPr-zEF9Htx7EhLj5SsWGtE_ejyoWJLzKPKt-55E=.708a04e7-e797-498b-aefd-1871f92ef41a@github.com>
 <3ujz2jiE8CXsCeSG3FgWf1TPv0xl2Fv7ltmWXXu5cWU=.662fd95b-11bd-41ed-8b40-2dfcc76da290@github.com>
 <i9ki_jaoGPHJyKQW2PG-wrac22yJEMQ-ghWwK8cuYnM=.22e31d8c-f89b-4dd7-9f4b-5886ffcdd8fb@github.com>
 <NGs9NatXlhrjQZC35z63Xp02jv1c6fHrTVNAieHypuk=.1e217c47-8da7-4cd1-a4c6-6d6fcf004b6c@github.com>
Message-ID: <heIyV2An-wrK07L_LOQM9gaePklKWA0IxuclHo2fRCQ=.4bca09d1-f281-41a9-9cff-e839deb28f27@github.com>

On Mon, 19 Dec 2022 12:09:01 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> I am still having issue with non-blinking cursor on editable field with the latest version of the fix.
>> 
>> Fails for me with test provided above and commented `requestFocus(button);` line.
>
> The latest version does not work good for me,
> e.g. with the test above and `textField.getCaret().setBlinkRate(250)`(not `2500`):
> 
> 1. with `requestFocus(button);`:
>  caret blinks several times and stops
>  on mouse move, focus gained on text field the caret blinks several times and stops again.
> 2. without `requestFocus(button);`:
>  it doesn't blink until focus out / focus in on the text component
>  after this blinks several times and stops.

That's weird, does not happen on any of my systems. Which OS are you testing on?

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From azvegint at openjdk.org  Mon Dec 19 18:20:51 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 19 Dec 2022 18:20:51 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v2]
In-Reply-To: <heIyV2An-wrK07L_LOQM9gaePklKWA0IxuclHo2fRCQ=.4bca09d1-f281-41a9-9cff-e839deb28f27@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <7lRrGCopXc6TOhPxpp4O7YP5L_z09DHG6Pd0Tj8kjgg=.c2177cce-78d9-40fd-8073-36b2eff352da@github.com>
 <CZ-rPr-zEF9Htx7EhLj5SsWGtE_ejyoWJLzKPKt-55E=.708a04e7-e797-498b-aefd-1871f92ef41a@github.com>
 <3ujz2jiE8CXsCeSG3FgWf1TPv0xl2Fv7ltmWXXu5cWU=.662fd95b-11bd-41ed-8b40-2dfcc76da290@github.com>
 <i9ki_jaoGPHJyKQW2PG-wrac22yJEMQ-ghWwK8cuYnM=.22e31d8c-f89b-4dd7-9f4b-5886ffcdd8fb@github.com>
 <NGs9NatXlhrjQZC35z63Xp02jv1c6fHrTVNAieHypuk=.1e217c47-8da7-4cd1-a4c6-6d6fcf004b6c@github.com>
 <heIyV2An-wrK07L_LOQM9gaePklKWA0IxuclHo2fRCQ=.4bca09d1-f281-41a9-9cff-e839deb28f27@github.com>
Message-ID: <bjUDzbcn8A_fEDofVJJ6i-VAMVuawKsAbvpIUSqS6M4=.231034c2-f2d0-4f8c-8f8c-09573407416d@github.com>

On Mon, 19 Dec 2022 17:35:43 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> The latest version does not work good for me,
>> e.g. with the test above and `textField.getCaret().setBlinkRate(250)`(not `2500`):
>> 
>> 1. with `requestFocus(button);`:
>>  caret blinks several times and stops
>>  on mouse move, focus gained on text field the caret blinks several times and stops again.
>> 2. without `requestFocus(button);`:
>>  it doesn't blink until focus out / focus in on the text component
>>  after this blinks several times and stops.
>
> That's weird, does not happen on any of my systems. Which OS are you testing on?

Ubuntu 22.04 and it reproduces always.

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From prr at openjdk.org  Mon Dec 19 18:30:39 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 19 Dec 2022 18:30:39 GMT
Subject: RFR: 8298974: Add ftcolor.c to imported freetype sources
Message-ID: <XXapPbkE0JaCjfrY6p2QJGTo7LRXJj8SKsXDiCngwGA=.35345450-4e01-4c69-a6aa-d1f6c65bb79e@github.com>

Add ftcolor.c to the freetype sources we import as it is needed for Emoji rendering.

-------------

Commit messages:
 - 8298974

Changes: https://git.openjdk.org/jdk/pull/11728/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11728&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298974
  Stats: 156 lines in 1 file changed: 156 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11728.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11728/head:pull/11728

PR: https://git.openjdk.org/jdk/pull/11728


From serb at openjdk.org  Mon Dec 19 18:44:49 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 Dec 2022 18:44:49 GMT
Subject: RFR: 8298974: Add ftcolor.c to imported freetype sources
In-Reply-To: <XXapPbkE0JaCjfrY6p2QJGTo7LRXJj8SKsXDiCngwGA=.35345450-4e01-4c69-a6aa-d1f6c65bb79e@github.com>
References: <XXapPbkE0JaCjfrY6p2QJGTo7LRXJj8SKsXDiCngwGA=.35345450-4e01-4c69-a6aa-d1f6c65bb79e@github.com>
Message-ID: <ystS3X0wxEASC9F7zBoFkhXQ00BO9dDsxhg1ZUhhBoQ=.deb5c186-9ddd-4d41-abc7-ac21b5ac38f9@github.com>

On Mon, 19 Dec 2022 18:21:44 GMT, Phil Race <prr at openjdk.org> wrote:

> Add ftcolor.c to the freetype sources we import as it is needed for Emoji rendering.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11728


From kizune at openjdk.org  Mon Dec 19 19:14:52 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 19 Dec 2022 19:14:52 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v2]
In-Reply-To: <bjUDzbcn8A_fEDofVJJ6i-VAMVuawKsAbvpIUSqS6M4=.231034c2-f2d0-4f8c-8f8c-09573407416d@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <7lRrGCopXc6TOhPxpp4O7YP5L_z09DHG6Pd0Tj8kjgg=.c2177cce-78d9-40fd-8073-36b2eff352da@github.com>
 <CZ-rPr-zEF9Htx7EhLj5SsWGtE_ejyoWJLzKPKt-55E=.708a04e7-e797-498b-aefd-1871f92ef41a@github.com>
 <3ujz2jiE8CXsCeSG3FgWf1TPv0xl2Fv7ltmWXXu5cWU=.662fd95b-11bd-41ed-8b40-2dfcc76da290@github.com>
 <i9ki_jaoGPHJyKQW2PG-wrac22yJEMQ-ghWwK8cuYnM=.22e31d8c-f89b-4dd7-9f4b-5886ffcdd8fb@github.com>
 <NGs9NatXlhrjQZC35z63Xp02jv1c6fHrTVNAieHypuk=.1e217c47-8da7-4cd1-a4c6-6d6fcf004b6c@github.com>
 <heIyV2An-wrK07L_LOQM9gaePklKWA0IxuclHo2fRCQ=.4bca09d1-f281-41a9-9cff-e839deb28f27@github.com>
 <bjUDzbcn8A_fEDofVJJ6i-VAMVuawKsAbvpIUSqS6M4=.231034c2-f2d0-4f8c-8f8c-09573407416d@github.com>
Message-ID: <RLLzXjwGO2lXpGv2cdsfsM02FEFLa9CKb6OfecY-dz8=.9df1cc57-ed27-4e8a-997d-30c4a4d4b3fb@github.com>

On Mon, 19 Dec 2022 18:17:48 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> That's weird, does not happen on any of my systems. Which OS are you testing on?
>
> Ubuntu 22.04 and it reproduces always.

Ok, i tried on Ubuntu 22 on x11 desktop and i see this behavior. However - i checked out master and i also can see the same glitch so this is not related to my fix.

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From duke at openjdk.org  Mon Dec 19 19:41:29 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Mon, 19 Dec 2022 19:41:29 GMT
Subject: RFR: 8299044 : test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java
 fails on non mac
Message-ID: <_YWvTEqXEo883Kdbxm4fhvVuxF9-LOsQfh1bwybmHuA=.94c23cc9-5b65-4364-a39b-9e1e0256fd52@github.com>

This test needs to be executed on mac os only

@shurymury 
@honkar-jdk

-------------

Commit messages:
 - 8299044 : test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac

Changes: https://git.openjdk.org/jdk/pull/11730/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11730&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299044
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11730.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11730/head:pull/11730

PR: https://git.openjdk.org/jdk/pull/11730


From aivanov at openjdk.org  Mon Dec 19 20:02:56 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 Dec 2022 20:02:56 GMT
Subject: RFR: 8296275: Write a test to verify setAccelerator method of
 JMenuItem [v10]
In-Reply-To: <UddJ-Ik7hDA1XvhSD3dKKKJCADNhuvsBM9zbicN23wc=.ab7a6ac7-02bb-4fd2-97fd-b3d92806a691@github.com>
References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
 <UddJ-Ik7hDA1XvhSD3dKKKJCADNhuvsBM9zbicN23wc=.ab7a6ac7-02bb-4fd2-97fd-b3d92806a691@github.com>
Message-ID: <tpaT5_YZkrtTbwcIXMGy1ENjFZN3cjQmrH3BquOgrMo=.753378c3-ed50-4d5e-9b65-02dbc20cc27d@github.com>

On Thu, 15 Dec 2022 16:35:38 GMT, Naveen Narayanan <duke at openjdk.org> wrote:

>> This testcase will
>> 1) Verify setAccelerator method of JMenuitem.
>> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M.
>> 
>> Testing:
>> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass.
>
> Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8296275: Review comments fixed.

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11035


From serb at openjdk.org  Mon Dec 19 20:24:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 Dec 2022 20:24:51 GMT
Subject: RFR: 8299044 :
 test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac
In-Reply-To: <_YWvTEqXEo883Kdbxm4fhvVuxF9-LOsQfh1bwybmHuA=.94c23cc9-5b65-4364-a39b-9e1e0256fd52@github.com>
References: <_YWvTEqXEo883Kdbxm4fhvVuxF9-LOsQfh1bwybmHuA=.94c23cc9-5b65-4364-a39b-9e1e0256fd52@github.com>
Message-ID: <FYKvuUu18PikNMXbNkUXjI0dYpMwPTg0GZFKcGMRwMk=.14443e27-3edb-4f8f-ab61-4c7b3c57dab1@github.com>

On Mon, 19 Dec 2022 19:34:21 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> This test needs to be executed on mac os only
> 
> @shurymury 
> @honkar-jdk

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11730


From duke at openjdk.org  Mon Dec 19 20:30:47 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Mon, 19 Dec 2022 20:30:47 GMT
Subject: RFR: 8299043 :
 test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java fails with
 java.lang.NullPointerException
Message-ID: <-PrbRCAE3t08Xa1g_VXDTNJknXsfxJK0NTPNuhNKsS8=.ce643120-d7d3-4ede-ad8e-c3f07e45f1c6@github.com>

Test was failing with java.lang.NullPointerException due to image file extension was specified in upper case ( GIF ) https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java#L44-L50  but actually it is in smaller case ( gif )  https://github.com/openjdk/jdk/tree/master/test/jdk/javax/swing/AbstractButton/5049549 . 
The was working as expected in mac but failed in ubuntu. After fixing the image file extension( gif ) and run the test it worked and exception was not reproduced. 

@shurymury 
@honkar-jdk

-------------

Commit messages:
 - 8299043 : test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java fails with java.lang.NullPointerException

Changes: https://git.openjdk.org/jdk/pull/11731/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11731&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299043
  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11731.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11731/head:pull/11731

PR: https://git.openjdk.org/jdk/pull/11731


From serb at openjdk.org  Mon Dec 19 20:30:47 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 Dec 2022 20:30:47 GMT
Subject: RFR: 8299043 :
 test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java fails with
 java.lang.NullPointerException
In-Reply-To: <-PrbRCAE3t08Xa1g_VXDTNJknXsfxJK0NTPNuhNKsS8=.ce643120-d7d3-4ede-ad8e-c3f07e45f1c6@github.com>
References: <-PrbRCAE3t08Xa1g_VXDTNJknXsfxJK0NTPNuhNKsS8=.ce643120-d7d3-4ede-ad8e-c3f07e45f1c6@github.com>
Message-ID: <EymAHYodUhM5J0UhBC7yI7-Rk9KjM__boalq-kWUjc8=.203b6d6c-6d1c-4a41-b62a-5a24bb3e42a6@github.com>

On Mon, 19 Dec 2022 20:20:11 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Test was failing with java.lang.NullPointerException due to image file extension was specified in upper case ( GIF ) https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java#L44-L50  but actually it is in smaller case ( gif )  https://github.com/openjdk/jdk/tree/master/test/jdk/javax/swing/AbstractButton/5049549 . 
> The was working as expected in mac but failed in ubuntu. After fixing the image file extension( gif ) and run the test it worked and exception was not reproduced. 
> 
> @shurymury 
> @honkar-jdk

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11731


From honkar at openjdk.org  Mon Dec 19 20:52:48 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 19 Dec 2022 20:52:48 GMT
Subject: RFR: 8299044 :
 test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac
In-Reply-To: <_YWvTEqXEo883Kdbxm4fhvVuxF9-LOsQfh1bwybmHuA=.94c23cc9-5b65-4364-a39b-9e1e0256fd52@github.com>
References: <_YWvTEqXEo883Kdbxm4fhvVuxF9-LOsQfh1bwybmHuA=.94c23cc9-5b65-4364-a39b-9e1e0256fd52@github.com>
Message-ID: <zt971iWNZO0ZOuXxtxUl392XzzkNuBatP82CY7rF2NM=.0326da66-3ce5-40b5-b3f3-9020aa7d909c@github.com>

On Mon, 19 Dec 2022 19:34:21 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> This test needs to be executed on mac os only
> 
> @shurymury 
> @honkar-jdk

Marked as reviewed by honkar (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/11730


From honkar at openjdk.org  Mon Dec 19 20:57:49 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 19 Dec 2022 20:57:49 GMT
Subject: RFR: 8299044 :
 test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac
In-Reply-To: <_YWvTEqXEo883Kdbxm4fhvVuxF9-LOsQfh1bwybmHuA=.94c23cc9-5b65-4364-a39b-9e1e0256fd52@github.com>
References: <_YWvTEqXEo883Kdbxm4fhvVuxF9-LOsQfh1bwybmHuA=.94c23cc9-5b65-4364-a39b-9e1e0256fd52@github.com>
Message-ID: <ah1AvFEIxjJ9pb-jWQ6Kf0oRWmLoAbm3kL3o1eYaPJY=.3b6ea1ce-c254-4a84-b2aa-e5692e41dc7b@github.com>

On Mon, 19 Dec 2022 19:34:21 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> This test needs to be executed on mac os only
> 
> @shurymury 
> @honkar-jdk

@lawrence-andrew Since it is manual test, I think adding that it is as mac-only test to the instructions would provide more clarity.

-------------

PR: https://git.openjdk.org/jdk/pull/11730


From duke at openjdk.org  Mon Dec 19 21:01:48 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Mon, 19 Dec 2022 21:01:48 GMT
Subject: RFR: 8299044 :
 test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac
In-Reply-To: <ah1AvFEIxjJ9pb-jWQ6Kf0oRWmLoAbm3kL3o1eYaPJY=.3b6ea1ce-c254-4a84-b2aa-e5692e41dc7b@github.com>
References: <_YWvTEqXEo883Kdbxm4fhvVuxF9-LOsQfh1bwybmHuA=.94c23cc9-5b65-4364-a39b-9e1e0256fd52@github.com>
 <ah1AvFEIxjJ9pb-jWQ6Kf0oRWmLoAbm3kL3o1eYaPJY=.3b6ea1ce-c254-4a84-b2aa-e5692e41dc7b@github.com>
Message-ID: <re1wkS1xGcDDCs--nGb-RC3SrlPt3efGKlbTfPPEQVg=.db3c49c5-8c36-4066-8485-cccb11bbe2d1@github.com>

On Mon, 19 Dec 2022 20:55:14 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> This test needs to be executed on mac os only
>> 
>> @shurymury 
>> @honkar-jdk
>
> @lawrence-andrew Since it is manual test, I think adding that it is as mac-only test to the instructions would provide more clarity.

@honkar-jdk , exception is thrown before showing the instruction since the test tries to load the https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java#L86

-------------

PR: https://git.openjdk.org/jdk/pull/11730


From aivanov at openjdk.org  Mon Dec 19 21:46:04 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 Dec 2022 21:46:04 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v2]
In-Reply-To: <0xRhqnSHTdlFswnkxX4GWQQAC_mB8pZXJoJEXuaszCE=.5b6e987a-40fd-4089-bddb-b79845ac212f@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
 <KwuZH3CQlUiklf-h_yzbB1RzoXACnqXNjWX4RZjGCI0=.5651d65a-391c-4588-9037-4d78d2ae357e@github.com>
 <YhS-pkykLDaNGlAiB-YDNyUkVYk-GceGszx7zvt6_aQ=.ad2efd92-6c58-4c45-9a54-6dad14eb42b3@github.com>
 <0xRhqnSHTdlFswnkxX4GWQQAC_mB8pZXJoJEXuaszCE=.5b6e987a-40fd-4089-bddb-b79845ac212f@github.com>
Message-ID: <KiSK3WRE-PpbRkZqG-LhokL6HzWISYevRTWMmM2vFsU=.e0c3b752-82df-475e-98c9-79dc4ddc5311@github.com>

On Thu, 15 Dec 2022 23:41:30 GMT, Phil Race <prr at openjdk.org> wrote:

> One JCK test fails; from a quick look, it's because the font is now uninstalled where it wasn't previously.

I confirmed it's a test problem. The JCK test needs to be updated. Details are in a confidential comment in JCK.

Do I need to submit a bug against JCK?


> do any of the jtreg test failures characterise the JCK failure ?

The failure of `javax/swing/GraphicsConfigNotifier/StalePreferredSize.java` may be related. The test fails for `JLabel`.

The test calls `SwingUtilities.updateComponentTreeUI(frame)` and expects the preferred size doesn't change. Yet it does change.

The failure in `sanity/client/SwingSet/src/SwingSet2DemoTest.java` is also related. It fails because of timeout where a font on a component (`JButton` presumably) doesn't change to _bold_ after selecting **Theme** ? **Font** ? **Bold** in the menu. Selecting this menu item results in `SwingUtilities.updateComponentTreeUI(frame)` being called to update the look and feel properties of all the components.


As for the closed test failure, it doesn't look related. A component being painted is null. It shouldn't happen.

-------------

PR: https://git.openjdk.org/jdk/pull/10565


From azvegint at openjdk.org  Mon Dec 19 22:13:50 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 19 Dec 2022 22:13:50 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v5]
In-Reply-To: <DL1Kou1vfwENoSwDzsv5Bo6exW8hnRuf4hLjAB2-4qs=.a354de75-206f-4256-9f2f-395a20d5752f@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <DL1Kou1vfwENoSwDzsv5Bo6exW8hnRuf4hLjAB2-4qs=.a354de75-206f-4256-9f2f-395a20d5752f@github.com>
Message-ID: <hfpeQTgDrMf_RmYL3ywXwXpMdKDq_G8ByUn-fgEnjqg=.171d170d-80da-48f5-99a1-05c450c7f327@github.com>

On Sat, 17 Dec 2022 18:21:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Set the text caret to be visible but not blinking on the non-editable text area. Fix the regression test that becames unstable after the change.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed blinkRateSaved to isBlinkRateSaved

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From azvegint at openjdk.org  Mon Dec 19 22:13:51 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 19 Dec 2022 22:13:51 GMT
Subject: [jdk20] RFR: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus [v2]
In-Reply-To: <RLLzXjwGO2lXpGv2cdsfsM02FEFLa9CKb6OfecY-dz8=.9df1cc57-ed27-4e8a-997d-30c4a4d4b3fb@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
 <7lRrGCopXc6TOhPxpp4O7YP5L_z09DHG6Pd0Tj8kjgg=.c2177cce-78d9-40fd-8073-36b2eff352da@github.com>
 <CZ-rPr-zEF9Htx7EhLj5SsWGtE_ejyoWJLzKPKt-55E=.708a04e7-e797-498b-aefd-1871f92ef41a@github.com>
 <3ujz2jiE8CXsCeSG3FgWf1TPv0xl2Fv7ltmWXXu5cWU=.662fd95b-11bd-41ed-8b40-2dfcc76da290@github.com>
 <i9ki_jaoGPHJyKQW2PG-wrac22yJEMQ-ghWwK8cuYnM=.22e31d8c-f89b-4dd7-9f4b-5886ffcdd8fb@github.com>
 <NGs9NatXlhrjQZC35z63Xp02jv1c6fHrTVNAieHypuk=.1e217c47-8da7-4cd1-a4c6-6d6fcf004b6c@github.com>
 <heIyV2An-wrK07L_LOQM9gaePklKWA0IxuclHo2fRCQ=.4bca09d1-f281-41a9-9cff-e839deb28f27@github.com>
 <bjUDzbcn8A_fEDofVJJ6i-VAMVuawKsAbvpIUSqS6M4=.231034c2-f2d0-4f8c-8f8c-09573407416d@github.com>
 <RLLzXjwGO2lXpGv2cdsfsM02FEFLa9CKb6OfecY-dz8=.9df1cc57-ed27-4e8a-997d-30c4a4d4b3fb@github.com>
Message-ID: <ptQk9r1o_NobCxP7lHE_aswFNOn5MlKNfPSt_-vMN2A=.695d17b8-39cf-4a69-875d-38bcdf92d4d4@github.com>

On Mon, 19 Dec 2022 19:11:46 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Ubuntu 22.04 and it reproduces always.
>
> Ok, i tried on Ubuntu 22 on x11 desktop and i see this behavior. However - i checked out master and i also can see the same glitch so this is not related to my fix.

Can confirm, filed [JDK-8299050](https://bugs.openjdk.org/browse/JDK-8299050) and [JDK-8299051](https://bugs.openjdk.org/browse/JDK-8299051) to track them.

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From kizune at openjdk.org  Mon Dec 19 22:19:52 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 19 Dec 2022 22:19:52 GMT
Subject: [jdk20] Integrated: 4512626: Non-editable JTextArea provides no visual
 indication of keyboard focus
In-Reply-To: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
References: <ibkIwSO1cyXow9LqALguO3TOsOMx7CaYKTW9Mrz_SM0=.9d7f46e2-b956-4cbe-8330-7e94f739048e@github.com>
Message-ID: <L23mhHnr8o6HwolzvXM7sqf6tbJR9hOVsmvlq6bIIVw=.1fca0048-c555-4fdd-ad8e-1acbc0309bc7@github.com>

On Mon, 12 Dec 2022 22:33:51 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Set the text caret to be visible but not blinking on the non-editable text area. Fix the regression test that becames unstable after the change.

This pull request has now been integrated.

Changeset: 3e17e3c1
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/3e17e3c1c12d71461213bf15cdb72d4d93c88460
Stats:     233 lines in 4 files changed: 73 ins; 76 del; 84 mod

4512626: Non-editable JTextArea provides no visual indication of keyboard focus
8194048: Regression automated test '/open/test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java' fails
8213562: Test javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java fails

Reviewed-by: aivanov, azvegint

-------------

PR: https://git.openjdk.org/jdk20/pull/21


From duke at openjdk.org  Mon Dec 19 23:28:55 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Mon, 19 Dec 2022 23:28:55 GMT
Subject: Integrated: 8299044 :
 test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac
In-Reply-To: <_YWvTEqXEo883Kdbxm4fhvVuxF9-LOsQfh1bwybmHuA=.94c23cc9-5b65-4364-a39b-9e1e0256fd52@github.com>
References: <_YWvTEqXEo883Kdbxm4fhvVuxF9-LOsQfh1bwybmHuA=.94c23cc9-5b65-4364-a39b-9e1e0256fd52@github.com>
Message-ID: <RBN3TfMuQy339bsCeZpdgh-QGhOcqtO0NAi1xdftsY0=.5726b239-4a19-49b4-879a-0e4bc5319db6@github.com>

On Mon, 19 Dec 2022 19:34:21 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> This test needs to be executed on mac os only
> 
> @shurymury 
> @honkar-jdk

This pull request has now been integrated.

Changeset: abc12976
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/abc1297643b03ea9b4a03a12ce681971784774fb
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8299044: test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac

Reviewed-by: serb, honkar

-------------

PR: https://git.openjdk.org/jdk/pull/11730


From honkar at openjdk.org  Mon Dec 19 23:31:56 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 19 Dec 2022 23:31:56 GMT
Subject: Withdrawn: JDK-8295813: misc client tests failing on Windows_11_Pro
In-Reply-To: <8lLtmuOrcP6cmaHVBx91hxB8PDD7RO9irr5-BpyJEbk=.8edebaf4-ae38-463f-9809-d66016452198@github.com>
References: <8lLtmuOrcP6cmaHVBx91hxB8PDD7RO9irr5-BpyJEbk=.8edebaf4-ae38-463f-9809-d66016452198@github.com>
Message-ID: <ZWlxd0dgBXyjeGRf3uMK8zlWdh1u-2rymJemBHCO3yA=.a08fb573-01d1-406a-a8d6-b47d6810c1f0@github.com>

On Thu, 10 Nov 2022 23:47:09 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> ViewportOverlapping test was failing intermittently on Windows_11_Pro. The test has been updated to run at uiScale=1 to position the mouse clicks at correct locations and the deprecated InputEvent.BUTTON1_MASK is replaced with BUTTON1_DOWN_MASK.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11097


From prr at openjdk.org  Mon Dec 19 23:35:56 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 19 Dec 2022 23:35:56 GMT
Subject: Integrated: 8298974: Add ftcolor.c to imported freetype sources
In-Reply-To: <XXapPbkE0JaCjfrY6p2QJGTo7LRXJj8SKsXDiCngwGA=.35345450-4e01-4c69-a6aa-d1f6c65bb79e@github.com>
References: <XXapPbkE0JaCjfrY6p2QJGTo7LRXJj8SKsXDiCngwGA=.35345450-4e01-4c69-a6aa-d1f6c65bb79e@github.com>
Message-ID: <zg26BXzASyx1PsRoJEtPqZIF0bI5S7xwK2B4d3B_9o0=.68bcb455-4ebe-4c4c-a802-df2d133713d9@github.com>

On Mon, 19 Dec 2022 18:21:44 GMT, Phil Race <prr at openjdk.org> wrote:

> Add ftcolor.c to the freetype sources we import as it is needed for Emoji rendering.

This pull request has now been integrated.

Changeset: 05f9e767
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05f9e7676ea457cd5ef44acca9a1706b5dd0d093
Stats:     156 lines in 1 file changed: 156 ins; 0 del; 0 mod

8298974: Add ftcolor.c to imported freetype sources

Reviewed-by: serb

-------------

PR: https://git.openjdk.org/jdk/pull/11728


From prr at openjdk.org  Mon Dec 19 23:44:51 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 19 Dec 2022 23:44:51 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v16]
In-Reply-To: <uSiS9dILM4zD8K1BZXguxHIMuK3DfEBqv_Yup3aVRIw=.ff39717c-2d8b-4e95-a8dd-43546cbd39c2@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <e70BNRnl2Lfj-HLKkZzN1l0TETgkkXsIXRolnOdvTdM=.ffcb0669-d798-4d04-ae5a-de04e8a12279@github.com>
 <bObcfMVaxCToOJcBgQ3TCPodNKgod65b2HohMsuNk9s=.bae92483-f3a2-4adf-bd71-3056ab59335e@github.com>
 <MSv3RbxPjfHQlAq4zu1uzs0Dc83rn5YDBuEXqI5uem4=.aef6fad5-3efd-4c72-9c2a-f97fe3aadabf@github.com>
 <R4t6-20S1hd8H71xGYByLoVWvmyqACdLB_2DUkbYhJw=.02c42d5c-e427-40d7-b1eb-2431dc349a85@github.com>
 <uSiS9dILM4zD8K1BZXguxHIMuK3DfEBqv_Yup3aVRIw=.ff39717c-2d8b-4e95-a8dd-43546cbd39c2@github.com>
Message-ID: <h_Vs9kfODi5IryiAFTciwLM0ffqZ1qbDLi8DRQLgzVM=.e791cedd-e9e7-42d0-bf13-e84ae575ba99@github.com>

On Fri, 16 Dec 2022 19:48:12 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> OK, I will submit a PR to take care of this soon.
>
> Thank you.

Pushed under bug https://bugs.openjdk.org/browse/JDK-8298974

-------------

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Tue Dec 20 01:19:52 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Tue, 20 Dec 2022 01:19:52 GMT
Subject: Integrated: 8299043 :
 test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java fails with
 java.lang.NullPointerException
In-Reply-To: <-PrbRCAE3t08Xa1g_VXDTNJknXsfxJK0NTPNuhNKsS8=.ce643120-d7d3-4ede-ad8e-c3f07e45f1c6@github.com>
References: <-PrbRCAE3t08Xa1g_VXDTNJknXsfxJK0NTPNuhNKsS8=.ce643120-d7d3-4ede-ad8e-c3f07e45f1c6@github.com>
Message-ID: <Egctd6iNo7NlgV7IMHBb5XOUx-omjFxeff7gQHB8KT8=.2a266f24-0c61-46aa-aea0-2f85bce5aba5@github.com>

On Mon, 19 Dec 2022 20:20:11 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Test was failing with java.lang.NullPointerException due to image file extension was specified in upper case ( GIF ) https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java#L44-L50  but actually it is in smaller case ( gif )  https://github.com/openjdk/jdk/tree/master/test/jdk/javax/swing/AbstractButton/5049549 . 
> The was working as expected in mac but failed in ubuntu. After fixing the image file extension( gif ) and run the test it worked and exception was not reproduced. 
> 
> @shurymury 
> @honkar-jdk

This pull request has now been integrated.

Changeset: dd15d306
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dd15d306a68caa02659dd95d16b71d0f1a437bc6
Stats:     7 lines in 1 file changed: 0 ins; 0 del; 7 mod

8299043: test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java fails with java.lang.NullPointerException

Reviewed-by: serb

-------------

PR: https://git.openjdk.org/jdk/pull/11731


From dnguyen at openjdk.org  Tue Dec 20 03:30:48 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 20 Dec 2022 03:30:48 GMT
Subject: RFR: 8202931: [macos]
 java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java fails [v3]
In-Reply-To: <1Yr4hOUnb3Xh2aWjUEriD-H-Bilbjs96lDmLPjye75o=.6f52bc31-7cc1-4d0a-8091-3aa66d97e30b@github.com>
References: <lMoM5UnFcd2T8yHEY5lN7WFY2cSQL_18I6maJD6xxnw=.776f2663-c6a7-43ee-ab8c-c2210d95cee0@github.com>
 <rTgkJ5GkjUUzcgAe7qGP7-vzijWpXpClg7jX06Z4WdE=.d7b1c7ad-e509-4ff2-a9ac-ca2d52b13dd2@github.com>
 <1Yr4hOUnb3Xh2aWjUEriD-H-Bilbjs96lDmLPjye75o=.6f52bc31-7cc1-4d0a-8091-3aa66d97e30b@github.com>
Message-ID: <SYtqmhx3LIasb-tVD6iDLfzxz1SZWl4oVd5RIWS1NvQ=.659b3c66-d77e-4f52-802f-ba96790b2bc0@github.com>

On Tue, 13 Dec 2022 19:07:25 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Test changes look good. I believe it is tested on multi-screen setup scenario too?

Yes! I tried it with an external monitor set to an extended display. Initially it failed, but it was due to the notifcation on macOS for updates blocking one of the window's selections. Ran the test again to be sure and it passes.

-------------

PR: https://git.openjdk.org/jdk/pull/11277


From serb at openjdk.org  Tue Dec 20 05:59:41 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 20 Dec 2022 05:59:41 GMT
Subject: RFR: 8298887: On the latest macOS+XCode the Robot API may report wrong
 colors
Message-ID: <xJUq-jlp7svDBuSk8ILnzQDpDwRwFctSKTPZfS0rP5I=.c07ed5a5-484f-4249-b1ef-b2c464341629@github.com>

The new macOS SDK provided by XCode 14.2 changed this macro:
`# define kCGBitmapByteOrder32Host kCGBitmapByteOrder32Little`
to this constant
`static const CGBitmapInfo kCGBitmapByteOrder32Host = kCGBitmapByteOrder32Little;`

As a result, our native code started to redefine the macro value to "define kCGBitmapByteOrder32Host 0". I think that was added a long time ago for a PPC platform.

I have also changed the type of the color we pass to the java Robot, the java code expects the xrgb format(the alpha ignored), but we for some reason prepared pre-multiplied alpha.

Tested on macOS 12.6.1 and 13.0.1 using xcode 14.2 and xcode 12.5.1

-------------

Commit messages:
 - update bugid
 - rework the patch
 - 8298887: On the latest macOS+XCode the Robot API may report wrong colors

Changes: https://git.openjdk.org/jdk/pull/11733/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11733&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298887
  Stats: 17 lines in 5 files changed: 0 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11733.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11733/head:pull/11733

PR: https://git.openjdk.org/jdk/pull/11733


From tr at openjdk.org  Tue Dec 20 08:18:11 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 20 Dec 2022 08:18:11 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v3]
In-Reply-To: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
Message-ID: <urW8Rvtb6DHjNL7fzHeeqylkLXrzz0g7NIAqp56jrgE=.8e3cfaae-3760-4a74-8211-ee5efb5fe0bd@github.com>

> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.

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/11104/files
  - new: https://git.openjdk.org/jdk/pull/11104/files/bd951a1d..120f7900

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11104&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11104&range=01-02

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11104.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11104/head:pull/11104

PR: https://git.openjdk.org/jdk/pull/11104


From jwilhelm at openjdk.org  Tue Dec 20 11:13:46 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 11:13:46 GMT
Subject: RFR: Merge jdk20
Message-ID: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298784: JFR: Test chunk integrity
 - 8298215: gc/g1/TestVerifyGCType.java failed with "Missing expected verification pattern Verifying After GC for: Pause Young (Prepare Mixed): expected true, was false"
 - 4958969: ObjectOutputStream example leads to non-working code
 - 8298699: java/lang/reflect/IllegalArgumentsTest.java times out with slowdebug bits
 - 4512626: Non-editable JTextArea provides no visual indication of keyboard focus
 - 8277074: Qualified exported types show up in JavaDoc
 - 8298894: java/lang/Thread/virtual/stress/Skynet.java timed out and threw OutOfMemoryError
 - 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64
 - 8298905: Test "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because the frames of instruction does not display
 - ... and 6 more: https://git.openjdk.org/jdk/compare/36de61c4...d70f5831

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11739/files
  Stats: 2286 lines in 125 files changed: 1286 ins; 609 del; 391 mod
  Patch: https://git.openjdk.org/jdk/pull/11739.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11739/head:pull/11739

PR: https://git.openjdk.org/jdk/pull/11739


From jwilhelm at openjdk.org  Tue Dec 20 11:47:31 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 11:47:31 GMT
Subject: RFR: Merge jdk20 [v2]
In-Reply-To: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
References: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
Message-ID: <FnOGkSoOkKJfJ5JjgZo7uwEF2JILRWkjhHgWx1sprIc=.38ff283a-01ab-401c-9411-f0d8c86702b6@github.com>

> Forwardport JDK 20 -> JDK 21

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits:

 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298865: Excessive memory allocation in CipherOutputStream AEAD decryption
   
   Reviewed-by: valeriep, ascarpino
 - 8299043: test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java fails with java.lang.NullPointerException
   
   Reviewed-by: serb
 - 8298974: Add ftcolor.c to imported freetype sources
   
   Reviewed-by: serb
 - 8299044: test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac
   
   Reviewed-by: serb, honkar
 - 8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943
   
   Reviewed-by: vromero
 - 8298943: Missing escapes for single quote marks in compiler.properties
   
   Reviewed-by: jjg
 - 8298701: Cleanup SA entries in ProblemList-zgc.txt.
   
   Reviewed-by: sspitsyn, amenkov
 - 8298470: Short cut java.lang.Object super class loading
   
   Reviewed-by: dholmes, iklam
 - 8299022: Linux ppc64le and s390x build issues after JDK-8160404
   
   Reviewed-by: mdoerr, lucy
 - ... and 97 more: https://git.openjdk.org/jdk/compare/3dd2cfab...d70f5831

-------------

Changes: https://git.openjdk.org/jdk/pull/11739/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=01
  Stats: 13539 lines in 425 files changed: 8409 ins; 3097 del; 2033 mod
  Patch: https://git.openjdk.org/jdk/pull/11739.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11739/head:pull/11739

PR: https://git.openjdk.org/jdk/pull/11739


From jwilhelm at openjdk.org  Tue Dec 20 11:47:33 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 11:47:33 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
References: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
Message-ID: <pk7xFH2bCEPTLw_KlI3RkDUTMMlze8j0j2fNKoqnm5Q=.49972633-6c2a-41af-be30-114c9f119772@github.com>

On Tue, 20 Dec 2022 10:57:44 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: c5a4a7a6
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c5a4a7a679ec76cb08a999a198e5c73e9cd9d2f0
Stats:     2286 lines in 125 files changed: 1286 ins; 609 del; 391 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/11739


From aghaisas at openjdk.org  Tue Dec 20 12:05:41 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 20 Dec 2022 12:05:41 GMT
Subject: [jdk20] RFR: 8299077: Regression -
 javax/swing/text/StyledEditorKit/8016833/bug8016833.java fails on all
 platforms
Message-ID: <2Z-d8_DSWrc7Hcj80skRKPiAkp6BQ0JvZ3OJW_yLIzw=.6cbf1f54-b503-4317-a304-1bf2236d067c@github.com>

This PR reverts the fix done in [JDK-4512626](https://bugs.openjdk.org/browse/JDK-4512626) as it caused few test regressions.

-------------

Commit messages:
 - revert JDK-4512626 fix

Changes: https://git.openjdk.org/jdk20/pull/61/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=61&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299077
  Stats: 213 lines in 4 files changed: 56 ins; 53 del; 104 mod
  Patch: https://git.openjdk.org/jdk20/pull/61.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/61/head:pull/61

PR: https://git.openjdk.org/jdk20/pull/61


From jdv at openjdk.org  Tue Dec 20 13:43:50 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 20 Dec 2022 13:43:50 GMT
Subject: [jdk20] RFR: 8299077: Regression -
 javax/swing/text/StyledEditorKit/8016833/bug8016833.java fails on all
 platforms
In-Reply-To: <2Z-d8_DSWrc7Hcj80skRKPiAkp6BQ0JvZ3OJW_yLIzw=.6cbf1f54-b503-4317-a304-1bf2236d067c@github.com>
References: <2Z-d8_DSWrc7Hcj80skRKPiAkp6BQ0JvZ3OJW_yLIzw=.6cbf1f54-b503-4317-a304-1bf2236d067c@github.com>
Message-ID: <O-6o-2S1z_7jXa7kS3XLi-C4WyEeaAHgDB8W5dhXhLs=.4baf59bb-e5b2-4fc2-be7e-a724c98c32b1@github.com>

On Tue, 20 Dec 2022 10:54:16 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR reverts the fix done in [JDK-4512626](https://bugs.openjdk.org/browse/JDK-4512626) as it caused few test regressions.

I dont think we should straightaway revert this fix.
We should try to fix the test failure or problemlist the test since it will make noise in the CI and fix the test failure.
@azuev-java please take a look.

-------------

PR: https://git.openjdk.org/jdk20/pull/61


From aivanov at openjdk.org  Tue Dec 20 14:45:58 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 Dec 2022 14:45:58 GMT
Subject: RFR: 8295707: Create a regression test for JDK-7184401 [v2]
In-Reply-To: <PY5VGkXX8T3KJbRwzjyRCh1dr_WGar_wie6_kzTjNHQ=.8950eb34-21bb-4f8e-8913-2b4124038be2@github.com>
References: <vIN06D-gVbz3GLi_NQZIQkx57ZyCiCKZCVKqm62g9nw=.ccf472cd-6020-457d-af86-911f6f248cf9@github.com>
 <PY5VGkXX8T3KJbRwzjyRCh1dr_WGar_wie6_kzTjNHQ=.8950eb34-21bb-4f8e-8913-2b4124038be2@github.com>
Message-ID: <CzIGgYwvb0MIgFQIkPNvo7y9MUw1vSiz5jbp4eqb064=.270eb328-8153-48ef-95c3-7e367919bf72@github.com>

On Mon, 7 Nov 2022 07:28:02 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> 8295707: Create a regression test for JDK-7184401
>> 
>> JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144
>> Above bug got introduced due to a fix for [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). 
>> The issue was observed on the netbeans UI. 
>> 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 explicitly edt.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
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed Review Comments: Removed redundant code

It is not very clear what the test is really verifying. However, I can confirm that the current test hangs in 7u5 and it successfully completes in 7u6 where [JDK-7184401](https://bugs.openjdk.org/browse/JDK-7184401) is fixed.

In JDK 7, `Robot.waitForIdle` does not call `SunToolkit.realSync`, therefore calling `realSync` is likely required to reproduce the original problem. Since JDK 9, `Robot.waitForIdle` calls `realSync` (see [JDK-8056911](https://bugs.openjdk.org/browse/JDK-8056911)), therefore it should be enough to call `Robot.waitForIdle` and it shouldn't hang.

-------------

PR: https://git.openjdk.org/jdk/pull/10784


From aivanov at openjdk.org  Tue Dec 20 14:46:00 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 Dec 2022 14:46:00 GMT
Subject: RFR: 8295707: Create a regression test for JDK-7184401 [v2]
In-Reply-To: <1ISRCYpxtqmJwnLOVTQ6N33tLaKJGaH1VH8H68qRhew=.07203892-aff3-4bb8-b754-94e89cb4d13f@github.com>
References: <vIN06D-gVbz3GLi_NQZIQkx57ZyCiCKZCVKqm62g9nw=.ccf472cd-6020-457d-af86-911f6f248cf9@github.com>
 <PY5VGkXX8T3KJbRwzjyRCh1dr_WGar_wie6_kzTjNHQ=.8950eb34-21bb-4f8e-8913-2b4124038be2@github.com>
 <vHEpPzcsOV5nw4xFBGJB954DeFLiL0u-HyS50XJPFZI=.81480b53-393a-4155-8cc9-3449289fa91e@github.com>
 <qzePcMoNyJaV9lH-HBbwPbu8Xw0SrZXIYjKG_6DGRjI=.8f00b927-c0b0-46d6-9ddf-8d91d8444cbc@github.com>
 <1ISRCYpxtqmJwnLOVTQ6N33tLaKJGaH1VH8H68qRhew=.07203892-aff3-4bb8-b754-94e89cb4d13f@github.com>
Message-ID: <bFWW5o3RaCj9FlnTcRwzVaMkQof7DjtpSddGxAw6tls=.3ec2eb76-fd1d-4f00-83af-c37288965a46@github.com>

On Fri, 2 Dec 2022 05:40:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> There was a comment in the original code before the realSync() call that was removed, which perhaps should have been left as is. 
>>         // cannot substitute with robot.waitForIdle() presumably because of flushPendingEvents() there
>> My understanding of above is that for simulating the test scenario - which is - Events (on line 75,76,77) are triggered and while these are potentially not yet complete(as they are wrapped in an invokeLater), the edt is interrupted. 
>> 
>> When run on jdk7u6  - the UI hangs and SOP of line 59 is not invoked. 
>> When run on jdk7u361 b01 the SOP on line 59 is printed and also the test passed.
>> 
>> waitForIdle here will trigger the flushPendingEvents internally before the edt interrupt call -and that would eliminate any possibility of simulating the above scenario.
>
> Then please double-check how robot.waitForIdle() and realSync() affect the test, since both call the flushPendingEvents(), why there is a difference?
>  * robot.waitForIdle()->SunToolkit.flushPendingEvents();
>  * realSync()->waitForIdle()->flushPendingEvents

That's right. If the test hangs when `Robot.waitForIdle` is called, it looks like another problem in the JDK.

`Robot.waitForIdle` calls `SunToolkit.flushPendingEvents` followed by `SunToolkit.realSync`.

`SunToolkit.realSync`, in its turn, calls `SunToolKit.waitForIdle` in a loop which calls `SunToolkit.flushPendingEvents`.

It looks like a problem to me.

-------------

PR: https://git.openjdk.org/jdk/pull/10784


From dcubed at openjdk.org  Tue Dec 20 15:49:33 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 20 Dec 2022 15:49:33 GMT
Subject: [jdk20] RFR: 8299123: [BACKOUT] 4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus
Message-ID: <4n-LRC1UyjzsAllan9-ySIBr0tRND8bkAGMlm6_6pFk=.22e6470b-caf1-4d17-9f2e-6e319093eb68@github.com>

This reverts commit 3e17e3c1c12d71461213bf15cdb72d4d93c88460.

-------------

Commit messages:
 - Revert "4512626: Non-editable JTextArea provides no visual indication of keyboard focus"

Changes: https://git.openjdk.org/jdk20/pull/62/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=62&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299123
  Stats: 213 lines in 4 files changed: 56 ins; 53 del; 104 mod
  Patch: https://git.openjdk.org/jdk20/pull/62.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/62/head:pull/62

PR: https://git.openjdk.org/jdk20/pull/62


From dcubed at openjdk.org  Tue Dec 20 15:50:54 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 20 Dec 2022 15:50:54 GMT
Subject: [jdk20] RFR: 8299077: Regression -
 javax/swing/text/StyledEditorKit/8016833/bug8016833.java fails on all
 platforms
In-Reply-To: <2Z-d8_DSWrc7Hcj80skRKPiAkp6BQ0JvZ3OJW_yLIzw=.6cbf1f54-b503-4317-a304-1bf2236d067c@github.com>
References: <2Z-d8_DSWrc7Hcj80skRKPiAkp6BQ0JvZ3OJW_yLIzw=.6cbf1f54-b503-4317-a304-1bf2236d067c@github.com>
Message-ID: <bIBCE1-KEe3tMB5w7oAM5xG0eRhAsLjV1uqXQlVCQ4Y=.9f67801f-528f-4490-9235-f8867a1848dc@github.com>

On Tue, 20 Dec 2022 10:54:16 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR reverts the fix done in [JDK-4512626](https://bugs.openjdk.org/browse/JDK-4512626) as it caused few test regressions.

Please close this PR in favor of this one:
https://github.com/openjdk/jdk20/pull/62

@jayathirthrao - The fix for [JDK-4512626](https://bugs.openjdk.org/browse/JDK-4512626)
has caused many test failures in Tier3 and Tier4. The proper thing to do is a [BACKOUT].

-------------

PR: https://git.openjdk.org/jdk20/pull/61


From tschatzl at openjdk.org  Tue Dec 20 16:18:51 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 20 Dec 2022 16:18:51 GMT
Subject: [jdk20] RFR: 8299123: [BACKOUT] 4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus
In-Reply-To: <4n-LRC1UyjzsAllan9-ySIBr0tRND8bkAGMlm6_6pFk=.22e6470b-caf1-4d17-9f2e-6e319093eb68@github.com>
References: <4n-LRC1UyjzsAllan9-ySIBr0tRND8bkAGMlm6_6pFk=.22e6470b-caf1-4d17-9f2e-6e319093eb68@github.com>
Message-ID: <xBK18wUhm1cX8ksobIyWMINFU4oJ5DU5q96MRzFlqPM=.b59fb86e-5610-4f1c-8280-8ade0323a480@github.com>

On Tue, 20 Dec 2022 15:41:45 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 3e17e3c1c12d71461213bf15cdb72d4d93c88460.

Ship it

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/62


From dcubed at openjdk.org  Tue Dec 20 16:18:52 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 20 Dec 2022 16:18:52 GMT
Subject: [jdk20] RFR: 8299123: [BACKOUT] 4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus
In-Reply-To: <xBK18wUhm1cX8ksobIyWMINFU4oJ5DU5q96MRzFlqPM=.b59fb86e-5610-4f1c-8280-8ade0323a480@github.com>
References: <4n-LRC1UyjzsAllan9-ySIBr0tRND8bkAGMlm6_6pFk=.22e6470b-caf1-4d17-9f2e-6e319093eb68@github.com>
 <xBK18wUhm1cX8ksobIyWMINFU4oJ5DU5q96MRzFlqPM=.b59fb86e-5610-4f1c-8280-8ade0323a480@github.com>
Message-ID: <0t9-MKP51Jn-fwOJShCLH_sW2aOXXAQomVmU4QDRpvY=.ecf7fdc2-459a-4696-b34b-d410f87923bd@github.com>

On Tue, 20 Dec 2022 16:15:09 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> This reverts commit 3e17e3c1c12d71461213bf15cdb72d4d93c88460.
>
> Ship it

@tschatzl - Thanks for the review!

-------------

PR: https://git.openjdk.org/jdk20/pull/62


From dcubed at openjdk.org  Tue Dec 20 16:24:00 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 20 Dec 2022 16:24:00 GMT
Subject: [jdk20] Integrated: 8299123: [BACKOUT] 4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus
In-Reply-To: <4n-LRC1UyjzsAllan9-ySIBr0tRND8bkAGMlm6_6pFk=.22e6470b-caf1-4d17-9f2e-6e319093eb68@github.com>
References: <4n-LRC1UyjzsAllan9-ySIBr0tRND8bkAGMlm6_6pFk=.22e6470b-caf1-4d17-9f2e-6e319093eb68@github.com>
Message-ID: <FCUDxmzDzThwYmi9W-t2wH1D6PY4BSy5t--mAM5lQp4=.2626f7b1-c545-45fa-b17d-6ba6a913d839@github.com>

On Tue, 20 Dec 2022 15:41:45 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 3e17e3c1c12d71461213bf15cdb72d4d93c88460.

This pull request has now been integrated.

Changeset: f4d7f433
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/f4d7f433942219704072a3fef156fe0fa7864f66
Stats:     213 lines in 4 files changed: 56 ins; 53 del; 104 mod

8299123: [BACKOUT] 4512626 Non-editable JTextArea provides no visual indication of keyboard focus

Reviewed-by: tschatzl

-------------

PR: https://git.openjdk.org/jdk20/pull/62


From aghaisas at openjdk.org  Tue Dec 20 16:29:56 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 20 Dec 2022 16:29:56 GMT
Subject: [jdk20] Withdrawn: 8299077: Regression -
 javax/swing/text/StyledEditorKit/8016833/bug8016833.java fails on all
 platforms
In-Reply-To: <2Z-d8_DSWrc7Hcj80skRKPiAkp6BQ0JvZ3OJW_yLIzw=.6cbf1f54-b503-4317-a304-1bf2236d067c@github.com>
References: <2Z-d8_DSWrc7Hcj80skRKPiAkp6BQ0JvZ3OJW_yLIzw=.6cbf1f54-b503-4317-a304-1bf2236d067c@github.com>
Message-ID: <kn6TR3JOA9a64Cd1JYjPucehuECxXKrrI1TSzUdGAxU=.849a8ce6-083e-4995-8db8-e6b87df25334@github.com>

On Tue, 20 Dec 2022 10:54:16 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR reverts the fix done in [JDK-4512626](https://bugs.openjdk.org/browse/JDK-4512626) as it caused few test regressions.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk20/pull/61


From clanger at openjdk.org  Tue Dec 20 16:32:50 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 20 Dec 2022 16:32:50 GMT
Subject: RFR: JDK-8299025: BMPImageReader.java readColorPalette could use
 staggeredReadByteStream
In-Reply-To: <JaSzb-XKdFvFRpzSwyXQNk1UB3301QLDImDOt11i7iY=.54b7e8d3-bc4a-4013-9d96-fb6e89f81cbd@github.com>
References: <JaSzb-XKdFvFRpzSwyXQNk1UB3301QLDImDOt11i7iY=.54b7e8d3-bc4a-4013-9d96-fb6e89f81cbd@github.com>
Message-ID: <a5q_YXhIeHGzmtq61Qi60JJ73pulHGrnJAD6mA0z_2w=.6432c513-ca64-4456-b7e2-788149f6e648@github.com>

On Mon, 19 Dec 2022 13:49:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Looks like the coding in jdk/src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java readColorPalette is rather close to what staggeredReadByteStream does, so we could instead use staggeredReadByteStream and do not duplicate the coding.

Looks good, helps deduplicate code.

-------------

Marked as reviewed by clanger (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11720


From duke at openjdk.org  Tue Dec 20 16:42:49 2022
From: duke at openjdk.org (SWinxy)
Date: Tue, 20 Dec 2022 16:42:49 GMT
Subject: RFR: JDK-8299025: BMPImageReader.java readColorPalette could use
 staggeredReadByteStream
In-Reply-To: <JaSzb-XKdFvFRpzSwyXQNk1UB3301QLDImDOt11i7iY=.54b7e8d3-bc4a-4013-9d96-fb6e89f81cbd@github.com>
References: <JaSzb-XKdFvFRpzSwyXQNk1UB3301QLDImDOt11i7iY=.54b7e8d3-bc4a-4013-9d96-fb6e89f81cbd@github.com>
Message-ID: <z_apDXhYbFiUoIY6Aozea60uRKSwV2V7FYhtyLglAFM=.6d4885f4-fe01-443f-8d93-04844760cc8e@github.com>

On Mon, 19 Dec 2022 13:49:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Looks like the coding in jdk/src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java readColorPalette is rather close to what staggeredReadByteStream does, so we could instead use staggeredReadByteStream and do not duplicate the coding.

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/11720


From jwilhelm at openjdk.org  Tue Dec 20 19:49:09 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 19:49:09 GMT
Subject: RFR: Merge jdk20
Message-ID: <f9m-NKslnFwzmaIBb3F-RVzKOtIQ-m45vsWvjMeeAFM=.75160a42-4482-44b9-bb25-bff6e4872e6f@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8299123: [BACKOUT] 4512626 Non-editable JTextArea provides no visual indication of keyboard focus
 - 8298162: Test PrintClasses hits assert when run with code that retransform classes
 - 8298061: vmTestbase/nsk/sysdict/vm/stress/btree/btree012/btree012.java failed with "fatal error: refcount has gone to zero"
 - 8298968: G1: Incorrect merged remset stats

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11744&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11744&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11744/files
  Stats: 258 lines in 8 files changed: 75 ins; 61 del; 122 mod
  Patch: https://git.openjdk.org/jdk/pull/11744.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11744/head:pull/11744

PR: https://git.openjdk.org/jdk/pull/11744


From djelinski at openjdk.org  Tue Dec 20 20:03:31 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 20 Dec 2022 20:03:31 GMT
Subject: RFR: 8200192: Verify exported symbols in java.desktop
Message-ID: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>

Please review this patch that removes unnecessary exports from libawt and libfreetype.

Verified that:
- mach5 client libs tests pass
- both release and debug builds finish successfully

Did not verify the other issues reported in the linked JBS ticket.

-------------

Commit messages:
 - Export selected symbols only

Changes: https://git.openjdk.org/jdk/pull/11742/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11742&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8200192
  Stats: 9 lines in 2 files changed: 0 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11742.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11742/head:pull/11742

PR: https://git.openjdk.org/jdk/pull/11742


From prr at openjdk.org  Tue Dec 20 20:17:00 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Dec 2022 20:17:00 GMT
Subject: RFR: 8200192: Verify exported symbols in java.desktop
In-Reply-To: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
References: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
Message-ID: <GOWxHUth3l8n3smNaFQ02cUYwi-IPk8RT44LtUe0UG0=.e6dfdd01-e39d-447f-ab8f-6d404da8481a@github.com>

On Tue, 20 Dec 2022 18:59:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes unnecessary exports from libawt and libfreetype.
> 
> Verified that:
> - mach5 client libs tests pass
> - both release and debug builds finish successfully
> 
> Did not verify the other issues reported in the linked JBS ticket.

Hmm, not easy to know for sure what might be affected. But it's early in JDK 21, so ...
Since you made a change to the freetype build, did you build with --with-freetype=bundled ?
If not, then the build on Linux defaults to using the system freetype and does not use the one in the sources.

-------------

PR: https://git.openjdk.org/jdk/pull/11742


From jwilhelm at openjdk.org  Tue Dec 20 20:25:54 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 20:25:54 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <f9m-NKslnFwzmaIBb3F-RVzKOtIQ-m45vsWvjMeeAFM=.75160a42-4482-44b9-bb25-bff6e4872e6f@github.com>
References: <f9m-NKslnFwzmaIBb3F-RVzKOtIQ-m45vsWvjMeeAFM=.75160a42-4482-44b9-bb25-bff6e4872e6f@github.com>
Message-ID: <50b6om_LcOMPSvd_OGuo2sXmamBxtL1AQo5kVQ7-nUE=.23a2bb67-52c6-4e68-98b9-7cad6e675883@github.com>

On Tue, 20 Dec 2022 19:41:28 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 386db071
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/386db07143883f85307138eca2f0305d997a2171
Stats:     258 lines in 8 files changed: 75 ins; 61 del; 122 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/11744


From djelinski at openjdk.org  Tue Dec 20 22:12:49 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 20 Dec 2022 22:12:49 GMT
Subject: RFR: 8200192: Verify exported symbols in java.desktop
In-Reply-To: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
References: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
Message-ID: <IlZgQKnOE8V-_u2Nogm72cfHcz57_OSxWu3QOrYePOs=.a02bb21e-9446-44d1-9c1a-a07343e66feb@github.com>

On Tue, 20 Dec 2022 18:59:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes unnecessary exports from libawt and libfreetype.
> 
> Verified that:
> - mach5 client libs tests pass
> - both release and debug builds finish successfully
> 
> Did not verify the other issues reported in the linked JBS ticket.

yes, I did build `--with-freetype=bundled`, and I compared the results of `readelf -s` between the system libfreetype and the one produced by the build.

After these changes, all of the bundled exports were present in system library. The following exports of the system library were absent in the bundled one:

FTC_CMapCache_Lookup
FTC_CMapCache_New
FTC_ImageCache_L[...]
FTC_ImageCache_Lookup
FTC_ImageCache_New
FTC_Manager_Done
FTC_Manager_Look[...]
FTC_Manager_Look[...]
FTC_Manager_New
FTC_Manager_Remo[...]
FTC_Manager_Reset
FTC_Node_Unref
FTC_SBitCache_Lo[...]
FTC_SBitCache_Lookup
FTC_SBitCache_New
FT_ClassicKern_Free
FT_ClassicKern_V[...]
FT_Error_String
FT_Get_BDF_Charset_ID
FT_Get_BDF_Property
FT_Get_PFR_Advance
FT_Get_PFR_Kerning
FT_Get_PFR_Metrics
FT_Get_WinFNT_Header
FT_Gzip_Uncompress
FT_OpenType_Free
FT_OpenType_Validate
FT_Palette_Data_Get
FT_Palette_Select
FT_Palette_Set_F[...]
FT_Stream_OpenBzip2
FT_Stream_OpenGzip
FT_Stream_OpenLZW
FT_TrueTypeGX_Free
FT_TrueTypeGX_Va[...]

These exports were absent even before my changes, so I believe we should be fine here.

-------------

PR: https://git.openjdk.org/jdk/pull/11742


From prr at openjdk.org  Tue Dec 20 23:06:49 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Dec 2022 23:06:49 GMT
Subject: RFR: 8200192: Verify exported symbols in java.desktop
In-Reply-To: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
References: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
Message-ID: <qUcyqGi8as8Jesh0irs9VriVoZY8FNSvRjMgDsBlQFE=.e7bd0bae-e20b-493c-9617-2a584418e43c@github.com>

On Tue, 20 Dec 2022 18:59:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes unnecessary exports from libawt and libfreetype.
> 
> Verified that:
> - mach5 client libs tests pass
> - both release and debug builds finish successfully
> 
> Did not verify the other issues reported in the linked JBS ticket.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11742


From prr at openjdk.org  Tue Dec 20 23:06:50 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Dec 2022 23:06:50 GMT
Subject: RFR: 8200192: Verify exported symbols in java.desktop
In-Reply-To: <IlZgQKnOE8V-_u2Nogm72cfHcz57_OSxWu3QOrYePOs=.a02bb21e-9446-44d1-9c1a-a07343e66feb@github.com>
References: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
 <IlZgQKnOE8V-_u2Nogm72cfHcz57_OSxWu3QOrYePOs=.a02bb21e-9446-44d1-9c1a-a07343e66feb@github.com>
Message-ID: <y1ZKoJz2rW9cHidTI05TJPB0vi2-LQcFI590-aLyULQ=.e3dca13e-c8ee-4209-9158-4ecb5fc9e422@github.com>

On Tue, 20 Dec 2022 22:09:42 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> These exports were absent even before my changes, so I believe we should be fine here.

I can't speak to all of these but we only have a subset of freetype in JDK sources, since for example we have no interest in the bitmap formats, so some of the differences are no surprise.

I don't have anything definite to say will be broken by this, so I'll approve this so we can get it in to the builds and we'll see if it causes problems.

-------------

PR: https://git.openjdk.org/jdk/pull/11742


From honkar at openjdk.org  Tue Dec 20 23:34:32 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 20 Dec 2022 23:34:32 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails on Win10 & Win11
Message-ID: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>

ViewportOverlapping was failing intermittently on Windows (Win10 & 11). Added robot.setAutoWaitForIdle() to ViewportOverlapping and its base class (OverlappingTestBase) to stabilize the test.

Additionally added awt & swings tests to exclusiveAccess.dir in TEST.ROOT.

-------------

Commit messages:
 - updated copyright year
 - problemlist change
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/11747/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11747&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299052
  Stats: 22 lines in 4 files changed: 9 ins; 3 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/11747.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11747/head:pull/11747

PR: https://git.openjdk.org/jdk/pull/11747


From kizune at openjdk.org  Tue Dec 20 23:48:49 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 20 Dec 2022 23:48:49 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus
Message-ID: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>

Slightly updated original fix - got rid of the extra flasher reset. Tests are fixed to be more stable and pass on the corresponding platforms.

-------------

Commit messages:
 - 8299077: [REDO] JDK-4512626 Non-editable JTextArea provides no visual indication of keyboard focus

Changes: https://git.openjdk.org/jdk20/pull/68/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=68&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299077
  Stats: 230 lines in 4 files changed: 70 ins; 76 del; 84 mod
  Patch: https://git.openjdk.org/jdk20/pull/68.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/68/head:pull/68

PR: https://git.openjdk.org/jdk20/pull/68


From jpai at openjdk.org  Wed Dec 21 01:14:49 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 Dec 2022 01:14:49 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11
In-Reply-To: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
Message-ID: <m3z28VJnQEMM38GGtwCj_AQsiHZr62IBBHKGg-cnL7s=.14543ee8-4371-4f79-a2ec-a238ea708c19@github.com>

On Tue, 20 Dec 2022 23:25:30 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> ViewportOverlapping was failing intermittently on Windows (Win10 & 11). Added robot.setAutoWaitForIdle() to ViewportOverlapping and its base class (OverlappingTestBase) to stabilize the test.
> 
> Additionally added awt & swings tests to exclusiveAccess.dir in TEST.ROOT.

test/jdk/TEST.ROOT line 36:

> 34: com/sun/net/httpserver/simpleserver \
> 35: java/awt \
> 36: javax/swing

Hello Harshitha, I don't have any knowledge of the client area, but I see that there are a large number of tests that are present in `test/jdk/java/awt` and `test/jdk/javax/swing`. Adding these 2 directories to `exclusiveAccess.dirs` would mean that none of the tests in `java/awt` will be run when any other test in `java/awt` is currently in progress. Same with the `javax/swing` directory. So it could increase the duration of the tiers in which these tests run. Is there a CI run which shows if this changes the test run duration drastically?

-------------

PR: https://git.openjdk.org/jdk/pull/11747


From kizune at openjdk.org  Wed Dec 21 04:59:55 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 21 Dec 2022 04:59:55 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus
In-Reply-To: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
Message-ID: <fYSjXv2cqHoApA3LQIoaYhpGbcM2BKlBxBNp4C9GjCo=.67a8400b-8515-4d34-9657-078b3ac3d998@github.com>

On Tue, 20 Dec 2022 23:38:31 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Slightly updated original fix - got rid of the extra flasher reset. Tests are fixed to be more stable and pass on the corresponding platforms.

@azvegint @aivanov-jdk Can you please take a look?

-------------

PR: https://git.openjdk.org/jdk20/pull/68


From kizune at openjdk.org  Wed Dec 21 05:04:48 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 21 Dec 2022 05:04:48 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus
In-Reply-To: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
Message-ID: <R1Mx2TkEcJl1_0peDKDaMH-VgBNfEZI4EesWljyN_24=.ae84df13-b800-43e7-a306-6326bd65c9ff@github.com>

On Tue, 20 Dec 2022 23:38:31 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Slightly updated original fix - got rid of the extra flasher reset. Tests are fixed to be more stable and pass on the corresponding platforms.

Full test run is finished, all tests except the JCK ones are passed. And we have a JCK challenge to fix their test.

-------------

PR: https://git.openjdk.org/jdk20/pull/68


From mbaesken at openjdk.org  Wed Dec 21 08:08:54 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Dec 2022 08:08:54 GMT
Subject: Integrated: JDK-8299025: BMPImageReader.java readColorPalette could
 use staggeredReadByteStream
In-Reply-To: <JaSzb-XKdFvFRpzSwyXQNk1UB3301QLDImDOt11i7iY=.54b7e8d3-bc4a-4013-9d96-fb6e89f81cbd@github.com>
References: <JaSzb-XKdFvFRpzSwyXQNk1UB3301QLDImDOt11i7iY=.54b7e8d3-bc4a-4013-9d96-fb6e89f81cbd@github.com>
Message-ID: <BOz2gP3dMPJ6WD43MwoPrgU5yA4-lBNC9EzoyR_61m8=.be7c1937-3af8-4d5d-aa77-ad31519da9fa@github.com>

On Mon, 19 Dec 2022 13:49:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Looks like the coding in jdk/src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java readColorPalette is rather close to what staggeredReadByteStream does, so we could instead use staggeredReadByteStream and do not duplicate the coding.

This pull request has now been integrated.

Changeset: f36e1449
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f36e144923da431a9c47faf5ae6577714fcf3adf
Stats:     24 lines in 1 file changed: 0 ins; 23 del; 1 mod

8299025: BMPImageReader.java readColorPalette could use staggeredReadByteStream

Reviewed-by: clanger

-------------

PR: https://git.openjdk.org/jdk/pull/11720


From duke at openjdk.org  Wed Dec 21 10:52:03 2022
From: duke at openjdk.org (Naveen Narayanan)
Date: Wed, 21 Dec 2022 10:52:03 GMT
Subject: Integrated: 8296275: Write a test to verify setAccelerator method of
 JMenuItem
In-Reply-To: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com>
Message-ID: <qvBxAcqJofA-hcn8GzA0Sp0AqZLa02yo5dPQrci2FuU=.91b4cb87-d1af-4a85-a595-a410a62573d5@github.com>

On Tue, 8 Nov 2022 08:57:54 GMT, Naveen Narayanan <duke at openjdk.org> wrote:

> This testcase will
> 1) Verify setAccelerator method of JMenuitem.
> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M.
> 
> Testing:
> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass.

This pull request has now been integrated.

Changeset: b005013a
Author:    Naveen Narayanan <naveen.n.narayanan at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b005013a0015656b7f6ccc26f8a13c44d61f77b9
Stats:     119 lines in 1 file changed: 119 ins; 0 del; 0 mod

8296275: Write a test to verify setAccelerator method of JMenuItem

Reviewed-by: mvs, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/11035


From aturbanov at openjdk.org  Wed Dec 21 11:11:36 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 21 Dec 2022 11:11:36 GMT
Subject: RFR: 8299199: Avoid redundant split calls in
 FontConfiguration.initReorderMap implementations
Message-ID: <DuDfZ1ahO9lvjdQjpJ88C1sMtwuqMT7O8HtXE4k6TeM=.fe53f02c-b9b0-44b4-9257-54f30a5446fe@github.com>

`FontConfiguration.split` uses legacy synchronized `Vector` class. But actually there is no need to use it, because input arguments are known at compile time. Instead of split usages we can just create String[] array with filled values directly.

-------------

Commit messages:
 - [PATCH] Avoid redundant split calls in FontConfiguration implementations

Changes: https://git.openjdk.org/jdk/pull/11754/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11754&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299199
  Stats: 9 lines in 3 files changed: 0 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11754.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11754/head:pull/11754

PR: https://git.openjdk.org/jdk/pull/11754


From aturbanov at openjdk.org  Wed Dec 21 11:27:54 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 21 Dec 2022 11:27:54 GMT
Subject: RFR: 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame
 throws a NPE. [v4]
In-Reply-To: <7P2I0AigbPWt_LkGjlZs9N6YlbCgMUH-sWgj0IurRTo=.9035162c-e492-4b21-b346-5f48fa02123a@github.com>
References: <2SC4Y5ekc2m4_y_Rj_5Ubp1PxZGrEt1yDz_8toJpQK4=.48cceec2-e0ac-4288-9478-3f8bf6cfe998@github.com>
 <7P2I0AigbPWt_LkGjlZs9N6YlbCgMUH-sWgj0IurRTo=.9035162c-e492-4b21-b346-5f48fa02123a@github.com>
Message-ID: <3pHfc07u0Zp4pK2EKkgQFtTySWAdN1jQ-WsthLS5B38=.0ad232a8-792f-49f9-bb63-841712854313@github.com>

On Wed, 14 Dec 2022 10:58:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In Swingset2 JInternalFrame demo, focusing on any internalframes and pressing Ctrl+F7 and then any of up/down/left/arrow key to move the internal frames results in NPE in NimbusL&F.
>> It is because `JComponent.processKeyBinding() `calls `SwingUtilities.notifyAction` which calls `BasicDesktopPaneUI.actionPerformed` where it gets `Desktop.minOnScreenInsets` property to get the Insets and then uses insets.top/bottom/left/right value to move the internalframe but this property is not defined for Nimbus so deferencing Insets object results in NPE.
>> 
>> Fix is added to create a 0 insets incase some L&F do not define` Desktop.minOnScreenInsets` property.
>> No regression test is added as it can be easily checked by SwingSet2 JInternalFrame demo.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

test/jdk/javax/swing/JInternalFrame/JInternalFrameTest.java line 118:

> 116:         JDesktopPane desktopPane = new JDesktopPane();
> 117: 
> 118:         iFrame =  new JInternalFrame("Test");

Suggestion:

        iFrame = new JInternalFrame("Test");

-------------

PR: https://git.openjdk.org/jdk/pull/11605


From aturbanov at openjdk.org  Wed Dec 21 11:28:59 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 21 Dec 2022 11:28:59 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v2]
In-Reply-To: <biffK-rMXKafRrrKPgT4rKrc_ZK_6EEbgw5NnO721P0=.db5323cc-6228-4cdc-80a0-b464d436b8e2@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
 <biffK-rMXKafRrrKPgT4rKrc_ZK_6EEbgw5NnO721P0=.db5323cc-6228-4cdc-80a0-b464d436b8e2@github.com>
Message-ID: <8xuGK0WotuZAKbeIZ7HY-df6V9GH-3JdNOanVx0NFjA=.5ff4fe92-c0e9-4ad1-85be-05c6c6d497e7@github.com>

On Mon, 12 Dec 2022 22:43:08 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as parameter to method.  
>> 
>> Following are the usual steps for any border scaling -
>> 
>> - Resetting transform.
>> - Calculating new width, height, x & y-translations.
>> - Perform the required border rendering.
>> - And at the end restore the previous transform.
>> 
>> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
>> 
>> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
>> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
>> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
>> 
>> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review changes

src/java.desktop/share/classes/javax/swing/border/LineBorder.java line 151:

> 149:     private void paintUnscaledBorder(Component c, Graphics g, int x, int y,
> 150:                                      int w, int h, double scale, int stroke) {
> 151:         if ((this.thickness > 0)) {

Suggestion:

        if (this.thickness > 0) {

src/java.desktop/share/classes/javax/swing/border/LineBorder.java line 152:

> 150:                                      int w, int h, double scale, int stroke) {
> 151:         if ((this.thickness > 0)) {
> 152:             int offs =  this.thickness * (int) scale;

Suggestion:

            int offs = this.thickness * (int) scale;

-------------

PR: https://git.openjdk.org/jdk/pull/11571


From aturbanov at openjdk.org  Wed Dec 21 11:29:50 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 21 Dec 2022 11:29:50 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel
In-Reply-To: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
Message-ID: <KLOOmtoO_cJhkJa-Q1xszITaOZcVjR2_lygpfLTwa0g=.12ae952c-9168-40a5-8ed4-aed3f3ded821@github.com>

On Wed, 7 Dec 2022 10:25:31 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> In case of GTK LAF, the current selected element was not visible due to arrowbutton is rendered in entire display area of Combobox.
> 
> The proposed fix is to set the `squareButton `property of combobox to `false `so that the arrowbutton didn't take entire combobox display area for rendering. The `getMinimumSize `method is overridden in `SynthComboBoxUI `to consider **arrowbutton insets** for combobox minimum size. 
> 
> The JCK tests mentioned in JBS seems fine with the fix. 
> An automated test case is implemented to test in Nimbus and GTK LAF. The text color check is to ensure the current selected item is visible.
> 
> When swing tests are run with LAF set to Nimbus and GTK LAF, few test failures observed. 
> 
> Although CI jobs looks ok with tests run in their default set LAFs.
> 
> `open/test/jdk/javax/swing/JComboBox/TestComboBoxHeight.java` test passes if run in GTK LAF with current fix.

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java line 374:

> 372:         size.height += insets.top + insets.bottom + arrowInsets.top
> 373:                         + arrowInsets.bottom;
> 374:         size.width +=  insets.left + insets.right +arrowInsets.left

Suggestion:

        size.width  += insets.left + insets.right + arrowInsets.left

-------------

PR: https://git.openjdk.org/jdk/pull/11555


From aivanov at openjdk.org  Wed Dec 21 11:39:52 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Dec 2022 11:39:52 GMT
Subject: RFR: 8299199: Avoid redundant split calls in
 FontConfiguration.initReorderMap implementations
In-Reply-To: <DuDfZ1ahO9lvjdQjpJ88C1sMtwuqMT7O8HtXE4k6TeM=.fe53f02c-b9b0-44b4-9257-54f30a5446fe@github.com>
References: <DuDfZ1ahO9lvjdQjpJ88C1sMtwuqMT7O8HtXE4k6TeM=.fe53f02c-b9b0-44b4-9257-54f30a5446fe@github.com>
Message-ID: <4W0pl3oi3kcSLInzSJfFoBfIqqaGy7gr9YOlN6D7LiE=.6091b048-a675-482f-80ae-0703411ca7d5@github.com>

On Wed, 21 Dec 2022 11:03:08 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `FontConfiguration.split` uses legacy synchronized `Vector` class. But actually there is no need to use it, because input arguments are known at compile time. Instead of split usages we can just create String[] array with filled values directly.

src/java.desktop/share/classes/sun/awt/FontConfiguration.java line 856:

> 854: 
> 855:     protected String[] split(String sequence) {
> 856:         Vector<String> v = splitSequence(sequence);

Can `splitSequence` be replaced with `sequence.split(",")`. The created vector is used only to convert it to array. Using `split` returns the array.

https://github.com/openjdk/jdk/blob/7170385dd8028ad8c2c84b619bee0ade3af3ff09/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L2118

-------------

PR: https://git.openjdk.org/jdk/pull/11754


From aturbanov at openjdk.org  Wed Dec 21 11:59:53 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 21 Dec 2022 11:59:53 GMT
Subject: RFR: 8299199: Avoid redundant split calls in
 FontConfiguration.initReorderMap implementations
In-Reply-To: <4W0pl3oi3kcSLInzSJfFoBfIqqaGy7gr9YOlN6D7LiE=.6091b048-a675-482f-80ae-0703411ca7d5@github.com>
References: <DuDfZ1ahO9lvjdQjpJ88C1sMtwuqMT7O8HtXE4k6TeM=.fe53f02c-b9b0-44b4-9257-54f30a5446fe@github.com>
 <4W0pl3oi3kcSLInzSJfFoBfIqqaGy7gr9YOlN6D7LiE=.6091b048-a675-482f-80ae-0703411ca7d5@github.com>
Message-ID: <avRWxXbs6kpX_-xWxkel9yQ6h50N9lWFFuyY7MXbAxo=.a89ccc89-ba7a-46be-895f-9b595f02b53c@github.com>

On Wed, 21 Dec 2022 11:35:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> `FontConfiguration.split` uses legacy synchronized `Vector` class. But actually there is no need to use it, because input arguments are known at compile time. Instead of split usages we can just create String[] array with filled values directly.
>
> src/java.desktop/share/classes/sun/awt/FontConfiguration.java line 856:
> 
>> 854: 
>> 855:     protected String[] split(String sequence) {
>> 856:         Vector<String> v = splitSequence(sequence);
> 
> Can `splitSequence` be replaced with `sequence.split(",")`. The created vector is used only to convert it to array. Using `split` returns the array.
> 
> https://github.com/openjdk/jdk/blob/7170385dd8028ad8c2c84b619bee0ade3af3ff09/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L2118

Initially I was intended to do so (#11380), but I found that there is slight difference between `splitSequence` and `Strings.split` implementations. They handle empty _elements_ differently. So I think it's worth to create a separate issue to investigate if it's worth to change.

-------------

PR: https://git.openjdk.org/jdk/pull/11754


From aivanov at openjdk.org  Wed Dec 21 12:12:50 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Dec 2022 12:12:50 GMT
Subject: RFR: 8299199: Avoid redundant split calls in
 FontConfiguration.initReorderMap implementations
In-Reply-To: <DuDfZ1ahO9lvjdQjpJ88C1sMtwuqMT7O8HtXE4k6TeM=.fe53f02c-b9b0-44b4-9257-54f30a5446fe@github.com>
References: <DuDfZ1ahO9lvjdQjpJ88C1sMtwuqMT7O8HtXE4k6TeM=.fe53f02c-b9b0-44b4-9257-54f30a5446fe@github.com>
Message-ID: <jlaj24_nh1XN7LphFMUCzXujtL-DemuvR_bsvo-CCWE=.246974cf-065e-4230-a252-006b6063d9b7@github.com>

On Wed, 21 Dec 2022 11:03:08 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `FontConfiguration.split` uses legacy synchronized `Vector` class. But actually there is no need to use it, because input arguments are known at compile time. Instead of split usages we can just create String[] array with filled values directly.

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11754


From aivanov at openjdk.org  Wed Dec 21 12:12:52 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Dec 2022 12:12:52 GMT
Subject: RFR: 8299199: Avoid redundant split calls in
 FontConfiguration.initReorderMap implementations
In-Reply-To: <avRWxXbs6kpX_-xWxkel9yQ6h50N9lWFFuyY7MXbAxo=.a89ccc89-ba7a-46be-895f-9b595f02b53c@github.com>
References: <DuDfZ1ahO9lvjdQjpJ88C1sMtwuqMT7O8HtXE4k6TeM=.fe53f02c-b9b0-44b4-9257-54f30a5446fe@github.com>
 <4W0pl3oi3kcSLInzSJfFoBfIqqaGy7gr9YOlN6D7LiE=.6091b048-a675-482f-80ae-0703411ca7d5@github.com>
 <avRWxXbs6kpX_-xWxkel9yQ6h50N9lWFFuyY7MXbAxo=.a89ccc89-ba7a-46be-895f-9b595f02b53c@github.com>
Message-ID: <t-mcMfc8QjcU_PmNvbnQtztjnM7n-3o2SBxhDJfrGow=.d1bb59ec-9505-4112-b439-7dc5944dfdb4@github.com>

On Wed, 21 Dec 2022 11:56:52 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/awt/FontConfiguration.java line 856:
>> 
>>> 854: 
>>> 855:     protected String[] split(String sequence) {
>>> 856:         Vector<String> v = splitSequence(sequence);
>> 
>> Can `splitSequence` be replaced with `sequence.split(",")`. The created vector is used only to convert it to array. Using `split` returns the array.
>> 
>> https://github.com/openjdk/jdk/blob/7170385dd8028ad8c2c84b619bee0ade3af3ff09/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L2118
>
> Initially I was intended to do so (#11380), but I found that there is slight difference between `splitSequence` and `Strings.split` implementations. They handle empty _elements_ differently. So I think it's worth to create a separate issue to investigate if it's worth to change.

Reasonable. Thanks.

As another suggestion, since `Vector` isn't returned, `splitSequence` could use `ArrayList` internally instead.

-------------

PR: https://git.openjdk.org/jdk/pull/11754


From azvegint at openjdk.org  Wed Dec 21 15:10:51 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 21 Dec 2022 15:10:51 GMT
Subject: RFR: 8298887: On the latest macOS+XCode the Robot API may report
 wrong colors
In-Reply-To: <xJUq-jlp7svDBuSk8ILnzQDpDwRwFctSKTPZfS0rP5I=.c07ed5a5-484f-4249-b1ef-b2c464341629@github.com>
References: <xJUq-jlp7svDBuSk8ILnzQDpDwRwFctSKTPZfS0rP5I=.c07ed5a5-484f-4249-b1ef-b2c464341629@github.com>
Message-ID: <_pN1nF0-WeWiq1RdvQKDFNx4XLLujDBwVCx31K1Nik8=.3b52d2d5-d802-4d98-a05f-308cda400812@github.com>

On Mon, 19 Dec 2022 21:48:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The new macOS SDK provided by XCode 14.2 changed this macro:
> `# define kCGBitmapByteOrder32Host kCGBitmapByteOrder32Little`
> to this constant
> `static const CGBitmapInfo kCGBitmapByteOrder32Host = kCGBitmapByteOrder32Little;`
> 
> As a result, our native code started to redefine the macro value to "define kCGBitmapByteOrder32Host 0". I think that was added a long time ago for a PPC platform.
> 
> I have also changed the type of the color we pass to the java Robot, the java code expects the xrgb format(the alpha ignored), but we for some reason prepared pre-multiplied alpha.
> 
> Tested on macOS 12.6.1 and 13.0.1 using xcode 14.2 and xcode 12.5.1

Looks good.
Testing on macosx-aarch64 and macosx-x64 also looks good.

-------------

Marked as reviewed by azvegint (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11733


From aivanov at openjdk.org  Wed Dec 21 16:52:03 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Dec 2022 16:52:03 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus
In-Reply-To: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
Message-ID: <JmPKd9YWuIeZdz45DOtM3cVD2EN__rFuPG4ZHEHgPhY=.262ef283-2b98-4991-ab86-500cad74d89b@github.com>

On Tue, 20 Dec 2022 23:38:31 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Slightly updated original fix - got rid of the extra flasher reset. Tests are fixed to be more stable and pass on the corresponding platforms.

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 1069:

> 1067:             }
> 1068:             if (component.isEditable()) {
> 1069:                 if (isBlinkRateSaved) {

Suggestion:

            if (component.isEditable() && isBlinkRateSaved) {

Less indentation and the same behaviour.

-------------

PR: https://git.openjdk.org/jdk20/pull/68


From azvegint at openjdk.org  Wed Dec 21 16:52:04 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 21 Dec 2022 16:52:04 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus
In-Reply-To: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
Message-ID: <pUDbaUtKl8Qyk3xrJgkNBUYQlo0mPKVC5h5DUmfhm5Y=.7ad0cd69-db43-4f82-b890-f22449b7948b@github.com>

On Tue, 20 Dec 2022 23:38:31 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Slightly updated original fix - got rid of the extra flasher reset. Tests are fixed to be more stable and pass on the corresponding platforms.

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/68


From aivanov at openjdk.org  Wed Dec 21 17:03:51 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Dec 2022 17:03:51 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus
In-Reply-To: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
Message-ID: <l3Tlaw56YBuMTqZkw_uv9g2rNOl8Z90-X08ZXioj9N0=.69ae1e4d-ac6c-48b5-b328-b389cdfce2a7@github.com>

On Tue, 20 Dec 2022 23:38:31 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Slightly updated original fix - got rid of the extra flasher reset. Tests are fixed to be more stable and pass on the corresponding platforms.

When the caret doesn't need to blink because the component is read-only, we call the public method `setBlinkRate` to set the rate to 0. At the same time, `getBlinkRate` continues to return non-zero value. This is confusing.

I propose introducing a protected method which would handle the internal state. This way changing blink rate because the text component changes its state from editable to non-editable and back would be hidden inside the class, and `getBlinkRate` would always return the rate which was set by the most recent call to `setBlinkRate`.

This can be handled as part of [JDK-8298602](https://bugs.openjdk.org/browse/JDK-8298602) or _separately_.

-------------

PR: https://git.openjdk.org/jdk20/pull/68


From honkar at openjdk.org  Wed Dec 21 17:27:57 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 21 Dec 2022 17:27:57 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11
In-Reply-To: <m3z28VJnQEMM38GGtwCj_AQsiHZr62IBBHKGg-cnL7s=.14543ee8-4371-4f79-a2ec-a238ea708c19@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
 <m3z28VJnQEMM38GGtwCj_AQsiHZr62IBBHKGg-cnL7s=.14543ee8-4371-4f79-a2ec-a238ea708c19@github.com>
Message-ID: <lmAhQF7EiYZIrlh96_1ok58GPeak2LWG3afAfP4XolQ=.c07eaf59-0849-42b5-b25d-ff32eb2c5547@github.com>

On Wed, 21 Dec 2022 01:12:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> ViewportOverlapping was failing intermittently on Windows (Win10 & 11). Added robot.setAutoWaitForIdle() to ViewportOverlapping and its base class (OverlappingTestBase) to stabilize the test.
>> 
>> Additionally added awt & swings tests to exclusiveAccess.dir in TEST.ROOT.
>
> test/jdk/TEST.ROOT line 36:
> 
>> 34: com/sun/net/httpserver/simpleserver \
>> 35: java/awt \
>> 36: javax/swing
> 
> Hello Harshitha, I don't have any knowledge of the client area, but I see that there are a large number of tests that are present in `test/jdk/java/awt` and `test/jdk/javax/swing`. Adding these 2 directories to `exclusiveAccess.dirs` would mean that none of the tests in `java/awt` will be run when any other test in `java/awt` is currently in progress. Same with the `javax/swing` directory. So it could increase the duration of the tiers in which these tests run. Is there a CI run which shows if this changes the test run duration drastically?

@jaikiran Thank you for the details. I'll check if the duration of run differed drastically. I thought all the client tests run in non-concurrent mode by default or does this differ for headful and headless test?

-------------

PR: https://git.openjdk.org/jdk/pull/11747


From aivanov at openjdk.org  Wed Dec 21 17:28:00 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Dec 2022 17:28:00 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v3]
In-Reply-To: <urW8Rvtb6DHjNL7fzHeeqylkLXrzz0g7NIAqp56jrgE=.8e3cfaae-3760-4a74-8211-ee5efb5fe0bd@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <urW8Rvtb6DHjNL7fzHeeqylkLXrzz0g7NIAqp56jrgE=.8e3cfaae-3760-4a74-8211-ee5efb5fe0bd@github.com>
Message-ID: <YDlk5GEqfDFB5ppsdmdMlBeRboqtR8rQyVBGLUf6NKk=.cea4292f-7c5a-464e-b5fe-bb2536159f1f@github.com>

On Tue, 20 Dec 2022 08:18:11 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Approved provided the message for MRII(int, Image) is updated.

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1408:

> 1406: 
> 1407:         public MultiResolutionIconImage(int baseSize, Image image) {
> 1408:             assert image != null : "Null icons are added into MRI variants map";

Suggestion:

            assert image != null : "Null icon passed as the base image for MRI";

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11104


From kizune at openjdk.org  Wed Dec 21 19:40:09 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 21 Dec 2022 19:40:09 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus [v2]
In-Reply-To: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
Message-ID: <9nwTzXDoTgHiSd9hcmzyy0zhvvPj7U2VbsV4h5olsQ4=.fa045e9b-7309-42d0-91a9-875c34de5316@github.com>

> Slightly updated original fix - got rid of the extra flasher reset. Tests are fixed to be more stable and pass on the corresponding platforms.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Simplifying the two nested if conditions into one.

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/68/files
  - new: https://git.openjdk.org/jdk20/pull/68/files/e55fbbad..03788c9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=68&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=68&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/68.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/68/head:pull/68

PR: https://git.openjdk.org/jdk20/pull/68


From kizune at openjdk.org  Wed Dec 21 19:40:10 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 21 Dec 2022 19:40:10 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus [v2]
In-Reply-To: <JmPKd9YWuIeZdz45DOtM3cVD2EN__rFuPG4ZHEHgPhY=.262ef283-2b98-4991-ab86-500cad74d89b@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
 <JmPKd9YWuIeZdz45DOtM3cVD2EN__rFuPG4ZHEHgPhY=.262ef283-2b98-4991-ab86-500cad74d89b@github.com>
Message-ID: <GvvqJ-pUDE36_79nOGhl7rb2nKmBrS19aKsgYmSmbKQ=.76322673-b9a5-48da-ba59-2d546f7940ca@github.com>

On Wed, 21 Dec 2022 16:40:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Less indentation and the same behaviour.

Agreed. Fixed.

-------------

PR: https://git.openjdk.org/jdk20/pull/68


From aivanov at openjdk.org  Wed Dec 21 19:47:49 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Dec 2022 19:47:49 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus [v2]
In-Reply-To: <9nwTzXDoTgHiSd9hcmzyy0zhvvPj7U2VbsV4h5olsQ4=.fa045e9b-7309-42d0-91a9-875c34de5316@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
 <9nwTzXDoTgHiSd9hcmzyy0zhvvPj7U2VbsV4h5olsQ4=.fa045e9b-7309-42d0-91a9-875c34de5316@github.com>
Message-ID: <jRi3D7zBmAYS7AzUgZsUYjleIm71Bwsq1UKT175tqMU=.a47d8373-09ae-432e-9c42-1057b3937898@github.com>

On Wed, 21 Dec 2022 19:40:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Slightly updated original fix - got rid of the extra flasher reset. Tests are fixed to be more stable and pass on the corresponding platforms.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplifying the two nested if conditions into one.

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/68


From prr at openjdk.org  Wed Dec 21 19:52:48 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 21 Dec 2022 19:52:48 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus [v2]
In-Reply-To: <9nwTzXDoTgHiSd9hcmzyy0zhvvPj7U2VbsV4h5olsQ4=.fa045e9b-7309-42d0-91a9-875c34de5316@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
 <9nwTzXDoTgHiSd9hcmzyy0zhvvPj7U2VbsV4h5olsQ4=.fa045e9b-7309-42d0-91a9-875c34de5316@github.com>
Message-ID: <EhYJnu6Snm1SWrQEJNbU_E2u3WvOVX7DxeaFBwtSvGI=.0a7012f4-62a8-4ef1-872f-640e9696ec28@github.com>

On Wed, 21 Dec 2022 19:40:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Slightly updated original fix - got rid of the extra flasher reset. Tests are fixed to be more stable and pass on the corresponding platforms.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplifying the two nested if conditions into one.

"Full test run" means what ? 
Remember that even if you run every test everywhere, we can't be 100% certain of no regressions since we'll never have tests for every scenario.

And which manual tests did you run ?
Are you SURE no manual Swing tests or manual JCK tests will fail ?

-------------

PR: https://git.openjdk.org/jdk20/pull/68


From aivanov at openjdk.org  Wed Dec 21 20:06:51 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Dec 2022 20:06:51 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11
In-Reply-To: <lmAhQF7EiYZIrlh96_1ok58GPeak2LWG3afAfP4XolQ=.c07eaf59-0849-42b5-b25d-ff32eb2c5547@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
 <m3z28VJnQEMM38GGtwCj_AQsiHZr62IBBHKGg-cnL7s=.14543ee8-4371-4f79-a2ec-a238ea708c19@github.com>
 <lmAhQF7EiYZIrlh96_1ok58GPeak2LWG3afAfP4XolQ=.c07eaf59-0849-42b5-b25d-ff32eb2c5547@github.com>
Message-ID: <W_HEgUOBCsJbzgbVW_WNWLgfgOAyqVI05WNAzeQYIrg=.ea10afc2-3854-4ad8-9ebe-fbd00fec52ce@github.com>

On Wed, 21 Dec 2022 17:25:20 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/TEST.ROOT line 36:
>> 
>>> 34: com/sun/net/httpserver/simpleserver \
>>> 35: java/awt \
>>> 36: javax/swing
>> 
>> Hello Harshitha, I don't have any knowledge of the client area, but I see that there are a large number of tests that are present in `test/jdk/java/awt` and `test/jdk/javax/swing`. Adding these 2 directories to `exclusiveAccess.dirs` would mean that none of the tests in `java/awt` will be run when any other test in `java/awt` is currently in progress. Same with the `javax/swing` directory. So it could increase the duration of the tiers in which these tests run. Is there a CI run which shows if this changes the test run duration drastically?
>
> @jaikiran Thank you for the details. I'll check if the duration of run differed drastically. I thought all the client tests run in non-concurrent mode by default or does this differ for headful and headless test?

*Headful* tests are not supposed concurrently: they display UI and often use Robot to send input events to the UI. Running such tests concurrently leads to obscure failures. In our CI system, `JTREG_JOBS=1` is passed to `make` when running headful tests.

There's a set of *headless* tests which can be run concurrently. Such tests will be affected if they're run concurrently.

-------------

PR: https://git.openjdk.org/jdk/pull/11747


From kizune at openjdk.org  Wed Dec 21 20:13:00 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 21 Dec 2022 20:13:00 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus [v2]
In-Reply-To: <EhYJnu6Snm1SWrQEJNbU_E2u3WvOVX7DxeaFBwtSvGI=.0a7012f4-62a8-4ef1-872f-640e9696ec28@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
 <9nwTzXDoTgHiSd9hcmzyy0zhvvPj7U2VbsV4h5olsQ4=.fa045e9b-7309-42d0-91a9-875c34de5316@github.com>
 <EhYJnu6Snm1SWrQEJNbU_E2u3WvOVX7DxeaFBwtSvGI=.0a7012f4-62a8-4ef1-872f-640e9696ec28@github.com>
Message-ID: <KXyFC-Nr1KsXHg2UFL-MbqpCr6QMZxfYAeUy8CPiaAE=.eaf75aae-0678-458b-a6f8-e7e350c06d78@github.com>

On Wed, 21 Dec 2022 19:50:33 GMT, Phil Race <prr at openjdk.org> wrote:

> "Full test run" means what ? Remember that even if you run every test everywhere, we can't be 100% certain of no regressions since we'll never have tests for every scenario.
> 
> And which manual tests did you run ? Are you SURE no manual Swing tests or manual JCK tests will fail ?

I ran manual tests form javax/swing on Mac OS X, Ubuntu 22 and Windows 10 comparing them side by side with the workspace that does not contain my fix and i had no new issues. I am pretty confident there will be no manual test failures.

-------------

PR: https://git.openjdk.org/jdk20/pull/68


From dnguyen at openjdk.org  Wed Dec 21 20:14:54 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 21 Dec 2022 20:14:54 GMT
Subject: Integrated: 8202931: [macos]
 java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java fails
In-Reply-To: <lMoM5UnFcd2T8yHEY5lN7WFY2cSQL_18I6maJD6xxnw=.776f2663-c6a7-43ee-ab8c-c2210d95cee0@github.com>
References: <lMoM5UnFcd2T8yHEY5lN7WFY2cSQL_18I6maJD6xxnw=.776f2663-c6a7-43ee-ab8c-c2210d95cee0@github.com>
Message-ID: <KP2UCsKlS2yn0MdEBxPRR5r8GRMXT2kcGClFwkQKNVc=.dd024d7a-1b1d-4d07-847e-afd13a4a4af1@github.com>

On Mon, 21 Nov 2022 20:56:40 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Test ran on all OS 100 times and passed. Test previously failed on macOS but no longer reproducible. Added screen capture on moment of failure to have more evidence of failures in the future (previously a runtime exception was thrown only).

This pull request has now been integrated.

Changeset: f80faced
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f80faced6e6c6c1b10541a8b0c91625215c9ef43
Stats:     10 lines in 2 files changed: 7 ins; 1 del; 2 mod

8202931: [macos] java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java fails

Reviewed-by: serb, honkar

-------------

PR: https://git.openjdk.org/jdk/pull/11277


From aivanov at openjdk.org  Wed Dec 21 20:19:49 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Dec 2022 20:19:49 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11
In-Reply-To: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
Message-ID: <KXg7eI2il-twcbge-5wMqEXxYpVYScrdqQTwBNL7hno=.fb5b37aa-9bc0-4002-add1-bec40cfa18c5@github.com>

On Tue, 20 Dec 2022 23:25:30 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> ViewportOverlapping was failing intermittently on Windows (Win10 & 11). Added robot.setAutoWaitForIdle() to ViewportOverlapping and its base class (OverlappingTestBase) to stabilize the test.
> 
> Additionally added awt & swings tests to exclusiveAccess.dir in TEST.ROOT.

Maybe also expand imports in `OverlappingTestBase.java`?

test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 464:

> 462:             robot.setAutoWaitForIdle(true);
> 463:         }catch(Exception ignorex) {
> 464:         }

Does it make sense to extract this code into a new method?

-------------

PR: https://git.openjdk.org/jdk/pull/11747


From aivanov at openjdk.org  Wed Dec 21 20:51:49 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Dec 2022 20:51:49 GMT
Subject: RFR: 8200192: Verify exported symbols in java.desktop
In-Reply-To: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
References: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
Message-ID: <HzleNW92D7fdH1MhUeWeKB70fthZ9BnkPWjN0WccfZ4=.abb4a8d1-5ff1-4462-bb10-5dc4d2bdbc62@github.com>

On Tue, 20 Dec 2022 18:59:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Did not verify the other issues reported in the linked JBS ticket.

Then I suggest filing a new bug to track additional issues raised in [JDK-8200192](https://bugs.openjdk.org/browse/JDK-8200192) and editing the description and the subject of JDK-8200192 correspondingly to reflect the current fix only.

-------------

PR: https://git.openjdk.org/jdk/pull/11742


From kizune at openjdk.org  Wed Dec 21 21:07:49 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 21 Dec 2022 21:07:49 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus
In-Reply-To: <l3Tlaw56YBuMTqZkw_uv9g2rNOl8Z90-X08ZXioj9N0=.69ae1e4d-ac6c-48b5-b328-b389cdfce2a7@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
 <l3Tlaw56YBuMTqZkw_uv9g2rNOl8Z90-X08ZXioj9N0=.69ae1e4d-ac6c-48b5-b328-b389cdfce2a7@github.com>
Message-ID: <pM-kTF0E6Ap-_5Jzbe8u3aZPRWaitwEv_CoD53-9XUg=.ecd49fd9-1857-41f4-bce7-0418e9ff92d7@github.com>

On Wed, 21 Dec 2022 17:00:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> When the caret doesn't need to blink because the component is read-only, we call the public method `setBlinkRate` to set the rate to 0. At the same time, `getBlinkRate` continues to return non-zero value. This is confusing.
> 
> I propose introducing a protected method which would handle the internal state. This way changing blink rate because the text component changes its state from editable to non-editable and back would be hidden inside the class, and `getBlinkRate` would always return the rate which was set by the most recent call to `setBlinkRate`.
> 
> This can be handled as part of [JDK-8298602](https://bugs.openjdk.org/browse/JDK-8298602) or _separately_.

I'm going to put it into the comment section of the [JDK-8298602](https://bugs.openjdk.org/browse/JDK-8298602) so it is not lost to whoever will do the implementation on it.

-------------

PR: https://git.openjdk.org/jdk20/pull/68


From honkar at openjdk.org  Wed Dec 21 21:50:49 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 21 Dec 2022 21:50:49 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11
In-Reply-To: <W_HEgUOBCsJbzgbVW_WNWLgfgOAyqVI05WNAzeQYIrg=.ea10afc2-3854-4ad8-9ebe-fbd00fec52ce@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
 <m3z28VJnQEMM38GGtwCj_AQsiHZr62IBBHKGg-cnL7s=.14543ee8-4371-4f79-a2ec-a238ea708c19@github.com>
 <lmAhQF7EiYZIrlh96_1ok58GPeak2LWG3afAfP4XolQ=.c07eaf59-0849-42b5-b25d-ff32eb2c5547@github.com>
 <W_HEgUOBCsJbzgbVW_WNWLgfgOAyqVI05WNAzeQYIrg=.ea10afc2-3854-4ad8-9ebe-fbd00fec52ce@github.com>
Message-ID: <L4VQY6JayQjdN-Avnc_FCMNpubkEZzgc6LUhgzZKAQI=.1276219a-1abe-4cec-aa77-24762f55b529@github.com>

On Wed, 21 Dec 2022 20:03:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @jaikiran Thank you for the details. I'll check if the duration of run differed drastically. I thought all the client tests run in non-concurrent mode by default or does this differ for headful and headless test?
>
> *Headful* tests are not supposed concurrently: they display UI and often use Robot to send input events to the UI. Running such tests concurrently leads to obscure failures. In our CI system, `JTREG_JOBS=1` is passed to `make` when running headful tests.
> 
> There's a set of *headless* tests which can be run concurrently. Such tests will be affected if they're run concurrently.

@aivanov-jdk If it affects the run time of certain group of tests then it is better not to add it to `exclusiveAccess.dirs` and explicitly specify the `JTREG_JOBS=1` instead as both produce same results?

-------------

PR: https://git.openjdk.org/jdk/pull/11747


From honkar at openjdk.org  Wed Dec 21 22:09:37 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 21 Dec 2022 22:09:37 GMT
Subject: RFR: JDK-8294680: Refactor scaled border rendering [v3]
In-Reply-To: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
References: <x0Zg56aOcHPRXnF9UV18ptsik2M9DYBzEyI2rt3seZk=.2ea54d55-db2b-422b-a6f5-ae9e3964a8ef@github.com>
Message-ID: <lYAXVRfHlBD3wxhnlk68b5PyjhL0xwIVs9G0weqJ3Y8=.69e8b1d4-13b3-4ce1-ab23-7cdc4df1c097@github.com>

> In this fix, the common code required for scaled border rendering is unified and added to SwingUtilities3. This is achieved by adding a functional interface to SwingUtilities3 and calling the the respective paintBorder function passed as parameter to method.  
> 
> Following are the usual steps for any border scaling -
> 
> - Resetting transform.
> - Calculating new width, height, x & y-translations.
> - Perform the required border rendering.
> - And at the end restore the previous transform.
> 
> To test the refactored code, 3 separate border scaling instances were taken (details below) and the SwingUtilities3.paintBorder, (containing the common functionality) was applied. All the tests associated with the respective border changes pass.
> 
> 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) - Test: ScaledEtchedBorderTest.java
> 2. LineBorder - [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
> 3. JInternalFrame Border - [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: InternalFrameBorderTest.java
> 
> The advantage of this solution is - it avoids code repetition and can be reused across all the border classes requiring border scaling fix.

Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - minor changes
 - Merge branch 'master' into RefactorBorder_8294484
 - Merge branch 'master' into RefactorBorder_8294484
 - review changes
 - Refactoring changes
 - Merge branch 'master' into RefactorBorder_8294484
 - revert MetalBorder changes
 - merge master
 - refactoring changes - initial commit

-------------

Changes: https://git.openjdk.org/jdk/pull/11571/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11571&range=02
  Stats: 272 lines in 4 files changed: 93 ins; 147 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/11571.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11571/head:pull/11571

PR: https://git.openjdk.org/jdk/pull/11571


From kizune at openjdk.org  Thu Dec 22 00:15:50 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 22 Dec 2022 00:15:50 GMT
Subject: [jdk20] Integrated: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus
In-Reply-To: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
Message-ID: <tPGd7rk_ukxL0rB05d56U62GeXTYk7yw9HwIrEBZPp0=.cb4cac18-6754-4376-b155-ee95d52660ae@github.com>

On Tue, 20 Dec 2022 23:38:31 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Slightly updated original fix - got rid of the extra flasher reset. Tests are fixed to be more stable and pass on the corresponding platforms.

This pull request has now been integrated.

Changeset: fef70d78
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/fef70d78baec9ce11d50b9a4c1fb26a1b854ccbf
Stats:     228 lines in 4 files changed: 68 ins; 76 del; 84 mod

8299077: [REDO] JDK-4512626 Non-editable JTextArea provides no visual indication of keyboard focus
8299127: [REDO] JDK-8194048 Regression automated test '/open/test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java' fails
8299128: [REDO] JDK-8213562 Test javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java fails

Reviewed-by: aivanov, azvegint

-------------

PR: https://git.openjdk.org/jdk20/pull/68


From tr at openjdk.org  Thu Dec 22 05:13:34 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 22 Dec 2022 05:13:34 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
Message-ID: <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>

> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.

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/11104/files
  - new: https://git.openjdk.org/jdk/pull/11104/files/120f7900..9dfccef1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11104&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11104&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11104.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11104/head:pull/11104

PR: https://git.openjdk.org/jdk/pull/11104


From tr at openjdk.org  Thu Dec 22 05:13:37 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 22 Dec 2022 05:13:37 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v3]
In-Reply-To: <YDlk5GEqfDFB5ppsdmdMlBeRboqtR8rQyVBGLUf6NKk=.cea4292f-7c5a-464e-b5fe-bb2536159f1f@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <urW8Rvtb6DHjNL7fzHeeqylkLXrzz0g7NIAqp56jrgE=.8e3cfaae-3760-4a74-8211-ee5efb5fe0bd@github.com>
 <YDlk5GEqfDFB5ppsdmdMlBeRboqtR8rQyVBGLUf6NKk=.cea4292f-7c5a-464e-b5fe-bb2536159f1f@github.com>
Message-ID: <b3FRnhfpOtwjMKYPoZlDh89OqyeoUCGQh8D6pgptZig=.53a96e7a-e3b9-4cd9-8a8f-56c9d52ab5cf@github.com>

On Wed, 21 Dec 2022 17:22:35 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/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1408:
> 
>> 1406: 
>> 1407:         public MultiResolutionIconImage(int baseSize, Image image) {
>> 1408:             assert image != null : "Null icons are added into MRI variants map";
> 
> Suggestion:
> 
>             assert image != null : "Null icon passed as the base image for MRI";

Updated.

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From aghaisas at openjdk.org  Thu Dec 22 05:49:00 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 22 Dec 2022 05:49:00 GMT
Subject: [jdk20] RFR: 8299207: [Testbug] Add back
 test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java
Message-ID: <TzP3yy7BByEkHUK3qRRpYLMU-iN45PmwBOpnzvmjp3w=.c1f389aa-33bc-4025-809b-596d1cd611fa@github.com>

- Regression test test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java was added as part of [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266). We had to revert [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) while fixing [JDK-8298217](https://bugs.openjdk.org/browse/JDK-8298217). 

- Although the [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) fix is no more needed, this test is good and can be added back to detect future regressions.

- CI test run is green with this test addition.

-------------

Commit messages:
 - Add back DrawPrimitivesTest

Changes: https://git.openjdk.org/jdk20/pull/72/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=72&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299207
  Stats: 150 lines in 1 file changed: 150 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/72.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/72/head:pull/72

PR: https://git.openjdk.org/jdk20/pull/72


From jdv at openjdk.org  Thu Dec 22 06:58:58 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 22 Dec 2022 06:58:58 GMT
Subject: [jdk20] RFR: 8299207: [Testbug] Add back
 test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java
In-Reply-To: <TzP3yy7BByEkHUK3qRRpYLMU-iN45PmwBOpnzvmjp3w=.c1f389aa-33bc-4025-809b-596d1cd611fa@github.com>
References: <TzP3yy7BByEkHUK3qRRpYLMU-iN45PmwBOpnzvmjp3w=.c1f389aa-33bc-4025-809b-596d1cd611fa@github.com>
Message-ID: <lX7BnH6SJkcMCycGVdckb2UZ-CBOaNbyGcl2VhYv0gA=.a43bed71-dc39-419e-ad6b-2d43bfa272f5@github.com>

On Thu, 22 Dec 2022 05:39:54 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> - Regression test test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java was added as part of [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266). We had to revert [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) while fixing [JDK-8298217](https://bugs.openjdk.org/browse/JDK-8298217). 
> 
> - Although the [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) fix is no more needed, this test is good and can be added back to detect future regressions.
> 
> - CI test run is green with this test addition.

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/72


From serb at openjdk.org  Thu Dec 22 07:22:55 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 Dec 2022 07:22:55 GMT
Subject: Integrated: 8298887: On the latest macOS+XCode the Robot API may
 report wrong colors
In-Reply-To: <xJUq-jlp7svDBuSk8ILnzQDpDwRwFctSKTPZfS0rP5I=.c07ed5a5-484f-4249-b1ef-b2c464341629@github.com>
References: <xJUq-jlp7svDBuSk8ILnzQDpDwRwFctSKTPZfS0rP5I=.c07ed5a5-484f-4249-b1ef-b2c464341629@github.com>
Message-ID: <8hphu4ZpBUcWyyTLnUlkOnubsJaLIYk78Q0JILckf0Y=.1f170573-561e-4631-9299-7f10e4df9855@github.com>

On Mon, 19 Dec 2022 21:48:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The new macOS SDK provided by XCode 14.2 changed this macro:
> `# define kCGBitmapByteOrder32Host kCGBitmapByteOrder32Little`
> to this constant
> `static const CGBitmapInfo kCGBitmapByteOrder32Host = kCGBitmapByteOrder32Little;`
> 
> As a result, our native code started to redefine the macro value to "define kCGBitmapByteOrder32Host 0". I think that was added a long time ago for a PPC platform.
> 
> I have also changed the type of the color we pass to the java Robot, the java code expects the xrgb format(the alpha ignored), but we for some reason prepared pre-multiplied alpha.
> 
> Tested on macOS 12.6.1 and 13.0.1 using xcode 14.2 and xcode 12.5.1

This pull request has now been integrated.

Changeset: 50120396
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/50120396b6cca1219fb5dd42a11e4b29b79bd3bd
Stats:     17 lines in 5 files changed: 0 ins; 12 del; 5 mod

8298887: On the latest macOS+XCode the Robot API may report wrong colors

Reviewed-by: azvegint

-------------

PR: https://git.openjdk.org/jdk/pull/11733


From lbourges at openjdk.org  Thu Dec 22 08:10:49 2022
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 22 Dec 2022 08:10:49 GMT
Subject: [jdk20] RFR: 8299207: [Testbug] Add back
 test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java
In-Reply-To: <TzP3yy7BByEkHUK3qRRpYLMU-iN45PmwBOpnzvmjp3w=.c1f389aa-33bc-4025-809b-596d1cd611fa@github.com>
References: <TzP3yy7BByEkHUK3qRRpYLMU-iN45PmwBOpnzvmjp3w=.c1f389aa-33bc-4025-809b-596d1cd611fa@github.com>
Message-ID: <LeZj4fRiE2s3ozoMfhRpE92eBOVKVR8hsq-IIXm-Omw=.59f72fa1-db3e-415d-b2b7-54e32ef3b06c@github.com>

On Thu, 22 Dec 2022 05:39:54 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> - Regression test test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java was added as part of [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266). We had to revert [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) while fixing [JDK-8298217](https://bugs.openjdk.org/browse/JDK-8298217). 
> 
> - Although the [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) fix is no more needed, this test is good and can be added back to detect future regressions.
> 
> - CI test run is green with this test addition.

LGTM

-------------

PR: https://git.openjdk.org/jdk20/pull/72


From djelinski at openjdk.org  Thu Dec 22 09:20:04 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Dec 2022 09:20:04 GMT
Subject: RFR: 8299260: Libawt should only export explicitly requested
 symbols
In-Reply-To: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
References: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
Message-ID: <pS9TL1lWXQQ_rj89QjVLCCOy_5R_YmpxjVlxcmUHuNE=.838dbdf6-41fe-4e3e-9269-ab3e45d2d476@github.com>

On Tue, 20 Dec 2022 18:59:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes unnecessary exports from libawt and libfreetype.
> 
> Verified that:
> - mach5 client libs tests pass
> - both release and debug builds finish successfully
> 
> Did not verify the other issues reported in the linked JBS ticket.

Thanks for the suggestion! I'll create a new bug for this fix instead, and leave a comment on the existing one.

-------------

PR: https://git.openjdk.org/jdk/pull/11742


From djelinski at openjdk.org  Thu Dec 22 10:17:27 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Dec 2022 10:17:27 GMT
Subject: RFR: 8299261: Clean up AWT D3D exports
Message-ID: <dAxIVJYLOXHv0t-y1d21lQyPx8v2SM7WTRn5Hf0Q96Q=.a0c5f8ac-3c7d-4984-bf08-065a8e06364b@github.com>

Please review this patch that removes unnecessary exports from awt.dll.

The exports were introduced in e4c9db984fe1a3a9d06fb60e333e92df3b165454, and as far as I could tell, they were never used; the exported functions are only used inside awt.dll.

Verified that:
- debug and release builds finish successfully
- mach5 client libs tests pass

-------------

Commit messages:
 - Clean up AWT D3D exports

Changes: https://git.openjdk.org/jdk/pull/11765/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11765&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299261
  Stats: 144 lines in 8 files changed: 5 ins; 106 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/11765.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11765/head:pull/11765

PR: https://git.openjdk.org/jdk/pull/11765


From abhiscxk at openjdk.org  Thu Dec 22 10:35:32 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 22 Dec 2022 10:35:32 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel [v2]
In-Reply-To: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
Message-ID: <IUkFswHdUwx2qx6lj6pEWtsAd6yS7N6EQj4G4iV_OMM=.d3edd5a8-6bbe-4540-b1b5-0be110f1410a@github.com>

> In case of GTK LAF, the current selected element was not visible due to arrowbutton is rendered in entire display area of Combobox.
> 
> The proposed fix is to set the `squareButton `property of combobox to `false `so that the arrowbutton didn't take entire combobox display area for rendering. The `getMinimumSize `method is overridden in `SynthComboBoxUI `to consider **arrowbutton insets** for combobox minimum size. 
> 
> The JCK tests mentioned in JBS seems fine with the fix. 
> An automated test case is implemented to test in Nimbus and GTK LAF. The text color check is to ensure the current selected item is visible.
> 
> When swing tests are run with LAF set to Nimbus and GTK LAF, few test failures observed. 
> 
> Although CI jobs looks ok with tests run in their default set LAFs.
> 
> `open/test/jdk/javax/swing/JComboBox/TestComboBoxHeight.java` test passes if run in GTK LAF with current fix.

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 update
 - Merge
 - Merge
 - Combobox componnet rendering fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11555/files
  - new: https://git.openjdk.org/jdk/pull/11555/files/b0db194b..ea53f8ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11555&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11555&range=00-01

  Stats: 159620 lines in 2761 files changed: 77674 ins; 58356 del; 23590 mod
  Patch: https://git.openjdk.org/jdk/pull/11555.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11555/head:pull/11555

PR: https://git.openjdk.org/jdk/pull/11555


From abhiscxk at openjdk.org  Thu Dec 22 10:35:35 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 22 Dec 2022 10:35:35 GMT
Subject: RFR: 8218474: JComboBox display issue with GTKLookAndFeel [v2]
In-Reply-To: <KLOOmtoO_cJhkJa-Q1xszITaOZcVjR2_lygpfLTwa0g=.12ae952c-9168-40a5-8ed4-aed3f3ded821@github.com>
References: <J3X3wQkjPMhrtwmQv4jgW8byBaroFyiqS259J49EX1M=.97e5ad70-59b5-4542-91ef-0e60248e7c5c@github.com>
 <KLOOmtoO_cJhkJa-Q1xszITaOZcVjR2_lygpfLTwa0g=.12ae952c-9168-40a5-8ed4-aed3f3ded821@github.com>
Message-ID: <8RtVYPfyikYOCpPSZ__GugvIVaRE_fTwk3768-pvtas=.44a4b5e3-b043-4ea1-b3b2-38240d80c3cb@github.com>

On Wed, 21 Dec 2022 11:27:30 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> 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 update
>>  - Merge
>>  - Merge
>>  - Combobox componnet rendering fix
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java line 374:
> 
>> 372:         size.height += insets.top + insets.bottom + arrowInsets.top
>> 373:                         + arrowInsets.bottom;
>> 374:         size.width +=  insets.left + insets.right +arrowInsets.left
> 
> Suggestion:
> 
>         size.width  += insets.left + insets.right + arrowInsets.left

Updated.

-------------

PR: https://git.openjdk.org/jdk/pull/11555


From aghaisas at openjdk.org  Thu Dec 22 10:41:53 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 22 Dec 2022 10:41:53 GMT
Subject: [jdk20] Integrated: 8299207: [Testbug] Add back
 test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java
In-Reply-To: <TzP3yy7BByEkHUK3qRRpYLMU-iN45PmwBOpnzvmjp3w=.c1f389aa-33bc-4025-809b-596d1cd611fa@github.com>
References: <TzP3yy7BByEkHUK3qRRpYLMU-iN45PmwBOpnzvmjp3w=.c1f389aa-33bc-4025-809b-596d1cd611fa@github.com>
Message-ID: <qQbIj_E8E4F8li6cLqJdkA1roLvtOn5gGXJbqxuCUiE=.2f0b3405-36bc-4965-aca9-e16472b8e257@github.com>

On Thu, 22 Dec 2022 05:39:54 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> - Regression test test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java was added as part of [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266). We had to revert [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) while fixing [JDK-8298217](https://bugs.openjdk.org/browse/JDK-8298217). 
> 
> - Although the [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) fix is no more needed, this test is good and can be added back to detect future regressions.
> 
> - CI test run is green with this test addition.

This pull request has now been integrated.

Changeset: 5e001d6f
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/5e001d6ff34e2cc954f824117a73dd39f09a81c1
Stats:     150 lines in 1 file changed: 150 ins; 0 del; 0 mod

8299207: [Testbug] Add back test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java

Co-authored-by: Alexey Ushakov <avu at openjdk.org>
Reviewed-by: jdv

-------------

PR: https://git.openjdk.org/jdk20/pull/72


From alexsch at openjdk.org  Thu Dec 22 10:57:15 2022
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Thu, 22 Dec 2022 10:57:15 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows [v2]
In-Reply-To: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
Message-ID: <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>

> **Environment**: 
> GraalVM 22.3.0 with  jdk 19, Windows OS.
> 
> **Description**:
> Create a native image of Swing application using GraalVM and run it with ` -Dsun.awt.fontconfig=fontconfig.properties.src` java property.
> `java.lang.Error: java.home property not set` error is thrown.
> 
> For more details see https://github.com/oracle/graal/issues/4875.
> 
> **Solution**:
> The error is thrown by the code from [FontConfiguration.findFontConfigFile()](https://github.com/openjdk/jdk19u/blob/c9d485792b99233f381dcdfd69838e7b973909bd/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L175) method.
> GraalVM does not set `java.home`  property, that is why the `java.lang.Error: java.home property not set` is thrown.
> `FontConfiguration.findFontConfigFile()` method compares `java.home` property to null before checking user provided `sun.awt.fontconfig` java property.
> 
> The proposed fix swaps the order of `java.home` and `sun.awt.fontconfig` properties checking to avoid using `java.home` property in case `sun.awt.fontconfig` is set.
> 
> 
> **Steps to reproduce**:
> - Download graal 22.3.0 jdk 19 for Windows from [GraalVM Community Edition 22.3.0](https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0) page.
> - Install native-image
> 
> graalvm-ce-java19-22.3.0\bin\gu.cmd install native-image
> 
> - Create and compile `SwingSample.java` sample
> 
> import java.awt.*;
> import javax.swing.*;
> 
> public class SwingSample {
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeAndWait(() -> {
> 
>             JFrame frame = new JFrame("Hello World");
> 
>             JButton button = new JButton("Hello");
>             button.addActionListener(e -> {
>                 System.out.printf("Hello, World!%n");
>             });
> 
>             JPanel panel = new JPanel(new FlowLayout());
>             panel.add(button);
> 
>             frame.add(panel);
>             frame.setSize(400, 300);
>             frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>             frame.setVisible(true);
>         });
>     }
> }
> 
> - Run native-image-agent to generate configuration files
> 
> graalvm-ce-java19-22.3.0\bin\java.cmd -agentlib:native-image-agent=config-output-dir=conf-dir SwingSample
> 
> - Copy `graalvm-ce-java19-22.3.0\lib\fontconfig.properties.src` file to the sample dir
> - Generate native image with configuration files and `-Djava.awt.headless=false `, `-Dsun.awt.fontconfig=fontconfig.properties.src` java properties
> 
> call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64"
> graalvm-ce-java19-22.3.0\bin\native-image.cmd --no-fallback -Djava.awt.headless=false -Dsun.awt.fontconfig=fontconfig.properties.src -H:ResourceConfigurationFiles=conf-dir/resource-config.json -H:SerializationConfigurationFiles=conf-dir/serialization-config.json -H:ReflectionConfigurationFiles=conf-dir/reflect-config.json -H:JNIConfigurationFiles=conf-dir/jni-config.json SwingSample
> 
> - Run the native image with `-Dsun.awt.fontconfig=fontconfig.properties.src` java property.
> 
> swingsample.exe  -Dsun.awt.fontconfig=fontconfig.properties.src
> 
> Exception in thread "main" java.lang.reflect.InvocationTargetException
>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371)
>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346)
>         at java.desktop at 19.0.1/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480)
>         at SwingSample.main(SwingSample.java:7)
> Caused by: java.lang.Error: java.home property not set
>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
>         at java.desktop at 19.0.1/sun.awt.windows.WFontConfiguration.<init>(WFontConfiguration.java:41)

Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:

  Initialize javaLib when a user fontconfig file is set

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11559/files
  - new: https://git.openjdk.org/jdk/pull/11559/files/f50dc866..f882a0eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11559&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11559&range=00-01

  Stats: 6 lines in 1 file changed: 4 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11559.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11559/head:pull/11559

PR: https://git.openjdk.org/jdk/pull/11559


From alexsch at openjdk.org  Thu Dec 22 11:01:49 2022
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Thu, 22 Dec 2022 11:01:49 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows [v2]
In-Reply-To: <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
 <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
Message-ID: <sJu-efFAhiB_vaOBcZ4S2DupfYyVdxFPuHuQQSk7Ka4=.b16efae3-6c4a-4b42-8faa-0c2d08338836@github.com>

On Thu, 22 Dec 2022 10:57:15 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> **Environment**: 
>> GraalVM 22.3.0 with  jdk 19, Windows OS.
>> 
>> **Description**:
>> Create a native image of Swing application using GraalVM and run it with ` -Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> `java.lang.Error: java.home property not set` error is thrown.
>> 
>> For more details see https://github.com/oracle/graal/issues/4875.
>> 
>> **Solution**:
>> The error is thrown by the code from [FontConfiguration.findFontConfigFile()](https://github.com/openjdk/jdk19u/blob/c9d485792b99233f381dcdfd69838e7b973909bd/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L175) method.
>> GraalVM does not set `java.home`  property, that is why the `java.lang.Error: java.home property not set` is thrown.
>> `FontConfiguration.findFontConfigFile()` method compares `java.home` property to null before checking user provided `sun.awt.fontconfig` java property.
>> 
>> The proposed fix swaps the order of `java.home` and `sun.awt.fontconfig` properties checking to avoid using `java.home` property in case `sun.awt.fontconfig` is set.
>> 
>> 
>> **Steps to reproduce**:
>> - Download graal 22.3.0 jdk 19 for Windows from [GraalVM Community Edition 22.3.0](https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0) page.
>> - Install native-image
>> 
>> graalvm-ce-java19-22.3.0\bin\gu.cmd install native-image
>> 
>> - Create and compile `SwingSample.java` sample
>> 
>> import java.awt.*;
>> import javax.swing.*;
>> 
>> public class SwingSample {
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeAndWait(() -> {
>> 
>>             JFrame frame = new JFrame("Hello World");
>> 
>>             JButton button = new JButton("Hello");
>>             button.addActionListener(e -> {
>>                 System.out.printf("Hello, World!%n");
>>             });
>> 
>>             JPanel panel = new JPanel(new FlowLayout());
>>             panel.add(button);
>> 
>>             frame.add(panel);
>>             frame.setSize(400, 300);
>>             frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>             frame.setVisible(true);
>>         });
>>     }
>> }
>> 
>> - Run native-image-agent to generate configuration files
>> 
>> graalvm-ce-java19-22.3.0\bin\java.cmd -agentlib:native-image-agent=config-output-dir=conf-dir SwingSample
>> 
>> - Copy `graalvm-ce-java19-22.3.0\lib\fontconfig.properties.src` file to the sample dir
>> - Generate native image with configuration files and `-Djava.awt.headless=false `, `-Dsun.awt.fontconfig=fontconfig.properties.src` java properties
>> 
>> call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64"
>> graalvm-ce-java19-22.3.0\bin\native-image.cmd --no-fallback -Djava.awt.headless=false -Dsun.awt.fontconfig=fontconfig.properties.src -H:ResourceConfigurationFiles=conf-dir/resource-config.json -H:SerializationConfigurationFiles=conf-dir/serialization-config.json -H:ReflectionConfigurationFiles=conf-dir/reflect-config.json -H:JNIConfigurationFiles=conf-dir/jni-config.json SwingSample
>> 
>> - Run the native image with `-Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> 
>> swingsample.exe  -Dsun.awt.fontconfig=fontconfig.properties.src
>> 
>> Exception in thread "main" java.lang.reflect.InvocationTargetException
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371)
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346)
>>         at java.desktop at 19.0.1/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480)
>>         at SwingSample.main(SwingSample.java:7)
>> Caused by: java.lang.Error: java.home property not set
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
>>         at java.desktop at 19.0.1/sun.awt.windows.WFontConfiguration.<init>(WFontConfiguration.java:41)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize javaLib when a user fontconfig file is set

Could you review the updated fix? The `javaLib` variable is initialized even `userConfigFile` is not null.

-------------

PR: https://git.openjdk.org/jdk/pull/11559


From tnakamura at openjdk.org  Thu Dec 22 11:40:01 2022
From: tnakamura at openjdk.org (Toshio Nakamura)
Date: Thu, 22 Dec 2022 11:40:01 GMT
Subject: RFR: 8299255: Unexpected round errors in FreetypeFontScaler
Message-ID: <94vFT5CtKVy47qA2LgpWnBbbkVeIR09KumB7YAhcBBI=.72e88bba-cd2e-458e-a37b-74782af36185@github.com>

In 'Java_sun_font_FreetypeFontScaler_createScalerContextNative', 'context->transform.xx' and '.yy' values are sometimes 65535 instead of 65536. There are unintentional double and float conversions. It may be no real harm, but I'd like to fix it.

Problem case:
context->transform.xx=**65535** yx=0 xy=0 yy=**65535** ptsz=46.590909 dmat[0]=46.590909 (float)dmat[0]=46.59090**8**

Normal case:
context->transform.xx=65536 yx=0 xy=0 yy=65536 ptsz=18.000000 dmat[0]=18.000000 (float)dmat[0]=18.000000

Test: jdk_desktop on Linux x86_64 had no regression issues.

-------------

Commit messages:
 - 8299255: Unexpected round errors in FreetypeFontScaler

Changes: https://git.openjdk.org/jdk/pull/11763/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11763&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299255
  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11763.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11763/head:pull/11763

PR: https://git.openjdk.org/jdk/pull/11763


From aivanov at openjdk.org  Thu Dec 22 12:55:52 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Dec 2022 12:55:52 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
Message-ID: <C6PQLYrwVpxUZ6r_LMVulZYqliyjJH6ULTQORJRAEN0=.2bdf0d22-b8c2-458d-a46a-0ae7bc997759@github.com>

On Thu, 22 Dec 2022 05:13:34 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.
>
> 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/11104


From aivanov at openjdk.org  Thu Dec 22 14:59:50 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Dec 2022 14:59:50 GMT
Subject: RFR: 8299260: Libawt should only export explicitly requested
 symbols
In-Reply-To: <pS9TL1lWXQQ_rj89QjVLCCOy_5R_YmpxjVlxcmUHuNE=.838dbdf6-41fe-4e3e-9269-ab3e45d2d476@github.com>
References: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
 <pS9TL1lWXQQ_rj89QjVLCCOy_5R_YmpxjVlxcmUHuNE=.838dbdf6-41fe-4e3e-9269-ab3e45d2d476@github.com>
Message-ID: <ABRQ6tIV3WkLOp4RxOMpwA_yNeBueEg2kV26_q-KyPQ=.9c50686c-3740-4077-8dfa-17b4801cf322@github.com>

On Thu, 22 Dec 2022 09:17:11 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Thanks for the suggestion! I'll create a new bug for this fix instead, and leave a comment on the existing one.

Thank you! This way it's clearer.

What about libfreetype? You also modify its settings.

_libawt and libfreetype should export only explicitly requested symbols_

Does this subject look good?

-------------

PR: https://git.openjdk.org/jdk/pull/11742


From aivanov at openjdk.org  Thu Dec 22 15:33:50 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Dec 2022 15:33:50 GMT
Subject: RFR: 8299260: libawt and libfreetype should export only explicitly
 requested symbols
In-Reply-To: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
References: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
Message-ID: <6Nqfh-XNOEL-CYfbcV6qx9P0iOHybLOqejwTHgNJ3C4=.1ce6dd56-1f76-466b-9e55-401c5997bdcf@github.com>

On Tue, 20 Dec 2022 18:59:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes unnecessary exports from libawt and libfreetype.
> 
> Verified that:
> - mach5 client libs tests pass
> - both release and debug builds finish successfully

The number of exported symbols from `libawt` and `libfreetype` is much lower now: 192 vs 970 and 222 vs 560.

I ran _clientlibs_ tests, no failures detected.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11742


From abhiscxk at openjdk.org  Thu Dec 22 17:15:26 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 22 Dec 2022 17:15:26 GMT
Subject: RFR: 8299227: host `exif.org` not found in link in doc comment
Message-ID: <BcDWg3I3tiODAkpifwJaNguBVvJDhokL40msPLVohkY=.d43d3a77-ad94-44df-b08c-642889c73273@github.com>

Broken links are replaced by the similar links fixed in [JDK-8288527](https://bugs.openjdk.org/browse/JDK-8288527) for file `src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java`.

-------------

Commit messages:
 - Broken links fix
 - Broken link fix

Changes: https://git.openjdk.org/jdk/pull/11768/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11768&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299227
  Stats: 5 lines in 3 files changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11768.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11768/head:pull/11768

PR: https://git.openjdk.org/jdk/pull/11768


From jdv at openjdk.org  Thu Dec 22 18:14:49 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 22 Dec 2022 18:14:49 GMT
Subject: RFR: 8299227: host `exif.org` not found in link in doc comment
In-Reply-To: <BcDWg3I3tiODAkpifwJaNguBVvJDhokL40msPLVohkY=.d43d3a77-ad94-44df-b08c-642889c73273@github.com>
References: <BcDWg3I3tiODAkpifwJaNguBVvJDhokL40msPLVohkY=.d43d3a77-ad94-44df-b08c-642889c73273@github.com>
Message-ID: <fMl0ZPeYdhu51285yYnyA1hkEb1qRfaPPyIRaMFJV-U=.d22bb337-9899-4a56-955e-3d791e03cb89@github.com>

On Thu, 22 Dec 2022 17:07:44 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Broken links are replaced by the similar links fixed in [JDK-8288527](https://bugs.openjdk.org/browse/JDK-8288527) for file `src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java`.

Since this is a simple change we can still push it to JDK20.

-------------

PR: https://git.openjdk.org/jdk/pull/11768


From honkar at openjdk.org  Thu Dec 22 18:15:07 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 22 Dec 2022 18:15:07 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11 [v2]
In-Reply-To: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
Message-ID: <tyvPceH1cD44Cvhu0H9Nyh9fXjvVM6zRQY58eDGvhGc=.dcccbc38-d120-490e-9b4f-82177e604917@github.com>

> ViewportOverlapping was failing intermittently on Windows (Win10 & 11). Added robot.setAutoWaitForIdle() to ViewportOverlapping and its base class (OverlappingTestBase) to stabilize the test.
> 
> Additionally added awt & swings tests to exclusiveAccess.dir in TEST.ROOT.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  reverted TEST.ROOT changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11747/files
  - new: https://git.openjdk.org/jdk/pull/11747/files/ee4d0762..a5a23745

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11747&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11747&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11747.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11747/head:pull/11747

PR: https://git.openjdk.org/jdk/pull/11747


From prr at openjdk.org  Thu Dec 22 18:28:51 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 Dec 2022 18:28:51 GMT
Subject: RFR: 8299227: host `exif.org` not found in link in doc comment
In-Reply-To: <BcDWg3I3tiODAkpifwJaNguBVvJDhokL40msPLVohkY=.d43d3a77-ad94-44df-b08c-642889c73273@github.com>
References: <BcDWg3I3tiODAkpifwJaNguBVvJDhokL40msPLVohkY=.d43d3a77-ad94-44df-b08c-642889c73273@github.com>
Message-ID: <ymoajzU_Wco5uxLdC4wgnwidwSRGA3erUdjQhJ87IF8=.faabfadd-8987-4d07-b74c-0f0fdcf0275a@github.com>

On Thu, 22 Dec 2022 17:07:44 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Broken links are replaced by the similar links fixed in [JDK-8288527](https://bugs.openjdk.org/browse/JDK-8288527) for file `src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java`.

The suggestion was to fix this doc bug in JDK20. So this is the wrong repo.
You need to withdraw this PR and resubmit against JDK 20
Remember JDK 20 fixes are forward ported to JDK mainline, not the other way around.

-------------

PR: https://git.openjdk.org/jdk/pull/11768


From prr at openjdk.org  Thu Dec 22 18:35:51 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 Dec 2022 18:35:51 GMT
Subject: RFR: 8299227: host `exif.org` not found in link in doc comment
In-Reply-To: <BcDWg3I3tiODAkpifwJaNguBVvJDhokL40msPLVohkY=.d43d3a77-ad94-44df-b08c-642889c73273@github.com>
References: <BcDWg3I3tiODAkpifwJaNguBVvJDhokL40msPLVohkY=.d43d3a77-ad94-44df-b08c-642889c73273@github.com>
Message-ID: <bwKQbyYlOvDRbr_2xMyVlmncWvNx76YlrcA6I8HhMo0=.905ad7fa-5d25-41af-8012-0c2891c7e396@github.com>

On Thu, 22 Dec 2022 17:07:44 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Broken links are replaced by the similar links fixed in [JDK-8288527](https://bugs.openjdk.org/browse/JDK-8288527) for file `src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java`.

Changes requested by prr (Reviewer).

src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageWriteParam.java line 81:

> 79:  * <td>Exif JPEG</td>
> 80:  * <td>Exif-specific JPEG compression (see note following this table)</td>
> 81:  * <td><a href="https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf">Exif 2.2 Specification</a>

BTW the link at the other end is EXIF 2.3 .. so you probably want to fix the text too.

src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageWriteParam.java line 82:

> 80:  * <td>Exif-specific JPEG compression (see note following this table)</td>
> 81:  * <td><a href="https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf">Exif 2.2 Specification</a>
> 82:  * (PDF), section 4.5.5, "Basic Structure of Thumbnail Data"</td>

This is now 4.5.8

src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html line 579:

> 577: <td><a href="https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf">
> 578:     Exif 2.2 Specification</a>
> 579: (PDF), section 4.5.5, "Basic Structure of Thumbnail Data"</td>

This is now 4.5.8

src/java.desktop/share/native/libjavajpeg/imageioJPEG.c line 1619:

> 1617:  * (see https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf, section 4.7, page 58)
> 1618:  */
> 1619: #define IS_EXIF(c) \

Page number is no longer correct

src/java.desktop/share/native/libjavajpeg/imageioJPEG.c line 1718:

> 1716:              *     Must be YCbCr (see http://www.w3.org/Graphics/JPEG/jfif3.pdf, page 2)
> 1717:              *  - we got EXIF image
> 1718:              *     Must be YCbCr (see https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf, section 4.7, page 63)

Page number is no longer correct

-------------

PR: https://git.openjdk.org/jdk/pull/11768


From prr at openjdk.org  Thu Dec 22 18:35:53 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 Dec 2022 18:35:53 GMT
Subject: RFR: 8299227: host `exif.org` not found in link in doc comment
In-Reply-To: <bwKQbyYlOvDRbr_2xMyVlmncWvNx76YlrcA6I8HhMo0=.905ad7fa-5d25-41af-8012-0c2891c7e396@github.com>
References: <BcDWg3I3tiODAkpifwJaNguBVvJDhokL40msPLVohkY=.d43d3a77-ad94-44df-b08c-642889c73273@github.com>
 <bwKQbyYlOvDRbr_2xMyVlmncWvNx76YlrcA6I8HhMo0=.905ad7fa-5d25-41af-8012-0c2891c7e396@github.com>
Message-ID: <yi8A4uyOecW9meNwdeU7iq5s9XxdN0wN5AsEdo349R4=.59a9ea49-f4e3-4d78-9e11-2f103195e7ab@github.com>

On Thu, 22 Dec 2022 18:31:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> Broken links are replaced by the similar links fixed in [JDK-8288527](https://bugs.openjdk.org/browse/JDK-8288527) for file `src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java`.
>
> src/java.desktop/share/native/libjavajpeg/imageioJPEG.c line 1619:
> 
>> 1617:  * (see https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf, section 4.7, page 58)
>> 1618:  */
>> 1619: #define IS_EXIF(c) \
> 
> Page number is no longer correct

I think it should be page 83

-------------

PR: https://git.openjdk.org/jdk/pull/11768


From abhiscxk at openjdk.org  Thu Dec 22 18:46:51 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 22 Dec 2022 18:46:51 GMT
Subject: RFR: 8299227: host `exif.org` not found in link in doc comment
In-Reply-To: <BcDWg3I3tiODAkpifwJaNguBVvJDhokL40msPLVohkY=.d43d3a77-ad94-44df-b08c-642889c73273@github.com>
References: <BcDWg3I3tiODAkpifwJaNguBVvJDhokL40msPLVohkY=.d43d3a77-ad94-44df-b08c-642889c73273@github.com>
Message-ID: <edB-TnqMz8GGXrB9f5KS1BBW8xkICR8048rPuY2DgGE=.039273cd-c5b2-4e47-b3de-67318d2eacb2@github.com>

On Thu, 22 Dec 2022 17:07:44 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Broken links are replaced by the similar links fixed in [JDK-8288527](https://bugs.openjdk.org/browse/JDK-8288527) for file `src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java`.

I will raise a PR for JDK20 repo with suggested changes.
Thank you.

-------------

PR: https://git.openjdk.org/jdk/pull/11768


From aturbanov at openjdk.org  Thu Dec 22 19:12:53 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 22 Dec 2022 19:12:53 GMT
Subject: Integrated: 8299199: Avoid redundant split calls in
 FontConfiguration.initReorderMap implementations
In-Reply-To: <DuDfZ1ahO9lvjdQjpJ88C1sMtwuqMT7O8HtXE4k6TeM=.fe53f02c-b9b0-44b4-9257-54f30a5446fe@github.com>
References: <DuDfZ1ahO9lvjdQjpJ88C1sMtwuqMT7O8HtXE4k6TeM=.fe53f02c-b9b0-44b4-9257-54f30a5446fe@github.com>
Message-ID: <UDqAiqVW7GFqZ9SSOhL9TQn5dxc5XsC0Se7VWYXpI2U=.9cb7c4ff-c86c-4810-bed3-71aba513f7ff@github.com>

On Wed, 21 Dec 2022 11:03:08 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `FontConfiguration.split` uses legacy synchronized `Vector` class. But actually there is no need to use it, because input arguments are known at compile time. Instead of split usages we can just create String[] array with filled values directly.

This pull request has now been integrated.

Changeset: b378381a
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b378381a9c5abf555c4ccf87d387d2cd77196e04
Stats:     9 lines in 3 files changed: 0 ins; 7 del; 2 mod

8299199: Avoid redundant split calls in FontConfiguration.initReorderMap implementations

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/11754


From aivanov at openjdk.org  Thu Dec 22 20:41:49 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Dec 2022 20:41:49 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds [v2]
In-Reply-To: <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
Message-ID: <aSifVJRa62shis8D30fdNdwxcUAzCybqmo6ZtiP7uBY=.4ffd8c68-3ebe-436e-b3a7-a1a23b8d0c03@github.com>

On Mon, 5 Dec 2022 22:10:15 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The above test was failing due to incorrect pixel color and wrong window bounds on Mac-ARM, Windows and Linux platforms.
>> 
>> The following changes have been made:
>> - Correct window bounds are obtained using the current ScreenDevice's DefaultConfig bounds (this test checks FullScreen functionality on multiple screen devices).
>> - Color tolerance has been added for color check
>> - Instead of scanning the full screen to check pixel color, vertical and horizontal scans are done at the far right and bottom end to ensure that window is in full screen mode w.r.t to screen device and the window bounds are as expected.
>> 
>> CI testing passes on all platforms (tested 50 times per platform).
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   frame changed back to decorated and exclude on linux

Why can't we scan all the pixels? It was the purpose of the test to ensure each window has the exact color. Does it take very long time?

Why is color tolerance needed? Is it to account for High DPI display? Can we use [`Robot.createMultiResolutionScreenCapture`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Robot.html#createMultiResolutionScreenCapture(java.awt.Rectangle)) to ensure the `BufferedImage` contains the actual pixels rather a scaled down version?

test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 109:

> 107:         if (!exp.equals(actual)) {
> 108:             System.out.println(" Wrong window size:" +
> 109:                                " Expected: " + exp + " Actual: " + actual);

I'd rather leave `err` ? it's supposed for printing error messages.

-------------

PR: https://git.openjdk.org/jdk/pull/11462


From abhiscxk at openjdk.org  Thu Dec 22 21:25:57 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 22 Dec 2022 21:25:57 GMT
Subject: RFR: 8299227: host `exif.org` not found in link in doc comment
In-Reply-To: <BcDWg3I3tiODAkpifwJaNguBVvJDhokL40msPLVohkY=.d43d3a77-ad94-44df-b08c-642889c73273@github.com>
References: <BcDWg3I3tiODAkpifwJaNguBVvJDhokL40msPLVohkY=.d43d3a77-ad94-44df-b08c-642889c73273@github.com>
Message-ID: <AvL70OCQYH_rt5VS5vMaM1FLIRDFImt5YOlcCjsGhII=.d5532b53-a46b-48fa-a7e7-5698955990d5@github.com>

On Thu, 22 Dec 2022 17:07:44 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Broken links are replaced by the similar links fixed in [JDK-8288527](https://bugs.openjdk.org/browse/JDK-8288527) for file `src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java`.

Withdrawing this PR.
I will submit for JDK20 repo.

-------------

PR: https://git.openjdk.org/jdk/pull/11768


From abhiscxk at openjdk.org  Thu Dec 22 21:25:58 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 22 Dec 2022 21:25:58 GMT
Subject: Withdrawn: 8299227: host `exif.org` not found in link in doc comment
In-Reply-To: <BcDWg3I3tiODAkpifwJaNguBVvJDhokL40msPLVohkY=.d43d3a77-ad94-44df-b08c-642889c73273@github.com>
References: <BcDWg3I3tiODAkpifwJaNguBVvJDhokL40msPLVohkY=.d43d3a77-ad94-44df-b08c-642889c73273@github.com>
Message-ID: <CqWTaOQ5tzgCkxqxsLlpybKzYEvxDZ60Gw8vLQbJWro=.34f15f51-8383-4c02-8976-ddc4d22a9966@github.com>

On Thu, 22 Dec 2022 17:07:44 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Broken links are replaced by the similar links fixed in [JDK-8288527](https://bugs.openjdk.org/browse/JDK-8288527) for file `src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java`.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11768


From abhiscxk at openjdk.org  Thu Dec 22 21:39:21 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 22 Dec 2022 21:39:21 GMT
Subject: [jdk20] RFR: 8299227: host exif.org not found in link in doc comment
Message-ID: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>

Reported broken links are updated accordingly.

-------------

Commit messages:
 - Broken links fix

Changes: https://git.openjdk.org/jdk20/pull/74/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=74&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299227
  Stats: 11 lines in 3 files changed: 4 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk20/pull/74.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/74/head:pull/74

PR: https://git.openjdk.org/jdk20/pull/74


From abhiscxk at openjdk.org  Thu Dec 22 21:39:21 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 22 Dec 2022 21:39:21 GMT
Subject: [jdk20] RFR: 8299227: host exif.org not found in link in doc
 comment
In-Reply-To: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
References: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
Message-ID: <uIu8K6Heqa2qjWLfN6YV3-u1Idy6452Vh9ZeOZYDsK8=.a7358328-558c-4300-b009-dda1350428ff@github.com>

On Thu, 22 Dec 2022 21:32:05 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Reported broken links are updated accordingly.

@prrace Updated the broken links for spec version 2.2.

-------------

PR: https://git.openjdk.org/jdk20/pull/74


From abhiscxk at openjdk.org  Thu Dec 22 21:52:43 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 22 Dec 2022 21:52:43 GMT
Subject: [jdk20] RFR: 8299227: host exif.org not found in link in doc
 comment [v2]
In-Reply-To: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
References: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
Message-ID: <CkBcNmCs96sP6ou8iSrMzqKa06tGQXkln-PNeDC1WOw=.360d4fb6-8b23-409d-8892-349fda6b806d@github.com>

> Reported broken links are updated accordingly.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Link re-fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/74/files
  - new: https://git.openjdk.org/jdk20/pull/74/files/2dfc8239..e5e3b929

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=74&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=74&range=00-01

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk20/pull/74.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/74/head:pull/74

PR: https://git.openjdk.org/jdk20/pull/74


From serb at openjdk.org  Thu Dec 22 21:55:55 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 Dec 2022 21:55:55 GMT
Subject: RFR: 8299255: Unexpected round errors in FreetypeFontScaler
In-Reply-To: <94vFT5CtKVy47qA2LgpWnBbbkVeIR09KumB7YAhcBBI=.72e88bba-cd2e-458e-a37b-74782af36185@github.com>
References: <94vFT5CtKVy47qA2LgpWnBbbkVeIR09KumB7YAhcBBI=.72e88bba-cd2e-458e-a37b-74782af36185@github.com>
Message-ID: <R_D87TZaDD4LOtCmlCTTwUuIxdZBNDMRbKR3xD59zKg=.a1821376-a375-4084-b092-4688d469ddf2@github.com>

On Thu, 22 Dec 2022 07:20:03 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> In 'Java_sun_font_FreetypeFontScaler_createScalerContextNative', 'context->transform.xx' and '.yy' values are sometimes 65535 instead of 65536. There are unintentional double and float conversions. It may be no real harm, but I'd like to fix it.
> 
> Problem case:
> context->transform.xx=**65535** yx=0 xy=0 yy=**65535** ptsz=46.590909 dmat[0]=46.590909 (float)dmat[0]=46.59090**8**
> 
> Normal case:
> context->transform.xx=65536 yx=0 xy=0 yy=65536 ptsz=18.000000 dmat[0]=18.000000 (float)dmat[0]=18.000000
> 
> Test: jdk_desktop on Linux x86_64 had no regression issues.

Is it possible to create a test case for this issue?

-------------

PR: https://git.openjdk.org/jdk/pull/11763


From serb at openjdk.org  Thu Dec 22 21:57:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 Dec 2022 21:57:51 GMT
Subject: RFR: 8299260: libawt and libfreetype should export only explicitly
 requested symbols
In-Reply-To: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
References: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
Message-ID: <Qq9MY-jh5r5fKRTVF-pQBB7qR-pk7jiGRX1_bZ7E8tM=.2d9b1fe0-e5af-4512-87d1-355c4aac29ec@github.com>

On Tue, 20 Dec 2022 18:59:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes unnecessary exports from libawt and libfreetype.
> 
> Verified that:
> - mach5 client libs tests pass
> - both release and debug builds finish successfully

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11742


From serb at openjdk.org  Thu Dec 22 21:58:54 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 Dec 2022 21:58:54 GMT
Subject: RFR: 8299261: Clean up AWT D3D exports
In-Reply-To: <dAxIVJYLOXHv0t-y1d21lQyPx8v2SM7WTRn5Hf0Q96Q=.a0c5f8ac-3c7d-4984-bf08-065a8e06364b@github.com>
References: <dAxIVJYLOXHv0t-y1d21lQyPx8v2SM7WTRn5Hf0Q96Q=.a0c5f8ac-3c7d-4984-bf08-065a8e06364b@github.com>
Message-ID: <Ydf3fAVe3mfX-hZ57uaC_BUmaLzl1FDOakS6IpO9FTw=.5d35a524-3b75-4b9a-8fc8-eb000466cd62@github.com>

On Thu, 22 Dec 2022 10:01:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes unnecessary exports from awt.dll.
> 
> The exports were introduced in e4c9db984fe1a3a9d06fb60e333e92df3b165454, and as far as I could tell, they were never used; the exported functions are only used inside awt.dll.
> 
> Verified that:
> - debug and release builds finish successfully
> - mach5 client libs tests pass

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11765


From honkar at openjdk.org  Thu Dec 22 22:05:50 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 22 Dec 2022 22:05:50 GMT
Subject: RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to
 incorrect pixel color and wrong window bounds [v2]
In-Reply-To: <aSifVJRa62shis8D30fdNdwxcUAzCybqmo6ZtiP7uBY=.4ffd8c68-3ebe-436e-b3a7-a1a23b8d0c03@github.com>
References: <MW18Sle0HQbBqDfZoCzu1we8QMJkwDOWzMzctciJhQs=.c8e38e88-0a7b-4720-8e7d-e3670a3e088f@github.com>
 <pLfEzW6uKCiYwPoupD8EupRVVl3JAlC0u4b2mj5AtCw=.e01a56c1-37ad-40a6-921a-75f9fd354c63@github.com>
 <aSifVJRa62shis8D30fdNdwxcUAzCybqmo6ZtiP7uBY=.4ffd8c68-3ebe-436e-b3a7-a1a23b8d0c03@github.com>
Message-ID: <tQFUlui7EfK7f-ZPmAaI51aw0hyWzyTxXJSzB7Wcosg=.70abc002-2e50-4d3f-9ffe-11b0421b4295@github.com>

On Thu, 22 Dec 2022 20:39:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Why can't we scan all the pixels? It was the purpose of the test to ensure each window has the exact color. Does it take very long time?

There isn't a significant time difference but I think it might be a better and efficient way. Since the right and bottom scans span across the entire height and width of full screen window, it can test the extent of full screen window effectively.
 
> Why is color tolerance needed? Is it to account for High DPI display? Can we use [`Robot.createMultiResolutionScreenCapture`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Robot.html#createMultiResolutionScreenCapture(java.awt.Rectangle)) to ensure the `BufferedImage` contains the actual pixels rather a scaled down version?

There seems to be color issues at certain locations the color is not exactly red or green hence the testColor check fails on some platforms. I'll have to recheck and test the artifacts like Sergey mentioned it earlier.

-------------

PR: https://git.openjdk.org/jdk/pull/11462


From serb at openjdk.org  Thu Dec 22 22:15:50 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 Dec 2022 22:15:50 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
In-Reply-To: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
Message-ID: <0x0ms0yarrHQrs6_AoYPZITOYxDHTyrHHgtfUzzaFKg=.687fa12c-eee3-4a89-9f36-1fa4792c7481@github.com>

On Wed, 14 Dec 2022 10:47:09 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> [OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

src/java.desktop/share/classes/javax/swing/JList.java line 3234:

> 3232:               static {
> 3233:                   AccessibleComponentAccessor.addAccessor(c ->
> 3234:                           c instanceof JList.AccessibleJList.AccessibleJListChild ? ((JList.AccessibleJList.AccessibleJListChild) c).getCurrentComponent() : null);

Please split the long lines to have 80 chars per line.

src/java.desktop/share/classes/sun/swing/AccessibleComponentAccessor.java line 42:

> 40:     }
> 41: 
> 42:     public static Accessible getAccessible(AccessibleContext context) {

Will the fix have more code if it will be implemented via SwingAccessor just to access that "private" method?

-------------

PR: https://git.openjdk.org/jdk/pull/11670


From serb at openjdk.org  Thu Dec 22 22:23:52 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 Dec 2022 22:23:52 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11 [v2]
In-Reply-To: <tyvPceH1cD44Cvhu0H9Nyh9fXjvVM6zRQY58eDGvhGc=.dcccbc38-d120-490e-9b4f-82177e604917@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
 <tyvPceH1cD44Cvhu0H9Nyh9fXjvVM6zRQY58eDGvhGc=.dcccbc38-d120-490e-9b4f-82177e604917@github.com>
Message-ID: <vhxMsdi8o_pMRRShVIXrVQEP0QOfYhuytb3eIFCIIpg=.592cc57a-b4ad-4564-b69b-fbfa6c385b83@github.com>

On Thu, 22 Dec 2022 18:15:07 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> ViewportOverlapping was failing intermittently on Windows (Win10 & 11). Added robot.setAutoWaitForIdle() to ViewportOverlapping and its base class (OverlappingTestBase) to stabilize the test.
>> 
>> Additionally added awt & swings tests to exclusiveAccess.dir in TEST.ROOT.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted TEST.ROOT changes

What was the reason for failure? Something was too fast or too slow?

-------------

PR: https://git.openjdk.org/jdk/pull/11747


From serb at openjdk.org  Thu Dec 22 22:25:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 Dec 2022 22:25:51 GMT
Subject: RFR: 8298645 JNI works with accessibleSelection on a wrong thread
 [v2]
In-Reply-To: <h5O1pwggmA5QGBoR5FGfpUnDCpbpWuVX2wiHnh1WEVg=.907269d9-0519-45a0-a44a-9fb6293c2e47@github.com>
References: <w3UAuIF1k3EhbKSCxEXQ_5g5S9mOaepbIf_x_PDpt9g=.694f5c75-8384-433c-9b65-75910f61be37@github.com>
 <h5O1pwggmA5QGBoR5FGfpUnDCpbpWuVX2wiHnh1WEVg=.907269d9-0519-45a0-a44a-9fb6293c2e47@github.com>
Message-ID: <qHiforJVcaYLNyz3Zb6bhxkiNX0M4Val7lonzm9X5Yc=.f6317588-a2f0-4b84-863c-8c5e9ae682f7@github.com>

On Wed, 14 Dec 2022 09:26:09 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> [ComboBoxAccessibility accessibilityValue] works with the accessibleSelection object directly, however the work should go through CAccessibility so that it is executed on the Event Dispatch thread.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A comment or javadoc should mention that this is called from native code, specifically pointing to ComboBoxAccessibility.m.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11653


From serb at openjdk.org  Thu Dec 22 22:26:50 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 Dec 2022 22:26:50 GMT
Subject: RFR: 8298643 JNI call of getAccessibleRowWithIndex and
 getAccessibleColumnWithIndex on a wrong thread
In-Reply-To: <Jjl2XjvF1YJgjDuDAAOrnHWvxVDYprv6ntpqguD0yHc=.3bb98d77-4d42-4cbc-95fe-2febd5e95d2e@github.com>
References: <Jjl2XjvF1YJgjDuDAAOrnHWvxVDYprv6ntpqguD0yHc=.3bb98d77-4d42-4cbc-95fe-2febd5e95d2e@github.com>
Message-ID: <3N66J7u_SBcFyXOTGBzrS5Fg4ihZn3FOE0RxxJl1I4E=.7c0d2af3-10e1-407d-a4c1-b16ecef222c3@github.com>

On Tue, 13 Dec 2022 13:30:45 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> [TableAccessibility accessibleRowWithIndex] and [TableAccessibility accessibleColumnWithIndex] defines the getAccessibleRowWithIndex and getAccessibleColumnWithIndex methods on the AccessibleContext instance of AccessibleJTable class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11649


From aivanov at openjdk.org  Thu Dec 22 22:27:48 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Dec 2022 22:27:48 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11 [v2]
In-Reply-To: <L4VQY6JayQjdN-Avnc_FCMNpubkEZzgc6LUhgzZKAQI=.1276219a-1abe-4cec-aa77-24762f55b529@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
 <m3z28VJnQEMM38GGtwCj_AQsiHZr62IBBHKGg-cnL7s=.14543ee8-4371-4f79-a2ec-a238ea708c19@github.com>
 <lmAhQF7EiYZIrlh96_1ok58GPeak2LWG3afAfP4XolQ=.c07eaf59-0849-42b5-b25d-ff32eb2c5547@github.com>
 <W_HEgUOBCsJbzgbVW_WNWLgfgOAyqVI05WNAzeQYIrg=.ea10afc2-3854-4ad8-9ebe-fbd00fec52ce@github.com>
 <L4VQY6JayQjdN-Avnc_FCMNpubkEZzgc6LUhgzZKAQI=.1276219a-1abe-4cec-aa77-24762f55b529@github.com>
Message-ID: <gfUtTprBhBIUtGTwS7jdOOUWBLLw_NHrT5u66fOpno0=.d0f351d0-81d2-453c-9ad2-d994ff16b86f@github.com>

On Wed, 21 Dec 2022 21:48:24 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> *Headful* tests are not supposed concurrently: they display UI and often use Robot to send input events to the UI. Running such tests concurrently leads to obscure failures. In our CI system, `JTREG_JOBS=1` is passed to `make` when running headful tests.
>> 
>> There's a set of *headless* tests which can be run concurrently. Such tests will be affected if they're run concurrently.
>
> @aivanov-jdk If it affects the run time of certain group of tests then it is better not to add it to `exclusiveAccess.dirs` and explicitly specify the `JTREG_JOBS=1` instead as both produce same results?

As discussed, *headless* suite is affected. Therefore neither `java/awt` nor `javax/swing` should be added to `exclusiveAccess.dirs`.

-------------

PR: https://git.openjdk.org/jdk/pull/11747


From serb at openjdk.org  Thu Dec 22 22:31:49 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 Dec 2022 22:31:49 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v2]
In-Reply-To: <_KNiQ96NyPHL7dQDcea1f2YhIHNqfv3a4ZNJKTmAEik=.c7d97d75-09f7-4c8c-b433-5a030b12205c@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <_KNiQ96NyPHL7dQDcea1f2YhIHNqfv3a4ZNJKTmAEik=.c7d97d75-09f7-4c8c-b433-5a030b12205c@github.com>
Message-ID: <Ql4IvmLxz59m7DnVJHBloyZLD6C9bMG0ydxAneZSiMY=.f202e219-0885-4c9f-9ecb-9380e0440b8a@github.com>

On Wed, 14 Dec 2022 03:50:54 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
>> says:
>> "...MetalLookAndFeel registers an entry for each of the classes
>> in the package javax.swing.plaf.metal that are named MetalXXXUI.
>> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
>> that do not have a class in metal, the corresponding class in
>> javax.swing.plaf.basic is used. For example, metal does not
>> have a class named "MetalColorChooserUI", as such,
>> javax.swing.plaf.basic.BasicColorChooserUI is used".
>> 
>> There is class MetalMenuBarUI, but the method populates given defaults table with the value
>> "javax.swing.plaf.basic.BasicMenuBarUI".
>> 
>> Added entry for MetalMenuBarUI..
>> CI tests including JCK tests are ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Spec update
>  - Spec update

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java line 255:

> 253:      * "MetalColorChooserUI"}, as such, {@code
> 254:      * javax.swing.plaf.basic.BasicColorChooserUI} is used.
> 255:      * Also, class {@code MetalMenuBarUI} is used only for {@code OceanTheme}

Maybe we can make it more generic, like some classes could be used only by some themes and registered only if that theme is "active", for example {@code MetalMenuBarUI} .... etc

-------------

PR: https://git.openjdk.org/jdk/pull/11646


From tnakamura at openjdk.org  Fri Dec 23 06:33:25 2022
From: tnakamura at openjdk.org (Toshio Nakamura)
Date: Fri, 23 Dec 2022 06:33:25 GMT
Subject: RFR: 8299255: Unexpected round errors in FreetypeFontScaler [v2]
In-Reply-To: <94vFT5CtKVy47qA2LgpWnBbbkVeIR09KumB7YAhcBBI=.72e88bba-cd2e-458e-a37b-74782af36185@github.com>
References: <94vFT5CtKVy47qA2LgpWnBbbkVeIR09KumB7YAhcBBI=.72e88bba-cd2e-458e-a37b-74782af36185@github.com>
Message-ID: <x7AXU3E9a9hh5U8TI2EYGgzbJ80lrxIFO5tUXa_um80=.f1108c89-fd04-477d-be55-553203b2aa9b@github.com>

> In 'Java_sun_font_FreetypeFontScaler_createScalerContextNative', 'context->transform.xx' and '.yy' values are sometimes 65535 instead of 65536. There are unintentional double and float conversions. It may be no real harm, but I'd like to fix it.
> 
> Problem case:
> context->transform.xx=**65535** yx=0 xy=0 yy=**65535** ptsz=46.590909 dmat[0]=46.590909 (float)dmat[0]=46.59090**8**
> 
> Normal case:
> context->transform.xx=65536 yx=0 xy=0 yy=65536 ptsz=18.000000 dmat[0]=18.000000 (float)dmat[0]=18.000000
> 
> Test: jdk_desktop on Linux x86_64 had no regression issues.

Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:

  Adding a testcase

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11763/files
  - new: https://git.openjdk.org/jdk/pull/11763/files/09ed05de..6a64ad71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11763&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11763&range=00-01

  Stats: 69 lines in 1 file changed: 69 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11763.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11763/head:pull/11763

PR: https://git.openjdk.org/jdk/pull/11763


From serb at openjdk.org  Fri Dec 23 07:28:48 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 23 Dec 2022 07:28:48 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows [v2]
In-Reply-To: <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
 <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
Message-ID: <Ezizi4qkPSP1YD7FxhR5ckaSofmvUhZAZ0LAv_RD5FI=.96a1c233-ad99-42fe-a421-8c1f3cbd1517@github.com>

On Thu, 22 Dec 2022 10:57:15 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> **Environment**: 
>> GraalVM 22.3.0 with  jdk 19, Windows OS.
>> 
>> **Description**:
>> Create a native image of Swing application using GraalVM and run it with ` -Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> `java.lang.Error: java.home property not set` error is thrown.
>> 
>> For more details see https://github.com/oracle/graal/issues/4875.
>> 
>> **Solution**:
>> The error is thrown by the code from [FontConfiguration.findFontConfigFile()](https://github.com/openjdk/jdk19u/blob/c9d485792b99233f381dcdfd69838e7b973909bd/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L175) method.
>> GraalVM does not set `java.home`  property, that is why the `java.lang.Error: java.home property not set` is thrown.
>> `FontConfiguration.findFontConfigFile()` method compares `java.home` property to null before checking user provided `sun.awt.fontconfig` java property.
>> 
>> The proposed fix swaps the order of `java.home` and `sun.awt.fontconfig` properties checking to avoid using `java.home` property in case `sun.awt.fontconfig` is set.
>> 
>> 
>> **Steps to reproduce**:
>> - Download graal 22.3.0 jdk 19 for Windows from [GraalVM Community Edition 22.3.0](https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0) page.
>> - Install native-image
>> 
>> graalvm-ce-java19-22.3.0\bin\gu.cmd install native-image
>> 
>> - Create and compile `SwingSample.java` sample
>> 
>> import java.awt.*;
>> import javax.swing.*;
>> 
>> public class SwingSample {
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeAndWait(() -> {
>> 
>>             JFrame frame = new JFrame("Hello World");
>> 
>>             JButton button = new JButton("Hello");
>>             button.addActionListener(e -> {
>>                 System.out.printf("Hello, World!%n");
>>             });
>> 
>>             JPanel panel = new JPanel(new FlowLayout());
>>             panel.add(button);
>> 
>>             frame.add(panel);
>>             frame.setSize(400, 300);
>>             frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>             frame.setVisible(true);
>>         });
>>     }
>> }
>> 
>> - Run native-image-agent to generate configuration files
>> 
>> graalvm-ce-java19-22.3.0\bin\java.cmd -agentlib:native-image-agent=config-output-dir=conf-dir SwingSample
>> 
>> - Copy `graalvm-ce-java19-22.3.0\lib\fontconfig.properties.src` file to the sample dir
>> - Generate native image with configuration files and `-Djava.awt.headless=false `, `-Dsun.awt.fontconfig=fontconfig.properties.src` java properties
>> 
>> call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64"
>> graalvm-ce-java19-22.3.0\bin\native-image.cmd --no-fallback -Djava.awt.headless=false -Dsun.awt.fontconfig=fontconfig.properties.src -H:ResourceConfigurationFiles=conf-dir/resource-config.json -H:SerializationConfigurationFiles=conf-dir/serialization-config.json -H:ReflectionConfigurationFiles=conf-dir/reflect-config.json -H:JNIConfigurationFiles=conf-dir/jni-config.json SwingSample
>> 
>> - Run the native image with `-Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> 
>> swingsample.exe  -Dsun.awt.fontconfig=fontconfig.properties.src
>> 
>> Exception in thread "main" java.lang.reflect.InvocationTargetException
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371)
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346)
>>         at java.desktop at 19.0.1/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480)
>>         at SwingSample.main(SwingSample.java:7)
>> Caused by: java.lang.Error: java.home property not set
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
>>         at java.desktop at 19.0.1/sun.awt.windows.WFontConfiguration.<init>(WFontConfiguration.java:41)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize javaLib when a user fontconfig file is set

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11559


From asemenov at openjdk.org  Fri Dec 23 09:11:59 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 23 Dec 2022 09:11:59 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v2]
In-Reply-To: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
Message-ID: <m-T828PLerwE4TjNg5IB5UQ1VftG3A0JrBY-LCa-S9w=.8773bfed-17db-41ca-9644-b388a51ec40b@github.com>

> [OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  Please split the long lines to have 80 chars per line.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11670/files
  - new: https://git.openjdk.org/jdk/pull/11670/files/256a2d2e..8bad4ba2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11670&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11670&range=00-01

  Stats: 14 lines in 3 files changed: 2 ins; 11 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11670.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11670/head:pull/11670

PR: https://git.openjdk.org/jdk/pull/11670


From asemenov at openjdk.org  Fri Dec 23 09:18:50 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 23 Dec 2022 09:18:50 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v2]
In-Reply-To: <0x0ms0yarrHQrs6_AoYPZITOYxDHTyrHHgtfUzzaFKg=.687fa12c-eee3-4a89-9f36-1fa4792c7481@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
 <0x0ms0yarrHQrs6_AoYPZITOYxDHTyrHHgtfUzzaFKg=.687fa12c-eee3-4a89-9f36-1fa4792c7481@github.com>
Message-ID: <zBeQgfPEKgHQzBf1qvx2EZsODu08VtzxOyfCI70MKQs=.446bf052-8d33-482e-a661-c136f795c505@github.com>

On Thu, 22 Dec 2022 22:01:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Please split the long lines to have 80 chars per line.
>
> src/java.desktop/share/classes/javax/swing/JList.java line 3234:
> 
>> 3232:               static {
>> 3233:                   AccessibleComponentAccessor.addAccessor(c ->
>> 3234:                           c instanceof JList.AccessibleJList.AccessibleJListChild ? ((JList.AccessibleJList.AccessibleJListChild) c).getCurrentComponent() : null);
> 
> Please split the long lines to have 80 chars per line.

Donw

> src/java.desktop/share/classes/sun/swing/AccessibleComponentAccessor.java line 42:
> 
>> 40:     }
>> 41: 
>> 42:     public static Accessible getAccessible(AccessibleContext context) {
> 
> Will the fix have more code if it will be implemented via SwingAccessor just to access that "private" method?

Thank you.
I removed adding accesses for TableCell and ListChildren. If that's what you meant.
I would like to keep the implementation of the Accesser itself, if possible. Because in the future it may come in handy in this form, if in the future you still need to add access to the currentComponent for ListChildren and TableCell.
this approach allows us to make the implementation more generic, in case the potential tree is not inherited from Jtree. It also avoids reflection.

-------------

PR: https://git.openjdk.org/jdk/pull/11670


From tnakamura at openjdk.org  Fri Dec 23 09:19:48 2022
From: tnakamura at openjdk.org (Toshio Nakamura)
Date: Fri, 23 Dec 2022 09:19:48 GMT
Subject: RFR: 8299255: Unexpected round errors in FreetypeFontScaler
In-Reply-To: <R_D87TZaDD4LOtCmlCTTwUuIxdZBNDMRbKR3xD59zKg=.a1821376-a375-4084-b092-4688d469ddf2@github.com>
References: <94vFT5CtKVy47qA2LgpWnBbbkVeIR09KumB7YAhcBBI=.72e88bba-cd2e-458e-a37b-74782af36185@github.com>
 <R_D87TZaDD4LOtCmlCTTwUuIxdZBNDMRbKR3xD59zKg=.a1821376-a375-4084-b092-4688d469ddf2@github.com>
Message-ID: <sjeWEen8J37OxlkCu69ssq3fI8LBRokvFN1x54H7ojU=.f64797b6-b9ac-4f80-9cb4-467955dd9cc3@github.com>

On Thu, 22 Dec 2022 21:52:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> In 'Java_sun_font_FreetypeFontScaler_createScalerContextNative', 'context->transform.xx' and '.yy' values are sometimes 65535 instead of 65536. There are unintentional double and float conversions. It may be no real harm, but I'd like to fix it.
>> 
>> Problem case:
>> context->transform.xx=**65535** yx=0 xy=0 yy=**65535** ptsz=46.590909 dmat[0]=46.590909 (float)dmat[0]=46.59090**8**
>> 
>> Normal case:
>> context->transform.xx=65536 yx=0 xy=0 yy=65536 ptsz=18.000000 dmat[0]=18.000000 (float)dmat[0]=18.000000
>> 
>> Test: jdk_desktop on Linux x86_64 had no regression issues.
>
> Is it possible to create a test case for this issue?

@mrserb Yes, I found the way to test this case. Please review this test case as well.

-------------

PR: https://git.openjdk.org/jdk/pull/11763


From jwilhelm at openjdk.org  Fri Dec 23 10:56:14 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 23 Dec 2022 10:56:14 GMT
Subject: RFR: Merge jdk20
Message-ID: <dcbxW50q2KMbb5q8mKS1UJ3Ihxpb8U-MSd2dt29r5R0=.65568df4-6705-4285-8cae-0e0043311df3@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8299237: add ArraysSupport.newLength test to a test group
 - 8299230: Use https: in links
 - 8299015: Ensure that HttpResponse.BodySubscribers.ofFile writes all bytes
 - 8299207: [Testbug] Add back test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java
 - 8298176: remove OpaqueZeroTripGuardPostLoop once main-loop disappears
 - 8299077: [REDO] JDK-4512626 Non-editable JTextArea provides no visual indication of keyboard focus

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11773&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11773&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11773/files
  Stats: 572 lines in 15 files changed: 407 ins; 76 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/11773.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11773/head:pull/11773

PR: https://git.openjdk.org/jdk/pull/11773


From jwilhelm at openjdk.org  Fri Dec 23 11:28:55 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 23 Dec 2022 11:28:55 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <dcbxW50q2KMbb5q8mKS1UJ3Ihxpb8U-MSd2dt29r5R0=.65568df4-6705-4285-8cae-0e0043311df3@github.com>
References: <dcbxW50q2KMbb5q8mKS1UJ3Ihxpb8U-MSd2dt29r5R0=.65568df4-6705-4285-8cae-0e0043311df3@github.com>
Message-ID: <Qpqs-x1BDsAeBRIOYkSaGMve-66Gv1MsBzE83e5C_Nc=.b629f16d-7df6-482d-bcc0-d9d8a27380fd@github.com>

On Fri, 23 Dec 2022 10:48:19 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 19ce23c6
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19ce23c6459a452c8d3856b9ed96bfa54a8346ae
Stats:     572 lines in 15 files changed: 407 ins; 76 del; 89 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/11773


From prr at openjdk.org  Fri Dec 23 18:07:51 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 23 Dec 2022 18:07:51 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows [v2]
In-Reply-To: <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
 <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
Message-ID: <oM_eWG7v30ibYo3rEb25DIVId14tNMAjwPHhV-uuZaM=.7087335a-3794-4cbb-ba11-3daf492c667d@github.com>

On Thu, 22 Dec 2022 10:57:15 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> **Environment**: 
>> GraalVM 22.3.0 with  jdk 19, Windows OS.
>> 
>> **Description**:
>> Create a native image of Swing application using GraalVM and run it with ` -Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> `java.lang.Error: java.home property not set` error is thrown.
>> 
>> For more details see https://github.com/oracle/graal/issues/4875.
>> 
>> **Solution**:
>> The error is thrown by the code from [FontConfiguration.findFontConfigFile()](https://github.com/openjdk/jdk19u/blob/c9d485792b99233f381dcdfd69838e7b973909bd/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L175) method.
>> GraalVM does not set `java.home`  property, that is why the `java.lang.Error: java.home property not set` is thrown.
>> `FontConfiguration.findFontConfigFile()` method compares `java.home` property to null before checking user provided `sun.awt.fontconfig` java property.
>> 
>> The proposed fix swaps the order of `java.home` and `sun.awt.fontconfig` properties checking to avoid using `java.home` property in case `sun.awt.fontconfig` is set.
>> 
>> 
>> **Steps to reproduce**:
>> - Download graal 22.3.0 jdk 19 for Windows from [GraalVM Community Edition 22.3.0](https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0) page.
>> - Install native-image
>> 
>> graalvm-ce-java19-22.3.0\bin\gu.cmd install native-image
>> 
>> - Create and compile `SwingSample.java` sample
>> 
>> import java.awt.*;
>> import javax.swing.*;
>> 
>> public class SwingSample {
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeAndWait(() -> {
>> 
>>             JFrame frame = new JFrame("Hello World");
>> 
>>             JButton button = new JButton("Hello");
>>             button.addActionListener(e -> {
>>                 System.out.printf("Hello, World!%n");
>>             });
>> 
>>             JPanel panel = new JPanel(new FlowLayout());
>>             panel.add(button);
>> 
>>             frame.add(panel);
>>             frame.setSize(400, 300);
>>             frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>             frame.setVisible(true);
>>         });
>>     }
>> }
>> 
>> - Run native-image-agent to generate configuration files
>> 
>> graalvm-ce-java19-22.3.0\bin\java.cmd -agentlib:native-image-agent=config-output-dir=conf-dir SwingSample
>> 
>> - Copy `graalvm-ce-java19-22.3.0\lib\fontconfig.properties.src` file to the sample dir
>> - Generate native image with configuration files and `-Djava.awt.headless=false `, `-Dsun.awt.fontconfig=fontconfig.properties.src` java properties
>> 
>> call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64"
>> graalvm-ce-java19-22.3.0\bin\native-image.cmd --no-fallback -Djava.awt.headless=false -Dsun.awt.fontconfig=fontconfig.properties.src -H:ResourceConfigurationFiles=conf-dir/resource-config.json -H:SerializationConfigurationFiles=conf-dir/serialization-config.json -H:ReflectionConfigurationFiles=conf-dir/reflect-config.json -H:JNIConfigurationFiles=conf-dir/jni-config.json SwingSample
>> 
>> - Run the native image with `-Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> 
>> swingsample.exe  -Dsun.awt.fontconfig=fontconfig.properties.src
>> 
>> Exception in thread "main" java.lang.reflect.InvocationTargetException
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371)
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346)
>>         at java.desktop at 19.0.1/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480)
>>         at SwingSample.main(SwingSample.java:7)
>> Caused by: java.lang.Error: java.home property not set
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
>>         at java.desktop at 19.0.1/sun.awt.windows.WFontConfiguration.<init>(WFontConfiguration.java:41)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize javaLib when a user fontconfig file is set

Why is it not set ? That seems wrong.

-------------

PR: https://git.openjdk.org/jdk/pull/11559


From prr at openjdk.org  Fri Dec 23 18:15:51 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 23 Dec 2022 18:15:51 GMT
Subject: RFR: 8299255: Unexpected round errors in FreetypeFontScaler [v2]
In-Reply-To: <x7AXU3E9a9hh5U8TI2EYGgzbJ80lrxIFO5tUXa_um80=.f1108c89-fd04-477d-be55-553203b2aa9b@github.com>
References: <94vFT5CtKVy47qA2LgpWnBbbkVeIR09KumB7YAhcBBI=.72e88bba-cd2e-458e-a37b-74782af36185@github.com>
 <x7AXU3E9a9hh5U8TI2EYGgzbJ80lrxIFO5tUXa_um80=.f1108c89-fd04-477d-be55-553203b2aa9b@github.com>
Message-ID: <Z-aYIRqVISNPbNjq5CyR6kSwGArvogGxDamGCVR2jJU=.d4baed9e-6f2a-43bb-8552-53d368866dba@github.com>

On Fri, 23 Dec 2022 06:33:25 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> In 'Java_sun_font_FreetypeFontScaler_createScalerContextNative', 'context->transform.xx' and '.yy' values are sometimes 65535 instead of 65536. There are unintentional double and float conversions. It may be no real harm, but I'd like to fix it.
>> 
>> Problem case:
>> context->transform.xx=**65535** yx=0 xy=0 yy=**65535** ptsz=46.590909 dmat[0]=46.590909 (float)dmat[0]=46.59090**8**
>> 
>> Normal case:
>> context->transform.xx=65536 yx=0 xy=0 yy=65536 ptsz=18.000000 dmat[0]=18.000000 (float)dmat[0]=18.000000
>> 
>> Test: jdk_desktop on Linux x86_64 had no regression issues.
>
> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a testcase

This seems reasonable. My only concern is that you make sure this test passes on all platforms.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11763


From prr at openjdk.org  Fri Dec 23 18:33:00 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 23 Dec 2022 18:33:00 GMT
Subject: [jdk20] RFR: 8299227: host `exif.org` not found in link in doc
 comment [v2]
In-Reply-To: <CkBcNmCs96sP6ou8iSrMzqKa06tGQXkln-PNeDC1WOw=.360d4fb6-8b23-409d-8892-349fda6b806d@github.com>
References: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
 <CkBcNmCs96sP6ou8iSrMzqKa06tGQXkln-PNeDC1WOw=.360d4fb6-8b23-409d-8892-349fda6b806d@github.com>
Message-ID: <0LINf1R5FoZStKMSlimveknC42QeZDxLIsNPYaFDXjA=.c08df247-13eb-4c2f-bdf3-b46bb61ca891@github.com>

On Thu, 22 Dec 2022 21:52:43 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Reported broken links are updated accordingly.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Link re-fix

src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html line 578:

> 576: <td>Exif-specific JPEG compression (see note following this table)</td>
> 577: <td><a href="https://www.kodak.com/global/plugins/acrobat/en/service/digCam/exifStandard2.pdf">
> 578:     Exif 2.2 Specification</a>

This doesn't seem like a very authorative URL.
It looks quite unstable and could be gone at the whim of whoever maintains that website describing their acrobat plugins ..

-------------

PR: https://git.openjdk.org/jdk20/pull/74


From alexsch at openjdk.org  Fri Dec 23 18:44:48 2022
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Fri, 23 Dec 2022 18:44:48 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows [v2]
In-Reply-To: <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
 <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
Message-ID: <0drTNu5bqEPbWvEkOFp3D757HuW0VzBfUXk6By_RgVk=.d29731eb-f266-439c-85ac-bde0468cc920@github.com>

On Thu, 22 Dec 2022 10:57:15 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> **Environment**: 
>> GraalVM 22.3.0 with  jdk 19, Windows OS.
>> 
>> **Description**:
>> Create a native image of Swing application using GraalVM and run it with ` -Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> `java.lang.Error: java.home property not set` error is thrown.
>> 
>> For more details see https://github.com/oracle/graal/issues/4875.
>> 
>> **Solution**:
>> The error is thrown by the code from [FontConfiguration.findFontConfigFile()](https://github.com/openjdk/jdk19u/blob/c9d485792b99233f381dcdfd69838e7b973909bd/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L175) method.
>> GraalVM does not set `java.home`  property, that is why the `java.lang.Error: java.home property not set` is thrown.
>> `FontConfiguration.findFontConfigFile()` method compares `java.home` property to null before checking user provided `sun.awt.fontconfig` java property.
>> 
>> The proposed fix swaps the order of `java.home` and `sun.awt.fontconfig` properties checking to avoid using `java.home` property in case `sun.awt.fontconfig` is set.
>> 
>> 
>> **Steps to reproduce**:
>> - Download graal 22.3.0 jdk 19 for Windows from [GraalVM Community Edition 22.3.0](https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0) page.
>> - Install native-image
>> 
>> graalvm-ce-java19-22.3.0\bin\gu.cmd install native-image
>> 
>> - Create and compile `SwingSample.java` sample
>> 
>> import java.awt.*;
>> import javax.swing.*;
>> 
>> public class SwingSample {
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeAndWait(() -> {
>> 
>>             JFrame frame = new JFrame("Hello World");
>> 
>>             JButton button = new JButton("Hello");
>>             button.addActionListener(e -> {
>>                 System.out.printf("Hello, World!%n");
>>             });
>> 
>>             JPanel panel = new JPanel(new FlowLayout());
>>             panel.add(button);
>> 
>>             frame.add(panel);
>>             frame.setSize(400, 300);
>>             frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>             frame.setVisible(true);
>>         });
>>     }
>> }
>> 
>> - Run native-image-agent to generate configuration files
>> 
>> graalvm-ce-java19-22.3.0\bin\java.cmd -agentlib:native-image-agent=config-output-dir=conf-dir SwingSample
>> 
>> - Copy `graalvm-ce-java19-22.3.0\lib\fontconfig.properties.src` file to the sample dir
>> - Generate native image with configuration files and `-Djava.awt.headless=false `, `-Dsun.awt.fontconfig=fontconfig.properties.src` java properties
>> 
>> call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64"
>> graalvm-ce-java19-22.3.0\bin\native-image.cmd --no-fallback -Djava.awt.headless=false -Dsun.awt.fontconfig=fontconfig.properties.src -H:ResourceConfigurationFiles=conf-dir/resource-config.json -H:SerializationConfigurationFiles=conf-dir/serialization-config.json -H:ReflectionConfigurationFiles=conf-dir/reflect-config.json -H:JNIConfigurationFiles=conf-dir/jni-config.json SwingSample
>> 
>> - Run the native image with `-Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> 
>> swingsample.exe  -Dsun.awt.fontconfig=fontconfig.properties.src
>> 
>> Exception in thread "main" java.lang.reflect.InvocationTargetException
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371)
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346)
>>         at java.desktop at 19.0.1/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480)
>>         at SwingSample.main(SwingSample.java:7)
>> Caused by: java.lang.Error: java.home property not set
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
>>         at java.desktop at 19.0.1/sun.awt.windows.WFontConfiguration.<init>(WFontConfiguration.java:41)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize javaLib when a user fontconfig file is set

There is the `Java system properties are inconsistent between traditional JDK and native image` issue in Graal: https://github.com/oracle/graal/issues/2835

With comment: https://github.com/oracle/graal/issues/2835#issuecomment-1333300103
> We are still not setting the `java.home` system property at image run time by default, and do not plan to change that. Because there is just no "JDK home directory" around at image run time, so setting `java.home` to, for example, the directory where the native image is located in is misleading - files that might be expected to be in that directory are not there.

-------------

PR: https://git.openjdk.org/jdk/pull/11559


From prr at openjdk.org  Fri Dec 23 18:56:50 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 23 Dec 2022 18:56:50 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows [v2]
In-Reply-To: <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
 <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
Message-ID: <mvXSvvyeb26OFmDaSzl7Ob8aP2PZjwr8_bW1ojzG9ak=.2c1e58bd-b184-485c-8bc1-f6fb47216b22@github.com>

On Thu, 22 Dec 2022 10:57:15 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> **Environment**: 
>> GraalVM 22.3.0 with  jdk 19, Windows OS.
>> 
>> **Description**:
>> Create a native image of Swing application using GraalVM and run it with ` -Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> `java.lang.Error: java.home property not set` error is thrown.
>> 
>> For more details see https://github.com/oracle/graal/issues/4875.
>> 
>> **Solution**:
>> The error is thrown by the code from [FontConfiguration.findFontConfigFile()](https://github.com/openjdk/jdk19u/blob/c9d485792b99233f381dcdfd69838e7b973909bd/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L175) method.
>> GraalVM does not set `java.home`  property, that is why the `java.lang.Error: java.home property not set` is thrown.
>> `FontConfiguration.findFontConfigFile()` method compares `java.home` property to null before checking user provided `sun.awt.fontconfig` java property.
>> 
>> The proposed fix swaps the order of `java.home` and `sun.awt.fontconfig` properties checking to avoid using `java.home` property in case `sun.awt.fontconfig` is set.
>> 
>> 
>> **Steps to reproduce**:
>> - Download graal 22.3.0 jdk 19 for Windows from [GraalVM Community Edition 22.3.0](https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0) page.
>> - Install native-image
>> 
>> graalvm-ce-java19-22.3.0\bin\gu.cmd install native-image
>> 
>> - Create and compile `SwingSample.java` sample
>> 
>> import java.awt.*;
>> import javax.swing.*;
>> 
>> public class SwingSample {
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeAndWait(() -> {
>> 
>>             JFrame frame = new JFrame("Hello World");
>> 
>>             JButton button = new JButton("Hello");
>>             button.addActionListener(e -> {
>>                 System.out.printf("Hello, World!%n");
>>             });
>> 
>>             JPanel panel = new JPanel(new FlowLayout());
>>             panel.add(button);
>> 
>>             frame.add(panel);
>>             frame.setSize(400, 300);
>>             frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>             frame.setVisible(true);
>>         });
>>     }
>> }
>> 
>> - Run native-image-agent to generate configuration files
>> 
>> graalvm-ce-java19-22.3.0\bin\java.cmd -agentlib:native-image-agent=config-output-dir=conf-dir SwingSample
>> 
>> - Copy `graalvm-ce-java19-22.3.0\lib\fontconfig.properties.src` file to the sample dir
>> - Generate native image with configuration files and `-Djava.awt.headless=false `, `-Dsun.awt.fontconfig=fontconfig.properties.src` java properties
>> 
>> call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64"
>> graalvm-ce-java19-22.3.0\bin\native-image.cmd --no-fallback -Djava.awt.headless=false -Dsun.awt.fontconfig=fontconfig.properties.src -H:ResourceConfigurationFiles=conf-dir/resource-config.json -H:SerializationConfigurationFiles=conf-dir/serialization-config.json -H:ReflectionConfigurationFiles=conf-dir/reflect-config.json -H:JNIConfigurationFiles=conf-dir/jni-config.json SwingSample
>> 
>> - Run the native image with `-Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> 
>> swingsample.exe  -Dsun.awt.fontconfig=fontconfig.properties.src
>> 
>> Exception in thread "main" java.lang.reflect.InvocationTargetException
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371)
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346)
>>         at java.desktop at 19.0.1/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480)
>>         at SwingSample.main(SwingSample.java:7)
>> Caused by: java.lang.Error: java.home property not set
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
>>         at java.desktop at 19.0.1/sun.awt.windows.WFontConfiguration.<init>(WFontConfiguration.java:41)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize javaLib when a user fontconfig file is set

> There is the `Java system properties are inconsistent between traditional JDK and native image` issue in Graal: [oracle/graal#2835](https://github.com/oracle/graal/issues/2835)
> 
> With comment: [oracle/graal#2835 (comment)](https://github.com/oracle/graal/issues/2835#issuecomment-1333300103)
> 
> > We are still not setting the `java.home` system property at image run time by default, and do not plan to change that. Because there is just no "JDK home directory" around at image run time, so setting `java.home` to, for example, the directory where the native image is located in is misleading - files that might be expected to be in that directory are not there.

Surely that's graal's problem to solve.
This is a standard system property, it is an error if it is not set correctly.
Also sun.awt.config is not a supported documented property. It was put there for debugging. 
If user code is relying on that (I'm not sure if that is being implied) then it is on shaky ground.
We could remove that at any time without notice.

-------------

PR: https://git.openjdk.org/jdk/pull/11559


From abhiscxk at openjdk.org  Fri Dec 23 19:11:59 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 23 Dec 2022 19:11:59 GMT
Subject: [jdk20] RFR: 8299227: host `exif.org` not found in link in doc
 comment [v2]
In-Reply-To: <0LINf1R5FoZStKMSlimveknC42QeZDxLIsNPYaFDXjA=.c08df247-13eb-4c2f-bdf3-b46bb61ca891@github.com>
References: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
 <CkBcNmCs96sP6ou8iSrMzqKa06tGQXkln-PNeDC1WOw=.360d4fb6-8b23-409d-8892-349fda6b806d@github.com>
 <0LINf1R5FoZStKMSlimveknC42QeZDxLIsNPYaFDXjA=.c08df247-13eb-4c2f-bdf3-b46bb61ca891@github.com>
Message-ID: <GAsu9kNA_vxUcRuE_SXMaH8GC2LvallS_qnzCncal5k=.5c2c2765-b06c-4eb5-beaf-c2a1e6d6dbbc@github.com>

On Fri, 23 Dec 2022 18:30:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Link re-fix
>
> src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html line 578:
> 
>> 576: <td>Exif-specific JPEG compression (see note following this table)</td>
>> 577: <td><a href="https://www.kodak.com/global/plugins/acrobat/en/service/digCam/exifStandard2.pdf">
>> 578:     Exif 2.2 Specification</a>
> 
> This doesn't seem like a very authorative URL.
> It looks quite unstable and could be gone at the whim of whoever maintains that website describing their acrobat plugins ..

I found another link `http://web.archive.org/web/20131018091152/http://exif.org/Exif2-2.PDF` for spec version 2.2 which is a web archive but the connection is not secure.

Is it ok to have `https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf` link and update the Spec version to 2.3 ?

What do you suggest?

-------------

PR: https://git.openjdk.org/jdk20/pull/74


From prr at openjdk.org  Fri Dec 23 19:28:00 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 23 Dec 2022 19:28:00 GMT
Subject: [jdk20] RFR: 8299227: host `exif.org` not found in link in doc
 comment [v2]
In-Reply-To: <GAsu9kNA_vxUcRuE_SXMaH8GC2LvallS_qnzCncal5k=.5c2c2765-b06c-4eb5-beaf-c2a1e6d6dbbc@github.com>
References: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
 <CkBcNmCs96sP6ou8iSrMzqKa06tGQXkln-PNeDC1WOw=.360d4fb6-8b23-409d-8892-349fda6b806d@github.com>
 <0LINf1R5FoZStKMSlimveknC42QeZDxLIsNPYaFDXjA=.c08df247-13eb-4c2f-bdf3-b46bb61ca891@github.com>
 <GAsu9kNA_vxUcRuE_SXMaH8GC2LvallS_qnzCncal5k=.5c2c2765-b06c-4eb5-beaf-c2a1e6d6dbbc@github.com>
Message-ID: <jajjPkrDk6xVnowdBFlrh3w5tKAGqjrtnNqDdWwYiis=.4e1ed866-8b70-41cc-9b49-4d7b3a8dfb67@github.com>

On Fri, 23 Dec 2022 19:09:05 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html line 578:
>> 
>>> 576: <td>Exif-specific JPEG compression (see note following this table)</td>
>>> 577: <td><a href="https://www.kodak.com/global/plugins/acrobat/en/service/digCam/exifStandard2.pdf">
>>> 578:     Exif 2.2 Specification</a>
>> 
>> This doesn't seem like a very authorative URL.
>> It looks quite unstable and could be gone at the whim of whoever maintains that website describing their acrobat plugins ..
>
> I found another link `http://web.archive.org/web/20131018091152/http://exif.org/Exif2-2.PDF` for spec version 2.2 which is a web archive but the connection is not secure.
> 
> Is it ok to have `https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf` link and update the Spec version to 2.3 ?
> 
> What do you suggest?

I found the webarchive myself yesterday, I did not think it a suitable link for JDK.
Since you haven't found a suitable link for 2.2, I think an update to 2.3 is best mainly because it seems a better place to link to.

-------------

PR: https://git.openjdk.org/jdk20/pull/74


From abhiscxk at openjdk.org  Fri Dec 23 19:48:02 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 23 Dec 2022 19:48:02 GMT
Subject: [jdk20] RFR: 8299227: host `exif.org` not found in link in doc
 comment [v3]
In-Reply-To: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
References: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
Message-ID: <CSY2Hm3PVq5HPG8BrA2Hsr3YHG0jnfbycbp4mSdbr7A=.5f944f1b-dc09-43c5-9220-9e5e33a3534d@github.com>

> Reported broken links are updated accordingly.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Links and spec version update

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/74/files
  - new: https://git.openjdk.org/jdk20/pull/74/files/e5e3b929..414e129e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=74&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=74&range=01-02

  Stats: 11 lines in 3 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk20/pull/74.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/74/head:pull/74

PR: https://git.openjdk.org/jdk20/pull/74


From abhiscxk at openjdk.org  Fri Dec 23 19:48:03 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 23 Dec 2022 19:48:03 GMT
Subject: [jdk20] RFR: 8299227: host `exif.org` not found in link in doc
 comment [v2]
In-Reply-To: <jajjPkrDk6xVnowdBFlrh3w5tKAGqjrtnNqDdWwYiis=.4e1ed866-8b70-41cc-9b49-4d7b3a8dfb67@github.com>
References: <0HObTOqFR7yjan7tc7sHZCNzgoCISxAfHz0B5CgsquM=.3cefd1be-9046-443e-8399-320fed1604af@github.com>
 <CkBcNmCs96sP6ou8iSrMzqKa06tGQXkln-PNeDC1WOw=.360d4fb6-8b23-409d-8892-349fda6b806d@github.com>
 <0LINf1R5FoZStKMSlimveknC42QeZDxLIsNPYaFDXjA=.c08df247-13eb-4c2f-bdf3-b46bb61ca891@github.com>
 <GAsu9kNA_vxUcRuE_SXMaH8GC2LvallS_qnzCncal5k=.5c2c2765-b06c-4eb5-beaf-c2a1e6d6dbbc@github.com>
 <jajjPkrDk6xVnowdBFlrh3w5tKAGqjrtnNqDdWwYiis=.4e1ed866-8b70-41cc-9b49-4d7b3a8dfb67@github.com>
Message-ID: <NRHvZpQ3Gp9yKf_1a8dNiSad35wV5KWtvzroRJaEC1Y=.cfbeea84-3d6c-40a8-971b-82b41ef84d6a@github.com>

On Fri, 23 Dec 2022 19:24:55 GMT, Phil Race <prr at openjdk.org> wrote:

>> I found another link `http://web.archive.org/web/20131018091152/http://exif.org/Exif2-2.PDF` for spec version 2.2 which is a web archive but the connection is not secure.
>> 
>> Is it ok to have `https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf` link and update the Spec version to 2.3 ?
>> 
>> What do you suggest?
>
> I found the webarchive myself yesterday, I did not think it a suitable link for JDK.
> Since you haven't found a suitable link for 2.2, I think an update to 2.3 is best mainly because it seems a better place to link to.

Updated to version 2.3.

-------------

PR: https://git.openjdk.org/jdk20/pull/74


From kizune at openjdk.org  Fri Dec 23 22:00:48 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 23 Dec 2022 22:00:48 GMT
Subject: RFR: 8298643 JNI call of getAccessibleRowWithIndex and
 getAccessibleColumnWithIndex on a wrong thread
In-Reply-To: <Jjl2XjvF1YJgjDuDAAOrnHWvxVDYprv6ntpqguD0yHc=.3bb98d77-4d42-4cbc-95fe-2febd5e95d2e@github.com>
References: <Jjl2XjvF1YJgjDuDAAOrnHWvxVDYprv6ntpqguD0yHc=.3bb98d77-4d42-4cbc-95fe-2febd5e95d2e@github.com>
Message-ID: <4MhKJiT-8PoVhj1M5vCBLDyQNFM8P57a6mwDgVxNqWE=.db25b3cc-3719-480a-8dec-ebd9211bbbaa@github.com>

On Tue, 13 Dec 2022 13:30:45 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> [TableAccessibility accessibleRowWithIndex] and [TableAccessibility accessibleColumnWithIndex] defines the getAccessibleRowWithIndex and getAccessibleColumnWithIndex methods on the AccessibleContext instance of AccessibleJTable class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11649


From kizune at openjdk.org  Fri Dec 23 22:02:49 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 23 Dec 2022 22:02:49 GMT
Subject: RFR: 8298645 JNI works with accessibleSelection on a wrong thread
 [v2]
In-Reply-To: <h5O1pwggmA5QGBoR5FGfpUnDCpbpWuVX2wiHnh1WEVg=.907269d9-0519-45a0-a44a-9fb6293c2e47@github.com>
References: <w3UAuIF1k3EhbKSCxEXQ_5g5S9mOaepbIf_x_PDpt9g=.694f5c75-8384-433c-9b65-75910f61be37@github.com>
 <h5O1pwggmA5QGBoR5FGfpUnDCpbpWuVX2wiHnh1WEVg=.907269d9-0519-45a0-a44a-9fb6293c2e47@github.com>
Message-ID: <5_4bi18sX2-jrqr8ibVj1OK5VGOZxn3H3UoncVenz48=.f0b9273c-2493-44e1-9d16-8b34ecdc5a68@github.com>

On Wed, 14 Dec 2022 09:26:09 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> [ComboBoxAccessibility accessibilityValue] works with the accessibleSelection object directly, however the work should go through CAccessibility so that it is executed on the Event Dispatch thread.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A comment or javadoc should mention that this is called from native code, specifically pointing to ComboBoxAccessibility.m.

Marked as reviewed by kizune (Reviewer).

Please update copyright years in both changed files. Other than that looks good.

-------------

PR: https://git.openjdk.org/jdk/pull/11653


From asemenov at openjdk.org  Fri Dec 23 22:10:55 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 23 Dec 2022 22:10:55 GMT
Subject: Integrated: 8298643 JNI call of getAccessibleRowWithIndex and
 getAccessibleColumnWithIndex on a wrong thread
In-Reply-To: <Jjl2XjvF1YJgjDuDAAOrnHWvxVDYprv6ntpqguD0yHc=.3bb98d77-4d42-4cbc-95fe-2febd5e95d2e@github.com>
References: <Jjl2XjvF1YJgjDuDAAOrnHWvxVDYprv6ntpqguD0yHc=.3bb98d77-4d42-4cbc-95fe-2febd5e95d2e@github.com>
Message-ID: <zm8CAu4gTjtCEHo6TvErdNH0eo7HGH_-wfXXt6D4UTQ=.88a7d28a-cb77-4609-9e25-6d6fc6079a81@github.com>

On Tue, 13 Dec 2022 13:30:45 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> [TableAccessibility accessibleRowWithIndex] and [TableAccessibility accessibleColumnWithIndex] defines the getAccessibleRowWithIndex and getAccessibleColumnWithIndex methods on the AccessibleContext instance of AccessibleJTable class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

This pull request has now been integrated.

Changeset: fd746a2f
Author:    Artem Semenov <asemenov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd746a2fe0e4c1c056065da93e2be2d8bb4e5428
Stats:     18 lines in 1 file changed: 0 ins; 8 del; 10 mod

8298643: JNI call of getAccessibleRowWithIndex and getAccessibleColumnWithIndex on a wrong thread

Reviewed-by: serb, kizune

-------------

PR: https://git.openjdk.org/jdk/pull/11649


From serb at openjdk.org  Fri Dec 23 22:11:54 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 23 Dec 2022 22:11:54 GMT
Subject: [jdk20] RFR: 8299207: [Testbug] Add back
 test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java
In-Reply-To: <TzP3yy7BByEkHUK3qRRpYLMU-iN45PmwBOpnzvmjp3w=.c1f389aa-33bc-4025-809b-596d1cd611fa@github.com>
References: <TzP3yy7BByEkHUK3qRRpYLMU-iN45PmwBOpnzvmjp3w=.c1f389aa-33bc-4025-809b-596d1cd611fa@github.com>
Message-ID: <JgsvE1aKzsEy5J0yfZGTVK_h4_d1IYobpw_z5ZPGtpk=.a49130ff-4f38-4d50-8c1c-ca9baf5f5562@github.com>

On Thu, 22 Dec 2022 05:39:54 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> - Regression test test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java was added as part of [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266). We had to revert [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) while fixing [JDK-8298217](https://bugs.openjdk.org/browse/JDK-8298217). 
> 
> - Although the [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266) fix is no more needed, this test is good and can be added back to detect future regressions.
> 
> - CI test run is green with this test addition.

Is it necessary to run it on macOS only? Can we cover other platforms as well?

-------------

PR: https://git.openjdk.org/jdk20/pull/72


From asemenov at openjdk.org  Fri Dec 23 22:24:58 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 23 Dec 2022 22:24:58 GMT
Subject: RFR: 8298645 JNI works with accessibleSelection on a wrong thread
 [v3]
In-Reply-To: <w3UAuIF1k3EhbKSCxEXQ_5g5S9mOaepbIf_x_PDpt9g=.694f5c75-8384-433c-9b65-75910f61be37@github.com>
References: <w3UAuIF1k3EhbKSCxEXQ_5g5S9mOaepbIf_x_PDpt9g=.694f5c75-8384-433c-9b65-75910f61be37@github.com>
Message-ID: <hLfCH6W6EzwTePcg4w4YeQAMAK4jQbf5uin7oHUe000=.65bce5a0-b602-474b-b60e-1235e9bc8a54@github.com>

> [ComboBoxAccessibility accessibilityValue] works with the accessibleSelection object directly, however the work should go through CAccessibility so that it is executed on the Event Dispatch thread.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  update copyrites

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11653/files
  - new: https://git.openjdk.org/jdk/pull/11653/files/38319bf7..02f9b760

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11653&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11653&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11653.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11653/head:pull/11653

PR: https://git.openjdk.org/jdk/pull/11653


From asemenov at openjdk.org  Fri Dec 23 22:31:52 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 23 Dec 2022 22:31:52 GMT
Subject: Integrated: 8298645 JNI works with accessibleSelection on a wrong
 thread
In-Reply-To: <w3UAuIF1k3EhbKSCxEXQ_5g5S9mOaepbIf_x_PDpt9g=.694f5c75-8384-433c-9b65-75910f61be37@github.com>
References: <w3UAuIF1k3EhbKSCxEXQ_5g5S9mOaepbIf_x_PDpt9g=.694f5c75-8384-433c-9b65-75910f61be37@github.com>
Message-ID: <q54HYC3MalWEN2MRl-Z7KyRFrj2b9dqX2BUA6GqT1LA=.51288453-7c62-46b9-90df-b4cf447ea9c7@github.com>

On Tue, 13 Dec 2022 15:59:53 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> [ComboBoxAccessibility accessibilityValue] works with the accessibleSelection object directly, however the work should go through CAccessibility so that it is executed on the Event Dispatch thread.

This pull request has now been integrated.

Changeset: 5e861e39
Author:    Artem Semenov <asemenov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e861e3965ce110889c8a1782ab0260937dee6ee
Stats:     56 lines in 2 files changed: 20 ins; 20 del; 16 mod

8298645: JNI works with accessibleSelection on a wrong thread

Reviewed-by: serb, kizune

-------------

PR: https://git.openjdk.org/jdk/pull/11653


From serb at openjdk.org  Fri Dec 23 22:33:02 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 23 Dec 2022 22:33:02 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus [v2]
In-Reply-To: <9nwTzXDoTgHiSd9hcmzyy0zhvvPj7U2VbsV4h5olsQ4=.fa045e9b-7309-42d0-91a9-875c34de5316@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
 <9nwTzXDoTgHiSd9hcmzyy0zhvvPj7U2VbsV4h5olsQ4=.fa045e9b-7309-42d0-91a9-875c34de5316@github.com>
Message-ID: <isnGEga7x_nBR2fnWxBgHgF4rZwkaMfT-P0wEvI1UPg=.5f1cb223-8665-4a5c-a6c4-6a85e39a940f@github.com>

On Wed, 21 Dec 2022 19:40:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Slightly updated original fix - got rid of the extra flasher reset. Tests are fixed to be more stable and pass on the corresponding platforms.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplifying the two nested if conditions into one.

I still think that the whole change is too generic, and affects many other places. For example, it will affect the XAWTCaret and the code added by the JDK-7129742. It seems the simpler change to make it always visible could cause fewer issues since we know that it works that way in awt on linux/windows.

test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java line 90:

> 88:         robot.waitForIdle();
> 89:         robot.delay(200);
> 90:         if (!field2.getCaret().isSelectionVisible()) {

This and the next test now checks behavior via the simple getter, but previously the test validated that the selection is actually visible on the screen which is more correct.

-------------

PR: https://git.openjdk.org/jdk20/pull/68


From serb at openjdk.org  Fri Dec 23 23:05:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 23 Dec 2022 23:05:51 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus [v2]
In-Reply-To: <9nwTzXDoTgHiSd9hcmzyy0zhvvPj7U2VbsV4h5olsQ4=.fa045e9b-7309-42d0-91a9-875c34de5316@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
 <9nwTzXDoTgHiSd9hcmzyy0zhvvPj7U2VbsV4h5olsQ4=.fa045e9b-7309-42d0-91a9-875c34de5316@github.com>
Message-ID: <x2ilcjEu2--mEt3EuOa3_RxFpAa4jZWHoDn9mUQlTcI=.7760a448-0062-4516-a6fc-1e2664f2dab3@github.com>

On Wed, 21 Dec 2022 19:40:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Slightly updated original fix - got rid of the extra flasher reset. Tests are fixed to be more stable and pass on the corresponding platforms.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplifying the two nested if conditions into one.

src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 373:

> 371:     // --- FocusListener methods --------------------------
> 372: 
> 373:     /**

I guess everybody noticed the specification of this method.
>This is implemented to set the caret to visible if the component is editable.

That should be updated? And overall it seems the whole behavior change required CSR.

-------------

PR: https://git.openjdk.org/jdk20/pull/68


From serb at openjdk.org  Sat Dec 24 00:37:49 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 24 Dec 2022 00:37:49 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v2]
In-Reply-To: <zBeQgfPEKgHQzBf1qvx2EZsODu08VtzxOyfCI70MKQs=.446bf052-8d33-482e-a661-c136f795c505@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
 <0x0ms0yarrHQrs6_AoYPZITOYxDHTyrHHgtfUzzaFKg=.687fa12c-eee3-4a89-9f36-1fa4792c7481@github.com>
 <zBeQgfPEKgHQzBf1qvx2EZsODu08VtzxOyfCI70MKQs=.446bf052-8d33-482e-a661-c136f795c505@github.com>
Message-ID: <Ty1gFxYg4bGBUkhCXOHjsemicZwpCO2W832siBZTes4=.30c78cc4-7273-494b-adf8-99521ca7c3d1@github.com>

On Fri, 23 Dec 2022 09:15:47 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/swing/AccessibleComponentAccessor.java line 42:
>> 
>>> 40:     }
>>> 41: 
>>> 42:     public static Accessible getAccessible(AccessibleContext context) {
>> 
>> Will the fix have more code if it will be implemented via SwingAccessor just to access that "private" method?
>
> Thank you.
> I removed adding accesses for TableCell and ListChildren. If that's what you meant.
> I would like to keep the implementation of the Accesser itself, if possible. Because in the future it may come in handy in this form, if in the future you still need to add access to the currentComponent for ListChildren and TableCell.
> this approach allows us to make the implementation more generic, in case the potential tree is not inherited from Jtree. It also avoids reflection.

Probably we can simplify it further. usually, the SwingAccessor is used to store one accessor per class, which does not need to have an additional list of functions. And if the a11y code needs to call different methods for different types of AccessibleComponent then it uses "instanceof" or role check inside the a11y code. Can we do the same here? It will have the same functionality.

-------------

PR: https://git.openjdk.org/jdk/pull/11670


From serb at openjdk.org  Sat Dec 24 00:58:48 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 24 Dec 2022 00:58:48 GMT
Subject: RFR: 8299255: Unexpected round errors in FreetypeFontScaler [v2]
In-Reply-To: <x7AXU3E9a9hh5U8TI2EYGgzbJ80lrxIFO5tUXa_um80=.f1108c89-fd04-477d-be55-553203b2aa9b@github.com>
References: <94vFT5CtKVy47qA2LgpWnBbbkVeIR09KumB7YAhcBBI=.72e88bba-cd2e-458e-a37b-74782af36185@github.com>
 <x7AXU3E9a9hh5U8TI2EYGgzbJ80lrxIFO5tUXa_um80=.f1108c89-fd04-477d-be55-553203b2aa9b@github.com>
Message-ID: <xsPGm-BkJcJUvq0PaBSNfzIEI1YquA31CkG3Rv-nvPg=.7698df57-cc3f-4517-ac61-3f95637ee506@github.com>

On Fri, 23 Dec 2022 06:33:25 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> In 'Java_sun_font_FreetypeFontScaler_createScalerContextNative', 'context->transform.xx' and '.yy' values are sometimes 65535 instead of 65536. There are unintentional double and float conversions. It may be no real harm, but I'd like to fix it.
>> 
>> Problem case:
>> context->transform.xx=**65535** yx=0 xy=0 yy=**65535** ptsz=46.590909 dmat[0]=46.590909 (float)dmat[0]=46.59090**8**
>> 
>> Normal case:
>> context->transform.xx=65536 yx=0 xy=0 yy=65536 ptsz=18.000000 dmat[0]=18.000000 (float)dmat[0]=18.000000
>> 
>> Test: jdk_desktop on Linux x86_64 had no regression issues.
>
> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a testcase

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11763


From serb at openjdk.org  Sat Dec 24 03:41:18 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 24 Dec 2022 03:41:18 GMT
Subject: RFR: 8299333: Unify exceptions used by all variants of
 ICC_Profile.getInstance(null)
Message-ID: <vcJUwGyej8Uk8AQC25VHJib-Tn0MMDATnf8H3JEZygQ=.8212bab6-583d-4e8b-9dce-15a94ef52c39@github.com>

I tried to clean up the documentation in the `java.awt.color` package and specify how the `null` parameters are handled here and there. But it looks like the `ICC_profile` class is too specific so I would like to discuss it separately.

The ICC_Profile has these methods:
 * `getInstance(int)`      - always throws specified `IllegalArgumentException` on the wrong constant
 * `getInstance(byte[])` - always throws specified `IllegalArgumentException` on `null`
 * `getInstance(String fileName)` - always throws unspecified `NullPointerException` on `null`
 * `getInstance(InputStream)`      - thrown unspecified `NullPointerException` before [JDK-8227816](https://github.com/openjdk/jdk/commit/af20c6b9c4a3a21c1e2c7f56721e1077e7d8f388) and now throws specified but misleading `IOException: Stream closed` exception on `null`

So we have 3 methods that can get null as a parameter and each throw a different exception.

Note that all of the specs for the methods above have this part:

> @throws IllegalArgumentException If the stream does not contain valid ICC Profile data

So I have an idea to change `getInstance(String)` and `getInstance(InputStream)` to throw `IllegalArgumentException`  even if I personally prefer NPE to be thrown.

>From another point of view the `ICC_Profile` profile has other methods:
 * `write(String fileName)` - always throws unspecified `NullPointerException` on `null`
 * `write(OutputStream) `  - always throws unspecified `NullPointerException` on `null`

I am not sure we can throw `IllegalArgumentException` from the `write` methods, so the specification for `getInstance(String)` and `getInstance(InputStream)` could be updated to throw NPE on null same as related `write`.

Thoughts?

-------------

Commit messages:
 - 8299333: Unify used exceptions by all variants of ICC_Profile.getInstance(null)

Changes: https://git.openjdk.org/jdk/pull/11784/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11784&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299333
  Stats: 22 lines in 2 files changed: 19 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11784.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11784/head:pull/11784

PR: https://git.openjdk.org/jdk/pull/11784


From serb at openjdk.org  Sat Dec 24 11:21:30 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 24 Dec 2022 11:21:30 GMT
Subject: RFR: 8299337: The java.awt.image.ColorModel#pData field is unused
Message-ID: <33MoUulwjlpaM_-aqninKh8mPXBN0-rKAacsfZ6OUF8=.957b42a7-73c1-4c0c-9ad1-74d0ed76c46b@github.com>

I have found that we store the native pointer in the "java.awt.image.ColorModel#pData" field and never update/clean it. We can check how and when the native data is deallocated and reset the pointer, but it will be easy just to delete the field as unused.

-------------

Commit messages:
 - pData macosx
 - pData

Changes: https://git.openjdk.org/jdk/pull/11785/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11785&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299337
  Stats: 13 lines in 5 files changed: 0 ins; 10 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11785.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11785/head:pull/11785

PR: https://git.openjdk.org/jdk/pull/11785


From tnakamura at openjdk.org  Sat Dec 24 14:30:09 2022
From: tnakamura at openjdk.org (Toshio Nakamura)
Date: Sat, 24 Dec 2022 14:30:09 GMT
Subject: RFR: 8299255: Unexpected round errors in FreetypeFontScaler [v2]
In-Reply-To: <x7AXU3E9a9hh5U8TI2EYGgzbJ80lrxIFO5tUXa_um80=.f1108c89-fd04-477d-be55-553203b2aa9b@github.com>
References: <94vFT5CtKVy47qA2LgpWnBbbkVeIR09KumB7YAhcBBI=.72e88bba-cd2e-458e-a37b-74782af36185@github.com>
 <x7AXU3E9a9hh5U8TI2EYGgzbJ80lrxIFO5tUXa_um80=.f1108c89-fd04-477d-be55-553203b2aa9b@github.com>
Message-ID: <-X0fCP9dAx4q7EKCKwWi5dNo-mlXR1nF7wSTLKCHBY4=.a8100c55-4fad-4024-8d6d-d1dbc5dae770@github.com>

On Fri, 23 Dec 2022 06:33:25 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> In 'Java_sun_font_FreetypeFontScaler_createScalerContextNative', 'context->transform.xx' and '.yy' values are sometimes 65535 instead of 65536. There are unintentional double and float conversions. It may be no real harm, but I'd like to fix it.
>> 
>> Problem case:
>> context->transform.xx=**65535** yx=0 xy=0 yy=**65535** ptsz=46.590909 dmat[0]=46.590909 (float)dmat[0]=46.59090**8**
>> 
>> Normal case:
>> context->transform.xx=65536 yx=0 xy=0 yy=65536 ptsz=18.000000 dmat[0]=18.000000 (float)dmat[0]=18.000000
>> 
>> Test: jdk_desktop on Linux x86_64 had no regression issues.
>
> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a testcase

Thank you for the review.
I confirmed Linux (RHEL9), mac (Ventura), and Windows (Windows Server 2019) with this test and patch.

-------------

PR: https://git.openjdk.org/jdk/pull/11763


From tnakamura at openjdk.org  Sat Dec 24 14:30:10 2022
From: tnakamura at openjdk.org (Toshio Nakamura)
Date: Sat, 24 Dec 2022 14:30:10 GMT
Subject: Integrated: 8299255: Unexpected round errors in FreetypeFontScaler
In-Reply-To: <94vFT5CtKVy47qA2LgpWnBbbkVeIR09KumB7YAhcBBI=.72e88bba-cd2e-458e-a37b-74782af36185@github.com>
References: <94vFT5CtKVy47qA2LgpWnBbbkVeIR09KumB7YAhcBBI=.72e88bba-cd2e-458e-a37b-74782af36185@github.com>
Message-ID: <it9jDfu2wF6OIR3-C8mpkFsES-Yl3oRhxYSiQT5DjDE=.a8cef8e9-f663-4774-a032-a0efc9cb7c3d@github.com>

On Thu, 22 Dec 2022 07:20:03 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> In 'Java_sun_font_FreetypeFontScaler_createScalerContextNative', 'context->transform.xx' and '.yy' values are sometimes 65535 instead of 65536. There are unintentional double and float conversions. It may be no real harm, but I'd like to fix it.
> 
> Problem case:
> context->transform.xx=**65535** yx=0 xy=0 yy=**65535** ptsz=46.590909 dmat[0]=46.590909 (float)dmat[0]=46.59090**8**
> 
> Normal case:
> context->transform.xx=65536 yx=0 xy=0 yy=65536 ptsz=18.000000 dmat[0]=18.000000 (float)dmat[0]=18.000000
> 
> Test: jdk_desktop on Linux x86_64 had no regression issues.

This pull request has now been integrated.

Changeset: 26868c1a
Author:    Toshio Nakamura <tnakamura at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/26868c1ac471c3b305b1d15e3075de0baa9319d2
Stats:     74 lines in 2 files changed: 69 ins; 0 del; 5 mod

8299255: Unexpected round errors in FreetypeFontScaler

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/11763


From duke at openjdk.org  Sat Dec 24 14:51:39 2022
From: duke at openjdk.org (Ravi Gupta)
Date: Sat, 24 Dec 2022 14:51:39 GMT
Subject: RFR: 8299296: Write a test to verify the components selection sends
 ItemEvent
Message-ID: <0HgEcWPfdikEgz9Qiq5C579YlTEaZ6-UG4wWXS0p7oA=.73a00672-386c-4a78-8bf6-619598a23dbd@github.com>

This testcase verifies the following assertions

a. Selecting an item in the Choice using mouse generates ItemEvent.
b. Single-click on an Checkbox generates ItemEvent.

Testing:
Tested using Mach5(20 times per platform) in macos, linux and windows and got all pass.

-------------

Commit messages:
 - Write a test to verify the components selection sends ItemEvent

Changes: https://git.openjdk.org/jdk/pull/11786/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11786&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299296
  Stats: 123 lines in 1 file changed: 123 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11786.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11786/head:pull/11786

PR: https://git.openjdk.org/jdk/pull/11786


From serb at openjdk.org  Sat Dec 24 22:15:47 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 24 Dec 2022 22:15:47 GMT
Subject: RFR: 8299296: Write a test to verify the components selection
 sends ItemEvent
In-Reply-To: <0HgEcWPfdikEgz9Qiq5C579YlTEaZ6-UG4wWXS0p7oA=.73a00672-386c-4a78-8bf6-619598a23dbd@github.com>
References: <0HgEcWPfdikEgz9Qiq5C579YlTEaZ6-UG4wWXS0p7oA=.73a00672-386c-4a78-8bf6-619598a23dbd@github.com>
Message-ID: <ssofgqKhhXhQfD2VeYi9ZEp6jtFk0fDw4QpifRglsn4=.6fc0f856-0046-4766-928c-3df77aa2b963@github.com>

On Sat, 24 Dec 2022 14:40:27 GMT, Ravi Gupta <duke at openjdk.org> wrote:

> This testcase verifies the following assertions
> 
> a. Selecting an item in the Choice using mouse generates ItemEvent.
> b. Single-click on an Checkbox generates ItemEvent.
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos, linux and windows and got all pass.

test/jdk/java/awt/event/ComponentEvent/ComponentItemEventTest.java line 25:

> 23: 
> 24: import java.awt.*;
> 25: import java.awt.event.*;

Just a small suggestion: "use single-class imports"

-------------

PR: https://git.openjdk.org/jdk/pull/11786


From serb at openjdk.org  Sun Dec 25 05:33:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 25 Dec 2022 05:33:51 GMT
Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java
 failed with 'Cannot invoke
 "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is
 null' [v4]
In-Reply-To: <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com>
 <xwdqUu0vvpO0S0BOaNDPAb_DZn7GCPGs87bzfH40YrQ=.8940071c-7fe5-4345-8029-146d17fff35d@github.com>
Message-ID: <DD5uVC90-DPgmwfJXNEgnLj_wxHGTD7_uKMZBwNLHa8=.6a564a17-23d4-4da8-8381-c882b852aaaa@github.com>

On Thu, 22 Dec 2022 05:13:34 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Did we check how the native code works w/o using JFileChooser, buy FileSystemView, or by the native example? Is it possible that it is intermittent because of timing related to "com" thread?

-------------

PR: https://git.openjdk.org/jdk/pull/11104


From abhiscxk at openjdk.org  Mon Dec 26 11:51:50 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 26 Dec 2022 11:51:50 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native [v4]
In-Reply-To: <xOcpuZQvcZc3HECZZCAIHWZd5zi0KqbvAMLQaLILG7E=.fe7ca755-acac-43d6-8946-1e8618105192@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
 <xOcpuZQvcZc3HECZZCAIHWZd5zi0KqbvAMLQaLILG7E=.fe7ca755-acac-43d6-8946-1e8618105192@github.com>
Message-ID: <FZQZUaWWldztOn71o2z6hRqaEBAdi5LGp_UOqBmrB1c=.d9505f77-5168-4567-9f2e-447fd1a0c2c4@github.com>

On Thu, 15 Dec 2022 06:47:33 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> It is not possible to select all files on press of Ctrl+A in JFileChooser for GTK LAF where as all folders can be selected. 
>> In native side on press of Ctrl+A, able to select all files as well as folders.
>> 
>> Proposed fix is to enable `multiselection `property by default for JFileChooser in GTK LAF to mimic native side behavior.
>> 
>> An automated test case is implemented and tested in CI. CI job links are attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

@jayathirthrao Tested the CI jobs in GTK LAF, seems all ok. JFileChooser test `javax/swing/JFileChooser/FileSizeCheck.java` failed in GTK LAF as this test is not supposed to run in GTK LAF.

Can you please review?

-------------

PR: https://git.openjdk.org/jdk/pull/11627


From asemenov at openjdk.org  Mon Dec 26 14:57:53 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 26 Dec 2022 14:57:53 GMT
Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v4]
In-Reply-To: <KMaPkryUkSlIZdpEz7fkT1nAqPTJZIseooxtFBBT4dc=.2d3f244f-7e94-4e97-b932-99cef0c7eaab@github.com>
References: <iogsScwXVmrG-QaPPqnBIyBbyc30OmKOUPLjiSKpEEs=.c76d3e64-ea3e-4560-a88a-821f25f9680b@github.com>
 <KMaPkryUkSlIZdpEz7fkT1nAqPTJZIseooxtFBBT4dc=.2d3f244f-7e94-4e97-b932-99cef0c7eaab@github.com>
Message-ID: <va7df3Hih5WDtdxG4JwYcaIh31psBKchKId7HmAPK3Q=.7bf3a3ac-3f33-4930-8892-66861b439683@github.com>

On Wed, 9 Nov 2022 09:42:00 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 are not using author tags in tests either - but that's just a nitpick.

@mrserb Please see my [comment](https://github.com/openjdk/jdk/pull/8578#issuecomment-1328770698) above in which I answer your questions.

-------------

PR: https://git.openjdk.org/jdk/pull/8578


From serb at openjdk.org  Mon Dec 26 23:13:41 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 26 Dec 2022 23:13:41 GMT
Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java fails
 with AssertionError
Message-ID: <cocMPNEB_pT0xJte81zvjMY_OXDmtNwajviD6LAfqsw=.5f205c88-1630-4b97-882b-c20ee47493ed@github.com>

This assertion happens when we try to build the path linked by the shortcut file when part of that path is not accessible. For example, if the ".lnk" file is pointed to the "windows-update. settings" inside the "Internet.settings". 

After the change, we will skip the target of the link if any part of the path to the target is not a folder and is not traversable in JFileChooser.

-------------

Commit messages:
 - 8227257: javax/swing/JFileChooser/4847375/bug4847375.java fails with AssertionError

Changes: https://git.openjdk.org/jdk/pull/11789/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11789&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8227257
  Stats: 84 lines in 4 files changed: 80 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11789.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11789/head:pull/11789

PR: https://git.openjdk.org/jdk/pull/11789


From mernst at openjdk.org  Tue Dec 27 14:26:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Dec 2022 14:26:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v3]
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <G6y9-__VIQjwSKAhHqAaBz9XhPTAsANIlDIZqrlAlow=.efb3bc20-d266-4717-84ee-b970989f8e44@github.com>

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge ../jdk-openjdk into typos-typos
 - Reinstate typos in Apache code that is copied into the JDK
 - Merge ../jdk-openjdk into typos-typos
 - Remove file that was removed upstream
 - Fix inconsistency in capitalization
 - Undo change in zlip
 - Fix typos

-------------

Changes: https://git.openjdk.org/jdk/pull/10029/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=02
  Stats: 11 lines in 10 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10029.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029

PR: https://git.openjdk.org/jdk/pull/10029


From mernst at openjdk.org  Tue Dec 27 14:26:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Dec 2022 14:26:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
 <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>
Message-ID: <KQM3bb5WQ1wCnIsc8lnqTrD54nkWyrhnHyk7hkSfp70=.5924492b-d7e8-4a26-bbe7-f78f0c9f9959@github.com>

On Mon, 28 Nov 2022 09:00:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs?  Then it can be merged, rather than wasting all the effort that went into it.
>
>> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it.
> 
> I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs.

Many thanks to those (especially @jaikiran) who helped to merge many of these typo fixes.
I have pulled master and resolved merge conflicts.  Only 11 typo fixes remain.
Could someone shepherd those into the codebase?  Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10029


From duke at openjdk.org  Tue Dec 27 14:44:06 2022
From: duke at openjdk.org (Christoph)
Date: Tue, 27 Dec 2022 14:44:06 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v19]
In-Reply-To: <W8Ac5RQQcrQmv0Z_dU-lwhu1ny1MjgGq7xvnObMFTlU=.c4eeee8b-535e-4394-99db-10a7918e8733@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <W8Ac5RQQcrQmv0Z_dU-lwhu1ny1MjgGq7xvnObMFTlU=.c4eeee8b-535e-4394-99db-10a7918e8733@github.com>
Message-ID: <IjQKyb39LaSWsKhpb9QqokFE0LzkytGH324VkE3H1yM=.e6f4a4d6-dff7-494c-9eda-cfa7e1e52844@github.com>

On Thu, 8 Dec 2022 19:41:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan 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 24 additional commits since the last revision:
> 
>  - adlc update per review
>  - Merge
>  - update on review feedback
>  - comment for snprintf_checked
>  - use checked snprintf for adlc
>  - use checked snprintf
>  - no check on adlc
>  - revert use of assert
>  - extra sizeof typo
>  - more size_t updare for windows build
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/3a3bbe53...49bb58fd

I just stumbled across this issue as well, make images did succeed, only the test is now failing with the same error
mac os 13.1 with XCode 14.2 on macbook M1 pro 
commit: 
11fd651ab1820770e3c65cd49589416098987a87 


ERROR: Build failed for target 'run-test-tier1' in configuration 'macosx-aarch64-server-release' (exit code 2) 

=== Output from failing command(s) repeated here ===
* For target support_test_hotspot_jtreg_native_support_libAsyncExceptionOnMonitorEnter_libAsyncExceptionOnMonitorEnter.o:

-------------

PR: https://git.openjdk.org/jdk/pull/11115


From abhiscxk at openjdk.org  Tue Dec 27 19:15:59 2022
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 27 Dec 2022 19:15:59 GMT
Subject: RFR: 8081507: Open or Save button in JFileChooser has OK title in GTK
 LaF
Message-ID: <xiAzTly59fGFbv79RPrpnePFxG42TRYmGXrikg8DUKQ=.96d809a6-379e-4943-9e6d-41ac46fbc01f@github.com>

Open or Save button in JFileChooser has OK title in GTK LAF. The open/save button text modified as per the native FileChooser. Manual test case is added.

`open/test/jdk/sanity/client/SwingSet/src/FileChooserDemoTest.java` failed with the current fix with an exception `**Wait AbstractButton with text "OK" loaded.**` Updated the test for GTK LAF and tested in CI which is OK now.

CI link is added in JBS.

-------------

Commit messages:
 - Open/Save button text modified

Changes: https://git.openjdk.org/jdk/pull/11790/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11790&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8081507
  Stats: 82 lines in 3 files changed: 78 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11790.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11790/head:pull/11790

PR: https://git.openjdk.org/jdk/pull/11790


From xuelei at openjdk.org  Tue Dec 27 19:43:58 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 27 Dec 2022 19:43:58 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v19]
In-Reply-To: <IjQKyb39LaSWsKhpb9QqokFE0LzkytGH324VkE3H1yM=.e6f4a4d6-dff7-494c-9eda-cfa7e1e52844@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <W8Ac5RQQcrQmv0Z_dU-lwhu1ny1MjgGq7xvnObMFTlU=.c4eeee8b-535e-4394-99db-10a7918e8733@github.com>
 <IjQKyb39LaSWsKhpb9QqokFE0LzkytGH324VkE3H1yM=.e6f4a4d6-dff7-494c-9eda-cfa7e1e52844@github.com>
Message-ID: <h75W5m-3jUgO0q1V9h2_RhhWuC_r4sTPVNsUbzrsjtA=.fef0b4dd-a9a0-4145-b421-57b90628d701@github.com>

On Tue, 27 Dec 2022 14:40:36 GMT, Christoph <duke at openjdk.org> wrote:

> ERROR: Build failed for target 'run-test-tier1' in configuration 'macosx-aarch64-server-release' (exit code 2) 
> 
[JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) was filled to track the issue.  Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/11115


From mik3hall at gmail.com  Tue Dec 27 20:04:15 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 27 Dec 2022 14:04:15 -0600
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v19]
In-Reply-To: <h75W5m-3jUgO0q1V9h2_RhhWuC_r4sTPVNsUbzrsjtA=.fef0b4dd-a9a0-4145-b421-57b90628d701@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <W8Ac5RQQcrQmv0Z_dU-lwhu1ny1MjgGq7xvnObMFTlU=.c4eeee8b-535e-4394-99db-10a7918e8733@github.com>
 <IjQKyb39LaSWsKhpb9QqokFE0LzkytGH324VkE3H1yM=.e6f4a4d6-dff7-494c-9eda-cfa7e1e52844@github.com>
 <h75W5m-3jUgO0q1V9h2_RhhWuC_r4sTPVNsUbzrsjtA=.fef0b4dd-a9a0-4145-b421-57b90628d701@github.com>
Message-ID: <51F41815-D3CE-4252-8BAF-E00A99A7878F@gmail.com>



> On Dec 27, 2022, at 1:43 PM, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:
> 
> On Tue, 27 Dec 2022 14:40:36 GMT, Christoph <duke at openjdk.org> wrote:
> 
>> ERROR: Build failed for target 'run-test-tier1' in configuration 'macosx-aarch64-server-release' (exit code 2) 
>> 
> [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) was filled to track the issue.  Thanks!
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/11115

Thank you for providing the tracking issue.

From duke at openjdk.org  Tue Dec 27 21:16:51 2022
From: duke at openjdk.org (Tres Finocchiaro)
Date: Tue, 27 Dec 2022 21:16:51 GMT
Subject: RFR: 8295737: macOS: Print content cut off when width > height
 with portrait orientation [v4]
In-Reply-To: <V5gvpteeBdnxA9CP2GvxRkNWQZkfXc4TwIQRTO4T6Gs=.e3a3c51d-0b29-483e-8bae-14fd12ac65d1@github.com>
References: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
 <V5gvpteeBdnxA9CP2GvxRkNWQZkfXc4TwIQRTO4T6Gs=.e3a3c51d-0b29-483e-8bae-14fd12ac65d1@github.com>
Message-ID: <lMyyDdDkDTQnXjZqXZHhzvuywz_M7AIJginynwdIG0Y=.ae8365f2-7f14-4054-abc0-f830ab951087@github.com>

On Tue, 29 Nov 2022 10:36:32 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)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in FlipPageFormat class comments

Bumping for bots.

-------------

PR: https://git.openjdk.org/jdk/pull/10808


From duke at openjdk.org  Wed Dec 28 00:10:53 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 28 Dec 2022 00:10:53 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v4]
In-Reply-To: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
Message-ID: <V_RDZRd3lBHSD6XCLj_TM4-wxZGXZw0y7R7QPneYNuY=.d2722225-fae2-47d1-8545-52dee5949d3b@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8296661)
> 
> This is tracked in JBS as 
> - [JDK-8296661 : Typo Found In CSSParser.java](https://bugs.openjdk.java.net/browse/JDK-8296661)
> 
> I suspect a typo in the documentation comments.
> 
> Designed from : [ScientificWare JDK-8296661 : Typo Found In CSSParser.java](https://github.com/scientificware/jdk/issues/18)

ScientificWare has updated the pull request incrementally with two additional commits since the last revision:

 - Update Copyright.
   
   Change date.
 - Suggested improvements.
   
   - Add missing {@code} tags and update <code> tag with {@code} tag.
   - Add a paragraph to improve readability

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10975/files
  - new: https://git.openjdk.org/jdk/pull/10975/files/8b5eab5d..3a6eac4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10975&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10975&range=02-03

  Stats: 20 lines in 1 file changed: 1 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/10975.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10975/head:pull/10975

PR: https://git.openjdk.org/jdk/pull/10975


From duke at openjdk.org  Wed Dec 28 00:11:13 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 28 Dec 2022 00:11:13 GMT
Subject: RFR: JDK-8296661 : Typo Found In CSSParser.java [v4]
In-Reply-To: <XQc1zO2_1zdGa9qZ7uI0V6EzSwf4CWw7hl2B4-d8Enc=.c2a9f7e8-03f8-4b02-b823-6385da2968b0@github.com>
References: <hgWufUs95jrLqGJAhDJtuhK0GKbl97nObvaxGaqIM2s=.f84a87d8-e5fa-40e5-94de-80c86fcab8b4@github.com>
 <zbvDGc4EHbOQfvq8srOEeTwlyfraCuDbRYN0jXDo7RE=.dfa036b5-bebe-4d7c-af1a-ab8328184328@github.com>
 <XQc1zO2_1zdGa9qZ7uI0V6EzSwf4CWw7hl2B4-d8Enc=.c2a9f7e8-03f8-4b02-b823-6385da2968b0@github.com>
Message-ID: <j1IrDIcomkKN_qPd1XZcnQitjodg7iPzBL74WFu4U8I=.6a563564-5c40-471f-8945-45456a7f7769@github.com>

On Mon, 12 Dec 2022 13:06:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Looks good to me.
>> 
>> In the description above: ??invoked one per property??, it shoud be ?once?.
>> 
>> I think there's room for improvement. However, this is an internal-only class.
>
>> I think there's room for improvement. However, this is an internal-only class.
> 
> This is what I have in mind. The list of callbacks is inconsistent in how the method and conditions when it's called are listed. One of the list items has no ending punctuation. Some portions of text should use `<code>` or `{@code}`, or even [`<samp>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/samp).
> 
> I think `<p>` should be added before this sentence, _?If an error results in parsing, a RuntimeException will be thrown.?_ The sentence itself requires re-writing: ?If parsing results in an error??
> 
> Both `RuntimeException` and `toLowerCase` below should be in `{@code}`.
> 
> The usage of `<code>` could be updated to `{@code}` which is the recommended way.
> 
> What do you think?

@aivanov-jdk Done.

-------------

PR: https://git.openjdk.org/jdk/pull/10975


From jdv at openjdk.org  Wed Dec 28 04:32:56 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 28 Dec 2022 04:32:56 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native [v4]
In-Reply-To: <xOcpuZQvcZc3HECZZCAIHWZd5zi0KqbvAMLQaLILG7E=.fe7ca755-acac-43d6-8946-1e8618105192@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
 <xOcpuZQvcZc3HECZZCAIHWZd5zi0KqbvAMLQaLILG7E=.fe7ca755-acac-43d6-8946-1e8618105192@github.com>
Message-ID: <2xID_ecGBaRwgqVZ1zS2xZNqBMAjT9djKg0rQ90LkF0=.2f359f07-ce0d-4a6d-9ed3-fe844b2dddcc@github.com>

On Thu, 15 Dec 2022 06:47:33 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> It is not possible to select all files on press of Ctrl+A in JFileChooser for GTK LAF where as all folders can be selected. 
>> In native side on press of Ctrl+A, able to select all files as well as folders.
>> 
>> Proposed fix is to enable `multiselection `property by default for JFileChooser in GTK LAF to mimic native side behavior.
>> 
>> An automated test case is implemented and tested in CI. CI job links are attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11627


From mbaesken at openjdk.org  Wed Dec 28 14:30:56 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Dec 2022 14:30:56 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <lGGwZvwa0eAtXlap63EaW0vJxvWj_u_g1eG_0D7HaaI=.ee110e67-29a4-4120-a048-d1835913e3d0@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

okay, if keeping the block in the code that contains free and return, we probably just stay with what we have


if ((*env)->ExceptionCheck(env)) {
  free(xyz);
  return val;
}

-------------

PR: https://git.openjdk.org/jdk/pull/11539


From mbaesken at openjdk.org  Wed Dec 28 14:30:56 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Dec 2022 14:30:56 GMT
Subject: Withdrawn: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <hovzXng89xaaB2qEqOczilkrVMvf20YRYcHirL9CZ8k=.24116009-ed32-4562-9c00-a859bb2c8494@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11539


From mik3hall at gmail.com  Wed Dec 28 15:11:46 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 28 Dec 2022 09:11:46 -0600
Subject: OS/X GUI applications
Message-ID: <CA1D7F10-343A-4052-8E35-D21C32F9719B@gmail.com>

I was wondering for some reason what version of the Scene Builder application I had. There was no application ?About? menu item. 
I noticed one of my own applications did have this but I didn?t remember how. 
I finally noticed on my jpackage options I was still using?

-Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe

Which I assume is enabling the feature.

I also include?

-Dapple.laf.useScreenMenuBar=true -Dapple.awt.application.name=HalfPipe

I am aware the jdk has replaced or eliminated some of this but I didn?t think still including them would cause any problems and more or less forgot they were there.

Is it the intention to continue supporting any of these old Apple properties? Or are they planned to all be eliminated?

I verified java.awt.Desktop does include?

void	setAboutHandler?(AboutHandler aboutHandler)

Which I would assume is the cross platform preferred and supported way of doing this. Although a bit more work to provide your own window. 

If java.awt,Desktop is still the preferred support encapsulating this platform specific functionality will javaFX at some point provide similar? 

This is possibly not the correct list for this. I suppose I should raise the question on the javaFX list as well as that it would be nice if SceneBuilder did have an ?about? menu item to check the version you have installed.

From swinxythecat at gmail.com  Wed Dec 28 23:08:05 2022
From: swinxythecat at gmail.com (SWinxy)
Date: Wed, 28 Dec 2022 18:08:05 -0500
Subject: OS/X GUI applications
In-Reply-To: <CA1D7F10-343A-4052-8E35-D21C32F9719B@gmail.com>
References: <CA1D7F10-343A-4052-8E35-D21C32F9719B@gmail.com>
Message-ID: <CAPRuVTVjNc262tiRHP71iHcR+_oAspdFzRdHA0icZ_qthH+tDg@mail.gmail.com>

The Apple system properties are going to remain as they are, unless e.g.
there's some good reason to change the key of a property. Afaik
setAboutHandler is the only way to set such a callback. I don't know what "
com.apple.mrj.application.apple.menu.about.name" is, as it's not a string
in the JDK. Ask the JavaFX mailing list for supporting an About handler if
they don't already have it; I believe their mailing list is
openjfx-dev at openjdk.org.

On Wed, Dec 28, 2022 at 10:11 AM Michael Hall <mik3hall at gmail.com> wrote:

> I was wondering for some reason what version of the Scene Builder
> application I had. There was no application ?About? menu item.
> I noticed one of my own applications did have this but I didn?t remember
> how.
> I finally noticed on my jpackage options I was still using?
>
> -Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe
>
> Which I assume is enabling the feature.
>
> I also include?
>
> -Dapple.laf.useScreenMenuBar=true -Dapple.awt.application.name=HalfPipe
>
> I am aware the jdk has replaced or eliminated some of this but I didn?t
> think still including them would cause any problems and more or less forgot
> they were there.
>
> Is it the intention to continue supporting any of these old Apple
> properties? Or are they planned to all be eliminated?
>
> I verified java.awt.Desktop does include?
>
> void    setAboutHandler?(AboutHandler aboutHandler)
>
> Which I would assume is the cross platform preferred and supported way of
> doing this. Although a bit more work to provide your own window.
>
> If java.awt,Desktop is still the preferred support encapsulating this
> platform specific functionality will javaFX at some point provide similar?
>
> This is possibly not the correct list for this. I suppose I should raise
> the question on the javaFX list as well as that it would be nice if
> SceneBuilder did have an ?about? menu item to check the version you have
> installed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221228/939f9ab7/attachment.htm>

From serb at openjdk.org  Thu Dec 29 03:42:50 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 29 Dec 2022 03:42:50 GMT
Subject: RFR: 8081507: Open or Save button in JFileChooser has OK title in
 GTK LaF
In-Reply-To: <xiAzTly59fGFbv79RPrpnePFxG42TRYmGXrikg8DUKQ=.96d809a6-379e-4943-9e6d-41ac46fbc01f@github.com>
References: <xiAzTly59fGFbv79RPrpnePFxG42TRYmGXrikg8DUKQ=.96d809a6-379e-4943-9e6d-41ac46fbc01f@github.com>
Message-ID: <asK1gGR8S-lk1vrFrmLRGg57jpbqclqqmJiKKVk8iFw=.7597cd9d-6391-4eea-af2b-607e9e283a79@github.com>

On Tue, 27 Dec 2022 19:05:10 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Open or Save button in JFileChooser has OK title in GTK LAF. The open/save button text modified as per the native FileChooser. Manual test case is added.
> 
> `open/test/jdk/sanity/client/SwingSet/src/FileChooserDemoTest.java` failed with the current fix with an exception `**Wait AbstractButton with text "OK" loaded.**` Updated the test for GTK LAF and tested in CI which is OK now.
> 
> CI link is added in JBS.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11790


From mik3hall at gmail.com  Thu Dec 29 03:51:27 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 28 Dec 2022 21:51:27 -0600
Subject: OS/X GUI applications
In-Reply-To: <CAPRuVTVjNc262tiRHP71iHcR+_oAspdFzRdHA0icZ_qthH+tDg@mail.gmail.com>
References: <CA1D7F10-343A-4052-8E35-D21C32F9719B@gmail.com>
 <CAPRuVTVjNc262tiRHP71iHcR+_oAspdFzRdHA0icZ_qthH+tDg@mail.gmail.com>
Message-ID: <CAMZMqONG43rUAKeZaRPg0zzge8QnHrv0wD4YDrjGzvm1w07SoQ@mail.gmail.com>

Mail.app not receiving for some reason. So from gmail in Safari.

>The Apple system properties are going to remain as they are, unless e.g.
there's some good reason to change the key of a property.

OK, good to know. I'm pretty sure -Dapple.laf.useScreenMenuBar=true was
made the OS/X application default. I thought some of the other old property
functionality had been incorporated in some way or other but might be
mistaken.

>Afaik setAboutHandler is the only way to set such a callback.

There seems to be some other way because I don't find anywhere I use this.
I eliminated all Apple system properties but still get an About... It seems
you are correct that eliminating the about.name appears to have no impact.
Eliminating -Dapple.awt.application.name=HalfPipe and the About menu item
no longer shows the application name but rather the unpackaged main class
name. The About window is still correct. It includes the application icon,
the application name (valid) in bold. Also, Version and Copyright it
appears to get from the application Info.plist. Rather a nice default. I
could post a screen shot somewhere? Possibly something has been cached for
the app by Apple from some time ago? Or I still need to figure out where
this comes from.

>Ask the JavaFX mailing list for supporting an About handler if they don't
already have it; I believe their mailing list is openjfx-dev at openjdk.org

OK, this part of the support would be split. Thanks.










On Wed, Dec 28, 2022 at 5:08 PM SWinxy <swinxythecat at gmail.com> wrote:

> The Apple system properties are going to remain as they are, unless e.g.
> there's some good reason to change the key of a property. Afaik
> setAboutHandler is the only way to set such a callback. I don't know what "
> com.apple.mrj.application.apple.menu.about.name" is, as it's not a string
> in the JDK. Ask the JavaFX mailing list for supporting an About handler if
> they don't already have it; I believe their mailing list is
> openjfx-dev at openjdk.org.
>
> On Wed, Dec 28, 2022 at 10:11 AM Michael Hall <mik3hall at gmail.com> wrote:
>
>> I was wondering for some reason what version of the Scene Builder
>> application I had. There was no application ?About? menu item.
>> I noticed one of my own applications did have this but I didn?t remember
>> how.
>> I finally noticed on my jpackage options I was still using?
>>
>> -Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe
>>
>> Which I assume is enabling the feature.
>>
>> I also include?
>>
>> -Dapple.laf.useScreenMenuBar=true -Dapple.awt.application.name=HalfPipe
>>
>> I am aware the jdk has replaced or eliminated some of this but I didn?t
>> think still including them would cause any problems and more or less forgot
>> they were there.
>>
>> Is it the intention to continue supporting any of these old Apple
>> properties? Or are they planned to all be eliminated?
>>
>> I verified java.awt.Desktop does include?
>>
>> void    setAboutHandler?(AboutHandler aboutHandler)
>>
>> Which I would assume is the cross platform preferred and supported way of
>> doing this. Although a bit more work to provide your own window.
>>
>> If java.awt,Desktop is still the preferred support encapsulating this
>> platform specific functionality will javaFX at some point provide similar?
>>
>> This is possibly not the correct list for this. I suppose I should raise
>> the question on the javaFX list as well as that it would be nice if
>> SceneBuilder did have an ?about? menu item to check the version you have
>> installed.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221228/69d0b4bc/attachment.htm>

From psadhukhan at openjdk.org  Thu Dec 29 06:22:01 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 29 Dec 2022 06:22:01 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v3]
In-Reply-To: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
Message-ID: <23xwHp6apwTTidFVoGzCjc-oSkW7v8hOVFZ4D_lP6c0=.eba74ea0-5731-4c4a-a971-95ec36248796@github.com>

> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
> says:
> "...MetalLookAndFeel registers an entry for each of the classes
> in the package javax.swing.plaf.metal that are named MetalXXXUI.
> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
> that do not have a class in metal, the corresponding class in
> javax.swing.plaf.basic is used. For example, metal does not
> have a class named "MetalColorChooserUI", as such,
> javax.swing.plaf.basic.BasicColorChooserUI is used".
> 
> There is class MetalMenuBarUI, but the method populates given defaults table with the value
> "javax.swing.plaf.basic.BasicMenuBarUI".
> 
> Added entry for MetalMenuBarUI..
> CI tests including JCK tests are ok.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Spec update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11646/files
  - new: https://git.openjdk.org/jdk/pull/11646/files/2ea55a0b..71965da8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11646&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11646&range=01-02

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11646.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11646/head:pull/11646

PR: https://git.openjdk.org/jdk/pull/11646


From psadhukhan at openjdk.org  Thu Dec 29 06:22:03 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 29 Dec 2022 06:22:03 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v2]
In-Reply-To: <Ql4IvmLxz59m7DnVJHBloyZLD6C9bMG0ydxAneZSiMY=.f202e219-0885-4c9f-9ecb-9380e0440b8a@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <_KNiQ96NyPHL7dQDcea1f2YhIHNqfv3a4ZNJKTmAEik=.c7d97d75-09f7-4c8c-b433-5a030b12205c@github.com>
 <Ql4IvmLxz59m7DnVJHBloyZLD6C9bMG0ydxAneZSiMY=.f202e219-0885-4c9f-9ecb-9380e0440b8a@github.com>
Message-ID: <LoISd4AszvmCZ3lgjRlA7IMmMrIBC5AjNKeuog7Jlf8=.a2cc6f69-c685-4664-9a21-b65c692b5a19@github.com>

On Thu, 22 Dec 2022 22:29:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Spec update
>>  - Spec update
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java line 255:
> 
>> 253:      * "MetalColorChooserUI"}, as such, {@code
>> 254:      * javax.swing.plaf.basic.BasicColorChooserUI} is used.
>> 255:      * Also, class {@code MetalMenuBarUI} is used only for {@code OceanTheme}
> 
> Maybe we can make it more generic, like some classes could be used only by some themes and registered only if that theme is "active", for example {@code MetalMenuBarUI} .... etc

ok..we can do that...modified...

-------------

PR: https://git.openjdk.org/jdk/pull/11646


From alanb at openjdk.org  Thu Dec 29 06:39:48 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 Dec 2022 06:39:48 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows [v2]
In-Reply-To: <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
 <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
Message-ID: <zb6eEaP0rHV2V07_5BEJASXyEGjNfp3TYe47hz29luM=.85310173-7cd4-4e5d-af5d-d2acd1104cb4@github.com>

On Thu, 22 Dec 2022 10:57:15 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> **Environment**: 
>> GraalVM 22.3.0 with  jdk 19, Windows OS.
>> 
>> **Description**:
>> Create a native image of Swing application using GraalVM and run it with ` -Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> `java.lang.Error: java.home property not set` error is thrown.
>> 
>> For more details see https://github.com/oracle/graal/issues/4875.
>> 
>> **Solution**:
>> The error is thrown by the code from [FontConfiguration.findFontConfigFile()](https://github.com/openjdk/jdk19u/blob/c9d485792b99233f381dcdfd69838e7b973909bd/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L175) method.
>> GraalVM does not set `java.home`  property, that is why the `java.lang.Error: java.home property not set` is thrown.
>> `FontConfiguration.findFontConfigFile()` method compares `java.home` property to null before checking user provided `sun.awt.fontconfig` java property.
>> 
>> The proposed fix swaps the order of `java.home` and `sun.awt.fontconfig` properties checking to avoid using `java.home` property in case `sun.awt.fontconfig` is set.
>> 
>> 
>> **Steps to reproduce**:
>> - Download graal 22.3.0 jdk 19 for Windows from [GraalVM Community Edition 22.3.0](https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0) page.
>> - Install native-image
>> 
>> graalvm-ce-java19-22.3.0\bin\gu.cmd install native-image
>> 
>> - Create and compile `SwingSample.java` sample
>> 
>> import java.awt.*;
>> import javax.swing.*;
>> 
>> public class SwingSample {
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeAndWait(() -> {
>> 
>>             JFrame frame = new JFrame("Hello World");
>> 
>>             JButton button = new JButton("Hello");
>>             button.addActionListener(e -> {
>>                 System.out.printf("Hello, World!%n");
>>             });
>> 
>>             JPanel panel = new JPanel(new FlowLayout());
>>             panel.add(button);
>> 
>>             frame.add(panel);
>>             frame.setSize(400, 300);
>>             frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>             frame.setVisible(true);
>>         });
>>     }
>> }
>> 
>> - Run native-image-agent to generate configuration files
>> 
>> graalvm-ce-java19-22.3.0\bin\java.cmd -agentlib:native-image-agent=config-output-dir=conf-dir SwingSample
>> 
>> - Copy `graalvm-ce-java19-22.3.0\lib\fontconfig.properties.src` file to the sample dir
>> - Generate native image with configuration files and `-Djava.awt.headless=false `, `-Dsun.awt.fontconfig=fontconfig.properties.src` java properties
>> 
>> call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64"
>> graalvm-ce-java19-22.3.0\bin\native-image.cmd --no-fallback -Djava.awt.headless=false -Dsun.awt.fontconfig=fontconfig.properties.src -H:ResourceConfigurationFiles=conf-dir/resource-config.json -H:SerializationConfigurationFiles=conf-dir/serialization-config.json -H:ReflectionConfigurationFiles=conf-dir/reflect-config.json -H:JNIConfigurationFiles=conf-dir/jni-config.json SwingSample
>> 
>> - Run the native image with `-Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> 
>> swingsample.exe  -Dsun.awt.fontconfig=fontconfig.properties.src
>> 
>> Exception in thread "main" java.lang.reflect.InvocationTargetException
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371)
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346)
>>         at java.desktop at 19.0.1/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480)
>>         at SwingSample.main(SwingSample.java:7)
>> Caused by: java.lang.Error: java.home property not set
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
>>         at java.desktop at 19.0.1/sun.awt.windows.WFontConfiguration.<init>(WFontConfiguration.java:41)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize javaLib when a user fontconfig file is set

The table in System.getProperties() lists the standard system properties. java.home is not optional. It's not hard to find code that reads the value of this property and it would be a major compatibility issue to change java.home to be optional.

-------------

PR: https://git.openjdk.org/jdk/pull/11559


From psadhukhan at openjdk.org  Thu Dec 29 06:52:17 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 29 Dec 2022 06:52:17 GMT
Subject: RFR: 7030853: JDK 7 Serializable Swing classes not compatible with
 JDK 6 [v8]
In-Reply-To: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
References: <8zjk0Ts2Wi9wcetmRUaRsQWWfyModJbXf_aRnl7225I=.40a6a68f-fb5c-4b63-a191-47e0e2a07b72@github.com>
Message-ID: <2foDWBaTP1qZxwNmj940TSWXfl3BkFr6lENO9ZG91qo=.f6c37ff2-f160-40e6-8e34-c531f565d97d@github.com>

> The serialized form of the following classes in JDK 7 builds are not compatible with prior versions of Java:
>     javax.swing.text.html.parser.ParserDelegator
>     javax.swing.LayoutComparator
> They need to be declared as not compatible between releases in the API documentation, as is the case for some other serializable Swing classes.
> 
> Since It is widely known that serialized Swing classes are not comptible between major releases, we just didn't add the warning at that couple classes.
> Added the warning..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Add <p> tag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11565/files
  - new: https://git.openjdk.org/jdk/pull/11565/files/6ac67d2f..1ae17a08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11565&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11565&range=06-07

  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11565.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11565/head:pull/11565

PR: https://git.openjdk.org/jdk/pull/11565


From asemenov at openjdk.org  Thu Dec 29 13:02:20 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 29 Dec 2022 13:02:20 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v3]
In-Reply-To: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
Message-ID: <Ni3jWmJDmGS6fAMRHBfQ2Qi6J7AVW4rOmCY125k0K9E=.e32b69f8-7946-47b6-b8d1-7b858af4b432@github.com>

> [OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  update accessor

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11670/files
  - new: https://git.openjdk.org/jdk/pull/11670/files/8bad4ba2..4fd570e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11670&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11670&range=01-02

  Stats: 108 lines in 6 files changed: 45 ins; 54 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/11670.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11670/head:pull/11670

PR: https://git.openjdk.org/jdk/pull/11670


From asemenov at openjdk.org  Thu Dec 29 14:23:40 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 29 Dec 2022 14:23:40 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v4]
In-Reply-To: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
Message-ID: <s4E0bCDZWMPHuScZXBcfc5FuApSr15CuahnNuxmCadk=.e76d700e-37a7-435f-b653-e3ad33605c9e@github.com>

> [OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

Artem Semenov 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 master
 - update accessor
 - Please split the long lines to have 80 chars per line.
 - 8298644 JNI call of getCurrentComponent on a wrong thread

-------------

Changes: https://git.openjdk.org/jdk/pull/11670/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11670&range=03
  Stats: 85 lines in 4 files changed: 63 ins; 15 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11670.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11670/head:pull/11670

PR: https://git.openjdk.org/jdk/pull/11670


From asemenov at openjdk.org  Thu Dec 29 14:23:42 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 29 Dec 2022 14:23:42 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v4]
In-Reply-To: <Ty1gFxYg4bGBUkhCXOHjsemicZwpCO2W832siBZTes4=.30c78cc4-7273-494b-adf8-99521ca7c3d1@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
 <0x0ms0yarrHQrs6_AoYPZITOYxDHTyrHHgtfUzzaFKg=.687fa12c-eee3-4a89-9f36-1fa4792c7481@github.com>
 <zBeQgfPEKgHQzBf1qvx2EZsODu08VtzxOyfCI70MKQs=.446bf052-8d33-482e-a661-c136f795c505@github.com>
 <Ty1gFxYg4bGBUkhCXOHjsemicZwpCO2W832siBZTes4=.30c78cc4-7273-494b-adf8-99521ca7c3d1@github.com>
Message-ID: <ttnyvXjTFQ4k146eKkzswz41TWm_xeaUKIYSST8DoSs=.fe9365aa-cda0-4815-aa39-377a69c711b0@github.com>

On Sat, 24 Dec 2022 00:35:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Thank you.
>> I removed adding accesses for TableCell and ListChildren. If that's what you meant.
>> I would like to keep the implementation of the Accesser itself, if possible. Because in the future it may come in handy in this form, if in the future you still need to add access to the currentComponent for ListChildren and TableCell.
>> this approach allows us to make the implementation more generic, in case the potential tree is not inherited from Jtree. It also avoids reflection.
>
> Probably we can simplify it further. usually, the SwingAccessor is used to store one accessor per class, which does not need to have an additional list of functions. And if the a11y code needs to call different methods for different types of AccessibleComponent then it uses "instanceof" or role check inside the a11y code. Can we do the same here? It will have the same functionality.

Done

-------------

PR: https://git.openjdk.org/jdk/pull/11670


From avu at openjdk.org  Thu Dec 29 14:57:50 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Thu, 29 Dec 2022 14:57:50 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v4]
In-Reply-To: <s4E0bCDZWMPHuScZXBcfc5FuApSr15CuahnNuxmCadk=.e76d700e-37a7-435f-b653-e3ad33605c9e@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
 <s4E0bCDZWMPHuScZXBcfc5FuApSr15CuahnNuxmCadk=.e76d700e-37a7-435f-b653-e3ad33605c9e@github.com>
Message-ID: <xK_m5T0R84q5aOn4wtwYdpE858K5qKs2fU_8kX0Kp0s=.f2da406d-9f23-4716-b6fd-80c7ca374b67@github.com>

On Thu, 29 Dec 2022 14:23:40 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> [OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.
>
> Artem Semenov 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 master
>  - update accessor
>  - Please split the long lines to have 80 chars per line.
>  - 8298644 JNI call of getCurrentComponent on a wrong thread

Looks good for me

-------------

Marked as reviewed by avu (Committer).

PR: https://git.openjdk.org/jdk/pull/11670


From asemenov at openjdk.org  Thu Dec 29 16:02:29 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 29 Dec 2022 16:02:29 GMT
Subject: RFR: 8299412 JNI call of getAccessibleActionCount on a wrong thread
Message-ID: <qZquaGznBhIRJMHMZ0mjEeg26LrwgnIyUOW9vkmr0vQ=.4b4f82ac-beea-4d45-8f0e-7c552844e80b@github.com>

[CommonComponentAccessibility getActionsWithEnv:] defines the getAccessibleActionCount method on the AccessibleAction class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

@azuev-java @mrserb @prrace please review

-------------

Commit messages:
 - 8299412 JNI call of getAccessibleActionCount on a wrong thread

Changes: https://git.openjdk.org/jdk/pull/11803/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11803&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299412
  Stats: 16 lines in 2 files changed: 11 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11803.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11803/head:pull/11803

PR: https://git.openjdk.org/jdk/pull/11803


From duke at openjdk.org  Thu Dec 29 19:42:49 2022
From: duke at openjdk.org (SWinxy)
Date: Thu, 29 Dec 2022 19:42:49 GMT
Subject: RFR: 8299412 JNI call of getAccessibleActionCount on a wrong
 thread
In-Reply-To: <qZquaGznBhIRJMHMZ0mjEeg26LrwgnIyUOW9vkmr0vQ=.4b4f82ac-beea-4d45-8f0e-7c552844e80b@github.com>
References: <qZquaGznBhIRJMHMZ0mjEeg26LrwgnIyUOW9vkmr0vQ=.4b4f82ac-beea-4d45-8f0e-7c552844e80b@github.com>
Message-ID: <F50v1J18Ox-Cei-1Z6lu3iDvGgMffvsin47hIORnPOc=.a77b5859-47f5-4354-a45e-eca81aa47fa3@github.com>

On Thu, 29 Dec 2022 15:54:43 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> [CommonComponentAccessibility getActionsWithEnv:] defines the getAccessibleActionCount method on the AccessibleAction class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.
> 
> @azuev-java @mrserb @prrace please review

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 530:

> 528:                 return aa.getAccessibleActionCount();
> 529:             }
> 530:         }, c);

There's a more compact way of doing this:
Suggestion:

        return invokeAndWait(aa::getAccessibleActionCount, c);

-------------

PR: https://git.openjdk.org/jdk/pull/11803


From asemenov at openjdk.org  Thu Dec 29 20:41:04 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 29 Dec 2022 20:41:04 GMT
Subject: RFR: 8299412 JNI call of getAccessibleActionCount on a wrong
 thread [v2]
In-Reply-To: <qZquaGznBhIRJMHMZ0mjEeg26LrwgnIyUOW9vkmr0vQ=.4b4f82ac-beea-4d45-8f0e-7c552844e80b@github.com>
References: <qZquaGznBhIRJMHMZ0mjEeg26LrwgnIyUOW9vkmr0vQ=.4b4f82ac-beea-4d45-8f0e-7c552844e80b@github.com>
Message-ID: <V021dlf9P3wKJrijtcLHYZFw5baJsO9VMnG3Cnuv4NM=.254a5b3b-c542-4ea1-9a76-936c3c5beb1d@github.com>

> [CommonComponentAccessibility getActionsWithEnv:] defines the getAccessibleActionCount method on the AccessibleAction class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.
> 
> @azuev-java @mrserb @prrace please review

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  There's a more compact way of doing this:

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11803/files
  - new: https://git.openjdk.org/jdk/pull/11803/files/a28dcb75..32c70b7e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11803&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11803&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11803.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11803/head:pull/11803

PR: https://git.openjdk.org/jdk/pull/11803


From asemenov at openjdk.org  Thu Dec 29 20:41:05 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 29 Dec 2022 20:41:05 GMT
Subject: RFR: 8299412 JNI call of getAccessibleActionCount on a wrong
 thread [v2]
In-Reply-To: <F50v1J18Ox-Cei-1Z6lu3iDvGgMffvsin47hIORnPOc=.a77b5859-47f5-4354-a45e-eca81aa47fa3@github.com>
References: <qZquaGznBhIRJMHMZ0mjEeg26LrwgnIyUOW9vkmr0vQ=.4b4f82ac-beea-4d45-8f0e-7c552844e80b@github.com>
 <F50v1J18Ox-Cei-1Z6lu3iDvGgMffvsin47hIORnPOc=.a77b5859-47f5-4354-a45e-eca81aa47fa3@github.com>
Message-ID: <OftY8GGuXqwb26YlELhEq7loPodf243cWnPkx8F8iJQ=.a43b8f32-675b-41d9-98c6-b9f2e234c500@github.com>

On Thu, 29 Dec 2022 19:40:17 GMT, SWinxy <duke at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   There's a more compact way of doing this:
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 530:
> 
>> 528:                 return aa.getAccessibleActionCount();
>> 529:             }
>> 530:         }, c);
> 
> There's a more compact way of doing this:
> Suggestion:
> 
>         return invokeAndWait(aa::getAccessibleActionCount, c);

Done

-------------

PR: https://git.openjdk.org/jdk/pull/11803


From duke at openjdk.org  Thu Dec 29 20:44:50 2022
From: duke at openjdk.org (SWinxy)
Date: Thu, 29 Dec 2022 20:44:50 GMT
Subject: RFR: 8299412 JNI call of getAccessibleActionCount on a wrong
 thread [v2]
In-Reply-To: <V021dlf9P3wKJrijtcLHYZFw5baJsO9VMnG3Cnuv4NM=.254a5b3b-c542-4ea1-9a76-936c3c5beb1d@github.com>
References: <qZquaGznBhIRJMHMZ0mjEeg26LrwgnIyUOW9vkmr0vQ=.4b4f82ac-beea-4d45-8f0e-7c552844e80b@github.com>
 <V021dlf9P3wKJrijtcLHYZFw5baJsO9VMnG3Cnuv4NM=.254a5b3b-c542-4ea1-9a76-936c3c5beb1d@github.com>
Message-ID: <dtipwE365M2EJJVi5j8r5xpAr5pGDXsMW6pWZSiLNrA=.6d06a676-a194-47e0-b9af-c658c9c3a1ba@github.com>

On Thu, 29 Dec 2022 20:41:04 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> [CommonComponentAccessibility getActionsWithEnv:] defines the getAccessibleActionCount method on the AccessibleAction class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.
>> 
>> @azuev-java @mrserb @prrace please review
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   There's a more compact way of doing this:

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/11803


From serb at openjdk.org  Thu Dec 29 20:56:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 29 Dec 2022 20:56:51 GMT
Subject: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread
 [v4]
In-Reply-To: <s4E0bCDZWMPHuScZXBcfc5FuApSr15CuahnNuxmCadk=.e76d700e-37a7-435f-b653-e3ad33605c9e@github.com>
References: <hDaexTcjX1xMyhdzxNWYctqpcCpLx_Et9V7Gw1gtdHo=.5c7ac1d1-7003-454a-84c8-941f6bcb23e0@github.com>
 <s4E0bCDZWMPHuScZXBcfc5FuApSr15CuahnNuxmCadk=.e76d700e-37a7-435f-b653-e3ad33605c9e@github.com>
Message-ID: <XoDoq-4eSMowk20xUz1W8tUDmEwi1oV02WbS_WKROAo=.449ad8d9-b852-49f7-a9a8-a4236e5d1210@github.com>

On Thu, 29 Dec 2022 14:23:40 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> [OutlineRowAccessibility currentAccessibleWithENV:] defines the getCurrentComponent method on the AccessibleContext instance of AccessibleJTreeNode class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.
>
> Artem Semenov 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 master
>  - update accessor
>  - Please split the long lines to have 80 chars per line.
>  - 8298644 JNI call of getCurrentComponent on a wrong thread

src/java.desktop/share/classes/sun/swing/SwingAccessor.java line 60:

> 58: 
> 59:     public static AccessibleComponentAccessor getAccessibleComponentAccessor() {
> 60:         return accessibleComponentAccessor;

It is better to force the "ensureClassInitialized" as any other getters in this class. To make sure the field is up-to-date even if it was initialized on another thread.

src/java.desktop/share/classes/sun/swing/SwingAccessor.java line 71:

> 69:      * For example, the renderer of a list element, a table cell, or a tree node
> 70:      */
> 71:     public interface AccessibleComponentAccessor {

Note that this class declares interfaces at the top, and then field/get/set at the bottom of the file.

-------------

PR: https://git.openjdk.org/jdk/pull/11670


From mik3hall at gmail.com  Fri Dec 30 01:34:48 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 29 Dec 2022 19:34:48 -0600
Subject: OS/X GUI applications
In-Reply-To: <CAMZMqONG43rUAKeZaRPg0zzge8QnHrv0wD4YDrjGzvm1w07SoQ@mail.gmail.com>
References: <CA1D7F10-343A-4052-8E35-D21C32F9719B@gmail.com>
 <CAPRuVTVjNc262tiRHP71iHcR+_oAspdFzRdHA0icZ_qthH+tDg@mail.gmail.com>
 <CAMZMqONG43rUAKeZaRPg0zzge8QnHrv0wD4YDrjGzvm1w07SoQ@mail.gmail.com>
Message-ID: <4E9D3135-2255-4146-B3C1-5E38B7C84942@gmail.com>



> On Dec 28, 2022, at 9:51 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> Mail.app not receiving for some reason. So from gmail in Safari.
> 
> >The Apple system properties are going to remain as they are, unless e.g. there's some good reason to change the key of a property.
> 
> OK, good to know. I'm pretty sure -Dapple.laf.useScreenMenuBar=true was made the OS/X application default. I thought some of the other old property functionality had been incorporated in some way or other but might be mistaken.
> 
> >Afaik setAboutHandler is the only way to set such a callback. 
> 
> There seems to be some other way because I don't find anywhere I use this. I eliminated all Apple system properties but still get an About... It seems you are correct that eliminating the about.name <http://about.name/> appears to have no impact. Eliminating -Dapple.awt.application.name <http://dapple.awt.application.name/>=HalfPipe and the About menu item no longer shows the application name but rather the unpackaged main class name. The About window is still correct. It includes the application icon, the application name (valid) in bold. Also, Version and Copyright it appears to get from the application Info.plist. Rather a nice default. I could post a screen shot somewhere? Possibly something has been cached for the app by Apple from some time ago? Or I still need to figure out where this comes from. 
> 
> >Ask the JavaFX mailing list for supporting an About handler if they don't already have it; I believe their mailing list is openjfx-dev at openjdk.org <mailto:openjfx-dev at openjdk.org>
> 
> OK, this part of the support would be split. Thanks.
> 

Fwiw, I did a little more looking at this.

It seems this?

_AppEventHandler
openCocoaAboutWindow(); // if the handler is null, fall back to showing the Cocoa default

Is what gets the default window that I am seeing.

It would then almost seem like a javaFX application could do something like?
static {
		java.awt.Desktop.getDesktop().setAboutHandler(null);
	}

Might work but it doesn?t.

You can?t compile directly against com.apple.eawt anymore?
JDK-8160437 : com.apple.eawt.Application is not exported

So I don;t know if that could work-around.

I might wonder if it would be easier for the jdk side to get the Desktop invocation to work rather than javaFX rework all that Apple and the jdk already has done from scratch?

But currently there appears to be no way to include this functionality for a javaFX app. 

Although, I haven?t asked on the javaFX list. Maybe they already figured all this out

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221229/a0e30808/attachment.htm>

From duke at openjdk.org  Fri Dec 30 06:13:01 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 30 Dec 2022 06:13:01 GMT
Subject: RFR: 8299337: The java.awt.image.ColorModel#pData field is unused
In-Reply-To: <33MoUulwjlpaM_-aqninKh8mPXBN0-rKAacsfZ6OUF8=.957b42a7-73c1-4c0c-9ad1-74d0ed76c46b@github.com>
References: <33MoUulwjlpaM_-aqninKh8mPXBN0-rKAacsfZ6OUF8=.957b42a7-73c1-4c0c-9ad1-74d0ed76c46b@github.com>
Message-ID: <WhFFPu1aVgNSxQGQtTYbqdDT3RtKMKRHa9vfCQiJwuU=.41a5ae9a-2335-4a23-a150-73bc2adf925e@github.com>

On Sat, 24 Dec 2022 03:49:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I have found that we store the native pointer in the "java.awt.image.ColorModel#pData" field and never update/clean it. We can check how and when the native data is deallocated and reset the pointer, but it will be easy just to delete the field as unused.

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/11785


From serb at openjdk.org  Fri Dec 30 06:31:37 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 30 Dec 2022 06:31:37 GMT
Subject: RFR: 8272288: Funky multiresolution image breaks graphics context
Message-ID: <v6GtuWIiXG4SzSCdmVGlwdf0hEEVHrZureMEm5NqcUE=.e5d62f8b-6a2f-429e-923a-1c05385f69ac@github.com>

This is the next iteration of fixing the issue of rendering "broken" image. The fix for [JDK-7183828](https://bugs.openjdk.org/browse/JDK-7183828) changed the possible IllegalArgumentException during rendering to the InvalidPipeException in assumtion that the new exception will be catched by the java2d machinery and the current-accelerated pipeline will be invalidated and software-pipeline will take care about that image.

But that change uncover another bug, the accelerated-pipeline invalidation by the InvalidPipeException works in D3D pipeline only, other pipelines start to use software based surfaces, but do not report about that the client code, as a result the next code does not work as expected, since contentsLost alwys return false:

        do {
            vi.validate(gc);
            Graphics2D g = vi.createGraphics();
            g.fillRect(0, 0, vi.getWidth(), vi.getHeight());
            g.dispose();
        } while (vi.contentsLost());

After this change the correct value will be reported by the contentsLost(), so the RepaintManager will be able to catch that.
But this fix uncovered another bug. That fallback code path in the RepaintManager was not tested on HiDPI screen and does not work well. I'll file a separate bug about that.

-------------

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into JDK-8272288
 - 8272288: Funky multiresolution image breaks graphics context

Changes: https://git.openjdk.org/jdk/pull/11664/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11664&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8272288
  Stats: 157 lines in 3 files changed: 143 ins; 12 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11664.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11664/head:pull/11664

PR: https://git.openjdk.org/jdk/pull/11664


From djelinski at openjdk.org  Fri Dec 30 06:43:52 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 30 Dec 2022 06:43:52 GMT
Subject: Integrated: 8299260: libawt and libfreetype should export only
 explicitly requested symbols
In-Reply-To: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
References: <IWUBLmJ69TgRxFiiCKWcD_YvVwpwB-JLCFy5ASouids=.5a0c0f90-d864-479b-8aa8-e6fb4c596b1d@github.com>
Message-ID: <a-YKsx0eo7IWKE2qwMXM1smILEA-YYXWpE1JOLfzmvg=.d7f253a7-b776-47af-b4fa-087ab94e6049@github.com>

On Tue, 20 Dec 2022 18:59:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes unnecessary exports from libawt and libfreetype.
> 
> Verified that:
> - mach5 client libs tests pass
> - both release and debug builds finish successfully

This pull request has now been integrated.

Changeset: 684e5069
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/684e50690c54fb93cb411553a8798cce041faac9
Stats:     9 lines in 2 files changed: 0 ins; 8 del; 1 mod

8299260: libawt and libfreetype should export only explicitly requested symbols

Reviewed-by: prr, aivanov, serb

-------------

PR: https://git.openjdk.org/jdk/pull/11742


From serb at openjdk.org  Fri Dec 30 06:56:48 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 30 Dec 2022 06:56:48 GMT
Subject: RFR: 8299412 JNI call of getAccessibleActionCount on a wrong
 thread [v2]
In-Reply-To: <V021dlf9P3wKJrijtcLHYZFw5baJsO9VMnG3Cnuv4NM=.254a5b3b-c542-4ea1-9a76-936c3c5beb1d@github.com>
References: <qZquaGznBhIRJMHMZ0mjEeg26LrwgnIyUOW9vkmr0vQ=.4b4f82ac-beea-4d45-8f0e-7c552844e80b@github.com>
 <V021dlf9P3wKJrijtcLHYZFw5baJsO9VMnG3Cnuv4NM=.254a5b3b-c542-4ea1-9a76-936c3c5beb1d@github.com>
Message-ID: <JfhakyBmut0SFSCpDIZZ5X9RFUp9A7ZrKhKz_ZbKlGE=.33fe1caf-8b16-49bf-9881-8ef0599d14e3@github.com>

On Thu, 29 Dec 2022 20:41:04 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> [CommonComponentAccessibility getActionsWithEnv:] defines the getAccessibleActionCount method on the AccessibleAction class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.
>> 
>> @azuev-java @mrserb @prrace please review
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   There's a more compact way of doing this:

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 605:

> 603:         DECLARE_STATIC_METHOD(jm_getAccessibleActionCount, sjc_CAccessibility, "getAccessibleActionCount", "(Ljavax/accessibility/AccessibleAction;Ljava/awt/Component;)I");
> 604:         jint count = (*env)->CallStaticIntMethod(env, sjc_CAccessibility, jm_getAccessibleActionCount, axAction, fComponent);
> 605:         CHECK_EXCEPTION();

Do we need to call "(*env)->DeleteLocalRef(env, axAction);" in case of error in CHECK_EXCEPTION?

-------------

PR: https://git.openjdk.org/jdk/pull/11803


From serb at openjdk.org  Fri Dec 30 07:22:21 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 30 Dec 2022 07:22:21 GMT
Subject: RFR: 8298240: Replace the usage of ImageLayoutException by the
 CMMException [v2]
In-Reply-To: <MugzKoEie2il8Rn7Tp4oLM0N8zg-QtGh1gsQmPPX-lE=.66e63bba-76ef-4425-8aa6-6a2350d77c24@github.com>
References: <MugzKoEie2il8Rn7Tp4oLM0N8zg-QtGh1gsQmPPX-lE=.66e63bba-76ef-4425-8aa6-6a2350d77c24@github.com>
Message-ID: <Al4VrMYfp2BWmJr-fOhXBd95NZTOxuCrnpDipj28Xg4=.fb982ce5-c96a-4dba-a7c7-542a3d13c0d2@github.com>

> ImageLayoutException is used to report any issues with image layout calculation. But since we cannot throw the unspecified exception to the application, all usages of ImageLayoutException are wrapped by the CMMException. And now if such CMMException occurs we have lost at what point the initial exception was raised.
> 
> We can pass some additional data around, but it looks like we can just delete the ImageLayoutException and use CMMException instead. 
> 
> Additionally:
>  * The `public` keyword is removed in a few places if not needed.
>  * The PT_XX flags are updated to make it clearly visible how they are related.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into delete_imagelayout
 - Simplify rge PT_XXX and replace public
 - delete ImageLayoutException

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11552/files
  - new: https://git.openjdk.org/jdk/pull/11552/files/146b1c36..4ce75894

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11552&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11552&range=00-01

  Stats: 76972 lines in 1730 files changed: 43211 ins; 24519 del; 9242 mod
  Patch: https://git.openjdk.org/jdk/pull/11552.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11552/head:pull/11552

PR: https://git.openjdk.org/jdk/pull/11552


From duke at openjdk.org  Fri Dec 30 08:39:58 2022
From: duke at openjdk.org (duke)
Date: Fri, 30 Dec 2022 08:39:58 GMT
Subject: Withdrawn: JDK-4305789: BasicToolBarUI: Request conversion of private
 instance variable
In-Reply-To: <N5UboF5_zFk9rHep_NHX3W2BOQS_VLVRFCPJogIEbuE=.abf3564e-c68f-42a1-b053-dfa0859fac52@github.com>
References: <N5UboF5_zFk9rHep_NHX3W2BOQS_VLVRFCPJogIEbuE=.abf3564e-c68f-42a1-b053-dfa0859fac52@github.com>
Message-ID: <BcuAZdvTXKMWzGdJFU3Jlf266set-Vek5C8bBUJKTIc=.d97dabfe-b17d-4dab-9447-6be8304d377e@github.com>

On Fri, 16 Sep 2022 13:47:41 GMT, aLiEnHeAd13 <duke at openjdk.org> wrote:

> Fixed Bug JDK-4305789 to support docking to any instantiated JFrame https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4305789

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10309


From alexsch at openjdk.org  Fri Dec 30 10:01:50 2022
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Fri, 30 Dec 2022 10:01:50 GMT
Subject: RFR: 8298266: "java.home property not set" error in Graal when
 sun.awt.fontconfig java property is set on Windows [v2]
In-Reply-To: <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
References: <Y2il7H-nJzWsFmPEP4WTXdfWhmIMR54qHWVLtrZv66g=.5ee1399a-1f8a-4b2c-b0f6-861fd4d2c0ce@github.com>
 <93q2xIfhU-PV31dl5-8Nim8oFtH1of1ICvS7tu01oZI=.81702f75-341b-4dbe-8247-911756326441@github.com>
Message-ID: <F4SV412DqkLOauA5TcpfgkjLCjQWNce8GJpCYNtSr4Y=.40302da7-f9e1-4f2f-a239-37d85ea03189@github.com>

On Thu, 22 Dec 2022 10:57:15 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> **Environment**: 
>> GraalVM 22.3.0 with  jdk 19, Windows OS.
>> 
>> **Description**:
>> Create a native image of Swing application using GraalVM and run it with ` -Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> `java.lang.Error: java.home property not set` error is thrown.
>> 
>> For more details see https://github.com/oracle/graal/issues/4875.
>> 
>> **Solution**:
>> The error is thrown by the code from [FontConfiguration.findFontConfigFile()](https://github.com/openjdk/jdk19u/blob/c9d485792b99233f381dcdfd69838e7b973909bd/src/java.desktop/share/classes/sun/awt/FontConfiguration.java#L175) method.
>> GraalVM does not set `java.home`  property, that is why the `java.lang.Error: java.home property not set` is thrown.
>> `FontConfiguration.findFontConfigFile()` method compares `java.home` property to null before checking user provided `sun.awt.fontconfig` java property.
>> 
>> The proposed fix swaps the order of `java.home` and `sun.awt.fontconfig` properties checking to avoid using `java.home` property in case `sun.awt.fontconfig` is set.
>> 
>> 
>> **Steps to reproduce**:
>> - Download graal 22.3.0 jdk 19 for Windows from [GraalVM Community Edition 22.3.0](https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0) page.
>> - Install native-image
>> 
>> graalvm-ce-java19-22.3.0\bin\gu.cmd install native-image
>> 
>> - Create and compile `SwingSample.java` sample
>> 
>> import java.awt.*;
>> import javax.swing.*;
>> 
>> public class SwingSample {
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeAndWait(() -> {
>> 
>>             JFrame frame = new JFrame("Hello World");
>> 
>>             JButton button = new JButton("Hello");
>>             button.addActionListener(e -> {
>>                 System.out.printf("Hello, World!%n");
>>             });
>> 
>>             JPanel panel = new JPanel(new FlowLayout());
>>             panel.add(button);
>> 
>>             frame.add(panel);
>>             frame.setSize(400, 300);
>>             frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>             frame.setVisible(true);
>>         });
>>     }
>> }
>> 
>> - Run native-image-agent to generate configuration files
>> 
>> graalvm-ce-java19-22.3.0\bin\java.cmd -agentlib:native-image-agent=config-output-dir=conf-dir SwingSample
>> 
>> - Copy `graalvm-ce-java19-22.3.0\lib\fontconfig.properties.src` file to the sample dir
>> - Generate native image with configuration files and `-Djava.awt.headless=false `, `-Dsun.awt.fontconfig=fontconfig.properties.src` java properties
>> 
>> call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64"
>> graalvm-ce-java19-22.3.0\bin\native-image.cmd --no-fallback -Djava.awt.headless=false -Dsun.awt.fontconfig=fontconfig.properties.src -H:ResourceConfigurationFiles=conf-dir/resource-config.json -H:SerializationConfigurationFiles=conf-dir/serialization-config.json -H:ReflectionConfigurationFiles=conf-dir/reflect-config.json -H:JNIConfigurationFiles=conf-dir/jni-config.json SwingSample
>> 
>> - Run the native image with `-Dsun.awt.fontconfig=fontconfig.properties.src` java property.
>> 
>> swingsample.exe  -Dsun.awt.fontconfig=fontconfig.properties.src
>> 
>> Exception in thread "main" java.lang.reflect.InvocationTargetException
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371)
>>         at java.desktop at 19.0.1/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346)
>>         at java.desktop at 19.0.1/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480)
>>         at SwingSample.main(SwingSample.java:7)
>> Caused by: java.lang.Error: java.home property not set
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
>>         at java.desktop at 19.0.1/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
>>         at java.desktop at 19.0.1/sun.awt.windows.WFontConfiguration.<init>(WFontConfiguration.java:41)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize javaLib when a user fontconfig file is set

Graal uses a substitutor which replaces [FontConfiguration.findFontConfigFile()](https://github.com/oracle/graal/blob/b6e1c8d0844c475c97ad7ef52796b192b59ef2fc/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/JavaAWTSubstitutions.java#L99
) method to empty on Linux.
This does not work on Windows because it requires to read logical fonts from fontconfig.properties file.

The idea of the fix was to allow to use `sun.awt.fontconfig` property in Graal.
If  `sun.awt.fontconfig` property is not a supported documented property then may be it is better to put the fontconfig.properties file as a resource during a native image generation and read it when the application is executed.

-------------

PR: https://git.openjdk.org/jdk/pull/11559


From serb at openjdk.org  Fri Dec 30 11:23:52 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 30 Dec 2022 11:23:52 GMT
Subject: RFR: 4912623: GTK L&F: Folder list of the JFileChooser is allowing
 multiple selection unlike native [v4]
In-Reply-To: <xOcpuZQvcZc3HECZZCAIHWZd5zi0KqbvAMLQaLILG7E=.fe7ca755-acac-43d6-8946-1e8618105192@github.com>
References: <AdQ8W2uwg_x1PuYuMakbsEL7fgcRGDQdt_cMZqUlKTk=.2fba28b8-0260-498b-906f-c10b31323fb5@github.com>
 <xOcpuZQvcZc3HECZZCAIHWZd5zi0KqbvAMLQaLILG7E=.fe7ca755-acac-43d6-8946-1e8618105192@github.com>
Message-ID: <8SVvDkkvKjlEqOK_MIgDDsh29l3iY6p92JsvJCuFReE=.4c24afbd-1656-428e-93ca-4e4fc9cec3b6@github.com>

On Thu, 15 Dec 2022 06:47:33 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> It is not possible to select all files on press of Ctrl+A in JFileChooser for GTK LAF where as all folders can be selected. 
>> In native side on press of Ctrl+A, able to select all files as well as folders.
>> 
>> Proposed fix is to enable `multiselection `property by default for JFileChooser in GTK LAF to mimic native side behavior.
>> 
>> An automated test case is implemented and tested in CI. CI job links are attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11627


From serb at openjdk.org  Sat Dec 31 21:41:29 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 31 Dec 2022 21:41:29 GMT
Subject: RFR: 8299425: "LCMSImageLayout.isIntPacked" flag can be deleted
Message-ID: <B5ZZeBPytgniy6zooDsWftJJG0_Q6qMH3sg_8OHUTM4=.b132ad52-56ff-4b88-89c5-2bb55b3d7356@github.com>

After this change we will set correct pixel formatter when we initially create it, instead of updating the pixel formatter in native based on additional "isIntPacked" flag.

FYI: The fix for https://bugs.openjdk.org/browse/JDK-7124245 added the "isIntPacked" flag to mark the non-byte pixels layouts(like TYPE_INT_RGB).
* This flag is passed around even if it is not used by the pixel layout
* It may cause unnecessary creation of new transform if one type is "rgb && isIntPacked=true" and another one is "bgr && isIntPacked=false", but the actual data is the same
see: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/2cf07dbdee64

-------------

Commit messages:
 - JDK-8299425: "LCMSImageLayout.isIntPacked" flag can be deleted

Changes: https://git.openjdk.org/jdk/pull/11806/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11806&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299425
  Stats: 48 lines in 4 files changed: 5 ins; 28 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/11806.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11806/head:pull/11806

PR: https://git.openjdk.org/jdk/pull/11806


From mik3hall at gmail.com  Sat Dec 31 22:47:06 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 31 Dec 2022 16:47:06 -0600
Subject: OS/X GUI applications
In-Reply-To: <4E9D3135-2255-4146-B3C1-5E38B7C84942@gmail.com>
References: <CA1D7F10-343A-4052-8E35-D21C32F9719B@gmail.com>
 <CAPRuVTVjNc262tiRHP71iHcR+_oAspdFzRdHA0icZ_qthH+tDg@mail.gmail.com>
 <CAMZMqONG43rUAKeZaRPg0zzge8QnHrv0wD4YDrjGzvm1w07SoQ@mail.gmail.com>
 <4E9D3135-2255-4146-B3C1-5E38B7C84942@gmail.com>
Message-ID: <5471F0B5-2DEE-4FED-A0BD-849CE0FE69C3@gmail.com>

> 
> Fwiw, I did a little more looking at this.
> 

Additionally FWIW, I tracked the handling through on this and it all looked good. I entered a null dispatch at the end and got the dialog fine for a javaFX app.

The problem is simply that the About menu item is never added for javaFX app?s.

In ApplicationDelegate?
NSLog(@"ApplicationDelegate init fAboutMenu %@", self.fAboutMenu);

Gets...
2022-12-31 16:13:30.892 HelloWorld[42268:1553617] ApplicationDelegate init fAboutMenu <NSMenuItem: 0x60000172abc0 Hide HelloWorld, ke='Command-H?>

Showing the About menu item is assumed there at this point but it isn?t, fAboutMenu is instead the Hide item. It manages to run fine while being wrong about this, although this seems a bug already with this bad assumption.

There are places where it suggests on occasion a default menu bar is installed. I?m thinking possibly for some reason it decides to do this for javaFX apps and it is without the About item?
Other places it seems to decide whether or not to use a default nib, might factor in. I?m not that familiar with any of this. 

Right now I?m having problems backtracking to where the menu?s are initially handled, I?m not hitting any of my additional sophisticated println and NSLog debugging for some reason.

I will probably keep looking but would appreciate it if anyone has any suggestions where that looking should be done. 

Otherwise, I would say only the jdk is involved at this point so it would be a bug on that side, not javaFX. If you want to just go ahead and call it that I guess I can leave it at that.