From kcr at openjdk.org  Thu May  1 17:24:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 May 2025 17:24:47 GMT
Subject: RFR: 8332947: [macos] java.awt.desktop.OpenURIHandler is not
 receiving events [v5]
In-Reply-To: <KcCJhJHXrOYdZCXdk3HcxvGoy6_SV4mAUeaE9qpbWsw=.0b64ca48-4182-4c0d-8e8f-47f5bcaeea3a@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <fqKmOzkrPk_XWcxB5WkUgsjBAGuwRRQBDWH6h_kTAEs=.8deacfe8-f565-4ac1-8810-dc687d4ef0de@github.com>
 <KcCJhJHXrOYdZCXdk3HcxvGoy6_SV4mAUeaE9qpbWsw=.0b64ca48-4182-4c0d-8e8f-47f5bcaeea3a@github.com>
Message-ID: <Z6NShw-Dhq2Wsv-5dGaLvd0swcr6XiSeYiMR36akZ1c=.50647876-688f-4a7b-84ef-3e300328a554@github.com>

On Tue, 29 Apr 2025 22:44:22 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> Answer to question 2:
> 
> I found the issue and moved the registration of the embedded event handler up. This way the embedded events can be received, even if AWT runs embedded.

With this latest update, I can see how this will work; and the log output you provided shows that it wouldn't have in the original form.

We'll review the proposed solution when we can.

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

PR Comment: https://git.openjdk.org/jdk/pull/24379#issuecomment-2845301517

From honkar at openjdk.org  Thu May  1 18:40:49 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 1 May 2025 18:40:49 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
Message-ID: <x26P1dF0sDRl4o9-uvv6-yq6j4yKWU8bBqiow0oBKjI=.23b0c02b-4b8a-4586-a185-93ffdebfd010@github.com>

On Mon, 17 Feb 2025 14:06:53 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
> 
> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
> 
> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
> 
> The new test class passes on Linux, Windows and macOS.

@gredler Tested your fix by applying your changes on top of harfbuzz upgrade - https://github.com/openjdk/jdk/pull/24973 . Initial testing of your fix with IgnoredWhitespaceTest.java test and NLGlyphTest.java looks good. I haven't done a full fledged testing yet.

This PR fixes the same issue observed on another test - `java/awt/font/TextLayout/TestControls.java` - [JDK-8353187](https://bugs.openjdk.org/browse/JDK-8353187). You can link the additional JBS ID to this PR with `/issue add 8353187`

I will be integrating harfbuzz upgrade PR soon after which you can sync your branch with mainline to test it on your end.

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

PR Review: https://git.openjdk.org/jdk/pull/23665#pullrequestreview-2810426871

From dgredler at openjdk.org  Thu May  1 19:09:47 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 1 May 2025 19:09:47 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <5mfWz8FHdIhs-j2Hn6q9NwomFhabKffMB9omJfE9phw=.d50f285c-32f4-4f8e-a428-98d3a8680e65@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <kuNH9v93_J7TolEW5t-QZRGnoimeuIsaAgo7uKGsEtA=.f7e097d7-acc9-4560-91d4-2e73a8c1f5fb@github.com>
 <qG0fq0vBXnnhmo2k8P4umvGZ0q_4p8ty1YAfTUMiiXk=.44626ae2-a5a6-45cb-9447-16ca8dd9f85b@github.com>
 <5mfWz8FHdIhs-j2Hn6q9NwomFhabKffMB9omJfE9phw=.d50f285c-32f4-4f8e-a428-98d3a8680e65@github.com>
Message-ID: <31Af0IbTC_NoxDcBkSSNU_57y8t1sahHY1rKDoM_Ju0=.7b18ec9c-f540-490d-92b3-b154d3e0ba72@github.com>

On Thu, 3 Apr 2025 22:12:28 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> @gredler  Yes, JDK harfbuzz was just upgraded to v10.4.0 - https://github.com/openjdk/jdk/pull/23910.
>> 
>> @prrace Do we consider patching the fix from upstream (https://github.com/harfbuzz/harfbuzz/pull/5119) for this upgrade or can it wait till the next time harfbuzz is upgraded on jdk ?
>
>> @honkar-jdk pls remember we need an updated harfbuzz for this PR to proceed.
> 
> Noted. Thank you for the reminder.

@honkar-jdk Great, thanks! I'll keep an eye on the HarfBuzz upgrade PR and sync + test once it has been integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2845524602

From dgredler at openjdk.org  Thu May  1 20:05:45 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 1 May 2025 20:05:45 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377
In-Reply-To: <uUkCO_G3zqWsdi7ps9Szvgb8hc8o4mfNLCKohS-Fl2g=.2c9fbd9e-d201-4026-aa80-eb08a0cb2f4e@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
 <uUkCO_G3zqWsdi7ps9Szvgb8hc8o4mfNLCKohS-Fl2g=.2c9fbd9e-d201-4026-aa80-eb08a0cb2f4e@github.com>
Message-ID: <G_7nhD-NCuHsBBpTGQ1K06AujshVAU5dX5xfF45oPUQ=.ed1d182f-3d5a-4018-8208-7da40fc2db10@github.com>

On Tue, 29 Apr 2025 09:55:56 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> It looks like this regression actually fits into a longer series of fixes / regressions in this area:
>> 
>> - [JDK-4517298](https://bugs.openjdk.org/browse/JDK-4517298) fixed metrics for zero-width characters, but broke some ligatures / glyph substitutions
>> - [JDK-7017058](https://bugs.openjdk.org/browse/JDK-7017058) fixed the ligatures / glyph substitutions, but broke some zero-width metrics
>> - [JDK-8208377](https://bugs.openjdk.org/browse/JDK-8208377) fixed some metrics and rendering for zero-width characters, but broke some ligatures / glyph substitutions
>> - Now, with this PR, we aim to fix the ligatures without re-breaking zero-width metrics and display
>> 
>> We have two different types of use cases pulling `CharToGlyphMapper` in two different directions: the users who need raw, untransformed glyph info, and the users who need normalized / transformed glyph info.
>> 
>> It looks to me like, in the current code base, the only `CharToGlyphMapper` user which requires raw font data is HarfBuzz (explicitly confirmed with the HarfBuzz team here: https://github.com/harfbuzz/harfbuzz/discussions/5234).
>> 
>> The regression mechanism at play here is that the HarfBuzz font callbacks are currently providing HarfBuzz with transformed glyph info (e.g. ZWJ -> INVISIBLE_GLYPH_ID), which prevents HarfBuzz from recognizing and applying the correct font GSUB substitutions (which involve ZWJ).
>> 
>> In order to fix this without (yet again) breaking metrics and display behavior elsewhere, I've added two methods to `CharToGlyphMapper` which provide access to raw glyph info, to be used by the HarfBuzz font callbacks: `charToGlyphRaw(int)` and `charToVariationGlyphRaw(int)`.
>> 
>> Note two intricacies related to `CompositeGlyphMapper`:
>> 1. We need to be careful to only cache raw (untransformed) values, to avoid conflicts between requests for a raw version of a glyph and a transformed version of the same glyph. Another option would have been two separate caches, but I don't think that's necessary.
>> 2. Consumers who are using `CompositeGlyphMapper.SLOTMASK` to check glyph slots (e.g. `FontRunIterator` and `CTextPipe`) will "see" invisible glyphs as having come from slot 0. This isn't new, and I think it's OK, but something to be aware of.
>> 
>> The glyph cache handling in `CCharToGlyphMapper` (for macOS) also requires care to avoid mixing value types.
>> 
>> Please also note that I'm not sure if the tweak to `sunFont.c` is being tested, since FFM is being used by default for Harf...
>
> By the way, I see that in each implementation, both `charToGlyph` and `charToGlyphRaw` call a common method, like `getGlyph(int uniciode, boolean raw)`. At first there was just `charToGlyph`, then `charToVariationGlyph` was added and now you added a "raw" version for each of them, I see that in the future we will need other variants and how it's already starting an exponential explosion. Overriding all of those methods in each implementation brings quite a bit of boilerplate, and it becomes easier to miss something. Maybe take a step back and refactor this into a single `charToGlyph(int unicode, int variationSelector, boolean raw)` version?
> Also, this `raw` parameter only really controls `isDefaultIgnorable` check in the end of each method. Maybe we could factor this out without bringing it separately into each mapper implementation?

@YaaZ: Thanks for the additional feedback, please see my thoughts below:

> By the way, I see that in each implementation, both charToGlyph and charToGlyphRaw call a common method, like getGlyph(int uniciode, boolean raw). At first there was just charToGlyph, then charToVariationGlyph was added and now you added a "raw" version for each of them, I see that in the future we will need other variants and how it's already starting an exponential explosion.

I don't know if I would call two changes to `CharToGlyphMapper` in 20 years an exponential explosion, but I get your point :-)

> Overriding all of those methods in each implementation brings quite a bit of boilerplate, and it becomes easier to miss something.

True, but again keep in mind that there are only 5 implementations, only one of which (the macOS `CCharToGlyphMapper`) has been added in the last 20 years.

> Maybe take a step back and refactor this into a single charToGlyph(int unicode, int variationSelector, boolean raw) version?

We'd still need separate methods for `int` vs. `char`, but I think this might reduce 5 methods down to 3? The changeset would be a bit more intrusive (lots of callers would need to change to reflect the new method signature). I'd be interested to hear thoughts from some of the reviewers on this one.

> Also, this raw parameter only really controls isDefaultIgnorable check in the end of each method. Maybe we could factor this out without bringing it separately into each mapper implementation?

I prefer to think of it as controlling whether or not any transformations to `INVISIBLE_GLYPH_ID` happen (right now it's just for default-ignorable characters, but there may be other scenarios in the future, e.g. `\r`, `\n` and `\t` which currently are handled elsewhere).

Any ideas for what this refactoring might look like?

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

PR Comment: https://git.openjdk.org/jdk/pull/24412#issuecomment-2845646011

From prr at openjdk.org  Thu May  1 20:06:45 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 May 2025 20:06:45 GMT
Subject: RFR: JDK-8355528 : Update HarfBuzz to 11.2.0
In-Reply-To: <OYvCAf8MTYtEoexbi05jUZAp1soN20wD9NIHFjIF594=.c5ea11eb-aaf8-41f1-84df-76da1b902654@github.com>
References: <OYvCAf8MTYtEoexbi05jUZAp1soN20wD9NIHFjIF594=.c5ea11eb-aaf8-41f1-84df-76da1b902654@github.com>
Message-ID: <7uJYkK2vsUG7zEUrn9jJLkD6Tu1iuIYVaHAlNGFWfV0=.d69f55f2-b7f9-42e3-b3e2-fa32fb631ccc@github.com>

On Wed, 30 Apr 2025 19:37:29 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> HarfBuzz upgraded to 11.2.0
> 
> 4 newly added files and 99 modified files.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24973#pullrequestreview-2810607371

From ngubarkov at openjdk.org  Thu May  1 21:57:45 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Thu, 1 May 2025 21:57:45 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377
In-Reply-To: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
Message-ID: <d6b4WxmTSTAL3soxfcjQZeEhteydDfd0GexPIUVedLY=.b77d056e-6d1e-463e-9cb8-c30ecabe4695@github.com>

On Thu, 3 Apr 2025 11:23:42 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> It looks like this regression actually fits into a longer series of fixes / regressions in this area:
> 
> - [JDK-4517298](https://bugs.openjdk.org/browse/JDK-4517298) fixed metrics for zero-width characters, but broke some ligatures / glyph substitutions
> - [JDK-7017058](https://bugs.openjdk.org/browse/JDK-7017058) fixed the ligatures / glyph substitutions, but broke some zero-width metrics
> - [JDK-8208377](https://bugs.openjdk.org/browse/JDK-8208377) fixed some metrics and rendering for zero-width characters, but broke some ligatures / glyph substitutions
> - Now, with this PR, we aim to fix the ligatures without re-breaking zero-width metrics and display
> 
> We have two different types of use cases pulling `CharToGlyphMapper` in two different directions: the users who need raw, untransformed glyph info, and the users who need normalized / transformed glyph info.
> 
> It looks to me like, in the current code base, the only `CharToGlyphMapper` user which requires raw font data is HarfBuzz (explicitly confirmed with the HarfBuzz team here: https://github.com/harfbuzz/harfbuzz/discussions/5234).
> 
> The regression mechanism at play here is that the HarfBuzz font callbacks are currently providing HarfBuzz with transformed glyph info (e.g. ZWJ -> INVISIBLE_GLYPH_ID), which prevents HarfBuzz from recognizing and applying the correct font GSUB substitutions (which involve ZWJ).
> 
> In order to fix this without (yet again) breaking metrics and display behavior elsewhere, I've added two methods to `CharToGlyphMapper` which provide access to raw glyph info, to be used by the HarfBuzz font callbacks: `charToGlyphRaw(int)` and `charToVariationGlyphRaw(int)`.
> 
> Note two intricacies related to `CompositeGlyphMapper`:
> 1. We need to be careful to only cache raw (untransformed) values, to avoid conflicts between requests for a raw version of a glyph and a transformed version of the same glyph. Another option would have been two separate caches, but I don't think that's necessary.
> 2. Consumers who are using `CompositeGlyphMapper.SLOTMASK` to check glyph slots (e.g. `FontRunIterator` and `CTextPipe`) will "see" invisible glyphs as having come from slot 0. This isn't new, and I think it's OK, but something to be aware of.
> 
> The glyph cache handling in `CCharToGlyphMapper` (for macOS) also requires care to avoid mixing value types.
> 
> Please also note that I'm not sure if the tweak to `sunFont.c` is being tested, since FFM is being used by default for HarfBuzz integration. (Is there a plan to remove...

I was talking about the explosion because there is a scenario in my mind, which I didn't make clear for everybody else. There is a change which I didn't have time to contribute, but would like to: it's related to composite fonts and variation selectors. We may need 2 variants for retrieving a glyph with a variation selector - one strictly matching a variation selector and another with a fallback to the base glyph, multiplied by raw/transformed versions, which adds 2 more methods. Not like it's a big problem, but given that they all end up calling a single method anyway... You get the point.

> there may be other scenarios in the future, e.g. \r, \n and \t which currently are handled elsewhere).

Are those scenarios specific to a patricular mapper/font type? I was thinking that those transformations are generic.

> Any ideas for what this refactoring might look like?

I was thinking about moving this default-ignorable or any potential generic transformation into base `CharToGlyphMapper` or even `Font2D`. For example, make default implementation of `CharToGlyphMapper.charToGlyph` check ignorable characters and then call `charToGlyphRaw` - then other implementations would only need to override `charToGlyphRaw`.

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

PR Comment: https://git.openjdk.org/jdk/pull/24412#issuecomment-2845865987

From serb at openjdk.org  Thu May  1 22:12:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 1 May 2025 22:12:02 GMT
Subject: RFR: 8355790: Enhance code consistency: java.desktop/unix:sun.awt
Message-ID: <7s8jC8r-uAS3k0NsaKJyhZMzhHVCOFbb-ZStbeBv9Pw=.b78af72d-c17f-4c57-b620-6a630a2aef80@github.com>

The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency.

To make the code review process easier I have made the following changes:

1. I chose `java.desktop/unix:sun.awt` as the starting package because it contains a relatively small number of classes
2. The public API was not affected so there is no need to worry about a CSR

Note: I will submit additional patches in this area later because:

1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797))
2. I skipped adding `@Override` for anonymous classes

Any feedback or suggestions are welcome!

Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/24941.diff) to a simple diff file, it might be more convenient for reviewing the changes.

To download the diff file and filter only the modified lines you can use the following script:


curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/24941.diff -o d.txt && grep -E '^+|^-' d.txt


The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected by these changes. It would be good to verify this by mach5 to ensure everything works as expected.

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

Commit messages:
 - override in java.desktop/unix:sun.awt
 - final in java.desktop/unix:sun.awt

Changes: https://git.openjdk.org/jdk/pull/24941/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24941&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355790
  Stats: 748 lines in 105 files changed: 646 ins; 1 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/24941.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24941/head:pull/24941

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

From prr at openjdk.org  Thu May  1 22:41:30 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 May 2025 22:41:30 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip
Message-ID: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>

A simple API to replace java.applet.AudioClip

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

Commit messages:
 - 8356049
 - 8356049

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

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

From mvs at openjdk.org  Fri May  2 09:29:46 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Fri, 2 May 2025 09:29:46 GMT
Subject: RFR: 8288471: java/awt/ScrollPane/bug8077409Test.java is unstable
 and fails intermittently in CI [v4]
In-Reply-To: <ujMNwdynb2P5WpUm1BTfTvWZtgopdvNLXbJqNoTxz3o=.37cfe758-c0ef-4fdb-bd0d-2e83796c0018@github.com>
References: <biMzqs33OmQ3OG6eduDmGw15gxdN01HH61vgYqVhosk=.80c0d3c9-65f3-40fc-8e40-a56882f98dc9@github.com>
 <ujMNwdynb2P5WpUm1BTfTvWZtgopdvNLXbJqNoTxz3o=.37cfe758-c0ef-4fdb-bd0d-2e83796c0018@github.com>
Message-ID: <RkG3YlPkO9qDcIkYpkOY8LQ_koVP_k0UYg2_SEEfYUg=.b90d9627-a0e1-4f46-a9fc-c93a2da10441@github.com>

On Mon, 28 Apr 2025 09:32:26 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> java/awt/ScrollPane/bug8077409Test.java is unstable and fails intermittently in CI, especially in MacOS machines.
>> Also the frame created in this test is not disposed which may interfere with other tests.
>> 
>> Fix:
>> Some stabilisations added and the frame is disposed properly.
>> 
>> Testing:
>> Tested 100 times per platform(macosx-x64,macosx-aarch64,windows-x64,linux-x64) and got all PASS.
>> I have also tested this on Windows-x64 with JDK 8u60b04 and JDK 8u60b20 as the original issue related to this test(JDK-8077409) was fixed in JDK 8u60b20.
>> With JDK 8u60b04:
>> Exception in thread "main" java.lang.RuntimeException: Wrong position of component in ScrollPane
>>         at bug8077409Test.main(bug8077409Test.java:142)
>> 
>> With JDK 8u60b20:
>> Passed.....
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed : Removed unwanted code and updated copyright year

Any sponsors?

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

PR Comment: https://git.openjdk.org/jdk/pull/24292#issuecomment-2846779659

From abhiscxk at openjdk.org  Fri May  2 10:01:55 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 2 May 2025 10:01:55 GMT
Subject: RFR: 8288471: java/awt/ScrollPane/bug8077409Test.java is unstable
 and fails intermittently in CI [v4]
In-Reply-To: <ujMNwdynb2P5WpUm1BTfTvWZtgopdvNLXbJqNoTxz3o=.37cfe758-c0ef-4fdb-bd0d-2e83796c0018@github.com>
References: <biMzqs33OmQ3OG6eduDmGw15gxdN01HH61vgYqVhosk=.80c0d3c9-65f3-40fc-8e40-a56882f98dc9@github.com>
 <ujMNwdynb2P5WpUm1BTfTvWZtgopdvNLXbJqNoTxz3o=.37cfe758-c0ef-4fdb-bd0d-2e83796c0018@github.com>
Message-ID: <_zlFiWA0VIFjTaoKMr6gGZhuoO3v-IJZJ-Ya5T7g6O4=.1b96b879-27c4-42a3-95a5-f5198800fdfc@github.com>

On Mon, 28 Apr 2025 09:32:26 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> java/awt/ScrollPane/bug8077409Test.java is unstable and fails intermittently in CI, especially in MacOS machines.
>> Also the frame created in this test is not disposed which may interfere with other tests.
>> 
>> Fix:
>> Some stabilisations added and the frame is disposed properly.
>> 
>> Testing:
>> Tested 100 times per platform(macosx-x64,macosx-aarch64,windows-x64,linux-x64) and got all PASS.
>> I have also tested this on Windows-x64 with JDK 8u60b04 and JDK 8u60b20 as the original issue related to this test(JDK-8077409) was fixed in JDK 8u60b20.
>> With JDK 8u60b04:
>> Exception in thread "main" java.lang.RuntimeException: Wrong position of component in ScrollPane
>>         at bug8077409Test.main(bug8077409Test.java:142)
>> 
>> With JDK 8u60b20:
>> Passed.....
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed : Removed unwanted code and updated copyright year

test/jdk/java/awt/ScrollPane/bug8077409Test.java line 32:

> 30:  */
> 31: 
> 32: 

Extra blank line can be removed.

test/jdk/java/awt/ScrollPane/bug8077409Test.java line 58:

> 56:         add(pane, BorderLayout.CENTER);
> 57:         setSize(320, 480);
> 58: 

For consistency, blank line can be removed.

test/jdk/java/awt/ScrollPane/bug8077409Test.java line 75:

> 73:                 throw new RuntimeException("Wrong position of component in ScrollPane");
> 74:             } else {
> 75:                 System.out.println("Passed.....");

Redundant print statement.

test/jdk/java/awt/ScrollPane/bug8077409Test.java line 85:

> 83:     protected void processKeyEvent(KeyEvent e) {
> 84:         super.processKeyEvent(e);
> 85: 

For consistency, blank line can be removed.

test/jdk/java/awt/ScrollPane/bug8077409Test.java line 89:

> 87: 
> 88:     class MyCanvas extends Canvas {
> 89:         public Dimension getPreferredSize() {

You can add @Override for overridden method

test/jdk/java/awt/ScrollPane/bug8077409Test.java line 93:

> 91:         }
> 92: 
> 93:         public void paint(Graphics g) {

You can add `@Override` for overridden method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24292#discussion_r2071382835
PR Review Comment: https://git.openjdk.org/jdk/pull/24292#discussion_r2071386731
PR Review Comment: https://git.openjdk.org/jdk/pull/24292#discussion_r2071384232
PR Review Comment: https://git.openjdk.org/jdk/pull/24292#discussion_r2071386531
PR Review Comment: https://git.openjdk.org/jdk/pull/24292#discussion_r2071385141
PR Review Comment: https://git.openjdk.org/jdk/pull/24292#discussion_r2071384845

From mvs at openjdk.org  Fri May  2 10:49:03 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Fri, 2 May 2025 10:49:03 GMT
Subject: RFR: 8288471: java/awt/ScrollPane/bug8077409Test.java is unstable
 and fails intermittently in CI [v5]
In-Reply-To: <biMzqs33OmQ3OG6eduDmGw15gxdN01HH61vgYqVhosk=.80c0d3c9-65f3-40fc-8e40-a56882f98dc9@github.com>
References: <biMzqs33OmQ3OG6eduDmGw15gxdN01HH61vgYqVhosk=.80c0d3c9-65f3-40fc-8e40-a56882f98dc9@github.com>
Message-ID: <2Y1tZfd5uHIxowWxcws3jxMJDP558uHTUABw7TqOQhE=.9d8930c9-118c-4510-86c2-fa887ae4228a@github.com>

> java/awt/ScrollPane/bug8077409Test.java is unstable and fails intermittently in CI, especially in MacOS machines.
> Also the frame created in this test is not disposed which may interfere with other tests.
> 
> Fix:
> Some stabilisations added and the frame is disposed properly.
> 
> Testing:
> Tested 100 times per platform(macosx-x64,macosx-aarch64,windows-x64,linux-x64) and got all PASS.
> I have also tested this on Windows-x64 with JDK 8u60b04 and JDK 8u60b20 as the original issue related to this test(JDK-8077409) was fixed in JDK 8u60b20.
> With JDK 8u60b04:
> Exception in thread "main" java.lang.RuntimeException: Wrong position of component in ScrollPane
>         at bug8077409Test.main(bug8077409Test.java:142)
> 
> With JDK 8u60b20:
> Passed.....

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed : Formatting changes, added @override

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24292/files
  - new: https://git.openjdk.org/jdk/pull/24292/files/13d1deeb..58349b9a

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

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

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

From ngubarkov at openjdk.org  Fri May  2 16:16:46 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Fri, 2 May 2025 16:16:46 GMT
Subject: RFR: 8352407: PixelInterleavedSampleModel with unused components
 throws RasterFormatException: Incorrect pixel stride [v2]
In-Reply-To: <WCIPiMONKTeNTfYpThn-E5KbK0xugUdVd9-cj4DVzgI=.426be1d0-7b23-4197-a572-31390f15c256@github.com>
References: <XG3ViAQRcqvh0bpwzKJ60-L_MNPcSLmY-0xdej3kZJ0=.94f48732-976b-4b08-938f-ed1c7a552b6c@github.com>
 <PmtIVc7ZAk24h4ZNm4L0ALtuOLRBN9wOzxqjRN8p8XY=.aa53b167-39ab-4656-b59a-fbf7155bfd37@github.com>
 <0IkJpQYFv_3lUjxKvd1T0EqtOeO4wN5XYEX1pJFf6Pc=.0eac5063-1b53-461b-8bc8-ca1320147a5a@github.com>
 <7PoUZmVaNchLPzKKv-Y2Kb3K2iTCIwF_GBxWgYOeSj8=.7c57eb44-10de-4e95-9fea-07ea39ed53ee@github.com>
 <LMhGv0pMFQ-fonjN85B7SFoZRr-QdDXmf2MyeWT2JZg=.d8fc64a1-e343-4635-95ac-1a2c3771aabe@github.com>
 <9t4GmM3f624NKzcRzc1I4m-jDABNjukX93uJiEge0Bs=.b3a8c0f9-cd9c-4f61-9d80-700e5d37fcc7@github.com>
 <y5wNOtgWxTsU3L0OM0_ZDa0sRWVdDmWenWakqw5e9M8=.0eae79f4-e17a-4d15-9934-7e6e7fb835b2@github.com>
 <amCkmXy5YrXzIPcXvdEdaOcNuhgYMD0J_0IekNEdBHE=.f21896f3-f3c5-464d-bf40-163f2197daea@github.com>
 <ijwQAEWyeTfdev8PuqUgJ9XqnqFIY_UjkwSIH87Ki5o=.2153f09b-2b42-42f4-b711-002785d1b296@github.com>
 <Xoj0n650Gc63yERu3_4xk8YKEb9iI3ZFsXDix6qAoPA=.603adcca-b515-4c9a-97d7-1b8580aed77c@github.com>
 <qa9UKNizjWYgcNRDWoMzqEz4WXl_WV0FrGP
 FGgIa8K8=.d10e7855-df49-424d-8f77-dbe0efb678b9@github.com>
 <JmGc0nBsRebbGf3SNHIiE5QW9yOPsIlUPQzeS6Z-ThQ=.28f512ff-9cbd-4eac-b7e4-9a1561ed2d1e@github.com>
 <mwNT_dq_Hmyxh3RnZjT_kn1wc0iJnXmwmeZG7lftZfA=.a5b8ffe4-8a83-4e8a-ba0e-db26a681733c@github.com>
 <yERUjx3zwLpkOLWdIc2VkSmLHuiRg5CMcX7EveOMpiQ=.ce3072d7-d161-4423-aeed-304ac3380c9c@github.com>
 <RShz9z4agb0ziljiCwM9mB8jeTpk8Cm9CVSBUbvJCQw=.4f7ce8ee-83cb-4571-ad70-10f1d32d8e71@github.com>
 <ePN4eu88VE2UnxLhUgNQIJ22fjt0JwYCJdjaWfSqMNI=.4690589f-205f-422a-ad9e-598fbef055f4@github.com>
 <G79PvZVAsqvqOpHbePLSp0T73rWDq7UGmw6Fd2eDDdE=.ccc51b6b-e684-4e42-bc1a-53cd6fad4532@github.com>
 <tSOGp-2BC63Dwr3bTHDC9KQeInn7jzvNJh5ykUKkD28=.fd45110d-a08b-4d8d-a1d1-0eb1a110cc6d@github.com>
 <8dCI6Y3gKiDufYZEKkqrUk7Fn3lz3cwHVyi2gS7-Qck=.e4d29c99-7cce-4aad-a635-31f199970b61@github.com>
 <WCIPiMONKTeNTfYpThn-E5KbK0xugUdVd9-cj4DVzgI=.426be1d0-7b23-4197-a572-31390f15c256@github.com>
Message-ID: <7b80MMi1QZ9zqKkL7LCFhaYSBiEMcVc5AgHmrWw5oO4=.23847f28-e1b0-43bb-b88e-2177b7ef9c09@github.com>

On Fri, 25 Apr 2025 19:12:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> In your sample you provided an example, when raster fits whole pixels (`scanline * (height - 1) + pixelStride * width`), which, I agree, is a perfectly fine case and must be supported by accelerated pipelines. But the question is: should partial pixels be handled by our pipelines too (`scanline * (height - 1) + pixelStride * (width - 1) + maxBandOffset + 1` where `maxBandOffset + 1 < pixelStride`), or should whole pixels be enforced? I am for the latter.
>
> However, this is not a case of a "partial pixel"- the data for the pixel itself is present. Therefore, the user can still manually create a buffer that discards the tail of the image and it will be accepted:
> 
> DataBuffer manualBuffer = new DataBufferByte(
>     scanlineStride * (SIZE - 1) + pixelStride * (SIZE - 1) + 2/*maxBandOffset*/ + 1 /*size of last component*/
> );
> 
> The current logic seems to imply that:
> 
> * The scanline stride doesn't matter for a single-line image, or for the last line in the image.
> * The pixel stride is irrelevant if there's only one pixel in the image, or for the last pixel in a row.
> 
> This behavior is validated in src/java.desktop/share/classes/sun/awt/image/ByteComponentRaster.java#verify, with the exception of the single-pixel image we mentioned earlier.
> 
> I believe that exception for the 1-pixel image is a bug (pixelStride > data.length) that was overlooked during the work on commit [86104df](https://github.com/openjdk/jdk/commit/86104df#diff-f5003f18f0f4594a4859901ea950652467137fb1d07900208a84617036142746R891-L891), where a similar check for scanlineStride > data.length was fixed.

Ok, I found another argument as to why I think we should allocate memory according to `pixelStride`, including padding. I am currently optimizing the Vulkan blit and specifically reducing the amount of extra copies, so the issue is real.

In order to do draw an image, we need a Vulkan image. To bring raster data into Vulkan image we are currently doing 2 copies: software raster -> VkBuffer -> VkImage. We could get rid of one copy if we imported raster memory as an external allocation and bind VkBuffer to it directly: VkBuffer(software raster) -> VkImage. In theory we could even wrap host memory as an image and use it directly, but I doubt that would be more performant.

So, if we try to import raster data as an external allocation, it becomes useless for the purposes of copying or sampling, because Vulkan requires the whole memory region to be resident, it will copy `height` rows of `rowLength` bytes and there is no way it could work in that strange scenario when we have RGBx raster with 1 byte of padding in the end, mapping to RGBA Vulkan format, and there is just a single missing byte in the end of the whole raster ruining our optimization, forcing us to memcpy the whole raster into a temporary buffer, which is just 1 byte larger so that we could properly copy that into Vulkan image.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24111#discussion_r2071847084

From duke at openjdk.org  Fri May  2 17:18:51 2025
From: duke at openjdk.org (Hendrik Schick)
Date: Fri, 2 May 2025 17:18:51 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <Nlospsfogo17X9rWEPw3yT6rqpcNFzeFcR3WI3_dvUc=.08737a9b-8363-477a-af8a-5eca9032f0aa@github.com>

On Thu, 1 May 2025 22:31:32 GMT, Phil Race <prr at openjdk.org> wrote:

> A simple API to replace java.applet.AudioClip

src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 101:

> 99:             clip.init(stream);
> 100:         } catch (final Exception e) {
> 101:             // AudioClip will be no-op if some exception will occurred

Suggestion:

            // AudioClip will be no-op if some exception will occur

or 'has occurred' (?)

src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 114:

> 112:             clip.init(uc.getInputStream());
> 113:         } catch (final Exception ignored) {
> 114:             // Playing the clip will be a no-op if an exception occured in inititialization.

Suggestion:

            // Playing the clip will be a no-op if an exception occured in initialization.

src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 124:

> 122:             clip.init(url.openStream());
> 123:         } catch (final Exception ignored) {
> 124:             // Playing the clip will be a no-op if an exception occurred in inititialization.

Suggestion:

            // Playing the clip will be a no-op if an exception occurred in initialization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2071917249
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2071917636
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2071917934

From duke at openjdk.org  Fri May  2 17:23:50 2025
From: duke at openjdk.org (Hendrik Schick)
Date: Fri, 2 May 2025 17:23:50 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <EFhPG58oNpsf7uz4WmtDNm1ANgKgKbdQgZwgHYOgGsM=.66c968d2-bf0c-4835-9f8a-df398cc4a975@github.com>

On Thu, 1 May 2025 22:31:32 GMT, Phil Race <prr at openjdk.org> wrote:

> A simple API to replace java.applet.AudioClip

src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 294:

> 292:     public synchronized void update(LineEvent event) {
> 293:        if (clip != null) {
> 294:            if (clip == event.getSource()) {

merge the two ifs to one if?

test/jdk/javax/sound/SoundClip/SoundClipTest.java line 40:

> 38: 
> 39:     public static void main(String[] args) throws Exception {
> 40: 

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2071921500
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2071922997

From duke at openjdk.org  Fri May  2 17:29:49 2025
From: duke at openjdk.org (Hendrik Schick)
Date: Fri, 2 May 2025 17:29:49 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <gAfurMkpusYXwyd8Jln28vfxQ8xxP_1Nl47KFmOd3H0=.5457ad20-b798-4af4-89b0-aa7cde9dd0ef@github.com>

On Thu, 1 May 2025 22:31:32 GMT, Phil Race <prr at openjdk.org> wrote:

> A simple API to replace java.applet.AudioClip

test/jdk/javax/sound/SoundClip/SoundClipTest.java line 100:

> 98:             }
> 99:         } catch (Exception e) {
> 100:             System.err.println("Exception occured: "+e);

Suggestion:

            System.err.println("Exception occurred: " + e);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2071926408

From achung at openjdk.org  Fri May  2 17:35:04 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 2 May 2025 17:35:04 GMT
Subject: RFR: 8343739: Test
 java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java failed: Wrong
 extended key code [v3]
In-Reply-To: <ubVHDLbUmS2V0etEvYlsOVr-1H6ZQxayrQTU4bXxz-o=.075cef8e-5d34-43de-8870-09e6afa4f588@github.com>
References: <ubVHDLbUmS2V0etEvYlsOVr-1H6ZQxayrQTU4bXxz-o=.075cef8e-5d34-43de-8870-09e6afa4f588@github.com>
Message-ID: <-VKRExcwuamNGxB1FbvYY_rA-dXICYFodaqiI2QnSe0=.0c5f4481-4016-4333-8360-3c6d519f710b@github.com>

> Test was failing on Ubuntu, looks to be a synchronous error in the test so I rewrote it to improve stability.

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

  check eventsCount

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24885/files
  - new: https://git.openjdk.org/jdk/pull/24885/files/2199d038..711bd81f

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

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

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

From achung at openjdk.org  Fri May  2 18:34:45 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 2 May 2025 18:34:45 GMT
Subject: RFR: 8343739: Test
 java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java failed: Wrong
 extended key code [v3]
In-Reply-To: <-VKRExcwuamNGxB1FbvYY_rA-dXICYFodaqiI2QnSe0=.0c5f4481-4016-4333-8360-3c6d519f710b@github.com>
References: <ubVHDLbUmS2V0etEvYlsOVr-1H6ZQxayrQTU4bXxz-o=.075cef8e-5d34-43de-8870-09e6afa4f588@github.com>
 <-VKRExcwuamNGxB1FbvYY_rA-dXICYFodaqiI2QnSe0=.0c5f4481-4016-4333-8360-3c6d519f710b@github.com>
Message-ID: <ht3_2I2H1FIIA8XGRX5o7kpGHn80Aw9z6rtEYI53oLU=.0ca28b73-57fb-4ebf-85b1-efe73bf2d898@github.com>

On Fri, 2 May 2025 17:35:04 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Test was failing on Ubuntu, looks to be a synchronous error in the test so I rewrote it to improve stability.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check eventsCount

I've updated the test to include logging and ran the test 200x without failures. I think it's ok to push the test with these changes so that if the test ever does fail again we can use the logs and analyze the problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/24885#issuecomment-2847848635

From prr at openjdk.org  Fri May  2 23:00:32 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 2 May 2025 23:00:32 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v2]
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <Xl1oVhRGDHJX-j5VoyIsGee1JfgbukuqGIgnpb6lR9Y=.a17d8c8a-d95b-4643-afbb-a99ff5fd3b94@github.com>

> A simple API to replace java.applet.AudioClip

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

  8356049

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24991/files
  - new: https://git.openjdk.org/jdk/pull/24991/files/d5ae1aef..299bce17

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

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

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

From prr at openjdk.org  Fri May  2 23:00:33 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 2 May 2025 23:00:33 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v2]
In-Reply-To: <Nlospsfogo17X9rWEPw3yT6rqpcNFzeFcR3WI3_dvUc=.08737a9b-8363-477a-af8a-5eca9032f0aa@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <Nlospsfogo17X9rWEPw3yT6rqpcNFzeFcR3WI3_dvUc=.08737a9b-8363-477a-af8a-5eca9032f0aa@github.com>
Message-ID: <gRl1i1i1FXCFbtkMuSGTV9ORhBJqCz8whTxjvxJxr9w=.816afc8f-39ea-4893-9a3e-2d1694666316@github.com>

On Fri, 2 May 2025 17:15:29 GMT, Hendrik Schick <duke at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356049
>
> src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 101:
> 
>> 99:             clip.init(stream);
>> 100:         } catch (final Exception e) {
>> 101:             // AudioClip will be no-op if some exception will occurred
> 
> Suggestion:
> 
>             // AudioClip will be no-op if some exception will occur
> 
> or 'has occurred' (?)

I'm just going to delete the comment here as it is a bit out of place.
The more interesting question is whether IOException should be thrown or swallowed like all other exceptions.
The current code throws it (clearly) and so the app has to handle it.
But if we swallow other exceptions ... ?

> src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 114:
> 
>> 112:             clip.init(uc.getInputStream());
>> 113:         } catch (final Exception ignored) {
>> 114:             // Playing the clip will be a no-op if an exception occured in inititialization.
> 
> Suggestion:
> 
>             // Playing the clip will be a no-op if an exception occurred in initialization.

No plans to fix typos comments for code I'm not touching and expect to delete in the near future

> src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 124:
> 
>> 122:             clip.init(url.openStream());
>> 123:         } catch (final Exception ignored) {
>> 124:             // Playing the clip will be a no-op if an exception occurred in inititialization.
> 
> Suggestion:
> 
>             // Playing the clip will be a no-op if an exception occurred in initialization.

No plans to fix typos comments for code I'm not touching and expect to delete in the near future

> src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 294:
> 
>> 292:     public synchronized void update(LineEvent event) {
>> 293:        if (clip != null) {
>> 294:            if (clip == event.getSource()) {
> 
> merge the two ifs to one if?

I could .. but this way it is clearer that clip may actually be null ..

> test/jdk/javax/sound/SoundClip/SoundClipTest.java line 40:
> 
>> 38: 
>> 39:     public static void main(String[] args) throws Exception {
>> 40: 
> 
> Suggestion:

I like blank lines there

> test/jdk/javax/sound/SoundClip/SoundClipTest.java line 100:
> 
>> 98:             }
>> 99:         } catch (Exception e) {
>> 100:             System.err.println("Exception occured: "+e);
> 
> Suggestion:
> 
>             System.err.println("Exception occurred: " + e);

I copied that from another test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2072221321
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2072221421
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2072221490
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2072222130
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2072222289
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2072222456

From serb at openjdk.org  Sat May  3 01:02:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 3 May 2025 01:02:52 GMT
Subject: RFR: 8352407: PixelInterleavedSampleModel with unused components
 throws RasterFormatException: Incorrect pixel stride [v2]
In-Reply-To: <7b80MMi1QZ9zqKkL7LCFhaYSBiEMcVc5AgHmrWw5oO4=.23847f28-e1b0-43bb-b88e-2177b7ef9c09@github.com>
References: <XG3ViAQRcqvh0bpwzKJ60-L_MNPcSLmY-0xdej3kZJ0=.94f48732-976b-4b08-938f-ed1c7a552b6c@github.com>
 <PmtIVc7ZAk24h4ZNm4L0ALtuOLRBN9wOzxqjRN8p8XY=.aa53b167-39ab-4656-b59a-fbf7155bfd37@github.com>
 <0IkJpQYFv_3lUjxKvd1T0EqtOeO4wN5XYEX1pJFf6Pc=.0eac5063-1b53-461b-8bc8-ca1320147a5a@github.com>
 <7PoUZmVaNchLPzKKv-Y2Kb3K2iTCIwF_GBxWgYOeSj8=.7c57eb44-10de-4e95-9fea-07ea39ed53ee@github.com>
 <LMhGv0pMFQ-fonjN85B7SFoZRr-QdDXmf2MyeWT2JZg=.d8fc64a1-e343-4635-95ac-1a2c3771aabe@github.com>
 <9t4GmM3f624NKzcRzc1I4m-jDABNjukX93uJiEge0Bs=.b3a8c0f9-cd9c-4f61-9d80-700e5d37fcc7@github.com>
 <y5wNOtgWxTsU3L0OM0_ZDa0sRWVdDmWenWakqw5e9M8=.0eae79f4-e17a-4d15-9934-7e6e7fb835b2@github.com>
 <amCkmXy5YrXzIPcXvdEdaOcNuhgYMD0J_0IekNEdBHE=.f21896f3-f3c5-464d-bf40-163f2197daea@github.com>
 <ijwQAEWyeTfdev8PuqUgJ9XqnqFIY_UjkwSIH87Ki5o=.2153f09b-2b42-42f4-b711-002785d1b296@github.com>
 <Xoj0n650Gc63yERu3_4xk8YKEb9iI3ZFsXDix6qAoPA=.603adcca-b515-4c9a-97d7-1b8580aed77c@github.com>
 <qa9UKNizjWYgcNRDWoMzqEz4WXl_WV0FrGP
 FGgIa8K8=.d10e7855-df49-424d-8f77-dbe0efb678b9@github.com>
 <JmGc0nBsRebbGf3SNHIiE5QW9yOPsIlUPQzeS6Z-ThQ=.28f512ff-9cbd-4eac-b7e4-9a1561ed2d1e@github.com>
 <mwNT_dq_Hmyxh3RnZjT_kn1wc0iJnXmwmeZG7lftZfA=.a5b8ffe4-8a83-4e8a-ba0e-db26a681733c@github.com>
 <yERUjx3zwLpkOLWdIc2VkSmLHuiRg5CMcX7EveOMpiQ=.ce3072d7-d161-4423-aeed-304ac3380c9c@github.com>
 <RShz9z4agb0ziljiCwM9mB8jeTpk8Cm9CVSBUbvJCQw=.4f7ce8ee-83cb-4571-ad70-10f1d32d8e71@github.com>
 <ePN4eu88VE2UnxLhUgNQIJ22fjt0JwYCJdjaWfSqMNI=.4690589f-205f-422a-ad9e-598fbef055f4@github.com>
 <G79PvZVAsqvqOpHbePLSp0T73rWDq7UGmw6Fd2eDDdE=.ccc51b6b-e684-4e42-bc1a-53cd6fad4532@github.com>
 <tSOGp-2BC63Dwr3bTHDC9KQeInn7jzvNJh5ykUKkD28=.fd45110d-a08b-4d8d-a1d1-0eb1a110cc6d@github.com>
 <8dCI6Y3gKiDufYZEKkqrUk7Fn3lz3cwHVyi2gS7-Qck=.e4d29c99-7cce-4aad-a635-31f199970b61@github.com>
 <WCIPiMONKTeNTfYpThn-E5KbK0xugUdVd9-cj4DVzgI=.426be1d0-7b23-4197-a572-31390f15c256@github.com>
 <7b80MMi1QZ9zqKkL7LCFhaYSBiEMcVc5AgHmrWw5oO4=.23847f28-e1b0-43bb-b88e-2177b7ef9c09@
 github.com>
Message-ID: <aM_RdM7L6ILzWH0zJCWBG8EZpl5LExa2ZM-2mo0cYdY=.5d1be0fc-b262-44a5-877f-a2a332f51e82@github.com>

On Fri, 2 May 2025 16:14:30 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> However, this is not a case of a "partial pixel"- the data for the pixel itself is present. Therefore, the user can still manually create a buffer that discards the tail of the image and it will be accepted:
>> 
>> DataBuffer manualBuffer = new DataBufferByte(
>>     scanlineStride * (SIZE - 1) + pixelStride * (SIZE - 1) + 2/*maxBandOffset*/ + 1 /*size of last component*/
>> );
>> 
>> The current logic seems to imply that:
>> 
>> * The scanline stride doesn't matter for a single-line image, or for the last line in the image.
>> * The pixel stride is irrelevant if there's only one pixel in the image, or for the last pixel in a row.
>> 
>> This behavior is validated in src/java.desktop/share/classes/sun/awt/image/ByteComponentRaster.java#verify, with the exception of the single-pixel image we mentioned earlier.
>> 
>> I believe that exception for the 1-pixel image is a bug (pixelStride > data.length) that was overlooked during the work on commit [86104df](https://github.com/openjdk/jdk/commit/86104df#diff-f5003f18f0f4594a4859901ea950652467137fb1d07900208a84617036142746R891-L891), where a similar check for scanlineStride > data.length was fixed.
>
> Ok, I found another argument as to why I think we should allocate memory according to `pixelStride`, including padding. I am currently optimizing the Vulkan blit and specifically reducing the amount of extra copies, so the issue is real.
> 
> In order to do draw an image, we need a Vulkan image. To bring raster data into Vulkan image we are currently doing 2 copies: software raster -> VkBuffer -> VkImage. We could get rid of one copy if we imported raster memory as an external allocation and bind VkBuffer to it directly: VkBuffer(software raster) -> VkImage. In theory we could even wrap host memory as an image and use it directly, but I doubt that would be more performant.
> 
> So, if we try to import raster data as an external allocation, it becomes useless for the purposes of copying or sampling, because Vulkan requires the whole memory region to be resident, it will copy `height` rows of `rowLength` bytes and there is no way it could work in that strange scenario when we have RGBx raster with 1 byte of padding in the end, mapping to RGBA Vulkan format, and there is just a single missing byte in the end of the whole raster ruining our optimization, forcing us to memcpy the whole raster into a temporary buffer, which is just 1 byte larger so that we could properly copy that into Vulkan image.

But even if we start allocating raster memory with padding internally, you will still need to support both cases anyway, right? So for now, maybe it's best to implement two versions of the blit: one optimized (assuming properly padded memory) and one fallback (handling the edge case with the missing padding).

At runtime, we can select the appropriate version depending on the actual memory layout. Then we can compare performance and see whether supporting both is actually worth it.

If the performance difference is significant, we can update our internal allocation strategy to always use the optimized layout, while still supporting custom rasters (with non-standard strides) using the slower path.

Just to clarify - are we talking only about padding per pixel, or do we also need full row padding to meet Vulkan?s alignment requirements?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24111#discussion_r2072266843

From serb at openjdk.org  Sat May  3 03:36:37 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 3 May 2025 03:36:37 GMT
Subject: RFR: 8355078: java.awt.Color.createContext() uses unnecessary
 synchronization
Message-ID: <0pWUD-E-stDoqVTXFmlRNJ2skEMIjeto6VFl6ydxyc0=.de5400a3-69a2-4621-a91a-45bdfbca4dd2@github.com>

At some point, java.awt.Color.createContext() was marked as synchronized to support caching of a ColorPaintContext instance. The cache was later removed, but the synchronized modifier remained. Since there is no shared mutable state anymore, the synchronization is no longer necessary and can be safely removed.


Note: This code path is rarely executed because a special optimization was introduced in [SunGraphics2D.setPaint](https://github.com/openjdk/jdk/blob/c514f135ccf08c3be016a32ae8f2c055fb941857/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1003). As a result, unless a custom wrapper around the Color class is used, the Color.createContext() method is typically bypassed during rendering. 

Two tests are added:
 - ColorPaintContextBasicTest: Checks if different image types (BufferedImage and VolatileImage) produce the same results when using different ways to fill the image (setColor, setPaint, and custom Paint). This test intentionally uses a custom Paint implementation to bypass the optimization and ensure that Color.createContext() is invoked verifying its correct behavior.
- ColorPaintContextStateTrackerTest: Checks that the raster used in ColorPaintContext.getRaster() can be properly cached in video memory and we do not need to call icr.markDirty() in ColorPaintContext.getRaster()

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

Commit messages:
 - Merge branch 'openjdk:master' into colorctx
 - Update ColorPaintContextBasicTest.java
 - handle VolatileImage properly
 - Update ColorPaintContext.java
 - 8355078: java.awt.Color.createContext() uses unnecessary synchronization

Changes: https://git.openjdk.org/jdk/pull/24771/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24771&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355078
  Stats: 304 lines in 4 files changed: 270 ins; 21 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/24771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24771/head:pull/24771

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

From liach at openjdk.org  Sat May  3 03:36:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 3 May 2025 03:36:37 GMT
Subject: RFR: 8355078: java.awt.Color.createContext() uses unnecessary
 synchronization
In-Reply-To: <0pWUD-E-stDoqVTXFmlRNJ2skEMIjeto6VFl6ydxyc0=.de5400a3-69a2-4621-a91a-45bdfbca4dd2@github.com>
References: <0pWUD-E-stDoqVTXFmlRNJ2skEMIjeto6VFl6ydxyc0=.de5400a3-69a2-4621-a91a-45bdfbca4dd2@github.com>
Message-ID: <-_5oVNGUPmnehTXt3lCZZQ2ieSW8PRT21D5b5GVZwI8=.7151f571-311c-45b6-b007-2431790780d3@github.com>

On Sun, 20 Apr 2025 08:15:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> At some point, java.awt.Color.createContext() was marked as synchronized to support caching of a ColorPaintContext instance. The cache was later removed, but the synchronized modifier remained. Since there is no shared mutable state anymore, the synchronization is no longer necessary and can be safely removed.
> 
> 
> Note: This code path is rarely executed because a special optimization was introduced in [SunGraphics2D.setPaint](https://github.com/openjdk/jdk/blob/c514f135ccf08c3be016a32ae8f2c055fb941857/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1003). As a result, unless a custom wrapper around the Color class is used, the Color.createContext() method is typically bypassed during rendering. 
> 
> Two tests are added:
>  - ColorPaintContextBasicTest: Checks if different image types (BufferedImage and VolatileImage) produce the same results when using different ways to fill the image (setColor, setPaint, and custom Paint). This test intentionally uses a custom Paint implementation to bypass the optimization and ensure that Color.createContext() is invoked verifying its correct behavior.
> - ColorPaintContextStateTrackerTest: Checks that the raster used in ColorPaintContext.getRaster() can be properly cached in video memory and we do not need to call icr.markDirty() in ColorPaintContext.getRaster()

Is a CSR requested for the access flags change? Some method flags, notably `native` or `synchronized`, are not part of the API specificaion and not rendered, and thus can be changed without CSR reviews. For example, the [javadoc for this particular method](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/Color.html#createContext(java.awt.image.ColorModel,java.awt.Rectangle,java.awt.geom.Rectangle2D,java.awt.geom.AffineTransform,java.awt.RenderingHints)) does not include the `synchronized` modifier.

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

PR Comment: https://git.openjdk.org/jdk/pull/24771#issuecomment-2817252429

From serb at openjdk.org  Sat May  3 03:36:37 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 3 May 2025 03:36:37 GMT
Subject: RFR: 8355078: java.awt.Color.createContext() uses unnecessary
 synchronization
In-Reply-To: <0pWUD-E-stDoqVTXFmlRNJ2skEMIjeto6VFl6ydxyc0=.de5400a3-69a2-4621-a91a-45bdfbca4dd2@github.com>
References: <0pWUD-E-stDoqVTXFmlRNJ2skEMIjeto6VFl6ydxyc0=.de5400a3-69a2-4621-a91a-45bdfbca4dd2@github.com>
Message-ID: <--OqL7L8b4WyVcaOPjzRd5HIOV1otfWrRnUfWHPrqrY=.248a6752-7b11-4207-83a8-e180e4d6cee7@github.com>

On Sun, 20 Apr 2025 08:15:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> At some point, java.awt.Color.createContext() was marked as synchronized to support caching of a ColorPaintContext instance. The cache was later removed, but the synchronized modifier remained. Since there is no shared mutable state anymore, the synchronization is no longer necessary and can be safely removed.
> 
> 
> Note: This code path is rarely executed because a special optimization was introduced in [SunGraphics2D.setPaint](https://github.com/openjdk/jdk/blob/c514f135ccf08c3be016a32ae8f2c055fb941857/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1003). As a result, unless a custom wrapper around the Color class is used, the Color.createContext() method is typically bypassed during rendering. 
> 
> Two tests are added:
>  - ColorPaintContextBasicTest: Checks if different image types (BufferedImage and VolatileImage) produce the same results when using different ways to fill the image (setColor, setPaint, and custom Paint). This test intentionally uses a custom Paint implementation to bypass the optimization and ensure that Color.createContext() is invoked verifying its correct behavior.
> - ColorPaintContextStateTrackerTest: Checks that the raster used in ColorPaintContext.getRaster() can be properly cached in video memory and we do not need to call icr.markDirty() in ColorPaintContext.getRaster()

src/java.desktop/share/classes/java/awt/ColorPaintContext.java line 39:

> 37:     private final int color;
> 38:     private volatile WritableRaster savedTile;
> 39: 

Since ColorPaintContext is no longer cached within the Color class, it's unlikely that this object will be accessed by multiple threads in typical JDK usage. Therefore, the synchronized modifier has been removed from the getRaster() method. However, to ensure thread safety in the rare case where a ColorPaintContext instance is shared across threads (if app decides to do so for some reason), the savedTile field has been declared as volatile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24771#discussion_r2071030293

From ngubarkov at openjdk.org  Sat May  3 09:28:45 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Sat, 3 May 2025 09:28:45 GMT
Subject: RFR: 8352407: PixelInterleavedSampleModel with unused components
 throws RasterFormatException: Incorrect pixel stride [v2]
In-Reply-To: <aM_RdM7L6ILzWH0zJCWBG8EZpl5LExa2ZM-2mo0cYdY=.5d1be0fc-b262-44a5-877f-a2a332f51e82@github.com>
References: <XG3ViAQRcqvh0bpwzKJ60-L_MNPcSLmY-0xdej3kZJ0=.94f48732-976b-4b08-938f-ed1c7a552b6c@github.com>
 <PmtIVc7ZAk24h4ZNm4L0ALtuOLRBN9wOzxqjRN8p8XY=.aa53b167-39ab-4656-b59a-fbf7155bfd37@github.com>
 <0IkJpQYFv_3lUjxKvd1T0EqtOeO4wN5XYEX1pJFf6Pc=.0eac5063-1b53-461b-8bc8-ca1320147a5a@github.com>
 <7PoUZmVaNchLPzKKv-Y2Kb3K2iTCIwF_GBxWgYOeSj8=.7c57eb44-10de-4e95-9fea-07ea39ed53ee@github.com>
 <LMhGv0pMFQ-fonjN85B7SFoZRr-QdDXmf2MyeWT2JZg=.d8fc64a1-e343-4635-95ac-1a2c3771aabe@github.com>
 <9t4GmM3f624NKzcRzc1I4m-jDABNjukX93uJiEge0Bs=.b3a8c0f9-cd9c-4f61-9d80-700e5d37fcc7@github.com>
 <y5wNOtgWxTsU3L0OM0_ZDa0sRWVdDmWenWakqw5e9M8=.0eae79f4-e17a-4d15-9934-7e6e7fb835b2@github.com>
 <amCkmXy5YrXzIPcXvdEdaOcNuhgYMD0J_0IekNEdBHE=.f21896f3-f3c5-464d-bf40-163f2197daea@github.com>
 <ijwQAEWyeTfdev8PuqUgJ9XqnqFIY_UjkwSIH87Ki5o=.2153f09b-2b42-42f4-b711-002785d1b296@github.com>
 <Xoj0n650Gc63yERu3_4xk8YKEb9iI3ZFsXDix6qAoPA=.603adcca-b515-4c9a-97d7-1b8580aed77c@github.com>
 <qa9UKNizjWYgcNRDWoMzqEz4WXl_WV0FrGP
 FGgIa8K8=.d10e7855-df49-424d-8f77-dbe0efb678b9@github.com>
 <JmGc0nBsRebbGf3SNHIiE5QW9yOPsIlUPQzeS6Z-ThQ=.28f512ff-9cbd-4eac-b7e4-9a1561ed2d1e@github.com>
 <mwNT_dq_Hmyxh3RnZjT_kn1wc0iJnXmwmeZG7lftZfA=.a5b8ffe4-8a83-4e8a-ba0e-db26a681733c@github.com>
 <yERUjx3zwLpkOLWdIc2VkSmLHuiRg5CMcX7EveOMpiQ=.ce3072d7-d161-4423-aeed-304ac3380c9c@github.com>
 <RShz9z4agb0ziljiCwM9mB8jeTpk8Cm9CVSBUbvJCQw=.4f7ce8ee-83cb-4571-ad70-10f1d32d8e71@github.com>
 <ePN4eu88VE2UnxLhUgNQIJ22fjt0JwYCJdjaWfSqMNI=.4690589f-205f-422a-ad9e-598fbef055f4@github.com>
 <G79PvZVAsqvqOpHbePLSp0T73rWDq7UGmw6Fd2eDDdE=.ccc51b6b-e684-4e42-bc1a-53cd6fad4532@github.com>
 <tSOGp-2BC63Dwr3bTHDC9KQeInn7jzvNJh5ykUKkD28=.fd45110d-a08b-4d8d-a1d1-0eb1a110cc6d@github.com>
 <8dCI6Y3gKiDufYZEKkqrUk7Fn3lz3cwHVyi2gS7-Qck=.e4d29c99-7cce-4aad-a635-31f199970b61@github.com>
 <WCIPiMONKTeNTfYpThn-E5KbK0xugUdVd9-cj4DVzgI=.426be1d0-7b23-4197-a572-31390f15c256@github.com>
 <7b80MMi1QZ9zqKkL7LCFhaYSBiEMcVc5AgHmrWw5oO4=.23847f28-e1b0-43bb-b88e-2177b7ef9c09@
 github.com>
 <aM_RdM7L6ILzWH0zJCWBG8EZpl5LExa2ZM-2mo0cYdY=.5d1be0fc-b262-44a5-877f-a2a332f51e82@github.com>
Message-ID: <ocxkWdh6CBJ8bKta-tTJ8LePoYNhZNGCE1A5FCL5I5s=.f84216e6-c223-4f31-8e61-3546504dee51@github.com>

On Sat, 3 May 2025 00:58:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> even if we start allocating raster memory with padding internally, you will still need to support both cases anyway, right?

I don't think so. If we accept a user-created raster, it will not have a native structs initialized due to https://github.com/openjdk/jdk/pull/24378 anyway, so it will be converted into a known type first, before being used in Vulkan loops. So if we create rasters with optimal layouts internally, we should mostly be fine. Similarly for accepting external rasters (https://github.com/openjdk/jdk/pull/24378), we could only initialize native data if the memory layout matches the requirements of our accelerated loops.

> are we talking only about padding per pixel, or do we also need full row padding to meet Vulkan?s alignment requirements?

Sorry, not "it will copy `height` rows of `rowLength`", but "it will copy `height` rows of `width` texels with `rowLength` steps".
We are talking about per-pixel padding, **not** full row one.
Here's the spec on that: https://registry.khronos.org/vulkan/specs/latest/html/vkspec.html#copies-buffers-images
There is also an alignment limitation: buffer offset and row length must be multiple of texel block size - for our rasters it means that `startingOffset` and `scanlineStride` must be aligned to `pixelStride`, in order to be able to copy from this memory into Vulkan image directly. Again, this requirement is easily fulfilled when creating rasters internally, and can be checked when accepting external rasters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24111#discussion_r2072359206

From achung at openjdk.org  Sun May  4 20:58:47 2025
From: achung at openjdk.org (Alisen Chung)
Date: Sun, 4 May 2025 20:58:47 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v11]
In-Reply-To: <6A6RT3ZqccBhAhdhEaSDc3Ri0yUWw61Alc2xbYHtXfI=.24af6c9c-b6b8-4f3e-a4c6-61143685eef2@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
 <741DjI-uVAuf4pjN9MqVaKz2iEI-qr-L9c6KCbP7IlY=.e46c1d54-4b0f-4cc3-b572-043923972212@github.com>
 <mwLvU39Qxbts9_I2MU5oup-aeFVOulBcjRjVvUNKLOI=.4fa7507c-b038-4e87-8dcf-6c6c9f108acc@github.com>
 <lI8-Y3StfMzsltCf-vFdP5Oo-S1h5FRG8p21xRMnbfk=.608efc2d-671c-4a37-bfd8-b5827c9bc6cd@github.com>
 <B4fWQWgcaUcHuz7pi_mJimGbCUWdsHrrDMsN0gvbTA0=.5fb9b028-012f-4da1-ac76-d925b8b64bf2@github.com>
 <UALf_jPu6Pju8jgD51nERwQnJXLjM0u5XrthhB26M9g=.dde004fc-0a73-408d-b9ab-d9f21e71a006@github.com>
 <QqY_tCRd6FxeEGOHL86BRxcgP_avpOnBK_JtuMzTeHU=.81163bd7-f6ba-4c43-b281-356566e8af69@github.com>
 <zye9iVM8AK70RuqU_2nm4evvJavym_cl3s2s-HDrBvk=.09c36435-63ea-4bee-adb1-ffc6f7124b41@github.com>
 <6A6RT3ZqccBhAhdhEaSDc3Ri0yUWw61Alc2xbYHtXfI=.24af6c9c-b6b8-4f3e-a4c6-61143685eef2@github.com>
Message-ID: <xPGWVGkGW255iwjDoWAhEuLEXVG3lC7D8rZj8ZAMcHE=.067cf490-52e2-44e4-9f9a-fff7e908a220@github.com>

On Wed, 30 Apr 2025 21:17:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > So this seems to be a bug in macOS, as the reported mouse location is incorrect while it is actually positioned at the edge?
> > Probably, there are other macOS APIs that could be used to implement Java_sun_lwawt_macosx_CCursorManager_nativeGetCursorPosition. Or perhaps the methods within it should be called on the appkit thread - I see a potential race, since the mouse is moved asynchronously on appkit, but the coordinates are fetched on the current thread.
> 
> Did you have a chance to check our implementation of setting and getting the cursor?

I took a look at the cocoa documentation and I wasn't able to find any APIs that handle clamping. I also looked at our implementation: we create an empty mouse event then grab the location of that event. Since macOS doesn't do clamping, we would need to add clamping code to nativeGetCursorPosition after we grab the location of that empty event. I think it's easier to just do the clamping in CRobot on mouseMove instead since that would be the only way for the mouse to initially reach out of bounds. What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2849412199

From achung at openjdk.org  Sun May  4 20:58:48 2025
From: achung at openjdk.org (Alisen Chung)
Date: Sun, 4 May 2025 20:58:48 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v11]
In-Reply-To: <pFe9Zjz4f93OredgOSHRepQUDUTcPmuh7Hy0L5Afj7g=.1d95ecb5-a858-4cba-9cf4-831b0d39bc4d@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
 <vVeHGgTDZR2GgosI-c2dAopuaTwiY6ujXA658I9SHGM=.49d0f9dd-4e54-4168-9b31-f9a89901cce3@github.com>
 <QGkiw4yMvqS3AgLkxjGiPgvdazNkjdlRkV6kjWOP7Ns=.b4fa221a-bee3-4cf7-81b5-e032d24b4e00@github.com>
 <5eX-W4QVC3rAl-stH-geqadwoXIuYNR02tcNnY93I-8=.de2a402f-675e-48ac-ad29-b40f3b894f96@github.com>
 <pFe9Zjz4f93OredgOSHRepQUDUTcPmuh7Hy0L5Afj7g=.1d95ecb5-a858-4cba-9cf4-831b0d39bc4d@github.com>
Message-ID: <PKDA4XOOeSrRBcS8AaZC4pHz9J2Z1cUjf632EzAFGGk=.8d506bd9-960a-42f4-861f-6d27edfdb427@github.com>

On Wed, 30 Apr 2025 15:06:48 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> These failures when moving to the offscreen point are actually because the new onscreen point being moved to is closer distance-wise than the onscreen point it would have moved to before the fix.
>
> I think it doesn't look like expected behavior anyway, the pre-clamping one seems more reasonable to me (as for Linux, haven't tested other platforms).
> 
> Anyway, if the we are only having issues getting the mouse pointer coordinates after moving it off-screen on macos, I guess the fix shouldn't change shared code and other platforms.

Linux tries to respect one of the bounds if it can, while my code just looks for the closest point across all screens. I think both are reasonable, but I've moved the code into macOS code so the behavior isn't changed on different platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r2072709435

From achung at openjdk.org  Sun May  4 21:02:45 2025
From: achung at openjdk.org (Alisen Chung)
Date: Sun, 4 May 2025 21:02:45 GMT
Subject: RFR: JDK-8355528 : Update HarfBuzz to 11.2.0
In-Reply-To: <OYvCAf8MTYtEoexbi05jUZAp1soN20wD9NIHFjIF594=.c5ea11eb-aaf8-41f1-84df-76da1b902654@github.com>
References: <OYvCAf8MTYtEoexbi05jUZAp1soN20wD9NIHFjIF594=.c5ea11eb-aaf8-41f1-84df-76da1b902654@github.com>
Message-ID: <Hb0Zrb1imoj4Fsa_fHkLuCd_AwtWnIoYeLVqGGqXyX8=.af777007-90a4-475b-92bc-eb005597e95c@github.com>

On Wed, 30 Apr 2025 19:37:29 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> HarfBuzz upgraded to 11.2.0
> 
> 4 newly added files and 99 modified files.

Just a quick question since usually the third party upgrades I've done don't include new files, did you check that the files are needed for jdk?

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

PR Comment: https://git.openjdk.org/jdk/pull/24973#issuecomment-2849414631

From abhiscxk at openjdk.org  Mon May  5 04:25:48 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 5 May 2025 04:25:48 GMT
Subject: RFR: 8288471: java/awt/ScrollPane/bug8077409Test.java is unstable
 and fails intermittently in CI [v5]
In-Reply-To: <2Y1tZfd5uHIxowWxcws3jxMJDP558uHTUABw7TqOQhE=.9d8930c9-118c-4510-86c2-fa887ae4228a@github.com>
References: <biMzqs33OmQ3OG6eduDmGw15gxdN01HH61vgYqVhosk=.80c0d3c9-65f3-40fc-8e40-a56882f98dc9@github.com>
 <2Y1tZfd5uHIxowWxcws3jxMJDP558uHTUABw7TqOQhE=.9d8930c9-118c-4510-86c2-fa887ae4228a@github.com>
Message-ID: <00Mvcitec-3Sio9wB9tPw_BtkySKySzbEDpR3BCEO1U=.f1b328dc-0c81-4f81-870d-6d0a341f0d7e@github.com>

On Fri, 2 May 2025 10:49:03 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> java/awt/ScrollPane/bug8077409Test.java is unstable and fails intermittently in CI, especially in MacOS machines.
>> Also the frame created in this test is not disposed which may interfere with other tests.
>> 
>> Fix:
>> Some stabilisations added and the frame is disposed properly.
>> 
>> Testing:
>> Tested 100 times per platform(macosx-x64,macosx-aarch64,windows-x64,linux-x64) and got all PASS.
>> I have also tested this on Windows-x64 with JDK 8u60b04 and JDK 8u60b20 as the original issue related to this test(JDK-8077409) was fixed in JDK 8u60b20.
>> With JDK 8u60b04:
>> Exception in thread "main" java.lang.RuntimeException: Wrong position of component in ScrollPane
>>         at bug8077409Test.main(bug8077409Test.java:142)
>> 
>> With JDK 8u60b20:
>> Passed.....
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed : Formatting changes, added @override

Looks good to me.

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

Marked as reviewed by abhiscxk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24292#pullrequestreview-2813774275

From duke at openjdk.org  Mon May  5 04:25:48 2025
From: duke at openjdk.org (duke)
Date: Mon, 5 May 2025 04:25:48 GMT
Subject: RFR: 8288471: java/awt/ScrollPane/bug8077409Test.java is unstable
 and fails intermittently in CI [v5]
In-Reply-To: <2Y1tZfd5uHIxowWxcws3jxMJDP558uHTUABw7TqOQhE=.9d8930c9-118c-4510-86c2-fa887ae4228a@github.com>
References: <biMzqs33OmQ3OG6eduDmGw15gxdN01HH61vgYqVhosk=.80c0d3c9-65f3-40fc-8e40-a56882f98dc9@github.com>
 <2Y1tZfd5uHIxowWxcws3jxMJDP558uHTUABw7TqOQhE=.9d8930c9-118c-4510-86c2-fa887ae4228a@github.com>
Message-ID: <5VYFch-1SI6ILWOXfGPmZSueuNSoZNAaZjmUdRCIjIY=.f138d553-c7b3-4b47-ba25-9b28c65057d8@github.com>

On Fri, 2 May 2025 10:49:03 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> java/awt/ScrollPane/bug8077409Test.java is unstable and fails intermittently in CI, especially in MacOS machines.
>> Also the frame created in this test is not disposed which may interfere with other tests.
>> 
>> Fix:
>> Some stabilisations added and the frame is disposed properly.
>> 
>> Testing:
>> Tested 100 times per platform(macosx-x64,macosx-aarch64,windows-x64,linux-x64) and got all PASS.
>> I have also tested this on Windows-x64 with JDK 8u60b04 and JDK 8u60b20 as the original issue related to this test(JDK-8077409) was fixed in JDK 8u60b20.
>> With JDK 8u60b04:
>> Exception in thread "main" java.lang.RuntimeException: Wrong position of component in ScrollPane
>>         at bug8077409Test.main(bug8077409Test.java:142)
>> 
>> With JDK 8u60b20:
>> Passed.....
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed : Formatting changes, added @override

@openjdk[bot] 
Your change (at version 58349b9a79690f49ab3ef2174bca1c3805f1ec7f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24292#issuecomment-2849874937

From kizune at openjdk.org  Mon May  5 10:44:48 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 5 May 2025 10:44:48 GMT
Subject: RFR: 8355561: [macos] Build failure with Xcode 16.3
In-Reply-To: <IZmniCs0dWQCtAS3-Mg9rRRNpoer26TkCr9EzRXKpVM=.f8c5269c-aa8f-4ecd-a6bb-517cf3a1fc3b@github.com>
References: <IZmniCs0dWQCtAS3-Mg9rRRNpoer26TkCr9EzRXKpVM=.f8c5269c-aa8f-4ecd-a6bb-517cf3a1fc3b@github.com>
Message-ID: <-sTh2qfUGEuQZ16dmL-Kyx4K_34FVamhKVx30VQ5NGY=.ea6b1294-d618-4a01-9ce6-86d4df5cb92a@github.com>

On Mon, 28 Apr 2025 19:47:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Multiple similar issues detected in PLATFORM_API_MacOSX_Ports.cpp more info about https://github.com/llvm/llvm-project/issues/62836
> 
> jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>   127 | AudioDeviceID devices[count];
>       | ^~~~~
> jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
> jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
>   126 | int count = size/sizeof(AudioDeviceID);
> 
> The usage of VLA has been replaced with malloc/calloc and free, which are already used in this file.
> 
> Note that while this patch adds some validation, I am pretty sure it is still possible to crash these code paths if they are executed concurrently. Access to the native pointers being passed around is not properly synchronized.

Looks good.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24937#pullrequestreview-2814420953

From aturbanov at openjdk.org  Mon May  5 12:34:46 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 May 2025 12:34:46 GMT
Subject: RFR: 8354944: Remove unnecessary PartiallyOrderedSet.nodes
In-Reply-To: <11dR4gRM1RWgmx8FloFzy3dfZOwn3zIPjiD0690ZdEw=.2662d35c-e7bf-400f-a224-df53967202eb@github.com>
References: <11dR4gRM1RWgmx8FloFzy3dfZOwn3zIPjiD0690ZdEw=.2662d35c-e7bf-400f-a224-df53967202eb@github.com>
Message-ID: <kO41rXfYkbnR6Q7UjfU0UTFaVRyHe-u5Vdolnb81Zp4=.d0cb4ea3-bd20-4640-b919-e7b9704c9e24@github.com>

On Wed, 16 Apr 2025 20:50:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> We can use `javax.imageio.spi.PartiallyOrderedSet#poNodes` directly

Can I get a second review?

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

PR Comment: https://git.openjdk.org/jdk/pull/24699#issuecomment-2850846651

From aturbanov at openjdk.org  Mon May  5 12:38:58 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 May 2025 12:38:58 GMT
Subject: RFR: 8356175: Remove unnecessary Map.get from XWM.getInsets
Message-ID: <czOfOz4HkWVe7efBo1uPx8P_xk_2Pe3EmR678ZL137U=.cf0b4856-9be4-46fa-81a9-ec0a9cd46f11@github.com>

Cleanup code to use Map.putIfAbsent. It's clearer and faster.

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

Commit messages:
 - [PATCH] Remove unnecessary Map.get from XWM.getInsets

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

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

From serb at openjdk.org  Mon May  5 12:38:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 5 May 2025 12:38:58 GMT
Subject: RFR: 8356175: Remove unnecessary Map.get from XWM.getInsets
In-Reply-To: <czOfOz4HkWVe7efBo1uPx8P_xk_2Pe3EmR678ZL137U=.cf0b4856-9be4-46fa-81a9-ec0a9cd46f11@github.com>
References: <czOfOz4HkWVe7efBo1uPx8P_xk_2Pe3EmR678ZL137U=.cf0b4856-9be4-46fa-81a9-ec0a9cd46f11@github.com>
Message-ID: <Fa2-9OBhpE2te0wvoLPWvgSU84R7Y3GIfAwv3n1qecM=.c686629f-7c91-484b-a159-0f44f27bef85@github.com>

On Sun, 27 Apr 2025 21:01:07 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Cleanup code to use Map.putIfAbsent. It's clearer and faster.

looks fine.

looks fine

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

PR Comment: https://git.openjdk.org/jdk/pull/24906#issuecomment-2837033384
PR Comment: https://git.openjdk.org/jdk/pull/24906#issuecomment-2840893704

From acobbs at openjdk.org  Mon May  5 13:56:46 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 5 May 2025 13:56:46 GMT
Subject: RFR: 8355561: [macos] Build failure with Xcode 16.3
In-Reply-To: <IZmniCs0dWQCtAS3-Mg9rRRNpoer26TkCr9EzRXKpVM=.f8c5269c-aa8f-4ecd-a6bb-517cf3a1fc3b@github.com>
References: <IZmniCs0dWQCtAS3-Mg9rRRNpoer26TkCr9EzRXKpVM=.f8c5269c-aa8f-4ecd-a6bb-517cf3a1fc3b@github.com>
Message-ID: <QpNxp-hwbwiotYM7o4Lg8mVw1ktQD3wuLv4oVvZYXWA=.643622a6-366e-443e-80c5-630e4d9143bc@github.com>

On Mon, 28 Apr 2025 19:47:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Multiple similar issues detected in PLATFORM_API_MacOSX_Ports.cpp more info about https://github.com/llvm/llvm-project/issues/62836
> 
> jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>   127 | AudioDeviceID devices[count];
>       | ^~~~~
> jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
> jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
>   126 | int count = size/sizeof(AudioDeviceID);
> 
> The usage of VLA has been replaced with malloc/calloc and free, which are already used in this file.
> 
> Note that while this patch adds some validation, I am pretty sure it is still possible to crash these code paths if they are executed concurrently. Access to the native pointers being passed around is not properly synchronized.

Looking forward to getting this fixed so I can build again...

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

PR Comment: https://git.openjdk.org/jdk/pull/24937#issuecomment-2851089294

From achung at openjdk.org  Mon May  5 16:00:56 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 5 May 2025 16:00:56 GMT
Subject: RFR: 8354219 : Automate javax/swing/JComboBox/ComboPopupBug.java
 [v9]
In-Reply-To: <BcDXCPcF6T5egm85rR4pqCpYrHVuHa2740zH32j84a0=.f0e822e4-f7ea-40a3-bbe9-60982ba3add4@github.com>
References: <xleWDjAur8VerD-q0QvQXfiRoXCDJk0ZsunhHWV72W4=.ed62e2f7-42ca-4153-b92a-39c358f5d6b6@github.com>
 <BcDXCPcF6T5egm85rR4pqCpYrHVuHa2740zH32j84a0=.f0e822e4-f7ea-40a3-bbe9-60982ba3add4@github.com>
Message-ID: <Rzp4vFOkkujHnNO9uHeW8fQR3TihcCmMFci8SkXHQX4=.670619f0-423a-4ba3-a7a5-28dcfb22ebab@github.com>

On Tue, 29 Apr 2025 01:23:00 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> This test was designed to manually verify that clicking on the JComboBox when the frame containing it is about to close does not cause an IllegalStateException.
>> 
>> The test allowed the tester extra time to click on the JComboBox when closing the frame by adding a Thread.sleep() in the close button handler.
>> 
>> In this test, a JComboBox is displayed with a Close button at the bottom. The tester should click the Close button, then try to click the JComboBox arrow button to display the popup.
>> 
>> In the automated test, we save the JComboBox  location size before closing the frame. We then use this information to click on the JComboBox right before the frame is closed.
>
> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add waitforidle

Marked as reviewed by achung (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/24624#pullrequestreview-2815294443

From achung at openjdk.org  Mon May  5 16:05:46 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 5 May 2025 16:05:46 GMT
Subject: RFR: 8355790: Enhance code consistency: java.desktop/unix:sun.awt
In-Reply-To: <7s8jC8r-uAS3k0NsaKJyhZMzhHVCOFbb-ZStbeBv9Pw=.b78af72d-c17f-4c57-b620-6a630a2aef80@github.com>
References: <7s8jC8r-uAS3k0NsaKJyhZMzhHVCOFbb-ZStbeBv9Pw=.b78af72d-c17f-4c57-b620-6a630a2aef80@github.com>
Message-ID: <21CksyRYKYeR-W0GQ5kwosvFvuBksDze3y5B27mOdwo=.a6ebb462-bd4a-4d41-ae12-9798debc1c8f@github.com>

On Tue, 29 Apr 2025 00:03:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency.
> 
> To make the code review process easier I have made the following changes:
> 
> 1. I chose `java.desktop/unix:sun.awt` as the starting package because it contains a relatively small number of classes
> 2. The public API was not affected so there is no need to worry about a CSR
> 
> Note: I will submit additional patches in this area later because:
> 
> 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797))
> 2. I skipped adding `@Override` for anonymous classes
> 
> Any feedback or suggestions are welcome!
> 
> Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/24941.diff) to a simple diff file, it might be more convenient for reviewing the changes.
> 
> To download the diff file and filter only the modified lines you can use the following script:
> 
> 
> curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/24941.diff -o d.txt && grep -E '^+|^-' d.txt
> 
> 
> The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected by these changes. It would be good to verify this by mach5 to ensure everything works as expected.

I've run the clientlibs tests on mach5 and everything passes.

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

Marked as reviewed by achung (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24941#pullrequestreview-2815311855

From duke at openjdk.org  Mon May  5 17:10:58 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 5 May 2025 17:10:58 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when disposal
 method changes
Message-ID: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>

This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:

1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
2. The transparent pixel is non-zero
3. There's more than one such consecutive frame

Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.

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

Commit messages:
 - 8356137: Fixing non-zero transparent pixel with disposal method 1
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge pull request #5 from openjdk/master
 - Merge pull request #4 from openjdk/master
 - Merge pull request #3 from openjdk/master
 - ... and 2 more: https://git.openjdk.org/jdk/compare/898d4798...5dbf7a11

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

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

From duke at openjdk.org  Mon May  5 17:15:47 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 5 May 2025 17:15:47 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes
In-Reply-To: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
Message-ID: <JZMZ-FMgS3n462ZZC9fJk0zMR6qUk1OC8tDaR1j1Oy8=.d6a35c77-84cd-4fd0-a80b-1bd322169e3a@github.com>

On Mon, 5 May 2025 17:07:11 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
> 
> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
> 2. The transparent pixel is non-zero
> 3. There's more than one such consecutive frame
> 
> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.

For reference, the commented out lines here are my first approach at resolving this problem.

<img width="687" alt="image" src="https://github.com/user-attachments/assets/8caa3372-ee42-412d-959c-6d55d258e4ba" />

This works, and it may be more readable/intuitive than this current PR. When we initialize saved_image we should flood fill it with transparent pixels.

I chose the approach in this PR though because it's lazier. (That is: it should be a little bit less work, CPU-wise.)

If anyone wants we can switch to this approach.

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

PR Comment: https://git.openjdk.org/jdk/pull/25044#issuecomment-2851693643

From prr at openjdk.org  Mon May  5 18:47:49 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 5 May 2025 18:47:49 GMT
Subject: RFR: 8343739: Test
 java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java failed: Wrong
 extended key code [v3]
In-Reply-To: <-VKRExcwuamNGxB1FbvYY_rA-dXICYFodaqiI2QnSe0=.0c5f4481-4016-4333-8360-3c6d519f710b@github.com>
References: <ubVHDLbUmS2V0etEvYlsOVr-1H6ZQxayrQTU4bXxz-o=.075cef8e-5d34-43de-8870-09e6afa4f588@github.com>
 <-VKRExcwuamNGxB1FbvYY_rA-dXICYFodaqiI2QnSe0=.0c5f4481-4016-4333-8360-3c6d519f710b@github.com>
Message-ID: <woWsW8rn-KV-UH3xWvqykkPsPXkn8_0YWkZ_-VXrCUs=.6a69b303-3e14-473d-be5d-ae1ee0394553@github.com>

On Fri, 2 May 2025 17:35:04 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Test was failing on Ubuntu, looks to be a synchronous error in the test so I rewrote it to improve stability.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check eventsCount

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24885#pullrequestreview-2815748937

From prr at openjdk.org  Mon May  5 19:26:47 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 5 May 2025 19:26:47 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v11]
In-Reply-To: <xPGWVGkGW255iwjDoWAhEuLEXVG3lC7D8rZj8ZAMcHE=.067cf490-52e2-44e4-9f9a-fff7e908a220@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
 <741DjI-uVAuf4pjN9MqVaKz2iEI-qr-L9c6KCbP7IlY=.e46c1d54-4b0f-4cc3-b572-043923972212@github.com>
 <mwLvU39Qxbts9_I2MU5oup-aeFVOulBcjRjVvUNKLOI=.4fa7507c-b038-4e87-8dcf-6c6c9f108acc@github.com>
 <lI8-Y3StfMzsltCf-vFdP5Oo-S1h5FRG8p21xRMnbfk=.608efc2d-671c-4a37-bfd8-b5827c9bc6cd@github.com>
 <B4fWQWgcaUcHuz7pi_mJimGbCUWdsHrrDMsN0gvbTA0=.5fb9b028-012f-4da1-ac76-d925b8b64bf2@github.com>
 <UALf_jPu6Pju8jgD51nERwQnJXLjM0u5XrthhB26M9g=.dde004fc-0a73-408d-b9ab-d9f21e71a006@github.com>
 <QqY_tCRd6FxeEGOHL86BRxcgP_avpOnBK_JtuMzTeHU=.81163bd7-f6ba-4c43-b281-356566e8af69@github.com>
 <zye9iVM8AK70RuqU_2nm4evvJavym_cl3s2s-HDrBvk=.09c36435-63ea-4bee-adb1-ffc6f7124b41@github.com>
 <6A6RT3ZqccBhAhdhEaSDc3Ri0yUWw61Alc2xbYHtXfI=.24af6c9c-b6b8-4f3e-a4c6-61143685eef2@github.com>
 <xPGWVGkGW255iwjDoWAhEuLEXVG3lC7D8rZ
 j8ZAMcHE=.067cf490-52e2-44e4-9f9a-fff7e908a220@github.com>
Message-ID: <we7CVGOf0v6qdH3wvbH4Dro986V_0YYVExf7CIfmQ8o=.cc2b2e29-3c47-441c-9334-360ca9619482@github.com>

On Sun, 4 May 2025 20:52:47 GMT, Alisen Chung <achung at openjdk.org> wrote:

> > > So this seems to be a bug in macOS, as the reported mouse location is incorrect while it is actually positioned at the edge?
> > > Probably, there are other macOS APIs that could be used to implement Java_sun_lwawt_macosx_CCursorManager_nativeGetCursorPosition. Or perhaps the methods within it should be called on the appkit thread - I see a potential race, since the mouse is moved asynchronously on appkit, but the coordinates are fetched on the current thread.
> > 
> > 
> > Did you have a chance to check our implementation of setting and getting the cursor?
> 
> I took a look at the cocoa documentation and I wasn't able to find any APIs that handle clamping. I also looked at our implementation: we create an empty mouse event then grab the location of that event. Since macOS doesn't do clamping, we would need to add clamping code to nativeGetCursorPosition after we grab the location of that empty event. I think it's easier to just do the clamping in CRobot on mouseMove instead since that would be the only way for the mouse to initially reach out of bounds. What do you think?

I (we) looked at the code that was reporting the off-screen mouse position several weeks ago.
What we are doing seems to correspond to all the suggestions on the internet as to how to get mouse position on macOS.
I didn't spot any obvious alternative.

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

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2852102362

From serb at openjdk.org  Mon May  5 22:48:20 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 5 May 2025 22:48:20 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v11]
In-Reply-To: <we7CVGOf0v6qdH3wvbH4Dro986V_0YYVExf7CIfmQ8o=.cc2b2e29-3c47-441c-9334-360ca9619482@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
 <741DjI-uVAuf4pjN9MqVaKz2iEI-qr-L9c6KCbP7IlY=.e46c1d54-4b0f-4cc3-b572-043923972212@github.com>
 <mwLvU39Qxbts9_I2MU5oup-aeFVOulBcjRjVvUNKLOI=.4fa7507c-b038-4e87-8dcf-6c6c9f108acc@github.com>
 <lI8-Y3StfMzsltCf-vFdP5Oo-S1h5FRG8p21xRMnbfk=.608efc2d-671c-4a37-bfd8-b5827c9bc6cd@github.com>
 <B4fWQWgcaUcHuz7pi_mJimGbCUWdsHrrDMsN0gvbTA0=.5fb9b028-012f-4da1-ac76-d925b8b64bf2@github.com>
 <UALf_jPu6Pju8jgD51nERwQnJXLjM0u5XrthhB26M9g=.dde004fc-0a73-408d-b9ab-d9f21e71a006@github.com>
 <QqY_tCRd6FxeEGOHL86BRxcgP_avpOnBK_JtuMzTeHU=.81163bd7-f6ba-4c43-b281-356566e8af69@github.com>
 <zye9iVM8AK70RuqU_2nm4evvJavym_cl3s2s-HDrBvk=.09c36435-63ea-4bee-adb1-ffc6f7124b41@github.com>
 <6A6RT3ZqccBhAhdhEaSDc3Ri0yUWw61Alc2xbYHtXfI=.24af6c9c-b6b8-4f3e-a4c6-61143685eef2@github.com>
 <xPGWVGkGW255iwjDoWAhEuLEXVG3lC7D8rZ
 j8ZAMcHE=.067cf490-52e2-44e4-9f9a-fff7e908a220@github.com>
 <we7CVGOf0v6qdH3wvbH4Dro986V_0YYVExf7CIfmQ8o=.cc2b2e29-3c47-441c-9334-360ca9619482@github.com>
Message-ID: <qQtGLrMW9zimjehHP3hyWkt6IE9_kaylDWI1XZ9hNrk=.db59639d-87dc-4cf8-90a7-6c4557184bcc@github.com>

On Mon, 5 May 2025 19:23:49 GMT, Phil Race <prr at openjdk.org> wrote:

> (we) looked at the code that was reporting the off-screen mouse position several weeks ago.
> What we are doing seems to correspond to all the suggestions on the internet as to how to get mouse position on macOS.
> I didn't spot any obvious alternative.

Previously, we used a different method, which might behave differently (It also used a different thread):
https://github.com/openjdk/jdk/commit/eea06f70fc6154be12d066df6669e7c6d8c0bc09#diff-698576e56937835cfc553bbd97fe12fabf954e0a20e7b9c3bfc3a77763fb6bd0L123

I propose developing a native reproducer to investigate the mouse position clamping behavior observed on macOS. The steps would include:
1. Moving the mouse cursor outside the screen bounds.
2. Retrieving the current mouse position.
3. Simulating a mouse click at the current position.
4. Retrieving the mouse position again.
5. Comparing the positions from steps 2 and 4.

If the positions differ, we can ask Apple on the following points:
1. Is the clamping of the mouse position during a click an intentional behavior or a bug?
2. If intentional, what is the recommended method for applications to replicate this clamping behavior?
3. If it is a feature intended to be used by certain applications, should we consider bypassing this behavior in the JDK?

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

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2852542797

From honkar at openjdk.org  Tue May  6 00:03:16 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 6 May 2025 00:03:16 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
Message-ID: <ZgTFzsooBxN-wUCWHshZzk6ntx-q73m8o9U9JkF1iFU=.d9c56bb3-90fb-4714-93fc-61e1ea6ad2ff@github.com>

On Mon, 17 Feb 2025 14:06:53 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
> 
> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
> 
> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
> 
> The new test class passes on Linux, Windows and macOS.

src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java line 138:

> 136:         return code == 0x0009 || code == 0x000a || code == 0x000d;
> 137:     }
> 138: 

@prrace @gredler 
Following is an existing issue NOT related to the recent harfbuzz upgrade PR nor this issue fix but it is similar in nature so a separate JBS issue can be created to handle it. I wanted to discuss it before integrating the HB upgrade tomorrow.

There seems to be similar issue on windows and linux where the hexcode - 0x2028 (line separator) and 0x2029 (paragraph separator) that are shown with a non-zero advance - `/java/awt/font/TextLayout/TestControls.java`

**On Windows:**

<img width="287" alt="image" src="https://github.com/user-attachments/assets/9eec9009-e3a5-49be-b505-619d041bfa3b" />

**On Linux:**

<img width="272" alt="image" src="https://github.com/user-attachments/assets/73a56d6d-53ec-4d6f-ad49-6fc13bdceea0" />


If adding these codes (0x2028, 0x2029) to platform specific src code (I believe it is NativeGlyphMapper (linux) and WPathGraphics (windows)) fixes the above issue then should we consider moving isIgnorableWhitespace() to common class - `CharToGlyphMapper` instead of macOS specific src?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2074388646

From honkar at openjdk.org  Tue May  6 00:13:16 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 6 May 2025 00:13:16 GMT
Subject: RFR: JDK-8355528 : Update HarfBuzz to 11.2.0
In-Reply-To: <Hb0Zrb1imoj4Fsa_fHkLuCd_AwtWnIoYeLVqGGqXyX8=.af777007-90a4-475b-92bc-eb005597e95c@github.com>
References: <OYvCAf8MTYtEoexbi05jUZAp1soN20wD9NIHFjIF594=.c5ea11eb-aaf8-41f1-84df-76da1b902654@github.com>
 <Hb0Zrb1imoj4Fsa_fHkLuCd_AwtWnIoYeLVqGGqXyX8=.af777007-90a4-475b-92bc-eb005597e95c@github.com>
Message-ID: <rUfM9do2YsZoh6FqMhDPzea7KbR_7NpK-xxdCV1W7gM=.785fdc91-6ef1-419a-bf9b-b63634dd5959@github.com>

On Sun, 4 May 2025 21:00:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Just a quick question since usually the third party upgrades I've done don't include new files, did you check that the files are needed for jdk?

Yes, only those new files are added from upstream as required to make JDK build successful.

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

PR Comment: https://git.openjdk.org/jdk/pull/24973#issuecomment-2852806939

From serb at openjdk.org  Tue May  6 00:18:00 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 May 2025 00:18:00 GMT
Subject: RFR: 8356053: Test java/awt/Toolkit/Headless/HeadlessToolkit.java
 fails by timeout
Message-ID: <rSxJ8yhJauBlv1dbHab2d61J46SjG7-54OvIaBtCteU=.354eaf8c-8257-4147-b45b-c7045755424a@github.com>

The `java/awt/Toolkit/Headless/HeadlessToolkit.java` test covers some functionality of various methods in the `HeadlessToolkit` class, specifically whether these methods throw a `HeadlessException` or not. The image-related methods do not require access to a remote server via a URL; they can be tested using a URL pointing to a local file. This ensures that the test does not depend on `openjdk.org`.

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

Commit messages:
 - 8356053: Test java/awt/Toolkit/Headless/HeadlessToolkit.java fails by timeout

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

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

From serb at openjdk.org  Tue May  6 02:45:20 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 May 2025 02:45:20 GMT
Subject: RFR: 8356208: Remove obsolete code in PSPrinterJob for plugin
 printing
In-Reply-To: <HbEWUYGs_6niHSFnJan9hIwnIYW5hd5mGnicHW_w3I4=.bb6f5c0e-e183-4165-8d98-bc1552ae5a00@github.com>
References: <HbEWUYGs_6niHSFnJan9hIwnIYW5hd5mGnicHW_w3I4=.bb6f5c0e-e183-4165-8d98-bc1552ae5a00@github.com>
Message-ID: <Xr76_hNUUICa3OlkDbs629QcJnqopTCEMENfL-Qv5S0=.9cc6cf2b-a8c0-4a30-83c8-e4f442636b80@github.com>

On Mon, 5 May 2025 18:55:47 GMT, Phil Race <prr at openjdk.org> wrote:

> Delete the obsolete classes PluginPrinter and EPSPrinter. They were only ever called by the Java Plugin printing for applets.

src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 272:

> 270:    /* non-null if printing EPS for Java Plugin */
> 271:    private EPSPrinter epsPrinter = null;
> 272: 

This looks fine, but what about all unused xx_MASK and xx_SHIFT and hexDigits at the start of this class? and unused escapeParens() and mCurMetrics below?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25047#discussion_r2074653014

From mvs at openjdk.org  Tue May  6 02:54:25 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 6 May 2025 02:54:25 GMT
Subject: Integrated: 8288471: java/awt/ScrollPane/bug8077409Test.java is
 unstable and fails intermittently in CI
In-Reply-To: <biMzqs33OmQ3OG6eduDmGw15gxdN01HH61vgYqVhosk=.80c0d3c9-65f3-40fc-8e40-a56882f98dc9@github.com>
References: <biMzqs33OmQ3OG6eduDmGw15gxdN01HH61vgYqVhosk=.80c0d3c9-65f3-40fc-8e40-a56882f98dc9@github.com>
Message-ID: <qfj3tqdJJKWy2Lx_0CAAiMbCA-WAzrnDzDgFGNQYGrM=.897b0ada-5d35-4bba-98ec-ca8ba548c01d@github.com>

On Fri, 28 Mar 2025 11:09:03 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> java/awt/ScrollPane/bug8077409Test.java is unstable and fails intermittently in CI, especially in MacOS machines.
> Also the frame created in this test is not disposed which may interfere with other tests.
> 
> Fix:
> Some stabilisations added and the frame is disposed properly.
> 
> Testing:
> Tested 100 times per platform(macosx-x64,macosx-aarch64,windows-x64,linux-x64) and got all PASS.
> I have also tested this on Windows-x64 with JDK 8u60b04 and JDK 8u60b20 as the original issue related to this test(JDK-8077409) was fixed in JDK 8u60b20.
> With JDK 8u60b04:
> Exception in thread "main" java.lang.RuntimeException: Wrong position of component in ScrollPane
>         at bug8077409Test.main(bug8077409Test.java:142)
> 
> With JDK 8u60b20:
> Passed.....

This pull request has now been integrated.

Changeset: e09d2e27
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e09d2e275bc646201a8da39bd4b977d3fda97954
Stats:     98 lines in 1 file changed: 23 ins; 40 del; 35 mod

8288471: java/awt/ScrollPane/bug8077409Test.java is unstable and fails intermittently in CI

Reviewed-by: abhiscxk, serb

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

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

From aturbanov at openjdk.org  Tue May  6 09:11:18 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 6 May 2025 09:11:18 GMT
Subject: RFR: 8356208: Remove obsolete code in PSPrinterJob for plugin
 printing
In-Reply-To: <HbEWUYGs_6niHSFnJan9hIwnIYW5hd5mGnicHW_w3I4=.bb6f5c0e-e183-4165-8d98-bc1552ae5a00@github.com>
References: <HbEWUYGs_6niHSFnJan9hIwnIYW5hd5mGnicHW_w3I4=.bb6f5c0e-e183-4165-8d98-bc1552ae5a00@github.com>
Message-ID: <ly_Z_9zCuSDFrwY_kaTYpraDxVS-kPP2D2ADhGB7UaQ=.6f0edd70-1705-49fc-83d7-f89fd2134575@github.com>

On Mon, 5 May 2025 18:55:47 GMT, Phil Race <prr at openjdk.org> wrote:

> Delete the obsolete classes PluginPrinter and EPSPrinter. They were only ever called by the Java Plugin printing for applets.

src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 533:

> 531:                 try {
> 532:                     spoolFile = new File(mDestination);
> 533:                     output =  new FileOutputStream(spoolFile);

Suggestion:

                    output = new FileOutputStream(spoolFile);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25047#discussion_r2075050472

From myankelevich at openjdk.org  Tue May  6 10:48:16 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 6 May 2025 10:48:16 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes
In-Reply-To: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
Message-ID: <ALs8YcxNg6TsL8l6TEJc-wArIUt4j1CiT7VS-0Kke_I=.e635a990-fd23-4205-96a6-3d2f24e8e219@github.com>

On Mon, 5 May 2025 17:07:11 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
> 
> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
> 2. The transparent pixel is non-zero
> 3. There's more than one such consecutive frame
> 
> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.

Just a few questions.

Also, a copyright in GifImageDecoder.java

test/jdk/sun/awt/image/gif/bug8356137/GifEmptyBackgroundTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2002, 2025, Oracle and/or its affiliates. All rights reserved.

Nitpick: do you need 2002 here? Isn't it a new file?

test/jdk/sun/awt/image/gif/bug8356137/GifEmptyBackgroundTest.java line 28:

> 26:  * @bug 8356137
> 27:  * @summary This test verifies a non-zero transparent pixel in gifs works when
> 28:  * the disposal method changes from 2 to 1, and when the

Nitpick: Do you need the `, and when the` ? ?

test/jdk/sun/awt/image/gif/bug8356137/GifEmptyBackgroundTest.java line 51:

> 49:         boolean pass = true;
> 50:         if (new Color(frames[3].getRGB(20, 20), true).getAlpha() != 0) {
> 51:             System.err.println("Sampling at (20,20) failed");

Do you think it would be cleaner if you jsut throw a `RuntimeException("Sampling at (20,20) failed");` instead of the whole

 System.err.println("Sampling at (20,20) failed");
  pass = false;
        }

        if (!pass)
            throw new Error("See System.err for details");

? 
It should result in the same level of details but with better readability imo

test/jdk/sun/awt/image/gif/bug8356137/GifEmptyBackgroundTest.java line 105:

> 103:                     // we don't expect this to happen, but if something goes
> 104:                     // wrong nobody else will print our stacktrace for us:
> 105:                     e.printStackTrace();

Do you need this print here? Runtime exception should print it out anyway to the system.error afaik

test/jdk/sun/awt/image/gif/bug8356137/GifEmptyBackgroundTest.java line 133:

> 131:                     }
> 132:                 } catch(Exception e) {
> 133:                     e.printStackTrace();

Do you need to print out the stack trace here when you are throwing it below?

test/jdk/sun/awt/image/gif/bug8356137/GifEmptyBackgroundTest.java line 143:

> 141:         return returnValue.toArray(new BufferedImage[0]);
> 142:     }
> 143: }

nitpick: could you please add a new line here for github? ?

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

PR Review: https://git.openjdk.org/jdk/pull/25044#pullrequestreview-2817764726
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2075186796
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2075200131
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2075190122
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2075197940
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2075193365
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2075192144

From ihse at openjdk.org  Tue May  6 14:16:32 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 14:16:32 GMT
Subject: RFR: 8354273: Replace even more Unicode characters with ASCII [v3]
In-Reply-To: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
References: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
Message-ID: <Ynl7ATLqF5wm7um0BI3RwZC2IO9VObO1blOBXNny1Sk=.0fedb3c5-dd77-4123-82a8-ecde62b4f01f@github.com>

> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII.

Magnus Ihse Bursie 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' into restore-more-ascii
 - Remove incorrectly copied "?anchor"
 - 8354273: Restore even more pointless unicode characters to ASCII

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24567/files
  - new: https://git.openjdk.org/jdk/pull/24567/files/876708c2..a07ef96d

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

  Stats: 273049 lines in 2453 files changed: 80961 ins; 183018 del; 9070 mod
  Patch: https://git.openjdk.org/jdk/pull/24567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24567/head:pull/24567

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

From ihse at openjdk.org  Tue May  6 15:39:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 15:39:24 GMT
Subject: RFR: 8354273: Replace even more Unicode characters with ASCII [v3]
In-Reply-To: <Ynl7ATLqF5wm7um0BI3RwZC2IO9VObO1blOBXNny1Sk=.0fedb3c5-dd77-4123-82a8-ecde62b4f01f@github.com>
References: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
 <Ynl7ATLqF5wm7um0BI3RwZC2IO9VObO1blOBXNny1Sk=.0fedb3c5-dd77-4123-82a8-ecde62b4f01f@github.com>
Message-ID: <NO4E3P79QlBsrC6zcQwwbnA4FgXHvAaMZXAwucxFtps=.7f0248af-a382-4f2d-a5c8-ebb1af37e5bd@github.com>

On Tue, 6 May 2025 14:16:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII.
>
> Magnus Ihse Bursie 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' into restore-more-ascii
>  - Remove incorrectly copied "?anchor"
>  - 8354273: Restore even more pointless unicode characters to ASCII

Ping?

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

PR Comment: https://git.openjdk.org/jdk/pull/24567#issuecomment-2855052189

From naoto at openjdk.org  Tue May  6 16:45:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 May 2025 16:45:26 GMT
Subject: RFR: 8354273: Replace even more Unicode characters with ASCII [v3]
In-Reply-To: <Ynl7ATLqF5wm7um0BI3RwZC2IO9VObO1blOBXNny1Sk=.0fedb3c5-dd77-4123-82a8-ecde62b4f01f@github.com>
References: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
 <Ynl7ATLqF5wm7um0BI3RwZC2IO9VObO1blOBXNny1Sk=.0fedb3c5-dd77-4123-82a8-ecde62b4f01f@github.com>
Message-ID: <i7yFd48vuJdikLZgeiz-IA4ww7ecKEDHrgLWiE_P7Oo=.fc92ab9b-8fc2-480d-81e5-61be832f6014@github.com>

On Tue, 6 May 2025 14:16:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII.
>
> Magnus Ihse Bursie 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' into restore-more-ascii
>  - Remove incorrectly copied "?anchor"
>  - 8354273: Restore even more pointless unicode characters to ASCII

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24567#pullrequestreview-2818989660

From aivanov at openjdk.org  Tue May  6 16:52:16 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 6 May 2025 16:52:16 GMT
Subject: RFR: 8354219 : Automate javax/swing/JComboBox/ComboPopupBug.java
 [v9]
In-Reply-To: <BcDXCPcF6T5egm85rR4pqCpYrHVuHa2740zH32j84a0=.f0e822e4-f7ea-40a3-bbe9-60982ba3add4@github.com>
References: <xleWDjAur8VerD-q0QvQXfiRoXCDJk0ZsunhHWV72W4=.ed62e2f7-42ca-4153-b92a-39c358f5d6b6@github.com>
 <BcDXCPcF6T5egm85rR4pqCpYrHVuHa2740zH32j84a0=.f0e822e4-f7ea-40a3-bbe9-60982ba3add4@github.com>
Message-ID: <UIEIWUw1m8KSnPJTl1vmI-j5TYQ34SwYzI1kJUL-Vv4=.76b28ead-a243-40e5-845b-5e632cd6a9e6@github.com>

On Tue, 29 Apr 2025 01:23:00 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> This test was designed to manually verify that clicking on the JComboBox when the frame containing it is about to close does not cause an IllegalStateException.
>> 
>> The test allowed the tester extra time to click on the JComboBox when closing the frame by adding a Thread.sleep() in the close button handler.
>> 
>> In this test, a JComboBox is displayed with a Close button at the bottom. The tester should click the Close button, then try to click the JComboBox arrow button to display the popup.
>> 
>> In the automated test, we save the JComboBox  location size before closing the frame. We then use this information to click on the JComboBox right before the frame is closed.
>
> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add waitforidle

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24624#pullrequestreview-2819005904

From honkar at openjdk.org  Tue May  6 16:53:25 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 6 May 2025 16:53:25 GMT
Subject: Integrated: JDK-8355528 : Update HarfBuzz to 11.2.0
In-Reply-To: <OYvCAf8MTYtEoexbi05jUZAp1soN20wD9NIHFjIF594=.c5ea11eb-aaf8-41f1-84df-76da1b902654@github.com>
References: <OYvCAf8MTYtEoexbi05jUZAp1soN20wD9NIHFjIF594=.c5ea11eb-aaf8-41f1-84df-76da1b902654@github.com>
Message-ID: <xb_-MR_79QR3wjE98xZR3LiwvTD7YnBnVGG2xoMvEU8=.bb6bc78a-562f-4854-9aca-0f8759a71636@github.com>

On Wed, 30 Apr 2025 19:37:29 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> HarfBuzz upgraded to 11.2.0
> 
> 4 newly added files and 99 modified files.

This pull request has now been integrated.

Changeset: b21b3a38
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b21b3a38a5dbc7eb23c4bd1fd5c0900a3a1b470b
Stats:     7130 lines in 104 files changed: 3723 ins; 2257 del; 1150 mod

8355528: Update HarfBuzz to 11.2.0

Reviewed-by: dnguyen, prr

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

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

From duke at openjdk.org  Tue May  6 16:55:16 2025
From: duke at openjdk.org (duke)
Date: Tue, 6 May 2025 16:55:16 GMT
Subject: RFR: 8354219 : Automate javax/swing/JComboBox/ComboPopupBug.java
 [v9]
In-Reply-To: <BcDXCPcF6T5egm85rR4pqCpYrHVuHa2740zH32j84a0=.f0e822e4-f7ea-40a3-bbe9-60982ba3add4@github.com>
References: <xleWDjAur8VerD-q0QvQXfiRoXCDJk0ZsunhHWV72W4=.ed62e2f7-42ca-4153-b92a-39c358f5d6b6@github.com>
 <BcDXCPcF6T5egm85rR4pqCpYrHVuHa2740zH32j84a0=.f0e822e4-f7ea-40a3-bbe9-60982ba3add4@github.com>
Message-ID: <h-COqIQ2c3Xz9Y6t8r8JesTzMvMXc1EQsUI-ijxkdsE=.6fa6d9d2-3ef9-495f-bb51-cdd6c24e5a6c@github.com>

On Tue, 29 Apr 2025 01:23:00 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> This test was designed to manually verify that clicking on the JComboBox when the frame containing it is about to close does not cause an IllegalStateException.
>> 
>> The test allowed the tester extra time to click on the JComboBox when closing the frame by adding a Thread.sleep() in the close button handler.
>> 
>> In this test, a JComboBox is displayed with a Close button at the bottom. The tester should click the Close button, then try to click the JComboBox arrow button to display the popup.
>> 
>> In the automated test, we save the JComboBox  location size before closing the frame. We then use this information to click on the JComboBox right before the frame is closed.
>
> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add waitforidle

@anass-baya 
Your change (at version ae836194f01f6622f0e7aba415cc2ab5b254b989) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24624#issuecomment-2855285542

From duke at openjdk.org  Tue May  6 17:13:56 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Tue, 6 May 2025 17:13:56 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v2]
In-Reply-To: <ALs8YcxNg6TsL8l6TEJc-wArIUt4j1CiT7VS-0Kke_I=.e635a990-fd23-4205-96a6-3d2f24e8e219@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
 <ALs8YcxNg6TsL8l6TEJc-wArIUt4j1CiT7VS-0Kke_I=.e635a990-fd23-4205-96a6-3d2f24e8e219@github.com>
Message-ID: <bVoWuvH7ifihsk_qhgx8_TIqNMgPrUtoOeRJHCR4O3M=.5495f08e-8280-48b6-bd04-dcd4bc51f012@github.com>

On Tue, 6 May 2025 10:33:47 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - 8356137: removing sentence fragment
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25044#discussion_r2075200131
>>  - 8356137: fixing typo
>>  - 8356137: adding empty line at bottom of file
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25044#discussion_r2075192144
>>  - 8356137: removing layered pass/fail pattern
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25044#discussion_r2075190122
>>  - 8356137: removing (c) 2002
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25044#discussion_r2075186796
>
> test/jdk/sun/awt/image/gif/bug8356137/GifEmptyBackgroundTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2002, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Nitpick: do you need 2002 here? Isn't it a new file?

OK, this is removed

> test/jdk/sun/awt/image/gif/bug8356137/GifEmptyBackgroundTest.java line 51:
> 
>> 49:         boolean pass = true;
>> 50:         if (new Color(frames[3].getRGB(20, 20), true).getAlpha() != 0) {
>> 51:             System.err.println("Sampling at (20,20) failed");
> 
> Do you think it would be cleaner if you jsut throw a `RuntimeException("Sampling at (20,20) failed");` instead of the whole
> 
>  System.err.println("Sampling at (20,20) failed");
>   pass = false;
>         }
> 
>         if (!pass)
>             throw new Error("See System.err for details");
> 
> ? 
> It should result in the same level of details but with better readability imo

I don't have a strong opinion; this is removed. (I often follow that pattern in case I try to add multiple criteria to pass/fail decisions.)

> test/jdk/sun/awt/image/gif/bug8356137/GifEmptyBackgroundTest.java line 143:
> 
>> 141:         return returnValue.toArray(new BufferedImage[0]);
>> 142:     }
>> 143: }
> 
> nitpick: could you please add a new line here for github? ?

OK, this is updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2075926075
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2075926374
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2075926503

From duke at openjdk.org  Tue May  6 17:13:56 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Tue, 6 May 2025 17:13:56 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v2]
In-Reply-To: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
Message-ID: <m631GoZrBYsPTTCYra3Y7YkOaAXnK2PM_H3T_QYzNXU=.16f6cb98-8d2d-4772-b6fa-91c656b5f33b@github.com>

> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
> 
> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
> 2. The transparent pixel is non-zero
> 3. There's more than one such consecutive frame
> 
> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.

Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision:

 - 8356137: removing sentence fragment
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#discussion_r2075200131
 - 8356137: fixing typo
 - 8356137: adding empty line at bottom of file
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#discussion_r2075192144
 - 8356137: removing layered pass/fail pattern
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#discussion_r2075190122
 - 8356137: removing (c) 2002
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#discussion_r2075186796

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25044/files
  - new: https://git.openjdk.org/jdk/pull/25044/files/5dbf7a11..925d558c

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

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

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

From duke at openjdk.org  Tue May  6 17:17:19 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Tue, 6 May 2025 17:17:19 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v2]
In-Reply-To: <ALs8YcxNg6TsL8l6TEJc-wArIUt4j1CiT7VS-0Kke_I=.e635a990-fd23-4205-96a6-3d2f24e8e219@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
 <ALs8YcxNg6TsL8l6TEJc-wArIUt4j1CiT7VS-0Kke_I=.e635a990-fd23-4205-96a6-3d2f24e8e219@github.com>
Message-ID: <drdsAgyiWqCeAik17Tg1TQToP7I0k-H-aF_ftyVerms=.7836ba4e-9e43-4c0c-b929-404941d4f7f4@github.com>

On Tue, 6 May 2025 10:43:02 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - 8356137: removing sentence fragment
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25044#discussion_r2075200131
>>  - 8356137: fixing typo
>>  - 8356137: adding empty line at bottom of file
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25044#discussion_r2075192144
>>  - 8356137: removing layered pass/fail pattern
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25044#discussion_r2075190122
>>  - 8356137: removing (c) 2002
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25044#discussion_r2075186796
>
> test/jdk/sun/awt/image/gif/bug8356137/GifEmptyBackgroundTest.java line 28:
> 
>> 26:  * @bug 8356137
>> 27:  * @summary This test verifies a non-zero transparent pixel in gifs works when
>> 28:  * the disposal method changes from 2 to 1, and when the
> 
> Nitpick: Do you need the `, and when the` ? ?

Thanks, this is updated

> test/jdk/sun/awt/image/gif/bug8356137/GifEmptyBackgroundTest.java line 105:
> 
>> 103:                     // we don't expect this to happen, but if something goes
>> 104:                     // wrong nobody else will print our stacktrace for us:
>> 105:                     e.printStackTrace();
> 
> Do you need this print here? Runtime exception should print it out anyway to the system.error afaik

Yes, because this eventually is caught here in GifImageDecoder.java:

                    try {
                        if (!readImage(totalframes == 0,
                                       disposal_method,
                                       delay)) {
                            return;
                        }
                    } catch (Exception e) {
                        if (verbose) {
                            e.printStackTrace();
                        }
                        return;
                    }


In this specific test file: I never expect an exception to be thrown, but one did come up when I was first drafting this test (because of my own error). It was hard to debug because it was unreported. I would prefer to leave these printStackTrace calls in, in case a developer someday makes a change and needs to see potential errors.

(Technically I could try to make verbose `true`, but that's declared as a final variable and I don't want to modify GifImageDecoder.java just for this.)

> test/jdk/sun/awt/image/gif/bug8356137/GifEmptyBackgroundTest.java line 133:
> 
>> 131:                     }
>> 132:                 } catch(Exception e) {
>> 133:                     e.printStackTrace();
> 
> Do you need to print out the stack trace here when you are throwing it below?

Yes, this is caught in the same place the other one is ( https://github.com/openjdk/jdk/pull/25044#discussion_r2075930867 )

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2075932570
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2075930867
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2075932044

From ihse at openjdk.org  Tue May  6 18:03:22 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 18:03:22 GMT
Subject: Integrated: 8354273: Replace even more Unicode characters with ASCII
In-Reply-To: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
References: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
Message-ID: <ozQlBoLORphUUvXLzjs_gDH9cMgvcJVlVzgbt3b6pR0=.df8da50a-67f9-4ee4-b87f-52b49445cefb@github.com>

On Thu, 10 Apr 2025 10:18:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII.

This pull request has now been integrated.

Changeset: 08dd4a75
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08dd4a75c5b751a66d2e088b0ec9c6d6c443c14a
Stats:     11 lines in 8 files changed: 0 ins; 1 del; 10 mod

8354273: Replace even more Unicode characters with ASCII

Reviewed-by: naoto

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

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

From mblaesing at openjdk.org  Tue May  6 18:09:29 2025
From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=)
Date: Tue, 6 May 2025 18:09:29 GMT
Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v2]
In-Reply-To: <HYQ237abKwF9M1jfKX3VQG_ytVIfbXo_m3OioPFbd4s=.f1ecbd3e-c630-457d-8b78-73292bbb39d4@github.com>
References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com>
 <HYQ237abKwF9M1jfKX3VQG_ytVIfbXo_m3OioPFbd4s=.f1ecbd3e-c630-457d-8b78-73292bbb39d4@github.com>
Message-ID: <XConyZW_uUsgs_MJ70uP3wAMVE-lvltzi5RaD6yzAHE=.c051bf2c-ebd3-440e-86db-037a0457132c@github.com>

On Mon, 14 Apr 2025 17:19:19 GMT, Matthias Bl?sing <mblaesing at openjdk.org> wrote:

>> - Introduce a lock into WClipboard that protects the code between
>>   openClipboard/closeClipboard invocations.
>>   The native side does not allow to open the clipboard multiple
>>   times or share the opened clipboard between multiple threads.
>> 
>> - Remove of need to call openClipboard/closeClipboard from
>>   getClipboardFormats by using the win32 call
>>   GetUpdatedClipboardFormats
>> 
>> - Prevent a race-condition by not registering the connection
>>   between java and native side of clipboard multiple time, but
>>   just at construction time.
>
> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adress review comments: Update copyright years and fix whitespace in if condition

It would be great to get a review on this. While the issues are "only" P-3 and P-4, the issues leave a very bad image for java on windows. Copy-and-Paste should just work and not fail randomly and maybe even crash the VM.

The issue is serious enough for NetBeans, that it will ship a java agent to work around this problem, but that will not implement this change here and is clearly not an option in the long run and thus this needs a real fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/24614#issuecomment-2855480128

From prr at openjdk.org  Tue May  6 18:37:31 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 May 2025 18:37:31 GMT
Subject: RFR: 8356208: Remove obsolete code in PSPrinterJob for plugin
 printing [v2]
In-Reply-To: <HbEWUYGs_6niHSFnJan9hIwnIYW5hd5mGnicHW_w3I4=.bb6f5c0e-e183-4165-8d98-bc1552ae5a00@github.com>
References: <HbEWUYGs_6niHSFnJan9hIwnIYW5hd5mGnicHW_w3I4=.bb6f5c0e-e183-4165-8d98-bc1552ae5a00@github.com>
Message-ID: <qWEXDjdN82ypTUbyKMdsNfx0rabfTAx-nCY2UIlfvHE=.1307aedc-36dc-464b-ada5-1f485e3f1dee@github.com>

> Delete the obsolete classes PluginPrinter and EPSPrinter. They were only ever called by the Java Plugin printing for applets.

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

  8356208

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25047/files
  - new: https://git.openjdk.org/jdk/pull/25047/files/1981c859..608deb19

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

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

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

From prr at openjdk.org  Tue May  6 18:37:32 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 May 2025 18:37:32 GMT
Subject: RFR: 8356208: Remove obsolete code in PSPrinterJob for plugin
 printing [v2]
In-Reply-To: <Xr76_hNUUICa3OlkDbs629QcJnqopTCEMENfL-Qv5S0=.9cc6cf2b-a8c0-4a30-83c8-e4f442636b80@github.com>
References: <HbEWUYGs_6niHSFnJan9hIwnIYW5hd5mGnicHW_w3I4=.bb6f5c0e-e183-4165-8d98-bc1552ae5a00@github.com>
 <Xr76_hNUUICa3OlkDbs629QcJnqopTCEMENfL-Qv5S0=.9cc6cf2b-a8c0-4a30-83c8-e4f442636b80@github.com>
Message-ID: <ChjmDxYlw0GLUUREbLjFmDL8AtMNBCgbtmovbZBItIc=.39fc6637-2e63-491a-93a5-6dd09657fc0f@github.com>

On Tue, 6 May 2025 02:42:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356208
>
> src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 272:
> 
>> 270:    /* non-null if printing EPS for Java Plugin */
>> 271:    private EPSPrinter epsPrinter = null;
>> 272: 
> 
> This looks fine, but what about all unused xx_MASK and xx_SHIFT and hexDigits at the start of this class? and unused escapeParens() and mCurMetrics below?

I guess un-related to what I was deleting but I will add it in as these can't have been used in a long time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25047#discussion_r2076044668

From prr at openjdk.org  Tue May  6 18:37:32 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 May 2025 18:37:32 GMT
Subject: RFR: 8356208: Remove obsolete code in PSPrinterJob for plugin
 printing [v2]
In-Reply-To: <ly_Z_9zCuSDFrwY_kaTYpraDxVS-kPP2D2ADhGB7UaQ=.6f0edd70-1705-49fc-83d7-f89fd2134575@github.com>
References: <HbEWUYGs_6niHSFnJan9hIwnIYW5hd5mGnicHW_w3I4=.bb6f5c0e-e183-4165-8d98-bc1552ae5a00@github.com>
 <ly_Z_9zCuSDFrwY_kaTYpraDxVS-kPP2D2ADhGB7UaQ=.6f0edd70-1705-49fc-83d7-f89fd2134575@github.com>
Message-ID: <kITz9Nug2N8TD2vL7JVZ-sPjSY7Mfx4usHOLbEtxnZQ=.d86fdda2-64c0-4b9b-93cc-3bbf4c45d932@github.com>

On Tue, 6 May 2025 09:08:35 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356208
>
> src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 533:
> 
>> 531:                 try {
>> 532:                     spoolFile = new File(mDestination);
>> 533:                     output =  new FileOutputStream(spoolFile);
> 
> Suggestion:
> 
>                     output = new FileOutputStream(spoolFile);

pre-existing but I guess I can do it since I'm pushing another commit for the other stuff to delete.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25047#discussion_r2076045625

From prr at openjdk.org  Tue May  6 19:13:13 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 May 2025 19:13:13 GMT
Subject: RFR: 8355561: [macos] Build failure with Xcode 16.3
In-Reply-To: <IZmniCs0dWQCtAS3-Mg9rRRNpoer26TkCr9EzRXKpVM=.f8c5269c-aa8f-4ecd-a6bb-517cf3a1fc3b@github.com>
References: <IZmniCs0dWQCtAS3-Mg9rRRNpoer26TkCr9EzRXKpVM=.f8c5269c-aa8f-4ecd-a6bb-517cf3a1fc3b@github.com>
Message-ID: <YR6qmO1vAcMBziqmcceGgvpAJtD1-9S9bX8MdsR0ekk=.78e007dd-13db-4536-bccc-6c6a8b9c0809@github.com>

On Mon, 28 Apr 2025 19:47:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Multiple similar issues detected in PLATFORM_API_MacOSX_Ports.cpp more info about https://github.com/llvm/llvm-project/issues/62836
> 
> jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>   127 | AudioDeviceID devices[count];
>       | ^~~~~
> jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
> jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
>   126 | int count = size/sizeof(AudioDeviceID);
> 
> The usage of VLA has been replaced with malloc/calloc and free, which are already used in this file.
> 
> Note that while this patch adds some validation, I am pretty sure it is still possible to crash these code paths if they are executed concurrently. Access to the native pointers being passed around is not properly synchronized.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24937#pullrequestreview-2819348805

From kcr at openjdk.org  Tue May  6 21:33:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 6 May 2025 21:33:16 GMT
Subject: RFR: 8332947: [macos] java.awt.desktop.OpenURIHandler is not
 receiving events [v5]
In-Reply-To: <fqKmOzkrPk_XWcxB5WkUgsjBAGuwRRQBDWH6h_kTAEs=.8deacfe8-f565-4ac1-8810-dc687d4ef0de@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <fqKmOzkrPk_XWcxB5WkUgsjBAGuwRRQBDWH6h_kTAEs=.8deacfe8-f565-4ac1-8810-dc687d4ef0de@github.com>
Message-ID: <8o9fVyLd4V1IWvemx2MjqX3V6NIDAS6T4vCvn-IWOCI=.f504c898-0260-41b5-b280-86065223bbee@github.com>

On Tue, 29 Apr 2025 22:43:03 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> JavaFX Pull Request: https://github.com/openjdk/jfx/pull/1755
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events
>  - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events
>  - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

You have an objective-C bug in two places in your proposed fix. I left a comment with suggestions as to how to update your fix to address the bug.

With that updated fix, I am able to run in both modes -- AWT as primary with JavaFX embedded, and JavaFX as primary with AWT embedded -- and see the OpenURIHandler events being delivered. Without these fixes, the OpenURIHandler events are only delivered when AWT is the primary toolkit.

I also verified that there are no problems running with a fixed AWT and unfixed JavaFX or an unfixed AWT and fixed JavaFX. When only one of them (JavaFX or AWT) is fixed, OpenURIHandler events are not delivered when JavaFX is the primary toolkit, which is the same behavior as today. So that's good.

I left a couple other comments with requested changes.

src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m line 132:

> 130:     NSNotificationCenter *ctr = [NSNotificationCenter defaultCenter];
> 131:     Class clz = [ApplicationDelegate class];
> 132:     [ctr addObserver:clz selector:@selector(_embeddedEvent:) name:@"EmbeddedEvent" object:nil];

`EmbeddedEvent` is too generic a name. I recommend two things:

1. Prefix it with `AWT`, so it would become `AWTEmbeddedEvent` (I think the method name, `_embeddedEvent `, is fine, since it is private to this file)
2. Create a static NSString constant for this string with a comment that it is intended for the primary toolkit to send an event to AWT when AWT is embedded. You probably want to put this string near the top of the file.

Related to the second point, this is only needed when running AWT as an embedded toolkit. I recommend putting this registration code in an `if (!isApplicationOwner) { ... }` block.

src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m line 302:

> 300: 
> 301:     NSString *url = [[openURLEvent paramDescriptorForKeyword:keyDirectObject] stringValue];
> 302:     [self _openURL:url];

`_openURL` is a class method. Using `self` is incorrect and causes a failure in the normal (non-embedded) case.

Suggestion:

    [ApplicationDelegate _openURL:url];

src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m line 492:

> 490:     if ([name isEqualToString:@"openURL"]) {
> 491:         NSString *url = notification.userInfo[@"url"];
> 492:         [self _openURL:url];

`_openURL` is a class method. Using `self` is incorrect (technically, it works here because the caller is also a class method in the same class, but it's still a mistake).

Suggestion:

        [ApplicationDelegate _openURL:url];

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

PR Review: https://git.openjdk.org/jdk/pull/24379#pullrequestreview-2819539381
PR Review Comment: https://git.openjdk.org/jdk/pull/24379#discussion_r2076217229
PR Review Comment: https://git.openjdk.org/jdk/pull/24379#discussion_r2076219525
PR Review Comment: https://git.openjdk.org/jdk/pull/24379#discussion_r2076221920

From kcr at openjdk.org  Tue May  6 21:48:14 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 6 May 2025 21:48:14 GMT
Subject: RFR: 8332947: [macos] java.awt.desktop.OpenURIHandler is not
 receiving events [v5]
In-Reply-To: <fqKmOzkrPk_XWcxB5WkUgsjBAGuwRRQBDWH6h_kTAEs=.8deacfe8-f565-4ac1-8810-dc687d4ef0de@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <fqKmOzkrPk_XWcxB5WkUgsjBAGuwRRQBDWH6h_kTAEs=.8deacfe8-f565-4ac1-8810-dc687d4ef0de@github.com>
Message-ID: <SmyaUQSLdQjkr7nRxv4iVt85MYcXJB1z0SvKqRd2Iik=.a9ae8a9d-4e5f-43f4-9492-27814339a2c7@github.com>

On Tue, 29 Apr 2025 22:43:03 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> JavaFX Pull Request: https://github.com/openjdk/jfx/pull/1755
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events
>  - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events
>  - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

I updated the JBS title slightly for (I hope) better clarity. Please update the PR title to match.

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

PR Comment: https://git.openjdk.org/jdk/pull/24379#issuecomment-2856146464

From serb at openjdk.org  Tue May  6 22:40:13 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 May 2025 22:40:13 GMT
Subject: RFR: 8356208: Remove obsolete code in PSPrinterJob for plugin
 printing [v2]
In-Reply-To: <qWEXDjdN82ypTUbyKMdsNfx0rabfTAx-nCY2UIlfvHE=.1307aedc-36dc-464b-ada5-1f485e3f1dee@github.com>
References: <HbEWUYGs_6niHSFnJan9hIwnIYW5hd5mGnicHW_w3I4=.bb6f5c0e-e183-4165-8d98-bc1552ae5a00@github.com>
 <qWEXDjdN82ypTUbyKMdsNfx0rabfTAx-nCY2UIlfvHE=.1307aedc-36dc-464b-ada5-1f485e3f1dee@github.com>
Message-ID: <dBc1pbDfVXyj6L2WglVuapBDZXL8ACf9xV6uXusiIIo=.11118d57-84a7-445a-9f2e-068feca1118b@github.com>

On Tue, 6 May 2025 18:37:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> Delete the obsolete classes PluginPrinter and EPSPrinter. They were only ever called by the Java Plugin printing for applets.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356208

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25047#pullrequestreview-2819861166

From lordpixel at mac.com  Tue May  6 22:48:06 2025
From: lordpixel at mac.com (Andrew Thompson)
Date: Tue, 6 May 2025 18:48:06 -0400
Subject: Integrated: 8354273: Replace even more Unicode characters with
 ASCII
In-Reply-To: <ozQlBoLORphUUvXLzjs_gDH9cMgvcJVlVzgbt3b6pR0=.df8da50a-67f9-4ee4-b87f-52b49445cefb@github.com>
References: <ozQlBoLORphUUvXLzjs_gDH9cMgvcJVlVzgbt3b6pR0=.df8da50a-67f9-4ee4-b87f-52b49445cefb@github.com>
Message-ID: <3AE8B671-24CA-4508-BF59-0276057DB8BD@mac.com>

> I believe the source code of the JDK should be in US-ASCII

Why? This seems like a bizarre thing to believe free of context. 

In my experience using non-ascii regularly is the only way to make sure that tools which destroy non-ascii data are not introduced into tool chains which then break cases that matter. 

The downside of making things ascii is you miss when bugs are introduced. The upsides of using ascii everywhere are unclear to me. 

Also, if it?s 8 bit, it?s not ascii anyway. It?s really Latin-1 or code page-1252 or who knows what. Better to decide everything is utf-8 and fix tools which can?t handle that before they cause issues. 

Andrew 

> On May 6, 2025, at 2:04?PM, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
> 
> ?On Thu, 10 Apr 2025 10:18:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
> 
>> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII.
> 
> This pull request has now been integrated.
> 
> Changeset: 08dd4a75
> Author:    Magnus Ihse Bursie <ihse at openjdk.org>
> URL:       https://git.openjdk.org/jdk/commit/08dd4a75c5b751a66d2e088b0ec9c6d6c443c14a
> Stats:     11 lines in 8 files changed: 0 ins; 1 del; 10 mod
> 
> 8354273: Replace even more Unicode characters with ASCII
> 
> Reviewed-by: naoto
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/24567
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250506/d3ad0729/attachment-0001.htm>

From serb at openjdk.org  Tue May  6 23:27:13 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 May 2025 23:27:13 GMT
Subject: RFR: 8343739: Test
 java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java failed: Wrong
 extended key code [v3]
In-Reply-To: <ht3_2I2H1FIIA8XGRX5o7kpGHn80Aw9z6rtEYI53oLU=.0ca28b73-57fb-4ebf-85b1-efe73bf2d898@github.com>
References: <ubVHDLbUmS2V0etEvYlsOVr-1H6ZQxayrQTU4bXxz-o=.075cef8e-5d34-43de-8870-09e6afa4f588@github.com>
 <-VKRExcwuamNGxB1FbvYY_rA-dXICYFodaqiI2QnSe0=.0c5f4481-4016-4333-8360-3c6d519f710b@github.com>
 <ht3_2I2H1FIIA8XGRX5o7kpGHn80Aw9z6rtEYI53oLU=.0ca28b73-57fb-4ebf-85b1-efe73bf2d898@github.com>
Message-ID: <iLK3z5iBImsqjqWlVZ7P-mLQQ6dYMQsqUXIw08eKqoE=.fe66c83a-869d-463c-9c3a-db8d41e50a17@github.com>

On Fri, 2 May 2025 18:32:29 GMT, Alisen Chung <achung at openjdk.org> wrote:

> I've updated the test to include logging and ran the test 200x without failures. I think it's ok to push the test with these changes so that if the test ever does fail again we can use the logs and analyze the problem.

I meant to run the test 200 times with logging but no other changes to find the root cause. The other changes to the test seems unnecessary at first glance. the test operations are already synchronized and delayed when necessary.

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

PR Comment: https://git.openjdk.org/jdk/pull/24885#issuecomment-2856471543

From dgredler at openjdk.org  Tue May  6 23:34:15 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Tue, 6 May 2025 23:34:15 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <ZgTFzsooBxN-wUCWHshZzk6ntx-q73m8o9U9JkF1iFU=.d9c56bb3-90fb-4714-93fc-61e1ea6ad2ff@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <ZgTFzsooBxN-wUCWHshZzk6ntx-q73m8o9U9JkF1iFU=.d9c56bb3-90fb-4714-93fc-61e1ea6ad2ff@github.com>
Message-ID: <K80Yidg0_CV5gl8Qu7tZ1Wb103M2uErnLmem-wIQae0=.a3073cf9-d58d-4fb7-92d3-77fb8bf37aae@github.com>

On Mon, 5 May 2025 23:45:36 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
>> 
>> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
>> 
>> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
>> 
>> The new test class passes on Linux, Windows and macOS.
>
> src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java line 138:
> 
>> 136:         return code == 0x0009 || code == 0x000a || code == 0x000d;
>> 137:     }
>> 138: 
> 
> @prrace @gredler 
> Following is an existing issue NOT related to the recent harfbuzz upgrade PR nor this issue fix but it is similar in nature so a separate JBS issue can be created to handle it. I wanted to discuss it before integrating the HB upgrade tomorrow.
> 
> There seems to be similar issue on windows and linux where the hexcode - 0x2028 (line separator) and 0x2029 (paragraph separator) are shown with a non-zero advance - `/java/awt/font/TextLayout/TestControls.java`
> 
> **On Windows:**
> 
> <img width="287" alt="image" src="https://github.com/user-attachments/assets/9eec9009-e3a5-49be-b505-619d041bfa3b" />
> 
> **On Linux:**
> 
> <img width="272" alt="image" src="https://github.com/user-attachments/assets/73a56d6d-53ec-4d6f-ad49-6fc13bdceea0" />
> 
> 
> If adding these codes (0x2028, 0x2029) to platform specific src code (I believe it is NativeGlyphMapper (linux) and WPathGraphics (windows)) fixes the above issue then should we consider moving isIgnorableWhitespace() to common class - `CharToGlyphMapper` instead of macOS specific src?

Yeah, I think right now `\t` `\r` `\n` handling is done separately for each platform, and I think also separately for screen display vs. printing.

As an example, this fix addresses the screen display side of things for macOS, but printing on macOS needs to be fixed separately (as can be seen when you run `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java`). I had a quick look at the corresponding macOS printing issue a few months ago and the fix wasn't obvious, especially given how that part of the code is organized (not really 1-to-1 with the other platforms).

So I think `\t` `\r` `\n` handling is repeated quite a bit, and if we wanted to handle `0x2028` and `0x2029` exactly like we do `\t` `\r` `\n` then we'd need to change multiple places right now.

> should we consider moving isIgnorableWhitespace() to common class - CharToGlyphMapper instead of macOS specific src

That sounds like it could be a good idea, but I don't have a sense of how likely it is to cause breakage elsewhere -- it'd be a matter of "do it and check for test regressions". Maybe you have a better gut feel for the likelihood of unintended side-effects?

Note these two characters (`0x2028` and `0x2029`) are not default-ignorable, though. It sounds like we just don't want to render their glyphs, if they have any (similar to `\t` `\r` `\n`, which are also not default-ignorable).

Over on PR #24412 Nikita has suggested an interesting change to `CharToGlyphMapper` and subclasses which might make this change easier, but I'd like some feedback from a reviewer or two before moving forward. The PR is complete from my POV, but we need some design direction (good as is, or needs tweaks, or need to use a different approach entirely, etc).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2076538725

From serb at openjdk.org  Wed May  7 02:57:19 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 May 2025 02:57:19 GMT
Subject: Integrated: 8355561: [macos] Build failure with Xcode 16.3
In-Reply-To: <IZmniCs0dWQCtAS3-Mg9rRRNpoer26TkCr9EzRXKpVM=.f8c5269c-aa8f-4ecd-a6bb-517cf3a1fc3b@github.com>
References: <IZmniCs0dWQCtAS3-Mg9rRRNpoer26TkCr9EzRXKpVM=.f8c5269c-aa8f-4ecd-a6bb-517cf3a1fc3b@github.com>
Message-ID: <joVAsCN0Ao7t8OMy55QgScU4Z5p3hmMgeC7aQ3sPUMU=.1cd4564a-bb4e-4aac-8f58-905a57e6ab7c@github.com>

On Mon, 28 Apr 2025 19:47:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Multiple similar issues detected in PLATFORM_API_MacOSX_Ports.cpp more info about https://github.com/llvm/llvm-project/issues/62836
> 
> jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>   127 | AudioDeviceID devices[count];
>       | ^~~~~
> jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
> jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
>   126 | int count = size/sizeof(AudioDeviceID);
> 
> The usage of VLA has been replaced with malloc/calloc and free, which are already used in this file.
> 
> Note that while this patch adds some validation, I am pretty sure it is still possible to crash these code paths if they are executed concurrently. Access to the native pointers being passed around is not properly synchronized.

This pull request has now been integrated.

Changeset: 762423d6
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/762423d64d10dcdb37800767d2b2f1b7757c804a
Stats:     60 lines in 1 file changed: 37 ins; 0 del; 23 mod

8355561: [macos] Build failure with Xcode 16.3

Reviewed-by: kizune, prr

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

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

From duke at openjdk.org  Wed May  7 02:58:01 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 7 May 2025 02:58:01 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v3]
In-Reply-To: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
Message-ID: <mg68N7wbejYkkcAJVbhf6NoDh5zIrm_Y2_PB7Oej5hA=.bdfccacd-e329-407f-bfd4-3172958eec43@github.com>

> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
> 
> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
> 2. The transparent pixel is non-zero
> 3. There's more than one such consecutive frame
> 
> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.

Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:

 - 8356120: updating (c) year
 - 8356137: cleaning up error message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25044/files
  - new: https://git.openjdk.org/jdk/pull/25044/files/925d558c..c7072231

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

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

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

From duke at openjdk.org  Wed May  7 03:01:04 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 7 May 2025 03:01:04 GMT
Subject: RFR: 8356320: GifImageDecoder can produce wrong image when GCE changes
 transparent pixel index
Message-ID: <3RTnzdT8-vrt_0nq19kYPZh0-zexouw2d3FjxNY2R5Q=.53abc5a2-b5d9-4386-9c8d-36f2677dfccc@github.com>

When a gif frame's disposal code is DISPOSAL_BGCOLOR and we're maintaining a saved image: we have to flood-fill the frame's bounds. And if the transparent pixel index changes across frames: we could sometimes flood fill the wrong value, resulting in an opaque rectangle in the output image.

(I know this looks similar to https://github.com/openjdk/jdk/pull/25044 , but if you look at the data structure of the sample gifs: they are separate problems with separate solutions.)

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

Commit messages:
 - 8356137: updating (c) year
 - 8356320: adding resource leo.gif
 - 8356320: fix tpix when we flood-fill a rect and tpix changes index
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge pull request #5 from openjdk/master
 - ... and 4 more: https://git.openjdk.org/jdk/compare/898d4798...da529dcd

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

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

From duke at openjdk.org  Wed May  7 03:08:00 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 7 May 2025 03:08:00 GMT
Subject: RFR: 8351913: ToolkitImage renders some gifs wrong [v4]
In-Reply-To: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com>
References: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com>
Message-ID: <eu4ZrRIFX_k-U6QDF54-UHHxOrZ1hSCvfpMfv8PHPg4=.58b80c14-78e5-450f-bb6a-eaa6c19cbe9d@github.com>

> I do not have much background in LZW compression or in C, but I'm reasonably confident this resolves the problem I'm observing. It looks like the GifImageDecoder was not always correctly handling compression codes after the table reached its limit of ~4096. If anyone has suggestions for improvements I'm happy to make adjustments.
> 
> Luckily while debugging this: I was able to compare the flawed implementation (GifImageDecoder) with ImageIO's implementation (GIFImageReader) to help identify how the suffix/prefix tables are supposed to work.
> 
> ImageIO's implementation may have suffered a similar bug (maybe https://bugs.openjdk.org/browse/JDK-7131823 ?), and that appears to have been backported.
> 
> I have dozens of additional test cases for this problem, but unfortunately I don't have the rights to commit them to the OpenJDK repo. Feel free to email me for additional context/test cases.

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

  8351913: moving test package
  
  I have two other PRs in progress that place their tests in a dir like:
  /jdk/test/jdk/sun/awt/image/gif/bug8351913/
  
  They aren't approved/merged yet, but hopefully all 3 of these new gif bugs will be merged and they'll benefit from being grouped in the same new gif directory. (And maybe more will test/directories will follow.)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24271/files
  - new: https://git.openjdk.org/jdk/pull/24271/files/d555631c..1733a85e

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

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

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

From prr at openjdk.org  Wed May  7 05:38:19 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 7 May 2025 05:38:19 GMT
Subject: Integrated: 8356208: Remove obsolete code in PSPrinterJob for plugin
 printing
In-Reply-To: <HbEWUYGs_6niHSFnJan9hIwnIYW5hd5mGnicHW_w3I4=.bb6f5c0e-e183-4165-8d98-bc1552ae5a00@github.com>
References: <HbEWUYGs_6niHSFnJan9hIwnIYW5hd5mGnicHW_w3I4=.bb6f5c0e-e183-4165-8d98-bc1552ae5a00@github.com>
Message-ID: <FbKIIc2jpfp0VrwCtjY9BU7uY2bmZBlacWrsOCKr5DI=.abb6b937-81d0-4b32-920e-55c7edfe0719@github.com>

On Mon, 5 May 2025 18:55:47 GMT, Phil Race <prr at openjdk.org> wrote:

> Delete the obsolete classes PluginPrinter and EPSPrinter. They were only ever called by the Java Plugin printing for applets.

This pull request has now been integrated.

Changeset: 4e3ec3c0
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e3ec3c04c1c60404b9ec7d5524eaceab6472b67
Stats:     339 lines in 1 file changed: 23 ins; 278 del; 38 mod

8356208: Remove obsolete code in PSPrinterJob for plugin printing

Reviewed-by: serb

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

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

From serb at openjdk.org  Wed May  7 06:06:27 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 May 2025 06:06:27 GMT
Subject: RFR: 8339561: The test/jdk/java/awt/Paint/ListRepaint.java may
 fail after JDK-8327401 [v9]
In-Reply-To: <rot7Rc0pyVsH2CTy5LnxVRPSAGilnI3HQJcJWTvrjs0=.9b585c6b-99bd-4ab7-bb9d-d164b6e90289@github.com>
References: <rot7Rc0pyVsH2CTy5LnxVRPSAGilnI3HQJcJWTvrjs0=.9b585c6b-99bd-4ab7-bb9d-d164b6e90289@github.com>
Message-ID: <i627UH49iJmTp4pXJxuEW9fOo3VrZjxE9Xr3eRWMhjg=.e50e19ce-aa7c-49c4-88b0-d6efd00e8b1e@github.com>

> Several tests modified by https://github.com/openjdk/jdk/pull/19339 have been tweaked, see inline comments.
> 
> Notes:
>  * We have a few XXXRepaint.java tests and in this patch, I updated all of them to follow the change added to the ListRepaint.java
> 
> @azvegint @aivanov-jdk please take a look.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'openjdk:master' into JDK-8339561
 - Merge branch 'openjdk:master' into JDK-8339561
 - Merge branch 'openjdk:master' into JDK-8339561
 - drop null check
 - copyright
 - Merge branch 'openjdk:master' into JDK-8339561
 - more volatiles
 - revert change reported in JDK-8339791
 - trigger github for new content
 - trigger github for new content
 - ... and 7 more: https://git.openjdk.org/jdk/compare/4e3ec3c0...a01d0b8d

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

Changes: https://git.openjdk.org/jdk/pull/20861/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20861&range=08
  Stats: 174 lines in 7 files changed: 48 ins; 45 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/20861.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20861/head:pull/20861

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

From serb at openjdk.org  Wed May  7 09:25:33 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 May 2025 09:25:33 GMT
Subject: Integrated: 8339561: The test/jdk/java/awt/Paint/ListRepaint.java may
 fail after JDK-8327401
In-Reply-To: <rot7Rc0pyVsH2CTy5LnxVRPSAGilnI3HQJcJWTvrjs0=.9b585c6b-99bd-4ab7-bb9d-d164b6e90289@github.com>
References: <rot7Rc0pyVsH2CTy5LnxVRPSAGilnI3HQJcJWTvrjs0=.9b585c6b-99bd-4ab7-bb9d-d164b6e90289@github.com>
Message-ID: <AbMxSsQwWEoHrsBlIgbf6A6HQ3vyXY5N5xBmhE3ByVU=.23334d2e-7644-477f-b50b-789779d5ad77@github.com>

On Wed, 4 Sep 2024 20:50:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Several tests modified by https://github.com/openjdk/jdk/pull/19339 have been tweaked, see inline comments.
> 
> Notes:
>  * We have a few XXXRepaint.java tests and in this patch, I updated all of them to follow the change added to the ListRepaint.java
> 
> @azvegint @aivanov-jdk please take a look.

This pull request has now been integrated.

Changeset: 0844745e
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0844745e7bd954a96441365f8010741ec1c29dbf
Stats:     174 lines in 7 files changed: 48 ins; 45 del; 81 mod

8339561: The test/jdk/java/awt/Paint/ListRepaint.java may fail after JDK-8327401

Reviewed-by: azvegint

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

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

From mvs at openjdk.org  Wed May  7 12:33:24 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 7 May 2025 12:33:24 GMT
Subject: RFR: 8355515: Clarify the purpose of forcePass() and forceFail()
 methods
Message-ID: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>

Clarified the purpose of forcePass() and forceFail() methods and recommended usage of these methods.

forcePass() contained an incorrect sample; it's addressed by [JDK-8355441](https://bugs.openjdk.org/browse/JDK-8355441).

The description of forceFail() has been expanded, too.


A new section in the description of the PassFailJFrame added to describe forcePass() and forceFail().

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

Commit messages:
 - 8355515: Clarify the purpose of forcePass() and forceFail() methods

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

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

From achung at openjdk.org  Wed May  7 16:24:30 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 7 May 2025 16:24:30 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v13]
In-Reply-To: <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
Message-ID: <yk4mYRZsnZz8Z4koY6rYmF5W8n_u1TTC7VqJO5vycns=.b71ade0d-2a2d-4219-9c77-27c9e650c85a@github.com>

On Wed, 30 Apr 2025 21:13:12 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Currently on macOS when mouseMove is given an offscreen coordinate to move the mouse to, mouseMove will physically clamp to the edge of the screen, but if you try to grab the mouse location immediately after by using MouseInfo.getPointerInfo().getLocation() you will get the value of the offscreen point.
>> 
>> Windows and linux do this clamping and coordinate handling for us, but new distributions may not necessarily handle clamping the same way, so Robot should be checking for clamping rather than delegating it to native.
>> 
>> This fix updates shared code to cache the screen bounds and adds a check to not exceed the bounds in mouseMove. The caching is done in the Robot constructor, so if the screen bounds changes the constructor must be called again to update to the new bounds.
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8345538
>  - move clamping code into macos
>  - use absolute distance to choose correct screen for offscreen clamping
>  - helper function
>  - grab screen data on mouseMove
>  - fix bounds
>  - peer.mouseMove
>  - fix implementation
>  - robot update
>  - Revert "robot multimonitor fix"
>    
>    This reverts commit 5734165881a66dc48d5a9f19e02bf63fac57cdc9.
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8b16897b...e0a5c872

Sure I can create a reproducer and submit an issue to Apple, but is there any reason to not fix the clamping on our end as well?

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

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2859214656

From duke at openjdk.org  Wed May  7 16:48:01 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Wed, 7 May 2025 16:48:01 GMT
Subject: RFR: 8332947: [macos] OpenURIHandler events not received when AWT
 is embedded in another toolkit [v5]
In-Reply-To: <fqKmOzkrPk_XWcxB5WkUgsjBAGuwRRQBDWH6h_kTAEs=.8deacfe8-f565-4ac1-8810-dc687d4ef0de@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <fqKmOzkrPk_XWcxB5WkUgsjBAGuwRRQBDWH6h_kTAEs=.8deacfe8-f565-4ac1-8810-dc687d4ef0de@github.com>
Message-ID: <l7zmFdaJ70dqIJc93lxQ1O8OFQgwYUJLhmAtw3Axqts=.80a9e0f8-54a5-4110-8c04-0105415e2f8e@github.com>

On Tue, 29 Apr 2025 22:43:03 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> JavaFX Pull Request: https://github.com/openjdk/jfx/pull/1755
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events
>  - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events
>  - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

I implemented the feedback and changed the pull request title.

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

PR Comment: https://git.openjdk.org/jdk/pull/24379#issuecomment-2859278162

From duke at openjdk.org  Wed May  7 16:48:01 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Wed, 7 May 2025 16:48:01 GMT
Subject: RFR: 8332947: [macos] OpenURIHandler events not received when AWT
 is embedded in another toolkit [v5]
In-Reply-To: <8o9fVyLd4V1IWvemx2MjqX3V6NIDAS6T4vCvn-IWOCI=.f504c898-0260-41b5-b280-86065223bbee@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <fqKmOzkrPk_XWcxB5WkUgsjBAGuwRRQBDWH6h_kTAEs=.8deacfe8-f565-4ac1-8810-dc687d4ef0de@github.com>
 <8o9fVyLd4V1IWvemx2MjqX3V6NIDAS6T4vCvn-IWOCI=.f504c898-0260-41b5-b280-86065223bbee@github.com>
Message-ID: <meygHfXBNyOlRXjoQZTScVCYN3MMu5toC-TLjQ6kh1M=.6dab1a38-0825-4daa-92c7-7a6d43dfca65@github.com>

On Tue, 6 May 2025 20:20:04 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Pabulaner IV has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events
>>  - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events
>>  - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m line 302:
> 
>> 300: 
>> 301:     NSString *url = [[openURLEvent paramDescriptorForKeyword:keyDirectObject] stringValue];
>> 302:     [self _openURL:url];
> 
> `_openURL` is a class method. Using `self` is incorrect and causes a failure in the normal (non-embedded) case.
> 
> Suggestion:
> 
>     [ApplicationDelegate _openURL:url];

Thanks for the feedback, I am new to Objective C, so it the feedback is much appreciated!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24379#discussion_r2078057470

From duke at openjdk.org  Wed May  7 16:48:00 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Wed, 7 May 2025 16:48:00 GMT
Subject: RFR: 8332947: [macos] OpenURIHandler events not received when AWT
 is embedded in another toolkit [v6]
In-Reply-To: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
Message-ID: <GMvUbC5RTseSnbfYZyGId9ikNX98scfV4lTDF4b_1t8=.fa78dc0f-2f82-4944-82fd-d5d47ae002be@github.com>

> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
> Either the native menu is not shown or the URIs are not received.
> 
> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
> 
> JavaFX Pull Request: https://github.com/openjdk/jfx/pull/1755
> Co-Author: @FlorianKirmaier

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

  8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24379/files
  - new: https://git.openjdk.org/jdk/pull/24379/files/1aa1831d..42b8707e

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

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

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

From duke at openjdk.org  Wed May  7 16:51:30 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Wed, 7 May 2025 16:51:30 GMT
Subject: RFR: 8332947: [macos] OpenURIHandler events not received when AWT
 is embedded in another toolkit [v7]
In-Reply-To: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
Message-ID: <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>

> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
> Either the native menu is not shown or the URIs are not received.
> 
> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
> 
> JavaFX Pull Request: https://github.com/openjdk/jfx/pull/1755
> Co-Author: @FlorianKirmaier

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

  8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24379/files
  - new: https://git.openjdk.org/jdk/pull/24379/files/42b8707e..924b17b1

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

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

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

From aivanov at openjdk.org  Wed May  7 17:03:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 7 May 2025 17:03:31 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v2]
In-Reply-To: <Xl1oVhRGDHJX-j5VoyIsGee1JfgbukuqGIgnpb6lR9Y=.a17d8c8a-d95b-4643-afbb-a99ff5fd3b94@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <Xl1oVhRGDHJX-j5VoyIsGee1JfgbukuqGIgnpb6lR9Y=.a17d8c8a-d95b-4643-afbb-a99ff5fd3b94@github.com>
Message-ID: <grGdOEa0QRz4vhBps8hGG5ZvMX-66Dud9ZCSbpQby5k=.770e090f-87b2-416a-a5d5-b61c556f81d9@github.com>

On Fri, 2 May 2025 23:00:32 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/com/sun/media/sound/DataPusher.java line 97:

> 95:     public boolean isPlaying() {
> 96:         return threadState == STATE_PLAYING;
> 97:     }

I think this method should be `synchronized`.

(The `threadState` field is modified in `run()` without synchronization, which isn't guaranteed to be visible by other threads. But it's a different issue.)

src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 104:

> 102:                 throw e;
> 103:             }
> 104:         }

Can any other (checked) exception be thrown?

I can't see that it's possible, then catching it isn't necessary.

src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 113:

> 111:             clip.init(uc.getInputStream());
> 112:         } catch (final Exception ignored) {
> 113:             // Playing the clip will be a no-op if an exception occured in inititialization.

Suggestion:

            // Playing the clip will be a no-op if an exception occurred in inititialization.

src/java.desktop/share/classes/javax/sound/SoundClip.java line 40:

> 38:  * Typically this means running the application in a desktop environment.
> 39:  *
> 40:  * Multiple {@code SoundClip} items can be playing at the same time, and

Suggestion:

 * Typically this means running the application in a desktop environment.
 *
 * <p>
 * Multiple {@code SoundClip} items can be playing at the same time, and

I assume a new paragraph starts with _?Multiple??_.

src/java.desktop/share/classes/javax/sound/SoundClip.java line 47:

> 45: public final class SoundClip {
> 46: 
> 47:     private JavaSoundAudioClip clip;

Suggestion:

    private final JavaSoundAudioClip clip;

The value doesn't change after an instance is created, so it can and should be final.

src/java.desktop/share/classes/javax/sound/SoundClip.java line 50:

> 48: 
> 49:     /**
> 50:      * Create a {@code SoundClip} instance which will play a clip from the supplied file.

Suggestion:

     * Creates a {@code SoundClip} instance which will play a clip from the supplied file.

src/java.desktop/share/classes/javax/sound/SoundClip.java line 52:

> 50:      * Create a {@code SoundClip} instance which will play a clip from the supplied file.
> 51:      *
> 52:      * If the file does not contain recognizable and supported sound data, or

Suggestion:

     * <p>
     * If the file does not contain recognizable and supported sound data, or

Without `<p>`, this block will be rendered right after the first sentence above without a paragraph break. If it's intended, I propose removing a seemingly empty line.

src/java.desktop/share/classes/javax/sound/SoundClip.java line 56:

> 54:      * playing the clip will be a no-op.
> 55:      *
> 56:      * @param file from which to obtain the sound data

Suggestion:

     * @param file the file from which to obtain the sound data

src/java.desktop/share/classes/javax/sound/SoundClip.java line 69:

> 67: 
> 68:     private SoundClip() {
> 69:     }

If the no-arg constructor is never used, then it's not needed and it should be removed.

src/java.desktop/share/classes/javax/sound/SoundClip.java line 78:

> 76:      * Returns whether this is a playable sound clip.
> 77:      * A value of {@code false} means that calling any of the other methods
> 78:      * of this class is a no-op

Suggestion:

     * of this class is a no-op.

src/java.desktop/share/classes/javax/sound/SoundClip.java line 90:

> 88:      * @return whether sound is currently playing
> 89:      */
> 90:     public boolean isPlaying() {

Suggestion:

    /**
     * {@return whether sound is currently playing}
     */
    public boolean isPlaying() {

src/java.desktop/share/classes/javax/sound/package-info.java line 32:

> 30:  * Capture, processing and playback of sampled audio data is under {@link javax.sound.sampled}
> 31:  * <p>
> 32:  * Sequencing, and synthesis of MIDI (Musical Instrument Digital Interface) data is under {@link javax.sound.midi}

Suggestion:

 * Capture, processing and playback of sampled audio data is under {@link javax.sound.sampled}.
 * <p>
 * Sequencing, and synthesis of MIDI (Musical Instrument Digital Interface) data is under {@link javax.sound.midi}.

test/jdk/javax/sound/SoundClip/SoundClipTest.java line 43:

> 41:         if (!isSoundcardInstalled()) {
> 42:             return;
> 43:         }

It should throw `jtreg.SkippedException` instead of pretending the test passes.

test/jdk/javax/sound/SoundClip/SoundClipTest.java line 60:

> 58:             if (clip.isPlaying()) {
> 59:                 playing = true;
> 60:                 break;

`break` is somewhat redundant since the loop has `!playing` as the condition for executing the body.

test/jdk/javax/sound/SoundClip/SoundClipTest.java line 101:

> 99:         } catch (Exception e) {
> 100:             System.err.println("Exception occurred: "+e);
> 101:         }

The stack trace of the exception could be crucial to understanding what went wrong, so printing the stack trace could be a better approach than just the error message.

I guess you want to pass the test (or as I suggest throw `jtreg.SkippedException`) if anything goes wrong.

`AudioSystem.getSourceDataLine` throws `LineUnavailableException` which is checked exception, and if the exception

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

PR Review: https://git.openjdk.org/jdk/pull/24991#pullrequestreview-2822446607
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078030777
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078040610
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078061539
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078065416
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078047776
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078048603
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078050809
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078051444
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078053524
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078054567
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078057503
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078067119
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078070770
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078072903
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078084485

From aivanov at openjdk.org  Wed May  7 17:03:32 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 7 May 2025 17:03:32 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v2]
In-Reply-To: <gRl1i1i1FXCFbtkMuSGTV9ORhBJqCz8whTxjvxJxr9w=.816afc8f-39ea-4893-9a3e-2d1694666316@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <Nlospsfogo17X9rWEPw3yT6rqpcNFzeFcR3WI3_dvUc=.08737a9b-8363-477a-af8a-5eca9032f0aa@github.com>
 <gRl1i1i1FXCFbtkMuSGTV9ORhBJqCz8whTxjvxJxr9w=.816afc8f-39ea-4893-9a3e-2d1694666316@github.com>
Message-ID: <muKcKP2bizRtPmBi-4cVHmetscMBnsxHslKbX9iUqaM=.4063f6ed-691d-490c-96bb-d257e6e13d6f@github.com>

On Fri, 2 May 2025 22:55:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/javax/sound/SoundClip/SoundClipTest.java line 40:
>> 
>>> 38: 
>>> 39:     public static void main(String[] args) throws Exception {
>>> 40: 
>> 
>> Suggestion:
>
> I like blank lines there

But why in the `main` method only? Why is it different from other methods which don't start with a blank line?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078069253

From prr at openjdk.org  Wed May  7 18:30:59 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 7 May 2025 18:30:59 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v24]
In-Reply-To: <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
Message-ID: <e3qY9co-ho5_Gi-l3GvltgHByxncmtOxGsRWHk1d9n8=.d85b53a1-49ec-452b-8055-a14e5534146c@github.com>

On Wed, 12 Mar 2025 11:00:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fix

I refined the example program and submitted a support case to Microsoft.
I'll attach to the JBS issue that version of the test case (rbm.cpp) and then
one (rbma.cpp) showing where we've got to.

First there are several elements to understand about menu items
https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-menuiteminfoa

(1) The menu item can have a string as the "item" (dwTypeData)
(2) The menu item can have a bitmap as the "item" (hbmpItem)
- Historically you could only have ONE of these because the field used to specify them is the same. Now by using the new MIIM* values you can have both. And - I don't quite understand this - using the old MFT_STRING didn't seem to work at all for me I had to use MIIM_STRING.

As well as those you can specify the images to use for the check state
- hbmpChecked - if the item is selected
- hbmpUnchecked - if it is not selected.


Some questions and some answers with Microsoft

Q. Why is the highlighting background gone in Windows 11 ?

A. That background was part of the ?Reveal? lighting effect used by the old Fluent-Design menus in Windows 10. As of WinUI 2.6 (the style set shipped with Windows 11) the UI team removed that effect across context-menus and other pop-ups to achieve a flatter look that meets new contrast guidelines. So it?s an intentional theme change, not a GDI regression.

 
Q. Why does the item image draw over the default radio button. How can this be anything except a bug ?

A. The Win32 menu engine draws the default bullet/checkmark at X = 0 unless you reserve a check-mark column by supplying hbmpChecked (and optionally hbmpUnchecked).
When an hbmpItem is also present, both bitmaps occupy the same origin, so the icon ends up covering the bullet. This rule has been in place since the Windows 9x/NT days?older SDK samples illustrate the same overlap if you omit the custom check bitmaps. Because the behaviour is longstanding and documented indirectly (see the remarks under SetMenuItemBitmaps and the SM_CXMENUCHECK metric), the shell team classifies it as by design rather than a bug.

Q. Why isn't space automatically left for the default rendering of the checkmark ? Another bug ?

A. For historical reasons the menu layout engine only allocates the check-mark column when it has a concrete size for that column, i.e. when hbmpChecked is non-NULL. If you ask for the default glyph while also providing an item icon, Windows assumes you are handling layout yourself. The docs don?t call this out explicitly (agreed, that would be helpful), but the behaviour is consistent and the same on every supported version of Windows, so it is not tracked as a GDI defect.

So .. in summary, two things that have been a bug so long they are considered a feature are at the root of this and the visual "cue" we've relied on for in Windows 10 was just an accident of some theming that is now gone.

So GDI really does make it hard to have all 3 of these. And maybe we should just not support it ?

But if  (as GDI programmers) we want an item string and bitmap, and expect feedback that an item is selected, we seem to be forced into needing to specify bitmaps for the checked and un-checked state. But then you lose the default rendering of the bullet that Windows provides !

There's some hoops we can jump through to get close
- Use a transparent bitmap for hbmpUnchecked
- Use a GDI API - DrawFrameControl - to render a bullet image into a bitmap we use for hbmpChecked. Prasanta previously noted that AWT uses this API already)

rbma.cpp illustrates this.

This still isn't perfect - the bullet is too large.

I'll leave it to others to figure out how we make use of this in the Swing rendering case.
Are there any unanswered questions ? This is a long PR so perhaps ..

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2859773998

From prr at openjdk.org  Wed May  7 19:10:53 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 7 May 2025 19:10:53 GMT
Subject: RFR: 8356053: Test java/awt/Toolkit/Headless/HeadlessToolkit.java
 fails by timeout
In-Reply-To: <rSxJ8yhJauBlv1dbHab2d61J46SjG7-54OvIaBtCteU=.354eaf8c-8257-4147-b45b-c7045755424a@github.com>
References: <rSxJ8yhJauBlv1dbHab2d61J46SjG7-54OvIaBtCteU=.354eaf8c-8257-4147-b45b-c7045755424a@github.com>
Message-ID: <oqvBLsEs8j4XpqjerbDkgvK-1HYfbwGjE2b_rqRerLg=.25a67473-1da0-413f-b1ca-cb5bb6034dc0@github.com>

On Mon, 5 May 2025 17:44:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The `java/awt/Toolkit/Headless/HeadlessToolkit.java` test covers some functionality of various methods in the `HeadlessToolkit` class, specifically whether these methods throw a `HeadlessException` or not. The image-related methods do not require access to a remote server via a URL; they can be tested using a URL pointing to a local file. This ensures that the test does not depend on `openjdk.org`.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25045#pullrequestreview-2822920567

From prr at openjdk.org  Wed May  7 20:47:16 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 7 May 2025 20:47:16 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v3]
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <yE60ih_uYBbmAe48BUySKVRRVyqCfZ40nW_uDxwUJ_c=.700bebb7-22e5-4c7d-b3ec-9d026a3ab25e@github.com>

> A simple API to replace java.applet.AudioClip
> 
> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200

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

  8356049

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24991/files
  - new: https://git.openjdk.org/jdk/pull/24991/files/299bce17..392c13f0

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

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

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

From prr at openjdk.org  Wed May  7 20:47:17 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 7 May 2025 20:47:17 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v2]
In-Reply-To: <grGdOEa0QRz4vhBps8hGG5ZvMX-66Dud9ZCSbpQby5k=.770e090f-87b2-416a-a5d5-b61c556f81d9@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <Xl1oVhRGDHJX-j5VoyIsGee1JfgbukuqGIgnpb6lR9Y=.a17d8c8a-d95b-4643-afbb-a99ff5fd3b94@github.com>
 <grGdOEa0QRz4vhBps8hGG5ZvMX-66Dud9ZCSbpQby5k=.770e090f-87b2-416a-a5d5-b61c556f81d9@github.com>
Message-ID: <fQGD1rAXdgazqR4bP-9ELUMSueIotIqduwta0_tsoeI=.610e7f43-1986-42f6-9bf8-a9d2d1864d6b@github.com>

On Wed, 7 May 2025 16:26:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356049
>
> src/java.desktop/share/classes/com/sun/media/sound/DataPusher.java line 97:
> 
>> 95:     public boolean isPlaying() {
>> 96:         return threadState == STATE_PLAYING;
>> 97:     }
> 
> I think this method should be `synchronized`.
> 
> (The `threadState` field is modified in `run()` without synchronization, which isn't guaranteed to be visible by other threads. But it's a different issue.)

ok

> src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 104:
> 
>> 102:                 throw e;
>> 103:             }
>> 104:         }
> 
> Can any other (checked) exception be thrown?
> 
> I can't see that it's possible, then catching it isn't necessary.

The implementations that accept a URLConnection, a URL and an InputStream all do the same.
It is probable that was just for IOExceptions but I'm not 100% sure since init() swallows certain pother exception types itself and then just propagates IOException to these and definitely those implementations swallow the propagated IOException.
If we are sufficiently sure that it is OK I could do that (ie assume IOException is the only possible exception here),
but the first question to answer is whether this new API should also swallow the IOException like the existing ones.
The one reason for doing that might be if you wanted to be lazy about when you actually read .. but I doubt we do want to do that. This API isn't for "streaming" so it should consume the data immediately.

So I'll remove it as you suggest and leave everything else unchanged and we'll see if anyone has a different opinion.

> src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 113:
> 
>> 111:             clip.init(uc.getInputStream());
>> 112:         } catch (final Exception ignored) {
>> 113:             // Playing the clip will be a no-op if an exception occured in inititialization.
> 
> Suggestion:
> 
>             // Playing the clip will be a no-op if an exception occurred in inititialization.

As I wrote previously I am not going fixing typos in methods I didn't touch and actually expect to remove when the Applet API is removed.

> src/java.desktop/share/classes/javax/sound/SoundClip.java line 40:
> 
>> 38:  * Typically this means running the application in a desktop environment.
>> 39:  *
>> 40:  * Multiple {@code SoundClip} items can be playing at the same time, and
> 
> Suggestion:
> 
>  * Typically this means running the application in a desktop environment.
>  *
>  * <p>
>  * Multiple {@code SoundClip} items can be playing at the same time, and
> 
> I assume a new paragraph starts with _?Multiple??_.

yes

> src/java.desktop/share/classes/javax/sound/SoundClip.java line 47:
> 
>> 45: public final class SoundClip {
>> 46: 
>> 47:     private JavaSoundAudioClip clip;
> 
> Suggestion:
> 
>     private final JavaSoundAudioClip clip;
> 
> The value doesn't change after an instance is created, so it can and should be final.

ok.

> src/java.desktop/share/classes/javax/sound/SoundClip.java line 50:
> 
>> 48: 
>> 49:     /**
>> 50:      * Create a {@code SoundClip} instance which will play a clip from the supplied file.
> 
> Suggestion:
> 
>      * Creates a {@code SoundClip} instance which will play a clip from the supplied file.

ok

> src/java.desktop/share/classes/javax/sound/SoundClip.java line 52:
> 
>> 50:      * Create a {@code SoundClip} instance which will play a clip from the supplied file.
>> 51:      *
>> 52:      * If the file does not contain recognizable and supported sound data, or
> 
> Suggestion:
> 
>      * <p>
>      * If the file does not contain recognizable and supported sound data, or
> 
> Without `<p>`, this block will be rendered right after the first sentence above without a paragraph break. If it's intended, I propose removing a seemingly empty line.

it is intended to be one sentence so is fine as it is.

> src/java.desktop/share/classes/javax/sound/SoundClip.java line 56:
> 
>> 54:      * playing the clip will be a no-op.
>> 55:      *
>> 56:      * @param file from which to obtain the sound data
> 
> Suggestion:
> 
>      * @param file the file from which to obtain the sound data

ok

> src/java.desktop/share/classes/javax/sound/SoundClip.java line 69:
> 
>> 67: 
>> 68:     private SoundClip() {
>> 69:     }
> 
> If the no-arg constructor is never used, then it's not needed and it should be removed.

ok

> src/java.desktop/share/classes/javax/sound/SoundClip.java line 78:
> 
>> 76:      * Returns whether this is a playable sound clip.
>> 77:      * A value of {@code false} means that calling any of the other methods
>> 78:      * of this class is a no-op
> 
> Suggestion:
> 
>      * of this class is a no-op.

ok

> src/java.desktop/share/classes/javax/sound/SoundClip.java line 90:
> 
>> 88:      * @return whether sound is currently playing
>> 89:      */
>> 90:     public boolean isPlaying() {
> 
> Suggestion:
> 
>     /**
>      * {@return whether sound is currently playing}
>      */
>     public boolean isPlaying() {

I didn't know you could do that.

> src/java.desktop/share/classes/javax/sound/package-info.java line 32:
> 
>> 30:  * Capture, processing and playback of sampled audio data is under {@link javax.sound.sampled}
>> 31:  * <p>
>> 32:  * Sequencing, and synthesis of MIDI (Musical Instrument Digital Interface) data is under {@link javax.sound.midi}
> 
> Suggestion:
> 
>  * Capture, processing and playback of sampled audio data is under {@link javax.sound.sampled}.
>  * <p>
>  * Sequencing, and synthesis of MIDI (Musical Instrument Digital Interface) data is under {@link javax.sound.midi}.

ok

> test/jdk/javax/sound/SoundClip/SoundClipTest.java line 43:
> 
>> 41:         if (!isSoundcardInstalled()) {
>> 42:             return;
>> 43:         }
> 
> It should throw `jtreg.SkippedException` instead of pretending the test passes.

Well perhaps, but this is what every other similar jtreg sound test does.

> test/jdk/javax/sound/SoundClip/SoundClipTest.java line 60:
> 
>> 58:             if (clip.isPlaying()) {
>> 59:                 playing = true;
>> 60:                 break;
> 
> `break` is somewhat redundant since the loop has `!playing` as the condition for executing the body.

I suppose ..

> test/jdk/javax/sound/SoundClip/SoundClipTest.java line 101:
> 
>> 99:         } catch (Exception e) {
>> 100:             System.err.println("Exception occurred: "+e);
>> 101:         }
> 
> The stack trace of the exception could be crucial to understanding what went wrong, so printing the stack trace could be a better approach than just the error message.
> 
> I guess you want to pass the test (or as I suggest throw `jtreg.SkippedException`) if anything goes wrong. Otherwise, I'd let the exception propagate to fail the test, which could be the right thing to do since the test include the _sound_ key.

I think I'd like to get to a place where  if you pass @sound these tests should skip this testing and actually FAIL if they can't find sound. Only allowing the skipping if you didn't explicitly pass @sound. 

I haven't found a way to know if that's possible. I'm going to ask ..

This method is copied straight from another test. I think lots of tests use it.
I guess since it already prints the exception adding a trace isn't a problem.

But it isn't completely reliable. Some systems (cloud ones with "emulated" sound) pass but then the test hangs. I'm probably going to have to do some test exclusion if I can't figure that out but I don't expect it to be in this PR because it'll be something internal to our CI systems.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078341427
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078344831
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078347050
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078363357
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078370154
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078370889
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078372396
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078410687
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078373008
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078374629
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078398834
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078382942
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078447291
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078446904
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2078444767

From prr at openjdk.org  Wed May  7 21:11:54 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 7 May 2025 21:11:54 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
In-Reply-To: <kG1MjZyVmybZj-A8u7ak4GBJ-h06fy5fAxIjFObj45c=.c80b7530-2747-4e56-bb7c-72bc84a612cf@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <vEWA2CeJs9SmRb8K81xVWRMko2w6xj9Q2hIGXlYUVZM=.e7d736f9-9b2c-4a48-b366-e3801a304f9e@github.com>
 <Ahgb4B8gkI9Cjqwdoq0-Acfcga0QYbiprxAS4k3Fa7U=.c36f229f-2529-4788-8d14-86a51422e373@github.com>
 <vmyVz_91nhgMmjLla6DKOkJGD-Xp_6qajAgUKfeXLoY=.89fefd83-43c9-476c-a951-70a633f9a5e2@github.com>
 <xrKZHsl3CpNOAmppgUcqtxPK_Pb8RinLTrj11RMxGOY=.a64e2fff-04cb-4001-acbb-3c10b24d54de@github.com>
 <f6oYZ6xLi4A9CLobrR9K5ENfgEmSBqTay1kQaf7f3yY=.29f79326-48e7-4ad8-9afb-055536cdb4b2@github.com>
 <isvH5l_2W5YQ-mbpXd3XJMLyp2XP8Yohrq9cxFi84Nc=.27fc812c-b5e4-43df-b9f8-55881331097c@github.com>
 <UzRKXFgBG_WyKaEF3Hjdb3qb2ExAFmUA3UNZI42zMm0=.48021bee-2600-47bf-8c26-bfdddf320592@github.com>
 <MsGQMdJVt_rqNfkj62DVrsBWPlQrx5lsxjnR5BKzl9k=.a8bbbc62-1b60-4982-9424-6af202a6304c@github.com>
 <PfOTt7diduByRh7oViyuN-gJ-3iiD_CnGHIY8Xmni8k=.b52391fd-f576-4c01-923b-209975713596@github.com>
 <HYVRAUlbtJyV9GVAKlTWbeUNMHzV8ugjNuP
 7B4ALY48=.134d9204-f8a9-48fa-85af-982aa124469a@github.com>
 <oTB8PeOedGLLoza4ALZkxGvEdJttzGQb3_eVKwwT0eE=.9f06dd2d-7485-45eb-8cae-af3bad0aa683@github.com>
 <kG1MjZyVmybZj-A8u7ak4GBJ-h06fy5fAxIjFObj45c=.c80b7530-2747-4e56-bb7c-72bc84a612cf@github.com>
Message-ID: <mwA2kTMeaSXuWYCnqXlvhMAJYUA50J58c-8BPaPiLw8=.71bc0dea-2509-491d-878a-ae27b04ec5fd@github.com>

On Wed, 23 Apr 2025 11:23:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> When we are unable to create a folder with special characters in windows OS, why do we need to test it using custom `FileSystemView` ? My point is will any developer do this in windows?
>
> Because the problem is still there, and there are virtual folders on Windows. If a custom `FileSystemView` can return file names with `"<html>"` in their name, `JFileChooser` in Windows Look and Feel will render the file name as HTML.
> 
> Isn't it the problem that you're trying to fix?

@aivanov-jdk @TejeshR13 
This seems stalled because there are conflicting statements
- Alexei : you can create a custom FIleSystemView on windows with <html> in path names.
- Tejesh : no you can't, or at least it doesn't work when you try to use it.

Can we please get that reconciled ?
Tejesh pls show the code you used, and Alexei please show how you would do it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2078495631

From prr at openjdk.org  Wed May  7 21:19:00 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 7 May 2025 21:19:00 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v13]
In-Reply-To: <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
Message-ID: <6N3u1cHzb-xFQ90zy1zuvLXzrwD9yoy-fsC7R8_cpnY=.7529ded3-50a6-473f-8fa2-98c4ee9d44f5@github.com>

On Wed, 30 Apr 2025 21:13:12 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Currently on macOS when mouseMove is given an offscreen coordinate to move the mouse to, mouseMove will physically clamp to the edge of the screen, but if you try to grab the mouse location immediately after by using MouseInfo.getPointerInfo().getLocation() you will get the value of the offscreen point.
>> 
>> Windows and linux do this clamping and coordinate handling for us, but new distributions may not necessarily handle clamping the same way, so Robot should be checking for clamping rather than delegating it to native.
>> 
>> This fix updates shared code to cache the screen bounds and adds a check to not exceed the bounds in mouseMove. The caching is done in the Robot constructor, so if the screen bounds changes the constructor must be called again to update to the new bounds.
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8345538
>  - move clamping code into macos
>  - use absolute distance to choose correct screen for offscreen clamping
>  - helper function
>  - grab screen data on mouseMove
>  - fix bounds
>  - peer.mouseMove
>  - fix implementation
>  - robot update
>  - Revert "robot multimonitor fix"
>    
>    This reverts commit 5734165881a66dc48d5a9f19e02bf63fac57cdc9.
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8b16897b...e0a5c872

Marked as reviewed by prr (Reviewer).

I think asking Apple is fine. But I don't know that we'd get an answer. We can always revise this if we learn something new 6 months from now.

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

PR Review: https://git.openjdk.org/jdk/pull/22781#pullrequestreview-2823231742
PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2860405243

From dgredler at openjdk.org  Wed May  7 22:23:02 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 7 May 2025 22:23:02 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v2]
In-Reply-To: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
Message-ID: <1iwy1ZiFNN_E6ykAkMS2AG8upZu2MpWp_DZAMGEThJs=.d25c503f-f4dc-4486-8a7d-87b26594664d@github.com>

> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
> 
> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
> 
> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
> 
> The new test class passes on Linux, Windows and macOS.

Daniel Gredler 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:

 - Merge branch 'master' into ignored-whitespace
 - Make Graphics2D.drawString ignore tabs and newlines on macOS
 - Add actual bug ID
 - Add ignored whitespace test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23665/files
  - new: https://git.openjdk.org/jdk/pull/23665/files/a0aeed4a..db3a1ff7

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

  Stats: 499365 lines in 6751 files changed: 183758 ins; 279967 del; 35640 mod
  Patch: https://git.openjdk.org/jdk/pull/23665.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23665/head:pull/23665

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

From serb at openjdk.org  Wed May  7 22:47:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 May 2025 22:47:56 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v13]
In-Reply-To: <yk4mYRZsnZz8Z4koY6rYmF5W8n_u1TTC7VqJO5vycns=.b71ade0d-2a2d-4219-9c77-27c9e650c85a@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
 <yk4mYRZsnZz8Z4koY6rYmF5W8n_u1TTC7VqJO5vycns=.b71ade0d-2a2d-4219-9c77-27c9e650c85a@github.com>
Message-ID: <O_qSAvjNKerFKdw9OquySwlIGyAIsCChRpxVmOdY700=.04fb58e7-1c6e-49f9-bec5-ec8b77d5abd6@github.com>

On Wed, 7 May 2025 16:21:19 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Sure I can create a reproducer and submit an issue to Apple, but is there any reason to not fix the clamping on our end as well?

Look at how many iterations this PR went through and issues it could introduced. The only suspicious thing here is that mouse movement and clicking behave differently(clamp vs not), it is unclear whether the problem exists in our code or in macOS, or it is a feature.

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

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2860619383

From prr at openjdk.org  Wed May  7 22:48:56 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 7 May 2025 22:48:56 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v2]
In-Reply-To: <1iwy1ZiFNN_E6ykAkMS2AG8upZu2MpWp_DZAMGEThJs=.d25c503f-f4dc-4486-8a7d-87b26594664d@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <1iwy1ZiFNN_E6ykAkMS2AG8upZu2MpWp_DZAMGEThJs=.d25c503f-f4dc-4486-8a7d-87b26594664d@github.com>
Message-ID: <VSuxymIF3e4HYhjjubAmCEwT3NzUnClespbcs58IQ58=.7c1d9183-8ab9-4a26-9dcf-e2cf3677822c@github.com>

On Wed, 7 May 2025 22:23:02 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
>> 
>> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
>> 
>> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
>> 
>> The new test class passes on Linux, Windows and macOS.
>
> Daniel Gredler 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:
> 
>  - Merge branch 'master' into ignored-whitespace
>  - Make Graphics2D.drawString ignore tabs and newlines on macOS
>  - Add actual bug ID
>  - Add ignored whitespace test

I don't think
NativeGlyphMapper - used only when we needs the Xserver to render, or
WPathGraphics - a windows printing class

are where I'd expect to find anything that could impact the TestControls test.

But I agree with the general points
- \t \r \n handling can be platform-specific
- macOS printing is very different

The other PR still needs a proper look on my part

I suggest we get this PR pushed but first I'll submit a test job .. unless Harshitha already did that ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2860620842

From prr at openjdk.org  Wed May  7 23:08:53 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 7 May 2025 23:08:53 GMT
Subject: RFR: 8334016: Make PrintNullString.java automatic [v2]
In-Reply-To: <aZFITvpPyrM9GFX3Yx0TNW3raU3KBmYXayqIzyGEGNo=.5d5efdd5-19d2-4af9-b371-186c0feb0793@github.com>
References: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
 <aZFITvpPyrM9GFX3Yx0TNW3raU3KBmYXayqIzyGEGNo=.5d5efdd5-19d2-4af9-b371-186c0feb0793@github.com>
Message-ID: <q6hD0I1mGZQAWdCgOrF2FOCkLiyM3pa2X_-xZBWmwTE=.9d2349ec-7c9d-4127-a826-c5d1f7009669@github.com>

On Wed, 23 Apr 2025 12:25:16 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> I have updated the test and made it semi-automatic (need to click "Print") . Test will initiate a print and result will be generated automatic. 
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made test fully automatic

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24501#pullrequestreview-2823408481

From honkar at openjdk.org  Wed May  7 23:11:54 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 7 May 2025 23:11:54 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v2]
In-Reply-To: <VSuxymIF3e4HYhjjubAmCEwT3NzUnClespbcs58IQ58=.7c1d9183-8ab9-4a26-9dcf-e2cf3677822c@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <1iwy1ZiFNN_E6ykAkMS2AG8upZu2MpWp_DZAMGEThJs=.d25c503f-f4dc-4486-8a7d-87b26594664d@github.com>
 <VSuxymIF3e4HYhjjubAmCEwT3NzUnClespbcs58IQ58=.7c1d9183-8ab9-4a26-9dcf-e2cf3677822c@github.com>
Message-ID: <Qwc9ldz5Eh3clbfDAtJGNyyLnSvdymsEOtlixq_7Z8g=.ee23fe46-708c-4097-b4bf-88feb5cde474@github.com>

On Wed, 7 May 2025 22:46:08 GMT, Phil Race <prr at openjdk.org> wrote:

> I suggest we get this PR pushed but first I'll submit a test job .. unless Harshitha already did that ?

I haven't done a complete CI run along with this PR changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2860653669

From prr at openjdk.org  Wed May  7 23:17:55 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 7 May 2025 23:17:55 GMT
Subject: RFR: 8343618: Stack smashing in awt_InputMethod.c on Linux s390x
In-Reply-To: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
References: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
Message-ID: <QF6PzaOk1kjdya38pageTE4J2bHZZTZI1SfQlXSyCPg=.63702dbd-6087-40a4-9893-f3ad3932d116@github.com>

On Mon, 24 Mar 2025 13:41:44 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> This fixes stack smashing issue in awt library on linux s390x. (jdk compiled with `-fstack-protector-strong`)
> 
> Fix is based on patch [submitted](https://mail.openjdk.org/pipermail/awt-dev/2019-July/015337.html) in JDK-8227919 review thread, rebased to master. They decided to go for Solaris only fix there, with [expected follow-up](https://mail.openjdk.org/pipermail/awt-dev/2019-July/015347.html) for linux/s390x. But that never happened.
> 
> I was not able to get response from original author for this issue, so I am creating PR myself.
> 
> **Testing:**
> I tested jdk with and without this fix on linux/s390x (using Xvfb). It fixes the issue (reproducer for this bug no longer crashes the JVM). I have also tried to run `jdk_awt` tests, where lot of tests was also affected by this. With this patch amount of failures dropped by ~100. 
> 
> Without fix:
> 
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/jdk:jdk_awt                             2171  1063   415     6   687 <<
> 
> 
> With fix
> 
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/jdk:jdk_awt                             2171  1162   316     6   687 <<
> 
> 
> Many tests are no longer crashing the VM:
> 
> -java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java                                                      Failed. Unexpected exit from test [exit code: 134]
> +java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java                                                      Passed. Execution successful
> 
> There seem to be few unstable tests in jdk_awt. (Ones that fail in one or another run, but seem unrelated to this fix)
> 
> I have not done any additional manual testing of XIM as did original author (in review thread mentioned higher), as I am not at all familiar with input method for Japanese (or other Asian characters), or how that supposed to work. (So I cannot verify that input of Asian characters works as expected on linux/s390x, but at least JVM no longer crashes.)

Looks reasonable although it seems an odd behaviour  (bug?) of  XGetICValues

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24197#pullrequestreview-2823434995

From honkar at openjdk.org  Wed May  7 23:22:04 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 7 May 2025 23:22:04 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v2]
In-Reply-To: <1iwy1ZiFNN_E6ykAkMS2AG8upZu2MpWp_DZAMGEThJs=.d25c503f-f4dc-4486-8a7d-87b26594664d@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <1iwy1ZiFNN_E6ykAkMS2AG8upZu2MpWp_DZAMGEThJs=.d25c503f-f4dc-4486-8a7d-87b26594664d@github.com>
Message-ID: <c5swTnoEMTWAMpBt8L-qcx9bZrn3HG3UBlw8KfXRydU=.4a67b4ad-c7c0-4456-b551-668cb82b730e@github.com>

On Wed, 7 May 2025 22:23:02 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
>> 
>> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
>> 
>> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
>> 
>> The new test class passes on Linux, Windows and macOS.
>
> Daniel Gredler 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:
> 
>  - Merge branch 'master' into ignored-whitespace
>  - Make Graphics2D.drawString ignore tabs and newlines on macOS
>  - Add actual bug ID
>  - Add ignored whitespace test

> As an example, this fix addresses the screen display side of things for macOS, but printing on macOS needs to be fixed separately (as can be seen when you run test/jdk/java/awt/print/PrinterJob/PrintTextTest.java). I had a quick look at the corresponding macOS printing issue a few months ago and the fix wasn't obvious, especially given how that part of the code is organized (not really 1-to-1 with the other platforms).

I agree it was not as straightforward to see where to add the fix for windows and linux platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2860675664

From dgredler at openjdk.org  Thu May  8 00:17:56 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 8 May 2025 00:17:56 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v2]
In-Reply-To: <1iwy1ZiFNN_E6ykAkMS2AG8upZu2MpWp_DZAMGEThJs=.d25c503f-f4dc-4486-8a7d-87b26594664d@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <1iwy1ZiFNN_E6ykAkMS2AG8upZu2MpWp_DZAMGEThJs=.d25c503f-f4dc-4486-8a7d-87b26594664d@github.com>
Message-ID: <MDQX3OQu91T9_g3o0wxg658f8G5hjvb6KTAqYk1GtVw=.6da81424-38f9-450f-bd7a-317023bf42c1@github.com>

On Wed, 7 May 2025 22:23:02 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
>> 
>> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
>> 
>> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
>> 
>> The new test class passes on Linux, Windows and macOS.
>
> Daniel Gredler 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:
> 
>  - Merge branch 'master' into ignored-whitespace
>  - Make Graphics2D.drawString ignore tabs and newlines on macOS
>  - Add actual bug ID
>  - Add ignored whitespace test

I haven't had time to test this latest merge on Windows, but my local testing of the current state on Linux and macOS looks good, so I'm cautiously optimistic.

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

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2860895517

From tr at openjdk.org  Thu May  8 04:10:52 2025
From: tr at openjdk.org (Tejesh R)
Date: Thu, 8 May 2025 04:10:52 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
In-Reply-To: <mwA2kTMeaSXuWYCnqXlvhMAJYUA50J58c-8BPaPiLw8=.71bc0dea-2509-491d-878a-ae27b04ec5fd@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <vEWA2CeJs9SmRb8K81xVWRMko2w6xj9Q2hIGXlYUVZM=.e7d736f9-9b2c-4a48-b366-e3801a304f9e@github.com>
 <Ahgb4B8gkI9Cjqwdoq0-Acfcga0QYbiprxAS4k3Fa7U=.c36f229f-2529-4788-8d14-86a51422e373@github.com>
 <vmyVz_91nhgMmjLla6DKOkJGD-Xp_6qajAgUKfeXLoY=.89fefd83-43c9-476c-a951-70a633f9a5e2@github.com>
 <xrKZHsl3CpNOAmppgUcqtxPK_Pb8RinLTrj11RMxGOY=.a64e2fff-04cb-4001-acbb-3c10b24d54de@github.com>
 <f6oYZ6xLi4A9CLobrR9K5ENfgEmSBqTay1kQaf7f3yY=.29f79326-48e7-4ad8-9afb-055536cdb4b2@github.com>
 <isvH5l_2W5YQ-mbpXd3XJMLyp2XP8Yohrq9cxFi84Nc=.27fc812c-b5e4-43df-b9f8-55881331097c@github.com>
 <UzRKXFgBG_WyKaEF3Hjdb3qb2ExAFmUA3UNZI42zMm0=.48021bee-2600-47bf-8c26-bfdddf320592@github.com>
 <MsGQMdJVt_rqNfkj62DVrsBWPlQrx5lsxjnR5BKzl9k=.a8bbbc62-1b60-4982-9424-6af202a6304c@github.com>
 <PfOTt7diduByRh7oViyuN-gJ-3iiD_CnGHIY8Xmni8k=.b52391fd-f576-4c01-923b-209975713596@github.com>
 <HYVRAUlbtJyV9GVAKlTWbeUNMHzV8ugjNuP
 7B4ALY48=.134d9204-f8a9-48fa-85af-982aa124469a@github.com>
 <oTB8PeOedGLLoza4ALZkxGvEdJttzGQb3_eVKwwT0eE=.9f06dd2d-7485-45eb-8cae-af3bad0aa683@github.com>
 <kG1MjZyVmybZj-A8u7ak4GBJ-h06fy5fAxIjFObj45c=.c80b7530-2747-4e56-bb7c-72bc84a612cf@github.com>
 <mwA2kTMeaSXuWYCnqXlvhMAJYUA50J58c-8BPaPiLw8=.71bc0dea-2509-491d-878a-ae27b04ec5fd@github.com>
Message-ID: <QhZ-yOsUL-Y-EFjbyDD98pdW-EqLQk9yIIyIZF-IAh0=.a2145cd5-59fe-437f-81f6-4b468a5e8cb3@github.com>

On Wed, 7 May 2025 21:08:53 GMT, Phil Race <prr at openjdk.org> wrote:

>> Because the problem is still there, and there are virtual folders on Windows. If a custom `FileSystemView` can return file names with `"<html>"` in their name, `JFileChooser` in Windows Look and Feel will render the file name as HTML.
>> 
>> Isn't it the problem that you're trying to fix?
>
> @aivanov-jdk @TejeshR13 
> This seems stalled because there are conflicting statements
> - Alexei : you can create a custom FIleSystemView on windows with <html> in path names.
> - Tejesh : no you can't, or at least it doesn't work when you try to use it.
> 
> Can we please get that reconciled ?
> Tejesh pls show the code you used, and Alexei please show how you would do it.

I tried with this code snippet. 

import javax.swing.JFileChooser;
import javax.swing.SwingUtilities;
import javax.swing.UIManager;
import javax.swing.UnsupportedLookAndFeelException;
import javax.swing.filechooser.FileSystemView;
import java.io.File;
import java.util.Arrays;

public class VirtualFileChooser {

    public static void main(String[] args) throws UnsupportedLookAndFeelException, ClassNotFoundException, InstantiationException, IllegalAccessException {
          UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");
        //UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel");


        SwingUtilities.invokeLater(() -> {
            JFileChooser chooser = new JFileChooser(new VirtualFileSystemView());

            int result = chooser.showOpenDialog(null);
            if (result == JFileChooser.APPROVE_OPTION) {
                File selectedFile = chooser.getSelectedFile();
                System.out.println("Selected: " + selectedFile.getAbsolutePath());
            }
        });
    }

    static class VirtualFileSystemView extends FileSystemView {

        private final File[] roots;

        public VirtualFileSystemView() {
            // Create a dummy root folder
            String name = "<html><h1 color=#ff00ff><font face="Comic Sans MS">SWING ROCKS!!!111";
            roots = new File[]{new File(name)};
        }

        @Override
        public File createNewFolder(File containingDir) {

            File folder = new File(containingDir, "New Folder");
            folder.mkdir();
            return folder;
        }

        @Override
        public File[] getRoots() {
            return roots;
        }

        @Override
        public File getHomeDirectory() {
            return roots[0];
        }

        @Override
        public File getDefaultDirectory() {
            return roots[0];
        }

        @Override
        public File[] getFiles(File dir, boolean useFileHiding) {
            // Simulate a virtual folder structure
            return new File[]{
                    new File(dir, "virtualFile1.txt"),
                    new File(dir, "virtualFile2.txt"),
                    new File(dir, "virtualFolder")
            };
        }

        @Override
        public boolean isRoot(File file) {
            return Arrays.asList(roots).contains(file);
        }

        @Override
        public Boolean isTraversable(File f) {
            return true;
        }
    }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2078849056

From abaya at openjdk.org  Thu May  8 07:34:08 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 8 May 2025 07:34:08 GMT
Subject: Integrated: 8354219 : Automate
 javax/swing/JComboBox/ComboPopupBug.java
In-Reply-To: <xleWDjAur8VerD-q0QvQXfiRoXCDJk0ZsunhHWV72W4=.ed62e2f7-42ca-4153-b92a-39c358f5d6b6@github.com>
References: <xleWDjAur8VerD-q0QvQXfiRoXCDJk0ZsunhHWV72W4=.ed62e2f7-42ca-4153-b92a-39c358f5d6b6@github.com>
Message-ID: <m4qt0Ypq5lMXRh4Ie0VZ5mIldYkpjxn8kU4Wmsbar8Y=.84d8d9a2-f268-479b-a723-bbdc4bdff9ae@github.com>

On Mon, 14 Apr 2025 13:50:54 GMT, Anass Baya <abaya at openjdk.org> wrote:

> This test was designed to manually verify that clicking on the JComboBox when the frame containing it is about to close does not cause an IllegalStateException.
> 
> The test allowed the tester extra time to click on the JComboBox when closing the frame by adding a Thread.sleep() in the close button handler.
> 
> In this test, a JComboBox is displayed with a Close button at the bottom. The tester should click the Close button, then try to click the JComboBox arrow button to display the popup.
> 
> In the automated test, we save the JComboBox  location size before closing the frame. We then use this information to click on the JComboBox right before the frame is closed.

This pull request has now been integrated.

Changeset: 223eec55
Author:    Anass Baya <abaya at openjdk.org>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/223eec55018f1640cb292b11130e3e1d6451990d
Stats:     72 lines in 1 file changed: 29 ins; 14 del; 29 mod

8354219: Automate javax/swing/JComboBox/ComboPopupBug.java

Reviewed-by: aivanov, achung

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

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

From lkorinth at openjdk.org  Thu May  8 15:02:42 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 15:02:42 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for change
 of default timeout factor
Message-ID: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>

This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).

The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.

In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).

My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.

These fixes have been created when I have plown through testcases:
JDK-8352719: Add an equals sign to the modules statement
JDK-8352709: Remove bad timing annotations from WhileOpTest.java
JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
CODETOOLS-7903961: Make default timeout configurable

Sometime in the future I will also fix:
8260555: Change the default TIMEOUT_FACTOR from 4 to 1

for which I am awaiting:
CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1

*After the review I will revert the two first commits, and update the copyrights*

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

Commit messages:
 - 8356171: Increase timeout for testcases as preparation for change of default timeout factor
 - Fix some tests that need an upgrade of JTREG --- REVERT THIS LATER
 - 8260555

Changes: https://git.openjdk.org/jdk/pull/25122/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356171
  Stats: 556 lines in 272 files changed: 59 ins; 96 del; 401 mod
  Patch: https://git.openjdk.org/jdk/pull/25122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25122/head:pull/25122

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

From stefank at openjdk.org  Thu May  8 16:09:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 May 2025 16:09:00 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thanks for tackling this! I look forward to the day when you change TIMEOUT_FACTOR to be 1 by default. I think that will reduce confusion.

I made a cursory look through some GC files and I think that looked good.

doc/testing.md line 385:

> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
> 384: certain amount of time will apply this factor. If we run in
> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

Maybe
Suggestion:

interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

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

PR Review: https://git.openjdk.org/jdk/pull/25122#pullrequestreview-2825661242
PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080028720

From dfuchs at openjdk.org  Thu May  8 16:28:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 16:28:53 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <VKBSy10yl0qvIk0P_JQb3KGFkmaDEtWYzncAlEW7VV8=.bd136181-45be-437e-b684-2ad16ac419b5@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

@lkorinth have you run all the tiers where the old default timeout factor of 4 applied?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863633579

From lkorinth at openjdk.org  Thu May  8 16:45:56 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 16:45:56 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Before this version, I had run tiers 1-8, with 11 fails.

** DONE 01 serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java#debug 700
** DONE 02 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 03 tools/javac/util/IteratorsTest.java 480
** DONE 04 java/math/BigInteger/LargeValueExceptions.java 480
** DONE 05 vmTestbase/gc/gctests/WeakReference/weak004/weak004.java OTHER
** DONE 06 compiler/loopstripmining/CheckLoopStripMining.java OTHER
** DONE 07 sun/security/tools/keytool/fakecacerts/TrustedCert.java 480
** DONE 08 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 09 containers/docker/TestJFRNetworkEvents.java OTHER
** DONE 10 java/foreign/TestMismatch.java 480
** DONE 11 linux-riscv64-open-cmp-baseline-linux-x64-build-796 OTHER

Six of those seems not related to my changes (marked `OTHER`),  five  I have updated for this run with new timeout.

I have fixed the timeouts and rebased (I had one conflict), and I am now again running tier1-8. It will take time, and it looks like I will have more (unrelated) fails this time.

After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863670496
PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863675379

From itakiguchi at openjdk.org  Thu May  8 16:54:55 2025
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Thu, 8 May 2025 16:54:55 GMT
Subject: RFR: 8343618: Stack smashing in awt_InputMethod.c on Linux s390x
In-Reply-To: <_eOfl-anqDLwR6jF6HhNA6oxc4ckZMA8GpwnMfWX73M=.bf4264e7-3aeb-40ac-a136-271b2cbb2a11@github.com>
References: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
 <3YjyS-OEdDbu9Gx4R4aGdgnH3CQxOmWveykhXMRE858=.ee5cbd82-e7d2-4f3f-b990-02b89841f750@github.com>
 <_eOfl-anqDLwR6jF6HhNA6oxc4ckZMA8GpwnMfWX73M=.bf4264e7-3aeb-40ac-a136-271b2cbb2a11@github.com>
Message-ID: <VdDBPInnAO13plYmByLcSdbHhLJKmN0XCvoVpGZS-3Q=.d1b41921-7ee5-4f15-8fad-b31799b81ba9@github.com>

On Wed, 23 Apr 2025 15:10:29 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

>> Attaching jdk_awt jtreg results (with and without fix).
>> [jdk-awt-results.tgz](https://github.com/user-attachments/files/19430946/jdk-awt-results.tgz)
>
>> @zzambers Sorry for my late reaction. Is it possible to add test result by using `XMODIFIERS=@im=local` ?
> 
> Thank you for you reaction.
> 
> I can do some additional testing. You mean to just run the tests with `XMODIFIERS` env. variable set to given value? Are there any other requirements about test system? Note that I only have access to headless linux/s390x machines, so I used Xvfb as X11 server.

@zzambers 
Sorry I'm late.
I could recreate your issue.
In my investigation,
Case 1: When I specified usable IM name, like `XMODIFIERS=@im=kinput2`, ` XGetICValues` returns like `0x200000000` instead of `0x2`.
Case 2: When I specified `XMODIFIERS=@im=local`, ` XGetICValues` returns `0x2`.
(It's the same as `XMODIFIERS=@im=none` or XMODIFIERS is unset)
I think it means case 2 just handles inside of Xlib without X protocol.
Your fix works fine on my test environment.

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

PR Comment: https://git.openjdk.org/jdk/pull/24197#issuecomment-2863698338

From lkorinth at openjdk.org  Thu May  8 17:06:02 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 17:06:02 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
Message-ID: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>

On Thu, 8 May 2025 16:04:53 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> doc/testing.md line 385:
> 
>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>> 384: certain amount of time will apply this factor. If we run in
>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> Maybe
> Suggestion:
> 
> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080117016

From kizune at openjdk.org  Thu May  8 17:19:51 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 8 May 2025 17:19:51 GMT
Subject: RFR: 8356053: Test java/awt/Toolkit/Headless/HeadlessToolkit.java
 fails by timeout
In-Reply-To: <rSxJ8yhJauBlv1dbHab2d61J46SjG7-54OvIaBtCteU=.354eaf8c-8257-4147-b45b-c7045755424a@github.com>
References: <rSxJ8yhJauBlv1dbHab2d61J46SjG7-54OvIaBtCteU=.354eaf8c-8257-4147-b45b-c7045755424a@github.com>
Message-ID: <-oXa-MwM2L3Wi9ylpW1XTlt-6Q4tdsULT6h8qyIyV-0=.923272d9-bd99-4334-ba8c-4fb0d02d28e2@github.com>

On Mon, 5 May 2025 17:44:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The `java/awt/Toolkit/Headless/HeadlessToolkit.java` test covers some functionality of various methods in the `HeadlessToolkit` class, specifically whether these methods throw a `HeadlessException` or not. The image-related methods do not require access to a remote server via a URL; they can be tested using a URL pointing to a local file. This ensures that the test does not depend on `openjdk.org`.

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25045#pullrequestreview-2825841095

From dfuchs at openjdk.org  Thu May  8 17:43:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 17:43:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
Tests have not finished running - but I already see one intermittent failure:
`java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
It would be good to flush out any such intermittent failures before this PR is integrated.
This might require multiple runs before we can get confidence.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863805648

From prr at openjdk.org  Thu May  8 19:21:06 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 8 May 2025 19:21:06 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v2]
In-Reply-To: <1iwy1ZiFNN_E6ykAkMS2AG8upZu2MpWp_DZAMGEThJs=.d25c503f-f4dc-4486-8a7d-87b26594664d@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <1iwy1ZiFNN_E6ykAkMS2AG8upZu2MpWp_DZAMGEThJs=.d25c503f-f4dc-4486-8a7d-87b26594664d@github.com>
Message-ID: <WKNW-BTPz3aszdz3qL8QAoLcgnJjC51O_y4jodwXpmQ=.9fef1357-6eee-4e6b-8437-2b1439f491d1@github.com>

On Wed, 7 May 2025 22:23:02 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
>> 
>> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
>> 
>> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
>> 
>> The new test class passes on Linux, Windows and macOS.
>
> Daniel Gredler 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:
> 
>  - Merge branch 'master' into ignored-whitespace
>  - Make Graphics2D.drawString ignore tabs and newlines on macOS
>  - Add actual bug ID
>  - Add ignored whitespace test

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23665#pullrequestreview-2826144863

From achung at openjdk.org  Thu May  8 20:00:40 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 8 May 2025 20:00:40 GMT
Subject: RFR: 8343739: Test
 java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java failed: Wrong
 extended key code [v4]
In-Reply-To: <ubVHDLbUmS2V0etEvYlsOVr-1H6ZQxayrQTU4bXxz-o=.075cef8e-5d34-43de-8870-09e6afa4f588@github.com>
References: <ubVHDLbUmS2V0etEvYlsOVr-1H6ZQxayrQTU4bXxz-o=.075cef8e-5d34-43de-8870-09e6afa4f588@github.com>
Message-ID: <0lPsNSeiz4axJaYDwGkXxjmChM7JE87jXvyjMWtxKJQ=.44de2e2e-16e0-4e95-92fd-48559fb3dfe3@github.com>

> Test was failing on Ubuntu, looks to be a synchronous error in the test so I rewrote it to improve stability.

Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:

 - remove author, update summary
 - revert test, add logging

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24885/files
  - new: https://git.openjdk.org/jdk/pull/24885/files/711bd81f..efcc2a77

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

  Stats: 87 lines in 1 file changed: 26 ins; 45 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24885.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24885/head:pull/24885

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

From prr at openjdk.org  Thu May  8 20:02:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 8 May 2025 20:02:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

test/jdk/java/awt/font/NumericShaper/MTTest.java

- * @run main/timeout=300/othervm MTTest
+ * @run main/timeout=1200/othervm MTTest

I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.

https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java

So 300 was fine, and 1200 isn't needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864133534

From achung at openjdk.org  Thu May  8 20:03:51 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 8 May 2025 20:03:51 GMT
Subject: RFR: 8343739: Test
 java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java failed: Wrong
 extended key code [v3]
In-Reply-To: <iLK3z5iBImsqjqWlVZ7P-mLQQ6dYMQsqUXIw08eKqoE=.fe66c83a-869d-463c-9c3a-db8d41e50a17@github.com>
References: <ubVHDLbUmS2V0etEvYlsOVr-1H6ZQxayrQTU4bXxz-o=.075cef8e-5d34-43de-8870-09e6afa4f588@github.com>
 <-VKRExcwuamNGxB1FbvYY_rA-dXICYFodaqiI2QnSe0=.0c5f4481-4016-4333-8360-3c6d519f710b@github.com>
 <ht3_2I2H1FIIA8XGRX5o7kpGHn80Aw9z6rtEYI53oLU=.0ca28b73-57fb-4ebf-85b1-efe73bf2d898@github.com>
 <iLK3z5iBImsqjqWlVZ7P-mLQQ6dYMQsqUXIw08eKqoE=.fe66c83a-869d-463c-9c3a-db8d41e50a17@github.com>
Message-ID: <56-CkiOPqQWo_63QhuCLxnk9ZOPw03fdzKl3PZPsxhk=.787cbf57-d426-4c38-82a1-19f1b13404cf@github.com>

On Tue, 6 May 2025 23:24:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I've updated the test to include logging and ran the test 200x without failures. I think it's ok to push the test with these changes so that if the test ever does fail again we can use the logs and analyze the problem.
> 
> I meant to run the test 200 times with logging but no other changes to find the root cause. The other changes to the test seems unnecessary at first glance. the test operations are already synchronized and delayed when necessary.

I've reverted the test and added logging for the eventsCount. I've run the test thru mach5 again without failures 200x. For now adding logging to the test is probably sufficient for debugging if the failure happens again.

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

PR Comment: https://git.openjdk.org/jdk/pull/24885#issuecomment-2864135431

From prr at openjdk.org  Thu May  8 20:50:06 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 8 May 2025 20:50:06 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v13]
In-Reply-To: <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
Message-ID: <bNRrYna0tu4wKw1EVwHGweiHDx0wRwPGS9KKPIeX5HA=.4305b22a-a2fe-4ed3-a2f2-4ef6875e757b@github.com>

On Wed, 30 Apr 2025 21:13:12 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Currently on macOS when mouseMove is given an offscreen coordinate to move the mouse to, mouseMove will physically clamp to the edge of the screen, but if you try to grab the mouse location immediately after by using MouseInfo.getPointerInfo().getLocation() you will get the value of the offscreen point.
>> 
>> Windows and linux do this clamping and coordinate handling for us, but new distributions may not necessarily handle clamping the same way, so Robot should be checking for clamping rather than delegating it to native.
>> 
>> This fix updates shared code to cache the screen bounds and adds a check to not exceed the bounds in mouseMove. The caching is done in the Robot constructor, so if the screen bounds changes the constructor must be called again to update to the new bounds.
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8345538
>  - move clamping code into macos
>  - use absolute distance to choose correct screen for offscreen clamping
>  - helper function
>  - grab screen data on mouseMove
>  - fix bounds
>  - peer.mouseMove
>  - fix implementation
>  - robot update
>  - Revert "robot multimonitor fix"
>    
>    This reverts commit 5734165881a66dc48d5a9f19e02bf63fac57cdc9.
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8b16897b...e0a5c872

> Previously, we used a different method, which might behave differently (It also used a different thread): [eea06f7#diff-698576e56937835cfc553bbd97fe12fabf954e0a20e7b9c3bfc3a77763fb6bd0L123](https://github.com/openjdk/jdk/commit/eea06f70fc6154be12d066df6669e7c6d8c0bc09#diff-698576e56937835cfc553bbd97fe12fabf954e0a20e7b9c3bfc3a77763fb6bd0L123)

More on the above ..
The fix you linked to was to "unify" getting mouse location.

 src/macosx/native/sun/awt/CCursorManager.m

<  [NSEvent mouseLocation]
>  CGEventRef event = CGEventCreate(NULL);
>  CGPoint globalPos = CGEventGetLocation(event);

src/macosx/native/sun/awt/CRobot.m

<  CGEventRef event = CGEventCreate(NULL);
<  CGPoint globalPos = CGEventGetLocation(event);

So what it did is delete the code in CRobot that did it and move it into CCursorManager.
So CCursorManager now does EXACTLY what Robot used to do.
And CCursorManager's old code using NSEvent superficially looked different but these really are the same underlying API

https://developer.apple.com/documentation/appkit/nsevent/cgevent?language=objc

Moreover, it looks like as part of the "unification" the fix dropped clamping code in Robot (!)

https://cr.openjdk.org/%7Epchelko/9/8035568/webrev.02/src/macosx/native/sun/awt/CRobot.m.udiff.html

So I guess we are fixing a regression caused by that fix, and perhaps more precisely to the bounds.

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

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2864275801

From serb at openjdk.org  Thu May  8 21:12:32 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 May 2025 21:12:32 GMT
Subject: RFR: 8356571: Re-enable -Wtype-limits for GCC in LCMS
Message-ID: <IOL-FKL69oLcujdfZcXzybD1AxIBCMf0rwDDx4RILOk=.714f04d5-482e-43e1-98a1-65c2b1740bc2@github.com>

The -Wtype-limits warning was previously disabled in the OpenJDK build for LCMS 2.14+ due to upstream issues: https://github.com/openjdk/jdk/pull/11217
The issue was reported to the LCMS project: https://github.com/mm2/Little-CMS/issues/458
It has since been fixed in LCMS 2.17 and integrated into OpenJDK as part of [JDK-8348110](https://bugs.openjdk.org/browse/JDK-8348110).

Now that the issue has been resolved, we can re-enable this warning.

The build works fine on the system where the initial [issue](https://github.com/openjdk/jdk/pull/11217) could be reproduced.

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

Commit messages:
 - 8356571: Re-enable -Wtype-limits for GCC in LCMS

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

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

From prr at openjdk.org  Thu May  8 21:29:20 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 8 May 2025 21:29:20 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v15]
In-Reply-To: <Idbkr_1O6El_xQd5NqPpe4wvCrnN7ILYcH7lK2nx-3w=.9a87e19e-f975-4820-8b89-c066c233301c@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <xdbhtBgikqvegs36jK5HQykyZPSHJ_hhB5xDCg_dqxw=.97a8c90f-4b87-406a-b0a7-1c73722f1e26@github.com>
 <Idbkr_1O6El_xQd5NqPpe4wvCrnN7ILYcH7lK2nx-3w=.9a87e19e-f975-4820-8b89-c066c233301c@github.com>
Message-ID: <rwkuHsqWQfZZAFxpylJZHZnPcWHJ1f0O2KimS7WbGxw=.2a3d404c-3000-4943-a3d9-dd619529aebc@github.com>

On Mon, 24 Feb 2025 20:10:58 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - merge
>>  - update specifications, replace default values in specifications with links to default var
>>  - update glide in test
>>  - merge
>>  - fix test with removed robot.glide using points
>>  - add code tag to specifications in Robot
>>  - fix syncdelay in ER
>>  - removing lesser used overridden methods
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8150564
>>  - update specification to public default fields, add waitforidle exceptions to specifications
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/10791477...30ca6a6b
>
> src/java.desktop/share/classes/java/awt/Robot.java line 130:
> 
>> 128: 
>> 129:     /**
>> 130:      * Default 20 milliseconds delay for mouse {@code click} and
> 
> Suggestion:
> 
>      * Default delay for mouse {@code click} and
> 
> 
> There is no need to specify the exact value in the documentation,  in case of something it will be much easier to change it later on.

Be aware that values of static fields are automatically documented.
eg see
(https://docs.oracle.com/en/java/javase/21/docs/api/constant-values.html#java.awt.Font.BOLD)

And an app really could use knowing what the default is.
And these defaults have been battle-tested in ExtendedRobot

> src/java.desktop/share/classes/java/awt/Robot.java line 138:
> 
>> 136:      * Default 2 pixel step length for mouse {@code glide}.
>> 137:      */
>> 138:     public static final int DEFAULT_STEP_LENGTH = 2;
> 
> Do we want to make the `DEFAULT_DELAY` and `DEFAULT_STEP_LENGTH` configurable?

glide  has over-rides step length

> src/java.desktop/share/classes/java/awt/Robot.java line 792:
> 
>> 790:      * and {@code mouseRelease}. Invokes {@code waitForIdle} with a default {@link #DEFAULT_DELAY delay} after
>> 791:      * {@code mousePress} and {@code mouseRelease} calls. For specifics on valid inputs please see
>> 792:      * {@link java.awt.Robot#mousePress(int)}.
> 
> It's discussable, and I may be wrong, but I'm not a fan of documentation that is very specific about its implementation.
> I prefer the one that was before in the `ExtendedRobot`.
> 
> 
> Clicks mouse button(s) by calling {@link #mousePress(int)} and {@link #mouseRelease(int)} methods

I understand the concern but in this case it is more or less explanation of what the method does. Perhaps it can be adjusted or made in to an apiNote or whatever is best.

> src/java.desktop/share/classes/java/awt/Robot.java line 924:
> 
>> 922:             x += tDx;
>> 923:             y += tDy;
>> 924:             mouseMove((int)x, (int)y);
> 
> `mouseMove` can throw an `IllegalThreadStateException` under certain circumstances.

yes should be added to all glide API methods

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2080487052
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2080487420
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2080490231
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2080491661

From prr at openjdk.org  Thu May  8 21:57:03 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 8 May 2025 21:57:03 GMT
Subject: RFR: 8346683: Problem list automated tests that fail on macOS15
Message-ID: <GEVbajFEhtK-c15NpnFo80aMbDS9gdkphLOaUfwZ4hs=.5e39d486-55c8-4ac0-ae69-f598db77c100@github.com>

We've not been doing regular automated testing on macoS 15.4 and it is well over-due.

Extensive testing (all tests run 100 times) reports 3 tests that always fail on macOS 15.4 that we should problem list to enable it.

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

Commit messages:
 - 8346683

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

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

From jwaters at openjdk.org  Thu May  8 22:08:52 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 8 May 2025 22:08:52 GMT
Subject: RFR: 8356571: Re-enable -Wtype-limits for GCC in LCMS
In-Reply-To: <IOL-FKL69oLcujdfZcXzybD1AxIBCMf0rwDDx4RILOk=.714f04d5-482e-43e1-98a1-65c2b1740bc2@github.com>
References: <IOL-FKL69oLcujdfZcXzybD1AxIBCMf0rwDDx4RILOk=.714f04d5-482e-43e1-98a1-65c2b1740bc2@github.com>
Message-ID: <LXf4kQTelGXbzmECSkHch4CEiJrVrioHHcFggyiJiR0=.e818ae31-f289-4d03-9fce-6449cd949f8d@github.com>

On Thu, 8 May 2025 18:30:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The -Wtype-limits warning was previously disabled in the OpenJDK build for LCMS 2.14+ due to upstream issues: https://github.com/openjdk/jdk/pull/11217
> The issue was reported to the LCMS project: https://github.com/mm2/Little-CMS/issues/458
> It has since been fixed in LCMS 2.17 and integrated into OpenJDK as part of [JDK-8348110](https://bugs.openjdk.org/browse/JDK-8348110).
> 
> Now that the issue has been resolved, we can re-enable this warning.
> 
> The build works fine on the system where the initial [issue](https://github.com/openjdk/jdk/pull/11217) could be reproduced.

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25127#pullrequestreview-2826465217

From prr at openjdk.org  Thu May  8 22:33:51 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 8 May 2025 22:33:51 GMT
Subject: RFR: 8356571: Re-enable -Wtype-limits for GCC in LCMS
In-Reply-To: <IOL-FKL69oLcujdfZcXzybD1AxIBCMf0rwDDx4RILOk=.714f04d5-482e-43e1-98a1-65c2b1740bc2@github.com>
References: <IOL-FKL69oLcujdfZcXzybD1AxIBCMf0rwDDx4RILOk=.714f04d5-482e-43e1-98a1-65c2b1740bc2@github.com>
Message-ID: <YQT9Amc3iKqMk5r3xA93qyDms3hjqj9mjPb28KJz5Dg=.79fcb97f-34de-4bea-8e37-c44009db9e15@github.com>

On Thu, 8 May 2025 18:30:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The -Wtype-limits warning was previously disabled in the OpenJDK build for LCMS 2.14+ due to upstream issues: https://github.com/openjdk/jdk/pull/11217
> The issue was reported to the LCMS project: https://github.com/mm2/Little-CMS/issues/458
> It has since been fixed in LCMS 2.17 and integrated into OpenJDK as part of [JDK-8348110](https://bugs.openjdk.org/browse/JDK-8348110).
> 
> Now that the issue has been resolved, we can re-enable this warning.
> 
> The build works fine on the system where the initial [issue](https://github.com/openjdk/jdk/pull/11217) could be reproduced.

CI Linux build passes

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25127#pullrequestreview-2826493341

From lmesnik at openjdk.org  Thu May  8 23:12:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 8 May 2025 23:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
 <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
Message-ID: <inHeApQE1qTo35yQi6vzs6LYuATsr8NxmEMOU_1x_5c=.6ea734d1-63f2-47dc-a245-23d3233c76e4@github.com>

On Thu, 8 May 2025 17:03:03 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> doc/testing.md line 385:
>> 
>>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>>> 384: certain amount of time will apply this factor. If we run in
>>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> Maybe
>> Suggestion:
>> 
>> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)
>
> Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

yep, let use Xcomp, the Xint is not really supported, a lot of tests might start failing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080606853

From lmesnik at openjdk.org  Fri May  9 00:55:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 9 May 2025 00:55:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <2oUdV1ca6y_cEHL3kTptk3jAlwCwnvsLGhRIAhVEUo8=.010c2226-c5ec-4508-be7f-90d244b2b7dc@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Can you please proposed fix for https://bugs.openjdk.org/browse/JDK-8260555 to make it more clear the complete goal of the fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864795990

From serb at openjdk.org  Fri May  9 02:10:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 9 May 2025 02:10:56 GMT
Subject: Integrated: 8356571: Re-enable -Wtype-limits for GCC in LCMS
In-Reply-To: <IOL-FKL69oLcujdfZcXzybD1AxIBCMf0rwDDx4RILOk=.714f04d5-482e-43e1-98a1-65c2b1740bc2@github.com>
References: <IOL-FKL69oLcujdfZcXzybD1AxIBCMf0rwDDx4RILOk=.714f04d5-482e-43e1-98a1-65c2b1740bc2@github.com>
Message-ID: <BHiIZ3iqc0DbSqCDAHzGY_HL8J9zR4q08OT9tHl5sok=.0f948139-10b7-4b2f-8110-f4e9d1c4b79c@github.com>

On Thu, 8 May 2025 18:30:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The -Wtype-limits warning was previously disabled in the OpenJDK build for LCMS 2.14+ due to upstream issues: https://github.com/openjdk/jdk/pull/11217
> The issue was reported to the LCMS project: https://github.com/mm2/Little-CMS/issues/458
> It has since been fixed in LCMS 2.17 and integrated into OpenJDK as part of [JDK-8348110](https://bugs.openjdk.org/browse/JDK-8348110).
> 
> Now that the issue has been resolved, we can re-enable this warning.
> 
> The build works fine on the system where the initial [issue](https://github.com/openjdk/jdk/pull/11217) could be reproduced.

This pull request has now been integrated.

Changeset: 9a0e6f33
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a0e6f338f34fb5da16d5f9eb710cdddd4302945
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8356571: Re-enable -Wtype-limits for GCC in LCMS

Reviewed-by: jwaters, prr

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

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

From dholmes at openjdk.org  Fri May  9 04:57:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 04:57:50 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

My biggest concern with this change is that potentially any test that implicitly uses the default timeout, and which passes with no problem with a factor of 4, may now need to have an explicit timeout set due to the factor of 1. I see this change in a number of tests (default timeout of 120s expressed as a new timeout of 480s to maintain equivalence**), but how many times did you run the tiers? I fear that the gatekeepers will be playing timeout whack-a-mole once these changes are put in.

** though another option would be to update the jtreg default timeout instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865099247

From dmarkov at openjdk.org  Fri May  9 06:47:51 2025
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Fri, 9 May 2025 06:47:51 GMT
Subject: RFR: 8346683: Problem list automated tests that fail on macOS15
In-Reply-To: <GEVbajFEhtK-c15NpnFo80aMbDS9gdkphLOaUfwZ4hs=.5e39d486-55c8-4ac0-ae69-f598db77c100@github.com>
References: <GEVbajFEhtK-c15NpnFo80aMbDS9gdkphLOaUfwZ4hs=.5e39d486-55c8-4ac0-ae69-f598db77c100@github.com>
Message-ID: <9nwBRRPsAaKqNRLWYGSPVv6qIvR2TUSxN0OXmbEavEQ=.db072480-2ec8-49b9-ae6c-a73d1c8a0f77@github.com>

On Thu, 8 May 2025 21:52:21 GMT, Phil Race <prr at openjdk.org> wrote:

> We've not been doing regular automated testing on macoS 15.4 and it is well over-due.
> 
> Extensive testing (all tests run 100 times) reports 3 tests that always fail on macOS 15.4 that we should problem list to enable it.

Marked as reviewed by dmarkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25133#pullrequestreview-2827190059

From dfuchs at openjdk.org  Fri May  9 07:18:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 07:18:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
Message-ID: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>

On Thu, 8 May 2025 17:41:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
> Tests have not finished running - but I already see one intermittent failure:
> `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
> It would be good to flush out any such intermittent failures before this PR is integrated.
> This might require multiple runs before we can get confidence.

Results came back - another intermittent timeout failure (much more frequent) observed in:
`java/net/httpclient/CancelledResponse.java` on macOS x64

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865413003

From cstein at openjdk.org  Fri May  9 07:36:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 07:36:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
Message-ID: <P_bn9YLGadoCvpQ4U3pQCWqa_FgbqOs_Smf_TRfTUxw=.5db4086c-fef8-437b-aa77-26124ea44177@github.com>

On Fri, 9 May 2025 04:54:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> [...]
> ** though another option would be to update the jtreg default timeout instead.

And affect all other tests, too? I'd rather let the default stay on the former hard-coded 120s value.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865469908

From alanb at openjdk.org  Fri May  9 08:12:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 08:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <togAOydR2ZGmRMpEDKHz7PXzdWIRLYaU6sFIlHUXUw4=.cdb2a446-5f7c-438e-8f1e-2d8bad8c9327@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ?  If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865581927

From swen at openjdk.org  Fri May  9 08:21:23 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 9 May 2025 08:21:23 GMT
Subject: RFR: 8356605: JRSUIControl.hashCode and JRSUIState.hashCode can use
 Long.hasCode
Message-ID: <nWA2jQWQE9lsM5Z2W8K7WniquRWpEBQWbtCYF2dN6iA=.7ad7b55a-6fa7-4331-bc9a-dac1d21726c8@github.com>

Similar to #24959 and #24971 and #24987, apple.laf.JRSUIControl and apple.laf.JRSUIState in java.desktop can also be simplified similarly.

Replace manual bitwise operations in hashCode implementations of JRSUIControl/JRSUIState with Long::hashCode.

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

Commit messages:
 - Use Double::hashCode & Long::hashCode

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

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

From lkorinth at openjdk.org  Fri May  9 08:32:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:32:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <uabWdORniwCo0BELgwEHL9xwszL7WvN02cMLTu253K4=.de2529aa-23d2-4c86-9133-504f4146c93e@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I feel almost all of the comments raised here are for me changing the timeout factor to `1`. I will try to answer those questions here as well, but note that the timeout factor is not to be changed to `1` in this pull request and will remain 4, so excluding bugs I might have introduced, tiers would --- if anything --- be running more stable after the change as I have only increased timeouts.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865644966

From lkorinth at openjdk.org  Fri May  9 08:42:58 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:42:58 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
Message-ID: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>

On Fri, 9 May 2025 07:14:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI. Tests have not finished running - but I already see one intermittent failure: `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows. It would be good to flush out any such intermittent failures before this PR is integrated. This might require multiple runs before we can get confidence.

My change of timeout factor to `0.7` is only temporal, as I said: it will be reverted to `4` before integration. Naturally, a few test cases will timeout when I do this /temporal/ change, hopefully `java/net/httpclient/RedirectTimeoutTest.java` will behave well with a timeout factor of `1` instead of `0.7`, but note that I will revert the timeout factor to `4` before integration. 

The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865685066

From stefank at openjdk.org  Fri May  9 08:48:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 08:48:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.

Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865697701

From lkorinth at openjdk.org  Fri May  9 09:02:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:02:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
Message-ID: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>

On Thu, 8 May 2025 20:00:21 GMT, Phil Race <prr at openjdk.org> wrote:

> test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
>     * * @run main/timeout=300/othervm MTTest
> 
> 
>     * * @run main/timeout=1200/othervm MTTest
> 
> 
> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> 
> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
> So 300 was fine, and 1200 isn't needed.

I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865742871

From lkorinth at openjdk.org  Fri May  9 09:12:19 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:12:19 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> - * @run main/timeout=300/othervm MTTest
>> + * @run main/timeout=1200/othervm MTTest
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
>
>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>>     * * @run main/timeout=300/othervm MTTest
>> 
>> 
>>     * * @run main/timeout=1200/othervm MTTest
>> 
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

> @lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ? If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change if the scaling is adjusted in the future. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

The code was run as it currently looks (with a timeout factor of `0.7`), what timeout factor do you think I should use to test, and for how many times?

At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to `1` will happen after the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865784064

From cstein at openjdk.org  Fri May  9 09:15:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 09:15:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
 <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
Message-ID: <LWO7Q1kcmK2ygzbo5WovS47Dbuj_vfNTrTCvtPe8eLs=.4247df94-1d6d-4be7-bd56-77257bea18f7@github.com>

On Fri, 9 May 2025 09:09:34 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to 1 will happen after the fork.

Note, that I moved the timeout configuration feature to `jtreg` 7.5.2 - which will be released soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865793769

From lkorinth at openjdk.org  Fri May  9 09:15:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:15:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
Message-ID: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>

On Fri, 9 May 2025 08:45:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> 
> Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865794195

From stefank at openjdk.org  Fri May  9 09:19:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 09:19:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
 <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
Message-ID: <rN9e2v3Ja1Kz4w4CsS6pDyFKNs88tAacAG4wiwWaK6w=.abf1d75b-861b-4de9-8e7b-61deca3e5e05@github.com>

On Fri, 9 May 2025 09:13:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> > 
> > 
> > Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?
> 
> I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

I understand the risk of being blocked on JDK-8260555, but frankly, if someone wants to block the change from 4 to 1 I'm not sure this PR is worth doing. We have enough groups represented in this PR so let's ask here: is anyone is opposing the idea of JDK-8260555?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865804474

From dfuchs at openjdk.org  Fri May  9 09:33:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 09:33:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <vhPQ5uxCX4mkm_a34_Elnbjxazr49tOXu_ezw8YbY_g=.81d3c926-7a82-4f4a-95b2-336c63350801@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

Yes - I understand. My point is that there are probably more tests that will need an extended timeout than those that you have already modified. And we want to find out which before the actual change from 4 to 1.0. IMO if a test fails intermittently with 0.7, it's a good indication that it might continue failling intermittently with 1.0, and therefore it should be updated in this PR too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865849069

From duke at openjdk.org  Fri May  9 10:54:57 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 9 May 2025 10:54:57 GMT
Subject: RFR: 8352149: open/test/jdk/java/awt/Frame/MultiScreenTest.java
 fails [v4]
In-Reply-To: <Io5zeUTgCYEDU2bJ34OGVS1ox8n2koIwl4pZg_he5-Y=.f91ba94f-c563-49b5-910a-7567ba1f31e5@github.com>
References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com>
 <Io5zeUTgCYEDU2bJ34OGVS1ox8n2koIwl4pZg_he5-Y=.f91ba94f-c563-49b5-910a-7567ba1f31e5@github.com>
Message-ID: <7lH7KVuhkVxHDhzOqxkyIUNiuGu9812d5lMZL0NpKo8=.2fafe422-6ff9-4954-9f97-19489db1497a@github.com>

On Wed, 30 Apr 2025 17:06:39 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Fixes issue in which the test fails when run on multi-screen machine.
>> 
>> Tested on Ubuntu 24.04, MacOS 15 and Windows 11
>> 
>> JTREG
>> 
>> runner starting test: java/awt/Frame/MultiScreenTest.java
>> runner finished test: java/awt/Frame/MultiScreenTest.java
>> Passed. Execution successful
>
> Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
> 
>   8352149: test/jdk/java/awt/Frame/MultiScreenTest.java fails in MacOS

Test has passed on MacOSX, Linux (Ubuntu X11) and Windows machines.

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

PR Comment: https://git.openjdk.org/jdk/pull/24752#issuecomment-2866099014

From abhiscxk at openjdk.org  Fri May  9 11:57:53 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 9 May 2025 11:57:53 GMT
Subject: RFR: 8352149: open/test/jdk/java/awt/Frame/MultiScreenTest.java
 fails [v4]
In-Reply-To: <Io5zeUTgCYEDU2bJ34OGVS1ox8n2koIwl4pZg_he5-Y=.f91ba94f-c563-49b5-910a-7567ba1f31e5@github.com>
References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com>
 <Io5zeUTgCYEDU2bJ34OGVS1ox8n2koIwl4pZg_he5-Y=.f91ba94f-c563-49b5-910a-7567ba1f31e5@github.com>
Message-ID: <Amie9oR9XHMk5U8QpCH_6mdJZbVOv5Yi2MBOtvck_HU=.b073d4e5-f8ce-4a80-9986-1d5646fe4ed7@github.com>

On Wed, 30 Apr 2025 17:06:39 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Fixes issue in which the test fails when run on multi-screen machine.
>> 
>> Tested on Ubuntu 24.04, MacOS 15 and Windows 11
>> 
>> JTREG
>> 
>> runner starting test: java/awt/Frame/MultiScreenTest.java
>> runner finished test: java/awt/Frame/MultiScreenTest.java
>> Passed. Execution successful
>
> Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8352149: test/jdk/java/awt/Frame/MultiScreenTest.java fails in MacOS

It may seem out of scope of this bug but you can add `@Override` annotation for all overridden methods, not mandatory though.

Please update PR title.

test/jdk/java/awt/Frame/MultiScreenTest.java line 104:

> 102:                 for (int i = 0; i < gc.length && i < 10; i++) {
> 103:                     JFrame f = new JFrame(gc[i]); //test JFrame( gc )
> 104:                     GCCanvas c = new GCCanvas(gc[i]);//test canvas( gc )

For consistency, add a space before start of comment.
Suggestion:

                    GCCanvas c = new GCCanvas(gc[i]); // test canvas( gc )

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

PR Review: https://git.openjdk.org/jdk/pull/24752#pullrequestreview-2828017540
PR Comment: https://git.openjdk.org/jdk/pull/24752#issuecomment-2866264022
PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2081510982

From dholmes at openjdk.org  Fri May  9 12:21:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 12:21:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <3CKLh1TDhqMNxlWyINFVMAI6MGe_s2rJrgnfzXYpx2M=.ab9a5cb5-9671-4b90-ba81-83f65b82cd6d@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I saw this PR as preparation for the change of the timeout factor so they could be reviewed distinctly and then integrated close together. So it is natural that people are querying how the proposed changes will work with that change - in particular if it will require explicit timeouts to be added to a lot of tests that don't presently have them.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866338479

From lkorinth at openjdk.org  Fri May  9 12:51:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 12:51:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <d4WeSYdxBsFQG_bsWZgsyGDKPbRL5ks8pTVVkck5foc=.5f39ab1e-bbab-483c-8b19-568c6e5a80e4@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Every time I rerun the tests, some new testcase fails on timeouts. Even worse is that I get quite a few /totally unrelated/ test failures every time because I am running 8 tiers.  I could probably change the timeout factor to 0.6 to weed out some more tests faster, but I can not use a timeout factor of 0.5 or less because of CODETOOLS-7903937.

Every 0.1 percent corresponds to 12 seconds. So in absolute measurements I have a margin of 36 seconds now if I would go to a timeout factor of 1. I am also a bit afraid of having too big of a margin --- it will force me to convert possible huge amount of new test cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866421573

From duke at openjdk.org  Fri May  9 12:53:09 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 9 May 2025 12:53:09 GMT
Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates
 too many frames on Linux [v5]
In-Reply-To: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com>
References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com>
Message-ID: <a3RFSa3i3uqgNo4K_XQdwd1Y6QU9eXmuBmctxWGHJZw=.66c6be15-0d7c-47ec-b3e1-db7a00b5b562@github.com>

> Fixes issue in which the test fails when run on multi-screen machine.
> 
> Tested on Ubuntu 24.04, MacOS 15 and Windows 11
> 
> JTREG
> 
> runner starting test: java/awt/Frame/MultiScreenTest.java
> runner finished test: java/awt/Frame/MultiScreenTest.java
> Passed. Execution successful

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

 - Merge branch 'openjdk:master' into jdk-8352149
 - 8352149: test/jdk/java/awt/Frame/MultiScreenTest.java fails in MacOS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24752/files
  - new: https://git.openjdk.org/jdk/pull/24752/files/d4f1d3bb..5657f884

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

  Stats: 27973 lines in 1022 files changed: 17071 ins; 6627 del; 4275 mod
  Patch: https://git.openjdk.org/jdk/pull/24752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24752/head:pull/24752

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

From duke at openjdk.org  Fri May  9 13:05:40 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 9 May 2025 13:05:40 GMT
Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates
 too many frames on Linux [v6]
In-Reply-To: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com>
References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com>
Message-ID: <NmZrzADfGzwZQAlsWdQAh4_ksyqHhZiRAQn95l_WBCc=.2e8e82ef-fb04-4d1c-a32e-98a8f8cec391@github.com>

> Fixes issue in which the test fails when run on multi-screen machine.
> 
> Tested on Ubuntu 24.04, MacOS 15 and Windows 11
> 
> JTREG
> 
> runner starting test: java/awt/Frame/MultiScreenTest.java
> runner finished test: java/awt/Frame/MultiScreenTest.java
> Passed. Execution successful

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

  Adds Override for overriden methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24752/files
  - new: https://git.openjdk.org/jdk/pull/24752/files/5657f884..5ec8be63

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

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

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

From lkorinth at openjdk.org  Fri May  9 13:06:01 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 13:06:01 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <zfwQsPX7kHwfbD2VUx3dhQwyy1VjAsb-yITfpShYhLM=.2c91dacc-78e2-4393-a7c5-b196fb5be962@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Changing the timeout factor might be preferable to do after the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866463008

From duke at openjdk.org  Fri May  9 13:08:53 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 9 May 2025 13:08:53 GMT
Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates
 too many frames on Linux [v6]
In-Reply-To: <NmZrzADfGzwZQAlsWdQAh4_ksyqHhZiRAQn95l_WBCc=.2e8e82ef-fb04-4d1c-a32e-98a8f8cec391@github.com>
References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com>
 <NmZrzADfGzwZQAlsWdQAh4_ksyqHhZiRAQn95l_WBCc=.2e8e82ef-fb04-4d1c-a32e-98a8f8cec391@github.com>
Message-ID: <x-ZP_wNFkkJgGM8v_0jMiBX1egj0F0PJK66PcufD8hc=.5ded7664-dab4-4025-b2a9-ee9d00a61dda@github.com>

On Fri, 9 May 2025 13:05:40 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Fixes issue in which the test fails when run on multi-screen machine.
>> 
>> Tested on Ubuntu 24.04, MacOS 15 and Windows 11
>> 
>> JTREG
>> 
>> runner starting test: java/awt/Frame/MultiScreenTest.java
>> runner finished test: java/awt/Frame/MultiScreenTest.java
>> Passed. Execution successful
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adds Override for overriden methods

Updates to  this PR:
1- Title changed to be meaningful for this PR
2- Override annotation added
3- Space inserted before comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/24752#issuecomment-2866468683

From ihse at openjdk.org  Fri May  9 14:20:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 14:20:31 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
Message-ID: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>

A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.

While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.

I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

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

Commit messages:
 - 8356644: Update encoding declaration to UTF-8

Changes: https://git.openjdk.org/jdk/pull/25148/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25148&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356644
  Stats: 794 lines in 53 files changed: 2 ins; 9 del; 783 mod
  Patch: https://git.openjdk.org/jdk/pull/25148.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25148/head:pull/25148

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

From dfuchs at openjdk.org  Fri May  9 16:01:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 16:01:51 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <xYLb16pp1-tzU59PSQJwkT13-nO_nm6t51FoewRQkEc=.943e14e7-46c2-4620-83c9-b5557b7480ae@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

Changes to net-properties.html LGTM

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

PR Review: https://git.openjdk.org/jdk/pull/25148#pullrequestreview-2828873053

From aivanov at openjdk.org  Fri May  9 16:12:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 9 May 2025 16:12:59 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v3]
In-Reply-To: <yE60ih_uYBbmAe48BUySKVRRVyqCfZ40nW_uDxwUJ_c=.700bebb7-22e5-4c7d-b3ec-9d026a3ab25e@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yE60ih_uYBbmAe48BUySKVRRVyqCfZ40nW_uDxwUJ_c=.700bebb7-22e5-4c7d-b3ec-9d026a3ab25e@github.com>
Message-ID: <aHNIdT9_RuMUjzjUMiDVrJk6L1xkj-5ob9p-o8N_PWo=.1ba6e51f-d948-4f33-930c-4b17c16bb215@github.com>

On Wed, 7 May 2025 20:47:16 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

Looks good to me except for a few nits.

I guess you should also update the copyright years in modified files.

src/java.desktop/share/classes/com/sun/media/sound/DataPusher.java line 97:

> 95:     public boolean isPlaying() {
> 96:         return threadState == STATE_PLAYING;
> 97:     }

I still think the `isPlaying` should be declared `synchronized`.

You resolved my previous comment but nothing's changed in the code.

src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 119:

> 117:             clip.init(url.openStream());
> 118:         } catch (final Exception ignored) {
> 119:             // Playing the clip will be a no-op if an exception occurred in inititialization.

Suggestion:

            // Playing the clip will be a no-op if an exception occurred in initialization.

src/java.desktop/share/classes/javax/sound/SoundClip.java line 52:

> 50:      * Creates a {@code SoundClip} instance which will play a clip from the supplied file.
> 51:      *
> 52:      * If the file does not contain recognizable and supported sound data, or

If the two sentences are intended to be in one paragraph, I strongly suggest removing the blank line between them. Otherwise, the blank line in the javadoc source hints that the second sentence should be in its own paragraph.

src/java.desktop/share/classes/javax/sound/package-info.java line 32:

> 30:  * Capture, processing and playback of sampled audio data is under {@link javax.sound.sampled}.
> 31:  * <p>
> 32:  * Sequencing, and synthesis of MIDI (Musical Instrument Digital Interface) data is under {@link javax.sound.midi}.

The description fits into an unordered list.

Suggestion:

 * The API is divided into sub-packages:
 * <ul>
 *   <li>Capture, processing and playback of sampled audio data is under {@link javax.sound.sampled}.
 *   <li>Sequencing, and synthesis of MIDI (Musical Instrument Digital Interface) data is under {@link javax.sound.midi}.
 * </ul>


The resulting text could be clearer and easier to skim quickly:
> The API is divided into sub-packages:
> * Capture, processing and playback of sampled audio data is under `javax. sound. sampled`.
> * Sequencing, and synthesis of MIDI (Musical Instrument Digital Interface) data is under `javax. sound. midi`.

test/jdk/javax/sound/SoundClip/SoundClipTest.java line 74:

> 72:                 playing = false;
> 73:                 break;
> 74:             }

Suggestion:

            if (clip.isPlaying()) {
                playing = false;
            }

Since you removed the `break` statement from the loop above, this one needs to go too for consistency.

test/jdk/javax/sound/SoundClip/SoundClipTest.java line 91:

> 89:      * on the system.
> 90:      */
> 91:     public static boolean isSoundcardInstalled() {

Suggestion:

    /**
     * Returns true if at least one soundcard is correctly installed
     * on the system.
     */
    public static boolean isSoundcardInstalled() {

The start of the comment is misaligned.

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24991#pullrequestreview-2828804099
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2081937814
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2081976115
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2081955900
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2081966734
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2081992607
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2081993946

From aivanov at openjdk.org  Fri May  9 16:13:00 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 9 May 2025 16:13:00 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v2]
In-Reply-To: <fQGD1rAXdgazqR4bP-9ELUMSueIotIqduwta0_tsoeI=.610e7f43-1986-42f6-9bf8-a9d2d1864d6b@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <Xl1oVhRGDHJX-j5VoyIsGee1JfgbukuqGIgnpb6lR9Y=.a17d8c8a-d95b-4643-afbb-a99ff5fd3b94@github.com>
 <grGdOEa0QRz4vhBps8hGG5ZvMX-66Dud9ZCSbpQby5k=.770e090f-87b2-416a-a5d5-b61c556f81d9@github.com>
 <fQGD1rAXdgazqR4bP-9ELUMSueIotIqduwta0_tsoeI=.610e7f43-1986-42f6-9bf8-a9d2d1864d6b@github.com>
Message-ID: <_Euttb5yXM4TRolLb5TBTo47_uyfJaYRWxG29Y81uTM=.b9fae9ac-f094-448d-9c7a-e885c2348d7f@github.com>

On Wed, 7 May 2025 19:28:46 GMT, Phil Race <prr at openjdk.org> wrote:

> The implementations that accept a URLConnection, a URL and an InputStream all do the same.

Yes, but these methods do not declare any exceptions to be thrown.

The new method declares `IOException` can be thrown, therefore we can let an `IOException` escape.

>> src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 113:
>> 
>>> 111:             clip.init(uc.getInputStream());
>>> 112:         } catch (final Exception ignored) {
>>> 113:             // Playing the clip will be a no-op if an exception occured in inititialization.
>> 
>> Suggestion:
>> 
>>             // Playing the clip will be a no-op if an exception occurred in initialization.
>
> As I wrote previously I am not going fixing typos in methods I didn't touch and actually expect to remove when the Applet API is removed.

Yes, you wrote but you had updated the comments in both `create(URLConnection)` and `create(URL)`, and both comments contain typos.

I wouldn't have noticed if these hadn't been included in the diff.

Fixing these typos only takes accepting the suggestions on GitHub. After you accept, if at all, use `git pull origin soundclip_api` in your local repo to get the changes before adding changes to your local branch.

>> test/jdk/javax/sound/SoundClip/SoundClipTest.java line 43:
>> 
>>> 41:         if (!isSoundcardInstalled()) {
>>> 42:             return;
>>> 43:         }
>> 
>> It should throw `jtreg.SkippedException` instead of pretending the test passes.
>
> Well perhaps, but this is what every other similar jtreg sound test does.

Maybe `jtreg.SkippedException` didn't exist when the tests were written.

Tests that throw `jtreg.SkippedException` were considered *passed*, but not any more.

I don't insist, though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2081947336
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2081974458
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2081990095

From honkar at openjdk.org  Fri May  9 16:17:02 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 9 May 2025 16:17:02 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v2]
In-Reply-To: <1iwy1ZiFNN_E6ykAkMS2AG8upZu2MpWp_DZAMGEThJs=.d25c503f-f4dc-4486-8a7d-87b26594664d@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <1iwy1ZiFNN_E6ykAkMS2AG8upZu2MpWp_DZAMGEThJs=.d25c503f-f4dc-4486-8a7d-87b26594664d@github.com>
Message-ID: <jr8lCK5Iep7zO-SiXezCzd20WXHV2UKFkJ3B52idZLs=.d892533e-0c15-44f4-b04e-fdd8e77c90ea@github.com>

On Wed, 7 May 2025 22:23:02 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
>> 
>> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
>> 
>> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
>> 
>> The new test class passes on Linux, Windows and macOS.
>
> Daniel Gredler 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:
> 
>  - Merge branch 'master' into ignored-whitespace
>  - Make Graphics2D.drawString ignore tabs and newlines on macOS
>  - Add actual bug ID
>  - Add ignored whitespace test

CI Testing looks good. Didn't observe any regressions in the couple of manual tests that I ran with this fix. LGTM

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23665#pullrequestreview-2828903562

From aivanov at openjdk.org  Fri May  9 16:38:01 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 9 May 2025 16:38:01 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v2]
In-Reply-To: <1iwy1ZiFNN_E6ykAkMS2AG8upZu2MpWp_DZAMGEThJs=.d25c503f-f4dc-4486-8a7d-87b26594664d@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <1iwy1ZiFNN_E6ykAkMS2AG8upZu2MpWp_DZAMGEThJs=.d25c503f-f4dc-4486-8a7d-87b26594664d@github.com>
Message-ID: <8dLb9b2g1ue8HL8IrTlvat5rX6JqMMjHsCxMbn-ANdw=.7845d47d-2d6b-4590-8e21-314bc6d73e86@github.com>

On Wed, 7 May 2025 22:23:02 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
>> 
>> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
>> 
>> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
>> 
>> The new test class passes on Linux, Windows and macOS.
>
> Daniel Gredler 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:
> 
>  - Merge branch 'master' into ignored-whitespace
>  - Make Graphics2D.drawString ignore tabs and newlines on macOS
>  - Add actual bug ID
>  - Add ignored whitespace test

Looks good to me, except for formatting suggestions.

test/jdk/java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java line 24:

> 22:  */
> 23: 
> 24: /**

Suggestion:

/*

It shouldn't use a javadoc comment syntax.

test/jdk/java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java line 46:

> 44:     public static void main(String[] args) throws Exception {
> 45: 
> 46:         BufferedImage image = new BufferedImage(600, 600, BufferedImage.TYPE_BYTE_BINARY);

Suggestion:

    public static void main(String[] args) throws Exception {
        BufferedImage image = new BufferedImage(600, 600, BufferedImage.TYPE_BYTE_BINARY);

Just two methods start with a (redundant) blank line.

test/jdk/java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java line 80:

> 78:     private static void test(BufferedImage image, Graphics2D g2d, Font font, String reference, String text) {
> 79: 
> 80:         g2d.setFont(font);

Suggestion:

    private static void test(BufferedImage image, Graphics2D g2d, Font font, String reference, String text) {
        g2d.setFont(font);

test/jdk/java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java line 124:

> 122:     private static void assertEqual(Rectangle r1, Rectangle r2, String text) {
> 123:         if (!r1.equals(r2)) {
> 124:             String escaped = text.replace("\r", "\\r").replace("\n", "\\n").replace("\t", "\\t");

I would format this way, so that each `replace` stands out in the chain of calls.
Suggestion:

            String escaped = text.replace("\r", "\\r")
                                 .replace("\n", "\\n")
                                 .replace("\t", "\\t");

test/jdk/java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java line 159:

> 157:         int height = image.getHeight();
> 158:         int[] rowPixels = new int[width];
> 159:         for (int y = 0; y < height; y++) {

Suggestion:

        int height = image.getHeight();

        int[] rowPixels = new int[width];
        for (int y = 0; y < height; y++) {

I suggest having a blank line here to introduce a new logical ?block? of code which iterates over the pixels in the image.

test/jdk/java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java line 179:

> 177:             }
> 178:         }
> 179:         if (minX != Integer.MAX_VALUE) {

Suggestion:

        }

        if (minX != Integer.MAX_VALUE) {

A blank line here breaks a long method into sections.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23665#pullrequestreview-2828951322
PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2082035028
PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2082034595
PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2082033475
PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2082045776
PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2082038800
PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2082036239

From serb at openjdk.org  Fri May  9 16:38:06 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 9 May 2025 16:38:06 GMT
Subject: RFR: 8356053: Test java/awt/Toolkit/Headless/HeadlessToolkit.java
 fails by timeout [v2]
In-Reply-To: <rSxJ8yhJauBlv1dbHab2d61J46SjG7-54OvIaBtCteU=.354eaf8c-8257-4147-b45b-c7045755424a@github.com>
References: <rSxJ8yhJauBlv1dbHab2d61J46SjG7-54OvIaBtCteU=.354eaf8c-8257-4147-b45b-c7045755424a@github.com>
Message-ID: <ZXQMGYlSyuBBLdML2h2EBUnJH44hPIoGRfWkE1R6k20=.fd9b0b35-78db-4c61-9092-657ca1d8b4dd@github.com>

> The `java/awt/Toolkit/Headless/HeadlessToolkit.java` test covers some functionality of various methods in the `HeadlessToolkit` class, specifically whether these methods throw a `HeadlessException` or not. The image-related methods do not require access to a remote server via a URL; they can be tested using a URL pointing to a local file. This ensures that the test does not depend on `openjdk.org`.

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

 - Merge branch 'openjdk:master' into JDK-8356053
 - 8356053: Test java/awt/Toolkit/Headless/HeadlessToolkit.java fails by timeout

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25045/files
  - new: https://git.openjdk.org/jdk/pull/25045/files/c82bc634..fa2b3f36

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

  Stats: 16619 lines in 559 files changed: 9274 ins; 4478 del; 2867 mod
  Patch: https://git.openjdk.org/jdk/pull/25045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25045/head:pull/25045

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

From prr at openjdk.org  Fri May  9 17:44:55 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 17:44:55 GMT
Subject: RFR: 8355790: Enhance code consistency: java.desktop/unix:sun.awt
In-Reply-To: <7s8jC8r-uAS3k0NsaKJyhZMzhHVCOFbb-ZStbeBv9Pw=.b78af72d-c17f-4c57-b620-6a630a2aef80@github.com>
References: <7s8jC8r-uAS3k0NsaKJyhZMzhHVCOFbb-ZStbeBv9Pw=.b78af72d-c17f-4c57-b620-6a630a2aef80@github.com>
Message-ID: <oCBN7whWWFK4sDCURqDxrivBv6wUx6ovQfTvI7i0Tdk=.02f9f400-3748-4681-aa26-f812776f7c28@github.com>

On Tue, 29 Apr 2025 00:03:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency.
> 
> To make the code review process easier I have made the following changes:
> 
> 1. I chose `java.desktop/unix:sun.awt` as the starting package because it contains a relatively small number of classes
> 2. The public API was not affected so there is no need to worry about a CSR
> 
> Note: I will submit additional patches in this area later because:
> 
> 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797))
> 2. I skipped adding `@Override` for anonymous classes
> 
> Any feedback or suggestions are welcome!
> 
> Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/24941.diff) to a simple diff file, it might be more convenient for reviewing the changes.
> 
> To download the diff file and filter only the modified lines you can use the following script:
> 
> 
> curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/24941.diff -o d.txt && grep -E '^+|^-' d.txt
> 
> 
> The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected by these changes. It would be good to verify this by mach5 to ensure everything works as expected.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24941#pullrequestreview-2829227399

From serb at openjdk.org  Fri May  9 17:53:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 9 May 2025 17:53:57 GMT
Subject: Integrated: 8356053: Test
 java/awt/Toolkit/Headless/HeadlessToolkit.java fails by timeout
In-Reply-To: <rSxJ8yhJauBlv1dbHab2d61J46SjG7-54OvIaBtCteU=.354eaf8c-8257-4147-b45b-c7045755424a@github.com>
References: <rSxJ8yhJauBlv1dbHab2d61J46SjG7-54OvIaBtCteU=.354eaf8c-8257-4147-b45b-c7045755424a@github.com>
Message-ID: <NflsQax6kaGFAOLAw2dHaYtkJuBK_JEEEw0ph--f4Rg=.1c9ebd1d-903f-497f-9029-2a73797d039b@github.com>

On Mon, 5 May 2025 17:44:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The `java/awt/Toolkit/Headless/HeadlessToolkit.java` test covers some functionality of various methods in the `HeadlessToolkit` class, specifically whether these methods throw a `HeadlessException` or not. The image-related methods do not require access to a remote server via a URL; they can be tested using a URL pointing to a local file. This ensures that the test does not depend on `openjdk.org`.

This pull request has now been integrated.

Changeset: 375f3dc9
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/375f3dc9ed0f1704e726d0d704420c38a0a5513c
Stats:     26 lines in 1 file changed: 15 ins; 4 del; 7 mod

8356053: Test java/awt/Toolkit/Headless/HeadlessToolkit.java fails by timeout

Reviewed-by: prr, kizune

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

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

From prr at openjdk.org  Fri May  9 18:12:55 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 18:12:55 GMT
Subject: Integrated: 8346683: Problem list automated tests that fail on macOS15
In-Reply-To: <GEVbajFEhtK-c15NpnFo80aMbDS9gdkphLOaUfwZ4hs=.5e39d486-55c8-4ac0-ae69-f598db77c100@github.com>
References: <GEVbajFEhtK-c15NpnFo80aMbDS9gdkphLOaUfwZ4hs=.5e39d486-55c8-4ac0-ae69-f598db77c100@github.com>
Message-ID: <2NSs6PcGmhBcGpZLuAN_YJWPtw46YBNfoU4ge0zNhmo=.27e2e95c-2443-42e1-8422-8ed9db1f6744@github.com>

On Thu, 8 May 2025 21:52:21 GMT, Phil Race <prr at openjdk.org> wrote:

> We've not been doing regular automated testing on macoS 15.4 and it is well over-due.
> 
> Extensive testing (all tests run 100 times) reports 3 tests that always fail on macOS 15.4 that we should problem list to enable it.

This pull request has now been integrated.

Changeset: 30cb94d6
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/30cb94d6b04a2be764a11b38f8bacabc7aaf9388
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8346683: Problem list automated tests that fail on macOS15

Reviewed-by: dmarkov

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

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

From dnguyen at openjdk.org  Fri May  9 18:42:51 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 9 May 2025 18:42:51 GMT
Subject: RFR: 8334016: Make PrintNullString.java automatic [v2]
In-Reply-To: <aZFITvpPyrM9GFX3Yx0TNW3raU3KBmYXayqIzyGEGNo=.5d5efdd5-19d2-4af9-b371-186c0feb0793@github.com>
References: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
 <aZFITvpPyrM9GFX3Yx0TNW3raU3KBmYXayqIzyGEGNo=.5d5efdd5-19d2-4af9-b371-186c0feb0793@github.com>
Message-ID: <UfD-OzZi-OxC2i-hrJK2OKyLEvgJP8IKQIh_5p4lIkc=.517e8111-f8b7-4352-9a2b-b091f527891e@github.com>

On Wed, 23 Apr 2025 12:25:16 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> I have updated the test and made it semi-automatic (need to click "Print") . Test will initiate a print and result will be generated automatic. 
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made test fully automatic

Looks good on my end when testing on MacOS 15.4.1.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24501#pullrequestreview-2829382896

From aivanov at openjdk.org  Fri May  9 19:11:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 9 May 2025 19:11:56 GMT
Subject: RFR: 8334016: Make PrintNullString.java automatic [v2]
In-Reply-To: <aZFITvpPyrM9GFX3Yx0TNW3raU3KBmYXayqIzyGEGNo=.5d5efdd5-19d2-4af9-b371-186c0feb0793@github.com>
References: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
 <aZFITvpPyrM9GFX3Yx0TNW3raU3KBmYXayqIzyGEGNo=.5d5efdd5-19d2-4af9-b371-186c0feb0793@github.com>
Message-ID: <krgtVxLvwRNfyZwfxBh75RKSSi-hrHMZnHeZ5nYCT5I=.3a495fe5-4848-47db-b5e0-33df6e47254d@github.com>

On Wed, 23 Apr 2025 12:25:16 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> I have updated the test and made it semi-automatic (need to click "Print") . Test will initiate a print and result will be generated automatic. 
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made test fully automatic

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/print/PrinterJob/PrintNullString.java line 33:

> 31: import java.awt.print.PrinterJob;
> 32: import java.io.File;
> 33: import java.lang.Override;

Suggestion:

import java.io.File;


No need to import classes from `java.lang` package.

test/jdk/java/awt/print/PrinterJob/PrintNullString.java line 48:

> 46:  * @run main PrintNullString
> 47:  */
> 48: public class PrintNullString extends Frame {

You don't display UI any more, no need to extend `Frame`.

test/jdk/java/awt/print/PrinterJob/PrintNullString.java line 63:

> 61:     }
> 62: 
> 63:     private static class TextCanvas extends Panel implements Printable {

Suggestion:

    private static class PrintText implements Printable {

`Panel` isn't needed any more, so simple class would do.

Better yet, make the test class `PrintNullString` implement `Printable` and embed everything from `TextCanvas` directly to `PrintNullString`.

test/jdk/java/awt/print/PrinterJob/PrintNullString.java line 84:

> 82: 
> 83:         private void paint(Graphics2D g2d) {
> 84:             // API 1: null & empty drawString(String, int, int);

Now this `paint` method is redundant, you can copy its body directly into `print` above.

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

PR Review: https://git.openjdk.org/jdk/pull/24501#pullrequestreview-2829420241
PR Review Comment: https://git.openjdk.org/jdk/pull/24501#discussion_r2082350935
PR Review Comment: https://git.openjdk.org/jdk/pull/24501#discussion_r2082356860
PR Review Comment: https://git.openjdk.org/jdk/pull/24501#discussion_r2082359813
PR Review Comment: https://git.openjdk.org/jdk/pull/24501#discussion_r2082361378

From prr at openjdk.org  Fri May  9 19:24:53 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 19:24:53 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <tWgLVluDO0fcZ3e9N1V1GU6rmEcz-tyTVkNuJdr06Pw=.749ad3d3-b55a-486b-8d74-40091899e657@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > test/jdk/java/awt/font/NumericShaper/MTTest.java
> > ```
> > * * @run main/timeout=300/othervm MTTest
> > 
> > 
> > * * @run main/timeout=1200/othervm MTTest
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> > https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> > So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

I think 300 is correct for this test. Setting the timeout factor to < 1 is an interesting experiment but I don't think tests that timeout in such a case are automatic candidates to have an increased time out and this one shows why.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2867676176

From kcr at openjdk.org  Fri May  9 19:47:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 9 May 2025 19:47:55 GMT
Subject: RFR: 8332947: [macos] OpenURIHandler events not received when AWT
 is embedded in another toolkit [v7]
In-Reply-To: <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
Message-ID: <_0XbksYxQT_W0ZUwPtj083VR42UYJTotXX40L9671rE=.a239c09b-cc13-402f-888d-07b65eeda7d8@github.com>

On Wed, 7 May 2025 16:51:30 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> JavaFX Pull Request: https://github.com/openjdk/jfx/pull/1755
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

The updated fix looks good. I verified that it works as expected.

I'll approve it early next week if no issues are found during testing.

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

PR Review: https://git.openjdk.org/jdk/pull/24379#pullrequestreview-2829508181

From prr at openjdk.org  Fri May  9 20:35:46 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 20:35:46 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v4]
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <QztPYMJ5Ood6sIoYxJRdMvorCtf5Sx89ZaNY_t3x40Y=.638d8f1f-cc46-4729-b0aa-49ddf600d0bf@github.com>

> A simple API to replace java.applet.AudioClip
> 
> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200

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

  8356049

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24991/files
  - new: https://git.openjdk.org/jdk/pull/24991/files/392c13f0..52eb9e41

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

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

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

From prr at openjdk.org  Fri May  9 20:35:50 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 20:35:50 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v3]
In-Reply-To: <aHNIdT9_RuMUjzjUMiDVrJk6L1xkj-5ob9p-o8N_PWo=.1ba6e51f-d948-4f33-930c-4b17c16bb215@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yE60ih_uYBbmAe48BUySKVRRVyqCfZ40nW_uDxwUJ_c=.700bebb7-22e5-4c7d-b3ec-9d026a3ab25e@github.com>
 <aHNIdT9_RuMUjzjUMiDVrJk6L1xkj-5ob9p-o8N_PWo=.1ba6e51f-d948-4f33-930c-4b17c16bb215@github.com>
Message-ID: <q1l1rP8bT1zHIHuLHnSjKYE6RJ3vQXQwdveE3Zy65-A=.0b918bf8-7812-4537-b5e2-dc8b924d3a95@github.com>

On Fri, 9 May 2025 15:30:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356049
>
> src/java.desktop/share/classes/com/sun/media/sound/DataPusher.java line 97:
> 
>> 95:     public boolean isPlaying() {
>> 96:         return threadState == STATE_PLAYING;
>> 97:     }
> 
> I still think the `isPlaying` should be declared `synchronized`.
> 
> You resolved my previous comment but nothing's changed in the code.

I guess I can but I made javax.SoundClip.isPlaying() synchronized and other methods there are also synchronized so ...

> src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 119:
> 
>> 117:             clip.init(url.openStream());
>> 118:         } catch (final Exception ignored) {
>> 119:             // Playing the clip will be a no-op if an exception occurred in inititialization.
> 
> Suggestion:
> 
>             // Playing the clip will be a no-op if an exception occurred in initialization.

I really have no intention of updating comments I will delete soon. Its just too odd.

> src/java.desktop/share/classes/javax/sound/SoundClip.java line 52:
> 
>> 50:      * Creates a {@code SoundClip} instance which will play a clip from the supplied file.
>> 51:      *
>> 52:      * If the file does not contain recognizable and supported sound data, or
> 
> If the two sentences are intended to be in one paragraph, I strongly suggest removing the blank line between them. Otherwise, the blank line in the javadoc source hints that the second sentence should be in its own paragraph.

I misunderstood which line you meant.

> src/java.desktop/share/classes/javax/sound/package-info.java line 32:
> 
>> 30:  * Capture, processing and playback of sampled audio data is under {@link javax.sound.sampled}.
>> 31:  * <p>
>> 32:  * Sequencing, and synthesis of MIDI (Musical Instrument Digital Interface) data is under {@link javax.sound.midi}.
> 
> The description fits into an unordered list.
> 
> Suggestion:
> 
>  * The API is divided into sub-packages:
>  * <ul>
>  *   <li>Capture, processing and playback of sampled audio data is under {@link javax.sound.sampled}.
>  *   <li>Sequencing, and synthesis of MIDI (Musical Instrument Digital Interface) data is under {@link javax.sound.midi}.
>  * </ul>
> 
> 
> The resulting text could be clearer and easier to skim quickly:
>> The API is divided into sub-packages:
>> * Capture, processing and playback of sampled audio data is under `javax. sound. sampled`.
>> * Sequencing, and synthesis of MIDI (Musical Instrument Digital Interface) data is under `javax. sound. midi`.

ok

> test/jdk/javax/sound/SoundClip/SoundClipTest.java line 74:
> 
>> 72:                 playing = false;
>> 73:                 break;
>> 74:             }
> 
> Suggestion:
> 
>             if (clip.isPlaying()) {
>                 playing = false;
>             }
> 
> Since you removed the `break` statement from the loop above, this one needs to go too for consistency.

ok

> test/jdk/javax/sound/SoundClip/SoundClipTest.java line 91:
> 
>> 89:      * on the system.
>> 90:      */
>> 91:     public static boolean isSoundcardInstalled() {
> 
> Suggestion:
> 
>     /**
>      * Returns true if at least one soundcard is correctly installed
>      * on the system.
>      */
>     public static boolean isSoundcardInstalled() {
> 
> The start of the comment is misaligned.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2082432876
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2082434062
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2082438861
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2082440731
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2082441853
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2082442824

From aivanov at openjdk.org  Fri May  9 20:42:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 9 May 2025 20:42:53 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v4]
In-Reply-To: <QztPYMJ5Ood6sIoYxJRdMvorCtf5Sx89ZaNY_t3x40Y=.638d8f1f-cc46-4729-b0aa-49ddf600d0bf@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <QztPYMJ5Ood6sIoYxJRdMvorCtf5Sx89ZaNY_t3x40Y=.638d8f1f-cc46-4729-b0aa-49ddf600d0bf@github.com>
Message-ID: <n5t0xxscr2Olwrg4HasK8GKmRqKC1CNADnbjL24K9sI=.91be4039-c629-448f-b250-f3963c7fd7e8@github.com>

On Fri, 9 May 2025 20:35:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

Looks good.

You should probably bump the copyright year in the modified files.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24991#pullrequestreview-2829601695

From dgredler at openjdk.org  Fri May  9 20:48:13 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 9 May 2025 20:48:13 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v3]
In-Reply-To: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
Message-ID: <ISKYj8E70TdudmfS-hIEX4Om6pL6acaPQ_MoRCuTYpw=.943f06e8-31b1-4b66-a44b-fa5075649951@github.com>

> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
> 
> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
> 
> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
> 
> The new test class passes on Linux, Windows and macOS.

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

  Apply suggestions from code review
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23665/files
  - new: https://git.openjdk.org/jdk/pull/23665/files/db3a1ff7..2e37be11

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

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

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

From prr at openjdk.org  Fri May  9 20:53:52 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 20:53:52 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <Smz6J8OkGf1azxvWU7doxgpYm42StyU8_196s8ZNmGU=.70a7da27-72e6-40dc-81b0-c57f65d4cfdc@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25148#pullrequestreview-2829627877

From prr at openjdk.org  Fri May  9 20:54:46 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 20:54:46 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>

> A simple API to replace java.applet.AudioClip
> 
> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200

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

  8356049

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24991/files
  - new: https://git.openjdk.org/jdk/pull/24991/files/52eb9e41..a2da1a1c

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

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

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

From prr at openjdk.org  Fri May  9 21:30:55 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 21:30:55 GMT
Subject: RFR: 8352407: PixelInterleavedSampleModel with unused components
 throws RasterFormatException: Incorrect pixel stride [v2]
In-Reply-To: <PmtIVc7ZAk24h4ZNm4L0ALtuOLRBN9wOzxqjRN8p8XY=.aa53b167-39ab-4656-b59a-fbf7155bfd37@github.com>
References: <XG3ViAQRcqvh0bpwzKJ60-L_MNPcSLmY-0xdej3kZJ0=.94f48732-976b-4b08-938f-ed1c7a552b6c@github.com>
 <PmtIVc7ZAk24h4ZNm4L0ALtuOLRBN9wOzxqjRN8p8XY=.aa53b167-39ab-4656-b59a-fbf7155bfd37@github.com>
Message-ID: <YPk-LD-L5gNqqdioXADsbAv1fwGsJwGOoVR1RGdBjOM=.1da4a106-ca52-461d-9781-9866718fc2c0@github.com>

On Wed, 19 Mar 2025 13:06:56 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> 8352407: PixelInterleavedSampleModel with unused components throws RasterFormatException: Incorrect pixel stride
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The previous approach was wrong for non-pixel interleaving.
>   
>   Just align the buffer size to the pixel stride instead, should be better.

One definite issue with this fix is that it assumes pixelStride !=0
The spec (at least as far back as JDK 1.3) has allowed pixelStride == 0

So this following code is broken with this change

import java.awt.image.*;

public class Z {
  public static void main(String[] args) {
    int[] offsets = {0};
    new ComponentSampleModel(DataBufferInt.TYPE_INT, 1, 1, 0, 0, offsets);
  }
}

% java Z
Exception in thread "main" java.lang.ArithmeticException: / by zero
    at java.desktop/java.awt.image.ComponentSampleModel.getBufferSize(ComponentSampleModel.java:284)
    at java.desktop/java.awt.image.ComponentSampleModel.verify(ComponentSampleModel.java:240)
    at java.desktop/java.awt.image.ComponentSampleModel.<init>(ComponentSampleModel.java:155)
    at Z.main(Z.java:6)

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

PR Comment: https://git.openjdk.org/jdk/pull/24111#issuecomment-2867910475

From prr at openjdk.org  Fri May  9 21:43:51 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 21:43:51 GMT
Subject: RFR: 8355078: java.awt.Color.createContext() uses unnecessary
 synchronization
In-Reply-To: <0pWUD-E-stDoqVTXFmlRNJ2skEMIjeto6VFl6ydxyc0=.de5400a3-69a2-4621-a91a-45bdfbca4dd2@github.com>
References: <0pWUD-E-stDoqVTXFmlRNJ2skEMIjeto6VFl6ydxyc0=.de5400a3-69a2-4621-a91a-45bdfbca4dd2@github.com>
Message-ID: <rvnNs2f7dBV0oK7SP1MphkT0HWjaiG1WkECxBFxWfI4=.ce92b5ac-736a-4382-b0ee-9cf387ab29ec@github.com>

On Sun, 20 Apr 2025 08:15:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> At some point, java.awt.Color.createContext() was marked as synchronized to support caching of a ColorPaintContext instance. The cache was later removed, but the synchronized modifier remained. Since there is no shared mutable state anymore, the synchronization is no longer necessary and can be safely removed.
> 
> 
> Note: This code path is rarely executed because a special optimization was introduced in [SunGraphics2D.setPaint](https://github.com/openjdk/jdk/blob/c514f135ccf08c3be016a32ae8f2c055fb941857/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1003). As a result, unless a custom wrapper around the Color class is used, the Color.createContext() method is typically bypassed during rendering. 
> 
> Two tests are added:
>  - ColorPaintContextBasicTest: Checks if different image types (BufferedImage and VolatileImage) produce the same results when using different ways to fill the image (setColor, setPaint, and custom Paint). This test intentionally uses a custom Paint implementation to bypass the optimization and ensure that Color.createContext() is invoked verifying its correct behavior.
> - ColorPaintContextStateTrackerTest: Checks that the raster used in ColorPaintContext.getRaster() can be properly cached in video memory and we do not need to call icr.markDirty() in ColorPaintContext.getRaster()

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24771#pullrequestreview-2829740767

From naoto at openjdk.org  Fri May  9 23:18:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 23:18:50 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <UqQ7Tm8xYaIcxM4GvA9ISQi7kDMs1WwuEvbC2kRo1CQ=.a38e9c07-04dd-4fba-a118-4afd33951c06@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25148#pullrequestreview-2829881137

From serb at openjdk.org  Sat May 10 09:46:45 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 10 May 2025 09:46:45 GMT
Subject: RFR: 8355790: Enhance code consistency: java.desktop/unix:sun.awt
 [v2]
In-Reply-To: <7s8jC8r-uAS3k0NsaKJyhZMzhHVCOFbb-ZStbeBv9Pw=.b78af72d-c17f-4c57-b620-6a630a2aef80@github.com>
References: <7s8jC8r-uAS3k0NsaKJyhZMzhHVCOFbb-ZStbeBv9Pw=.b78af72d-c17f-4c57-b620-6a630a2aef80@github.com>
Message-ID: <2B1WbBLpaR4EfVGQqIub44UC67tuEpVQ0y-ocjmezqI=.54e69d96-3080-4b78-883f-2c5091122005@github.com>

> The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency.
> 
> To make the code review process easier I have made the following changes:
> 
> 1. I chose `java.desktop/unix:sun.awt` as the starting package because it contains a relatively small number of classes
> 2. The public API was not affected so there is no need to worry about a CSR
> 
> Note: I will submit additional patches in this area later because:
> 
> 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797))
> 2. I skipped adding `@Override` for anonymous classes
> 
> Any feedback or suggestions are welcome!
> 
> Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/24941.diff) to a simple diff file, it might be more convenient for reviewing the changes.
> 
> To download the diff file and filter only the modified lines you can use the following script:
> 
> 
> curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/24941.diff -o d.txt && grep -E '^+|^-' d.txt
> 
> 
> The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected by these changes. It would be good to verify this by mach5 to ensure everything works as expected.

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 branch 'openjdk:master' into overunix
 - override in java.desktop/unix:sun.awt
 - final in java.desktop/unix:sun.awt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24941/files
  - new: https://git.openjdk.org/jdk/pull/24941/files/7c46a0b6..e4d5c3df

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

  Stats: 39454 lines in 1207 files changed: 26470 ins; 7356 del; 5628 mod
  Patch: https://git.openjdk.org/jdk/pull/24941.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24941/head:pull/24941

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

From duke at openjdk.org  Sat May 10 19:01:59 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Sat, 10 May 2025 19:01:59 GMT
Subject: RFR: 8351913: ToolkitImage renders some gifs wrong [v4]
In-Reply-To: <eu4ZrRIFX_k-U6QDF54-UHHxOrZ1hSCvfpMfv8PHPg4=.58b80c14-78e5-450f-bb6a-eaa6c19cbe9d@github.com>
References: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com>
 <eu4ZrRIFX_k-U6QDF54-UHHxOrZ1hSCvfpMfv8PHPg4=.58b80c14-78e5-450f-bb6a-eaa6c19cbe9d@github.com>
Message-ID: <trTFEkyaTQbRntTiivD2dWGy9CUPWB4ZEZLytQUmkig=.ab508207-710f-4d95-9fe0-7c74bba19d30@github.com>

On Wed, 7 May 2025 03:08:00 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> I do not have much background in LZW compression or in C, but I'm reasonably confident this resolves the problem I'm observing. It looks like the GifImageDecoder was not always correctly handling compression codes after the table reached its limit of ~4096. If anyone has suggestions for improvements I'm happy to make adjustments.
>> 
>> Luckily while debugging this: I was able to compare the flawed implementation (GifImageDecoder) with ImageIO's implementation (GIFImageReader) to help identify how the suffix/prefix tables are supposed to work.
>> 
>> ImageIO's implementation may have suffered a similar bug (maybe https://bugs.openjdk.org/browse/JDK-7131823 ?), and that appears to have been backported.
>> 
>> I have dozens of additional test cases for this problem, but unfortunately I don't have the rights to commit them to the OpenJDK repo. Feel free to email me for additional context/test cases.
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8351913: moving test package
>   
>   I have two other PRs in progress that place their tests in a dir like:
>   /jdk/test/jdk/sun/awt/image/gif/bug8351913/
>   
>   They aren't approved/merged yet, but hopefully all 3 of these new gif bugs will be merged and they'll benefit from being grouped in the same new gif directory. (And maybe more will test/directories will follow.)

I'm closing this for now; it turns out this is not ready for review yet.

[This gif](https://pixabay.com/gifs/ginger-gingerbread-man-cookies-9997/) is much improved with this PR, but frame 12 still has issues:

According to the app Preview, it should resemble:
![image](https://github.com/user-attachments/assets/23a4e1c7-9be5-4956-ae17-039200360e59)

But with this PR it currently resembles (see bottom of image):
![frame-12](https://github.com/user-attachments/assets/2b13b306-447f-4410-9a9a-38b3697c784b)

I'm 90% sure these weird artifacts are related to this ticket.

Before this PR several frames get mangled, and frame 12 resembled: 
![frame-12](https://github.com/user-attachments/assets/5dc57af8-9d47-46f0-bca6-fe235317dc2a)

(As before: if anyone feels confident in this subject matter and has any extra capacity I'd appreciate some help, but so far with enough time I've been able to make progress on these issues...)

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

PR Comment: https://git.openjdk.org/jdk/pull/24271#issuecomment-2869111725

From duke at openjdk.org  Sat May 10 19:02:00 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Sat, 10 May 2025 19:02:00 GMT
Subject: Withdrawn: 8351913: ToolkitImage renders some gifs wrong
In-Reply-To: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com>
References: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com>
Message-ID: <LJ9zawCY8yBzi89qJkdWGOO8Il7O7gL8nanLKgiAxbQ=.14d11c27-e150-4b2e-9705-5c10268eceeb@github.com>

On Thu, 27 Mar 2025 03:40:05 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> I do not have much background in LZW compression or in C, but I'm reasonably confident this resolves the problem I'm observing. It looks like the GifImageDecoder was not always correctly handling compression codes after the table reached its limit of ~4096. If anyone has suggestions for improvements I'm happy to make adjustments.
> 
> Luckily while debugging this: I was able to compare the flawed implementation (GifImageDecoder) with ImageIO's implementation (GIFImageReader) to help identify how the suffix/prefix tables are supposed to work.
> 
> ImageIO's implementation may have suffered a similar bug (maybe https://bugs.openjdk.org/browse/JDK-7131823 ?), and that appears to have been backported.
> 
> I have dozens of additional test cases for this problem, but unfortunately I don't have the rights to commit them to the OpenJDK repo. Feel free to email me for additional context/test cases.

This pull request has been closed without being integrated.

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

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

From serb at openjdk.org  Sun May 11 07:42:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 11 May 2025 07:42:56 GMT
Subject: Integrated: 8355790: Enhance code consistency:
 java.desktop/unix:sun.awt
In-Reply-To: <7s8jC8r-uAS3k0NsaKJyhZMzhHVCOFbb-ZStbeBv9Pw=.b78af72d-c17f-4c57-b620-6a630a2aef80@github.com>
References: <7s8jC8r-uAS3k0NsaKJyhZMzhHVCOFbb-ZStbeBv9Pw=.b78af72d-c17f-4c57-b620-6a630a2aef80@github.com>
Message-ID: <t2TdiJnsaXKz5MSyxN_PLWbqsNY5JD2STa4q78HFQKU=.d1e5a976-96bc-4924-8953-8c0a971e97a0@github.com>

On Tue, 29 Apr 2025 00:03:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency.
> 
> To make the code review process easier I have made the following changes:
> 
> 1. I chose `java.desktop/unix:sun.awt` as the starting package because it contains a relatively small number of classes
> 2. The public API was not affected so there is no need to worry about a CSR
> 
> Note: I will submit additional patches in this area later because:
> 
> 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797))
> 2. I skipped adding `@Override` for anonymous classes
> 
> Any feedback or suggestions are welcome!
> 
> Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/24941.diff) to a simple diff file, it might be more convenient for reviewing the changes.
> 
> To download the diff file and filter only the modified lines you can use the following script:
> 
> 
> curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/24941.diff -o d.txt && grep -E '^+|^-' d.txt
> 
> 
> The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected by these changes. It would be good to verify this by mach5 to ensure everything works as expected.

This pull request has now been integrated.

Changeset: 97d2a379
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/97d2a37927fca993537644e748c8abca58752d44
Stats:     748 lines in 105 files changed: 646 ins; 1 del; 101 mod

8355790: Enhance code consistency: java.desktop/unix:sun.awt

Reviewed-by: achung, prr

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

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

From aivanov at openjdk.org  Sun May 11 17:06:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sun, 11 May 2025 17:06:58 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
Message-ID: <JccVtlyvC-fTYHspyhNrfIWmmgJkwK8ka6jkZur6JuM=.2337a55e-6b93-4b6f-9c7d-b21044878834@github.com>

On Fri, 9 May 2025 20:54:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24991#pullrequestreview-2831451608

From aivanov at openjdk.org  Sun May 11 17:55:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sun, 11 May 2025 17:55:57 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v3]
In-Reply-To: <ISKYj8E70TdudmfS-hIEX4Om6pL6acaPQ_MoRCuTYpw=.943f06e8-31b1-4b66-a44b-fa5075649951@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <ISKYj8E70TdudmfS-hIEX4Om6pL6acaPQ_MoRCuTYpw=.943f06e8-31b1-4b66-a44b-fa5075649951@github.com>
Message-ID: <RodhOlciudHkzXjyYUnODv-RrFaNVctur-MCreaTjoo=.63d18935-0343-4f3c-a84a-3d5de2121b60@github.com>

On Fri, 9 May 2025 20:48:13 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
>> 
>> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
>> 
>> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
>> 
>> The new test class passes on Linux, Windows and macOS.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23665#pullrequestreview-2831460328

From tr at openjdk.org  Mon May 12 06:06:53 2025
From: tr at openjdk.org (Tejesh R)
Date: Mon, 12 May 2025 06:06:53 GMT
Subject: RFR: 8356175: Remove unnecessary Map.get from XWM.getInsets
In-Reply-To: <czOfOz4HkWVe7efBo1uPx8P_xk_2Pe3EmR678ZL137U=.cf0b4856-9be4-46fa-81a9-ec0a9cd46f11@github.com>
References: <czOfOz4HkWVe7efBo1uPx8P_xk_2Pe3EmR678ZL137U=.cf0b4856-9be4-46fa-81a9-ec0a9cd46f11@github.com>
Message-ID: <eX7h7fAIhCuzNVK2zzadD0HB0e82mc06vT859UnZtKI=.176b780a-25b7-4093-8435-5a09da8f8a8d@github.com>

On Sun, 27 Apr 2025 21:01:07 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Cleanup code to use Map.putIfAbsent. It's clearer and faster.

LGTM

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

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24906#pullrequestreview-2831900481

From tr at openjdk.org  Mon May 12 06:11:54 2025
From: tr at openjdk.org (Tejesh R)
Date: Mon, 12 May 2025 06:11:54 GMT
Subject: RFR: 8343739: Test
 java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java failed: Wrong
 extended key code [v4]
In-Reply-To: <0lPsNSeiz4axJaYDwGkXxjmChM7JE87jXvyjMWtxKJQ=.44de2e2e-16e0-4e95-92fd-48559fb3dfe3@github.com>
References: <ubVHDLbUmS2V0etEvYlsOVr-1H6ZQxayrQTU4bXxz-o=.075cef8e-5d34-43de-8870-09e6afa4f588@github.com>
 <0lPsNSeiz4axJaYDwGkXxjmChM7JE87jXvyjMWtxKJQ=.44de2e2e-16e0-4e95-92fd-48559fb3dfe3@github.com>
Message-ID: <CRS5_O8EqNpIhtgSKsHDI--sVR6h428f7mEmS2e1kSo=.8d278215-0ea3-4fc4-9e86-3003fbbea27d@github.com>

On Thu, 8 May 2025 20:00:40 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Test was failing on Ubuntu, looks to be a synchronous error in the test so I rewrote it to improve stability.
>
> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove author, update summary
>  - revert test, add logging

If you are updating the test with debug print, then its better to do it as a sub task of main bug and retain the main bug as open until root cause is found.

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

PR Review: https://git.openjdk.org/jdk/pull/24885#pullrequestreview-2831909300

From abhiscxk at openjdk.org  Mon May 12 07:25:34 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 12 May 2025 07:25:34 GMT
Subject: RFR: 8356752: Log mouse enter and exit events for debugging
Message-ID: <GiKCRhZEQF_gfmkPySMU0A-W-5FhBG28E8LfKW2CT74=.9ceb09db-98b6-4c3d-93c2-ab8a57fcb5f9@github.com>

Log mouse events output to analyze the failure in CI pipeline.

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

Commit messages:
 - Log mouse events

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

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

From avu at openjdk.org  Mon May 12 07:58:53 2025
From: avu at openjdk.org (Alexey Ushakov)
Date: Mon, 12 May 2025 07:58:53 GMT
Subject: RFR: 8355904: Use variadic macros for J2dTrace [v2]
In-Reply-To: <JaUF5lhA6226WIq4FYvYmzVzoQC2sNwWusOMqJ6_lNg=.176e6b14-4a34-4615-ac7c-7e4544ebfa8d@github.com>
References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
 <y2QEN4e7q0seEp3kOSqYrK5YEj4F5GxP0mlGDCc7S1s=.f77e750d-cdbc-498a-8422-37b170196c77@github.com>
 <QZLSka3oxPAlWfIavuI47nsKiPw6VBQvFtv-DSUMHWE=.b90b76c5-9974-491d-9441-b56bbde16569@github.com>
 <JaUF5lhA6226WIq4FYvYmzVzoQC2sNwWusOMqJ6_lNg=.176e6b14-4a34-4615-ac7c-7e4544ebfa8d@github.com>
Message-ID: <3ej1X8fJ5R49AG9eK0SnIl3WrIuMtk9djq3zB1uFcCM=.ec799248-68e1-4632-b55b-62a3b32a251d@github.com>

On Wed, 30 Apr 2025 06:15:33 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> src/java.desktop/share/native/libawt/java2d/Trace.h line 58:
>> 
>>> 56: #ifndef DEBUG
>>> 57: #define J2dTrace(level, ...)
>>> 58: #define J2dTraceLn(level, ...)
>> 
>> This looks fine, but maybe the string argument could be included as a parameter? Would that improve usability, like better error messages when no arguments are provided, or enhance auto-completion in the IDE?"
>
> There is a trailing comma problem when passing no extra args. I didn't figure out how to solve it without `__VA_OPT__` or compiler-specific tricks, so I moved the string into variadic part, so that it always has at least one parameter.

I think that the benefits (having an arbitrary number of arguments) outweigh the lack of a check for the string argument type. So, I'd let's put some comments here about future use of __VA_OPT__ and integrate this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084052837

From avu at openjdk.org  Mon May 12 07:58:52 2025
From: avu at openjdk.org (Alexey Ushakov)
Date: Mon, 12 May 2025 07:58:52 GMT
Subject: RFR: 8355904: Use variadic macros for J2dTrace [v2]
In-Reply-To: <y2QEN4e7q0seEp3kOSqYrK5YEj4F5GxP0mlGDCc7S1s=.f77e750d-cdbc-498a-8422-37b170196c77@github.com>
References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
 <y2QEN4e7q0seEp3kOSqYrK5YEj4F5GxP0mlGDCc7S1s=.f77e750d-cdbc-498a-8422-37b170196c77@github.com>
Message-ID: <fRqkcmjQegSCz_hdm2X5dmlkNGZg2kv4y6snI13HISQ=.62138cf8-0513-4121-b793-4717984e5975@github.com>

On Tue, 29 Apr 2025 14:04:07 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> J2dTrace macros have multiple overloads specifying number of arguments, making it less convent to change number of arguments. There were cases when existing macros were not enough and people had to add new variants with even more arguments. We could simply use variadic macros instead.
>> 
>> Also, currently those macros expand to a { code block }, which doesn't require a semicolon at the end, so it can sometimes be missed, leading to an inconsistent code style. We could expand it directly to the function, forcing user to insert a semicolon after that, in a function-like style.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! 8355904: Use variadic macros for J2dTrace

LGTM

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

Marked as reviewed by avu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24949#pullrequestreview-2832198050

From jdv at openjdk.org  Mon May 12 08:42:52 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 12 May 2025 08:42:52 GMT
Subject: RFR: 8356752: Log mouse enter and exit events for debugging
In-Reply-To: <GiKCRhZEQF_gfmkPySMU0A-W-5FhBG28E8LfKW2CT74=.9ceb09db-98b6-4c3d-93c2-ab8a57fcb5f9@github.com>
References: <GiKCRhZEQF_gfmkPySMU0A-W-5FhBG28E8LfKW2CT74=.9ceb09db-98b6-4c3d-93c2-ab8a57fcb5f9@github.com>
Message-ID: <nxzLW0tEuXMd2xU9PK9-K_8TPat7IN_g52lUE0oTH1U=.7c820988-b7a3-4c85-bcef-c5aaa703e993@github.com>

On Mon, 12 May 2025 07:20:43 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Log mouse events output to analyze the failure in CI pipeline.

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25176#pullrequestreview-2832349394

From abhiscxk at openjdk.org  Mon May 12 09:17:56 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 12 May 2025 09:17:56 GMT
Subject: Integrated: 8356752: Log mouse enter and exit events for debugging
In-Reply-To: <GiKCRhZEQF_gfmkPySMU0A-W-5FhBG28E8LfKW2CT74=.9ceb09db-98b6-4c3d-93c2-ab8a57fcb5f9@github.com>
References: <GiKCRhZEQF_gfmkPySMU0A-W-5FhBG28E8LfKW2CT74=.9ceb09db-98b6-4c3d-93c2-ab8a57fcb5f9@github.com>
Message-ID: <XtS29QuvqkWfRbYMEd8l-XMgS6EHeLtJy5fabZagknk=.616e8198-4412-4d68-8686-e690ba4148ef@github.com>

On Mon, 12 May 2025 07:20:43 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Log mouse events output to analyze the failure in CI pipeline.

This pull request has now been integrated.

Changeset: ab8c808e
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ab8c808ed8ebec4f70141ee31fbaf312fccf7fa4
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8356752: Log mouse enter and exit events for debugging

Reviewed-by: jdv, tr

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

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

From tr at openjdk.org  Mon May 12 09:17:55 2025
From: tr at openjdk.org (Tejesh R)
Date: Mon, 12 May 2025 09:17:55 GMT
Subject: RFR: 8356752: Log mouse enter and exit events for debugging
In-Reply-To: <GiKCRhZEQF_gfmkPySMU0A-W-5FhBG28E8LfKW2CT74=.9ceb09db-98b6-4c3d-93c2-ab8a57fcb5f9@github.com>
References: <GiKCRhZEQF_gfmkPySMU0A-W-5FhBG28E8LfKW2CT74=.9ceb09db-98b6-4c3d-93c2-ab8a57fcb5f9@github.com>
Message-ID: <4aHtxRh2Sgn6K7ODjwBlAAicNivbevZ2p0fU4KyGpIk=.74bbcd8d-d0bf-43c8-9b31-9ee421a45b80@github.com>

On Mon, 12 May 2025 07:20:43 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Log mouse events output to analyze the failure in CI pipeline.

Marked as reviewed by tr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25176#pullrequestreview-2832472783

From kizune at openjdk.org  Mon May 12 10:23:01 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 12 May 2025 10:23:01 GMT
Subject: RFR: 8323545: java/awt/GraphicsDevice/CheckDisplayModes.java fails
 with "exit code: 133"
Message-ID: <_YE9ifFDv0XSJfwJXoX-TkY9OLaXlD1d7NkQWxiTJsU=.5aaa2457-1dce-4d95-be85-1e78dbb46a89@github.com>

This test fails intermittently, sometimes it does not fail in half a year so i was unable to catch it myself to do any reasonable debugging. In this pull request I am adding debug output to understand at least what graphics device is connected to the test machine and which graphics mode on which device gives us problem. Next time test fails we will at least have some hint on what's going on.

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

Commit messages:
 - 8323545: java/awt/GraphicsDevice/CheckDisplayModes.java fails with "exit code: 133"
 - Merge pull request #70 from openjdk/master

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

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

From dgredler at openjdk.org  Mon May 12 11:30:58 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 12 May 2025 11:30:58 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v2]
In-Reply-To: <VSuxymIF3e4HYhjjubAmCEwT3NzUnClespbcs58IQ58=.7c1d9183-8ab9-4a26-9dcf-e2cf3677822c@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <1iwy1ZiFNN_E6ykAkMS2AG8upZu2MpWp_DZAMGEThJs=.d25c503f-f4dc-4486-8a7d-87b26594664d@github.com>
 <VSuxymIF3e4HYhjjubAmCEwT3NzUnClespbcs58IQ58=.7c1d9183-8ab9-4a26-9dcf-e2cf3677822c@github.com>
Message-ID: <LujJwlodNbXBgn9qWsbo_kzFwI3UCGAASBGCeqW3zRA=.374e0bd2-9c18-4173-9a5d-0669992e7054@github.com>

On Wed, 7 May 2025 22:46:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Daniel Gredler 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:
>> 
>>  - Merge branch 'master' into ignored-whitespace
>>  - Make Graphics2D.drawString ignore tabs and newlines on macOS
>>  - Add actual bug ID
>>  - Add ignored whitespace test
>
> I don't think
> NativeGlyphMapper - used only when we needs the Xserver to render, or
> WPathGraphics - a windows printing class
> 
> are where I'd expect to find anything that could impact the TestControls test.
> 
> But I agree with the general points
> - \t \r \n handling can be platform-specific
> - macOS printing is very different
> 
> The other PR still needs a proper look on my part
> 
> I suggest we get this PR pushed but first I'll submit a test job .. unless Harshitha already did that ?

@prrace @honkar-jdk I've incorporated a few minor formatting changes requested by Alexey. Please let me know if you have any concerns with these latest tweaks, otherwise I will go ahead and mark as ready for integration tomorrow. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2872167214

From aivanov at openjdk.org  Mon May 12 12:08:00 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 May 2025 12:08:00 GMT
Subject: RFR: 8355904: Use variadic macros for J2dTrace [v2]
In-Reply-To: <y2QEN4e7q0seEp3kOSqYrK5YEj4F5GxP0mlGDCc7S1s=.f77e750d-cdbc-498a-8422-37b170196c77@github.com>
References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
 <y2QEN4e7q0seEp3kOSqYrK5YEj4F5GxP0mlGDCc7S1s=.f77e750d-cdbc-498a-8422-37b170196c77@github.com>
Message-ID: <At29CLzUNtkzdZemFY1vvaRTYDQXO6gThNDoWvytR_Q=.57d2d207-3745-4cc6-9f1d-b2d3bbbf2d07@github.com>

On Tue, 29 Apr 2025 14:04:07 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> J2dTrace macros have multiple overloads specifying number of arguments, making it less convent to change number of arguments. There were cases when existing macros were not enough and people had to add new variants with even more arguments. We could simply use variadic macros instead.
>> 
>> Also, currently those macros expand to a { code block }, which doesn't require a semicolon at the end, so it can sometimes be missed, leading to an inconsistent code style. We could expand it directly to the function, forcing user to insert a semicolon after that, in a function-like style.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! 8355904: Use variadic macros for J2dTrace

Wrapped arguments were aligned to the opening parenthesis of the macro, thus these lines need adjusting.

Bump the copyright year in all the modified files, please.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/EncoderManager.m line 366:

> 364:       J2dTraceLn(J2D_TRACE_VERBOSE,
> 365:                   "end common encoder because of dest change: %p -> %p",
> 366:                   _destination, dest);

Suggestion:

      J2dTraceLn(J2D_TRACE_VERBOSE,
                 "end common encoder because of dest change: %p -> %p",
                 _destination, dest);

Restore aligning of the arguments on the wrapped lines.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/EncoderManager.m line 379:

> 377:       J2dTraceLn(J2D_TRACE_VERBOSE,
> 378:                   "end common encoder because toggle stencil: %d -> %d",
> 379:                   (int)_useStencil, (int)[_mtlc.clip isShape]);

Suggestion:

      J2dTraceLn(J2D_TRACE_VERBOSE,
                 "end common encoder because toggle stencil: %d -> %d",
                 (int)_useStencil, (int)[_mtlc.clip isShape]);

Restore aligning. This applies to other files.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m line 186:

> 184:     @autoreleasepool {
> 185:         J2dTraceLn(J2D_TRACE_VERBOSE, "replaceTextureRegion src (dw, dh) : [%d, %d] dest (dx1, dy1) =[%d, %d]",
> 186:                     dw, dh, dx1, dy1);

Suggestion:

        J2dTraceLn(J2D_TRACE_VERBOSE, "replaceTextureRegion src (dw, dh) : [%d, %d] dest (dx1, dy1) =[%d, %d]",
                   dw, dh, dx1, dy1);

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBufImgOps.m line 50:

> 48:     self = [super init];
> 49:     if (self) {
> 50:         J2dTraceLn(J2D_TRACE_INFO,"Created MTLRescaleOp: isNonPremult=%d", isNonPremult);

Suggestion:

        J2dTraceLn(J2D_TRACE_INFO, "Created MTLRescaleOp: isNonPremult=%d", isNonPremult);

Does it look reasonable to add a space after the first argument too?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLContext.m line 254:

> 252:     }
> 253: 
> 254:     J2dTraceLn(J2D_TRACE_VERBOSE, "MTLContext_SetSurfaces: bsrc=%p (tex=%p type=%d), bdst=%p (tex=%p type=%d)", srcOps, srcOps->pTexture, srcOps->drawableType, dstOps, dstOps->pTexture, dstOps->drawableType);

This long line is worth wrapping:
Suggestion:

    J2dTraceLn(J2D_TRACE_VERBOSE, "MTLContext_SetSurfaces: bsrc=%p (tex=%p type=%d), bdst=%p (tex=%p type=%d)",
               srcOps, srcOps->pTexture, srcOps->drawableType,
               dstOps, dstOps->pTexture, dstOps->drawableType);

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLContext.m line 360:

> 358: 
> 359: - (void)setColorPaint:(int)pixel {
> 360:     J2dTraceLn(J2D_TRACE_INFO, "MTLContext.setColorPaint: pixel=%08x [r=%d g=%d b=%d a=%d]", pixel, (pixel >> 16) & (0xFF), (pixel >> 8) & 0xFF, (pixel) & 0xFF, (pixel >> 24) & 0xFF);

Wrap the line, too?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGlyphCache.m line 295:

> 293:             J2dTraceLn(J2D_TRACE_VERBOSE,
> 294:                         "  glyph 0x%x: removing cell 0x%x from glyph's list",
> 295:                         glyph, currCellInfo);

Suggestion:

            J2dTraceLn(J2D_TRACE_VERBOSE,
                       "  glyph 0x%x: removing cell 0x%x from glyph's list",
                       glyph, currCellInfo);

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderQueue.h line 85:

> 83:     if ((value) == NULL) {                 \
> 84:         J2dTraceLn(J2D_TRACE_ERROR,        \
> 85:                     "%s is null", #value); \

Suggestion:

        J2dTraceLn(J2D_TRACE_ERROR,        \
                   "%s is null", #value);  \

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderQueue.h line 94:

> 92:     if ((value)) {                         \
> 93:         J2dTraceLn(J2D_TRACE_ERROR,        \
> 94:                     "%s is false", #value);\

Suggestion:

        J2dTraceLn(J2D_TRACE_ERROR,        \
                   "%s is false", #value); \

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceData.m line 96:

> 94:         bmtlsdo->drawableType = rtt ? MTLSD_RT_TEXTURE : MTLSD_TEXTURE;
> 95: 
> 96:         J2dTraceLn(J2D_TRACE_VERBOSE, "MTLSurfaceData_initTexture: w=%d h=%d bp=%p [tex=%p] opaque=%d rtt=%d", width, height, bmtlsdo, bmtlsdo->pTexture, isOpaque, rtt);

Wrap the line?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLVertexCache.m line 224:

> 222: 
> 223:     J2dTraceLn(J2D_TRACE_INFO, "MTLVertexCache_AddMaskQuad: %d",
> 224:                 maskCacheIndex);

Suggestion:

    J2dTraceLn(J2D_TRACE_INFO, "MTLVertexCache_AddMaskQuad: %d",
               maskCacheIndex);

src/java.desktop/share/native/common/java2d/opengl/OGLContext.c line 756:

> 754:         J2dRlsTraceLn(J2D_TRACE_INFO,
> 755:           "OGLContext_IsLCDShaderSupportAvailable: not enough tex units (%d)",
> 756:           maxTexUnits);

Suggestion:

        J2dRlsTraceLn(J2D_TRACE_INFO,
            "OGLContext_IsLCDShaderSupportAvailable: not enough tex units (%d)",
            maxTexUnits);

However, continuation lines are usually indented by 8 spaces instead of 4 spaces.

src/java.desktop/share/native/common/java2d/opengl/OGLContext.c line 986:

> 984:         J2dRlsTraceLn(J2D_TRACE_WARNING,
> 985:             "OGLContext_CreateFragmentProgram: compiler msg (%d):\n%s",
> 986:                        infoLogLength, infoLog);

Suggestion:

        J2dRlsTraceLn(J2D_TRACE_WARNING,
            "OGLContext_CreateFragmentProgram: compiler msg (%d):\n%s",
            infoLogLength, infoLog);

Aligning is weird here, I guess it's fine to amend this.

src/java.desktop/share/native/common/java2d/opengl/OGLContext.c line 1018:

> 1016:         J2dRlsTraceLn(J2D_TRACE_WARNING,
> 1017:             "OGLContext_CreateFragmentProgram: linker msg (%d):\n%s",
> 1018:                        infoLogLength, infoLog);

Suggestion:

        J2dRlsTraceLn(J2D_TRACE_WARNING,
            "OGLContext_CreateFragmentProgram: linker msg (%d):\n%s",
            infoLogLength, infoLog);

src/java.desktop/share/native/common/java2d/opengl/OGLRenderQueue.h line 118:

> 116:     if ((value) == NULL) {                 \
> 117:         J2dTraceLn(J2D_TRACE_ERROR,        \
> 118:                     "%s is null", #value); \

Suggestion:

        J2dTraceLn(J2D_TRACE_ERROR,        \
                   "%s is null", #value);  \

src/java.desktop/windows/native/libawt/java2d/d3d/D3DContext.cpp line 1380:

> 1378:             pd3dDevice->GetTransform(D3DTS_WORLD, &tx);
> 1379:             J2dTraceLn(10,
> 1380:                         "  %5f %5f %5f %5f", tx._11, tx._12, tx._13, tx._14);

I wonder why these lines use 10 as the level instead of constant. Should we update these lines to use a trace constant/define?

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24949#pullrequestreview-2832814532
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084428158
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084429615
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084433163
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084438108
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084440921
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084442259
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084442917
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084444730
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084445157
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084448036
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084450001
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084501289
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084502360
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084503017
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084507075
PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084517205

From aivanov at openjdk.org  Mon May 12 12:13:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 May 2025 12:13:52 GMT
Subject: RFR: 8355904: Use variadic macros for J2dTrace [v2]
In-Reply-To: <3ej1X8fJ5R49AG9eK0SnIl3WrIuMtk9djq3zB1uFcCM=.ec799248-68e1-4632-b55b-62a3b32a251d@github.com>
References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
 <y2QEN4e7q0seEp3kOSqYrK5YEj4F5GxP0mlGDCc7S1s=.f77e750d-cdbc-498a-8422-37b170196c77@github.com>
 <QZLSka3oxPAlWfIavuI47nsKiPw6VBQvFtv-DSUMHWE=.b90b76c5-9974-491d-9441-b56bbde16569@github.com>
 <JaUF5lhA6226WIq4FYvYmzVzoQC2sNwWusOMqJ6_lNg=.176e6b14-4a34-4615-ac7c-7e4544ebfa8d@github.com>
 <3ej1X8fJ5R49AG9eK0SnIl3WrIuMtk9djq3zB1uFcCM=.ec799248-68e1-4632-b55b-62a3b32a251d@github.com>
Message-ID: <vszRNsXFbv2K5m0td3PuOSTGVkgwZNBQb6hJW7LnInQ=.a05939ee-2f64-496c-869c-c248f55e7280@github.com>

On Mon, 12 May 2025 07:54:23 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> There is a trailing comma problem when passing no extra args. I didn't figure out how to solve it without `__VA_OPT__` or compiler-specific tricks, so I moved the string into variadic part, so that it always has at least one parameter.
>
> I think that the benefits (having an arbitrary number of arguments) outweigh the lack of a check for the string argument type. So, I'd let's put some comments here about future use of __VA_OPT__ and integrate this change.

I think we still have the same benefits, and the first argument has to be string? It wasn't enforced at the macro level, but it was suggested by the name of the argument.

https://github.com/openjdk/jdk/blob/867aee60dd12c4ea232aaf03f14a45a3d0f91851/src/java.desktop/share/native/libawt/java2d/Trace.c#L38C38-L38C44

The functions that implement traces, `J2dTraceImpl`, still require that the first argument is a string, therefore we should get a compilation error if the first parameter isn't a string.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2084536439

From aivanov at openjdk.org  Mon May 12 12:24:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 May 2025 12:24:56 GMT
Subject: RFR: 8356175: Remove unnecessary Map.get from XWM.getInsets
In-Reply-To: <czOfOz4HkWVe7efBo1uPx8P_xk_2Pe3EmR678ZL137U=.cf0b4856-9be4-46fa-81a9-ec0a9cd46f11@github.com>
References: <czOfOz4HkWVe7efBo1uPx8P_xk_2Pe3EmR678ZL137U=.cf0b4856-9be4-46fa-81a9-ec0a9cd46f11@github.com>
Message-ID: <QBJUk1-0ajSL2noigIjZwTk1fvq7G9WuQpxWcR5bZCg=.0d9ec3c8-e27d-4be8-a24f-1d8ee56ef59d@github.com>

On Sun, 27 Apr 2025 21:01:07 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Cleanup code to use Map.putIfAbsent. It's clearer and faster.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24906#pullrequestreview-2833019355

From aivanov at openjdk.org  Mon May 12 12:24:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 May 2025 12:24:57 GMT
Subject: RFR: 8356175: Remove unnecessary Map.get from XWM.getInsets
In-Reply-To: <Fa2-9OBhpE2te0wvoLPWvgSU84R7Y3GIfAwv3n1qecM=.c686629f-7c91-484b-a159-0f44f27bef85@github.com>
References: <czOfOz4HkWVe7efBo1uPx8P_xk_2Pe3EmR678ZL137U=.cf0b4856-9be4-46fa-81a9-ec0a9cd46f11@github.com>
 <Fa2-9OBhpE2te0wvoLPWvgSU84R7Y3GIfAwv3n1qecM=.c686629f-7c91-484b-a159-0f44f27bef85@github.com>
Message-ID: <lDK-56NakgH_LPzssByE7B_thAuImeZS-5kR0Pxklx0=.1b94beb6-d63b-4aaa-a35e-60b87ba224bf@github.com>

On Wed, 30 Apr 2025 06:02:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> looks fine

@mrserb You meant to select the Approve option, didn't you?

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

PR Comment: https://git.openjdk.org/jdk/pull/24906#issuecomment-2872344120

From duke at openjdk.org  Mon May 12 15:27:55 2025
From: duke at openjdk.org (lawrence.andrews)
Date: Mon, 12 May 2025 15:27:55 GMT
Subject: RFR: 8323545: java/awt/GraphicsDevice/CheckDisplayModes.java fails
 with "exit code: 133"
In-Reply-To: <_YE9ifFDv0XSJfwJXoX-TkY9OLaXlD1d7NkQWxiTJsU=.5aaa2457-1dce-4d95-be85-1e78dbb46a89@github.com>
References: <_YE9ifFDv0XSJfwJXoX-TkY9OLaXlD1d7NkQWxiTJsU=.5aaa2457-1dce-4d95-be85-1e78dbb46a89@github.com>
Message-ID: <3cNJ0sGy8OWUyuf_IAUEFaPijSnDSlbTdyyAnZlD3k8=.0f687f07-3a7f-4d4a-9386-2c572e1bface@github.com>

On Mon, 12 May 2025 10:18:13 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> This test fails intermittently, sometimes it does not fail in half a year so i was unable to catch it myself to do any reasonable debugging. In this pull request I am adding debug output to understand at least what graphics device is connected to the test machine and which graphics mode on which device gives us problem. Next time test fails we will at least have some hint on what's going on.

LGTM

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

PR Comment: https://git.openjdk.org/jdk/pull/25179#issuecomment-2873014312

From honkar at openjdk.org  Mon May 12 16:20:55 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 12 May 2025 16:20:55 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v3]
In-Reply-To: <ISKYj8E70TdudmfS-hIEX4Om6pL6acaPQ_MoRCuTYpw=.943f06e8-31b1-4b66-a44b-fa5075649951@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <ISKYj8E70TdudmfS-hIEX4Om6pL6acaPQ_MoRCuTYpw=.943f06e8-31b1-4b66-a44b-fa5075649951@github.com>
Message-ID: <BvIhghgYSvrzszWznyu5h_7siEYBWXvonTVec5IpCws=.989aece5-1c75-4c07-942c-df32cd578b77@github.com>

On Fri, 9 May 2025 20:48:13 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
>> 
>> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
>> 
>> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
>> 
>> The new test class passes on Linux, Windows and macOS.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

LGTM

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23665#pullrequestreview-2833805424

From honkar at openjdk.org  Mon May 12 16:37:54 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 12 May 2025 16:37:54 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v3]
In-Reply-To: <K80Yidg0_CV5gl8Qu7tZ1Wb103M2uErnLmem-wIQae0=.a3073cf9-d58d-4fb7-92d3-77fb8bf37aae@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <ZgTFzsooBxN-wUCWHshZzk6ntx-q73m8o9U9JkF1iFU=.d9c56bb3-90fb-4714-93fc-61e1ea6ad2ff@github.com>
 <K80Yidg0_CV5gl8Qu7tZ1Wb103M2uErnLmem-wIQae0=.a3073cf9-d58d-4fb7-92d3-77fb8bf37aae@github.com>
Message-ID: <VvO6M6bM6hJP65PB2MOsdv8kQhPxoCtmPbbfAQVxJ04=.988d9446-965b-4076-bf44-87092194200b@github.com>

On Tue, 6 May 2025 23:31:34 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java line 138:
>> 
>>> 136:         return code == 0x0009 || code == 0x000a || code == 0x000d;
>>> 137:     }
>>> 138: 
>> 
>> @prrace @gredler 
>> Following is an existing issue NOT related to the recent harfbuzz upgrade PR nor this issue fix but it is similar in nature so a separate JBS issue can be created to handle it. I wanted to discuss it before integrating the HB upgrade tomorrow.
>> 
>> There seems to be similar issue on windows and linux where the hexcode - 0x2028 (line separator) and 0x2029 (paragraph separator) are shown with a non-zero advance - `/java/awt/font/TextLayout/TestControls.java`
>> 
>> **On Windows:**
>> 
>> <img width="287" alt="image" src="https://github.com/user-attachments/assets/9eec9009-e3a5-49be-b505-619d041bfa3b" />
>> 
>> **On Linux:**
>> 
>> <img width="272" alt="image" src="https://github.com/user-attachments/assets/73a56d6d-53ec-4d6f-ad49-6fc13bdceea0" />
>> 
>> 
>> If adding these codes (0x2028, 0x2029) to platform specific src code (I believe it is NativeGlyphMapper (linux) and WPathGraphics (windows)) fixes the above issue then should we consider moving isIgnorableWhitespace() to common class - `CharToGlyphMapper` instead of macOS specific src?
>
> Yeah, I think right now `\t` `\r` `\n` handling is done separately for each platform, and I think also separately for screen display vs. printing.
> 
> As an example, this fix addresses the screen display side of things for macOS, but printing on macOS needs to be fixed separately (as can be seen when you run `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java`). I had a quick look at the corresponding macOS printing issue a few months ago and the fix wasn't obvious, especially given how that part of the code is organized (not really 1-to-1 with the other platforms).
> 
> So I think `\t` `\r` `\n` handling is repeated quite a bit, and if we wanted to handle `0x2028` and `0x2029` exactly like we do `\t` `\r` `\n` then we'd need to change multiple places right now.
> 
>> should we consider moving isIgnorableWhitespace() to common class - CharToGlyphMapper instead of macOS specific src
> 
> That sounds like it could be a good idea, but I don't have a sense of how likely it is to cause breakage elsewhere -- it'd be a matter of "do it and check for test regressions". Maybe you have a better gut feel for the likelihood of unintended side-effects?
> 
> Note these two characters (`0x2028` and `0x2029`) are not default-ignorable, though. It sounds like we just don't want to render their glyphs, if they have any (similar to `\t` `\r` `\n`, which are also not default-ignorable).
> 
> Over on PR #24412 Nikita has suggested an interesting change to `CharToGlyphMapper` and subclasses which might make this change easier, but I'd like some feedback from a reviewer or two before moving forward. The PR is complete from my POV, but we need some design direction (good as is, or needs tweaks, or need to use a different approach entirely, etc).

Created a new JBS to track the issue on windows and linux - [JDK-8356803](https://bugs.openjdk.org/browse/JDK-8356803) - Test TextLayout/TestControls fails on windows & linux: line and paragraph separator show a non-zero advance

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2085054047

From honkar at openjdk.org  Mon May 12 16:55:54 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 12 May 2025 16:55:54 GMT
Subject: RFR: 8332947: [macos] OpenURIHandler events not received when AWT
 is embedded in another toolkit [v7]
In-Reply-To: <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
Message-ID: <BucQfYotlcFooKFJHNoV_381ZOVA3G_hAxqys3PGTys=.96d8a123-d0e2-4d71-a7b1-f108ea2b2dda@github.com>

On Wed, 7 May 2025 16:51:30 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> JavaFX Pull Request: https://github.com/openjdk/jfx/pull/1755
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

@prrace @kevinrushforth @pabulaner Tested  all 4 combinations of with/without JDK + with/without JFX fix in both app modes before and after. The updated fix works as expected and no regressions observed.

Kevin's suggestion to add !isApplicationOwner check before registering embedded event listener on JDK AppDelegate limits any unwanted side-effects and the event listener is registered as required only - When FX is app owner.

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

PR Comment: https://git.openjdk.org/jdk/pull/24379#issuecomment-2873294172

From honkar at openjdk.org  Mon May 12 16:59:56 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 12 May 2025 16:59:56 GMT
Subject: RFR: 8332947: [macos] OpenURIHandler events not received when AWT
 is embedded in another toolkit [v7]
In-Reply-To: <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
Message-ID: <1iqZn5rEKpz6Q-rQYl0KZ8WFCfUCNvzcOQHmC5mPmco=.09f1d93a-73f7-45c0-9d38-ca605d736af2@github.com>

On Wed, 7 May 2025 16:51:30 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> JavaFX Pull Request: https://github.com/openjdk/jfx/pull/1755
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m line 293:

> 291: 
> 292: - (void)_handleOpenURLEvent:(NSAppleEventDescriptor *)openURLEvent withReplyEvent:(NSAppleEventDescriptor *)replyEvent {
> 293: AWT_ASSERT_APPKIT_THREAD;

@prrace `AWT_ASSERT_APPKIT_THREAD` is removed from handleOpenURLEvent and moved to _openURL(). This should be okay since we have moved the crux of the method (i.e calling java method handleOpenURI) to _openURL now ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24379#discussion_r2085090521

From kizune at openjdk.org  Mon May 12 18:02:56 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 12 May 2025 18:02:56 GMT
Subject: RFR: 8355515: Clarify the purpose of forcePass() and forceFail()
 methods
In-Reply-To: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
References: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
Message-ID: <Fw-P7sO3UgOco1VEBl0Xa_d3J8wn7qIE088fk0F9B20=.54c4d7b3-116a-41d5-a672-b0dc5b598e25@github.com>

On Wed, 7 May 2025 12:28:52 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Clarified the purpose of forcePass() and forceFail() methods and recommended usage of these methods.
> 
> forcePass() contained an incorrect sample; it's addressed by [JDK-8355441](https://bugs.openjdk.org/browse/JDK-8355441).
> 
> The description of forceFail() has been expanded, too.
> 
> 
> A new section in the description of the PassFailJFrame added to describe forcePass() and forceFail().

Looks reasonable. Using the blob version of the link to GH as a code example seems unusual but it works.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25091#pullrequestreview-2834051647

From kizune at openjdk.org  Mon May 12 18:04:57 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 12 May 2025 18:04:57 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
Message-ID: <6B5unPv7OtgfkemdfqFB87GPshqPlCXeIbpQgo6dgd0=.a95c2109-39b2-47cd-a0d8-2676f515c484@github.com>

On Fri, 9 May 2025 20:54:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

Seems to be working fine.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24991#pullrequestreview-2834056592

From aivanov at openjdk.org  Mon May 12 19:00:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 May 2025 19:00:54 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v3]
In-Reply-To: <VvO6M6bM6hJP65PB2MOsdv8kQhPxoCtmPbbfAQVxJ04=.988d9446-965b-4076-bf44-87092194200b@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <ZgTFzsooBxN-wUCWHshZzk6ntx-q73m8o9U9JkF1iFU=.d9c56bb3-90fb-4714-93fc-61e1ea6ad2ff@github.com>
 <K80Yidg0_CV5gl8Qu7tZ1Wb103M2uErnLmem-wIQae0=.a3073cf9-d58d-4fb7-92d3-77fb8bf37aae@github.com>
 <VvO6M6bM6hJP65PB2MOsdv8kQhPxoCtmPbbfAQVxJ04=.988d9446-965b-4076-bf44-87092194200b@github.com>
Message-ID: <Qpk-lugLdVIHa53UpCNn3NvIJV7xeM9DS8A_WJ0Vr2s=.cbd494ca-fd9e-42a9-bba0-777b92443d02@github.com>

On Mon, 12 May 2025 16:33:59 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Yeah, I think right now `\t` `\r` `\n` handling is done separately for each platform, and I think also separately for screen display vs. printing.
>> 
>> As an example, this fix addresses the screen display side of things for macOS, but printing on macOS needs to be fixed separately (as can be seen when you run `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java`). I had a quick look at the corresponding macOS printing issue a few months ago and the fix wasn't obvious, especially given how that part of the code is organized (not really 1-to-1 with the other platforms).
>> 
>> So I think `\t` `\r` `\n` handling is repeated quite a bit, and if we wanted to handle `0x2028` and `0x2029` exactly like we do `\t` `\r` `\n` then we'd need to change multiple places right now.
>> 
>>> should we consider moving isIgnorableWhitespace() to common class - CharToGlyphMapper instead of macOS specific src
>> 
>> That sounds like it could be a good idea, but I don't have a sense of how likely it is to cause breakage elsewhere -- it'd be a matter of "do it and check for test regressions". Maybe you have a better gut feel for the likelihood of unintended side-effects?
>> 
>> Note these two characters (`0x2028` and `0x2029`) are not default-ignorable, though. It sounds like we just don't want to render their glyphs, if they have any (similar to `\t` `\r` `\n`, which are also not default-ignorable).
>> 
>> Over on PR #24412 Nikita has suggested an interesting change to `CharToGlyphMapper` and subclasses which might make this change easier, but I'd like some feedback from a reviewer or two before moving forward. The PR is complete from my POV, but we need some design direction (good as is, or needs tweaks, or need to use a different approach entirely, etc).
>
> Created a new JBS to track the issue on windows and linux - [JDK-8356803](https://bugs.openjdk.org/browse/JDK-8356803) - Test TextLayout/TestControls fails on windows & linux: line and paragraph separator show a non-zero advance

> There seems to be similar issue on Windows and Linux where the hexcode - 0x2028 (line separator) and 0x2029 (paragraph separator) are shown with a non-zero advance - `/java/awt/font/TextLayout/TestControls.java`

Are these characters new? I can't remember there were any characters with non-zero width on Linux and Windows. I ran this test (or its previous version) on each HarfBuzz update.

No, they were these characters are part of the existing test.

I cannot reproduce this problem with 21.0.6. Nor is it reproducible with 21.0.7, the latest GA version of Java 21.

Yet I the same picture as you attached on Windows on a recent build of mainline.

If that's the case, it seems to be regression rather than an existing issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2085275529

From aivanov at openjdk.org  Mon May 12 19:36:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 May 2025 19:36:52 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v3]
In-Reply-To: <Qpk-lugLdVIHa53UpCNn3NvIJV7xeM9DS8A_WJ0Vr2s=.cbd494ca-fd9e-42a9-bba0-777b92443d02@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <ZgTFzsooBxN-wUCWHshZzk6ntx-q73m8o9U9JkF1iFU=.d9c56bb3-90fb-4714-93fc-61e1ea6ad2ff@github.com>
 <K80Yidg0_CV5gl8Qu7tZ1Wb103M2uErnLmem-wIQae0=.a3073cf9-d58d-4fb7-92d3-77fb8bf37aae@github.com>
 <VvO6M6bM6hJP65PB2MOsdv8kQhPxoCtmPbbfAQVxJ04=.988d9446-965b-4076-bf44-87092194200b@github.com>
 <Qpk-lugLdVIHa53UpCNn3NvIJV7xeM9DS8A_WJ0Vr2s=.cbd494ca-fd9e-42a9-bba0-777b92443d02@github.com>
Message-ID: <eT6I5ZBnSjZI_mZPMh0dumyTOfo686x4dwA4bNnY9ho=.f3866c5d-34f6-4bb3-8f79-85a9885bb186@github.com>

On Mon, 12 May 2025 18:58:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Created a new JBS to track the issue on windows and linux - [JDK-8356803](https://bugs.openjdk.org/browse/JDK-8356803) - Test TextLayout/TestControls fails on windows & linux: line and paragraph separator show a non-zero advance
>
>> There seems to be similar issue on Windows and Linux where the hexcode - 0x2028 (line separator) and 0x2029 (paragraph separator) are shown with a non-zero advance - `/java/awt/font/TextLayout/TestControls.java`
> 
> Are these characters new? I can't remember there were any characters with non-zero width on Linux and Windows. I ran this test (or its previous version) on each HarfBuzz update.
> 
> No, they were these characters are part of the existing test.
> 
> I cannot reproduce this problem with 21.0.6. Nor is it reproducible with 21.0.7, the latest GA version of Java 21.
> 
> Yet I the same picture as you attached on Windows on a recent build of mainline.
> 
> If that's the case, it seems to be regression rather than an existing issue.

I also submitted [JDK-8356812](https://bugs.openjdk.org/browse/JDK-8356812): *Create an automated version of TextLayout/TestControls*.

Verifying that the widths of all control characters is zero can be automated; the manual version can exist along-side to ensure all the characters are rendered as expected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2085323180

From honkar at openjdk.org  Mon May 12 19:42:55 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 12 May 2025 19:42:55 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v3]
In-Reply-To: <eT6I5ZBnSjZI_mZPMh0dumyTOfo686x4dwA4bNnY9ho=.f3866c5d-34f6-4bb3-8f79-85a9885bb186@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <ZgTFzsooBxN-wUCWHshZzk6ntx-q73m8o9U9JkF1iFU=.d9c56bb3-90fb-4714-93fc-61e1ea6ad2ff@github.com>
 <K80Yidg0_CV5gl8Qu7tZ1Wb103M2uErnLmem-wIQae0=.a3073cf9-d58d-4fb7-92d3-77fb8bf37aae@github.com>
 <VvO6M6bM6hJP65PB2MOsdv8kQhPxoCtmPbbfAQVxJ04=.988d9446-965b-4076-bf44-87092194200b@github.com>
 <Qpk-lugLdVIHa53UpCNn3NvIJV7xeM9DS8A_WJ0Vr2s=.cbd494ca-fd9e-42a9-bba0-777b92443d02@github.com>
 <eT6I5ZBnSjZI_mZPMh0dumyTOfo686x4dwA4bNnY9ho=.f3866c5d-34f6-4bb3-8f79-85a9885bb186@github.com>
Message-ID: <XgZCJ0FW37q2SPCOolpUNjqhkKs2zV88n3-LKNbEqzE=.f4cf3380-77a1-4efc-b385-824e829c91db@github.com>

On Mon, 12 May 2025 19:34:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> There seems to be similar issue on Windows and Linux where the hexcode - 0x2028 (line separator) and 0x2029 (paragraph separator) are shown with a non-zero advance - `/java/awt/font/TextLayout/TestControls.java`
>> 
>> Are these characters new? I can't remember there were any characters with non-zero width on Linux and Windows. I ran this test (or its previous version) on each HarfBuzz update.
>> 
>> No, they were these characters are part of the existing test.
>> 
>> I cannot reproduce this problem with 21.0.6. Nor is it reproducible with 21.0.7, the latest GA version of Java 21.
>> 
>> Yet I the same picture as you attached on Windows on a recent build of mainline.
>> 
>> If that's the case, it seems to be regression rather than an existing issue.
>
> I also submitted [JDK-8356812](https://bugs.openjdk.org/browse/JDK-8356812): *Create an automated version of TextLayout/TestControls*.
> 
> Verifying that the widths of all control characters is zero can be automated; the manual version can exist along-side to ensure all the characters are rendered as expected.

@aivanov-jdk Thanks for testing on older versions of JDK. I'm checking if this issue was caused by  harfbuzz upgrade or recent code changes to JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2085328760

From dgredler at openjdk.org  Mon May 12 20:41:03 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 12 May 2025 20:41:03 GMT
Subject: RFR: 8356814: LineBreakMeasurer.nextLayout() slower than necessary
 when no break needed
Message-ID: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>

`LineBreakMeasurer.nextLayout()` calls `nextOffset()` internally to calculate the layout limit. When this happens, a `GlyphVector` is created and the layout engine is invoked to shape the text. The `GlyphVector` is cached in the relevant `ExtendedTextSourceLabel` component.

`LineBreakMeasurer.nextLayout()` then calls `TextMeasurer.getLayout()` which eventually asks that same `ExtendedTextSourceLabel` component for a subset component. This triggers the creation of a fresh `ExtendedTextSourceLabel` without the cached `GlyphVector`.

However, this fresh `ExtendedTextSourceLabel` is not necessary if the subset requested perfectly matches the already-existing `ExtendedTextSourceLabel` component. This happens when the text is short enough that no line break is needed.

I think we should change `ExtendedTextSourceLabel.getSubset()` to return `this` if the requested subset is identical to the existing instance. This will allow us to use the existing cached `GlyphVector`, and the call to `LineBreakMeasurer.nextLayout()` will trigger text shaping once, rather than twice.

In local testing, the test program below ran in ~1250 ms before this optimization, and ran in ~960 ms after the change (a 23% reduction in run time).

The following three existing test classes provide good regression test coverage for this change:
- test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTrackingAuto
- test/jdk/java/awt/font/LineBreakMeasurer/TestLineBreakWithFontSub
- test/jdk/java/awt/font/LineBreakMeasurer/FRCTest


public class LineBreakMeasurerPerfTest {

    public static void main(String[] args) {

        float advance = 0;
        long start = System.currentTimeMillis();
        AttributedString string = new AttributedString("This is a test.");
        FontRenderContext frc = new FontRenderContext(new AffineTransform(), true, true);

        for (int i = 0; i < 100_000; i++) {
            LineBreakMeasurer measurer = new LineBreakMeasurer(string.getIterator(), frc);
            TextLayout layout = measurer.nextLayout(999); // large enough to not require break
            advance = Math.max(advance, layout.getAdvance());
        }

        long end = System.currentTimeMillis();
        System.out.println((end - start) + " ms elapsed (advance: " + advance + ")");
    }

}

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

Commit messages:
 - Avoid double text shaping in some scenarios

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

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

From honkar at openjdk.org  Mon May 12 20:57:57 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 12 May 2025 20:57:57 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v3]
In-Reply-To: <XgZCJ0FW37q2SPCOolpUNjqhkKs2zV88n3-LKNbEqzE=.f4cf3380-77a1-4efc-b385-824e829c91db@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <ZgTFzsooBxN-wUCWHshZzk6ntx-q73m8o9U9JkF1iFU=.d9c56bb3-90fb-4714-93fc-61e1ea6ad2ff@github.com>
 <K80Yidg0_CV5gl8Qu7tZ1Wb103M2uErnLmem-wIQae0=.a3073cf9-d58d-4fb7-92d3-77fb8bf37aae@github.com>
 <VvO6M6bM6hJP65PB2MOsdv8kQhPxoCtmPbbfAQVxJ04=.988d9446-965b-4076-bf44-87092194200b@github.com>
 <Qpk-lugLdVIHa53UpCNn3NvIJV7xeM9DS8A_WJ0Vr2s=.cbd494ca-fd9e-42a9-bba0-777b92443d02@github.com>
 <eT6I5ZBnSjZI_mZPMh0dumyTOfo686x4dwA4bNnY9ho=.f3866c5d-34f6-4bb3-8f79-85a9885bb186@github.com>
 <XgZCJ0FW37q2SPCOolpUNjqhkKs2zV88n3-LKNbEqzE=.f4cf3380-77a1-4efc-b385-824e829c91db@github.com>
Message-ID: <6HH0VKf0fffFEl0GR2Zqq6AmDFI-iNKNb34fOji2mP0=.72ba4a3a-ee47-4bef-b3af-564ebdf608d8@github.com>

On Mon, 12 May 2025 19:38:34 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> I also submitted [JDK-8356812](https://bugs.openjdk.org/browse/JDK-8356812): *Create an automated version of TextLayout/TestControls*.
>> 
>> Verifying that the widths of all control characters is zero can be automated; the manual version can exist along-side to ensure all the characters are rendered as expected.
>
> @aivanov-jdk Thanks for testing on older versions of JDK. I'm checking if this issue was caused by  harfbuzz upgrade or recent code changes to JDK.

The above issue is replicable after jdk25+b10 and was introduced by changeset related to **[JDK-8208377](https://bugs.openjdk.org/browse/JDK-8208377) - Soft hyphens render if not using TextLayout** , https://github.com/openjdk/jdk/pull/22670

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2085473996

From honkar at openjdk.org  Mon May 12 21:08:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 12 May 2025 21:08:53 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v3]
In-Reply-To: <K80Yidg0_CV5gl8Qu7tZ1Wb103M2uErnLmem-wIQae0=.a3073cf9-d58d-4fb7-92d3-77fb8bf37aae@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <ZgTFzsooBxN-wUCWHshZzk6ntx-q73m8o9U9JkF1iFU=.d9c56bb3-90fb-4714-93fc-61e1ea6ad2ff@github.com>
 <K80Yidg0_CV5gl8Qu7tZ1Wb103M2uErnLmem-wIQae0=.a3073cf9-d58d-4fb7-92d3-77fb8bf37aae@github.com>
Message-ID: <2pjU3eogoZP4bGad5TWJnPxlTpdVTOAisygH3fvTU2E=.596b6601-a379-4a69-a54d-41788c57db31@github.com>

On Tue, 6 May 2025 23:31:34 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java line 138:
>> 
>>> 136:         return code == 0x0009 || code == 0x000a || code == 0x000d;
>>> 137:     }
>>> 138: 
>> 
>> @prrace @gredler 
>> Following is an existing issue NOT related to the recent harfbuzz upgrade PR nor this issue fix but it is similar in nature so a separate JBS issue can be created to handle it. I wanted to discuss it before integrating the HB upgrade tomorrow.
>> 
>> There seems to be similar issue on windows and linux where the hexcode - 0x2028 (line separator) and 0x2029 (paragraph separator) are shown with a non-zero advance - `/java/awt/font/TextLayout/TestControls.java`
>> 
>> **On Windows:**
>> 
>> <img width="287" alt="image" src="https://github.com/user-attachments/assets/9eec9009-e3a5-49be-b505-619d041bfa3b" />
>> 
>> **On Linux:**
>> 
>> <img width="272" alt="image" src="https://github.com/user-attachments/assets/73a56d6d-53ec-4d6f-ad49-6fc13bdceea0" />
>> 
>> 
>> If adding these codes (0x2028, 0x2029) to platform specific src code (I believe it is NativeGlyphMapper (linux) and WPathGraphics (windows)) fixes the above issue then should we consider moving isIgnorableWhitespace() to common class - `CharToGlyphMapper` instead of macOS specific src?
>
> Yeah, I think right now `\t` `\r` `\n` handling is done separately for each platform, and I think also separately for screen display vs. printing.
> 
> As an example, this fix addresses the screen display side of things for macOS, but printing on macOS needs to be fixed separately (as can be seen when you run `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java`). I had a quick look at the corresponding macOS printing issue a few months ago and the fix wasn't obvious, especially given how that part of the code is organized (not really 1-to-1 with the other platforms).
> 
> So I think `\t` `\r` `\n` handling is repeated quite a bit, and if we wanted to handle `0x2028` and `0x2029` exactly like we do `\t` `\r` `\n` then we'd need to change multiple places right now.
> 
>> should we consider moving isIgnorableWhitespace() to common class - CharToGlyphMapper instead of macOS specific src
> 
> That sounds like it could be a good idea, but I don't have a sense of how likely it is to cause breakage elsewhere -- it'd be a matter of "do it and check for test regressions". Maybe you have a better gut feel for the likelihood of unintended side-effects?
> 
> Note these two characters (`0x2028` and `0x2029`) are not default-ignorable, though. It sounds like we just don't want to render their glyphs, if they have any (similar to `\t` `\r` `\n`, which are also not default-ignorable).
> 
> Over on PR #24412 Nikita has suggested an interesting change to `CharToGlyphMapper` and subclasses which might make this change easier, but I'd like some feedback from a reviewer or two before moving forward. The PR is complete from my POV, but we need some design direction (good as is, or needs tweaks, or need to use a different approach entirely, etc).

@gredler This issue _[JDK-8356803](https://bugs.openjdk.org/browse/JDK-8356803) - Test TextLayout/TestControls fails on windows & linux line and paragraph separator show a non-zero advance_, is re-assigned to you since it is a regression of [JDK-8208377](https://bugs.openjdk.org/browse/JDK-8208377)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2085495237

From prr at openjdk.org  Mon May 12 22:52:52 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 12 May 2025 22:52:52 GMT
Subject: RFR: 8356605: JRSUIControl.hashCode and JRSUIState.hashCode can
 use Long.hasCode
In-Reply-To: <nWA2jQWQE9lsM5Z2W8K7WniquRWpEBQWbtCYF2dN6iA=.7ad7b55a-6fa7-4331-bc9a-dac1d21726c8@github.com>
References: <nWA2jQWQE9lsM5Z2W8K7WniquRWpEBQWbtCYF2dN6iA=.7ad7b55a-6fa7-4331-bc9a-dac1d21726c8@github.com>
Message-ID: <2ufz9IUTazVEwoNsGiP6v5b5VTRO7ZJKtYfr0TnGWR8=.c3fe46d0-ed36-4f89-af54-ebf38995259b@github.com>

On Thu, 1 May 2025 16:16:29 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to #24959 and #24971 and #24987, apple.laf.JRSUIControl and apple.laf.JRSUIState in java.desktop can also be simplified similarly.
> 
> Replace manual bitwise operations in hashCode implementations of JRSUIControl/JRSUIState with Long::hashCode.

I'm not entirely convinced this "simplification" was worth anyone's time to understand and review. I've run tests and I don't see any failures, but it wasn't likely something we have a test for.
You'll need to fix the PR name

src/java.desktop/macosx/classes/apple/laf/JRSUIState.java line 186:

> 184:         @Override
> 185:         public int hashCode() {
> 186:             return super.hashCode() ^ Double.hashCode(value);

Since this uses Double.hashCode() not Long.hashCode() it would have been nice to have some comments on that. It took a bit of reading and following to learn that Double.hashCode() first uses Double.doubleToRawLongBits and then calls out to Long.hashCode

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24989#pullrequestreview-2834788162
PR Review Comment: https://git.openjdk.org/jdk/pull/24989#discussion_r2085638753

From swen at openjdk.org  Mon May 12 23:13:55 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 12 May 2025 23:13:55 GMT
Subject: RFR: 8356605: JRSUIControl.hashCode and JRSUIState.hashCode can
 use Long.hashCode
In-Reply-To: <2ufz9IUTazVEwoNsGiP6v5b5VTRO7ZJKtYfr0TnGWR8=.c3fe46d0-ed36-4f89-af54-ebf38995259b@github.com>
References: <nWA2jQWQE9lsM5Z2W8K7WniquRWpEBQWbtCYF2dN6iA=.7ad7b55a-6fa7-4331-bc9a-dac1d21726c8@github.com>
 <2ufz9IUTazVEwoNsGiP6v5b5VTRO7ZJKtYfr0TnGWR8=.c3fe46d0-ed36-4f89-af54-ebf38995259b@github.com>
Message-ID: <u-FR7HRy5r9uR6cBiaQSuy_YGXzywz_gFzIbu4Q0yvg=.ba76029f-8c0b-464b-b9c5-4dfdb618856c@github.com>

On Mon, 12 May 2025 22:50:34 GMT, Phil Race <prr at openjdk.org> wrote:

> I'm not entirely convinced this "simplification" was worth anyone's time to understand and review. I've run tests and I don't see any failures, but it wasn't likely something we have a test for. You'll need to fix the PR name

@pprace, thank you for reviewing this PR. I will follow your advice and will not submit similar PRs in the client module.

> src/java.desktop/macosx/classes/apple/laf/JRSUIState.java line 186:
> 
>> 184:         @Override
>> 185:         public int hashCode() {
>> 186:             return super.hashCode() ^ Double.hashCode(value);
> 
> Since this uses Double.hashCode() not Long.hashCode() it would have been nice to have some comments on that. It took a bit of reading and following to learn that Double.hashCode() first uses Double.doubleToRawLongBits and then calls out to Long.hashCode

Double.hashCode is a simple call, and there are no comments in other places where Double.hashCode is used in the JDK source code.

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

PR Comment: https://git.openjdk.org/jdk/pull/24989#issuecomment-2874418460
PR Review Comment: https://git.openjdk.org/jdk/pull/24989#discussion_r2085653994

From achung at openjdk.org  Mon May 12 23:26:09 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 12 May 2025 23:26:09 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v15]
In-Reply-To: <Idbkr_1O6El_xQd5NqPpe4wvCrnN7ILYcH7lK2nx-3w=.9a87e19e-f975-4820-8b89-c066c233301c@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <xdbhtBgikqvegs36jK5HQykyZPSHJ_hhB5xDCg_dqxw=.97a8c90f-4b87-406a-b0a7-1c73722f1e26@github.com>
 <Idbkr_1O6El_xQd5NqPpe4wvCrnN7ILYcH7lK2nx-3w=.9a87e19e-f975-4820-8b89-c066c233301c@github.com>
Message-ID: <yMyCXpIgKWuseX_cVEVZBVCuhFMcLfTXEAPK_IeCJpg=.b19ed869-cc81-4c20-a592-c96460861e76@github.com>

On Mon, 24 Feb 2025 21:12:15 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - merge
>>  - update specifications, replace default values in specifications with links to default var
>>  - update glide in test
>>  - merge
>>  - fix test with removed robot.glide using points
>>  - add code tag to specifications in Robot
>>  - fix syncdelay in ER
>>  - removing lesser used overridden methods
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8150564
>>  - update specification to public default fields, add waitforidle exceptions to specifications
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/10791477...30ca6a6b
>
> src/java.desktop/share/classes/java/awt/Robot.java line 858:
> 
>> 856:      * @since   25
>> 857:      */
>> 858:     public void glide(int x, int y) {
> 
> I don't see the `public void glide(Point dest)` and `public void glide(Point src, Point dest)` added, it may be convenient in some cases.

I've taken a look at all the tests running glide and very few of them actually used glide(Point dest) and glide(Point src, Point dest) so I decided to remove them from them from the migration

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2085671341

From achung at openjdk.org  Mon May 12 23:35:50 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 12 May 2025 23:35:50 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v16]
In-Reply-To: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
Message-ID: <RfPGJBBVFJLSFm2Ss0zqay-7rs59k8z5DscLfiOWnlE=.7cd54c23-501f-4654-80b6-6d6085be4b89@github.com>

> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).

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

  remove specified numbers in constant fields, add exception to documentation in glide

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22044/files
  - new: https://git.openjdk.org/jdk/pull/22044/files/30ca6a6b..c0cd6e73

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

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

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

From serb at openjdk.org  Mon May 12 23:59:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 12 May 2025 23:59:52 GMT
Subject: RFR: 8323545: java/awt/GraphicsDevice/CheckDisplayModes.java fails
 with "exit code: 133"
In-Reply-To: <_YE9ifFDv0XSJfwJXoX-TkY9OLaXlD1d7NkQWxiTJsU=.5aaa2457-1dce-4d95-be85-1e78dbb46a89@github.com>
References: <_YE9ifFDv0XSJfwJXoX-TkY9OLaXlD1d7NkQWxiTJsU=.5aaa2457-1dce-4d95-be85-1e78dbb46a89@github.com>
Message-ID: <ns_4dFl4STO9O3nG2q-fwP3t7KNuzNQ8onOT8VqcbVs=.351144ae-9a0d-4b23-ba85-e8dd3cb41b19@github.com>

On Mon, 12 May 2025 10:18:13 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> This test fails intermittently, sometimes it does not fail in half a year so i was unable to catch it myself to do any reasonable debugging. In this pull request I am adding debug output to understand at least what graphics device is connected to the test machine and which graphics mode on which device gives us problem. Next time test fails we will at least have some hint on what's going on.

test/jdk/java/awt/GraphicsDevice/CheckDisplayModes.java line 42:

> 40:         }
> 41: 
> 42:         for (GraphicsDevice graphicDevice : ge.getScreenDevices()) {

I remember that, at least in ogl, querying/initializing devices can invalidate the list of existing devices on the fly. It might be better to call getScreenDevices only once, this could(or maybe not) increase the chances to catch the bug."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25179#discussion_r2085702105

From serb at openjdk.org  Tue May 13 00:13:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 00:13:50 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

src/demo/share/jfc/CodePointIM/README.html line 5:

> 3: <head>
> 4:   <title>README - CodePointIM</title>
> 5:   <meta http-equiv="content-type" content="text/html; charset=utf-8">

I believe this line is equivalent to simple `<meta charset="utf-8"/>` which is widely used in java.desktop's docs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25148#discussion_r2085710719

From serb at openjdk.org  Tue May 13 00:40:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 00:40:03 GMT
Subject: RFR: 8356605: JRSUIControl.hashCode and JRSUIState.hashCode can
 use Long.hashCode
In-Reply-To: <nWA2jQWQE9lsM5Z2W8K7WniquRWpEBQWbtCYF2dN6iA=.7ad7b55a-6fa7-4331-bc9a-dac1d21726c8@github.com>
References: <nWA2jQWQE9lsM5Z2W8K7WniquRWpEBQWbtCYF2dN6iA=.7ad7b55a-6fa7-4331-bc9a-dac1d21726c8@github.com>
Message-ID: <Y6hklnFRCGRFO5MiTD_tr9I2GQTKWLGqvHBHBUUQGfk=.6c462822-eae7-448d-8487-5b0607e73af1@github.com>

On Thu, 1 May 2025 16:16:29 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to #24959 and #24971 and #24987, apple.laf.JRSUIControl and apple.laf.JRSUIState in java.desktop can also be simplified similarly.
> 
> Replace manual bitwise operations in hashCode implementations of JRSUIControl/JRSUIState with Long::hashCode.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24989#pullrequestreview-2834993165

From serb at openjdk.org  Tue May 13 00:45:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 00:45:50 GMT
Subject: RFR: 8356175: Remove unnecessary Map.get from XWM.getInsets
In-Reply-To: <czOfOz4HkWVe7efBo1uPx8P_xk_2Pe3EmR678ZL137U=.cf0b4856-9be4-46fa-81a9-ec0a9cd46f11@github.com>
References: <czOfOz4HkWVe7efBo1uPx8P_xk_2Pe3EmR678ZL137U=.cf0b4856-9be4-46fa-81a9-ec0a9cd46f11@github.com>
Message-ID: <ZcixIcGGbQi-ceJ5wZrqmkpBzTmcZfrjG1HBlw5KMXs=.4e758acb-f02f-4ceb-be52-3142bf636b00@github.com>

On Sun, 27 Apr 2025 21:01:07 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Cleanup code to use Map.putIfAbsent. It's clearer and faster.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24906#pullrequestreview-2834999263

From serb at openjdk.org  Tue May 13 00:45:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 00:45:50 GMT
Subject: RFR: 8356175: Remove unnecessary Map.get from XWM.getInsets
In-Reply-To: <Fa2-9OBhpE2te0wvoLPWvgSU84R7Y3GIfAwv3n1qecM=.c686629f-7c91-484b-a159-0f44f27bef85@github.com>
References: <czOfOz4HkWVe7efBo1uPx8P_xk_2Pe3EmR678ZL137U=.cf0b4856-9be4-46fa-81a9-ec0a9cd46f11@github.com>
 <Fa2-9OBhpE2te0wvoLPWvgSU84R7Y3GIfAwv3n1qecM=.c686629f-7c91-484b-a159-0f44f27bef85@github.com>
Message-ID: <WsboF2YYz0ImfXMQxDtr4gw6ChnZ9ohe4HDZ7DRJ7mo=.46453af2-9fd0-4d0a-864e-0dc757285d28@github.com>

On Wed, 30 Apr 2025 06:02:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Cleanup code to use Map.putIfAbsent. It's clearer and faster.
>
> looks fine

> @mrserb You meant to select the Approve option, didn't you?

At that time, it did not have an associated bug ID, so it could not be approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/24906#issuecomment-2874672251

From serb at openjdk.org  Tue May 13 00:48:59 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 00:48:59 GMT
Subject: RFR: 8343739: Test
 java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java failed: Wrong
 extended key code [v4]
In-Reply-To: <0lPsNSeiz4axJaYDwGkXxjmChM7JE87jXvyjMWtxKJQ=.44de2e2e-16e0-4e95-92fd-48559fb3dfe3@github.com>
References: <ubVHDLbUmS2V0etEvYlsOVr-1H6ZQxayrQTU4bXxz-o=.075cef8e-5d34-43de-8870-09e6afa4f588@github.com>
 <0lPsNSeiz4axJaYDwGkXxjmChM7JE87jXvyjMWtxKJQ=.44de2e2e-16e0-4e95-92fd-48559fb3dfe3@github.com>
Message-ID: <uLZb2S_dVI_P884BI6bgvKy0ww3QdpTeWRCvLk-yBmk=.9978c552-43fb-44cd-8a39-c53fd8cf59c8@github.com>

On Thu, 8 May 2025 20:00:40 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Test was failing on Ubuntu, looks to be a synchronous error in the test so I rewrote it to improve stability.
>
> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove author, update summary
>  - revert test, add logging

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24885#pullrequestreview-2835001523

From serb at openjdk.org  Tue May 13 02:06:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 02:06:54 GMT
Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates
 too many frames on Linux
In-Reply-To: <0IkXQzTfHKgD2Zn6NLHlFZs6jpVi2ub7Zz-K74wObFA=.f53a3a43-53ec-41cd-a95b-d264fef102f8@github.com>
References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com>
 <0IkXQzTfHKgD2Zn6NLHlFZs6jpVi2ub7Zz-K74wObFA=.f53a3a43-53ec-41cd-a95b-d264fef102f8@github.com>
Message-ID: <-SBD5rSWBUqG_5ToRe8BKD3uXVo9anMyso7nlishEW8=.bf332e96-18bd-4c11-849d-e26f2fbba5fd@github.com>

On Thu, 24 Apr 2025 05:23:43 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> I ran the test (**without your fix**) on Windows, Mac and Linux platform. It failed on Windows and Mac but no issues on Linux.

Why it fails on win/mac?

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

PR Comment: https://git.openjdk.org/jdk/pull/24752#issuecomment-2874809884

From serb at openjdk.org  Tue May 13 02:13:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 02:13:51 GMT
Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v2]
In-Reply-To: <HYQ237abKwF9M1jfKX3VQG_ytVIfbXo_m3OioPFbd4s=.f1ecbd3e-c630-457d-8b78-73292bbb39d4@github.com>
References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com>
 <HYQ237abKwF9M1jfKX3VQG_ytVIfbXo_m3OioPFbd4s=.f1ecbd3e-c630-457d-8b78-73292bbb39d4@github.com>
Message-ID: <IVseDGLFBp2TAQMrbsgvCgX1wBOALL0QZXwMwHxp7Hw=.d305f8ac-3a89-42c0-b626-08ae327f1cb1@github.com>

On Mon, 14 Apr 2025 17:19:19 GMT, Matthias Bl?sing <mblaesing at openjdk.org> wrote:

>> - Introduce a lock into WClipboard that protects the code between
>>   openClipboard/closeClipboard invocations.
>>   The native side does not allow to open the clipboard multiple
>>   times or share the opened clipboard between multiple threads.
>> 
>> - Remove of need to call openClipboard/closeClipboard from
>>   getClipboardFormats by using the win32 call
>>   GetUpdatedClipboardFormats
>> 
>> - Prevent a race-condition by not registering the connection
>>   between java and native side of clipboard multiple time, but
>>   just at construction time.
>
> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adress review comments: Update copyright years and fix whitespace in if condition

is it possible to create a jtreg test for this issue?

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

PR Comment: https://git.openjdk.org/jdk/pull/24614#issuecomment-2874817388

From serb at openjdk.org  Tue May 13 03:04:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 03:04:52 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
In-Reply-To: <QhZ-yOsUL-Y-EFjbyDD98pdW-EqLQk9yIIyIZF-IAh0=.a2145cd5-59fe-437f-81f6-4b468a5e8cb3@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <vEWA2CeJs9SmRb8K81xVWRMko2w6xj9Q2hIGXlYUVZM=.e7d736f9-9b2c-4a48-b366-e3801a304f9e@github.com>
 <Ahgb4B8gkI9Cjqwdoq0-Acfcga0QYbiprxAS4k3Fa7U=.c36f229f-2529-4788-8d14-86a51422e373@github.com>
 <vmyVz_91nhgMmjLla6DKOkJGD-Xp_6qajAgUKfeXLoY=.89fefd83-43c9-476c-a951-70a633f9a5e2@github.com>
 <xrKZHsl3CpNOAmppgUcqtxPK_Pb8RinLTrj11RMxGOY=.a64e2fff-04cb-4001-acbb-3c10b24d54de@github.com>
 <f6oYZ6xLi4A9CLobrR9K5ENfgEmSBqTay1kQaf7f3yY=.29f79326-48e7-4ad8-9afb-055536cdb4b2@github.com>
 <isvH5l_2W5YQ-mbpXd3XJMLyp2XP8Yohrq9cxFi84Nc=.27fc812c-b5e4-43df-b9f8-55881331097c@github.com>
 <UzRKXFgBG_WyKaEF3Hjdb3qb2ExAFmUA3UNZI42zMm0=.48021bee-2600-47bf-8c26-bfdddf320592@github.com>
 <MsGQMdJVt_rqNfkj62DVrsBWPlQrx5lsxjnR5BKzl9k=.a8bbbc62-1b60-4982-9424-6af202a6304c@github.com>
 <PfOTt7diduByRh7oViyuN-gJ-3iiD_CnGHIY8Xmni8k=.b52391fd-f576-4c01-923b-209975713596@github.com>
 <HYVRAUlbtJyV9GVAKlTWbeUNMHzV8ugjNuP
 7B4ALY48=.134d9204-f8a9-48fa-85af-982aa124469a@github.com>
 <oTB8PeOedGLLoza4ALZkxGvEdJttzGQb3_eVKwwT0eE=.9f06dd2d-7485-45eb-8cae-af3bad0aa683@github.com>
 <kG1MjZyVmybZj-A8u7ak4GBJ-h06fy5fAxIjFObj45c=.c80b7530-2747-4e56-bb7c-72bc84a612cf@github.com>
 <mwA2kTMeaSXuWYCnqXlvhMAJYUA50J58c-8BPaPiLw8=.71bc0dea-2509-491d-878a-ae27b04ec5fd@github.com>
 <QhZ-yOsUL-Y-EFjbyDD98pdW-EqLQk9yIIyIZF-IAh0=.a2145cd5-59fe-437f-81f6-4b468a5e8cb3@github.com>
Message-ID: <p019LdENzXf5VWn6bjL5itcebyP1FWZeacqqDwVERmA=.86fa1fe0-138d-4655-8046-0f7021a4f0f4@github.com>

On Thu, 8 May 2025 04:08:30 GMT, Tejesh R <tr at openjdk.org> wrote:

>> @aivanov-jdk @TejeshR13 
>> This seems stalled because there are conflicting statements
>> - Alexei : you can create a custom FIleSystemView on windows with <html> in path names.
>> - Tejesh : no you can't, or at least it doesn't work when you try to use it.
>> 
>> Can we please get that reconciled ?
>> Tejesh pls show the code you used, and Alexei please show how you would do it.
>
> I tried with this code snippet. 
> 
> import javax.swing.JFileChooser;
> import javax.swing.SwingUtilities;
> import javax.swing.UIManager;
> import javax.swing.UnsupportedLookAndFeelException;
> import javax.swing.filechooser.FileSystemView;
> import java.io.File;
> import java.util.Arrays;
> 
> public class VirtualFileChooser {
> 
>     public static void main(String[] args) throws UnsupportedLookAndFeelException, ClassNotFoundException, InstantiationException, IllegalAccessException {
>           UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");
>         //UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel");
> 
> 
>         SwingUtilities.invokeLater(() -> {
>             JFileChooser chooser = new JFileChooser(new VirtualFileSystemView());
> 
>             int result = chooser.showOpenDialog(null);
>             if (result == JFileChooser.APPROVE_OPTION) {
>                 File selectedFile = chooser.getSelectedFile();
>                 System.out.println("Selected: " + selectedFile.getAbsolutePath());
>             }
>         });
>     }
> 
>     static class VirtualFileSystemView extends FileSystemView {
> 
>         private final File[] roots;
> 
>         public VirtualFileSystemView() {
>             // Create a dummy root folder
>             String name = "<html><h1 color=#ff00ff><font face="Comic Sans MS">SWING ROCKS!!!111";
>             roots = new File[]{new File(name)};
>         }
> 
>         @Override
>         public File createNewFolder(File containingDir) {
> 
>             File folder = new File(containingDir, "New Folder");
>             folder.mkdir();
>             return folder;
>         }
> 
>         @Override
>         public File[] getRoots() {
>             return roots;
>         }
> 
>         @Override
>         public File getHomeDirectory() {
>             return roots[0];
>         }
> 
>         @Override
>         public File getDefaultDirectory() {
>             return roots[0];
>         }
> 
>         @Override
>         public File[] getFiles(File dir, boolean useFileHiding) {
>             // Simulate a virtual folder structure
>             return new File[]{
>                     new File(dir, "virtualFile1.txt"),
>                     new File(dir, "virtualFile2.txt"),
>                     new File(dir, "virtualFolder")
>             };
>         }
> 
>         @Override
>         public boolean isRoot(File file) {
>             return Arrays.asList(roots).contains(file);
>         }
> 
>         @Override
>         public Boolean isTraversable(File f) {
>             return true;
>         }
>    ...

> Exception in thread "AWT-EventQueue-0" java.nio.file.InvalidPathException: Illegal char <<> at index 0: <html><h1 color=#ff00ff><font face="Comic Sans MS">SWING ROCKS!!!111
>         at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:191)
>         at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:142)
>         at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:46)
>         at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
>         at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:203)
>         at java.base/java.nio.file.Path.of(Path.java:148)
>         at java.base/java.nio.file.Paths.get(Paths.java:69)
>         at java.desktop/sun.awt.shell.ShellFolder.getShellFolder(ShellFolder.java:260)
>         at java.desktop/javax.swing.filechooser.FileSystemView.getShellFolder(FileSystemView.java:724)
>         at java.desktop/javax.swing.filechooser.FileSystemView.getSystemIcon(FileSystemView.java:242)
>         at java.desktop/com.sun.java.swing.plaf.windows.WindowsFileChooserUI$WindowsFileView.getIcon(WindowsFileChooserUI.java:1398)
>         at java.desktop/javax.swing.JFileChooser.getIcon(JFileChooser.java:1614)


This exception looks like a bug? I think if the file was not found then null is an expected result.
For now it can be bypassed by this:


import java.io.File;
import java.lang.Override;

import javax.swing.Icon;
import javax.swing.JFileChooser;
import javax.swing.SwingUtilities;
import javax.swing.UIManager;
import javax.swing.UnsupportedLookAndFeelException;
import javax.swing.filechooser.FileSystemView;

public class VirtualFileChooser {

    public static void main(String[] args) throws UnsupportedLookAndFeelException, ClassNotFoundException, InstantiationException, IllegalAccessException {
        UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");
        //UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel");


        SwingUtilities.invokeLater(() -> {
            JFileChooser chooser = new JFileChooser(new VirtualFileSystemView());

            int result = chooser.showOpenDialog(null);
            if (result == JFileChooser.APPROVE_OPTION) {
                File selectedFile = chooser.getSelectedFile();
                System.out.println("Selected: " + selectedFile.getAbsolutePath());
            }
        });
    }

    static class VirtualFileSystemView extends FileSystemView {

        @Override
        public File createNewFolder(File containingDir) {
            return null;
        }

        @Override
        public File[] getRoots() {
            return new File[]{
                    new File("/", "<html><h1 color=#ff00ff><font face="Comic Sans MS">SWING ROCKS!!!111"),
                    new File("/", "virtualFile2.txt"),
                    new File("/", "virtualFolder")
            };
        }

        @Override
        public File getHomeDirectory() {
            return new File("/");
        }

        @Override
        public File getDefaultDirectory() {
            return new File("/");
        }

        @Override
        public File[] getFiles(File dir, boolean useFileHiding) {
            // Simulate a virtual folder structure
            return new File[]{
                    new File("/", "<html><h1 color=#ff00ff><font face="Comic Sans MS">SWING ROCKS!!!111"),
                    new File(dir, "virtualFile2.txt"),
                    new File(dir, "virtualFolder")
            };
        }

        @Override
        public Icon getSystemIcon(File f) {
            return null;
        }
    }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2085839647

From serb at openjdk.org  Tue May 13 03:08:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 03:08:52 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
In-Reply-To: <p019LdENzXf5VWn6bjL5itcebyP1FWZeacqqDwVERmA=.86fa1fe0-138d-4655-8046-0f7021a4f0f4@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <vEWA2CeJs9SmRb8K81xVWRMko2w6xj9Q2hIGXlYUVZM=.e7d736f9-9b2c-4a48-b366-e3801a304f9e@github.com>
 <Ahgb4B8gkI9Cjqwdoq0-Acfcga0QYbiprxAS4k3Fa7U=.c36f229f-2529-4788-8d14-86a51422e373@github.com>
 <vmyVz_91nhgMmjLla6DKOkJGD-Xp_6qajAgUKfeXLoY=.89fefd83-43c9-476c-a951-70a633f9a5e2@github.com>
 <xrKZHsl3CpNOAmppgUcqtxPK_Pb8RinLTrj11RMxGOY=.a64e2fff-04cb-4001-acbb-3c10b24d54de@github.com>
 <f6oYZ6xLi4A9CLobrR9K5ENfgEmSBqTay1kQaf7f3yY=.29f79326-48e7-4ad8-9afb-055536cdb4b2@github.com>
 <isvH5l_2W5YQ-mbpXd3XJMLyp2XP8Yohrq9cxFi84Nc=.27fc812c-b5e4-43df-b9f8-55881331097c@github.com>
 <UzRKXFgBG_WyKaEF3Hjdb3qb2ExAFmUA3UNZI42zMm0=.48021bee-2600-47bf-8c26-bfdddf320592@github.com>
 <MsGQMdJVt_rqNfkj62DVrsBWPlQrx5lsxjnR5BKzl9k=.a8bbbc62-1b60-4982-9424-6af202a6304c@github.com>
 <PfOTt7diduByRh7oViyuN-gJ-3iiD_CnGHIY8Xmni8k=.b52391fd-f576-4c01-923b-209975713596@github.com>
 <HYVRAUlbtJyV9GVAKlTWbeUNMHzV8ugjNuP
 7B4ALY48=.134d9204-f8a9-48fa-85af-982aa124469a@github.com>
 <oTB8PeOedGLLoza4ALZkxGvEdJttzGQb3_eVKwwT0eE=.9f06dd2d-7485-45eb-8cae-af3bad0aa683@github.com>
 <kG1MjZyVmybZj-A8u7ak4GBJ-h06fy5fAxIjFObj45c=.c80b7530-2747-4e56-bb7c-72bc84a612cf@github.com>
 <mwA2kTMeaSXuWYCnqXlvhMAJYUA50J58c-8BPaPiLw8=.71bc0dea-2509-491d-878a-ae27b04ec5fd@github.com>
 <QhZ-yOsUL-Y-EFjbyDD98pdW-EqLQk9yIIyIZF-IAh0=.a2145cd5-59fe-437f-81f6-4b468a5e8cb3@github.com>
 <p019LdENzXf5VWn6bjL5itcebyP1FWZeacqqDwVERmA=.86fa1fe0-138d-4655-8046-0f7021a4f0f4@github.com>
Message-ID: <9eWBFqqVGM6xc824gwLDzpRT6cYOORMC1bFkdzFrseA=.424e137c-e5d9-4fb9-a2b1-e5a675b8ac6b@github.com>

On Tue, 13 May 2025 03:01:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I tried with this code snippet. 
>> 
>> import javax.swing.JFileChooser;
>> import javax.swing.SwingUtilities;
>> import javax.swing.UIManager;
>> import javax.swing.UnsupportedLookAndFeelException;
>> import javax.swing.filechooser.FileSystemView;
>> import java.io.File;
>> import java.util.Arrays;
>> 
>> public class VirtualFileChooser {
>> 
>>     public static void main(String[] args) throws UnsupportedLookAndFeelException, ClassNotFoundException, InstantiationException, IllegalAccessException {
>>           UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");
>>         //UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel");
>> 
>> 
>>         SwingUtilities.invokeLater(() -> {
>>             JFileChooser chooser = new JFileChooser(new VirtualFileSystemView());
>> 
>>             int result = chooser.showOpenDialog(null);
>>             if (result == JFileChooser.APPROVE_OPTION) {
>>                 File selectedFile = chooser.getSelectedFile();
>>                 System.out.println("Selected: " + selectedFile.getAbsolutePath());
>>             }
>>         });
>>     }
>> 
>>     static class VirtualFileSystemView extends FileSystemView {
>> 
>>         private final File[] roots;
>> 
>>         public VirtualFileSystemView() {
>>             // Create a dummy root folder
>>             String name = "<html><h1 color=#ff00ff><font face="Comic Sans MS">SWING ROCKS!!!111";
>>             roots = new File[]{new File(name)};
>>         }
>> 
>>         @Override
>>         public File createNewFolder(File containingDir) {
>> 
>>             File folder = new File(containingDir, "New Folder");
>>             folder.mkdir();
>>             return folder;
>>         }
>> 
>>         @Override
>>         public File[] getRoots() {
>>             return roots;
>>         }
>> 
>>         @Override
>>         public File getHomeDirectory() {
>>             return roots[0];
>>         }
>> 
>>         @Override
>>         public File getDefaultDirectory() {
>>             return roots[0];
>>         }
>> 
>>         @Override
>>         public File[] getFiles(File dir, boolean useFileHiding) {
>>             // Simulate a virtual folder structure
>>             return new File[]{
>>                     new File(dir, "virtualFile1.txt"),
>>                     new File(dir, "virtualFile2.txt"),
>>                     new File(dir, "virtualFolder")
>>             };
>>         }
>> 
>>         @Override
>>         public boolean isRoot(File file) {
>>             return Arr...
>
>> Exception in thread "AWT-EventQueue-0" java.nio.file.InvalidPathException: Illegal char <<> at index 0: <html><h1 color=#ff00ff><font face="Comic Sans MS">SWING ROCKS!!!111
>>         at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:191)
>>         at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:142)
>>         at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:46)
>>         at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
>>         at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:203)
>>         at java.base/java.nio.file.Path.of(Path.java:148)
>>         at java.base/java.nio.file.Paths.get(Paths.java:69)
>>         at java.desktop/sun.awt.shell.ShellFolder.getShellFolder(ShellFolder.java:260)
>>         at java.desktop/javax.swing.filechooser.FileSystemView.getShellFolder(FileSystemView.java:724)
>>         at java.desktop/javax.swing.filechooser.FileSystemView.getSystemIcon(FileSystemView.java:242)
>>         at java.desktop/com.sun.java.swing.plaf.windows.WindowsFileChooserUI$WindowsFileView.getIcon(WindowsFileChooserUI.java:1398)
>>         at java.desktop/javax.swing.JFileChooser.getIcon(JFileChooser.java:1614)
> 
> 
> This exception looks like a bug? I think if the file was not found then null is an expected result.
> For now it can be bypassed by this:
> 
> 
> import java.io.File;
> import java.lang.Override;
> 
> import javax.swing.Icon;
> import javax.swing.JFileChooser;
> import javax.swing.SwingUtilities;
> import javax.swing.UIManager;
> import javax.swing.UnsupportedLookAndFeelException;
> import javax.swing.filechooser.FileSystemView;
> 
> public class VirtualFileChooser {
> 
>     public static void main(String[] args) throws UnsupportedLookAndFeelException, ClassNotFoundException, InstantiationException, IllegalAccessException {
>         UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");
>         //UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel");
> 
> 
>         SwingUtilities.invokeLater(() -> {
>             JFileChooser chooser = new JFileChooser(new VirtualFileSystemView());
> 
>             int result = chooser.showOpenDialog(null);
>             if (result == JFileChooser.APPROVE_OPTION) {
>                 File selectedFile = chooser.getSelectedFile();
>                 System.out.println("Selected: " + selectedFile.getAbsolutePath());
>             }
>         });
>     }
> 
>     static class VirtualFileSystemView extends FileSystemV...

Note that the bug occurs both in the list of roots (in the dropdown) and in the list of files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2085842106

From serb at openjdk.org  Tue May 13 03:44:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 03:44:53 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v13]
In-Reply-To: <bNRrYna0tu4wKw1EVwHGweiHDx0wRwPGS9KKPIeX5HA=.4305b22a-a2fe-4ed3-a2f2-4ef6875e757b@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
 <bNRrYna0tu4wKw1EVwHGweiHDx0wRwPGS9KKPIeX5HA=.4305b22a-a2fe-4ed3-a2f2-4ef6875e757b@github.com>
Message-ID: <CntGph5PSS5ifIZ9p2tEKs4wruI69vd5JRNkxn5GMmI=.573d97a7-1462-4800-8966-5afb9538e14a@github.com>

On Thu, 8 May 2025 20:46:48 GMT, Phil Race <prr at openjdk.org> wrote:

> Moreover, it looks like as part of the "unification" the fix dropped clamping code in Robot (!)
> 
> https://cr.openjdk.org/%7Epchelko/9/8035568/webrev.02/src/macosx/native/sun/awt/CRobot.m.udiff.html

That code executed only if the current mouse position is unknown or outside of the mainscreen, that native code was moved to the java level into the CRobot class by the patch:
https://cr.openjdk.org/~pchelko/9/8035568/webrev.02/src/macosx/classes/sun/lwawt/macosx/CRobot.java.sdiff.html

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

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2874970368

From abhiscxk at openjdk.org  Tue May 13 04:00:54 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 13 May 2025 04:00:54 GMT
Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates
 too many frames on Linux
In-Reply-To: <-SBD5rSWBUqG_5ToRe8BKD3uXVo9anMyso7nlishEW8=.bf332e96-18bd-4c11-849d-e26f2fbba5fd@github.com>
References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com>
 <0IkXQzTfHKgD2Zn6NLHlFZs6jpVi2ub7Zz-K74wObFA=.f53a3a43-53ec-41cd-a95b-d264fef102f8@github.com>
 <-SBD5rSWBUqG_5ToRe8BKD3uXVo9anMyso7nlishEW8=.bf332e96-18bd-4c11-849d-e26f2fbba5fd@github.com>
Message-ID: <pWpUV1M2SQ2EfY1K8FOt7Fdj6k9I0p8IkXuCCGXc7QY=.991aed27-503f-4c4e-8130-635a41d9fe2c@github.com>

On Tue, 13 May 2025 02:04:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I ran the test (**without your fix**) on Windows, Mac and Linux platform. It failed on Windows and Mac but no issues on Linux.
> 
> Why it fails on win/mac?

On Win/mac, graphic configuration return value is 1 and then there is no frame created as gc.length/2 evaluates to 0.

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

PR Comment: https://git.openjdk.org/jdk/pull/24752#issuecomment-2874985462

From rkannathpari at openjdk.org  Tue May 13 04:54:37 2025
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 13 May 2025 04:54:37 GMT
Subject: RFR: 8334016: Make PrintNullString.java automatic [v3]
In-Reply-To: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
References: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
Message-ID: <Rad0Nfn4m_i5hOkKRYEuZIZSS1RjBgro1yn7mR10rIg=.6caaffdc-4b71-430f-80cb-573afc922691@github.com>

> Hi Reviewers,
> 
> I have updated the test and made it semi-automatic (need to click "Print") . Test will initiate a print and result will be generated automatic. 
> 
> Please review and let me know your suggestions.

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on suggesion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24501/files
  - new: https://git.openjdk.org/jdk/pull/24501/files/5d53c5c9..e2185a98

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

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

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

From rkannathpari at openjdk.org  Tue May 13 05:19:09 2025
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 13 May 2025 05:19:09 GMT
Subject: RFR: 8334016: Make PrintNullString.java automatic [v4]
In-Reply-To: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
References: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
Message-ID: <PQTNgM9wxEooZ0G08bE76V-O1GcG4u1UKrVDqdaqLOQ=.1cf50bfd-44b8-402b-bf76-41596c3a7496@github.com>

> Hi Reviewers,
> 
> I have updated the test and made it semi-automatic (need to click "Print") . Test will initiate a print and result will be generated automatic. 
> 
> Please review and let me know your suggestions.

Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision:

 - Removed comment
 - Updated based on suggesion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24501/files
  - new: https://git.openjdk.org/jdk/pull/24501/files/e2185a98..6f4c150b

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

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

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

From rkannathpari at openjdk.org  Tue May 13 05:19:09 2025
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 13 May 2025 05:19:09 GMT
Subject: RFR: 8334016: Make PrintNullString.java automatic
In-Reply-To: <n9wRknJ-KLMdShLDbGBEXDytFGdRgNmgWnLx-UmnBNo=.db3f9826-c2c3-4957-ab68-c5ea3247d6ce@github.com>
References: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
 <n9wRknJ-KLMdShLDbGBEXDytFGdRgNmgWnLx-UmnBNo=.db3f9826-c2c3-4957-ab68-c5ea3247d6ce@github.com>
Message-ID: <JTHl2n49kyz6NHImwdaJcwl63HvG3Kf3N6eCy9QXNGo=.5c4f28e0-2798-4c22-b994-db2026b2d054@github.com>

On Wed, 16 Apr 2025 19:04:57 GMT, Phil Race <prr at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> I have updated the test and made it semi-automatic (need to click "Print") . Test will initiate a print and result will be generated automatic. 
>> 
>> Please review and let me know your suggestions.
>
> I don't think these changes are worth doing.
> What I would do is make the test completely automated.
> You don't need a user to create a printerjob any more - although you did when this test was first written
> Also you can print to file so you don't even need to waste paper.

Thanks @prrace, @DamonGuy and @aivanov-jdk for your time and review. Based on the feedback I have removed old UI related stuff, please review and let me know your suggestion if any .

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

PR Comment: https://git.openjdk.org/jdk/pull/24501#issuecomment-2875072016

From duke at openjdk.org  Tue May 13 06:06:53 2025
From: duke at openjdk.org (duke)
Date: Tue, 13 May 2025 06:06:53 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object [v3]
In-Reply-To: <ISKYj8E70TdudmfS-hIEX4Om6pL6acaPQ_MoRCuTYpw=.943f06e8-31b1-4b66-a44b-fa5075649951@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
 <ISKYj8E70TdudmfS-hIEX4Om6pL6acaPQ_MoRCuTYpw=.943f06e8-31b1-4b66-a44b-fa5075649951@github.com>
Message-ID: <fLTc-frMpAcayQdGI3wgXtwZl6MXz9zA-LSuCyLuWgk=.a6d4929a-a0ea-4a44-952f-78f9422b153d@github.com>

On Fri, 9 May 2025 20:48:13 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
>> 
>> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
>> 
>> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
>> 
>> The new test class passes on Linux, Windows and macOS.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

@gredler 
Your change (at version 2e37be11fefb88a6f7eee7bd4e46ff93581fbaed) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2875153632

From aturbanov at openjdk.org  Tue May 13 08:12:57 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 13 May 2025 08:12:57 GMT
Subject: Integrated: 8356175: Remove unnecessary Map.get from XWM.getInsets
In-Reply-To: <czOfOz4HkWVe7efBo1uPx8P_xk_2Pe3EmR678ZL137U=.cf0b4856-9be4-46fa-81a9-ec0a9cd46f11@github.com>
References: <czOfOz4HkWVe7efBo1uPx8P_xk_2Pe3EmR678ZL137U=.cf0b4856-9be4-46fa-81a9-ec0a9cd46f11@github.com>
Message-ID: <J5W_N7MF17GMgYKOmK5vVx-44AXASOxagL5XEkjAz-k=.b53b79ee-6c19-418c-831e-31af7dace4b7@github.com>

On Sun, 27 Apr 2025 21:01:07 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Cleanup code to use Map.putIfAbsent. It's clearer and faster.

This pull request has now been integrated.

Changeset: 522c7b44
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/522c7b446fef17a8400bc589c55b161e939770cc
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

8356175: Remove unnecessary Map.get from XWM.getInsets

Reviewed-by: tr, aivanov, serb

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

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

From aturbanov at openjdk.org  Tue May 13 08:15:32 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 13 May 2025 08:15:32 GMT
Subject: RFR: 8356843: Avoid redundant HashMap.get to obtain old value in
 Toolkit.setDesktopProperty
Message-ID: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>

To obtain previous value of `HashMap` we can use result of `.put` call. In this case we can avoid redundant `.get` call.

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

Commit messages:
 - [PATCH] Avoid redundant WeakHashMap.get to obtain old value in Toolkit

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

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

From liach at openjdk.org  Tue May 13 08:15:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 08:15:32 GMT
Subject: RFR: 8356843: Avoid redundant HashMap.get to obtain old value in
 Toolkit.setDesktopProperty
In-Reply-To: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
References: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
Message-ID: <cx9-fdllNQTqXAnU42CYCDdgOY4KkHvZBbl9ORR7PHA=.ffd22938-be24-4f44-a4a4-cc336472a7b5@github.com>

On Wed, 16 Apr 2025 14:48:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> To obtain previous value of `HashMap` we can use result of `.put` call. In this case we can avoid redundant `.get` call.

This field is protected; need evaluation about subclass tempering.

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

PR Comment: https://git.openjdk.org/jdk/pull/24691#issuecomment-2810085858

From aturbanov at openjdk.org  Tue May 13 08:15:32 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 13 May 2025 08:15:32 GMT
Subject: RFR: 8356843: Avoid redundant HashMap.get to obtain old value in
 Toolkit.setDesktopProperty
In-Reply-To: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
References: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
Message-ID: <sdxIS8doTl5JPZ7WY3WORcNMWBvm91SXZoeDN9XHWFE=.15ddd454-5eaa-4937-84f7-425191ff69d3@github.com>

On Wed, 16 Apr 2025 14:48:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> To obtain previous value of `HashMap` we can use result of `.put` call. In this case we can avoid redundant `.get` call.

It's `final`. What kind of problems can be from `protected` field?

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

PR Comment: https://git.openjdk.org/jdk/pull/24691#issuecomment-2810188669

From serb at openjdk.org  Tue May 13 08:15:32 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 08:15:32 GMT
Subject: RFR: 8356843: Avoid redundant HashMap.get to obtain old value in
 Toolkit.setDesktopProperty
In-Reply-To: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
References: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
Message-ID: <vZi6OdDftFiQC9PzvPd5v0-Pb9JD9oYtM6R3fg3zHPM=.9870ddbd-4639-40a9-aeab-4e859e8e84b2@github.com>

On Wed, 16 Apr 2025 14:48:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> To obtain previous value of `HashMap` we can use result of `.put` call. In this case we can avoid redundant `.get` call.

looks fine

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

PR Comment: https://git.openjdk.org/jdk/pull/24691#issuecomment-2874815079

From serb at openjdk.org  Tue May 13 08:53:39 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 08:53:39 GMT
Subject: RFR: 8356846: Remove unnecessary List.contains key from
 TIFFDirectory.removeTagSet
In-Reply-To: <nApYMgifHXmxIwNzIBbzcU8cLM6TBbTVVanCuQ-xj9s=.da62460b-ea8f-44bc-b750-52e93bdbe267@github.com>
References: <nApYMgifHXmxIwNzIBbzcU8cLM6TBbTVVanCuQ-xj9s=.da62460b-ea8f-44bc-b750-52e93bdbe267@github.com>
Message-ID: <NRyN8FO0oItJovVRhicrHXmOh4TLsSOxIYzBnuOWChg=.be4abe30-d23a-48bc-a0d5-0b0dbf2a2c47@github.com>

On Wed, 23 Apr 2025 08:38:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is no need to call List.contains before List.remove call.
> `tagSets` - is an ArrayList.

looks fine

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

PR Comment: https://git.openjdk.org/jdk/pull/24816#issuecomment-2874801400

From aturbanov at openjdk.org  Tue May 13 08:53:38 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 13 May 2025 08:53:38 GMT
Subject: RFR: 8356846: Remove unnecessary List.contains key from
 TIFFDirectory.removeTagSet
Message-ID: <nApYMgifHXmxIwNzIBbzcU8cLM6TBbTVVanCuQ-xj9s=.da62460b-ea8f-44bc-b750-52e93bdbe267@github.com>

There is no need to call List.contains before List.remove call.
`tagSets` - is an ArrayList.

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

Commit messages:
 - [PATCH] Remove unnecessary List.contains key from TIFFDirectory.removeTagSet

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

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

From tr at openjdk.org  Tue May 13 10:34:38 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 13 May 2025 10:34:38 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v2]
In-Reply-To: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
Message-ID: <JBqag_eOA8EpegeuHHyWg9X4sxDcuaDBx4wfLH_Gkjw=.bcb5562f-6f43-4294-be9a-791726e819a7@github.com>

> The rendering of the directory names are handled as JLabel w.r.t Look and feel and also either Details/List view. Though FilePane creates basic rendering for these two few Look and Feel define their own renderers and also ComboBox Directory directory name view. Since HTML filtering is not taken care in any of these renderers, JLabel renders them as HTML document if nothing is set or specified.
> The fix is to get "html.disable" property from JFileChooser and set the same to JLabel component which renders and set Directory name. Hence applications can either enable/disable this property and control HTML rendering of directory name.

Tejesh R 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://git.openjdk.java.net/jdk into branch_8139228
 - Fix for windows L&F
 - Fix + Manual test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24439/files
  - new: https://git.openjdk.org/jdk/pull/24439/files/7c190fe3..ebe3d910

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

  Stats: 332004 lines in 3532 files changed: 111256 ins; 205570 del; 15178 mod
  Patch: https://git.openjdk.org/jdk/pull/24439.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24439/head:pull/24439

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

From dgredler at openjdk.org  Tue May 13 10:41:01 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Tue, 13 May 2025 10:41:01 GMT
Subject: Integrated: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
Message-ID: <gJk3kIEjlV8keGLPVyV5vunTQTjLawoOehoL63Az1ek=.7f846671-4fa0-419c-918c-529981983f9c@github.com>

On Mon, 17 Feb 2025 14:06:53 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
> 
> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
> 
> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
> 
> The new test class passes on Linux, Windows and macOS.

This pull request has now been integrated.

Changeset: 85db4631
Author:    Daniel Gredler <dgredler at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85db4631ae5208fba74fa8b8638c32d4e42d3268
Stats:     195 lines in 2 files changed: 193 ins; 0 del; 2 mod

8350203: [macos] Newlines and tabs are not ignored when drawing text to a Graphics2D object
8353187: Test TextLayout/TestControls fails on macOS: width of 0x9, 0xa, 0xd isn't zero

Reviewed-by: honkar, aivanov, prr

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

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

From tr at openjdk.org  Tue May 13 11:04:52 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 13 May 2025 11:04:52 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v2]
In-Reply-To: <9eWBFqqVGM6xc824gwLDzpRT6cYOORMC1bFkdzFrseA=.424e137c-e5d9-4fb9-a2b1-e5a675b8ac6b@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <vEWA2CeJs9SmRb8K81xVWRMko2w6xj9Q2hIGXlYUVZM=.e7d736f9-9b2c-4a48-b366-e3801a304f9e@github.com>
 <Ahgb4B8gkI9Cjqwdoq0-Acfcga0QYbiprxAS4k3Fa7U=.c36f229f-2529-4788-8d14-86a51422e373@github.com>
 <vmyVz_91nhgMmjLla6DKOkJGD-Xp_6qajAgUKfeXLoY=.89fefd83-43c9-476c-a951-70a633f9a5e2@github.com>
 <xrKZHsl3CpNOAmppgUcqtxPK_Pb8RinLTrj11RMxGOY=.a64e2fff-04cb-4001-acbb-3c10b24d54de@github.com>
 <f6oYZ6xLi4A9CLobrR9K5ENfgEmSBqTay1kQaf7f3yY=.29f79326-48e7-4ad8-9afb-055536cdb4b2@github.com>
 <isvH5l_2W5YQ-mbpXd3XJMLyp2XP8Yohrq9cxFi84Nc=.27fc812c-b5e4-43df-b9f8-55881331097c@github.com>
 <UzRKXFgBG_WyKaEF3Hjdb3qb2ExAFmUA3UNZI42zMm0=.48021bee-2600-47bf-8c26-bfdddf320592@github.com>
 <MsGQMdJVt_rqNfkj62DVrsBWPlQrx5lsxjnR5BKzl9k=.a8bbbc62-1b60-4982-9424-6af202a6304c@github.com>
 <PfOTt7diduByRh7oViyuN-gJ-3iiD_CnGHIY8Xmni8k=.b52391fd-f576-4c01-923b-209975713596@github.com>
 <HYVRAUlbtJyV9GVAKlTWbeUNMHzV8ugjNuP
 7B4ALY48=.134d9204-f8a9-48fa-85af-982aa124469a@github.com>
 <oTB8PeOedGLLoza4ALZkxGvEdJttzGQb3_eVKwwT0eE=.9f06dd2d-7485-45eb-8cae-af3bad0aa683@github.com>
 <kG1MjZyVmybZj-A8u7ak4GBJ-h06fy5fAxIjFObj45c=.c80b7530-2747-4e56-bb7c-72bc84a612cf@github.com>
 <mwA2kTMeaSXuWYCnqXlvhMAJYUA50J58c-8BPaPiLw8=.71bc0dea-2509-491d-878a-ae27b04ec5fd@github.com>
 <QhZ-yOsUL-Y-EFjbyDD98pdW-EqLQk9yIIyIZF-IAh0=.a2145cd5-59fe-437f-81f6-4b468a5e8cb3@github.com>
 <p019LdENzXf5VWn6bjL5itcebyP1FWZeacqqDwVERmA=.86fa1fe0-138d-4655-8046-0f7021a4f0f4@github.com>
 <9eWBFqqVGM6xc824gwLDzpRT6cYOORMC1bFkdzFrseA=.424e137c-e5d9-4fb9-a2b1-e5a675b8ac6b@github.com>
Message-ID: <UctL2tyyTq19OTYn62hPBRP50kNy-iWe04G7NTS5PjQ=.2b189227-3755-470d-a82d-2dd94f46bb86@github.com>

On Tue, 13 May 2025 03:05:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Exception in thread "AWT-EventQueue-0" java.nio.file.InvalidPathException: Illegal char <<> at index 0: <html><h1 color=#ff00ff><font face="Comic Sans MS">SWING ROCKS!!!111
>>>         at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:191)
>>>         at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:142)
>>>         at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:46)
>>>         at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
>>>         at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:203)
>>>         at java.base/java.nio.file.Path.of(Path.java:148)
>>>         at java.base/java.nio.file.Paths.get(Paths.java:69)
>>>         at java.desktop/sun.awt.shell.ShellFolder.getShellFolder(ShellFolder.java:260)
>>>         at java.desktop/javax.swing.filechooser.FileSystemView.getShellFolder(FileSystemView.java:724)
>>>         at java.desktop/javax.swing.filechooser.FileSystemView.getSystemIcon(FileSystemView.java:242)
>>>         at java.desktop/com.sun.java.swing.plaf.windows.WindowsFileChooserUI$WindowsFileView.getIcon(WindowsFileChooserUI.java:1398)
>>>         at java.desktop/javax.swing.JFileChooser.getIcon(JFileChooser.java:1614)
>> 
>> 
>> This exception looks like a bug? I think if the file was not found then null is an expected result.
>> For now it can be bypassed by this:
>> 
>> 
>> import java.io.File;
>> import java.lang.Override;
>> 
>> import javax.swing.Icon;
>> import javax.swing.JFileChooser;
>> import javax.swing.SwingUtilities;
>> import javax.swing.UIManager;
>> import javax.swing.UnsupportedLookAndFeelException;
>> import javax.swing.filechooser.FileSystemView;
>> 
>> public class VirtualFileChooser {
>> 
>>     public static void main(String[] args) throws UnsupportedLookAndFeelException, ClassNotFoundException, InstantiationException, IllegalAccessException {
>>         UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");
>>         //UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel");
>> 
>> 
>>         SwingUtilities.invokeLater(() -> {
>>             JFileChooser chooser = new JFileChooser(new VirtualFileSystemView());
>> 
>>             int result = chooser.showOpenDialog(null);
>>             if (result == JFileChooser.APPROVE_OPTION) {
>>                 File selectedFile = chooser.getSelectedFile();
>>                 System.out.println("Selected: " + selectedFile.getAbsolutePath());
>>             }
>> ...
>
> Note that the bug occurs both in the list of roots (in the dropdown) and in the list of files.

Yes, thank you for the updated virtual test. I've updated the PR with windows L&F fix and also have updated the test too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2086548132

From aivanov at openjdk.org  Tue May 13 16:28:00 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 May 2025 16:28:00 GMT
Subject: RFR: 8334016: Make PrintNullString.java automatic [v4]
In-Reply-To: <PQTNgM9wxEooZ0G08bE76V-O1GcG4u1UKrVDqdaqLOQ=.1cf50bfd-44b8-402b-bf76-41596c3a7496@github.com>
References: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
 <PQTNgM9wxEooZ0G08bE76V-O1GcG4u1UKrVDqdaqLOQ=.1cf50bfd-44b8-402b-bf76-41596c3a7496@github.com>
Message-ID: <1VdMVLD7fTyAUZC0rV-0mmyZVZRbqZu1sB2Ht_C3GTk=.306c0442-4921-4ab5-841e-0033b7bd63c9@github.com>

On Tue, 13 May 2025 05:19:09 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> I have updated the test and made it semi-automatic (need to click "Print") . Test will initiate a print and result will be generated automatic. 
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Removed comment
>  - Updated based on suggesion

Marked as reviewed by aivanov (Reviewer).

test/jdk/java/awt/print/PrinterJob/PrintNullString.java line 61:

> 59:     public static void main(String[] args) throws Exception {
> 60:         if (PrinterJob.lookupPrintServices().length == 0) {
> 61:             throw new RuntimeException("Printer not configured or available.");

I'd leave the `main` method at the top of the file ? it describes what the test does.

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

PR Review: https://git.openjdk.org/jdk/pull/24501#pullrequestreview-2837416278
PR Review Comment: https://git.openjdk.org/jdk/pull/24501#discussion_r2087210314

From serb at openjdk.org  Tue May 13 17:10:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 17:10:01 GMT
Subject: RFR: 8356844: Missing @Serial annotation for
 sun.print.CustomOutputBin#serialVersionUID
Message-ID: <zH4YF8csdxwjpO7t7x7tWVZGQ4d77QkX2NzJfu4gRvc=.b8dcc685-f3cc-47de-b527-7a2523a93310@github.com>

The serialVersionUID field in sun.print.CustomOutputBin is missing the `@Serial` annotation. This is the only one missing usage of `@Serial` in the java.desktop module. The class was introduced in [JDK-8314070](https://bugs.openjdk.org/browse/JDK-8314070), after the `@Serial` annotation was applied to java.desktop in [JDK-8259522](https://bugs.openjdk.org/browse/JDK-8259522).

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

Commit messages:
 - 8356844: Missing @Serial annotation for sun.print.CustomOutputBin#serialVersionUID

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

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

From prr at openjdk.org  Tue May 13 17:45:50 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 13 May 2025 17:45:50 GMT
Subject: RFR: 8356844: Missing @Serial annotation for
 sun.print.CustomOutputBin#serialVersionUID
In-Reply-To: <zH4YF8csdxwjpO7t7x7tWVZGQ4d77QkX2NzJfu4gRvc=.b8dcc685-f3cc-47de-b527-7a2523a93310@github.com>
References: <zH4YF8csdxwjpO7t7x7tWVZGQ4d77QkX2NzJfu4gRvc=.b8dcc685-f3cc-47de-b527-7a2523a93310@github.com>
Message-ID: <1nMw8umDwMdNT_FZh0RETsuXUiU2PH8UxTrK0VQzxtw=.fb156f9a-892e-4a24-a5a9-2c112acdd982@github.com>

On Tue, 13 May 2025 08:19:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The serialVersionUID field in sun.print.CustomOutputBin is missing the `@Serial` annotation. This is the only one missing usage of `@Serial` in the java.desktop module. The class was introduced in [JDK-8314070](https://bugs.openjdk.org/browse/JDK-8314070), after the `@Serial` annotation was applied to java.desktop in [JDK-8259522](https://bugs.openjdk.org/browse/JDK-8259522).

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25202#pullrequestreview-2837641755

From aivanov at openjdk.org  Tue May 13 18:13:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 May 2025 18:13:52 GMT
Subject: RFR: 8356846: Remove unnecessary List.contains key from
 TIFFDirectory.removeTagSet
In-Reply-To: <nApYMgifHXmxIwNzIBbzcU8cLM6TBbTVVanCuQ-xj9s=.da62460b-ea8f-44bc-b750-52e93bdbe267@github.com>
References: <nApYMgifHXmxIwNzIBbzcU8cLM6TBbTVVanCuQ-xj9s=.da62460b-ea8f-44bc-b750-52e93bdbe267@github.com>
Message-ID: <ZWaoJWv-4wBcAH6NkaZg0HmGg4-PRN1_DvcFxVlZRSQ=.a145ff1b-2fc7-4143-a114-127d4af07e18@github.com>

On Wed, 23 Apr 2025 08:38:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is no need to call List.contains before List.remove call.
> `tagSets` - is an ArrayList.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24816#pullrequestreview-2837706376

From aivanov at openjdk.org  Tue May 13 18:16:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 May 2025 18:16:57 GMT
Subject: RFR: 8356843: Avoid redundant HashMap.get to obtain old value in
 Toolkit.setDesktopProperty
In-Reply-To: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
References: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
Message-ID: <ymajNei3PsRJ2kUcpXxxeitA7oY-aG7F2XDMexa3mFs=.11a9687d-7cdd-4fa6-8e12-4bf0579749eb@github.com>

On Wed, 16 Apr 2025 14:48:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> To obtain previous value of `HashMap` we can use result of `.put` call. In this case we can avoid redundant `.get` call.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24691#pullrequestreview-2837712897

From honkar at openjdk.org  Tue May 13 18:24:28 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 13 May 2025 18:24:28 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9
Message-ID: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>

The following line results in unused-result warning on linux/clang.


/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
 declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 


There are two ways to handle it 

1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.

2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.

NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.

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

Commit messages:
 - unused-result changes

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

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

From honkar at openjdk.org  Tue May 13 18:32:51 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 13 May 2025 18:32:51 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9
In-Reply-To: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
Message-ID: <H_UxlxeowDOSVY5hrBBO-5OjIQvqgNpFx0VPPqMPayE=.ccd6b076-ae32-4931-8bbb-6fe6cc402609@github.com>

On Tue, 13 May 2025 18:19:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> The following line results in unused-result warning on linux/clang.
> 
> 
> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
> 
> 
> There are two ways to handle it 
> 
> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
> 
> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
> 
> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.

make/modules/java.desktop/lib/AwtLibraries.gmk line 281:

> 279:       DISABLED_WARNINGS_gcc_XlibWrapper.c := type-limits pointer-to-int-cast, \
> 280:       DISABLED_WARNINGS_gcc_XRBackendNative.c := maybe-uninitialized, \
> 281:       DISABLED_WARNINGS_gcc_XToolkit.c := unused-result, \

Probably a question for build team -
One thing to be noted here is that:  With unused-result line removed and WITHOUT the if block changes in XToolkit.c, I expected the build to fail due to unused-result on linux/gcc but it did not.
So is there any chance that this disabled warning is being added from else where for gcc ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2087413125

From aivanov at openjdk.org  Tue May 13 18:29:01 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 May 2025 18:29:01 GMT
Subject: RFR: 8356844: Missing @Serial annotation for
 sun.print.CustomOutputBin#serialVersionUID
In-Reply-To: <zH4YF8csdxwjpO7t7x7tWVZGQ4d77QkX2NzJfu4gRvc=.b8dcc685-f3cc-47de-b527-7a2523a93310@github.com>
References: <zH4YF8csdxwjpO7t7x7tWVZGQ4d77QkX2NzJfu4gRvc=.b8dcc685-f3cc-47de-b527-7a2523a93310@github.com>
Message-ID: <SYA6GfCtBZbeZV2zsoGIa5uZlITeSya9A98aSRTpwmA=.69b126d0-c233-4262-bc53-eee6efce7f81@github.com>

On Tue, 13 May 2025 08:19:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The serialVersionUID field in sun.print.CustomOutputBin is missing the `@Serial` annotation. This is the only one missing usage of `@Serial` in the java.desktop module. The class was introduced in [JDK-8314070](https://bugs.openjdk.org/browse/JDK-8314070), after the `@Serial` annotation was applied to java.desktop in [JDK-8259522](https://bugs.openjdk.org/browse/JDK-8259522).

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/sun/print/CustomOutputBin.java line 2:

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

Suggestion:

 * Copyright (c) 2024, 2025, Oracle and/or its affiliates. All rights reserved.

The year shouldn't be replaced but added.

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

PR Review: https://git.openjdk.org/jdk/pull/25202#pullrequestreview-2837743112
PR Review Comment: https://git.openjdk.org/jdk/pull/25202#discussion_r2087407925

From aivanov at openjdk.org  Tue May 13 18:38:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 May 2025 18:38:52 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9
In-Reply-To: <H_UxlxeowDOSVY5hrBBO-5OjIQvqgNpFx0VPPqMPayE=.ccd6b076-ae32-4931-8bbb-6fe6cc402609@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
 <H_UxlxeowDOSVY5hrBBO-5OjIQvqgNpFx0VPPqMPayE=.ccd6b076-ae32-4931-8bbb-6fe6cc402609@github.com>
Message-ID: <mfESXOoDKToRvOX2SiR3xtqDa3hRvbXSXdFRpOPkvF0=.2a4b461d-5a2d-4ff6-a0aa-42ea91360066@github.com>

On Tue, 13 May 2025 18:30:01 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The following line results in unused-result warning on linux/clang.
>> 
>> 
>> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
>> 
>> 
>> There are two ways to handle it 
>> 
>> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
>> 
>> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
>> 
>> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.
>
> make/modules/java.desktop/lib/AwtLibraries.gmk line 281:
> 
>> 279:       DISABLED_WARNINGS_gcc_XlibWrapper.c := type-limits pointer-to-int-cast, \
>> 280:       DISABLED_WARNINGS_gcc_XRBackendNative.c := maybe-uninitialized, \
>> 281:       DISABLED_WARNINGS_gcc_XToolkit.c := unused-result, \
> 
> Probably a question for build team -
> One thing to be noted here is that:  With unused-result line removed and WITHOUT the if block changes in XToolkit.c, I expected the build to fail due to unused-result on linux/gcc but it did not.
> So is there any chance that this disabled warning is being added from else where for gcc ?

Maybe gcc doesn't detect this specific case.

There could've been other cases which triggered the warning in gcc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2087418018

From aivanov at openjdk.org  Tue May 13 18:38:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 May 2025 18:38:53 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9
In-Reply-To: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
Message-ID: <QzueQ7pYx9bUYK38vRL0Dkm2HL9yZ3dxyGpBZye9aBo=.f0f46590-145c-48bf-85da-509d066cc900@github.com>

On Tue, 13 May 2025 18:19:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> The following line results in unused-result warning on linux/clang.
> 
> 
> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
> 
> 
> There are two ways to handle it 
> 
> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
> 
> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
> 
> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.

src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c line 696:

> 694:     if (!isMainThread() && awt_pipe_inited) {
> 695:         if (write(AWT_WRITEPIPE, &wakeUp_char, 1) < 0) {
> 696:             // if block is left empty to avoid adding unused-result to

Does it make sense to add a trace with `DTRACE_PRINTLN*`?

It could be useful for debugging?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2087421715

From serb at openjdk.org  Tue May 13 19:11:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 19:11:53 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
Message-ID: <XayTq0y7nzJiJ4mbRYd5QZLLu2bgJ1zgGydnvW0kvLk=.82ee972d-3906-4c06-b6f6-dfcc9d7c537b@github.com>

On Fri, 9 May 2025 20:54:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

src/java.desktop/share/classes/javax/sound/SoundClip.java line 61:

> 59:      * @throws IOException if there is an error reading from {@code file}
> 60:      */
> 61:     public static SoundClip createSoundClip(File file) throws IOException {

Can we gain any benefits by using Path instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087467168

From serb at openjdk.org  Tue May 13 19:15:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 19:15:53 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
Message-ID: <S3nlbHuFmxb4nE78c1VHbWFD8k_ifJ3FOlaH1rnLXgA=.dfd3e998-749c-45c9-b56a-5343ee25d1b5@github.com>

On Fri, 9 May 2025 20:54:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

src/java.desktop/share/classes/javax/sound/SoundClip.java line 63:

> 61:     public static SoundClip createSoundClip(File file) throws IOException {
> 62:         if (file == null) {
> 63:             throw new IllegalArgumentException("file must not be null");

Most of the APIs in javax.sound.* throw NullPointerException for null arguments and IllegalArgumentException for other invalid parameters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087471460

From serb at openjdk.org  Tue May 13 19:18:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 19:18:53 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
Message-ID: <HUoNiBr13XJRwAXCnlWQV50wLHNY8IUOmqP-aCq1KnQ=.e416d22c-f20d-419d-add4-55f4ce90e822@github.com>

On Fri, 9 May 2025 20:54:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

src/java.desktop/share/classes/javax/sound/SoundClip.java line 78:

> 76:      * of this class is a no-op.
> 77:      */
> 78:     public synchronized boolean canPlay() {

Should we perhaps document the multithreaded use of Clip? Do we really need all these synchronized keywords in the file?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087475827

From serb at openjdk.org  Tue May 13 19:26:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 19:26:54 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
Message-ID: <Qi14sG1j4R6aADbzev3vyM0v3yNnZqhKiCHYljdIOQY=.4c0b83cc-7ade-47e8-9a6e-6fd308ce4ae5@github.com>

On Fri, 9 May 2025 20:54:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

test/jdk/javax/sound/SoundClip/SoundClipTest.java line 34:

> 32:  * @key sound headful
> 33:  * @summary basic testing of javax.sound.SoundClip
> 34:  * @run main/othervm SoundClipTest javasound.wav

What about a non-existent or broken file? Should we check for an IOException in that case?

test/jdk/javax/sound/SoundClip/SoundClipTest.java line 41:

> 39:     public static void main(String[] args) throws Exception {
> 40: 
> 41:         if (!isSoundcardInstalled()) {

Why we cannot check that the playing sound is a no-op in this case, as specified?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087486464
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087484987

From serb at openjdk.org  Tue May 13 19:34:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 19:34:55 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
Message-ID: <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>

On Fri, 9 May 2025 20:54:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

src/java.desktop/share/classes/javax/sound/SoundClip.java line 35:

> 33: /**
> 34:  * The {@code SoundClip} class is a simple abstraction for playing a sound clip.
> 35:  * It will play any format that is recognized by the {@code javax.sound} API,

I think we should mention in the doc that this is applicable for small audio files since we will load all data into the memory.

src/java.desktop/share/classes/javax/sound/SoundClip.java line 45:

> 43:  * @since 25
> 44:  */
> 45: public final class SoundClip {

What about considering a different name, such as AudioClip with a static method like AudioClip.create(...)? or maybe Audio....Player?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087496834
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087496010

From serb at openjdk.org  Tue May 13 19:49:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 19:49:52 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <XayTq0y7nzJiJ4mbRYd5QZLLu2bgJ1zgGydnvW0kvLk=.82ee972d-3906-4c06-b6f6-dfcc9d7c537b@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <XayTq0y7nzJiJ4mbRYd5QZLLu2bgJ1zgGydnvW0kvLk=.82ee972d-3906-4c06-b6f6-dfcc9d7c537b@github.com>
Message-ID: <OYyNZ91Uu-nhfJYWA63p82m34ZcffwlnR3_V4sqWpBM=.a50a5a1d-8e37-4585-87de-996cdc638cec@github.com>

On Tue, 13 May 2025 19:09:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356049
>
> src/java.desktop/share/classes/javax/sound/SoundClip.java line 61:
> 
>> 59:      * @throws IOException if there is an error reading from {@code file}
>> 60:      */
>> 61:     public static SoundClip createSoundClip(File file) throws IOException {
> 
> Can we gain any benefits by using Path instead?

Or maybe we can add this API to AudioSystem/clip?
Old code

    File file = new File(file);
    AudioInputStream audioIn = AudioSystem.getAudioInputStream(...file...);  
    Clip clip = AudioSystem.getClip();
    clip.open(audioIn);
    clip.start();

new code:

    File file = new File(file);
    AudioClip clip = AudioSystem.getAudioClip(...file...);
    clip.play()/canPlay/loop/stop;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087508034

From serb at openjdk.org  Tue May 13 19:49:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 19:49:52 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <OYyNZ91Uu-nhfJYWA63p82m34ZcffwlnR3_V4sqWpBM=.a50a5a1d-8e37-4585-87de-996cdc638cec@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <XayTq0y7nzJiJ4mbRYd5QZLLu2bgJ1zgGydnvW0kvLk=.82ee972d-3906-4c06-b6f6-dfcc9d7c537b@github.com>
 <OYyNZ91Uu-nhfJYWA63p82m34ZcffwlnR3_V4sqWpBM=.a50a5a1d-8e37-4585-87de-996cdc638cec@github.com>
Message-ID: <Ys8Ja-yLiBLnARGD4Z8BHwRD2TkD551lJGws9xd1V_o=.7d84d0b3-eb34-4455-9efa-467c7f08daab@github.com>

On Tue, 13 May 2025 19:40:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/sound/SoundClip.java line 61:
>> 
>>> 59:      * @throws IOException if there is an error reading from {@code file}
>>> 60:      */
>>> 61:     public static SoundClip createSoundClip(File file) throws IOException {
>> 
>> Can we gain any benefits by using Path instead?
>
> Or maybe we can add this API to AudioSystem/clip?
> Old code
> 
>     File file = new File(file);
>     AudioInputStream audioIn = AudioSystem.getAudioInputStream(...file...);  
>     Clip clip = AudioSystem.getClip();
>     clip.open(audioIn);
>     clip.start();
> 
> new code:
> 
>     File file = new File(file);
>     AudioClip clip = AudioSystem.getAudioClip(...file...);
>     clip.play()/canPlay/loop/stop;

or maybe inject all these simple methods into `javax.sound.sampled.Clip` or its subclass/superclass.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087516819

From serb at openjdk.org  Tue May 13 19:49:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 19:49:54 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
Message-ID: <dab0U4m4_afowQ9uCT7DMsJ-CzOwn7lHb9OVFZ4jGZc=.db037b40-f617-48f6-93e8-336a5fa6beef@github.com>

On Fri, 9 May 2025 20:54:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

src/java.desktop/share/classes/javax/sound/package-info.java line 43:

> 41:  * @since 25
> 42:  */
> 43: package javax.sound;

Why javax.sound and not sampled? do we want to support midi files by SoundClip as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087511125

From serb at openjdk.org  Tue May 13 20:35:36 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 20:35:36 GMT
Subject: RFR: 8356844: Missing @Serial annotation for
 sun.print.CustomOutputBin#serialVersionUID [v2]
In-Reply-To: <zH4YF8csdxwjpO7t7x7tWVZGQ4d77QkX2NzJfu4gRvc=.b8dcc685-f3cc-47de-b527-7a2523a93310@github.com>
References: <zH4YF8csdxwjpO7t7x7tWVZGQ4d77QkX2NzJfu4gRvc=.b8dcc685-f3cc-47de-b527-7a2523a93310@github.com>
Message-ID: <fpDOiYqI1fZyyJsB7L9ZpOva-N6Q-Sw8GBzRZRnD5Fc=.507b84ea-be57-4775-91ec-ad996f25b212@github.com>

> The serialVersionUID field in sun.print.CustomOutputBin is missing the `@Serial` annotation. This is the only one missing usage of `@Serial` in the java.desktop module. The class was introduced in [JDK-8314070](https://bugs.openjdk.org/browse/JDK-8314070), after the `@Serial` annotation was applied to java.desktop in [JDK-8259522](https://bugs.openjdk.org/browse/JDK-8259522).

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

  Update src/java.desktop/share/classes/sun/print/CustomOutputBin.java
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25202/files
  - new: https://git.openjdk.org/jdk/pull/25202/files/84e2364c..901a1346

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

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

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

From serb at openjdk.org  Tue May 13 20:37:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 20:37:52 GMT
Subject: RFR: 8356844: Missing @Serial annotation for
 sun.print.CustomOutputBin#serialVersionUID [v2]
In-Reply-To: <SYA6GfCtBZbeZV2zsoGIa5uZlITeSya9A98aSRTpwmA=.69b126d0-c233-4262-bc53-eee6efce7f81@github.com>
References: <zH4YF8csdxwjpO7t7x7tWVZGQ4d77QkX2NzJfu4gRvc=.b8dcc685-f3cc-47de-b527-7a2523a93310@github.com>
 <SYA6GfCtBZbeZV2zsoGIa5uZlITeSya9A98aSRTpwmA=.69b126d0-c233-4262-bc53-eee6efce7f81@github.com>
Message-ID: <OphA3KRIxJdtUm2OA485HatpSR4530WvRm7bUIEWqL8=.62dece26-9ea0-4cd9-a9d3-7bdcaebffe7b@github.com>

On Tue, 13 May 2025 18:26:14 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.desktop/share/classes/sun/print/CustomOutputBin.java
>>   
>>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>
> src/java.desktop/share/classes/sun/print/CustomOutputBin.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Suggestion:
> 
>  * Copyright (c) 2024, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> The year shouldn't be replaced but added.

I keep forgetting that... Thanks a lot!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25202#discussion_r2087591306

From kizune at openjdk.org  Tue May 13 20:46:37 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 13 May 2025 20:46:37 GMT
Subject: RFR: 8323545: java/awt/GraphicsDevice/CheckDisplayModes.java fails
 with "exit code: 133" [v2]
In-Reply-To: <_YE9ifFDv0XSJfwJXoX-TkY9OLaXlD1d7NkQWxiTJsU=.5aaa2457-1dce-4d95-be85-1e78dbb46a89@github.com>
References: <_YE9ifFDv0XSJfwJXoX-TkY9OLaXlD1d7NkQWxiTJsU=.5aaa2457-1dce-4d95-be85-1e78dbb46a89@github.com>
Message-ID: <LDaRpyoWAZZOMgLeCvIVGoXVoJT3VAZz0llPalhauEU=.8e6567fb-4882-4b4a-8821-e494131480e9@github.com>

> This test fails intermittently, sometimes it does not fail in half a year so i was unable to catch it myself to do any reasonable debugging. In this pull request I am adding debug output to understand at least what graphics device is connected to the test machine and which graphics mode on which device gives us problem. Next time test fails we will at least have some hint on what's going on.

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

  Caching getScreenDevices() output in a local variable.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25179/files
  - new: https://git.openjdk.org/jdk/pull/25179/files/2d8a27f5..d7349fe0

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

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

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

From kizune at openjdk.org  Tue May 13 20:46:38 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 13 May 2025 20:46:38 GMT
Subject: RFR: 8323545: java/awt/GraphicsDevice/CheckDisplayModes.java fails
 with "exit code: 133" [v2]
In-Reply-To: <ns_4dFl4STO9O3nG2q-fwP3t7KNuzNQ8onOT8VqcbVs=.351144ae-9a0d-4b23-ba85-e8dd3cb41b19@github.com>
References: <_YE9ifFDv0XSJfwJXoX-TkY9OLaXlD1d7NkQWxiTJsU=.5aaa2457-1dce-4d95-be85-1e78dbb46a89@github.com>
 <ns_4dFl4STO9O3nG2q-fwP3t7KNuzNQ8onOT8VqcbVs=.351144ae-9a0d-4b23-ba85-e8dd3cb41b19@github.com>
Message-ID: <BGQAnAypBvDrF7yNoU2lTd31GRh5eLIs0Fn5A8kaf2s=.7ececcd3-458c-453c-85ee-c3c4c3e63d30@github.com>

On Mon, 12 May 2025 23:56:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Caching getScreenDevices() output in a local variable.
>
> test/jdk/java/awt/GraphicsDevice/CheckDisplayModes.java line 42:
> 
>> 40:         }
>> 41: 
>> 42:         for (GraphicsDevice graphicDevice : ge.getScreenDevices()) {
> 
> I remember that, at least in ogl, querying/initializing devices can invalidate the list of existing devices on the fly. It might be better to call getScreenDevices only once, this could(or maybe not) increase the chances to catch the bug."

Ok, storing all devices in a local array to use it in both debug output and actual resolution testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25179#discussion_r2087601289

From prr at openjdk.org  Tue May 13 20:52:50 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 13 May 2025 20:52:50 GMT
Subject: RFR: 8356814: LineBreakMeasurer.nextLayout() slower than necessary
 when no break needed
In-Reply-To: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>
References: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>
Message-ID: <eCNglzFBXWXR00R_CTjBCr3D9lKRBArNOEOCT2McrAw=.e387b4b3-e275-4fa6-be83-0bf82daa3659@github.com>

On Mon, 12 May 2025 20:35:52 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> `LineBreakMeasurer.nextLayout()` calls `nextOffset()` internally to calculate the layout limit. When this happens, a `GlyphVector` is created and the layout engine is invoked to shape the text. The `GlyphVector` is cached in the relevant `ExtendedTextSourceLabel` component.
> 
> `LineBreakMeasurer.nextLayout()` then calls `TextMeasurer.getLayout()` which eventually asks that same `ExtendedTextSourceLabel` component for a subset component. This triggers the creation of a fresh `ExtendedTextSourceLabel` without the cached `GlyphVector`.
> 
> However, this fresh `ExtendedTextSourceLabel` is not necessary if the subset requested perfectly matches the already-existing `ExtendedTextSourceLabel` component. This happens when the text is short enough that no line break is needed.
> 
> I think we should change `ExtendedTextSourceLabel.getSubset()` to return `this` if the requested subset is identical to the existing instance. This will allow us to use the existing cached `GlyphVector`, and the call to `LineBreakMeasurer.nextLayout()` will trigger text shaping once, rather than twice.
> 
> In local testing, the test program below ran in ~1250 ms before this optimization, and ran in ~960 ms after the change (a 23% reduction in run time).
> 
> The following three existing test classes provide good regression test coverage for this change:
> - test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTrackingAuto
> - test/jdk/java/awt/font/LineBreakMeasurer/TestLineBreakWithFontSub
> - test/jdk/java/awt/font/LineBreakMeasurer/FRCTest
> 
> 
> public class LineBreakMeasurerPerfTest {
> 
>     public static void main(String[] args) {
> 
>         float advance = 0;
>         long start = System.currentTimeMillis();
>         AttributedString string = new AttributedString("This is a test.");
>         FontRenderContext frc = new FontRenderContext(new AffineTransform(), true, true);
> 
>         for (int i = 0; i < 100_000; i++) {
>             LineBreakMeasurer measurer = new LineBreakMeasurer(string.getIterator(), frc);
>             TextLayout layout = measurer.nextLayout(999); // large enough to not require break
>             advance = Math.max(advance, layout.getAdvance());
>         }
> 
>         long end = System.currentTimeMillis();
>         System.out.println((end - start) + " ms elapsed (advance: " + advance + ")");
>     }
> 
> }

Looks OK. Testing passes. My only concern would have been if these are mutable, but they aren't Unless something casts to a known sub-class that is mutable, but I don't know think that is the case.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25193#pullrequestreview-2838090850

From prr at openjdk.org  Tue May 13 21:28:24 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 13 May 2025 21:28:24 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>

> A simple API to replace java.applet.AudioClip
> 
> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200

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

  8356049

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24991/files
  - new: https://git.openjdk.org/jdk/pull/24991/files/a2da1a1c..b3cda856

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

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

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

From swen at openjdk.org  Tue May 13 22:19:56 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 13 May 2025 22:19:56 GMT
Subject: Integrated: 8356605: JRSUIControl.hashCode and JRSUIState.hashCode can
 use Long.hashCode
In-Reply-To: <nWA2jQWQE9lsM5Z2W8K7WniquRWpEBQWbtCYF2dN6iA=.7ad7b55a-6fa7-4331-bc9a-dac1d21726c8@github.com>
References: <nWA2jQWQE9lsM5Z2W8K7WniquRWpEBQWbtCYF2dN6iA=.7ad7b55a-6fa7-4331-bc9a-dac1d21726c8@github.com>
Message-ID: <n9XYy8OWqkcV_L0d7esgxvUPbQNpFvYwAKTJD28qAvE=.808bba84-93b6-4890-9fdc-75ef2e75122a@github.com>

On Thu, 1 May 2025 16:16:29 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to #24959 and #24971 and #24987, apple.laf.JRSUIControl and apple.laf.JRSUIState in java.desktop can also be simplified similarly.
> 
> Replace manual bitwise operations in hashCode implementations of JRSUIControl/JRSUIState with Long::hashCode.

This pull request has now been integrated.

Changeset: 1bded718
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1bded7188f866a61d03936a9537503b31d603dc2
Stats:     5 lines in 2 files changed: 0 ins; 1 del; 4 mod

8356605: JRSUIControl.hashCode and JRSUIState.hashCode can use Long.hashCode

Reviewed-by: prr, serb

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

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

From achung at openjdk.org  Tue May 13 23:37:51 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 13 May 2025 23:37:51 GMT
Subject: RFR: 8323545: java/awt/GraphicsDevice/CheckDisplayModes.java fails
 with "exit code: 133" [v2]
In-Reply-To: <LDaRpyoWAZZOMgLeCvIVGoXVoJT3VAZz0llPalhauEU=.8e6567fb-4882-4b4a-8821-e494131480e9@github.com>
References: <_YE9ifFDv0XSJfwJXoX-TkY9OLaXlD1d7NkQWxiTJsU=.5aaa2457-1dce-4d95-be85-1e78dbb46a89@github.com>
 <LDaRpyoWAZZOMgLeCvIVGoXVoJT3VAZz0llPalhauEU=.8e6567fb-4882-4b4a-8821-e494131480e9@github.com>
Message-ID: <za1IpNHdEzy-lVKjSVU60MvBPm5mFqKVB-_7fu5Ybw4=.2dc1e1ed-3a9b-48ca-ac9f-0a97ec3f5d01@github.com>

On Tue, 13 May 2025 20:46:37 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> This test fails intermittently, sometimes it does not fail in half a year so i was unable to catch it myself to do any reasonable debugging. In this pull request I am adding debug output to understand at least what graphics device is connected to the test machine and which graphics mode on which device gives us problem. Next time test fails we will at least have some hint on what's going on.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Caching getScreenDevices() output in a local variable.

Marked as reviewed by achung (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25179#pullrequestreview-2838339543

From mvs at openjdk.org  Wed May 14 03:01:50 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 14 May 2025 03:01:50 GMT
Subject: RFR: 8355515: Clarify the purpose of forcePass() and forceFail()
 methods
In-Reply-To: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
References: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
Message-ID: <vjV14-Du8aLCr5C191VLrJt5K_C6lfZ3Dxran4Y3uUY=.e15cc23a-d819-4dde-8fdf-537b8a50914b@github.com>

On Wed, 7 May 2025 12:28:52 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Clarified the purpose of forcePass() and forceFail() methods and recommended usage of these methods.
> 
> forcePass() contained an incorrect sample; it's addressed by [JDK-8355441](https://bugs.openjdk.org/browse/JDK-8355441).
> 
> The description of forceFail() has been expanded, too.
> 
> 
> A new section in the description of the PassFailJFrame added to describe forcePass() and forceFail().

@aivanov-jdk Any comments from your side?

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

PR Comment: https://git.openjdk.org/jdk/pull/25091#issuecomment-2878491658

From serb at openjdk.org  Wed May 14 03:04:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 May 2025 03:04:51 GMT
Subject: RFR: 8323545: java/awt/GraphicsDevice/CheckDisplayModes.java fails
 with "exit code: 133" [v2]
In-Reply-To: <LDaRpyoWAZZOMgLeCvIVGoXVoJT3VAZz0llPalhauEU=.8e6567fb-4882-4b4a-8821-e494131480e9@github.com>
References: <_YE9ifFDv0XSJfwJXoX-TkY9OLaXlD1d7NkQWxiTJsU=.5aaa2457-1dce-4d95-be85-1e78dbb46a89@github.com>
 <LDaRpyoWAZZOMgLeCvIVGoXVoJT3VAZz0llPalhauEU=.8e6567fb-4882-4b4a-8821-e494131480e9@github.com>
Message-ID: <JEIce5V-yV_g1jLIz2lY71u9zxS-nGXkyGGREmy6TBY=.8da8dec4-632f-4008-b01c-d481fcd558c2@github.com>

On Tue, 13 May 2025 20:46:37 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> This test fails intermittently, sometimes it does not fail in half a year so i was unable to catch it myself to do any reasonable debugging. In this pull request I am adding debug output to understand at least what graphics device is connected to the test machine and which graphics mode on which device gives us problem. Next time test fails we will at least have some hint on what's going on.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Caching getScreenDevices() output in a local variable.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25179#pullrequestreview-2838583830

From serb at openjdk.org  Wed May 14 03:14:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 May 2025 03:14:57 GMT
Subject: RFR: 8356843: Avoid redundant HashMap.get to obtain old value in
 Toolkit.setDesktopProperty
In-Reply-To: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
References: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
Message-ID: <pFBZeTan4bM8nooKyqc_9Pwc8sOz6TkU2mdwe2Lr2GI=.431e114b-4442-422c-bc65-192244f72ad7@github.com>

On Wed, 16 Apr 2025 14:48:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> To obtain previous value of `HashMap` we can use result of `.put` call. In this case we can avoid redundant `.get` call.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24691#pullrequestreview-2838598416

From rkannathpari at openjdk.org  Wed May 14 04:07:08 2025
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Wed, 14 May 2025 04:07:08 GMT
Subject: RFR: 8334016: Make PrintNullString.java automatic [v5]
In-Reply-To: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
References: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
Message-ID: <TU550HE7vdwVBAfasjoUWnLsLNXMEq-9AhfSOOQ6bhw=.af24780f-9677-4a8b-a9fb-8ec51bd71d23@github.com>

> Hi Reviewers,
> 
> I have updated the test and made it semi-automatic (need to click "Print") . Test will initiate a print and result will be generated automatic. 
> 
> Please review and let me know your suggestions.

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Moved main fuction to top

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24501/files
  - new: https://git.openjdk.org/jdk/pull/24501/files/6f4c150b..2c9f9901

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

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

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

From serb at openjdk.org  Wed May 14 04:14:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 May 2025 04:14:54 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
Message-ID: <lTHWCVus_F1QuH_rk-EzUlQPPTFn2P6qq4PPF11jtAk=.15a99668-cf50-4395-a75e-6120757041d2@github.com>

On Tue, 13 May 2025 21:28:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 131:

> 129:             }
> 130:         } catch (UnsupportedAudioFileException e) {
> 131:             // not an audio file

This code path seems will not be (rarely) executed?
The midi file will be handled above by the AudioSystem.getAudioInputStream() via SoftMidiAudioFileReader provider? But if converted midi->sampled data cannot be played via audio device then it might be useful to try MidiDevice, but I do not think it can be done by catching UnsupportedAudioFileException.

src/java.desktop/share/classes/javax/sound/SoundClip.java line 93:

> 91:      * Each time this method is called, the clip is restarted from the beginning.
> 92:      */
> 93:     public synchronized void play() {

We might want to clarify that play() and loop() are non-blocking in terms of execution but may keep the application alive if audio threads are still running.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087964236
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087992995

From serb at openjdk.org  Wed May 14 04:14:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 May 2025 04:14:56 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
Message-ID: <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>

On Tue, 13 May 2025 19:32:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356049
>
> src/java.desktop/share/classes/javax/sound/SoundClip.java line 35:
> 
>> 33: /**
>> 34:  * The {@code SoundClip} class is a simple abstraction for playing a sound clip.
>> 35:  * It will play any format that is recognized by the {@code javax.sound} API,
> 
> I think we should mention in the doc that this is applicable for small audio files since we will load all data into the memory.

Example of memory requirement: https://github.com/openjdk/jdk/blob/2c4e8d211a030c85488e656a9a851d10dd0f9c11/src/java.desktop/share/classes/javax/sound/sampled/Clip.java#L34

> src/java.desktop/share/classes/javax/sound/SoundClip.java line 45:
> 
>> 43:  * @since 25
>> 44:  */
>> 45: public final class SoundClip {
> 
> What about considering a different name, such as AudioClip with a static method like AudioClip.create(...)? or maybe Audio....Player?

Could having both javax.sound.SoundClip and javax.sound.sampled.Clip cause confusion?

> src/java.desktop/share/classes/javax/sound/SoundClip.java line 63:
> 
>> 61:     public static SoundClip createSoundClip(File file) throws IOException {
>> 62:         if (file == null) {
>> 63:             throw new IllegalArgumentException("file must not be null");
> 
> Most of the APIs in javax.sound.* throw NullPointerException for null arguments and IllegalArgumentException for other invalid parameters.

it is even noticed for both subpackages, it is better to use NPE here as well:

 * Please note: In the {@code javax.sound.sampled.spi} APIs, a {@code null}
 * reference parameter to methods is incorrect unless explicitly documented on
 * the method as having a meaningful interpretation. Usage to the contrary is
 * incorrect coding and may result in a run time exception either immediately or
 * at some later time. {@code NullPointerException} is an example of typical and
 * acceptable run time exception for such cases.

> test/jdk/javax/sound/SoundClip/SoundClipTest.java line 41:
> 
>> 39:     public static void main(String[] args) throws Exception {
>> 40: 
>> 41:         if (!isSoundcardInstalled()) {
> 
> Why we cannot check that the playing sound is a no-op in this case, as specified?

Why do not check this case as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087976970
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087986810
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087974279
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087985318

From serb at openjdk.org  Wed May 14 04:25:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 May 2025 04:25:52 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9
In-Reply-To: <QzueQ7pYx9bUYK38vRL0Dkm2HL9yZ3dxyGpBZye9aBo=.f0f46590-145c-48bf-85da-509d066cc900@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
 <QzueQ7pYx9bUYK38vRL0Dkm2HL9yZ3dxyGpBZye9aBo=.f0f46590-145c-48bf-85da-509d066cc900@github.com>
Message-ID: <Z8wyMfkdqQFBMEK-wLO7VLpn2DYbCmvFgDOrsHq44Go=.8401baf1-8888-4b27-b5d9-459b6f9cd99d@github.com>

On Tue, 13 May 2025 18:36:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The following line results in unused-result warning on linux/clang.
>> 
>> 
>> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
>> 
>> 
>> There are two ways to handle it 
>> 
>> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
>> 
>> 
>> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html
>> 
>> 
>> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
>> 
>> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.
>
> src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c line 696:
> 
>> 694:     if (!isMainThread() && awt_pipe_inited) {
>> 695:         if (write(AWT_WRITEPIPE, &wakeUp_char, 1) < 0) {
>> 696:             // if block is left empty to avoid adding unused-result to
> 
> Does it make sense to add a trace with `DTRACE_PRINTLN*`?
> 
> It could be useful for debugging?

yes If write does not return 1 might indicate an error, it would be good to log it. so we can skip this long comment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2088003281

From serb at openjdk.org  Wed May 14 04:37:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 May 2025 04:37:54 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <lTHWCVus_F1QuH_rk-EzUlQPPTFn2P6qq4PPF11jtAk=.15a99668-cf50-4395-a75e-6120757041d2@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <lTHWCVus_F1QuH_rk-EzUlQPPTFn2P6qq4PPF11jtAk=.15a99668-cf50-4395-a75e-6120757041d2@github.com>
Message-ID: <bsOG3L7WJL2amGAwkxvMg2mcoIsJgbWPqAAu6afQVQE=.e4acac34-24c9-4d30-ac8a-a8aa8af54e71@github.com>

On Wed, 14 May 2025 04:10:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356049
>
> src/java.desktop/share/classes/javax/sound/SoundClip.java line 93:
> 
>> 91:      * Each time this method is called, the clip is restarted from the beginning.
>> 92:      */
>> 93:     public synchronized void play() {
> 
> We might want to clarify that play() and loop() are non-blocking in terms of execution but may keep the application alive if audio threads are still running.

And still do we want to have all of them synchronized? so the app may affect these methods by synchronized(soundClip)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2088012769

From serb at openjdk.org  Wed May 14 04:42:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 May 2025 04:42:52 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <bsOG3L7WJL2amGAwkxvMg2mcoIsJgbWPqAAu6afQVQE=.e4acac34-24c9-4d30-ac8a-a8aa8af54e71@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <lTHWCVus_F1QuH_rk-EzUlQPPTFn2P6qq4PPF11jtAk=.15a99668-cf50-4395-a75e-6120757041d2@github.com>
 <bsOG3L7WJL2amGAwkxvMg2mcoIsJgbWPqAAu6afQVQE=.e4acac34-24c9-4d30-ac8a-a8aa8af54e71@github.com>
Message-ID: <uRKpk8hijsqouGGurND49ScU9EBpnfY2GH_qsOJaqC0=.e3a08246-644d-484c-b930-0ec6409ab9d0@github.com>

On Wed, 14 May 2025 04:35:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/sound/SoundClip.java line 93:
>> 
>>> 91:      * Each time this method is called, the clip is restarted from the beginning.
>>> 92:      */
>>> 93:     public synchronized void play() {
>> 
>> We might want to clarify that play() and loop() are non-blocking in terms of execution but may keep the application alive if audio threads are still running.
>
> And still do we want to have all of them synchronized? so the app may affect these methods by synchronized(soundClip)?

>     * Each time this method is called, the clip is restarted from the beginning.
Note that calls within 30 ms are ignored: https://github.com/openjdk/jdk/blob/2c4e8d211a030c85488e656a9a851d10dd0f9c11/src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java#L158

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2088016451

From kizune at openjdk.org  Wed May 14 05:02:55 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 14 May 2025 05:02:55 GMT
Subject: Integrated: 8323545: java/awt/GraphicsDevice/CheckDisplayModes.java
 fails with "exit code: 133"
In-Reply-To: <_YE9ifFDv0XSJfwJXoX-TkY9OLaXlD1d7NkQWxiTJsU=.5aaa2457-1dce-4d95-be85-1e78dbb46a89@github.com>
References: <_YE9ifFDv0XSJfwJXoX-TkY9OLaXlD1d7NkQWxiTJsU=.5aaa2457-1dce-4d95-be85-1e78dbb46a89@github.com>
Message-ID: <YFffGpJCyA4gNpI705fXMH6jXewrPURHIcE5gLwrE9c=.eee1a3ee-cf6b-4c6b-8793-e054b67acb78@github.com>

On Mon, 12 May 2025 10:18:13 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> This test fails intermittently, sometimes it does not fail in half a year so i was unable to catch it myself to do any reasonable debugging. In this pull request I am adding debug output to understand at least what graphics device is connected to the test machine and which graphics mode on which device gives us problem. Next time test fails we will at least have some hint on what's going on.

This pull request has now been integrated.

Changeset: e07c65b8
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e07c65b892ecb02d6b52877508131de3a2067e23
Stats:     14 lines in 1 file changed: 12 ins; 0 del; 2 mod

8323545: java/awt/GraphicsDevice/CheckDisplayModes.java fails with "exit code: 133"

Reviewed-by: achung, serb

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

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

From ihse at openjdk.org  Wed May 14 06:35:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 06:35:56 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
 <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>
Message-ID: <12he4bTHjyqUILsl4m4lQOE7_dSLFWMgcx7812qaoZY=.f0bc7143-3bc0-432f-8a51-2bacade3e9a6@github.com>

On Tue, 13 May 2025 00:10:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
>> 
>> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
>> 
>> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.
>
> src/demo/share/jfc/CodePointIM/README.html line 5:
> 
>> 3: <head>
>> 4:   <title>README - CodePointIM</title>
>> 5:   <meta http-equiv="content-type" content="text/html; charset=utf-8">
> 
> I believe this line is equivalent to simple `<meta charset="utf-8"/>` which is widely used in java.desktop's docs.

That seems reasonable, yes. However, I'd like to keep this change to the absolute minimum. Feel free to open a separate issue for fixing this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25148#discussion_r2088152886

From ihse at openjdk.org  Wed May 14 06:35:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 06:35:57 GMT
Subject: Integrated: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <1uf8Qu09x2byR-S1kMvt4zMdBu_BKZHCvx13v-uaxYc=.9e974fe5-0125-4001-99f6-acbba3ea517d@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

This pull request has now been integrated.

Changeset: dd251599
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dd2515993bf76f424e4c56d529ae1541f55e3f8b
Stats:     794 lines in 53 files changed: 2 ins; 9 del; 783 mod

8356644: Update encoding declaration to UTF-8

Reviewed-by: prr, naoto

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

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

From serb at openjdk.org  Wed May 14 06:52:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 May 2025 06:52:55 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <12he4bTHjyqUILsl4m4lQOE7_dSLFWMgcx7812qaoZY=.f0bc7143-3bc0-432f-8a51-2bacade3e9a6@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
 <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>
 <12he4bTHjyqUILsl4m4lQOE7_dSLFWMgcx7812qaoZY=.f0bc7143-3bc0-432f-8a51-2bacade3e9a6@github.com>
Message-ID: <IpJv8SIJ2TSeGf31v4EPP7vbfL9injugtQRKbLZy1MM=.3980df30-43fb-48a2-a48b-4cafcf7352fd@github.com>

On Wed, 14 May 2025 06:32:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> That seems reasonable, yes. However, I'd like to keep this change to the absolute minimum. Feel free to open a separate issue for fixing this.

FIled: https://bugs.openjdk.org/browse/JDK-8356937

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25148#discussion_r2088181402

From dgredler at openjdk.org  Wed May 14 07:42:50 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 14 May 2025 07:42:50 GMT
Subject: RFR: 8356814: LineBreakMeasurer.nextLayout() slower than necessary
 when no break needed
In-Reply-To: <eCNglzFBXWXR00R_CTjBCr3D9lKRBArNOEOCT2McrAw=.e387b4b3-e275-4fa6-be83-0bf82daa3659@github.com>
References: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>
 <eCNglzFBXWXR00R_CTjBCr3D9lKRBArNOEOCT2McrAw=.e387b4b3-e275-4fa6-be83-0bf82daa3659@github.com>
Message-ID: <exJ561B3b9XuvAJYShay6akAiy7tcaWckntYRtDJguc=.e5869187-e09d-42e6-b0b8-e8302d257c44@github.com>

On Tue, 13 May 2025 20:49:59 GMT, Phil Race <prr at openjdk.org> wrote:

> Looks OK. Testing passes. My only concern would have been if these are mutable, but they aren't Unless something casts to a known sub-class that is mutable, but I don't know think that is the case.

It doesn't look like it, but let me know if you'd like me to make `ExtendedTextSourceLabel` final and make all the instance variables private, just to tighten things up.

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

PR Comment: https://git.openjdk.org/jdk/pull/25193#issuecomment-2879071641

From jwaters at openjdk.org  Wed May 14 11:31:59 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 14 May 2025 11:31:59 GMT
Subject: RFR: 8342869: Errors related to unused code on Windows after
 8339120 in awt
In-Reply-To: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
References: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
Message-ID: <TYyWRtItPA-JDmdNEBW-CTWNBBWkzBEMEM4C3My2itg=.394e7d00-b43f-4dad-a092-55ae432a171c@github.com>

On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
> 
> build.log on release configuration:
> 
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp:3560:39: warning: '_VKS_ALT_MASK' defined but not used [-Wunused-const-variable=]
>  3560 |                     static const UINT _VKS_ALT_MASK = 0x04;
>       |                                       ^~~~~~~~~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'void CSegTable::MakeTable()':
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1361:14: warning: typedef 'PSUBTABLE' locally defined but not used [-Wunused-local-typedefs]
>  1361 | } SUBTABLE, *PSUBTABLE;
>       |              ^~~~~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'virtual void CEUDCSegTable::Create(LPCWSTR)':
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1588:10: warning: typedef 'PHEAD' locally defined but not used [-Wunused-local-typedefs]
>  1588 | } HEAD, *PHEAD;
>       |          ^~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1595:11: warning: typedef 'PENTRY' locally defined but not used [-Wunused-local-typedefs]
>  1595 | } ENTRY, *PENTRY;
>       |           ^~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/...

Keep open

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

PR Comment: https://git.openjdk.org/jdk/pull/21655#issuecomment-2879835298

From aivanov at openjdk.org  Wed May 14 12:11:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 14 May 2025 12:11:59 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
Message-ID: <HwKf3rDD39LT_vh0XAjjD8u8k7SaSHOdiduoTsgXzLg=.eef81151-e671-4640-8c81-d0dfb4b25c9b@github.com>

On Wed, 14 May 2025 03:46:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/sound/SoundClip.java line 63:
>> 
>>> 61:     public static SoundClip createSoundClip(File file) throws IOException {
>>> 62:         if (file == null) {
>>> 63:             throw new IllegalArgumentException("file must not be null");
>> 
>> Most of the APIs in javax.sound.* throw NullPointerException for null arguments and IllegalArgumentException for other invalid parameters.
>
> it is even noticed for both subpackages, it is better to use NPE here as well:
> 
>  * Please note: In the {@code javax.sound.sampled.spi} APIs, a {@code null}
>  * reference parameter to methods is incorrect unless explicitly documented on
>  * the method as having a meaningful interpretation. Usage to the contrary is
>  * incorrect coding and may result in a run time exception either immediately or
>  * at some later time. {@code NullPointerException} is an example of typical and
>  * acceptable run time exception for such cases.

I still think `IllegalArgumentException` is better and clearer if we check the value of the parameter before proceeding to doing anything with the parameter and bail out if the parameter has an invalid value.

`NullPointerException`, on the other hand, indicates the code accessed an object but the reference was `null`. (This could occur, for example, if parameters aren't validated.)

Although both exception indicate a coding error, they have different semantics.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2088789154

From ihse at openjdk.org  Wed May 14 14:28:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 14:28:10 GMT
Subject: RFR: 8356977: UTF-8 cleanups
Message-ID: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>

I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

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

Commit messages:
 - Replace uncessary unicode characters with ASCII in instructions, and fix typo
 - Seems like typos in the comments
 - Fix unicode sequences in comments (previously missed)

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

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

From ihse at openjdk.org  Wed May 14 14:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 14:34:37 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8
Message-ID: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>

After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

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

Commit messages:
 - 8356978: Convert unicode sequences in Java source code to UTF-8

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

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

From ihse at openjdk.org  Wed May 14 15:16:18 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 15:16:18 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
Message-ID: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>

Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences.

I have checked:
* U+00A0 NO-BREAK SPACE (NBSP)
* U+202F NARROW NO-BREAK SPACE (NNBSP)
* U+2007 FIGURE SPACE
* U+2060 WORD JOINER

In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences.

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

Commit messages:
 - Use sequences for valid nbsp usage
 - Remove mistaken nbsp

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

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

From prr at openjdk.org  Wed May 14 17:01:55 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 14 May 2025 17:01:55 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
Message-ID: <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>

On Wed, 14 May 2025 15:11:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences.
> 
> I have checked:
> * U+00A0 NO-BREAK SPACE (NBSP)
> * U+202F NARROW NO-BREAK SPACE (NNBSP)
> * U+2007 FIGURE SPACE
> * U+2060 WORD JOINER
> 
> In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences.

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

> 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte :
> 38: 
> 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0:

So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991
But I think you know that ..  since you commented on the PR

The fix was done by @justin-curtis-lu and reviewed by
@naotoj so I think I'd like to get their opinion on this

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089371921

From prr at openjdk.org  Wed May 14 17:12:52 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 14 May 2025 17:12:52 GMT
Subject: RFR: 8356814: LineBreakMeasurer.nextLayout() slower than necessary
 when no break needed
In-Reply-To: <exJ561B3b9XuvAJYShay6akAiy7tcaWckntYRtDJguc=.e5869187-e09d-42e6-b0b8-e8302d257c44@github.com>
References: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>
 <eCNglzFBXWXR00R_CTjBCr3D9lKRBArNOEOCT2McrAw=.e387b4b3-e275-4fa6-be83-0bf82daa3659@github.com>
 <exJ561B3b9XuvAJYShay6akAiy7tcaWckntYRtDJguc=.e5869187-e09d-42e6-b0b8-e8302d257c44@github.com>
Message-ID: <NSuCxM9G_z2EVGf5M00UeVM3Fa-2CRHju_2I6RSS_VE=.7f8ff33b-cbe8-4e98-a1fe-0b334c8c8c96@github.com>

On Wed, 14 May 2025 07:40:07 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> > Looks OK. Testing passes. My only concern would have been if these are mutable, but they aren't Unless something casts to a known sub-class that is mutable, but I don't know think that is the case.
> 
> It doesn't look like it, but let me know if you'd like me to make `ExtendedTextSourceLabel` final and make all the instance variables private, just to tighten things up.

I don't think we need to do that. If it is done, a separate clean up PR would be better rather than adding it in here.

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

PR Comment: https://git.openjdk.org/jdk/pull/25193#issuecomment-2880960222

From jlu at openjdk.org  Wed May 14 17:21:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 14 May 2025 17:21:54 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
Message-ID: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>

On Wed, 14 May 2025 16:59:23 GMT, Phil Race <prr at openjdk.org> wrote:

>> Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences.
>> 
>> I have checked:
>> * U+00A0 NO-BREAK SPACE (NBSP)
>> * U+202F NARROW NO-BREAK SPACE (NNBSP)
>> * U+2007 FIGURE SPACE
>> * U+2060 WORD JOINER
>> 
>> In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences.
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties line 39:
> 
>> 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte :
>> 38: 
>> 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0:
> 
> So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991
> But I think you know that ..  since you commented on the PR
> 
> The fix was done by @justin-curtis-lu and reviewed by
> @naotoj so I think I'd like to get their opinion on this

For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089399946

From naoto at openjdk.org  Wed May 14 17:36:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 May 2025 17:36:51 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
Message-ID: <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>

On Wed, 14 May 2025 17:18:35 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties line 39:
>> 
>>> 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte :
>>> 38: 
>>> 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0:
>> 
>> So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991
>> But I think you know that ..  since you commented on the PR
>> 
>> The fix was done by @justin-curtis-lu and reviewed by
>> @naotoj so I think I'd like to get their opinion on this
>
> For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.)

I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089424644

From dgredler at openjdk.org  Wed May 14 17:50:08 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 14 May 2025 17:50:08 GMT
Subject: RFR: 8356966:
 java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails on Linux after
 JDK-8350203
Message-ID: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>

If the new test (`IgnoredWhitespaceTest`) runs on a system with Type1 physical fonts, it fails because the Type1 handling of ignorable whitespace characters does not match the behavior of the TrueType and macOS glyph mappers.

This PR updates the Type1 glyph mapper to follow the same rules in this area as the other glyph mappers.

It would probably be a good idea to consolidate all of this into the `CharToGlyphMapper` superclass at some point, so that we're not duplicating this handling across the subclasses, but some users are reporting failing builds and I wanted to keep the PR simple.

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

Commit messages:
 - Handle ignorable whitespace correctly with Type1 fonts

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

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

From serb at openjdk.org  Wed May 14 18:36:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 May 2025 18:36:55 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <HwKf3rDD39LT_vh0XAjjD8u8k7SaSHOdiduoTsgXzLg=.eef81151-e671-4640-8c81-d0dfb4b25c9b@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
 <HwKf3rDD39LT_vh0XAjjD8u8k7SaSHOdiduoTsgXzLg=.eef81151-e671-4640-8c81-d0dfb4b25c9b@github.com>
Message-ID: <TZaGuWgAMowQY249bB-gKPcRYEDGdYPgr_o-TH-T31M=.47698e31-16d1-4ef6-af0f-d325c9c8e65b@github.com>

On Wed, 14 May 2025 12:09:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> it is even noticed for both subpackages, it is better to use NPE here as well:
>> 
>>  * Please note: In the {@code javax.sound.sampled.spi} APIs, a {@code null}
>>  * reference parameter to methods is incorrect unless explicitly documented on
>>  * the method as having a meaningful interpretation. Usage to the contrary is
>>  * incorrect coding and may result in a run time exception either immediately or
>>  * at some later time. {@code NullPointerException} is an example of typical and
>>  * acceptable run time exception for such cases.
>
> I still think `IllegalArgumentException` is better and clearer if we check the value of the parameter before proceeding to doing anything with the parameter and bail out if the parameter has an invalid value.
> 
> `NullPointerException`, on the other hand, indicates the code accessed an object but the reference was `null`. (This could occur, for example, if parameters aren't validated.)
> 
> Although both exception indicate a coding error, they have different semantics.

I respectfully disagree for a few reasons:

>  NullPointerException, on the other hand, indicates the code accessed an object but the reference was null. (This could occur, for example, if parameters aren't validated.)

Implementation and documentation of Objects.requireNonNull including its use in our codebase and in newly added code suggests that it is intended for validating parameters before dereferencing them. This contradicts the strict separation you're implying.

Additionally as I mentioned earlier the javax.sound.** code already uses npe for null parameter checks. Introducing a mix of exception styles would reduce consistency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2089520351

From achung at openjdk.org  Wed May 14 18:50:57 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 14 May 2025 18:50:57 GMT
Subject: Integrated: 8343739: Test
 java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java failed: Wrong
 extended key code
In-Reply-To: <ubVHDLbUmS2V0etEvYlsOVr-1H6ZQxayrQTU4bXxz-o=.075cef8e-5d34-43de-8870-09e6afa4f588@github.com>
References: <ubVHDLbUmS2V0etEvYlsOVr-1H6ZQxayrQTU4bXxz-o=.075cef8e-5d34-43de-8870-09e6afa4f588@github.com>
Message-ID: <TeTll7XzwSJCJpslOGBP13RgE9vTZZHrcQQ6OHfwTiQ=.655fd192-5dba-4f74-bd9b-6db356fb9490@github.com>

On Fri, 25 Apr 2025 19:49:02 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Test was failing on Ubuntu, looks to be a synchronous error in the test so I rewrote it to improve stability.

This pull request has now been integrated.

Changeset: e91088a9
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e91088a9e8193b81a1de82d48effd8c8c0f3b45d
Stats:     5 lines in 1 file changed: 1 ins; 1 del; 3 mod

8343739: Test java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java failed: Wrong extended key code

Reviewed-by: serb, prr

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

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

From honkar at openjdk.org  Wed May 14 20:41:55 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 14 May 2025 20:41:55 GMT
Subject: RFR: 8356966:
 java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails on Linux after
 JDK-8350203
In-Reply-To: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
References: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
Message-ID: <fJ-oM1LAsWC4VvBeAxk4h-tRC4wyi_yVwwBFotnefUE=.5d4aa724-2993-42d1-8495-792c56e96387@github.com>

On Wed, 14 May 2025 17:45:54 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> If the new test (`IgnoredWhitespaceTest`) runs on a system with Type1 physical fonts, it fails because the Type1 handling of ignorable whitespace characters does not match the behavior of the TrueType and macOS glyph mappers.
> 
> This PR updates the Type1 glyph mapper to follow the same rules in this area as the other glyph mappers.
> 
> It would probably be a good idea to consolidate all of this into the `CharToGlyphMapper` superclass at some point, so that we're not duplicating this handling across the subclasses, but some users are reporting failing builds and I wanted to keep the PR simple.

Since this issue specifically occurs on some flavors of linux (RHEL,SLES) I wasn't able verify the fix.

test/jdk/java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java line 126:

> 124:                                  .replace("\t", "\\t");
> 125:             String msg = String.format("for text '%s' with font '%s': %s != %s",
> 126:                 escaped, font.getName(), r1.toString(), r2.toString());

Suggestion: you could get more details about the font using font.toString() or font.getAttributes()

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

PR Review: https://git.openjdk.org/jdk/pull/25235#pullrequestreview-2841436270
PR Review Comment: https://git.openjdk.org/jdk/pull/25235#discussion_r2089697980

From honkar at openjdk.org  Wed May 14 21:28:37 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 14 May 2025 21:28:37 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9 [v2]
In-Reply-To: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
Message-ID: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>

> The following line results in unused-result warning on linux/clang.
> 
> 
> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
> 
> 
> There are two ways to handle it 
> 
> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
> 
> 
> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html
> 
> 
> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
> 
> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.

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

  DTRACE added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25217/files
  - new: https://git.openjdk.org/jdk/pull/25217/files/f1172662..91f3d409

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

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

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

From honkar at openjdk.org  Wed May 14 21:28:37 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 14 May 2025 21:28:37 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9 [v2]
In-Reply-To: <Z8wyMfkdqQFBMEK-wLO7VLpn2DYbCmvFgDOrsHq44Go=.8401baf1-8888-4b27-b5d9-459b6f9cd99d@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
 <QzueQ7pYx9bUYK38vRL0Dkm2HL9yZ3dxyGpBZye9aBo=.f0f46590-145c-48bf-85da-509d066cc900@github.com>
 <Z8wyMfkdqQFBMEK-wLO7VLpn2DYbCmvFgDOrsHq44Go=.8401baf1-8888-4b27-b5d9-459b6f9cd99d@github.com>
Message-ID: <lD_QZoLFlFeRfcKUF6MFZ5P9UoL2ufqemyRkZEdENG4=.9dee82c3-78b2-4cd4-a64f-e4002035a59e@github.com>

On Wed, 14 May 2025 04:23:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c line 696:
>> 
>>> 694:     if (!isMainThread() && awt_pipe_inited) {
>>> 695:         if (write(AWT_WRITEPIPE, &wakeUp_char, 1) < 0) {
>>> 696:             // if block is left empty to avoid adding unused-result to
>> 
>> Does it make sense to add a trace with `DTRACE_PRINTLN*`?
>> 
>> It could be useful for debugging?
>
> yes If write does not return 1 might indicate an error, it would be good to log it. so we can skip this long comment

Updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2089778602

From dgredler at openjdk.org  Wed May 14 21:40:47 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 14 May 2025 21:40:47 GMT
Subject: RFR: 8356966:
 java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails on Linux after
 JDK-8350203 [v2]
In-Reply-To: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
References: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
Message-ID: <TIBNLsI9rDJ4N7i5nnEOAdWV4G0-3PAecFYKVWukv3I=.00857aa2-731e-4fc3-aca9-3919da1be53e@github.com>

> If the new test (`IgnoredWhitespaceTest`) runs on a system with Type1 physical fonts, it fails because the Type1 handling of ignorable whitespace characters does not match the behavior of the TrueType and macOS glyph mappers.
> 
> This PR updates the Type1 glyph mapper to follow the same rules in this area as the other glyph mappers.
> 
> It would probably be a good idea to consolidate all of this into the `CharToGlyphMapper` superclass at some point, so that we're not duplicating this handling across the subclasses, but some users are reporting failing builds and I wanted to keep the PR simple.

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

  Include additional font information in message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25235/files
  - new: https://git.openjdk.org/jdk/pull/25235/files/2c118da5..13130c4c

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

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

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

From dgredler at openjdk.org  Wed May 14 21:40:48 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 14 May 2025 21:40:48 GMT
Subject: RFR: 8356966:
 java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails on Linux after
 JDK-8350203 [v2]
In-Reply-To: <fJ-oM1LAsWC4VvBeAxk4h-tRC4wyi_yVwwBFotnefUE=.5d4aa724-2993-42d1-8495-792c56e96387@github.com>
References: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
 <fJ-oM1LAsWC4VvBeAxk4h-tRC4wyi_yVwwBFotnefUE=.5d4aa724-2993-42d1-8495-792c56e96387@github.com>
Message-ID: <UQPG4uSz9fsRvhEnoe6sRID1fVCHxjJF9qLrsIPxCr0=.03112254-9073-4c50-b246-bbce61eb22a7@github.com>

On Wed, 14 May 2025 20:38:47 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> I wasn't able replicate and verify the fix myself as I don't have specific linux flavors (RHEL,SLES) to test it .

I had to build in a clean SUSE Docker image (`registry.suse.com/suse/sle15:15.3`). Here are my notes on the steps required, if you want to try to replicate (you'll want to adjust the git repo / branch, I think):


zypper in -y wget
wget https://download.java.net/java/GA/jdk24.0.1/24a58e0e276943138bf3e963e6291ac2/9/GPL/openjdk-24.0.1_linux-x64_bin.tar.gz
zypper in -y tar
zypper in -y gzip
tar -xvzf openjdk-24.0.1_linux-x64_bin.tar.gz
wget https://builds.shipilev.net/jtreg/jtreg-7.5.1%2B1.zip
zypper in -y unzip
unzip jtreg-7.5.1+1.zip
zypper in -y git
git clone https://github.com/gredler/jdk.git
cd jdk
git checkout ignored-whitespace
zypper in -y autoconf make awk zip gcc11 gcc11-c++ alsa-devel cups-devel fontconfig-devel
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-11 20
update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-11 20
zypper in -y libX11-devel libXext-devel libXrender-devel libXrandr-devel libXtst-devel libXt-devel libXi-devel
bash configure --with-boot-jdk=/jdk-24.0.1 --with-jtreg=/jtreg
make images
../jtreg/bin/jtreg -jdk:build/linux-x86_64-server-release/images/jdk/ -w build/jtreg/work -r build/jtreg/report -verbose:all test/jdk/java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java
>> java.lang.RuntimeException: Fontconfig head is null, check your fonts or fonts configuration
zypper in -y ghostscript-fonts-std
fc-list
../jtreg/bin/jtreg -jdk:build/linux-x86_64-server-release/images/jdk/ -w build/jtreg/work -r build/jtreg/report -verbose:all test/jdk/java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java

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

PR Comment: https://git.openjdk.org/jdk/pull/25235#issuecomment-2881641220

From serb at openjdk.org  Wed May 14 22:18:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 May 2025 22:18:52 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9 [v2]
In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
 <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
Message-ID: <0uH-6ZiwZcJSccs_3Fjwh7OiHRO-PJCisDiv8Dyju8c=.22ee3992-431d-4a1d-a9e0-74dac955b6a5@github.com>

On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The following line results in unused-result warning on linux/clang.
>> 
>> 
>> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
>> 
>> 
>> There are two ways to handle it 
>> 
>> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
>> 
>> 
>> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html
>> 
>> 
>> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
>> 
>> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   DTRACE added

src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c line 695:

> 693:     static char wakeUp_char = 'p';
> 694:     if (!isMainThread() && awt_pipe_inited) {
> 695:         if (write(AWT_WRITEPIPE, &wakeUp_char, 1) < 0) {

No strong preference between write() < 0, < 1, or != 1, it depends on how strict we want to be.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2089843696

From duke at openjdk.org  Wed May 14 23:12:57 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 14 May 2025 23:12:57 GMT
Subject: Withdrawn: 8356137: GifImageDecode can produce opaque image when
 disposal method changes
In-Reply-To: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
Message-ID: <p-xnDOGY3sFjPYXVuUBkfANJtlBycbiFMk4bgUIMNwU=.6672ffd3-4130-4c68-b655-9696b0117887@github.com>

On Mon, 5 May 2025 17:07:11 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
> 
> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
> 2. The transparent pixel is non-zero
> 3. There's more than one such consecutive frame
> 
> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Wed May 14 23:12:56 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 14 May 2025 23:12:56 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v3]
In-Reply-To: <mg68N7wbejYkkcAJVbhf6NoDh5zIrm_Y2_PB7Oej5hA=.bdfccacd-e329-407f-bfd4-3172958eec43@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
 <mg68N7wbejYkkcAJVbhf6NoDh5zIrm_Y2_PB7Oej5hA=.bdfccacd-e329-407f-bfd4-3172958eec43@github.com>
Message-ID: <0-nDWHrDL6PXZdjMaAc4kGSAwS0S72_LDnvCDcmluN8=.fd91595d-d767-4b6e-9656-2b44899f1909@github.com>

On Wed, 7 May 2025 02:58:01 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
>> 
>> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
>> 2. The transparent pixel is non-zero
>> 3. There's more than one such consecutive frame
>> 
>> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.
>
> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8356120: updating (c) year
>  - 8356137: cleaning up error message

Closing for now; I want to focus on one PR at a time. I can reopen this after #25076 .

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

PR Comment: https://git.openjdk.org/jdk/pull/25044#issuecomment-2881794176

From serb at openjdk.org  Thu May 15 00:09:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 15 May 2025 00:09:52 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9 [v2]
In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
 <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
Message-ID: <LZXqYaedb2BR5HcJ9IUuHjTD_rvfL5JgBq5_g45VmIs=.565d63c5-9b64-4c71-8be5-5a505566e43f@github.com>

On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The following line results in unused-result warning on linux/clang.
>> 
>> 
>> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
>> 
>> 
>> There are two ways to handle it 
>> 
>> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
>> 
>> 
>> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html
>> 
>> 
>> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
>> 
>> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   DTRACE added

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25217#pullrequestreview-2841767253

From duke at openjdk.org  Thu May 15 00:31:31 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Thu, 15 May 2025 00:31:31 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v4]
In-Reply-To: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
Message-ID: <5Cr3SzVTw-FqqDTWkLhpzGww0_9bqgK5iapQMLMz924=.c63779b6-9b17-4f30-a17e-e97d87761c44@github.com>

> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
> 
> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
> 2. The transparent pixel is non-zero
> 3. There's more than one such consecutive frame
> 
> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.

Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision:

 - 8356137: readding transparency check at (20, 20)
 - GifComparison: fixing error message
 - GifComparison: code cleanup
 - 8356137: change package to access GifComparison
 - GifComparison: adding common helper class for gif bugs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25044/files
  - new: https://git.openjdk.org/jdk/pull/25044/files/c7072231..cfa679a8

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

  Stats: 590 lines in 4 files changed: 452 ins; 138 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25044/head:pull/25044

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

From duke at openjdk.org  Thu May 15 00:31:31 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Thu, 15 May 2025 00:31:31 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v3]
In-Reply-To: <mg68N7wbejYkkcAJVbhf6NoDh5zIrm_Y2_PB7Oej5hA=.bdfccacd-e329-407f-bfd4-3172958eec43@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
 <mg68N7wbejYkkcAJVbhf6NoDh5zIrm_Y2_PB7Oej5hA=.bdfccacd-e329-407f-bfd4-3172958eec43@github.com>
Message-ID: <1migULIogbSlLq8wO6M6kODyynhbkowNqMYSQvzsQ4w=.3339b4b7-00ea-4812-b0fa-c4edf60830a2@github.com>

On Wed, 7 May 2025 02:58:01 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
>> 
>> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
>> 2. The transparent pixel is non-zero
>> 3. There's more than one such consecutive frame
>> 
>> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.
>
> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8356120: updating (c) year
>  - 8356137: cleaning up error message

Reopening: I think this PR should come first.

I have a set of 4 tickets related to GIF problems (8356137, 8356320, 8351913, and one TBD based on incident 9078482). I wrote a helper class GifComparison that all 4 PR's can use. It compares the output of the AWT-based parser with the ImageIO parser, and it fails if there's any deviation.

Once the GIfComparison clears code review the others PRs will be only a few lines of code.

This PR can pass in isolation.
The PR for the TBD bug can pass in isolation, but it's blocked by triage (for now).
The PR for 8356320 relies on the TBD bug to pass.
The PR for 8351913 can pass in isolation, but I want to save that for last because of [this comment](https://github.com/openjdk/jdk/pull/24271#issuecomment-2831430009)

With all 4 PRs merged: I've scanned over 100 modern gifs from popular websites (like giphy, pixabay) and found the ToolkitImage renderer to be identical to ImageIO's renderer. (And I've visually inspected most of those results, too.) So I don't anticipate adding to this set of 4 issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/25044#issuecomment-2881889090

From duke at openjdk.org  Thu May 15 00:33:19 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Thu, 15 May 2025 00:33:19 GMT
Subject: RFR: 8356320: GifImageDecoder can produce wrong image when GCE
 changes transparent pixel index
In-Reply-To: <3RTnzdT8-vrt_0nq19kYPZh0-zexouw2d3FjxNY2R5Q=.53abc5a2-b5d9-4386-9c8d-36f2677dfccc@github.com>
References: <3RTnzdT8-vrt_0nq19kYPZh0-zexouw2d3FjxNY2R5Q=.53abc5a2-b5d9-4386-9c8d-36f2677dfccc@github.com>
Message-ID: <R_C1xCUamSZPHxH6ejQCQw23k1hWAl86BqK9iJM5SgQ=.540db569-fdab-4266-9f52-1e77b525b8ea@github.com>

On Wed, 7 May 2025 02:55:12 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> When a gif frame's disposal code is DISPOSAL_BGCOLOR and we're maintaining a saved image: we have to flood-fill the frame's bounds. And if the transparent pixel index changes across frames: we could sometimes flood fill the wrong value, resulting in an opaque rectangle in the output image.
> 
> (I know this looks similar to https://github.com/openjdk/jdk/pull/25044 , but if you look at the data structure of the sample gifs: they are separate problems with separate solutions.)

Closing temporarily. As noted [here](https://github.com/openjdk/jdk/pull/25044#issuecomment-2881889090): this new test case is blocked. Once incident report 9078482 clears: I can make a PR for that new ticket. Once that ticket is merged: this test will pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/25076#issuecomment-2881892650

From duke at openjdk.org  Thu May 15 00:33:19 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Thu, 15 May 2025 00:33:19 GMT
Subject: Withdrawn: 8356320: GifImageDecoder can produce wrong image when GCE
 changes transparent pixel index
In-Reply-To: <3RTnzdT8-vrt_0nq19kYPZh0-zexouw2d3FjxNY2R5Q=.53abc5a2-b5d9-4386-9c8d-36f2677dfccc@github.com>
References: <3RTnzdT8-vrt_0nq19kYPZh0-zexouw2d3FjxNY2R5Q=.53abc5a2-b5d9-4386-9c8d-36f2677dfccc@github.com>
Message-ID: <salMbz05jLuUacbFPYXLoYhXVHTT7gaxz_y9iyVlXcY=.d1c9d562-6866-4ff3-bed1-edfe886a174a@github.com>

On Wed, 7 May 2025 02:55:12 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> When a gif frame's disposal code is DISPOSAL_BGCOLOR and we're maintaining a saved image: we have to flood-fill the frame's bounds. And if the transparent pixel index changes across frames: we could sometimes flood fill the wrong value, resulting in an opaque rectangle in the output image.
> 
> (I know this looks similar to https://github.com/openjdk/jdk/pull/25044 , but if you look at the data structure of the sample gifs: they are separate problems with separate solutions.)

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu May 15 00:33:19 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Thu, 15 May 2025 00:33:19 GMT
Subject: RFR: 8356320: GifImageDecoder can produce wrong image when GCE
 changes transparent pixel index [v2]
In-Reply-To: <3RTnzdT8-vrt_0nq19kYPZh0-zexouw2d3FjxNY2R5Q=.53abc5a2-b5d9-4386-9c8d-36f2677dfccc@github.com>
References: <3RTnzdT8-vrt_0nq19kYPZh0-zexouw2d3FjxNY2R5Q=.53abc5a2-b5d9-4386-9c8d-36f2677dfccc@github.com>
Message-ID: <x3Jl4XnOdn_hRw1jwwM3bZQh1E8Brbt4B-HRF1pfI38=.b067544e-c19d-45eb-8085-ccf843f5cc46@github.com>

> When a gif frame's disposal code is DISPOSAL_BGCOLOR and we're maintaining a saved image: we have to flood-fill the frame's bounds. And if the transparent pixel index changes across frames: we could sometimes flood fill the wrong value, resulting in an opaque rectangle in the output image.
> 
> (I know this looks similar to https://github.com/openjdk/jdk/pull/25044 , but if you look at the data structure of the sample gifs: they are separate problems with separate solutions.)

Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision:

 - 8356320: fixing copy & paste typo
 - GifComparison: fixing error message
 - GifComparison: code cleanup
 - 8356320: change package to access GifComparison
 - GifComparison: adding common helper class for gif bugs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25076/files
  - new: https://git.openjdk.org/jdk/pull/25076/files/da529dcd..178c006f

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

  Stats: 586 lines in 4 files changed: 447 ins; 139 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25076.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25076/head:pull/25076

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

From serb at openjdk.org  Thu May 15 02:21:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 15 May 2025 02:21:57 GMT
Subject: RFR: 8356846: Remove unnecessary List.contains key from
 TIFFDirectory.removeTagSet
In-Reply-To: <nApYMgifHXmxIwNzIBbzcU8cLM6TBbTVVanCuQ-xj9s=.da62460b-ea8f-44bc-b750-52e93bdbe267@github.com>
References: <nApYMgifHXmxIwNzIBbzcU8cLM6TBbTVVanCuQ-xj9s=.da62460b-ea8f-44bc-b750-52e93bdbe267@github.com>
Message-ID: <e6AbDMhZIHEd6oAk4nH3zEkVG4s_T45qoQLVmpwwdnA=.6d676cfd-1326-4331-b3cc-0df47a89234e@github.com>

On Wed, 23 Apr 2025 08:38:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is no need to call List.contains before List.remove call.
> `tagSets` - is an ArrayList.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24816#pullrequestreview-2841983842

From serb at openjdk.org  Thu May 15 02:27:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 15 May 2025 02:27:50 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
Message-ID: <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>

On Wed, 14 May 2025 17:34:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.)
>
> I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them.

maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090083320

From serb at openjdk.org  Thu May 15 02:30:59 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 15 May 2025 02:30:59 GMT
Subject: RFR: 8355203: [macos] AquaButtonUI and AquaRootPaneUI repaint
 default button unnecessarily
In-Reply-To: <eDOa42oqm03QAfmkZvblWEqNNjOON6IRGOjydlFS1DU=.d6322745-65bd-4aec-acd9-9874362ddedc@github.com>
References: <FttU4YF0WFwAdOokVQgmnqQ7zh4UG2W0EzPkWeKShT8=.4ca0197f-9e1b-47ab-8c69-fdf6ac98e01d@github.com>
 <9ok7x8AADpGFkVPORr8UGxQeNb3l-5fyjngxBuQc-aY=.e0207e50-b7db-403a-8c76-7626b6b4e10e@github.com>
 <eDOa42oqm03QAfmkZvblWEqNNjOON6IRGOjydlFS1DU=.d6322745-65bd-4aec-acd9-9874362ddedc@github.com>
Message-ID: <LywSnLMw30gB8xGmtj84qTz7fxifXyrsMnA0QOqbtCs=.2870b7ab-7040-42ea-8397-23b67cf4b2b7@github.com>

On Mon, 21 Apr 2025 21:09:44 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Just to confirm, have you checked that the default button pulse has been disabled since macOS Yosemite?
>
>> have you checked that the default button pulse has been disabled since macOS Yosemite
> 
> No; I'm not sure how to check that with 100% certainty. Does anyone know of a resource to confirm how older Mac UI's looked? (I don't have access to a Mavericks machine (which should pulse) or a Yosemite machine (which should not pulse).)
> 
> Wikipedia says the pulsing was discontinued with Yosemite:
> 
> <img width="913" alt="image" src="https://github.com/user-attachments/assets/083a0945-bb85-480a-80e5-5cce7749fc15" />
> 
> I can find old videos featuring a non-pulsing default button. Here's one from 2015:
> 
> https://www.youtube.com/watch?v=tzgP3YwGwRw

@mickleness please take a look https://bugs.openjdk.org/browse/JDK-8356061

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

PR Comment: https://git.openjdk.org/jdk/pull/24778#issuecomment-2882033393

From davidalayachew at gmail.com  Thu May 15 03:01:25 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 14 May 2025 23:01:25 -0400
Subject: [External] : Re: Windows Magnifier does not work with my Swing
 applications
In-Reply-To: <CAA9v-_OGuk9UAP2xN5pi+TaZXM55patErtyW38jHX5frWG2NbQ@mail.gmail.com>
References: <CAA9v-_NR0j1aKJ-KaaN+JwH_GQay7214Q=fcFrUquurLDoLzpg@mail.gmail.com>
 <b90b84d8-64cb-47dd-acdf-98be34075c5a@oracle.com>
 <CAA9v-_PVYjQ1hB_+r85WqVUy0jfiGH8z03G6PKucDa9CRtWyEg@mail.gmail.com>
 <CAA9v-_PN0WuYYUDSfKKPKuHQ0jCsB2++s-9TcDQ5BeYDRR2zkg@mail.gmail.com>
 <CAA9v-_OKzT-gG3O3U4vEc2fneLdKNPWY2Kd=hu-8FUva3ZWqsw@mail.gmail.com>
 <d46c58f5-a25b-4b07-8d36-66885ac314ad@oracle.com>
 <CAA9v-_OG67a8ovoVP-LYJXQorn1+A9gq+6t5ye6QAyps+xrgkw@mail.gmail.com>
 <SJ2PR10MB7059510B85F8249E1AD58E91CFFD2@SJ2PR10MB7059.namprd10.prod.outlook.com>
 <CAA9v-_OGuk9UAP2xN5pi+TaZXM55patErtyW38jHX5frWG2NbQ@mail.gmail.com>
Message-ID: <CAA9v-_NBzWGLCm9L7bmysHWMiuBamt_hRMNMqcYZAEe_=i2ycQ@mail.gmail.com>

Hey, any updates on this? I understand if not, but accessibility in Swing
is important to me, even more so for the abovementioned reasons.

On Tue, Feb 11, 2025 at 5:52?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> And thank you.
>
> On Tue, Feb 11, 2025, 12:50?AM Abhishek Kumar <
> abhishek.cx.kumar at oracle.com> wrote:
>
>> Hello David,
>>
>>
>>
>> Yeah, I will evaluate if existing JDK implementation can be extended to
>> work with Windows Magnifier. I didn?t get enough time to look into this
>> issue due to other issues but this is on my to-do list. I will update my
>> findings on JBS after my analysis.
>>
>>
>>
>> Thank you for your patience.
>>
>>
>>
>> Regards,
>>
>> Abhishek
>>
>>
>>
>> *From: *David Alayachew <davidalayachew at gmail.com>
>> *Date: *Tuesday, 11 February 2025 at 4:39?AM
>> *To: *Philip Race <philip.race at oracle.com>
>> *Cc: *Abhishek Kumar <abhishek.cx.kumar at oracle.com>,
>> client-libs-dev at openjdk.org <client-libs-dev at openjdk.org>
>> *Subject: *[External] : Re: Windows Magnifier does not work with my
>> Swing applications
>>
>> Ok, ty vm. Hey Abhishek, any updates?
>>
>>
>>
>> On Mon, Feb 10, 2025, 5:50?PM Philip Race <philip.race at oracle.com> wrote:
>>
>> I think I asked Abhishek to take a look.
>>
>> -phil.
>>
>> On 2/10/25 2:41 PM, David Alayachew wrote:
>>
>> Poke.
>>
>> Any new info?
>>
>>
>>
>> On Fri, Jan 17, 2025, 8:05?AM David Alayachew <davidalayachew at gmail.com>
>> wrote:
>>
>> Hello Phil,
>>
>> Did you get any more info about this issue?
>>
>>
>>
>> On Tue, Dec 17, 2024, 11:58?AM David Alayachew <davidalayachew at gmail.com>
>> wrote:
>>
>> Thanks Phil.
>>
>>
>>
>> Yeah, I am A-OK as long as this something that is looked into and the JBS
>> Bug Report is updated with the findings. If this isn't too bad, this would
>> be a solid inclusion. But if it's not worth the effort, I just want the JBS
>> to be updated, and then I can put that as an answer for my StackOverflow
>> post.
>>
>>
>>
>> Thanks again for taking a look into this.
>>
>>
>>
>> On Tue, Dec 17, 2024 at 11:56?AM Philip Race <philip.race at oracle.com>
>> wrote:
>>
>> Perhaps .. if it is an easy fix but I do not know the specifics and the
>> evaluator of that bug wrote
>> "the magnifier cannot receive PropertyChangeEvents from Swing. This is a
>> limitation in the Window magnifier.
>> The Windows magnifier could be modified by Microsoft to receive such
>> events but the work would need to be done by Microsoft."
>>
>> then went on to add that other magnifiers do work ..
>>
>> I also don't know how tied in this would be to implementing support for
>> the Windows Accessibility API.
>>
>> Swing apps today use something called JavaAccessBridge and there are
>> screen readers out there that support it.
>>
>> It would be good to have another look at this specific issue, but I can't
>> make any promises.
>>
>> -phil.
>>
>> On 12/15/24 1:04 PM, David Alayachew wrote:
>>
>> Hello Client Libs Dev Team,
>>
>>
>>
>> My eyesite has started to deteriorate significantly, so I have been using
>> the built-in Accessibility tool called Windows (Screen) Magnifier
>> (available since Windows XP at least). It zooms in and out of the screen by
>> pressing the Windows Key and (+) or (-).
>>
>>
>>
>> This works great because, as I type stuff, the magnifier will follow my
>> text, so that I don't have to keep manually moving the magnifier whenever
>> what I type inevitably ends up off-screen (off-view?).
>>
>>
>>
>> This feature works great for basically every other application I have,
>> except my Swing apps. I make a lot of Swing apps, and I use a bunch too.
>> And this Magnifier feature that follows text does not work for any of the
>> ones I have tried.
>>
>>
>>
>> This feature does work on basically every other application I have. To
>> name a few.
>>
>>
>>
>> * Notepad++
>>
>> * WordPad
>>
>> * Firefox
>>
>> * Git Bash
>>
>>
>>
>> Here is a Bug Report referring to this problem.
>>
>>
>>
>> https://bugs.openjdk.org/browse/JDK-5079680
>>
>>
>>
>> The resolution was listed as "Future Project". Any chance that the future
>> can be now?
>>
>>
>>
>> I know that Swing is largely in maintenance mode, but if this were to get
>> added, practically ALL Swing apps would receive a significant boost in
>> accessibility. I think that's worth making some significant changes for.
>>
>>
>>
>> Finally, here is a StackOverflow post I made discussing the same subject.
>>
>>
>>
>> https://stackoverflow.com/questions/79281778
>> <https://urldefense.com/v3/__https:/stackoverflow.com/questions/79281778__;!!ACWV5N9M2RV99hQ!Ly4-UF3NKnfHKegv0u1A73-bJexJCRENPe2tHIfIZbS-UVOiAyGFuQ5ftsZLZ3nYii9HnobMtSSE1q01jU3NB22v20jnRIk$>
>>
>>
>>
>> Thank you for your time.
>>
>> David Alayachew
>>
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250514/e5fbc35d/attachment.htm>

From naoto at openjdk.org  Thu May 15 03:20:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 03:20:51 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
Message-ID: <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>

On Thu, 15 May 2025 02:25:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them.
>
> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?

Maybe, but sometimes it is intentional. CLDR has once switched normal spaces to NBSP/NNBSP for certain locales (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if it is intentional or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090140891

From duke at openjdk.org  Thu May 15 04:10:01 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Thu, 15 May 2025 04:10:01 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine
Message-ID: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>

Unfortunately I'm unable to reproduce this failure. I slowed the test down; it passes on my machine before and after this PR.

I added a little bit of logging that might also help identify what's happening.

Does anyone have any more suggestions?

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

Commit messages:
 - 8356061: additional output in the event of failure
 - 8356061: slowing down RootPaneDefaultButtonTest
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge pull request #5 from openjdk/master
 - ... and 4 more: https://git.openjdk.org/jdk/compare/5e50a584...b7270924

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

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

From abhishek.cx.kumar at oracle.com  Thu May 15 05:19:36 2025
From: abhishek.cx.kumar at oracle.com (Abhishek Kumar)
Date: Thu, 15 May 2025 05:19:36 +0000
Subject: [External] : Re: Windows Magnifier does not work with my Swing
 applications
In-Reply-To: <CAA9v-_NBzWGLCm9L7bmysHWMiuBamt_hRMNMqcYZAEe_=i2ycQ@mail.gmail.com>
References: <CAA9v-_NR0j1aKJ-KaaN+JwH_GQay7214Q=fcFrUquurLDoLzpg@mail.gmail.com>
 <b90b84d8-64cb-47dd-acdf-98be34075c5a@oracle.com>
 <CAA9v-_PVYjQ1hB_+r85WqVUy0jfiGH8z03G6PKucDa9CRtWyEg@mail.gmail.com>
 <CAA9v-_PN0WuYYUDSfKKPKuHQ0jCsB2++s-9TcDQ5BeYDRR2zkg@mail.gmail.com>
 <CAA9v-_OKzT-gG3O3U4vEc2fneLdKNPWY2Kd=hu-8FUva3ZWqsw@mail.gmail.com>
 <d46c58f5-a25b-4b07-8d36-66885ac314ad@oracle.com>
 <CAA9v-_OG67a8ovoVP-LYJXQorn1+A9gq+6t5ye6QAyps+xrgkw@mail.gmail.com>
 <SJ2PR10MB7059510B85F8249E1AD58E91CFFD2@SJ2PR10MB7059.namprd10.prod.outlook.com>
 <CAA9v-_OGuk9UAP2xN5pi+TaZXM55patErtyW38jHX5frWG2NbQ@mail.gmail.com>
 <CAA9v-_NBzWGLCm9L7bmysHWMiuBamt_hRMNMqcYZAEe_=i2ycQ@mail.gmail.com>
Message-ID: <SJ2PR10MB7059FC939F6FAC7F96C6835BCF90A@SJ2PR10MB7059.namprd10.prod.outlook.com>

Hello David,

I didn?t get enough time to investigate it further due to other priority work. But I will try to look into this issue ASAP.

Regards,
Abhishek

From: David Alayachew <davidalayachew at gmail.com>
Date: Thursday, 15 May 2025 at 8:32?AM
To: Abhishek Kumar <abhishek.cx.kumar at oracle.com>
Cc: Philip Race <philip.race at oracle.com>, Ajit Ghaisas <ajit.ghaisas at oracle.com>, client-libs-dev at openjdk.org <client-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Windows Magnifier does not work with my Swing applications
Hey, any updates on this? I understand if not, but accessibility in Swing is important to me, even more so for the abovementioned reasons.

On Tue, Feb 11, 2025 at 5:52?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:

And thank you.

On Tue, Feb 11, 2025, 12:50?AM Abhishek Kumar <abhishek.cx.kumar at oracle.com<mailto:abhishek.cx.kumar at oracle.com>> wrote:
Hello David,

Yeah, I will evaluate if existing JDK implementation can be extended to work with Windows Magnifier. I didn?t get enough time to look into this issue due to other issues but this is on my to-do list. I will update my findings on JBS after my analysis.

Thank you for your patience.

Regards,
Abhishek

From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Date: Tuesday, 11 February 2025 at 4:39?AM
To: Philip Race <philip.race at oracle.com<mailto:philip.race at oracle.com>>
Cc: Abhishek Kumar <abhishek.cx.kumar at oracle.com<mailto:abhishek.cx.kumar at oracle.com>>, client-libs-dev at openjdk.org<mailto:client-libs-dev at openjdk.org> <client-libs-dev at openjdk.org<mailto:client-libs-dev at openjdk.org>>
Subject: [External] : Re: Windows Magnifier does not work with my Swing applications

Ok, ty vm. Hey Abhishek, any updates?

On Mon, Feb 10, 2025, 5:50?PM Philip Race <philip.race at oracle.com<mailto:philip.race at oracle.com>> wrote:
I think I asked Abhishek to take a look.

-phil.
On 2/10/25 2:41 PM, David Alayachew wrote:

Poke.

Any new info?

On Fri, Jan 17, 2025, 8:05?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:

Hello Phil,

Did you get any more info about this issue?

On Tue, Dec 17, 2024, 11:58?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:
Thanks Phil.

Yeah, I am A-OK as long as this something that is looked into and the JBS Bug Report is updated with the findings. If this isn't too bad, this would be a solid inclusion. But if it's not worth the effort, I just want the JBS to be updated, and then I can put that as an answer for my StackOverflow post.

Thanks again for taking a look into this.

On Tue, Dec 17, 2024 at 11:56?AM Philip Race <philip.race at oracle.com<mailto:philip.race at oracle.com>> wrote:
Perhaps .. if it is an easy fix but I do not know the specifics and the evaluator of that bug wrote
"the magnifier cannot receive PropertyChangeEvents from Swing. This is a limitation in the Window magnifier.
The Windows magnifier could be modified by Microsoft to receive such events but the work would need to be done by Microsoft."

then went on to add that other magnifiers do work ..

I also don't know how tied in this would be to implementing support for the Windows Accessibility API.

Swing apps today use something called JavaAccessBridge and there are screen readers out there that support it.

It would be good to have another look at this specific issue, but I can't make any promises.

-phil.
On 12/15/24 1:04 PM, David Alayachew wrote:
Hello Client Libs Dev Team,

My eyesite has started to deteriorate significantly, so I have been using the built-in Accessibility tool called Windows (Screen) Magnifier (available since Windows XP at least). It zooms in and out of the screen by pressing the Windows Key and (+) or (-).

This works great because, as I type stuff, the magnifier will follow my text, so that I don't have to keep manually moving the magnifier whenever what I type inevitably ends up off-screen (off-view?).

This feature works great for basically every other application I have, except my Swing apps. I make a lot of Swing apps, and I use a bunch too. And this Magnifier feature that follows text does not work for any of the ones I have tried.

This feature does work on basically every other application I have. To name a few.

* Notepad++
* WordPad
* Firefox
* Git Bash

Here is a Bug Report referring to this problem.

https://bugs.openjdk.org/browse/JDK-5079680

The resolution was listed as "Future Project". Any chance that the future can be now?

I know that Swing is largely in maintenance mode, but if this were to get added, practically ALL Swing apps would receive a significant boost in accessibility. I think that's worth making some significant changes for.

Finally, here is a StackOverflow post I made discussing the same subject.

https://stackoverflow.com/questions/79281778<https://urldefense.com/v3/__https:/stackoverflow.com/questions/79281778__;!!ACWV5N9M2RV99hQ!Ly4-UF3NKnfHKegv0u1A73-bJexJCRENPe2tHIfIZbS-UVOiAyGFuQ5ftsZLZ3nYii9HnobMtSSE1q01jU3NB22v20jnRIk$>

Thank you for your time.
David Alayachew


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250515/17f5c0c8/attachment-0001.htm>

From mbaesken at openjdk.org  Thu May 15 07:37:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 15 May 2025 07:37:56 GMT
Subject: RFR: 8356966:
 java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails on Linux after
 JDK-8350203 [v2]
In-Reply-To: <TIBNLsI9rDJ4N7i5nnEOAdWV4G0-3PAecFYKVWukv3I=.00857aa2-731e-4fc3-aca9-3919da1be53e@github.com>
References: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
 <TIBNLsI9rDJ4N7i5nnEOAdWV4G0-3PAecFYKVWukv3I=.00857aa2-731e-4fc3-aca9-3919da1be53e@github.com>
Message-ID: <R8Kwq1ZAdeXf_bCL-s06DLWeQOh5vrJFqdCsSGYMMyk=.2b4bea5a-b349-49f4-b533-ce3c63328c85@github.com>

On Wed, 14 May 2025 21:40:47 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> If the new test (`IgnoredWhitespaceTest`) runs on a system with Type1 physical fonts, it fails because the Type1 handling of ignorable whitespace characters does not match the behavior of the TrueType and macOS glyph mappers.
>> 
>> This PR updates the Type1 glyph mapper to follow the same rules in this area as the other glyph mappers.
>> 
>> It would probably be a good idea to consolidate all of this into the `CharToGlyphMapper` superclass at some point, so that we're not duplicating this handling across the subclasses, but some users are reporting failing builds and I wanted to keep the PR simple.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include additional font information in message

I added your PR to our build/test queue, let's see if it fixes the  issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/25235#issuecomment-2882856563

From aturbanov at openjdk.org  Thu May 15 08:00:00 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 15 May 2025 08:00:00 GMT
Subject: Integrated: 8356843: Avoid redundant HashMap.get to obtain old value
 in Toolkit.setDesktopProperty
In-Reply-To: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
References: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
Message-ID: <NHMtTO5ypUDAjqyyVCgcdoyO5nXKb4yXYQfpNXuX2nY=.6fff38e8-b2e5-447c-a11f-547e2c0415e6@github.com>

On Wed, 16 Apr 2025 14:48:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> To obtain previous value of `HashMap` we can use result of `.put` call. In this case we can avoid redundant `.get` call.

This pull request has now been integrated.

Changeset: e557b695
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e557b6956bdf9b0d89ad69427c7b4a97a65868ea
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8356843: Avoid redundant HashMap.get to obtain old value in Toolkit.setDesktopProperty

Reviewed-by: aivanov, serb

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

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

From davidalayachew at gmail.com  Thu May 15 08:45:25 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 15 May 2025 04:45:25 -0400
Subject: [External] : Re: Windows Magnifier does not work with my Swing
 applications
In-Reply-To: <SJ2PR10MB7059FC939F6FAC7F96C6835BCF90A@SJ2PR10MB7059.namprd10.prod.outlook.com>
References: <CAA9v-_NR0j1aKJ-KaaN+JwH_GQay7214Q=fcFrUquurLDoLzpg@mail.gmail.com>
 <b90b84d8-64cb-47dd-acdf-98be34075c5a@oracle.com>
 <CAA9v-_PVYjQ1hB_+r85WqVUy0jfiGH8z03G6PKucDa9CRtWyEg@mail.gmail.com>
 <CAA9v-_PN0WuYYUDSfKKPKuHQ0jCsB2++s-9TcDQ5BeYDRR2zkg@mail.gmail.com>
 <CAA9v-_OKzT-gG3O3U4vEc2fneLdKNPWY2Kd=hu-8FUva3ZWqsw@mail.gmail.com>
 <d46c58f5-a25b-4b07-8d36-66885ac314ad@oracle.com>
 <CAA9v-_OG67a8ovoVP-LYJXQorn1+A9gq+6t5ye6QAyps+xrgkw@mail.gmail.com>
 <SJ2PR10MB7059510B85F8249E1AD58E91CFFD2@SJ2PR10MB7059.namprd10.prod.outlook.com>
 <CAA9v-_OGuk9UAP2xN5pi+TaZXM55patErtyW38jHX5frWG2NbQ@mail.gmail.com>
 <CAA9v-_NBzWGLCm9L7bmysHWMiuBamt_hRMNMqcYZAEe_=i2ycQ@mail.gmail.com>
 <SJ2PR10MB7059FC939F6FAC7F96C6835BCF90A@SJ2PR10MB7059.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_PuV+u_Yd-hEVfZ5rLk94=Yzd1yMADUEuoGTrGTmDyKrw@mail.gmail.com>

Understood. Ty vm.

On Thu, May 15, 2025, 1:19?AM Abhishek Kumar <abhishek.cx.kumar at oracle.com>
wrote:

> Hello David,
>
>
>
> I didn?t get enough time to investigate it further due to other priority
> work. But I will try to look into this issue ASAP.
>
>
>
> Regards,
>
> Abhishek
>
>
>
> *From: *David Alayachew <davidalayachew at gmail.com>
> *Date: *Thursday, 15 May 2025 at 8:32?AM
> *To: *Abhishek Kumar <abhishek.cx.kumar at oracle.com>
> *Cc: *Philip Race <philip.race at oracle.com>, Ajit Ghaisas <
> ajit.ghaisas at oracle.com>, client-libs-dev at openjdk.org <
> client-libs-dev at openjdk.org>
> *Subject: *Re: [External] : Re: Windows Magnifier does not work with my
> Swing applications
>
> Hey, any updates on this? I understand if not, but accessibility in Swing
> is important to me, even more so for the abovementioned reasons.
>
>
>
> On Tue, Feb 11, 2025 at 5:52?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
> And thank you.
>
>
>
> On Tue, Feb 11, 2025, 12:50?AM Abhishek Kumar <
> abhishek.cx.kumar at oracle.com> wrote:
>
> Hello David,
>
>
>
> Yeah, I will evaluate if existing JDK implementation can be extended to
> work with Windows Magnifier. I didn?t get enough time to look into this
> issue due to other issues but this is on my to-do list. I will update my
> findings on JBS after my analysis.
>
>
>
> Thank you for your patience.
>
>
>
> Regards,
>
> Abhishek
>
>
>
> *From: *David Alayachew <davidalayachew at gmail.com>
> *Date: *Tuesday, 11 February 2025 at 4:39?AM
> *To: *Philip Race <philip.race at oracle.com>
> *Cc: *Abhishek Kumar <abhishek.cx.kumar at oracle.com>,
> client-libs-dev at openjdk.org <client-libs-dev at openjdk.org>
> *Subject: *[External] : Re: Windows Magnifier does not work with my Swing
> applications
>
> Ok, ty vm. Hey Abhishek, any updates?
>
>
>
> On Mon, Feb 10, 2025, 5:50?PM Philip Race <philip.race at oracle.com> wrote:
>
> I think I asked Abhishek to take a look.
>
> -phil.
>
> On 2/10/25 2:41 PM, David Alayachew wrote:
>
> Poke.
>
> Any new info?
>
>
>
> On Fri, Jan 17, 2025, 8:05?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
> Hello Phil,
>
> Did you get any more info about this issue?
>
>
>
> On Tue, Dec 17, 2024, 11:58?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
> Thanks Phil.
>
>
>
> Yeah, I am A-OK as long as this something that is looked into and the JBS
> Bug Report is updated with the findings. If this isn't too bad, this would
> be a solid inclusion. But if it's not worth the effort, I just want the JBS
> to be updated, and then I can put that as an answer for my StackOverflow
> post.
>
>
>
> Thanks again for taking a look into this.
>
>
>
> On Tue, Dec 17, 2024 at 11:56?AM Philip Race <philip.race at oracle.com>
> wrote:
>
> Perhaps .. if it is an easy fix but I do not know the specifics and the
> evaluator of that bug wrote
> "the magnifier cannot receive PropertyChangeEvents from Swing. This is a
> limitation in the Window magnifier.
> The Windows magnifier could be modified by Microsoft to receive such
> events but the work would need to be done by Microsoft."
>
> then went on to add that other magnifiers do work ..
>
> I also don't know how tied in this would be to implementing support for
> the Windows Accessibility API.
>
> Swing apps today use something called JavaAccessBridge and there are
> screen readers out there that support it.
>
> It would be good to have another look at this specific issue, but I can't
> make any promises.
>
> -phil.
>
> On 12/15/24 1:04 PM, David Alayachew wrote:
>
> Hello Client Libs Dev Team,
>
>
>
> My eyesite has started to deteriorate significantly, so I have been using
> the built-in Accessibility tool called Windows (Screen) Magnifier
> (available since Windows XP at least). It zooms in and out of the screen by
> pressing the Windows Key and (+) or (-).
>
>
>
> This works great because, as I type stuff, the magnifier will follow my
> text, so that I don't have to keep manually moving the magnifier whenever
> what I type inevitably ends up off-screen (off-view?).
>
>
>
> This feature works great for basically every other application I have,
> except my Swing apps. I make a lot of Swing apps, and I use a bunch too.
> And this Magnifier feature that follows text does not work for any of the
> ones I have tried.
>
>
>
> This feature does work on basically every other application I have. To
> name a few.
>
>
>
> * Notepad++
>
> * WordPad
>
> * Firefox
>
> * Git Bash
>
>
>
> Here is a Bug Report referring to this problem.
>
>
>
> https://bugs.openjdk.org/browse/JDK-5079680
>
>
>
> The resolution was listed as "Future Project". Any chance that the future
> can be now?
>
>
>
> I know that Swing is largely in maintenance mode, but if this were to get
> added, practically ALL Swing apps would receive a significant boost in
> accessibility. I think that's worth making some significant changes for.
>
>
>
> Finally, here is a StackOverflow post I made discussing the same subject.
>
>
>
> https://stackoverflow.com/questions/79281778
> <https://urldefense.com/v3/__https:/stackoverflow.com/questions/79281778__;!!ACWV5N9M2RV99hQ!Ly4-UF3NKnfHKegv0u1A73-bJexJCRENPe2tHIfIZbS-UVOiAyGFuQ5ftsZLZ3nYii9HnobMtSSE1q01jU3NB22v20jnRIk$>
>
>
>
> Thank you for your time.
>
> David Alayachew
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250515/217c1871/attachment-0001.htm>

From abhiscxk at openjdk.org  Thu May 15 08:51:52 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 15 May 2025 08:51:52 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently
In-Reply-To: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
Message-ID: <AiN8sRdyx85DmffRjcmTqBG-o8INUUMzlxvnrrEwcoA=.91159761-a31f-43ce-980e-b611dae10c12@github.com>

On Mon, 12 May 2025 13:40:06 GMT, Anass Baya <abaya at openjdk.org> wrote:

>However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt.
This causes the test to proceed immediately to the validation step:
if (fd.isVisible()) {
throw new RuntimeException("File Dialog is not closed");

I don't see the existing code ignores the second attempt, that is due to longer delay put after the robot operations.
You can add print statements and observe the behavior.

However, I agree the countdown latch should be initialize to 2 to behave correctly.
}

Other enhancements look good as threads are not required to verify the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/25184#issuecomment-2883052617
PR Comment: https://git.openjdk.org/jdk/pull/25184#issuecomment-2883059066

From abhiscxk at openjdk.org  Thu May 15 09:16:52 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 15 May 2025 09:16:52 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently
In-Reply-To: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
Message-ID: <D16HeMCf9v1pdIVZSkziNmso3JBU_JklAEb9NbswFlM=.665102ed-d628-44f6-998a-f2bd8ef9d9ac@github.com>

On Mon, 12 May 2025 13:40:06 GMT, Anass Baya <abaya at openjdk.org> wrote:

> **Analysis :**
> 
> Whether the test passes on the main line or fails, the behavior is still incorrect.
> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly.
> 
> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt.
> 
> This causes the test to proceed immediately to the validation step:
> 
> if (fd.isVisible()) {
>     throw new RuntimeException("File Dialog is not closed");
> }
> 
> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet)
> 
> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation.
> 
> **Proposed fix:**
> 
> set the CountDownLatch to 2
> 
> **Proposed enhancements :**
> 
> Remove unnecessary threads (Thread and Thread-2)
> Properly handle delays and robot.waitForIdle()
> Avoid indefinite blocking on latch.await()
> 
> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds
> 
> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details

Tested updated test on JDK1.6.0_25 and JDK1.6.0_29 and I don't see any behavior difference.
[JDK-5097243](https://bugs.openjdk.org/browse/JDK-5097243) says that issue is resolved in b29.

Did you verify the test as per [JDK-5097243](https://bugs.openjdk.org/browse/JDK-5097243) ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25184#issuecomment-2883123277

From ihse at openjdk.org  Thu May 15 09:19:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 May 2025 09:19:53 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
 <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
Message-ID: <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>

On Thu, 15 May 2025 03:18:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?
>
> Maybe, but sometimes it is intentional. CLDR has once switched normal spaces to NBSP/NNBSP for certain locales (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if it is intentional or not.

> So, this exactly reverses what was done in the fix for JDK-8301991

No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences.

This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space.

Technically, it might be that some of these lines in the properties files are reversals of JDK-8301991, but that's just basically coincidence.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090692617

From ihse at openjdk.org  Thu May 15 09:19:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 May 2025 09:19:53 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
 <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
 <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>
Message-ID: <bffWy8H4d6xnje0Gz_jIyv5jPBMuqp7S-iBFZTioTng=.7ee33246-76c2-470f-b608-894b5ba93988@github.com>

On Thu, 15 May 2025 09:16:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Maybe, but sometimes it is intentional. CLDR has once switched normal spaces to NBSP/NNBSP for certain locales (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if it is intentional or not.
>
>> So, this exactly reverses what was done in the fix for JDK-8301991
> 
> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences.
> 
> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space.
> 
> Technically, it might be that some of these lines in the properties files are reversals of JDK-8301991, but that's just basically coincidence.

> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?

That seems unlikely. The pattern is used consistently in the French translations, where `Foo:` in the original is replaced with `Foo :` with a non-breaking space. I guess it is a French orthographic rule to have a space before the colon, and I understand why it really must be non-breaking in that case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090695445

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <ExI4OcZ4H03w2Kmpe35WuEynczPvNAcXjCFY4cd6ldg=.1be29db4-e6a7-4376-93d9-94c05587c721@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

After an offline discussion, we agreed to wait a bit with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2883137218

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: Withdrawn: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <LrGk5ztc6aRY4EQjv-mVBVaNIVBhvjY-SQD1ZkUD5d4=.dba136cb-acc9-4d18-9112-41f62464a65f@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

This pull request has been closed without being integrated.

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

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

From abhiscxk at openjdk.org  Thu May 15 10:44:51 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 15 May 2025 10:44:51 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently
In-Reply-To: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
Message-ID: <dpjENr1rTwNPVb7IA5DSD57QSLAh3ifS_L8G-pUJ5rE=.ca31dc19-8fee-4daa-a5ae-f056b3297224@github.com>

On Mon, 12 May 2025 13:40:06 GMT, Anass Baya <abaya at openjdk.org> wrote:

> **Analysis :**
> 
> Whether the test passes on the main line or fails, the behavior is still incorrect.
> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly.
> 
> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt.
> 
> This causes the test to proceed immediately to the validation step:
> 
> if (fd.isVisible()) {
>     throw new RuntimeException("File Dialog is not closed");
> }
> 
> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet)
> 
> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation.
> 
> **Proposed fix:**
> 
> set the CountDownLatch to 2
> 
> **Proposed enhancements :**
> 
> Remove unnecessary threads (Thread and Thread-2)
> Properly handle delays and robot.waitForIdle()
> Avoid indefinite blocking on latch.await()
> 
> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds
> 
> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details

test/jdk/ProblemList.txt line 819:

> 817: java/awt/TrayIcon/DragEventSource/DragEventSource.java 8252242 macosx-all
> 818: java/awt/FileDialog/DefaultFocusOwner/DefaultFocusOwner.java 7187728 macosx-all,linux-all
> 819: java/awt/FileDialog/DoubleActionESC.java GTKFileDialog linux-all

For problem listing this test, you need to add the bug-id [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981)
Suggestion:

java/awt/FileDialog/DoubleActionESC.java 8356981 linux-all

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2090875926

From rgiulietti at openjdk.org  Thu May 15 12:35:51 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 15 May 2025 12:35:51 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <bffWy8H4d6xnje0Gz_jIyv5jPBMuqp7S-iBFZTioTng=.7ee33246-76c2-470f-b608-894b5ba93988@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
 <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
 <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>
 <bffWy8H4d6xnje0Gz_jIyv5jPBMuqp7S-iBFZTioTng=.7ee33246-76c2-470f-b608-894b5ba93988@github.com>
Message-ID: <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com>

On Thu, 15 May 2025 09:17:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> So, this exactly reverses what was done in the fix for JDK-8301991
>> 
>> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences.
>> 
>> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space.
>> 
>> Technically, it might be that some of these lines in the properties files are reversals of JDK-8301991, but that's just basically coincidence.
>
>> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?
> 
> That seems unlikely. The pattern is used consistently in the French translations, where `Foo:` in the original is replaced with `Foo :` with a non-breaking space. I guess it is a French orthographic rule to have a space before the colon, and I understand why it really must be non-breaking in that case.

FYI, the style guide for France [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France):

- U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark, and exclamation mark.
- U+00A0 (No-Break Space NBSP) preceding colon.

Similar conventions are used in other French speaking countries.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2091068610

From abaya at openjdk.org  Thu May 15 13:51:07 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 15 May 2025 13:51:07 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v2]
In-Reply-To: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
Message-ID: <iNjn5dg1IjU_fT_ajdxgdO5iuk030EZtkrPT34_wjFs=.4e8c3708-36fc-4bcc-9f70-a3779416b501@github.com>

> **Analysis :**
> 
> Whether the test passes on the main line or fails, the behavior is still incorrect.
> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly.
> 
> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt.
> 
> This causes the test to proceed immediately to the validation step:
> 
> if (fd.isVisible()) {
>     throw new RuntimeException("File Dialog is not closed");
> }
> 
> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet)
> 
> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation.
> 
> **Proposed fix:**
> 
> set the CountDownLatch to 2
> 
> **Proposed enhancements :**
> 
> Remove unnecessary threads (Thread and Thread-2)
> Properly handle delays and robot.waitForIdle()
> Avoid indefinite blocking on latch.await()
> 
> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds
> 
> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details

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

  Update test/jdk/ProblemList.txt
  
  Co-authored-by: Abhishek Kumar <abhishek.cx.kumar at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25184/files
  - new: https://git.openjdk.org/jdk/pull/25184/files/a8ca48e8..0e234a54

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

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

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

From abaya at openjdk.org  Thu May 15 14:26:57 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 15 May 2025 14:26:57 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently
In-Reply-To: <D16HeMCf9v1pdIVZSkziNmso3JBU_JklAEb9NbswFlM=.665102ed-d628-44f6-998a-f2bd8ef9d9ac@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
 <D16HeMCf9v1pdIVZSkziNmso3JBU_JklAEb9NbswFlM=.665102ed-d628-44f6-998a-f2bd8ef9d9ac@github.com>
Message-ID: <GBelvNQueR6l_g6xHHyDyc-tvd4d5Baii3kqkoeGmnE=.37b41ba7-efaa-41c8-b14f-70a89846b8b5@github.com>

On Thu, 15 May 2025 09:12:36 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> **Analysis :**
>> 
>> Whether the test passes on the main line or fails, the behavior is still incorrect.
>> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly.
>> 
>> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt.
>> 
>> This causes the test to proceed immediately to the validation step:
>> 
>> if (fd.isVisible()) {
>>     throw new RuntimeException("File Dialog is not closed");
>> }
>> 
>> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet)
>> 
>> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation.
>> 
>> **Proposed fix:**
>> 
>> set the CountDownLatch to 2
>> 
>> **Proposed enhancements :**
>> 
>> Remove unnecessary threads (Thread and Thread-2)
>> Properly handle delays and robot.waitForIdle()
>> Avoid indefinite blocking on latch.await()
>> 
>> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds
>> 
>> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details
>
> Ran updated test on JDK1.6.0_25 and JDK1.6.0_29 and I don't see any behavior difference and the test passes always on my local machine (Ubuntu 22.04). File dialog opened seems a XToolKit based dialog not the GTK based dialog.
> 
> [JDK-5097243](https://bugs.openjdk.org/browse/JDK-5097243) says that issue is resolved in b29.
> So, test should **fail for b25** and **pass for b29**
> 
> Did you verify the test as per [JDK-5097243](https://bugs.openjdk.org/browse/JDK-5097243) ?

Hello @kumarabhi006,
Thank you for your review.

Did you try to reproduce the bug manually first with b25 before proceeding with the automated test ?
>From my side, I proceed that way: I revert the fix on the mainline, the test fails 20/20 times.
Then, when I reapply the fix, the test passes 20/20

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

PR Comment: https://git.openjdk.org/jdk/pull/25184#issuecomment-2884009898

From abhiscxk at openjdk.org  Thu May 15 15:20:51 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 15 May 2025 15:20:51 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently
In-Reply-To: <GBelvNQueR6l_g6xHHyDyc-tvd4d5Baii3kqkoeGmnE=.37b41ba7-efaa-41c8-b14f-70a89846b8b5@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
 <D16HeMCf9v1pdIVZSkziNmso3JBU_JklAEb9NbswFlM=.665102ed-d628-44f6-998a-f2bd8ef9d9ac@github.com>
 <GBelvNQueR6l_g6xHHyDyc-tvd4d5Baii3kqkoeGmnE=.37b41ba7-efaa-41c8-b14f-70a89846b8b5@github.com>
Message-ID: <b0RkK8aNDmKzrRPoF2j2S1tMo3VUFstHXKb0rkK2TmE=.2b52c88f-c491-4dac-a1d9-3d84e268c184@github.com>

On Thu, 15 May 2025 14:24:36 GMT, Anass Baya <abaya at openjdk.org> wrote:

> Did you try to reproduce the bug manually first with b25 before proceeding with the automated test ?

Yes, I tried with the manual applet test with b25 and b29.
There is an exception thrown (related with security permission) for the first time whenever Show File Dialog button is clicked but on next click File Dialog is shown and it's getting closed on `ESC` press.

The behavior is same for b25 and b29 both.

For automated test, it's same behavior and there is no exception thrown.
Debug prints for b25 and b29:

     Show File Dialog
     Set File Dialog Visible
     Press ESC Button
     Before latch countDown : 2
     After latch countDown : 1
     Show File Dialog
     Set File Dialog Visible
     Press ESC Button
     Before latch countDown : 1
     After latch countDown : 0

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

PR Comment: https://git.openjdk.org/jdk/pull/25184#issuecomment-2884210888

From abaya at openjdk.org  Thu May 15 15:32:53 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 15 May 2025 15:32:53 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently
In-Reply-To: <b0RkK8aNDmKzrRPoF2j2S1tMo3VUFstHXKb0rkK2TmE=.2b52c88f-c491-4dac-a1d9-3d84e268c184@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
 <D16HeMCf9v1pdIVZSkziNmso3JBU_JklAEb9NbswFlM=.665102ed-d628-44f6-998a-f2bd8ef9d9ac@github.com>
 <GBelvNQueR6l_g6xHHyDyc-tvd4d5Baii3kqkoeGmnE=.37b41ba7-efaa-41c8-b14f-70a89846b8b5@github.com>
 <b0RkK8aNDmKzrRPoF2j2S1tMo3VUFstHXKb0rkK2TmE=.2b52c88f-c491-4dac-a1d9-3d84e268c184@github.com>
Message-ID: <EMUsox94T_KZ8YI_G7C9PPMHby11CTHDbPPmEfVO1Vg=.cfe5e1d7-dfa7-481a-925c-8d38927e6535@github.com>

On Thu, 15 May 2025 15:17:47 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Hello @kumarabhi006,
>> Thank you for your review.
>> 
>> Did you try to reproduce the bug manually first with b25 before proceeding with the automated test ?
>> From my side, I proceed that way: I revert the fix on the mainline, the test fails 20/20 times.
>> Then, when I reapply the fix, the test passes 20/20
>
>> Did you try to reproduce the bug manually first with b25 before proceeding with the automated test ?
> 
> Yes, I tried with the manual applet test with b25 and b29.
> There is an exception thrown (related with security permission) for the first time whenever Show File Dialog button is clicked but on next click File Dialog is shown and it's getting closed on `ESC` press (Behaves same for repeat operations).
> 
> The behavior is same for b25 and b29 both.
> 
> For automated test, it's same behavior and there is no exception thrown.
> Debug prints for b25 and b29:
> 
>      Show File Dialog
>      Set File Dialog Visible
>      Press ESC Button
>      Before latch countDown : 2
>      After latch countDown : 1
>      Show File Dialog
>      Set File Dialog Visible
>      Press ESC Button
>      Before latch countDown : 1
>      After latch countDown : 0

@kumarabhi006 
As I understand, you're not able to reproduce the issue with b25( the version that doent include the fix), even when testing manually. So it's unclear whether the automated test is actually effective since you are not reproducing the issue manually

As I mentioned earlier, to check the test's effectiveness, I reverted the fix on the mainline ? and the test failed 20 out of 20 times. Then, when I reapplied the fix, the test passed 20 out of 20 times.

Maybe you could try running the test in a loop. According to [JDK-5097243](https://bugs.openjdk.org/browse/JDK-5097243), the issue reproduction is intermittent

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

PR Comment: https://git.openjdk.org/jdk/pull/25184#issuecomment-2884250541

From kcr at openjdk.org  Thu May 15 15:42:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 May 2025 15:42:58 GMT
Subject: RFR: 8332947: [macos] OpenURIHandler events not received when AWT
 is embedded in another toolkit [v7]
In-Reply-To: <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
Message-ID: <KVrKBCKPkqFBMMkk7GT4Ijj8wTTP_5f0E7LBXEsLlX0=.c66e879a-1d14-48da-875c-f0760a0671bc@github.com>

On Wed, 7 May 2025 16:51:30 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> JavaFX Pull Request: https://github.com/openjdk/jfx/pull/1755
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

LGTM. All testing complete.

NOTE: The order of integration of the two PRs (AWT and JavaFX) doesn't matter. However, taking one without the other will be ineffective, so wait for both PRs to be approved before integrating either of them.

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

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/24379#pullrequestreview-2844212594

From aivanov at openjdk.org  Thu May 15 16:16:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 May 2025 16:16:57 GMT
Subject: RFR: 8356966:
 java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails on Linux after
 JDK-8350203 [v2]
In-Reply-To: <TIBNLsI9rDJ4N7i5nnEOAdWV4G0-3PAecFYKVWukv3I=.00857aa2-731e-4fc3-aca9-3919da1be53e@github.com>
References: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
 <TIBNLsI9rDJ4N7i5nnEOAdWV4G0-3PAecFYKVWukv3I=.00857aa2-731e-4fc3-aca9-3919da1be53e@github.com>
Message-ID: <v8zAFvFci1go5zapplkfkgkTIkZBACTcsH0CkLUCn4U=.4a30c586-5dec-48ce-b6b2-7fbb15e74fe7@github.com>

On Wed, 14 May 2025 21:40:47 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> If the new test (`IgnoredWhitespaceTest`) runs on a system with Type1 physical fonts, it fails because the Type1 handling of ignorable whitespace characters does not match the behavior of the TrueType and macOS glyph mappers.
>> 
>> This PR updates the Type1 glyph mapper to follow the same rules in this area as the other glyph mappers.
>> 
>> It would probably be a good idea to consolidate all of this into the `CharToGlyphMapper` superclass at some point, so that we're not duplicating this handling across the subclasses, but some users are reporting failing builds and I wanted to keep the PR simple.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include additional font information in message

Looks good to me.
I didn't try to reproduce the problem. Let's wait for @MBaesken test results.

test/jdk/java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java line 1:

> 1: /*

Add 8356966 to the `@bug` tag in the test.

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25235#pullrequestreview-2844313205
PR Review Comment: https://git.openjdk.org/jdk/pull/25235#discussion_r2091546737

From honkar at openjdk.org  Thu May 15 16:23:55 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 15 May 2025 16:23:55 GMT
Subject: RFR: 8332947: [macos] OpenURIHandler events not received when AWT
 is embedded in another toolkit [v7]
In-Reply-To: <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
Message-ID: <v_AWwgsQPYRRzziDuqShRy6DNGSC4U-lEGBbSZAlciQ=.7afe9be7-26bb-406a-8fb7-4856eb0bc79e@github.com>

On Wed, 7 May 2025 16:51:30 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> JavaFX Pull Request: https://github.com/openjdk/jfx/pull/1755
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

LGTM apart from minor inline comments

src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m line 494:

> 492: }
> 493: 
> 494: + (void)_embeddedEvent:(NSNotification *)notification {

@kevinrushforth @prrace 

Is '_embeddedEvent' too generic, does it need to be changed to something more inline with OpenURI e.g '_openURIEvent' ?

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24379#pullrequestreview-2844335685
PR Review Comment: https://git.openjdk.org/jdk/pull/24379#discussion_r2091559784

From honkar at openjdk.org  Thu May 15 16:31:01 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 15 May 2025 16:31:01 GMT
Subject: RFR: 8332947: [macos] OpenURIHandler events not received when AWT
 is embedded in another toolkit [v5]
In-Reply-To: <l7zmFdaJ70dqIJc93lxQ1O8OFQgwYUJLhmAtw3Axqts=.80a9e0f8-54a5-4110-8c04-0105415e2f8e@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <fqKmOzkrPk_XWcxB5WkUgsjBAGuwRRQBDWH6h_kTAEs=.8deacfe8-f565-4ac1-8810-dc687d4ef0de@github.com>
 <l7zmFdaJ70dqIJc93lxQ1O8OFQgwYUJLhmAtw3Axqts=.80a9e0f8-54a5-4110-8c04-0105415e2f8e@github.com>
Message-ID: <O-wPZ271uZZjANdzIFczeQodJuGLk2xYdWzXZFHZqZ0=.90dc85ba-8bcd-4b16-9d2b-c87c497ee3f0@github.com>

On Wed, 7 May 2025 16:43:57 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> Pabulaner IV has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events
>>  - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events
>>  - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events
>
> I implemented the feedback and changed the pull request title.

@pabulaner Changes look good. Please wait until @prrace has gotten a chance to review and approve this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/24379#issuecomment-2884418615

From kcr at openjdk.org  Thu May 15 16:31:04 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 May 2025 16:31:04 GMT
Subject: RFR: 8332947: [macos] OpenURIHandler events not received when AWT
 is embedded in another toolkit [v7]
In-Reply-To: <v_AWwgsQPYRRzziDuqShRy6DNGSC4U-lEGBbSZAlciQ=.7afe9be7-26bb-406a-8fb7-4856eb0bc79e@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
 <v_AWwgsQPYRRzziDuqShRy6DNGSC4U-lEGBbSZAlciQ=.7afe9be7-26bb-406a-8fb7-4856eb0bc79e@github.com>
Message-ID: <hYjh0CB0uNPBsJzi6N2jRvH_AVrgB00aJFi5hg9U5f4=.34e73d48-510c-43cb-b7a8-af813b30edc1@github.com>

On Thu, 15 May 2025 16:20:57 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m line 494:
> 
>> 492: }
>> 493: 
>> 494: + (void)_embeddedEvent:(NSNotification *)notification {
> 
> @kevinrushforth @prrace 
> 
> Is '_embeddedEvent' too generic, does it need to be changed to something more inline with OpenURI e.g '_openURIEvent' ?

As I noted in an earlier comment, I think the method name, _embeddedEvent , is fine, since it is private to this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24379#discussion_r2091568016

From kcr at openjdk.org  Thu May 15 16:31:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 May 2025 16:31:05 GMT
Subject: RFR: 8332947: [macos] OpenURIHandler events not received when AWT
 is embedded in another toolkit [v7]
In-Reply-To: <hYjh0CB0uNPBsJzi6N2jRvH_AVrgB00aJFi5hg9U5f4=.34e73d48-510c-43cb-b7a8-af813b30edc1@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
 <v_AWwgsQPYRRzziDuqShRy6DNGSC4U-lEGBbSZAlciQ=.7afe9be7-26bb-406a-8fb7-4856eb0bc79e@github.com>
 <hYjh0CB0uNPBsJzi6N2jRvH_AVrgB00aJFi5hg9U5f4=.34e73d48-510c-43cb-b7a8-af813b30edc1@github.com>
Message-ID: <xrNRAMtvy9ntCNGClZjuDWeLOz4BMx_-gtexg1dUWGs=.d48363ae-b03c-42b7-991c-71d909ba9f45@github.com>

On Thu, 15 May 2025 16:25:56 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m line 494:
>> 
>>> 492: }
>>> 493: 
>>> 494: + (void)_embeddedEvent:(NSNotification *)notification {
>> 
>> @kevinrushforth @prrace 
>> 
>> Is '_embeddedEvent' too generic, does it need to be changed to something more inline with OpenURI e.g '_openURIEvent' ?
>
> As I noted in an earlier comment, I think the method name, _embeddedEvent , is fine, since it is private to this file.

Also, while it is only used for openURI today, it could be used to pass additional messages in the future, so even if he were to change it, it shouldn't have "openURI" in the name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24379#discussion_r2091569752

From honkar at openjdk.org  Thu May 15 16:35:59 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 15 May 2025 16:35:59 GMT
Subject: RFR: 8332947: [macos] OpenURIHandler events not received when AWT
 is embedded in another toolkit [v7]
In-Reply-To: <xrNRAMtvy9ntCNGClZjuDWeLOz4BMx_-gtexg1dUWGs=.d48363ae-b03c-42b7-991c-71d909ba9f45@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
 <v_AWwgsQPYRRzziDuqShRy6DNGSC4U-lEGBbSZAlciQ=.7afe9be7-26bb-406a-8fb7-4856eb0bc79e@github.com>
 <hYjh0CB0uNPBsJzi6N2jRvH_AVrgB00aJFi5hg9U5f4=.34e73d48-510c-43cb-b7a8-af813b30edc1@github.com>
 <xrNRAMtvy9ntCNGClZjuDWeLOz4BMx_-gtexg1dUWGs=.d48363ae-b03c-42b7-991c-71d909ba9f45@github.com>
Message-ID: <tY73mDmzm3G4k-UmiDCFMc_7Egov6aawMA9ViC7TTC8=.aff4c5c1-6b07-456f-8dd3-91e5a44a4258@github.com>

On Thu, 15 May 2025 16:26:55 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> As I noted in an earlier comment, I think the method name, _embeddedEvent , is fine, since it is private to this file.
>
> Also, while it is only used for openURI today, it could be used to pass additional messages in the future, so even if he were to change it, it shouldn't have "openURI" in the name.

Good point. Agreed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24379#discussion_r2091581008

From aivanov at openjdk.org  Thu May 15 16:35:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 May 2025 16:35:59 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v2]
In-Reply-To: <iNjn5dg1IjU_fT_ajdxgdO5iuk030EZtkrPT34_wjFs=.4e8c3708-36fc-4bcc-9f70-a3779416b501@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
 <iNjn5dg1IjU_fT_ajdxgdO5iuk030EZtkrPT34_wjFs=.4e8c3708-36fc-4bcc-9f70-a3779416b501@github.com>
Message-ID: <Tb8wCoSGNxrXbmWsx0UYegv2BbteRHBZcYQUP3qnZaQ=.d733e1cc-82d6-4d34-b9fb-27532b6c1731@github.com>

On Thu, 15 May 2025 13:51:07 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> **Analysis :**
>> 
>> Whether the test passes on the main line or fails, the behavior is still incorrect.
>> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly.
>> 
>> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt.
>> 
>> This causes the test to proceed immediately to the validation step:
>> 
>> if (fd.isVisible()) {
>>     throw new RuntimeException("File Dialog is not closed");
>> }
>> 
>> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet)
>> 
>> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation.
>> 
>> **Proposed fix:**
>> 
>> set the CountDownLatch to 2
>> 
>> **Proposed enhancements :**
>> 
>> Remove unnecessary threads (Thread and Thread-2)
>> Properly handle delays and robot.waitForIdle()
>> Avoid indefinite blocking on latch.await()
>> 
>> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds
>> 
>> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details
>
> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/ProblemList.txt
>   
>   Co-authored-by: Abhishek Kumar <abhishek.cx.kumar at oracle.com>

A sanity check: does the updated test reproduce the problem reported in [JDK-5097243](https://bugs.openjdk.org/browse/JDK-5097243)? I'm pretty sure it should.

test/jdk/java/awt/FileDialog/DoubleActionESC.java line 56:

> 54:     private static volatile CountDownLatch latch;
> 55:     private static final int REPEAT_COUNT = 2;
> 56:     private static final long LATCH_TIMEOUT = 4;

Suggestion:

    private static final int REPEAT_COUNT = 2;
    private static final long LATCH_TIMEOUT = 4;

        private static final CountDownLatch latch = new CountDownLatch(REPEAT_COUNT);

test/jdk/java/awt/FileDialog/DoubleActionESC.java line 81:

> 79:                 robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
> 80:                 robot.waitForIdle();
> 81:                 robot.delay(1000);

Can the delay be reduced to `500`?

test/jdk/java/awt/FileDialog/DoubleActionESC.java line 89:

> 87:             }
> 88: 
> 89:             latch.await(LATCH_TIMEOUT, SECONDS);

Throw an exception if the timeout is reached ? the test already failed.

test/jdk/java/awt/FileDialog/DoubleActionESC.java line 90:

> 88: 
> 89:             latch.await(LATCH_TIMEOUT, SECONDS);
> 90:             if (fd.isVisible()) {

I'm on the fence here? Calling `fd.isVisible()` on EDT is more reliable; but it's not strictly required for AWT components.

test/jdk/java/awt/FileDialog/DoubleActionESC.java line 92:

> 90:             if (fd.isVisible()) {
> 91:                 throw new RuntimeException("File Dialog is not closed");
> 92:             }

Dispose of `fd` too (in the finally block).

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25184#pullrequestreview-2844332500
PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2091558746
PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2091564010
PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2091576832
PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2091578738
PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2091575682

From aivanov at openjdk.org  Thu May 15 16:38:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 May 2025 16:38:52 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently
In-Reply-To: <AiN8sRdyx85DmffRjcmTqBG-o8INUUMzlxvnrrEwcoA=.91159761-a31f-43ce-980e-b611dae10c12@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
 <AiN8sRdyx85DmffRjcmTqBG-o8INUUMzlxvnrrEwcoA=.91159761-a31f-43ce-980e-b611dae10c12@github.com>
Message-ID: <BVODNbFFzFKbGAljTsQ2gYC2HdyYnHoKo3BvZ5N9GI8=.b626a496-a613-4a91-a984-e474b89395d2@github.com>

On Thu, 15 May 2025 08:46:46 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> > However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt.
> > This causes the test to proceed immediately to the validation step:
> > if (fd.isVisible()) {
> > throw new RuntimeException("File Dialog is not closed");
> > }
> 
> I don't see the existing code ignores the second attempt, that is due to longer delay put after the robot operations. You can add print statements and observe the behavior.
> 
> However, I agree the countdown latch should be initialize to 2 to behave correctly.

Technically, longer delays do add up, yet if it takes longer to display the dialog and hide it, it's well possible that the dialog isn't hidden by the time the main thread reaches the point where it calls `fd.isVisible()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25184#issuecomment-2884439345

From mblaesing at openjdk.org  Thu May 15 16:48:47 2025
From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=)
Date: Thu, 15 May 2025 16:48:47 GMT
Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v3]
In-Reply-To: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com>
References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com>
Message-ID: <eMVuk6CjTRjfvR6UUtz4FsRN4wqGOoZRedYLQMtY24g=.1988f3cd-3d59-4f2c-9886-1f038f0d834d@github.com>

> - Introduce a lock into WClipboard that protects the code between
>   openClipboard/closeClipboard invocations.
>   The native side does not allow to open the clipboard multiple
>   times or share the opened clipboard between multiple threads.
> 
> - Remove of need to call openClipboard/closeClipboard from
>   getClipboardFormats by using the win32 call
>   GetUpdatedClipboardFormats
> 
> - Prevent a race-condition by not registering the connection
>   between java and native side of clipboard multiple time, but
>   just at construction time.

Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision:

  Add crash reproducer as jtreg test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24614/files
  - new: https://git.openjdk.org/jdk/pull/24614/files/4fa4ef90..e5ebf59f

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

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

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

From mblaesing at openjdk.org  Thu May 15 17:00:56 2025
From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=)
Date: Thu, 15 May 2025 17:00:56 GMT
Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v2]
In-Reply-To: <IVseDGLFBp2TAQMrbsgvCgX1wBOALL0QZXwMwHxp7Hw=.d305f8ac-3a89-42c0-b626-08ae327f1cb1@github.com>
References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com>
 <HYQ237abKwF9M1jfKX3VQG_ytVIfbXo_m3OioPFbd4s=.f1ecbd3e-c630-457d-8b78-73292bbb39d4@github.com>
 <IVseDGLFBp2TAQMrbsgvCgX1wBOALL0QZXwMwHxp7Hw=.d305f8ac-3a89-42c0-b626-08ae327f1cb1@github.com>
Message-ID: <70CaDViNDBcpE7Nno03joM9Dov0f27h7swxpBiPFSFc=.a9e9ce1a-db48-4921-bd99-8578af5ba9ef@github.com>

On Tue, 13 May 2025 02:11:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adress review comments: Update copyright years and fix whitespace in if condition
>
> is it possible to create a jtreg test for this issue?

@mrserb added the reproducer and validated, that it works:

- *fastdebug* build: Before this change assertion is hit quickly, this will not be reported as a testfailure as the assertion handler displays a message and only blocks further execution of that thread, after the change no assertion is hit.
- *release* build: Before this change the JVM crashes and that is reported as a test failure, after the change the code runs through.

The test was run via:


CONF=windows-x86_64-server-release make test TEST="test/jdk/java/awt/Clipboard/ConcurrentClipboardAccessTest.java"
# and
CONF=windows-x86_64-server-fastdebug make test TEST="test/jdk/java/awt/Clipboard/ConcurrentClipboardAccessTest.java"

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

PR Comment: https://git.openjdk.org/jdk/pull/24614#issuecomment-2884495131

From dgredler at openjdk.org  Thu May 15 17:20:06 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 15 May 2025 17:20:06 GMT
Subject: RFR: 8356966:
 java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails on Linux after
 JDK-8350203 [v3]
In-Reply-To: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
References: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
Message-ID: <Pob6jA6-9qJROD6s9JOTdSPcRMsx5cK0ba1kQ08cPjo=.9f850e75-2e1a-49c1-8a79-95a9d932b508@github.com>

> If the new test (`IgnoredWhitespaceTest`) runs on a system with Type1 physical fonts, it fails because the Type1 handling of ignorable whitespace characters does not match the behavior of the TrueType and macOS glyph mappers.
> 
> This PR updates the Type1 glyph mapper to follow the same rules in this area as the other glyph mappers.
> 
> It would probably be a good idea to consolidate all of this into the `CharToGlyphMapper` superclass at some point, so that we're not duplicating this handling across the subclasses, but some users are reporting failing builds and I wanted to keep the PR simple.

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

  Update bug tag in test class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25235/files
  - new: https://git.openjdk.org/jdk/pull/25235/files/13130c4c..fe1fda57

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

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

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

From serb at openjdk.org  Thu May 15 17:23:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 15 May 2025 17:23:52 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine
In-Reply-To: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
Message-ID: <KtWy5PAcbJKIMzCdknC5d-YFGjs4dUqTA0p4WznpDE4=.cea2724e-4d1b-4c24-aefa-4d6ef09cc057@github.com>

On Thu, 15 May 2025 04:05:38 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> Unfortunately I'm unable to reproduce this failure. I slowed the test down; it passes on my machine before and after this PR.
> 
> I added a little bit of logging that might also help identify what's happening.
> 
> Does anyone have any more suggestions?

test/jdk/com/apple/laf/RootPane/RootPaneDefaultButtonTest.java line 131:

> 129:         robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
> 130: 
> 131:         robot.delay(1000);

it will be useful to add the same delay before the first call to test, right after invokeAndWait.....setVisible(...)
Also please move creation and access_to all Swing components to EDT(button, radioButton1)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25244#discussion_r2091656355

From aivanov at openjdk.org  Thu May 15 17:51:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 May 2025 17:51:54 GMT
Subject: RFR: 8356966:
 java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails on Linux after
 JDK-8350203 [v3]
In-Reply-To: <Pob6jA6-9qJROD6s9JOTdSPcRMsx5cK0ba1kQ08cPjo=.9f850e75-2e1a-49c1-8a79-95a9d932b508@github.com>
References: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
 <Pob6jA6-9qJROD6s9JOTdSPcRMsx5cK0ba1kQ08cPjo=.9f850e75-2e1a-49c1-8a79-95a9d932b508@github.com>
Message-ID: <6pfFk3ULMg49y3gxczuSVrbx-Vf9gX_RoJPU7kjmkmY=.727cf914-7c02-4faa-b07f-5a3f4f7711dd@github.com>

On Thu, 15 May 2025 17:20:06 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> If the new test (`IgnoredWhitespaceTest`) runs on a system with Type1 physical fonts, it fails because the Type1 handling of ignorable whitespace characters does not match the behavior of the TrueType and macOS glyph mappers.
>> 
>> This PR updates the Type1 glyph mapper to follow the same rules in this area as the other glyph mappers.
>> 
>> It would probably be a good idea to consolidate all of this into the `CharToGlyphMapper` superclass at some point, so that we're not duplicating this handling across the subclasses, but some users are reporting failing builds and I wanted to keep the PR simple.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update bug tag in test class

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25235#pullrequestreview-2844554557

From naoto at openjdk.org  Thu May 15 18:32:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 18:32:53 GMT
Subject: RFR: 8356977: UTF-8 cleanups
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>

On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

test/jdk/sun/text/resources/LocaleDataTest.java line 106:

> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
> 106:  *        LocaleNames/fr_FR/US=?tats-Unis

This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2091757029

From duke at openjdk.org  Thu May 15 19:22:06 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Thu, 15 May 2025 19:22:06 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine [v2]
In-Reply-To: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
Message-ID: <myxGswD8nolzReIdvjkl3yd-KFTGlN4UVPQJjKBanoE=.ff638733-77b7-4526-94ba-4b8a229a2011@github.com>

> Unfortunately I'm unable to reproduce this failure. I slowed the test down; it passes on my machine before and after this PR.
> 
> I added a little bit of logging that might also help identify what's happening.
> 
> Does anyone have any more suggestions?

Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:

 - 8356061: restructuring to move things to EDT
   
   This was requested here:
   https://github.com/openjdk/jdk/pull/25244#discussion_r2091656355
   
   mrserb asked: "Also please move creation and access_to all Swing components to EDT"
   
   (I'm not sure this will help much? My understanding was *creation* of Swing components could happen off the EDT as long as they were made displayable on the EDT.)
   
   Now we still call jc.getLocationOnScreen off the EDT. If that posed a thread-based problem it'd probably manifest as a IllegalComponentStateException, which is not mentioned in 8356061.
 - 8356061: adding 1000ms pause after window construction
   
   This was requested here:
   https://github.com/openjdk/jdk/pull/25244#discussion_r2091656355
   
   So now we'll pause at least 1.1s before the first call to `jc.getLocationOnScreen`, and at least 2.1s before the first call to `robot.getPixelColor(x, y)`.
   
   (getLocationOnScreen has never failed with an IllegalStateException.)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25244/files
  - new: https://git.openjdk.org/jdk/pull/25244/files/b7270924..b076c964

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

  Stats: 183 lines in 1 file changed: 92 ins; 77 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25244/head:pull/25244

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

From duke at openjdk.org  Thu May 15 19:31:52 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Thu, 15 May 2025 19:31:52 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine [v2]
In-Reply-To: <KtWy5PAcbJKIMzCdknC5d-YFGjs4dUqTA0p4WznpDE4=.cea2724e-4d1b-4c24-aefa-4d6ef09cc057@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
 <KtWy5PAcbJKIMzCdknC5d-YFGjs4dUqTA0p4WznpDE4=.cea2724e-4d1b-4c24-aefa-4d6ef09cc057@github.com>
Message-ID: <Lp9r0fyFSOR2TkmuErsUWT1VhR38MycgfxhTPdZZj6Y=.c2953055-2756-48fb-a2fb-97bb050ecf3e@github.com>

On Thu, 15 May 2025 17:21:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8356061: restructuring to move things to EDT
>>    
>>    This was requested here:
>>    https://github.com/openjdk/jdk/pull/25244#discussion_r2091656355
>>    
>>    mrserb asked: "Also please move creation and access_to all Swing components to EDT"
>>    
>>    (I'm not sure this will help much? My understanding was *creation* of Swing components could happen off the EDT as long as they were made displayable on the EDT.)
>>    
>>    Now we still call jc.getLocationOnScreen off the EDT. If that posed a thread-based problem it'd probably manifest as a IllegalComponentStateException, which is not mentioned in 8356061.
>>  - 8356061: adding 1000ms pause after window construction
>>    
>>    This was requested here:
>>    https://github.com/openjdk/jdk/pull/25244#discussion_r2091656355
>>    
>>    So now we'll pause at least 1.1s before the first call to `jc.getLocationOnScreen`, and at least 2.1s before the first call to `robot.getPixelColor(x, y)`.
>>    
>>    (getLocationOnScreen has never failed with an IllegalStateException.)
>
> test/jdk/com/apple/laf/RootPane/RootPaneDefaultButtonTest.java line 131:
> 
>> 129:         robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
>> 130: 
>> 131:         robot.delay(1000);
> 
> it will be useful to add the same delay before the first call to test, right after invokeAndWait.....setVisible(...)
> Also please move creation and access_to all Swing components to EDT(button, radioButton1)

I added an additional delay. I'm not sure exactly what refactor you're looking for, but I rewrote the test to put more in the EDT.

(I double-checked that the test still passes, but that doesn't prove much since I've never reproduced a failure.)

I did try at one point blocking the testing thread until the EDT had a chance to complete an invokeLater runnable, but that didn't seem to make a difference so I didn't commit it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25244#discussion_r2091836908

From prr at openjdk.org  Thu May 15 21:18:00 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 May 2025 21:18:00 GMT
Subject: RFR: 8332947: [macos] OpenURIHandler events not received when AWT
 is embedded in another toolkit [v7]
In-Reply-To: <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
Message-ID: <tY53kZGDEv7CTkbdZH6XhCwjFIXtMhv1pCj1y6s9lSE=.ee9b5c7e-bc86-4294-9dcf-b7f851897904@github.com>

On Wed, 7 May 2025 16:51:30 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> JavaFX Pull Request: https://github.com/openjdk/jfx/pull/1755
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24379#pullrequestreview-2844987602

From duke at openjdk.org  Thu May 15 21:20:56 2025
From: duke at openjdk.org (duke)
Date: Thu, 15 May 2025 21:20:56 GMT
Subject: RFR: 8332947: [macos] OpenURIHandler events not received when AWT
 is embedded in another toolkit [v7]
In-Reply-To: <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
 <7WiIudj17C-fXWZL1FxnPqXrtk2sQH2V_kAX7Yy6s3w=.50d1a1df-f653-4a9b-abec-e170e3a9cf09@github.com>
Message-ID: <dGlanTgUwK6_UzfhhuwWSyzjR0qJqzDAGz7rkGV1p6Y=.7dbfa77e-17e6-4b9f-9b1d-c8325f0b17d0@github.com>

On Wed, 7 May 2025 16:51:30 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> JavaFX Pull Request: https://github.com/openjdk/jfx/pull/1755
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

@pabulaner 
Your change (at version 924b17b166fa88b02b38c4a046e177fa7e5ccccf) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24379#issuecomment-2885075019

From duke at openjdk.org  Thu May 15 22:38:59 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Thu, 15 May 2025 22:38:59 GMT
Subject: Integrated: 8332947: [macos] OpenURIHandler events not received when
 AWT is embedded in another toolkit
In-Reply-To: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
References: <Z3MlrHF0QKX9QyirbL5SoaYrWU8oOjmK02L891LjVzk=.d0c2d96d-ed5c-4335-8a3b-43737a9c993a@github.com>
Message-ID: <1-SbOb8AwwmdoaYmhLe9rEbV6hQFkhk_eF_P7Cl6sLM=.e717838a-fe0c-41b2-85c1-f17afdfeeb0b@github.com>

On Wed, 2 Apr 2025 14:15:28 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
> Either the native menu is not shown or the URIs are not received.
> 
> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
> 
> JavaFX Pull Request: https://github.com/openjdk/jfx/pull/1755
> Co-Author: @FlorianKirmaier

This pull request has now been integrated.

Changeset: f6b0f016
Author:    Paul H <p.hayder at icloud.com>
Committer: Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f6b0f016f6da5d9c96b21c74d3b906ed8e6ae4b4
Stats:     31 lines in 1 file changed: 28 ins; 3 del; 0 mod

8332947: [macos] OpenURIHandler events not received when AWT is embedded in another toolkit

Reviewed-by: kcr, honkar, prr

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

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

From duke at openjdk.org  Fri May 16 01:51:50 2025
From: duke at openjdk.org (duke)
Date: Fri, 16 May 2025 01:51:50 GMT
Subject: RFR: 8355515: Clarify the purpose of forcePass() and forceFail()
 methods
In-Reply-To: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
References: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
Message-ID: <RYqM9SArAez8yKI3xsxtAtQKSky1BUd1sVCb7WSLznI=.88a54a01-0028-4a47-8ff1-5fc1c3de24db@github.com>

On Wed, 7 May 2025 12:28:52 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Clarified the purpose of forcePass() and forceFail() methods and recommended usage of these methods.
> 
> forcePass() contained an incorrect sample; it's addressed by [JDK-8355441](https://bugs.openjdk.org/browse/JDK-8355441).
> 
> The description of forceFail() has been expanded, too.
> 
> 
> A new section in the description of the PassFailJFrame added to describe forcePass() and forceFail().

@manukumarvs 
Your change (at version 68f72e4684b703c79853739c43009db225e8173e) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25091#issuecomment-2885424356

From achung at openjdk.org  Fri May 16 02:02:55 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 16 May 2025 02:02:55 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v11]
In-Reply-To: <qQtGLrMW9zimjehHP3hyWkt6IE9_kaylDWI1XZ9hNrk=.db59639d-87dc-4cf8-90a7-6c4557184bcc@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
 <741DjI-uVAuf4pjN9MqVaKz2iEI-qr-L9c6KCbP7IlY=.e46c1d54-4b0f-4cc3-b572-043923972212@github.com>
 <mwLvU39Qxbts9_I2MU5oup-aeFVOulBcjRjVvUNKLOI=.4fa7507c-b038-4e87-8dcf-6c6c9f108acc@github.com>
 <lI8-Y3StfMzsltCf-vFdP5Oo-S1h5FRG8p21xRMnbfk=.608efc2d-671c-4a37-bfd8-b5827c9bc6cd@github.com>
 <B4fWQWgcaUcHuz7pi_mJimGbCUWdsHrrDMsN0gvbTA0=.5fb9b028-012f-4da1-ac76-d925b8b64bf2@github.com>
 <UALf_jPu6Pju8jgD51nERwQnJXLjM0u5XrthhB26M9g=.dde004fc-0a73-408d-b9ab-d9f21e71a006@github.com>
 <QqY_tCRd6FxeEGOHL86BRxcgP_avpOnBK_JtuMzTeHU=.81163bd7-f6ba-4c43-b281-356566e8af69@github.com>
 <zye9iVM8AK70RuqU_2nm4evvJavym_cl3s2s-HDrBvk=.09c36435-63ea-4bee-adb1-ffc6f7124b41@github.com>
 <6A6RT3ZqccBhAhdhEaSDc3Ri0yUWw61Alc2xbYHtXfI=.24af6c9c-b6b8-4f3e-a4c6-61143685eef2@github.com>
 <xPGWVGkGW255iwjDoWAhEuLEXVG3lC7D8rZ
 j8ZAMcHE=.067cf490-52e2-44e4-9f9a-fff7e908a220@github.com>
 <we7CVGOf0v6qdH3wvbH4Dro986V_0YYVExf7CIfmQ8o=.cc2b2e29-3c47-441c-9334-360ca9619482@github.com>
 <qQtGLrMW9zimjehHP3hyWkt6IE9_kaylDWI1XZ9hNrk=.db59639d-87dc-4cf8-90a7-6c4557184bcc@github.com>
Message-ID: <e31kIuQsidDOCpJVgb6kfcJuopcdn92W99oBTWGaFHY=.072890a8-d718-4bc5-818b-f7a86436fb99@github.com>

On Mon, 5 May 2025 22:45:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I propose developing a native reproducer to investigate the mouse position clamping behavior observed on macOS. The steps would include:
> 
> 1. Moving the mouse cursor outside the screen bounds.
> 2. Retrieving the current mouse position.
> 3. Simulating a mouse click at the current position.
> 4. Retrieving the mouse position again.
> 5. Comparing the positions from steps 2 and 4.

I have attached a native reproducer to the JBS issue. The result is that getting the location of the mouse after the mouseMove and mousePress/Release both result in the offscreen coordinates, so it is reproducible natively.

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

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2885437648

From mbaesken at openjdk.org  Fri May 16 06:38:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 May 2025 06:38:54 GMT
Subject: RFR: 8356966:
 java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails on Linux after
 JDK-8350203 [v2]
In-Reply-To: <R8Kwq1ZAdeXf_bCL-s06DLWeQOh5vrJFqdCsSGYMMyk=.2b4bea5a-b349-49f4-b533-ce3c63328c85@github.com>
References: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
 <TIBNLsI9rDJ4N7i5nnEOAdWV4G0-3PAecFYKVWukv3I=.00857aa2-731e-4fc3-aca9-3919da1be53e@github.com>
 <R8Kwq1ZAdeXf_bCL-s06DLWeQOh5vrJFqdCsSGYMMyk=.2b4bea5a-b349-49f4-b533-ce3c63328c85@github.com>
Message-ID: <lUlQiFUlDaaIKDDQeOYpiaWx3OPTciJhiezbXNX0U2s=.52ee6435-ad33-4f60-b7d5-bd87d81399fe@github.com>

On Thu, 15 May 2025 07:35:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Include additional font information in message
>
> I added your PR to our build/test queue, let's see if it fixes the  issues.

> Looks good to me. I didn't try to reproduce the problem. Let's wait for @MBaesken test results.

Test results look good, with your PR the issue is gone on the 2 Linux machines where we noticed it before .

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

PR Comment: https://git.openjdk.org/jdk/pull/25235#issuecomment-2885779628

From abhiscxk at openjdk.org  Fri May 16 07:27:02 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 16 May 2025 07:27:02 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently
In-Reply-To: <BVODNbFFzFKbGAljTsQ2gYC2HdyYnHoKo3BvZ5N9GI8=.b626a496-a613-4a91-a984-e474b89395d2@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
 <AiN8sRdyx85DmffRjcmTqBG-o8INUUMzlxvnrrEwcoA=.91159761-a31f-43ce-980e-b611dae10c12@github.com>
 <BVODNbFFzFKbGAljTsQ2gYC2HdyYnHoKo3BvZ5N9GI8=.b626a496-a613-4a91-a984-e474b89395d2@github.com>
Message-ID: <AcK1Hi9s-jkY9DQnsVL_hcOqa3IGNxuL-rshIOCQE0Q=.f53c34be-4ec8-46c3-b946-1b8ff100d2d9@github.com>

On Thu, 15 May 2025 16:36:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt.
> > > This causes the test to proceed immediately to the validation step:
> > > if (fd.isVisible()) {
> > > throw new RuntimeException("File Dialog is not closed");
> > > }
> > 
> > 
> > I don't see the existing code ignores the second attempt, that is due to longer delay put after the robot operations. You can add print statements and observe the behavior.
> > However, I agree the countdown latch should be initialize to 2 to behave correctly.
> 
> Technically, longer delays do add up, yet if it takes longer to display the dialog and hide it, it's well possible that the dialog isn't hidden by the time the main thread reaches the point where it calls `fd.isVisible()`.

Yes, I agree. That's why I am in favour of increasing the latch count to 2 which will ensure everything is all right.

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

PR Comment: https://git.openjdk.org/jdk/pull/25184#issuecomment-2885876078

From abhiscxk at openjdk.org  Fri May 16 07:27:02 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 16 May 2025 07:27:02 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently
In-Reply-To: <EMUsox94T_KZ8YI_G7C9PPMHby11CTHDbPPmEfVO1Vg=.cfe5e1d7-dfa7-481a-925c-8d38927e6535@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
 <D16HeMCf9v1pdIVZSkziNmso3JBU_JklAEb9NbswFlM=.665102ed-d628-44f6-998a-f2bd8ef9d9ac@github.com>
 <GBelvNQueR6l_g6xHHyDyc-tvd4d5Baii3kqkoeGmnE=.37b41ba7-efaa-41c8-b14f-70a89846b8b5@github.com>
 <b0RkK8aNDmKzrRPoF2j2S1tMo3VUFstHXKb0rkK2TmE=.2b52c88f-c491-4dac-a1d9-3d84e268c184@github.com>
 <EMUsox94T_KZ8YI_G7C9PPMHby11CTHDbPPmEfVO1Vg=.cfe5e1d7-dfa7-481a-925c-8d38927e6535@github.com>
Message-ID: <Ef2CII9wFiKFyU-xakxRLpPGV4gLYix23qvGTd6YoN0=.95083288-6573-490b-a158-88d6275c7621@github.com>

On Thu, 15 May 2025 15:30:15 GMT, Anass Baya <abaya at openjdk.org> wrote:

>>> Did you try to reproduce the bug manually first with b25 before proceeding with the automated test ?
>> 
>> Yes, I tried with the manual applet test with b25 and b29.
>> There is an exception thrown (related with security permission) for the first time whenever Show File Dialog button is clicked but on next click File Dialog is shown and it's getting closed on `ESC` press (Behaves same for repeat operations).
>> 
>> The behavior is same for b25 and b29 both.
>> 
>> For automated test, it's same behavior and there is no exception thrown.
>> Debug prints for b25 and b29:
>> 
>>      Show File Dialog
>>      Set File Dialog Visible
>>      Press ESC Button
>>      Before latch countDown : 2
>>      After latch countDown : 1
>>      Show File Dialog
>>      Set File Dialog Visible
>>      Press ESC Button
>>      Before latch countDown : 1
>>      After latch countDown : 0
>
> @kumarabhi006 
> As I understand, you're not able to reproduce the issue with b25( the version that doent include the fix), even when testing manually. So it's unclear whether the automated test is actually effective since you are not reproducing the issue manually
> 
> As I mentioned earlier, to check the test's effectiveness, I reverted the fix on the mainline ? and the test failed 20 out of 20 times. Then, when I reapplied the fix, the test passed 20 out of 20 times.
> 
> Maybe you could try running the test in a loop. According to [JDK-5097243](https://bugs.openjdk.org/browse/JDK-5097243), the issue reproduction is intermittent

@anass-baya Could you please add the CI link in JBS ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25184#issuecomment-2885877557

From duke at openjdk.org  Fri May 16 10:32:06 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 16 May 2025 10:32:06 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
Message-ID: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>

If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer.

We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block.

There are 4 tickets/PRs that use this new GifComparison class. I recommend not reviewing this PR until #25044 clears code review. (See https://github.com/openjdk/jdk/pull/25044#issuecomment-2881889090 )

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

Commit messages:
 - 8357034: fixing ticket number
 - GifComparison: fixing error message
 - Incident 9078482: fix when new trans index is in saved images
 - GifComparison: code cleanup
 - GifComparison: adding common helper class for gif bugs
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'openjdk:master' into master
 - ... and 7 more: https://git.openjdk.org/jdk/compare/5e50a584...5b982b12

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

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

From tr at openjdk.org  Fri May 16 10:48:53 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 16 May 2025 10:48:53 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v2]
In-Reply-To: <9eWBFqqVGM6xc824gwLDzpRT6cYOORMC1bFkdzFrseA=.424e137c-e5d9-4fb9-a2b1-e5a675b8ac6b@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <vEWA2CeJs9SmRb8K81xVWRMko2w6xj9Q2hIGXlYUVZM=.e7d736f9-9b2c-4a48-b366-e3801a304f9e@github.com>
 <Ahgb4B8gkI9Cjqwdoq0-Acfcga0QYbiprxAS4k3Fa7U=.c36f229f-2529-4788-8d14-86a51422e373@github.com>
 <vmyVz_91nhgMmjLla6DKOkJGD-Xp_6qajAgUKfeXLoY=.89fefd83-43c9-476c-a951-70a633f9a5e2@github.com>
 <xrKZHsl3CpNOAmppgUcqtxPK_Pb8RinLTrj11RMxGOY=.a64e2fff-04cb-4001-acbb-3c10b24d54de@github.com>
 <f6oYZ6xLi4A9CLobrR9K5ENfgEmSBqTay1kQaf7f3yY=.29f79326-48e7-4ad8-9afb-055536cdb4b2@github.com>
 <isvH5l_2W5YQ-mbpXd3XJMLyp2XP8Yohrq9cxFi84Nc=.27fc812c-b5e4-43df-b9f8-55881331097c@github.com>
 <UzRKXFgBG_WyKaEF3Hjdb3qb2ExAFmUA3UNZI42zMm0=.48021bee-2600-47bf-8c26-bfdddf320592@github.com>
 <MsGQMdJVt_rqNfkj62DVrsBWPlQrx5lsxjnR5BKzl9k=.a8bbbc62-1b60-4982-9424-6af202a6304c@github.com>
 <PfOTt7diduByRh7oViyuN-gJ-3iiD_CnGHIY8Xmni8k=.b52391fd-f576-4c01-923b-209975713596@github.com>
 <HYVRAUlbtJyV9GVAKlTWbeUNMHzV8ugjNuP
 7B4ALY48=.134d9204-f8a9-48fa-85af-982aa124469a@github.com>
 <oTB8PeOedGLLoza4ALZkxGvEdJttzGQb3_eVKwwT0eE=.9f06dd2d-7485-45eb-8cae-af3bad0aa683@github.com>
 <kG1MjZyVmybZj-A8u7ak4GBJ-h06fy5fAxIjFObj45c=.c80b7530-2747-4e56-bb7c-72bc84a612cf@github.com>
 <mwA2kTMeaSXuWYCnqXlvhMAJYUA50J58c-8BPaPiLw8=.71bc0dea-2509-491d-878a-ae27b04ec5fd@github.com>
 <QhZ-yOsUL-Y-EFjbyDD98pdW-EqLQk9yIIyIZF-IAh0=.a2145cd5-59fe-437f-81f6-4b468a5e8cb3@github.com>
 <p019LdENzXf5VWn6bjL5itcebyP1FWZeacqqDwVERmA=.86fa1fe0-138d-4655-8046-0f7021a4f0f4@github.com>
 <9eWBFqqVGM6xc824gwLDzpRT6cYOORMC1bFkdzFrseA=.424e137c-e5d9-4fb9-a2b1-e5a675b8ac6b@github.com>
Message-ID: <GFg3jELh7bdn020VBxETgf_oilC0d30tEU9P_3nQyeY=.0445274f-561c-404e-99e3-164d39c5f486@github.com>

On Tue, 13 May 2025 03:05:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Exception in thread "AWT-EventQueue-0" java.nio.file.InvalidPathException: Illegal char <<> at index 0: <html><h1 color=#ff00ff><font face="Comic Sans MS">SWING ROCKS!!!111
>>>         at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:191)
>>>         at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:142)
>>>         at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:46)
>>>         at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
>>>         at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:203)
>>>         at java.base/java.nio.file.Path.of(Path.java:148)
>>>         at java.base/java.nio.file.Paths.get(Paths.java:69)
>>>         at java.desktop/sun.awt.shell.ShellFolder.getShellFolder(ShellFolder.java:260)
>>>         at java.desktop/javax.swing.filechooser.FileSystemView.getShellFolder(FileSystemView.java:724)
>>>         at java.desktop/javax.swing.filechooser.FileSystemView.getSystemIcon(FileSystemView.java:242)
>>>         at java.desktop/com.sun.java.swing.plaf.windows.WindowsFileChooserUI$WindowsFileView.getIcon(WindowsFileChooserUI.java:1398)
>>>         at java.desktop/javax.swing.JFileChooser.getIcon(JFileChooser.java:1614)
>> 
>> 
>> This exception looks like a bug? I think if the file was not found then null is an expected result.
>> For now it can be bypassed by this:
>> 
>> 
>> import java.io.File;
>> import java.lang.Override;
>> 
>> import javax.swing.Icon;
>> import javax.swing.JFileChooser;
>> import javax.swing.SwingUtilities;
>> import javax.swing.UIManager;
>> import javax.swing.UnsupportedLookAndFeelException;
>> import javax.swing.filechooser.FileSystemView;
>> 
>> public class VirtualFileChooser {
>> 
>>     public static void main(String[] args) throws UnsupportedLookAndFeelException, ClassNotFoundException, InstantiationException, IllegalAccessException {
>>         UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");
>>         //UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel");
>> 
>> 
>>         SwingUtilities.invokeLater(() -> {
>>             JFileChooser chooser = new JFileChooser(new VirtualFileSystemView());
>> 
>>             int result = chooser.showOpenDialog(null);
>>             if (result == JFileChooser.APPROVE_OPTION) {
>>                 File selectedFile = chooser.getSelectedFile();
>>                 System.out.println("Selected: " + selectedFile.getAbsolutePath());
>>             }
>> ...
>
> Note that the bug occurs both in the list of roots (in the dropdown) and in the list of files.

@mrserb @aivanov-jdk Can u please re-review the updated changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2092813657

From amitkumar at openjdk.org  Fri May 16 11:35:29 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 16 May 2025 11:35:29 GMT
Subject: RFR: 8356643: Switching focus causes Segmentation Fault on zLinux
Message-ID: <hNZHzVKB-oP5gGoBw5fwCMcY7RDK96u924XSq66W8X8=.d19b4242-e2a4-42a1-91a0-38a5f924dd2e@github.com>

In OpenJKD code, for big endian architecture, `XIMPreeditState` is considered `unsigned int` whereas in `xlib` code it is `unsigned long` [source](https://github.com/mirror/libX11/blob/ff8706a5eae25b8bafce300527079f68a201d27f/include/X11/Xlib.h#L1267).

Now, openjdk compiled code pushes a frame and allots the address, just 4 bytes away, because it considers state to be a int, from the store `callers_sp` : 


2: /x $r15 = 0x3ff8137da20
3: x/2xg 0x3ff8137da20
0x3ff8137da20:	0x000003ff8137daf0	0x000003fffa2a9a86


`0x000003ff8137daf0` is callers sp for s390x.  And this is address for `state` : 

(gdb) p &state
$9 = (unsigned int *) 0x3ff8137da1c


which is just 4 byte away from the callers sp: 

(gdb) p/x 0x3ff8137da20 - 4 
$10 = 0x3ff8137da1c


Now while executing `_XimDecodePreeditState` method from xlib library where `state` is of type `unsigned long` we are going to emit a 8-byte instruction.: 

(gdb) disassemble _XimDecodePreeditState
Dump of assembler code for function _XimDecodePreeditState:
=> 0x000003ff989f3360 <+0>:	  llgf	%r1,8(%r2)
   0x000003ff989f3366 <+6>:	  lghi	%r2,1
   0x000003ff989f336a <+10>:	lg	%r1,0(%r3,%r1)
   0x000003ff989f3370 <+16>:	stg	%r1,0(%r4)  
   0x000003ff989f3376 <+22>:	br	%r14
End of assembler dump.


`0x000003ff989f3370 <+16>:	stg	%r1,0(%r4)  ` here `r4` is pointing the `state` variable. And the moment this write happens we will corrupt the first 4 byte of callers_sp, which will cause issue while the stack-unwinding. And at the end JVM will crash with segmentation fault. This is always reproducible with the test case provided in the JBS. And test only failed with compiler (c1 & c2) but passed always with interpreter.

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

Commit messages:
 - fix datatype mismatch

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

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

From aivanov at openjdk.org  Fri May 16 12:18:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 16 May 2025 12:18:59 GMT
Subject: RFR: 8355515: Clarify the purpose of forcePass() and forceFail()
 methods
In-Reply-To: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
References: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
Message-ID: <8gMOJCtNcN-Ou84pCTXuEV5h2AFnT0QMVOsYlPeD1EQ=.a967e9ae-1268-477a-8cb0-c503a7c63f39@github.com>

On Wed, 7 May 2025 12:28:52 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Clarified the purpose of forcePass() and forceFail() methods and recommended usage of these methods.
> 
> forcePass() contained an incorrect sample; it's addressed by [JDK-8355441](https://bugs.openjdk.org/browse/JDK-8355441).
> 
> The description of forceFail() has been expanded, too.
> 
> 
> A new section in the description of the PassFailJFrame added to describe forcePass() and forceFail().

Changes requested by aivanov (Reviewer).

After reading the description again, I started to wonder which adverb suits better: [?forcibly?](https://en.wiktionary.org/wiki/forcibly) or [?forcefully?](https://en.wiktionary.org/wiki/forcefully). Does any native English speaker have an opinion?

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 160:

> 158:  * the test will be forcefully Passed/Failed accordingly.
> 159:  * Code examples are given in the corresponding method javadoc.
> 160:  * <p>

Suggestion:

 *
 * <p id="forcePassAndFail">
 * For semi-automatic tests, use {@code forcePass} or
 * {@code forceFail} methods to forcibly pass or fail the test
 * when it's determined that the required conditions are already met
 * or cannot be met correspondingly.
 * These methods release {@code awaitAndCheck}, and
 * the test will complete successfully or fail.
 * <p>
 * Refer to examples of using these methods in the description of the
 * {@link #forcePass() forcePass} and {@link #forceFail() forceFail} methods.


The empty `<p>` in the end before a heading is redundant and will be ignored.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 1325:

> 1323:      * <p>
> 1324:      * Use this method in semi-automatic tests when
> 1325:      * the test determines that all/any of the conditions for passing the test are not met.

Suggestion:

     * <p>
     * Use this method in semi-automatic tests when
     * it is determined that the conditions for passing the test cannot be met.

I still don't like this phrase? but I can't come up with a different one.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 1342:

> 1340:      * <p>
> 1341:      * Use this method in semi-automatic tests when
> 1342:      * the test determines that all/any of the conditions for passing the test are not met.

Suggestion:

     * Use this method in semi-automatic tests when
     * it is determined that the conditions for passing the test cannot be met.

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

PR Review: https://git.openjdk.org/jdk/pull/25091#pullrequestreview-2846421361
PR Comment: https://git.openjdk.org/jdk/pull/25091#issuecomment-2886557839
PR Review Comment: https://git.openjdk.org/jdk/pull/25091#discussion_r2092914570
PR Review Comment: https://git.openjdk.org/jdk/pull/25091#discussion_r2092919697
PR Review Comment: https://git.openjdk.org/jdk/pull/25091#discussion_r2092931090

From aph at openjdk.org  Fri May 16 12:21:00 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 16 May 2025 12:21:00 GMT
Subject: RFR: 8343618: Stack smashing in awt_InputMethod.c on Linux s390x
In-Reply-To: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
References: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
Message-ID: <5fiGZhiUeut1V4c4CAVraAsa4-Lv-B5z8Bvt19UK4X8=.72aa6db8-b7c7-40d7-9928-aa8ccf9567f9@github.com>

On Mon, 24 Mar 2025 13:41:44 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> This fixes stack smashing issue in awt library on linux s390x. (jdk compiled with `-fstack-protector-strong`)
> 
> Fix is based on patch [submitted](https://mail.openjdk.org/pipermail/awt-dev/2019-July/015337.html) in JDK-8227919 review thread, rebased to master. They decided to go for Solaris only fix there, with [expected follow-up](https://mail.openjdk.org/pipermail/awt-dev/2019-July/015347.html) for linux/s390x. But that never happened.
> 
> I was not able to get response from original author for this issue, so I am creating PR myself.
> 
> **Testing:**
> I tested jdk with and without this fix on linux/s390x (using Xvfb). It fixes the issue (reproducer for this bug no longer crashes the JVM). I have also tried to run `jdk_awt` tests, where lot of tests was also affected by this. With this patch amount of failures dropped by ~100. 
> 
> Without fix:
> 
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/jdk:jdk_awt                             2171  1063   415     6   687 <<
> 
> 
> With fix
> 
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/jdk:jdk_awt                             2171  1162   316     6   687 <<
> 
> 
> Many tests are no longer crashing the VM:
> 
> -java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java                                                      Failed. Unexpected exit from test [exit code: 134]
> +java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java                                                      Passed. Execution successful
> 
> There seem to be few unstable tests in jdk_awt. (Ones that fail in one or another run, but seem unrelated to this fix)
> 
> I have not done any additional manual testing of XIM as did original author (in review thread mentioned higher), as I am not at all familiar with input method for Japanese (or other Asian characters), or how that supposed to work. (So I cannot verify that input of Asian characters works as expected on linux/s390x, but at least JVM no longer crashes.)

That looks right, and it should also be good for backports. The root cause must be a bug in Xlib, though. Has anyone found it, or reported it?

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24197#pullrequestreview-2846458677

From amitkumar at openjdk.org  Fri May 16 12:24:52 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 16 May 2025 12:24:52 GMT
Subject: RFR: 8343618: Stack smashing in awt_InputMethod.c on Linux s390x
In-Reply-To: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
References: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
Message-ID: <h0S1M4pHhKfRAuHYKu5UFiCGZq75-ChhVg3qyP3vRRg=.88e307c5-77ea-49d1-8371-8fa456e39246@github.com>

On Mon, 24 Mar 2025 13:41:44 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> This fixes stack smashing issue in awt library on linux s390x. (jdk compiled with `-fstack-protector-strong`)
> 
> Fix is based on patch [submitted](https://mail.openjdk.org/pipermail/awt-dev/2019-July/015337.html) in JDK-8227919 review thread, rebased to master. They decided to go for Solaris only fix there, with [expected follow-up](https://mail.openjdk.org/pipermail/awt-dev/2019-July/015347.html) for linux/s390x. But that never happened.
> 
> I was not able to get response from original author for this issue, so I am creating PR myself.
> 
> **Testing:**
> I tested jdk with and without this fix on linux/s390x (using Xvfb). It fixes the issue (reproducer for this bug no longer crashes the JVM). I have also tried to run `jdk_awt` tests, where lot of tests was also affected by this. With this patch amount of failures dropped by ~100. 
> 
> Without fix:
> 
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/jdk:jdk_awt                             2171  1063   415     6   687 <<
> 
> 
> With fix
> 
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/jdk:jdk_awt                             2171  1162   316     6   687 <<
> 
> 
> Many tests are no longer crashing the VM:
> 
> -java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java                                                      Failed. Unexpected exit from test [exit code: 134]
> +java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java                                                      Passed. Execution successful
> 
> There seem to be few unstable tests in jdk_awt. (Ones that fail in one or another run, but seem unrelated to this fix)
> 
> I have not done any additional manual testing of XIM as did original author (in review thread mentioned higher), as I am not at all familiar with input method for Japanese (or other Asian characters), or how that supposed to work. (So I cannot verify that input of Asian characters works as expected on linux/s390x, but at least JVM no longer crashes.)

LGTM. I did the effort again as this issue was not under cpu:s390 tag, So I missed it.

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

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24197#pullrequestreview-2846469382

From amitkumar at openjdk.org  Fri May 16 12:25:57 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 16 May 2025 12:25:57 GMT
Subject: RFR: 8356643: Switching focus causes Segmentation Fault on zLinux
In-Reply-To: <hNZHzVKB-oP5gGoBw5fwCMcY7RDK96u924XSq66W8X8=.d19b4242-e2a4-42a1-91a0-38a5f924dd2e@github.com>
References: <hNZHzVKB-oP5gGoBw5fwCMcY7RDK96u924XSq66W8X8=.d19b4242-e2a4-42a1-91a0-38a5f924dd2e@github.com>
Message-ID: <9KYgVTUFweo2qW69Tp6v3b9yw2NwA3BGcdIKR_LgJk8=.55bfdfc5-39c8-483a-b0b3-91a6126394f7@github.com>

On Fri, 16 May 2025 11:29:26 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> In OpenJKD code, for big endian architecture, `XIMPreeditState` is considered `unsigned int` whereas in `xlib` code it is `unsigned long` [source](https://github.com/mirror/libX11/blob/ff8706a5eae25b8bafce300527079f68a201d27f/include/X11/Xlib.h#L1267).
> 
> Now, openjdk compiled code pushes a frame and allots the address, just 4 bytes away, because it considers state to be a int, from the store `callers_sp` : 
> 
> 
> 2: /x $r15 = 0x3ff8137da20
> 3: x/2xg 0x3ff8137da20
> 0x3ff8137da20:	0x000003ff8137daf0	0x000003fffa2a9a86
> 
> 
> `0x000003ff8137daf0` is callers sp for s390x.  And this is address for `state` : 
> 
> (gdb) p &state
> $9 = (unsigned int *) 0x3ff8137da1c
> 
> 
> which is just 4 byte away from the callers sp: 
> 
> (gdb) p/x 0x3ff8137da20 - 4 
> $10 = 0x3ff8137da1c
> 
> 
> Now while executing `_XimDecodePreeditState` method from xlib library where `state` is of type `unsigned long` we are going to emit a 8-byte instruction.: 
> 
> (gdb) disassemble _XimDecodePreeditState
> Dump of assembler code for function _XimDecodePreeditState:
> => 0x000003ff989f3360 <+0>:	  llgf	%r1,8(%r2)
>    0x000003ff989f3366 <+6>:	  lghi	%r2,1
>    0x000003ff989f336a <+10>:	lg	%r1,0(%r3,%r1)
>    0x000003ff989f3370 <+16>:	stg	%r1,0(%r4)  
>    0x000003ff989f3376 <+22>:	br	%r14
> End of assembler dump.
> 
> 
> `0x000003ff989f3370 <+16>:	stg	%r1,0(%r4)  ` here `r4` is pointing the `state` variable. And the moment this write happens we will corrupt the first 4 byte of callers_sp, which will cause issue while the stack-unwinding. And at the end JVM will crash with segmentation fault. This is always reproducible with the test case provided in the JBS. And test only failed with compiler (c1 & c2) but passed always with interpreter.

closing in favour of https://github.com/openjdk/jdk/pull/24197

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

PR Comment: https://git.openjdk.org/jdk/pull/25266#issuecomment-2886572360

From amitkumar at openjdk.org  Fri May 16 12:25:57 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 16 May 2025 12:25:57 GMT
Subject: Withdrawn: 8356643: Switching focus causes Segmentation Fault on
 zLinux
In-Reply-To: <hNZHzVKB-oP5gGoBw5fwCMcY7RDK96u924XSq66W8X8=.d19b4242-e2a4-42a1-91a0-38a5f924dd2e@github.com>
References: <hNZHzVKB-oP5gGoBw5fwCMcY7RDK96u924XSq66W8X8=.d19b4242-e2a4-42a1-91a0-38a5f924dd2e@github.com>
Message-ID: <B-aakkGHLZnLNORtRu_ZF7cOhfPP67nniqIbCjjBwCU=.cca1a0fd-b141-4405-aeac-88a8e50ead24@github.com>

On Fri, 16 May 2025 11:29:26 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> In OpenJKD code, for big endian architecture, `XIMPreeditState` is considered `unsigned int` whereas in `xlib` code it is `unsigned long` [source](https://github.com/mirror/libX11/blob/ff8706a5eae25b8bafce300527079f68a201d27f/include/X11/Xlib.h#L1267).
> 
> Now, openjdk compiled code pushes a frame and allots the address, just 4 bytes away, because it considers state to be a int, from the store `callers_sp` : 
> 
> 
> 2: /x $r15 = 0x3ff8137da20
> 3: x/2xg 0x3ff8137da20
> 0x3ff8137da20:	0x000003ff8137daf0	0x000003fffa2a9a86
> 
> 
> `0x000003ff8137daf0` is callers sp for s390x.  And this is address for `state` : 
> 
> (gdb) p &state
> $9 = (unsigned int *) 0x3ff8137da1c
> 
> 
> which is just 4 byte away from the callers sp: 
> 
> (gdb) p/x 0x3ff8137da20 - 4 
> $10 = 0x3ff8137da1c
> 
> 
> Now while executing `_XimDecodePreeditState` method from xlib library where `state` is of type `unsigned long` we are going to emit a 8-byte instruction.: 
> 
> (gdb) disassemble _XimDecodePreeditState
> Dump of assembler code for function _XimDecodePreeditState:
> => 0x000003ff989f3360 <+0>:	  llgf	%r1,8(%r2)
>    0x000003ff989f3366 <+6>:	  lghi	%r2,1
>    0x000003ff989f336a <+10>:	lg	%r1,0(%r3,%r1)
>    0x000003ff989f3370 <+16>:	stg	%r1,0(%r4)  
>    0x000003ff989f3376 <+22>:	br	%r14
> End of assembler dump.
> 
> 
> `0x000003ff989f3370 <+16>:	stg	%r1,0(%r4)  ` here `r4` is pointing the `state` variable. And the moment this write happens we will corrupt the first 4 byte of callers_sp, which will cause issue while the stack-unwinding. And at the end JVM will crash with segmentation fault. This is always reproducible with the test case provided in the JBS. And test only failed with compiler (c1 & c2) but passed always with interpreter.

This pull request has been closed without being integrated.

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

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

From aivanov at openjdk.org  Fri May 16 12:45:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 16 May 2025 12:45:53 GMT
Subject: RFR: 8355515: Clarify the purpose of forcePass() and forceFail()
 methods
In-Reply-To: <Fw-P7sO3UgOco1VEBl0Xa_d3J8wn7qIE088fk0F9B20=.54c4d7b3-116a-41d5-a672-b0dc5b598e25@github.com>
References: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
 <Fw-P7sO3UgOco1VEBl0Xa_d3J8wn7qIE088fk0F9B20=.54c4d7b3-116a-41d5-a672-b0dc5b598e25@github.com>
Message-ID: <sCudOwpHPGng1jArvWmzpH_3pOkXB4VZCYOhDm5ia1Q=.0b1f0362-91da-4194-b1ac-796da55f7a45@github.com>

On Mon, 12 May 2025 17:59:51 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Looks reasonable. Using the blob version of the link to GH as a code example seems unusual but it works.

It's the simplest way, and an explicit commit ensures the link always points to the line where the method is used.

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

PR Comment: https://git.openjdk.org/jdk/pull/25091#issuecomment-2886615942

From azvegint at openjdk.org  Fri May 16 13:50:44 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 16 May 2025 13:50:44 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place
Message-ID: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>

The issue is the inability to move the mouse cursor using `java.awt.Robot` on Oracle Linux 10 (which has not yet been released). FIY, the OL10 is no longer provides an Xorg session, so only Wayland is available.
It is a JCK conformance failure. 

---

In our robot implementation, we emulate mouse/keyboard actions using the XTEST extension protocol.

The XTEST calls are now wired to [libEI](https://libinput.pages.freedesktop.org/libei/api/index.html):

1.

It now asks for a user confirmation to allow interaction, so we should now be able to click on native applications, window titles, etc.

However, our robot implementation is mostly uses XTEST, but there is an exception:
for mouse move we use XWarpPointer, which is not part of the XTEST, thus it is not propagated outside of Xwayland server.

So we have a situation where mouse is moving only inside Xwayland server, and we see the mouse enter/exit events,
on mouse press we call XTestFakeButtonEvent and it is handled by libei,
so the click happens where is the actual mouse cursor is in the system. That is why the test fails.

To avoid this situation we should use XTestFakeMotionEvent for mouseMove in Xwayland case.

It would be a simple solution, but


2.

This permission granted by a user doesn't persist across reboots, it timeouts after a period of inactivity.

It still seems to conform to the specifications, but we will not be able to conveniently run automated tests in this case.

---

So as a solution we can switch the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
It has session and `restore_token` functionality to keep permissions granted by a user, similar to what we use in a [Screencast](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html) for taking screenshots.
Most of the code can be reused, and it has everything we need.


* It is only enabled by default on Wayland and Gnome Shell 47 and higher due to XTEST API complications that first arose in this version. For earlier versions, Screencast is used instead.
* A new value has been introduced for the `awt.robot.screenshotMethod` system property - `dbusRemoteDesktop`. It works on Ubuntu 24.04 with Gnome 46, but is not enabled by default.
* extra mouse buttons are not supported yet, [JDK-8357142](https://bugs.openjdk.org/browse/JDK-8357142)
* Since we are now moving the mouse using a non-X11 API and `MouseInfo.getPointerInfo().getLocation()` uses the X11 API to get the mouse pointer location, `XRobotPeer#mouseMove` still calls the old API to update the mouse position within the XWayland server.
This workaround is necessary to pass the another conformance test.

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

Commit messages:
 - 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to wrong place

Changes: https://git.openjdk.org/jdk/pull/25265/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25265&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351907
  Stats: 941 lines in 13 files changed: 804 ins; 51 del; 86 mod
  Patch: https://git.openjdk.org/jdk/pull/25265.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25265/head:pull/25265

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

From vdyakov at openjdk.org  Fri May 16 15:52:53 2025
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Fri, 16 May 2025 15:52:53 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place
In-Reply-To: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
Message-ID: <zNDhhweDTWlOrfRGCzs-s_hcrtzP0Ru9iKhFtdI5Q-o=.ad4f9dd4-39fe-4262-8f57-e59f9fc150e3@github.com>

On Fri, 16 May 2025 10:40:22 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The issue is the inability to move the mouse cursor using `java.awt.Robot` on Oracle Linux 10 (which has not yet been released). FIY, the OL10 is no longer provides an Xorg session, so only Wayland is available.
> It is a JCK conformance failure. 
> 
> ---
> 
> In our robot implementation, we emulate mouse/keyboard actions using the XTEST extension protocol.
> 
> The XTEST calls are now wired to [libEI](https://libinput.pages.freedesktop.org/libei/api/index.html):
> 
> 1.
> 
> It now asks for a user confirmation to allow interaction, so we should now be able to click on native applications, window titles, etc.
> 
> However, our robot implementation is mostly uses XTEST, but there is an exception:
> for mouse move we use XWarpPointer, which is not part of the XTEST, thus it is not propagated outside of Xwayland server.
> 
> So we have a situation where mouse is moving only inside Xwayland server, and we see the mouse enter/exit events,
> on mouse press we call XTestFakeButtonEvent and it is handled by libei,
> so the click happens where is the actual mouse cursor is in the system. That is why the test fails.
> 
> To avoid this situation we should use XTestFakeMotionEvent for mouseMove in Xwayland case.
> 
> It would be a simple solution, but
> 
> 
> 2.
> 
> This permission granted by a user doesn't persist across reboots, it timeouts after a period of inactivity.
> 
> It still seems to conform to the specifications, but we will not be able to conveniently run automated tests in this case.
> 
> ---
> 
> So as a solution we can switch the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
> It has session and `restore_token` functionality to keep permissions granted by a user, similar to what we use in a [Screencast](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html) for taking screenshots.
> Most of the code can be reused, and it has everything we need.
> 
> 
> * It is only enabled by default on Wayland and Gnome Shell 47 and higher due to XTEST API complications that first arose in this version. For earlier versions, Screencast is used instead.
> * A new value has been introduced for the `awt.robot.screenshotMethod` system property - `dbusRemoteDesktop`. It works on Ubuntu 24.04 with Gnome 46, but is not enabled by default.
> * extra mouse buttons are not supported yet, [JDK-8357142](https://bugs.openjdk.org/browse/JDK-8357142)
> * Since we are now moving the mouse using a non-X11 API and `MouseInfo.getPointerInfo().getLo...

@honkar-jdk @prrace please review

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

PR Comment: https://git.openjdk.org/jdk/pull/25265#issuecomment-2887102044

From prr at openjdk.org  Fri May 16 18:21:59 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 May 2025 18:21:59 GMT
Subject: RFR: 8343618: Stack smashing in awt_InputMethod.c on Linux s390x
In-Reply-To: <5fiGZhiUeut1V4c4CAVraAsa4-Lv-B5z8Bvt19UK4X8=.72aa6db8-b7c7-40d7-9928-aa8ccf9567f9@github.com>
References: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
 <5fiGZhiUeut1V4c4CAVraAsa4-Lv-B5z8Bvt19UK4X8=.72aa6db8-b7c7-40d7-9928-aa8ccf9567f9@github.com>
Message-ID: <bQ6w0gWIgM4nzhRfaKzH8zGPmDZatws7RFN-wzcYbd4=.3ffaae38-ef06-4de4-bfb3-c3daa5c1b1ba@github.com>

On Fri, 16 May 2025 12:18:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

> That looks right, and it should also be good for backports. The root cause must be a bug in Xlib, though. Has anyone found it, or reported it?

That was my thought too  : "Looks reasonable although it seems an odd behaviour (bug?) of XGetICValues"

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

PR Comment: https://git.openjdk.org/jdk/pull/24197#issuecomment-2887398135

From prr at openjdk.org  Fri May 16 18:30:56 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 May 2025 18:30:56 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <lTHWCVus_F1QuH_rk-EzUlQPPTFn2P6qq4PPF11jtAk=.15a99668-cf50-4395-a75e-6120757041d2@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <lTHWCVus_F1QuH_rk-EzUlQPPTFn2P6qq4PPF11jtAk=.15a99668-cf50-4395-a75e-6120757041d2@github.com>
Message-ID: <W_NVp55o8MtQIzk8E9rZQDRFC1EGT0nwRcMQH0ZWytk=.b261a590-81bd-491d-bc83-da61a4e42348@github.com>

On Wed, 14 May 2025 03:31:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356049
>
> src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 131:
> 
>> 129:             }
>> 130:         } catch (UnsupportedAudioFileException e) {
>> 131:             // not an audio file
> 
> This code path seems will not be (rarely) executed?
> The midi file will be handled above by the AudioSystem.getAudioInputStream() via SoftMidiAudioFileReader provider? But if converted midi->sampled data cannot be played via audio device then it might be useful to try MidiDevice, but I do not think it can be done by catching UnsupportedAudioFileException.

Perhaps but that's the behaviour today and I don't see the need to change it in order to provide a different API to reach here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093505994

From prr at openjdk.org  Fri May 16 18:30:59 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 May 2025 18:30:59 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
Message-ID: <EATHedwrSHzqKljRBzUt0iVkr7YntxomtTow4qDnTTA=.3ece1cfd-e7c0-4d77-9db2-f6ad7628fdf1@github.com>

On Tue, 13 May 2025 19:32:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356049
>
> src/java.desktop/share/classes/javax/sound/SoundClip.java line 35:
> 
>> 33: /**
>> 34:  * The {@code SoundClip} class is a simple abstraction for playing a sound clip.
>> 35:  * It will play any format that is recognized by the {@code javax.sound} API,
> 
> I think we should mention in the doc that this is applicable for small audio files since we will load all data into the memory.

What is small ? I would not want to try to define that.
Since the application supplies the file it is in control of that and should know what it is supplying.
Lots of APIs read files and don't mention that they need enough memory to hold the data in the file.
The Applet case was historically even more constrained (64 Mb heap for applets once upon a time) and
it seemed to be fine without this.

> src/java.desktop/share/classes/javax/sound/SoundClip.java line 45:
> 
>> 43:  * @since 25
>> 44:  */
>> 45: public final class SoundClip {
> 
> What about considering a different name, such as AudioClip with a static method like AudioClip.create(...)? or maybe Audio....Player?

I picked SoundClip because AudioClip over AudioClip for a few reasons. Mapping to the Sound API name for one and because there's already an AudioClip.  "Player" might be construed as a UI component.

> src/java.desktop/share/classes/javax/sound/SoundClip.java line 63:
> 
>> 61:     public static SoundClip createSoundClip(File file) throws IOException {
>> 62:         if (file == null) {
>> 63:             throw new IllegalArgumentException("file must not be null");
> 
> Most of the APIs in javax.sound.* throw NullPointerException for null arguments and IllegalArgumentException for other invalid parameters.

Using NPE hadn't escaped me.
I think that was probably common practice back then, but  I think IAE is better here.

> src/java.desktop/share/classes/javax/sound/SoundClip.java line 78:
> 
>> 76:      * of this class is a no-op.
>> 77:      */
>> 78:     public synchronized boolean canPlay() {
> 
> Should we perhaps document the multithreaded use of Clip? Do we really need all these synchronized keywords in the file?

The API calls are best protected this way just like the ones in AudioClip were. There's no advantage in removing them. I don't think there's anything to document.

> src/java.desktop/share/classes/javax/sound/package-info.java line 43:
> 
>> 41:  * @since 25
>> 42:  */
>> 43: package javax.sound;
> 
> Why javax.sound and not sampled? do we want to support midi files by SoundClip as well?

That and a top-level is easier to find. I did spend some time debating with myself over whether to create a new package just for this class but it made the most sense.

> test/jdk/javax/sound/SoundClip/SoundClipTest.java line 34:
> 
>> 32:  * @key sound headful
>> 33:  * @summary basic testing of javax.sound.SoundClip
>> 34:  * @run main/othervm SoundClipTest javasound.wav
> 
> What about a non-existent or broken file? Should we check for an IOException in that case?

I could do a minor test enhancement for this case. I don't think it would be an IOException for a broken file, it would just not be playable.

> test/jdk/javax/sound/SoundClip/SoundClipTest.java line 41:
> 
>> 39:     public static void main(String[] args) throws Exception {
>> 40: 
>> 41:         if (!isSoundcardInstalled()) {
> 
> Why we cannot check that the playing sound is a no-op in this case, as specified?

The intent is that this should always run on a system with sound. It just might happen that it isn't, so this isn't a case to start adding tests. 
That might be better done by feeding it unplayable data.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087653970
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087618093
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087623944
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087626652
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087628133
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087631361
PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087647725

From prr at openjdk.org  Fri May 16 18:31:00 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 May 2025 18:31:00 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <Ys8Ja-yLiBLnARGD4Z8BHwRD2TkD551lJGws9xd1V_o=.7d84d0b3-eb34-4455-9efa-467c7f08daab@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <XayTq0y7nzJiJ4mbRYd5QZLLu2bgJ1zgGydnvW0kvLk=.82ee972d-3906-4c06-b6f6-dfcc9d7c537b@github.com>
 <OYyNZ91Uu-nhfJYWA63p82m34ZcffwlnR3_V4sqWpBM=.a50a5a1d-8e37-4585-87de-996cdc638cec@github.com>
 <Ys8Ja-yLiBLnARGD4Z8BHwRD2TkD551lJGws9xd1V_o=.7d84d0b3-eb34-4455-9efa-467c7f08daab@github.com>
Message-ID: <rf7VnTaKYP1yM-qR98IeIYdSIp-rqyLqOGQYa7AETCI=.212cdd78-1273-4333-8bff-edea4cdb354a@github.com>

On Tue, 13 May 2025 19:45:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Or maybe we can add this API to AudioSystem/clip?
>> Old code
>> 
>>     File file = new File(file);
>>     AudioInputStream audioIn = AudioSystem.getAudioInputStream(...file...);  
>>     Clip clip = AudioSystem.getClip();
>>     clip.open(audioIn);
>>     clip.start();
>> 
>> new code:
>> 
>>     File file = new File(file);
>>     AudioClip clip = AudioSystem.getAudioClip(...file...);
>>     clip.play()/canPlay/loop/stop;
>
> or maybe inject all these simple methods into `javax.sound.sampled.Clip` or its subclass/superclass.

> Can we gain any benefits by using Path instead?

You had mentioned that and I looked but I didn't see any compelling reason.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2087621643

From prr at openjdk.org  Fri May 16 18:31:00 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 May 2025 18:31:00 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <uRKpk8hijsqouGGurND49ScU9EBpnfY2GH_qsOJaqC0=.e3a08246-644d-484c-b930-0ec6409ab9d0@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <lTHWCVus_F1QuH_rk-EzUlQPPTFn2P6qq4PPF11jtAk=.15a99668-cf50-4395-a75e-6120757041d2@github.com>
 <bsOG3L7WJL2amGAwkxvMg2mcoIsJgbWPqAAu6afQVQE=.e4acac34-24c9-4d30-ac8a-a8aa8af54e71@github.com>
 <uRKpk8hijsqouGGurND49ScU9EBpnfY2GH_qsOJaqC0=.e3a08246-644d-484c-b930-0ec6409ab9d0@github.com>
Message-ID: <deHe7hKJaok55bjhXd-WkTVjuE97JbruA1BFyS31QEY=.c02cea2b-eda2-4e25-b014-a1cbfec8a454@github.com>

On Wed, 14 May 2025 04:40:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> And still do we want to have all of them synchronized? so the app may affect these methods by synchronized(soundClip)?
>
>>     * Each time this method is called, the clip is restarted from the beginning.
> Note that calls within 30 ms are ignored: https://github.com/openjdk/jdk/blob/2c4e8d211a030c85488e656a9a851d10dd0f9c11/src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java#L158

I don't think any of the above requires changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093507736

From prr at openjdk.org  Fri May 16 18:35:54 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 May 2025 18:35:54 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
Message-ID: <fDCtY1Zjp0_fvPv01xzD8QM-_IYFi-VO_Rza7EfDO3E=.883f1b8d-b744-4cf8-9105-435d2317e97f@github.com>

On Wed, 14 May 2025 03:50:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> What is small ? I would not want to try to define that.
>> Since the application supplies the file it is in control of that and should know what it is supplying.
>> Lots of APIs read files and don't mention that they need enough memory to hold the data in the file.
>> The Applet case was historically even more constrained (64 Mb heap for applets once upon a time) and
>> it seemed to be fine without this.
>
> Example of memory requirement: https://github.com/openjdk/jdk/blob/2c4e8d211a030c85488e656a9a851d10dd0f9c11/src/java.desktop/share/classes/javax/sound/sampled/Clip.java#L34

That's not defining small. Its about another topic entirely : positioning.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093514437

From prr at openjdk.org  Fri May 16 18:39:58 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 May 2025 18:39:58 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
Message-ID: <eocjb-LWD-iLCk7UQ-23eQZ-mustsyIDpvIFRONYTwI=.2730b2be-ebf4-4d5e-8e08-5f2bb126d7a3@github.com>

On Wed, 14 May 2025 04:01:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I picked SoundClip because AudioClip over AudioClip for a few reasons. Mapping to the Sound API name for one and because there's already an AudioClip.  "Player" might be construed as a UI component.
>
> Could having both javax.sound.SoundClip and javax.sound.sampled.Clip cause confusion?

I don't see a big problem here. Naming is a choice and SoundClip is a sensible choice here and anything else would just be a different choice which someone else might disagree with.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093518982

From prr at openjdk.org  Fri May 16 18:45:54 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 May 2025 18:45:54 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <TZaGuWgAMowQY249bB-gKPcRYEDGdYPgr_o-TH-T31M=.47698e31-16d1-4ef6-af0f-d325c9c8e65b@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
 <HwKf3rDD39LT_vh0XAjjD8u8k7SaSHOdiduoTsgXzLg=.eef81151-e671-4640-8c81-d0dfb4b25c9b@github.com>
 <TZaGuWgAMowQY249bB-gKPcRYEDGdYPgr_o-TH-T31M=.47698e31-16d1-4ef6-af0f-d325c9c8e65b@github.com>
Message-ID: <3-KbtEsAwLLS8Ge__LmkptkvGdoQZ7sBTLWDeNFaZIw=.1b3f6fa1-bffe-448a-a3d7-3a2ebdbc9f79@github.com>

On Wed, 14 May 2025 18:34:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I respectfully disagree for a few reasons:
> 
> > NullPointerException, on the other hand, indicates the code accessed an object but the reference was null. (This could occur, for example, if parameters aren't validated.)
> 
> Implementation and documentation of Objects.requireNonNull including its use in our codebase and in newly added code suggests that it is intended for validating parameters before dereferencing them. This contradicts the strict separation you're implying.
> 
> Additionally as I mentioned earlier the javax.sound.** code already uses npe for null parameter checks. Introducing a mix of exception styles would reduce consistency.

The verbiage on those "sub" packages says it applies to those sub-packages not others.
Moreover it was not there in the original Java Sound API docs.
There was no "careful thought" given to NPE being the way to do things.
It was added to avoid having to explicitly retroactively specify @throws NPE on however many methods didn't actually declare it in their spec and "accidentally" threw NPE.
So not a design practice to follow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093526197

From serb at openjdk.org  Fri May 16 19:11:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 16 May 2025 19:11:50 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place
In-Reply-To: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
Message-ID: <8JCrFisXgNtBSXxxVA_QkcG3LObiggKIPfEBVdb3NO0=.47a846aa-4a05-4a9b-85e7-5cd1d3b146eb@github.com>

On Fri, 16 May 2025 10:40:22 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The issue is the inability to move the mouse cursor using `java.awt.Robot` on Oracle Linux 10 (which has not yet been released). FIY, the OL10 is no longer provides an Xorg session, so only Wayland is available.
> It is a JCK conformance failure. 
> 
> ---
> 
> In our robot implementation, we emulate mouse/keyboard actions using the XTEST extension protocol.
> 
> The XTEST calls are now wired to [libEI](https://libinput.pages.freedesktop.org/libei/api/index.html):
> 
> 1.
> 
> It now asks for a user confirmation to allow interaction, so we should now be able to click on native applications, window titles, etc.
> 
> However, our robot implementation is mostly uses XTEST, but there is an exception:
> for mouse move we use XWarpPointer, which is not part of the XTEST, thus it is not propagated outside of Xwayland server.
> 
> So we have a situation where mouse is moving only inside Xwayland server, and we see the mouse enter/exit events,
> on mouse press we call XTestFakeButtonEvent and it is handled by libei,
> so the click happens where is the actual mouse cursor is in the system. That is why the test fails.
> 
> To avoid this situation we should use XTestFakeMotionEvent for mouseMove in Xwayland case.
> 
> It would be a simple solution, but
> 
> 
> 2.
> 
> This permission granted by a user doesn't persist across reboots, it timeouts after a period of inactivity.
> 
> It still seems to conform to the specifications, but we will not be able to conveniently run automated tests in this case.
> 
> ---
> 
> So as a solution we can switch the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
> It has session and `restore_token` functionality to keep permissions granted by a user, similar to what we use in a [Screencast](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html) for taking screenshots.
> Most of the code can be reused, and it has everything we need.
> 
> 
> * It is only enabled by default on Wayland and Gnome Shell 47 and higher due to XTEST API complications that first arose in this version. For earlier versions, Screencast is used instead.
> * A new value has been introduced for the `awt.robot.screenshotMethod` system property - `dbusRemoteDesktop`. It works on Ubuntu 24.04 with Gnome 46, but is not enabled by default.
> * extra mouse buttons are not supported yet, [JDK-8357142](https://bugs.openjdk.org/browse/JDK-8357142)
> * Since we are now moving the mouse using a non-X11 API and `MouseInfo.getPointerInfo().getLo...

src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java line 259:

> 257:         try {
> 258:             Process process =
> 259:                 new ProcessBuilder("/usr/bin/gnome-shell", "--version")

Before the patch the getGnomeShellMajorVersion was guarded by the "gnome.equals(getDesktop()))" should we do the same in XdgDesktopPortal? or maybe we can at least check if gnome-shell exists so we don't waste time launching it? or is ProcessBuilder's performance good enough?

BTW how it is expected to work on KDE + wayland?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25265#discussion_r2093555459

From aivanov at openjdk.org  Fri May 16 20:09:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 16 May 2025 20:09:57 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v2]
In-Reply-To: <JBqag_eOA8EpegeuHHyWg9X4sxDcuaDBx4wfLH_Gkjw=.bcb5562f-6f43-4294-be9a-791726e819a7@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <JBqag_eOA8EpegeuHHyWg9X4sxDcuaDBx4wfLH_Gkjw=.bcb5562f-6f43-4294-be9a-791726e819a7@github.com>
Message-ID: <I2gu3h6HaCY36funo-uLbP-vtqTk49Mn8Ey_3Tb2vOk=.81f32408-dd1f-4e89-876e-4c04092f2247@github.com>

On Tue, 13 May 2025 10:34:38 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The rendering of the directory names are handled as JLabel w.r.t Look and feel and also either Details/List view. Though FilePane creates basic rendering for these two few Look and Feel define their own renderers and also ComboBox Directory directory name view. Since HTML filtering is not taken care in any of these renderers, JLabel renders them as HTML document if nothing is set or specified.
>> The fix is to get "html.disable" property from JFileChooser and set the same to JLabel component which renders and set Directory name. Hence applications can either enable/disable this property and control HTML rendering of directory name.
>
> Tejesh R 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://git.openjdk.java.net/jdk into branch_8139228
>  - Fix for windows L&F
>  - Fix + Manual test

Changes requested by aivanov (Reviewer).

src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java line 1195:

> 1193:             setIcon(fc.getIcon(file));
> 1194:             setEnabled(isSelectableInList(file));
> 1195:             this.putClientProperty("html.disable", getFileChooser().getClientProperty("html.disable"));

Suggestion:

            putClientProperty("html.disable", getFileChooser().getClientProperty("html.disable"));

No method call above uses explicit `this`, I see no reason to use it here either.

This comment applies to all the modified files.

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

> 1236:             setText(text);
> 1237:             this.putClientProperty("html.disable", getFileChooser().getClientProperty("html.disable"));
> 1238:             return this;

Be consistent at least inside one file. Here you removed the blank line, but below at 1632?1635 you preserved the blank line.

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

> 1633:             this.putClientProperty("html.disable", getFileChooser().getClientProperty("html.disable"));
> 1634: 
> 1635:             return this;

I prefer this style everywhere: all the code that sets up the component, a blank line followed by the `return` statement.

I'd add a blank line before `putClientProperty` as well ? setting the `"html.disable"` property isn't the part of previous statements which configure the renderer component one way or another, and, with blank lines around this call, it will stand out in the code.

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 68:

> 66:                     .instructions(INSTRUCTIONS)
> 67:                     .columns(45)
> 68:                     .testUI(initialize())

In majority of cases, you should pass a method reference rather than the result of a method call to `testUI`.

As it's written, the `initialize` is executed on the main thread, and its result?the list frames?is passed to `PassFailJFrame`.

What you actually want is `HTMLFileName::initialize`. In this case, the `PassFailJFrame` framework will call the `initialize` method on EDT when the time to create UI comes.

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 69:

> 67:                     .columns(45)
> 68:                     .testUI(initialize())
> 69:                     .position(PassFailJFrame.Position.TOP_LEFT_CORNER)

Suggestion:

                    .positionTestUIRightColumn()

I suggest using [**`positionTestUIRightColumnCentered`**](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.Builder.html#positionTestUIRightColumnCentered()) to lay out the entire test UI in the centre of the screen.

Since two file choosers take quite a lot of space, the file chooser at the bottom doesn't fit the screen if you use  [`positionTestUIRightColumn`](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.Builder.html#positionTestUIRightColumn()).

Alternatively, you can choose a horizontal layout with [`positionTestUIBottomRowCentered`](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.Builder.html#positionTestUIBottomRowCentered()).

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 79:

> 77:     }
> 78: 
> 79:     public static List<JFrame> initialize() {

Suggestion:

    private static List<JFrame> initialize() {

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

> 82:         String fileName = homeDir + File.separator +
> 83:                 "<html><h1 color=#ff00ff><font face=\"Comic Sans MS\">Testing Name";
> 84:         directory = new File(fileName);

You shouldn't create the files in the home directory of the user any way. Create them in the current directory which is a scratch directory when the test is run with jtreg; the contents of the scratch directory is automatically removed by jtreg when the test exits, even if the test itself fails to remove its own temporary files.

Yet if you create the files in the user's home, all these files and directories will be still be around if anything goes awry in the test.

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 85:

> 83:                 "<html><h1 color=#ff00ff><font face=\"Comic Sans MS\">Testing Name";
> 84:         directory = new File(fileName);
> 85:         directory.mkdir();

Do you need the directory at all?

Use `VirtualFileSystemView` for all platforms. The fact that it's possible to create files with HTML tags in the name is irrelevant to the test.

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 96:

> 94:             jfc = new JFileChooser(homeDir);
> 95:             jfc_HTML_Enabled = new JFileChooser(homeDir);
> 96:         }

I suggest creating a method that creates one file chooser placed in a frame; pass a boolean parameter to specify whether to set the `"html.disable"` property to `false` or keep its default value of `true`.

Then your `initialize` method would be as simple as a single return statement:


    private static List<JFrame> initialize() {
        return List.of(createFileChooser(true), createFileChooser(false));
    }

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 107:

> 105:     }
> 106: 
> 107:     static class VirtualFileSystemView extends FileSystemView {

Suggestion:

    private static class VirtualFileSystemView extends FileSystemView {

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

PR Review: https://git.openjdk.org/jdk/pull/24439#pullrequestreview-2847459647
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2093571535
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2093578359
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2093586784
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2093592420
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2093595668
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2093604829
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2093609644
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2093604201
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2093617717
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2093604589

From azvegint at openjdk.org  Fri May 16 20:45:39 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 16 May 2025 20:45:39 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v2]
In-Reply-To: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
Message-ID: <XRQDe9qB8vtFFeCAbMRxRr5lB4vBCaFCAkDc9autvRc=.597810e7-8ce4-4879-bcf6-a4739273ccdf@github.com>

> The issue is the inability to move the mouse cursor using `java.awt.Robot` on Oracle Linux 10 (which has not yet been released). FIY, the OL10 is no longer provides an Xorg session, so only Wayland is available.
> It is a JCK conformance failure. 
> 
> ---
> 
> In our robot implementation, we emulate mouse/keyboard actions using the XTEST extension protocol.
> 
> The XTEST calls are now wired to [libEI](https://libinput.pages.freedesktop.org/libei/api/index.html):
> 
> 1.
> 
> It now asks for a user confirmation to allow interaction, so we should now be able to click on native applications, window titles, etc.
> 
> However, our robot implementation is mostly uses XTEST, but there is an exception:
> for mouse move we use XWarpPointer, which is not part of the XTEST, thus it is not propagated outside of Xwayland server.
> 
> So we have a situation where mouse is moving only inside Xwayland server, and we see the mouse enter/exit events,
> on mouse press we call XTestFakeButtonEvent and it is handled by libei,
> so the click happens where is the actual mouse cursor is in the system. That is why the test fails.
> 
> To avoid this situation we should use XTestFakeMotionEvent for mouseMove in Xwayland case.
> 
> It would be a simple solution, but
> 
> 
> 2.
> 
> This permission granted by a user doesn't persist across reboots, it timeouts after a period of inactivity.
> 
> It still seems to conform to the specifications, but we will not be able to conveniently run automated tests in this case.
> 
> ---
> 
> So as a solution we can switch the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
> It has session and `restore_token` functionality to keep permissions granted by a user, similar to what we use in a [Screencast](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html) for taking screenshots.
> Most of the code can be reused, and it has everything we need.
> 
> 
> * It is only enabled by default on Wayland and Gnome Shell 47 and higher due to XTEST API complications that first arose in this version. For earlier versions, Screencast is used instead.
> * A new value has been introduced for the `awt.robot.screenshotMethod` system property - `dbusRemoteDesktop`. It works on Ubuntu 24.04 with Gnome 46, but is not enabled by default.
> * extra mouse buttons are not supported yet, [JDK-8357142](https://bugs.openjdk.org/browse/JDK-8357142)
> * Since we are now moving the mouse using a non-X11 API and `MouseInfo.getPointerInfo().getLo...

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

  Only call getGnomeShellMajorVersion when the desktop is Gnome.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25265/files
  - new: https://git.openjdk.org/jdk/pull/25265/files/f75e0ed7..5d08133e

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

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

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

From azvegint at openjdk.org  Fri May 16 20:45:39 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 16 May 2025 20:45:39 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v2]
In-Reply-To: <8JCrFisXgNtBSXxxVA_QkcG3LObiggKIPfEBVdb3NO0=.47a846aa-4a05-4a9b-85e7-5cd1d3b146eb@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <8JCrFisXgNtBSXxxVA_QkcG3LObiggKIPfEBVdb3NO0=.47a846aa-4a05-4a9b-85e7-5cd1d3b146eb@github.com>
Message-ID: <tYVS4MtY0OV0S2YNjJBbykPzFhX06K-udfZjhRdCCn8=.4b4c573d-af88-405c-ab86-332299fae4f9@github.com>

On Fri, 16 May 2025 19:09:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Before the patch the getGnomeShellMajorVersion was guarded by the "gnome.equals(getDesktop()))" should we do the same in XdgDesktopPortal? 

Thanks, this is a good point, updated.

>  or maybe we can at least check if gnome-shell exists so we don't waste time launching it? or is ProcessBuilder's performance good enough?

It's actually pretty fast for a non-existent binary, only 1 ms
The `getGnomeShellMajorVersion` check takes about 33 ms  on my machine when the binary is in the system.

Alternatively we can try to receive this version via DBUS API and see if it is faster.
It is definitely available through introspection:
`gdbus introspect --session --dest org.gnome.Shell --object-path /org/gnome/Shell | grep ShellVersion`

But not as part of this issue, [JDK-8357174](https://bugs.openjdk.org/browse/JDK-8357174) created.

> BTW how it is expected to work on KDE + wayland?

It is not a supported configuration.However, when I tested it a while ago, it only worked in a single-screen scenario for the Screencast.
There was an issue with the screen streams; they did not specify their `x` and `y` coordinates.
This prevented the correct arrangement of multiple screens.
I don't know if this has been fixed, but the issue is addressed in our code here:

https://github.com/openjdk/jdk/blob/3dd34517000e4ce1a21619922c62c025f98aad44/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L132-L155

In this case, the Screencast is simply disabled.

The Remote Desktop uses the same streams from Screencast portal to control the mouse position.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25265#discussion_r2093639881

From serb at openjdk.org  Fri May 16 20:53:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 16 May 2025 20:53:54 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <fDCtY1Zjp0_fvPv01xzD8QM-_IYFi-VO_Rza7EfDO3E=.883f1b8d-b744-4cf8-9105-435d2317e97f@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
 <fDCtY1Zjp0_fvPv01xzD8QM-_IYFi-VO_Rza7EfDO3E=.883f1b8d-b744-4cf8-9105-435d2317e97f@github.com>
Message-ID: <7uFWKUMMkDky6Qy3Z5-DW7tPyAMIXj3RDP6XbvQi_1s=.b2a9faea-99e6-4142-a159-d2e68280cfbd@github.com>

On Fri, 16 May 2025 18:33:01 GMT, Phil Race <prr at openjdk.org> wrote:

>> Example of memory requirement: https://github.com/openjdk/jdk/blob/2c4e8d211a030c85488e656a9a851d10dd0f9c11/src/java.desktop/share/classes/javax/sound/sampled/Clip.java#L34
>
> That's not defining small. Its about another topic entirely : positioning.

But then you may get exactly the same bug we discussed recently about converting midi files into audio stream and loading all that into the memory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093663955

From serb at openjdk.org  Fri May 16 20:53:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 16 May 2025 20:53:55 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <3-KbtEsAwLLS8Ge__LmkptkvGdoQZ7sBTLWDeNFaZIw=.1b3f6fa1-bffe-448a-a3d7-3a2ebdbc9f79@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
 <HwKf3rDD39LT_vh0XAjjD8u8k7SaSHOdiduoTsgXzLg=.eef81151-e671-4640-8c81-d0dfb4b25c9b@github.com>
 <TZaGuWgAMowQY249bB-gKPcRYEDGdYPgr_o-TH-T31M=.47698e31-16d1-4ef6-af0f-d325c9c8e65b@github.com>
 <3-KbtEsAwLLS8Ge__LmkptkvGdoQZ7sBTLWDeNFaZIw=.1b3f6fa1-bffe-448a-a3d7-3a2ebdbc9f79@github.com>
Message-ID: <esa-IyM9MbrXK8vdB6zuduTROJLn3ZGwG1bb-yg0Ws8=.90cfc1d7-1140-47c6-a471-4991a7f8ca37@github.com>

On Fri, 16 May 2025 18:43:33 GMT, Phil Race <prr at openjdk.org> wrote:

>It was added to avoid having to explicitly retroactively specify @throws NPE on however many methods didn't actually declare it in their spec and "accidentally" threw NPE.

No, in many cases NPE was explicitly added to many methods in that packages, even if npe had not been thrown before. It is better to use NPE. Check how many "@throws NullPointerException if XXX is {@code null}" is in that code, and compare that with usage of IllegalArgumentException.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093662600

From serb at openjdk.org  Fri May 16 21:00:59 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 16 May 2025 21:00:59 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <W_NVp55o8MtQIzk8E9rZQDRFC1EGT0nwRcMQH0ZWytk=.b261a590-81bd-491d-bc83-da61a4e42348@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <lTHWCVus_F1QuH_rk-EzUlQPPTFn2P6qq4PPF11jtAk=.15a99668-cf50-4395-a75e-6120757041d2@github.com>
 <W_NVp55o8MtQIzk8E9rZQDRFC1EGT0nwRcMQH0ZWytk=.b261a590-81bd-491d-bc83-da61a4e42348@github.com>
Message-ID: <zlJ29mElT9SHKmf-7gTCde8o3eN0jqieQpdqm11rJag=.53c89542-dd28-4c2c-b838-acf577522025@github.com>

On Fri, 16 May 2025 18:25:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 131:
>> 
>>> 129:             }
>>> 130:         } catch (UnsupportedAudioFileException e) {
>>> 131:             // not an audio file
>> 
>> This code path seems will not be (rarely) executed?
>> The midi file will be handled above by the AudioSystem.getAudioInputStream() via SoftMidiAudioFileReader provider? But if converted midi->sampled data cannot be played via audio device then it might be useful to try MidiDevice, but I do not think it can be done by catching UnsupportedAudioFileException.
>
> Perhaps but that's the behaviour today and I don't see the need to change it in order to provide a different API to reach here.

My point was not about adding a different API, but about changing this logic, which I believe no longer works well after the Gervill integration. For MIDI files, we should first attempt to play them as audio files(we do it now). But if no audio output devices are available then should fallback to this code path and use a MidiDevice directly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093670550

From prr at openjdk.org  Fri May 16 21:01:00 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 May 2025 21:01:00 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <esa-IyM9MbrXK8vdB6zuduTROJLn3ZGwG1bb-yg0Ws8=.90cfc1d7-1140-47c6-a471-4991a7f8ca37@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
 <HwKf3rDD39LT_vh0XAjjD8u8k7SaSHOdiduoTsgXzLg=.eef81151-e671-4640-8c81-d0dfb4b25c9b@github.com>
 <TZaGuWgAMowQY249bB-gKPcRYEDGdYPgr_o-TH-T31M=.47698e31-16d1-4ef6-af0f-d325c9c8e65b@github.com>
 <3-KbtEsAwLLS8Ge__LmkptkvGdoQZ7sBTLWDeNFaZIw=.1b3f6fa1-bffe-448a-a3d7-3a2ebdbc9f79@github.com>
 <esa-IyM9MbrXK8vdB6zuduTROJLn3ZGwG1bb-yg0Ws8=.90cfc1d7-1140-47c6-a471-4991a7f8ca37@github.com>
Message-ID: <ZCUkGl-w0dJbrJorv3xZOY4i5d8sJCQhu-sQOjlM13s=.c8c03c82-962c-446a-a0b1-ef68e34f0eac@github.com>

On Fri, 16 May 2025 20:50:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > It was added to avoid having to explicitly retroactively specify @throws NPE on however many methods didn't actually declare it in their spec and "accidentally" threw NPE.
> 
> No, in many cases NPE was explicitly added to many methods in that packages, even if npe had not been thrown before. It is better to use NPE. Check how many "@throws NullPointerException if XXX is {@code null}" is in that code, and compare that with usage of IllegalArgumentException.

So even if some parts ofthe fix up did add NPE after the fact - documenting what was already happening by accident doesn't seem to support a clear design desicion or an essential need to use NPE in this case

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093669729

From serb at openjdk.org  Fri May 16 21:01:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 16 May 2025 21:01:01 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <deHe7hKJaok55bjhXd-WkTVjuE97JbruA1BFyS31QEY=.c02cea2b-eda2-4e25-b014-a1cbfec8a454@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <lTHWCVus_F1QuH_rk-EzUlQPPTFn2P6qq4PPF11jtAk=.15a99668-cf50-4395-a75e-6120757041d2@github.com>
 <bsOG3L7WJL2amGAwkxvMg2mcoIsJgbWPqAAu6afQVQE=.e4acac34-24c9-4d30-ac8a-a8aa8af54e71@github.com>
 <uRKpk8hijsqouGGurND49ScU9EBpnfY2GH_qsOJaqC0=.e3a08246-644d-484c-b930-0ec6409ab9d0@github.com>
 <deHe7hKJaok55bjhXd-WkTVjuE97JbruA1BFyS31QEY=.c02cea2b-eda2-4e25-b014-a1cbfec8a454@github.com>
Message-ID: <tnNmYQRKr7smbeC6Jt2rVklvrcNf_P3nCFACmnGvAYA=.16c79ce0-c8ec-4f95-847f-8cc3b4951bcb@github.com>

On Fri, 16 May 2025 18:26:47 GMT, Phil Race <prr at openjdk.org> wrote:

>>>     * Each time this method is called, the clip is restarted from the beginning.
>> Note that calls within 30 ms are ignored: https://github.com/openjdk/jdk/blob/2c4e8d211a030c85488e656a9a851d10dd0f9c11/src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java#L158
>
> I don't think any of the above requires changes.

Still, it's worth making some arguments:
- Why are all these methods marked as synchronized?
- Why don't we want to specify that the application will be blocked from exiting if sound is playing? especially if loop() was called.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093667050

From prr at openjdk.org  Fri May 16 21:05:57 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 May 2025 21:05:57 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <7uFWKUMMkDky6Qy3Z5-DW7tPyAMIXj3RDP6XbvQi_1s=.b2a9faea-99e6-4142-a159-d2e68280cfbd@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
 <fDCtY1Zjp0_fvPv01xzD8QM-_IYFi-VO_Rza7EfDO3E=.883f1b8d-b744-4cf8-9105-435d2317e97f@github.com>
 <7uFWKUMMkDky6Qy3Z5-DW7tPyAMIXj3RDP6XbvQi_1s=.b2a9faea-99e6-4142-a159-d2e68280cfbd@github.com>
Message-ID: <kYgCjjFpRIVk1b3XZG4IjDQhzxgSl5E0bu90SZoqkkA=.f2f4260c-7e60-4cdd-b687-0cb8e1f57535@github.com>

On Fri, 16 May 2025 20:51:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> But then you may get exactly the same bug we discussed recently about converting midi files into audio stream and loading all that into the memory.

I think that shows that you can't document what small is

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093672960

From serb at openjdk.org  Fri May 16 21:05:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 16 May 2025 21:05:58 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <EATHedwrSHzqKljRBzUt0iVkr7YntxomtTow4qDnTTA=.3ece1cfd-e7c0-4d77-9db2-f6ad7628fdf1@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <EATHedwrSHzqKljRBzUt0iVkr7YntxomtTow4qDnTTA=.3ece1cfd-e7c0-4d77-9db2-f6ad7628fdf1@github.com>
Message-ID: <BSRiWvTcNJZuzTYfumO8H4zrjFuBVcvdFlKF4Y3727U=.fe19af20-7c00-413d-bab5-4f7424afa1f1@github.com>

On Tue, 13 May 2025 21:00:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/sound/SoundClip.java line 78:
>> 
>>> 76:      * of this class is a no-op.
>>> 77:      */
>>> 78:     public synchronized boolean canPlay() {
>> 
>> Should we perhaps document the multithreaded use of Clip? Do we really need all these synchronized keywords in the file?
>
> The API calls are best protected this way just like the ones in AudioClip were. There's no advantage in removing them. I don't think there's anything to document.

Hmm I did not see all this responses for yesterday...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093674887

From serb at openjdk.org  Fri May 16 21:05:59 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 16 May 2025 21:05:59 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
Message-ID: <dBPv5N4yThCKs_0ibgiXHKx8RcfWuR4RWlObH6Pcbis=.32312ba5-0c7f-45bf-853b-b6978d102c68@github.com>

On Wed, 14 May 2025 03:58:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The intent is that this should always run on a system with sound. It just might happen that it isn't, so this isn't a case to start adding tests. 
>> That might be better done by feeding it unplayable data.
>
> Why do not check this case as well?

But it is part of the new spec:
>     * if the implementation does not find a suitable output device for the data,
>     * playing the clip will be a no-op.

It is better to cover it if we have a chance than just exiting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093673788

From serb at openjdk.org  Fri May 16 21:10:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 16 May 2025 21:10:54 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <BSRiWvTcNJZuzTYfumO8H4zrjFuBVcvdFlKF4Y3727U=.fe19af20-7c00-413d-bab5-4f7424afa1f1@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <EATHedwrSHzqKljRBzUt0iVkr7YntxomtTow4qDnTTA=.3ece1cfd-e7c0-4d77-9db2-f6ad7628fdf1@github.com>
 <BSRiWvTcNJZuzTYfumO8H4zrjFuBVcvdFlKF4Y3727U=.fe19af20-7c00-413d-bab5-4f7424afa1f1@github.com>
Message-ID: <WS2VzdujxVST5KQbyLezbtIweM_NV0ivdUO_NxAylg4=.36abe36e-8b90-4c0f-8b66-724a5ebc3122@github.com>

On Fri, 16 May 2025 21:03:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The API calls are best protected this way just like the ones in AudioClip were. There's no advantage in removing them. I don't think there's anything to document.
>
> Hmm I did not see all this responses for yesterday...

>The API calls are best protected this way just like the ones in AudioClip were. There's no advantage in removing them.
But previously it was protected by methods in the non-public JavaSoundAudioClip, which extended AudioClip. Now SoundClip wraps JavaSoundAudioClip with the same results. Moreover, previously synchronized was not part of the public API, now it is.

One of the benefits to remove them is that it will not be possible to abuse synchronized(SoundClip) which will block execution of its methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093678819

From prr at openjdk.org  Fri May 16 21:16:50 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 May 2025 21:16:50 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v2]
In-Reply-To: <tYVS4MtY0OV0S2YNjJBbykPzFhX06K-udfZjhRdCCn8=.4b4c573d-af88-405c-ab86-332299fae4f9@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <8JCrFisXgNtBSXxxVA_QkcG3LObiggKIPfEBVdb3NO0=.47a846aa-4a05-4a9b-85e7-5cd1d3b146eb@github.com>
 <tYVS4MtY0OV0S2YNjJBbykPzFhX06K-udfZjhRdCCn8=.4b4c573d-af88-405c-ab86-332299fae4f9@github.com>
Message-ID: <ePRIvU-XVconvnSCLyh5IMfyCZdqMlkdg33p3h72IfE=.65b41519-6739-45bf-bddd-fafea41ce037@github.com>

On Fri, 16 May 2025 20:28:25 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The getGnomeShellMajorVersion check takes about 33 ms on my machine when the binary is in the system.

This seems like it is the 'common case', and I think we discussed the performance when it was added (yes we did I just checked) even though at that time it was only for SystemTray and it was noted then that DBUS would be a better solution  : https://github.com/openjdk/jdk/pull/17860#discussion_r1490283265

We've started  using it for Robot too, but its still not on a "start up" path, so its still a nice-to-have but not at all critical.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25265#discussion_r2093684318

From serb at openjdk.org  Fri May 16 21:17:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 16 May 2025 21:17:55 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <ZCUkGl-w0dJbrJorv3xZOY4i5d8sJCQhu-sQOjlM13s=.c8c03c82-962c-446a-a0b1-ef68e34f0eac@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
 <HwKf3rDD39LT_vh0XAjjD8u8k7SaSHOdiduoTsgXzLg=.eef81151-e671-4640-8c81-d0dfb4b25c9b@github.com>
 <TZaGuWgAMowQY249bB-gKPcRYEDGdYPgr_o-TH-T31M=.47698e31-16d1-4ef6-af0f-d325c9c8e65b@github.com>
 <3-KbtEsAwLLS8Ge__LmkptkvGdoQZ7sBTLWDeNFaZIw=.1b3f6fa1-bffe-448a-a3d7-3a2ebdbc9f79@github.com>
 <esa-IyM9MbrXK8vdB6zuduTROJLn3ZGwG1bb-yg0Ws8=.90cfc1d7-1140-47c6-a471-4991a7f8ca37@github.com>
 <ZCUkGl-w0dJbrJorv3xZOY4i5d8sJCQhu-sQOjlM13s=.c8c03c82-962c-446a-a0b1-ef68e34f0eac@github.com>
Message-ID: <agLk5yr-MuEdrk-tU3bjMVrRtCJlYJl5aCr1Gm-SHEQ=.337447df-38ee-4bf2-9d8a-c620c196d7fc@github.com>

On Fri, 16 May 2025 20:57:42 GMT, Phil Race <prr at openjdk.org> wrote:

>>>It was added to avoid having to explicitly retroactively specify @throws NPE on however many methods didn't actually declare it in their spec and "accidentally" threw NPE.
>> 
>> No, in many cases NPE was explicitly added to many methods in that packages, even if npe had not been thrown before. It is better to use NPE. Check how many "@throws NullPointerException if XXX is {@code null}" is in that code, and compare that with usage of IllegalArgumentException.
>
>> > It was added to avoid having to explicitly retroactively specify @throws NPE on however many methods didn't actually declare it in their spec and "accidentally" threw NPE.
>> 
>> No, in many cases NPE was explicitly added to many methods in that packages, even if npe had not been thrown before. It is better to use NPE. Check how many "@throws NullPointerException if XXX is {@code null}" is in that code, and compare that with usage of IllegalArgumentException.
> 
> So even if some parts ofthe fix up did add NPE after the fact - documenting what was already happening by accident doesn't seem to support a clear design desicion or an essential need to use NPE in this case

That is not an accident, most of that API already thrown IllegalArgumentException and we could change to throw it on null as well, but the whole JavaSound api was checked and unified to throw only one NPE.

What is the point of adding an IllegalArgumentException just for that one case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093684901

From dgredler at openjdk.org  Fri May 16 21:49:55 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 16 May 2025 21:49:55 GMT
Subject: RFR: 8356966:
 java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails on Linux after
 JDK-8350203 [v2]
In-Reply-To: <lUlQiFUlDaaIKDDQeOYpiaWx3OPTciJhiezbXNX0U2s=.52ee6435-ad33-4f60-b7d5-bd87d81399fe@github.com>
References: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
 <TIBNLsI9rDJ4N7i5nnEOAdWV4G0-3PAecFYKVWukv3I=.00857aa2-731e-4fc3-aca9-3919da1be53e@github.com>
 <R8Kwq1ZAdeXf_bCL-s06DLWeQOh5vrJFqdCsSGYMMyk=.2b4bea5a-b349-49f4-b533-ce3c63328c85@github.com>
 <lUlQiFUlDaaIKDDQeOYpiaWx3OPTciJhiezbXNX0U2s=.52ee6435-ad33-4f60-b7d5-bd87d81399fe@github.com>
Message-ID: <Zrx1T0-rxYENa65g1uKU-306N6Hftuvj4G4U4RLruAY=.5616b604-da24-4abc-82a5-d28728e246d6@github.com>

On Fri, 16 May 2025 06:35:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> I added your PR to our build/test queue, let's see if it fixes the  issues.
>
>> Looks good to me. I didn't try to reproduce the problem. Let's wait for @MBaesken test results.
> 
> Test results look good, with your PR the issue is gone on the 2 Linux machines where we noticed it before .

@MBaesken Thanks for the confirmation!

@honkar-jdk Do you feel OK approving based on the test feedback above?

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

PR Comment: https://git.openjdk.org/jdk/pull/25235#issuecomment-2887731013

From azvegint at openjdk.org  Fri May 16 21:53:55 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 16 May 2025 21:53:55 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v2]
In-Reply-To: <ePRIvU-XVconvnSCLyh5IMfyCZdqMlkdg33p3h72IfE=.65b41519-6739-45bf-bddd-fafea41ce037@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <8JCrFisXgNtBSXxxVA_QkcG3LObiggKIPfEBVdb3NO0=.47a846aa-4a05-4a9b-85e7-5cd1d3b146eb@github.com>
 <tYVS4MtY0OV0S2YNjJBbykPzFhX06K-udfZjhRdCCn8=.4b4c573d-af88-405c-ab86-332299fae4f9@github.com>
 <ePRIvU-XVconvnSCLyh5IMfyCZdqMlkdg33p3h72IfE=.65b41519-6739-45bf-bddd-fafea41ce037@github.com>
Message-ID: <dlqUdi1y-1JXnk_p2FgE33Ya2CDN6i9kbeHE6b3ZgpY=.15589d3f-1bdd-41b9-9111-0ec35aae030c@github.com>

On Fri, 16 May 2025 21:14:17 GMT, Phil Race <prr at openjdk.org> wrote:

> I think we discussed the performance when it was added (yes we did I just checked) even though at that time it was only for SystemTray and it was noted then that DBUS would be a better solution : https://github.com/openjdk/jdk/pull/17860#discussion_r1490283265

Oh, thanks for the reminder.

> but its still not on a "start up" path

It's not exactly in there, but it might be pretty close.

It's being [called](https://github.com/openjdk/jdk/commit/f75e0ed7c313700044557db6ea09cfd9e85eac70#diff-bc685def01d3c123e569dec4b2dfe03163da3853321e94d2fa81f93e049412c2L1524) now during the static initialization of `MouseEvent`, for example, when the pointer is moved to a frame by a user:


java.lang.Exception: Stack trace
        at java.base/java.lang.Thread.dumpStack(Thread.java:1991)
        at java.desktop/sun.awt.X11.XToolkit.getNumberOfButtons(XToolkit.java:1526)
        at java.desktop/java.awt.event.MouseEvent.<clinit>(MouseEvent.java:404)
        at java.desktop/sun.awt.X11.XWindow.handleXCrossingEvent(XWindow.java:995)
        at java.desktop/sun.awt.X11.XComponentPeer.handleXCrossingEvent(XComponentPeer.java:74)
        at java.desktop/sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1155)
        at java.desktop/sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1113)
        at java.desktop/sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:592)
        at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:705)
        at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:621)
        at java.base/java.lang.Thread.run(Thread.java:1447)


It's still not critical though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25265#discussion_r2093712590

From serb at openjdk.org  Fri May 16 21:56:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 16 May 2025 21:56:53 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <kYgCjjFpRIVk1b3XZG4IjDQhzxgSl5E0bu90SZoqkkA=.f2f4260c-7e60-4cdd-b687-0cb8e1f57535@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
 <fDCtY1Zjp0_fvPv01xzD8QM-_IYFi-VO_Rza7EfDO3E=.883f1b8d-b744-4cf8-9105-435d2317e97f@github.com>
 <7uFWKUMMkDky6Qy3Z5-DW7tPyAMIXj3RDP6XbvQi_1s=.b2a9faea-99e6-4142-a159-d2e68280cfbd@github.com>
 <kYgCjjFpRIVk1b3XZG4IjDQhzxgSl5E0bu90SZoqkkA=.f2f4260c-7e60-4cdd-b687-0cb8e1f57535@github.com>
Message-ID: <dieegetJczR5I_vfBROr9Usx2SYvklFBqGDSwrRgVA4=.e729fffa-8eaa-41f0-a6f9-39d73548d43d@github.com>

On Fri, 16 May 2025 21:01:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> But then you may get exactly the same bug we discussed recently about converting midi files into audio stream and loading all that into the memory.
>
>> But then you may get exactly the same bug we discussed recently about converting midi files into audio stream and loading all that into the memory.
> 
> I think that shows that you can't document what small is

it depends from the heap, but we may document it similar to what Clip(link above) currently say:
> * The {@code Clip} ........  can load all data prior to playback, instead of being streamed in real time.

at least we should check that similar "big boom" will not happen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093714330

From prr at openjdk.org  Fri May 16 22:04:54 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 May 2025 22:04:54 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <WS2VzdujxVST5KQbyLezbtIweM_NV0ivdUO_NxAylg4=.36abe36e-8b90-4c0f-8b66-724a5ebc3122@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <EATHedwrSHzqKljRBzUt0iVkr7YntxomtTow4qDnTTA=.3ece1cfd-e7c0-4d77-9db2-f6ad7628fdf1@github.com>
 <BSRiWvTcNJZuzTYfumO8H4zrjFuBVcvdFlKF4Y3727U=.fe19af20-7c00-413d-bab5-4f7424afa1f1@github.com>
 <WS2VzdujxVST5KQbyLezbtIweM_NV0ivdUO_NxAylg4=.36abe36e-8b90-4c0f-8b66-724a5ebc3122@github.com>
Message-ID: <1Un21fM0uraTLpioLLwvcMP55EMzRWoSCVYZ_THMh6w=.94cd92e5-0018-4bad-9c72-311d507de878@github.com>

On Fri, 16 May 2025 21:07:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > The API calls are best protected this way just like the ones in AudioClip were. There's no advantage in removing them.
> > But previously it was protected by methods in the non-public JavaSoundAudioClip, which extended AudioClip. Now SoundClip wraps JavaSoundAudioClip with the same results. Moreover, previously synchronized was not part of the public API, now it is.
> 
> One of the benefits to remove them is that it will not be possible to abuse synchronized(SoundClip) which will block execution of its methods.

That is no different than with the applet AudioClip .. it doesn't matter whether it is in the API doc, they are all synchronized. And I don't know why an app would hold a lock that prevents itself from working.
We can later - meaning in another release - remove synchronized if there's a compelling reason to do so, but I would have thought it better to be explicit about this - unlike applet AudioClip.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093722139

From prr at openjdk.org  Fri May 16 22:04:54 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 May 2025 22:04:54 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <1Un21fM0uraTLpioLLwvcMP55EMzRWoSCVYZ_THMh6w=.94cd92e5-0018-4bad-9c72-311d507de878@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <EATHedwrSHzqKljRBzUt0iVkr7YntxomtTow4qDnTTA=.3ece1cfd-e7c0-4d77-9db2-f6ad7628fdf1@github.com>
 <BSRiWvTcNJZuzTYfumO8H4zrjFuBVcvdFlKF4Y3727U=.fe19af20-7c00-413d-bab5-4f7424afa1f1@github.com>
 <WS2VzdujxVST5KQbyLezbtIweM_NV0ivdUO_NxAylg4=.36abe36e-8b90-4c0f-8b66-724a5ebc3122@github.com>
 <1Un21fM0uraTLpioLLwvcMP55EMzRWoSCVYZ_THMh6w=.94cd92e5-0018-4bad-9c72-311d507de878@github.com>
Message-ID: <WFkVJV5H6kiebyzlzo_jKGOur4TLMCNmAN1IkXVStcA=.04f03866-64a5-46a6-98c1-eee0cd569af6@github.com>

On Fri, 16 May 2025 22:01:11 GMT, Phil Race <prr at openjdk.org> wrote:

>>>The API calls are best protected this way just like the ones in AudioClip were. There's no advantage in removing them.
>> But previously it was protected by methods in the non-public JavaSoundAudioClip, which extended AudioClip. Now SoundClip wraps JavaSoundAudioClip with the same results. Moreover, previously synchronized was not part of the public API, now it is.
>> 
>> One of the benefits to remove them is that it will not be possible to abuse synchronized(SoundClip) which will block execution of its methods.
>
>> > The API calls are best protected this way just like the ones in AudioClip were. There's no advantage in removing them.
>> > But previously it was protected by methods in the non-public JavaSoundAudioClip, which extended AudioClip. Now SoundClip wraps JavaSoundAudioClip with the same results. Moreover, previously synchronized was not part of the public API, now it is.
>> 
>> One of the benefits to remove them is that it will not be possible to abuse synchronized(SoundClip) which will block execution of its methods.
> 
> That is no different than with the applet AudioClip .. it doesn't matter whether it is in the API doc, they are all synchronized. And I don't know why an app would hold a lock that prevents itself from working.
> We can later - meaning in another release - remove synchronized if there's a compelling reason to do so, but I would have thought it better to be explicit about this - unlike applet AudioClip.

> Hmm I did not see all this responses for yesterday...

I umm went to add new comments today and it looked like I did not submit a previous batch of pending replies

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093722549

From serb at openjdk.org  Fri May 16 22:05:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 16 May 2025 22:05:50 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v2]
In-Reply-To: <dlqUdi1y-1JXnk_p2FgE33Ya2CDN6i9kbeHE6b3ZgpY=.15589d3f-1bdd-41b9-9111-0ec35aae030c@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <8JCrFisXgNtBSXxxVA_QkcG3LObiggKIPfEBVdb3NO0=.47a846aa-4a05-4a9b-85e7-5cd1d3b146eb@github.com>
 <tYVS4MtY0OV0S2YNjJBbykPzFhX06K-udfZjhRdCCn8=.4b4c573d-af88-405c-ab86-332299fae4f9@github.com>
 <ePRIvU-XVconvnSCLyh5IMfyCZdqMlkdg33p3h72IfE=.65b41519-6739-45bf-bddd-fafea41ce037@github.com>
 <dlqUdi1y-1JXnk_p2FgE33Ya2CDN6i9kbeHE6b3ZgpY=.15589d3f-1bdd-41b9-9111-0ec35aae030c@github.com>
Message-ID: <-5JfOcgmQU0aU4Zj_9GbtNHyCv2qbe-fK1jSTXqXIcc=.164fcc53-248f-4c08-802d-23276862149f@github.com>

On Fri, 16 May 2025 21:51:00 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> It's still not critical though.

that looks fine.

Maybe as a temporary solution, we can preload this property at Toolkit startup in a separate thread, and wait for XdgDesktopPortal/etc only if that thread hasn't completed yet?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25265#discussion_r2093722225

From duke at openjdk.org  Fri May 16 22:09:59 2025
From: duke at openjdk.org (Florian)
Date: Fri, 16 May 2025 22:09:59 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v2]
In-Reply-To: <Xl1oVhRGDHJX-j5VoyIsGee1JfgbukuqGIgnpb6lR9Y=.a17d8c8a-d95b-4643-afbb-a99ff5fd3b94@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <Xl1oVhRGDHJX-j5VoyIsGee1JfgbukuqGIgnpb6lR9Y=.a17d8c8a-d95b-4643-afbb-a99ff5fd3b94@github.com>
Message-ID: <YF-qBcbrlYNOqrjSO9G9k-zx5LlZ_1nsIL0Xa36YGfs=.5a7444e5-9be3-4192-a6dd-de818799c12c@github.com>

On Fri, 2 May 2025 23:00:32 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

I wonder about the limitation to `java.io.File` as source for sound clips. Allowing playback from an `InputStream` allows developers to use their own packaging, compression, bundling, or use dynamically generated sound clips, and to work around missing file access permissions. How about this additional factory method:

 public static SoundClip createSoundClip(InputStream file) throws IOException;

The implementation is simple, because it boils down to an InputStream internally anyway, and testing is equally simple.

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

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2848551015

From prr at openjdk.org  Fri May 16 22:09:59 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 May 2025 22:09:59 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v5]
In-Reply-To: <dieegetJczR5I_vfBROr9Usx2SYvklFBqGDSwrRgVA4=.e729fffa-8eaa-41f0-a6f9-39d73548d43d@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <yDLSnwAO6_j_4hUsD8XLphAxg6G9EBmETpUd2PtoVMg=.783c2ac5-036f-4d9a-af19-349917124a11@github.com>
 <Ue6iJwGOMUBGvxs5rZoaVIkxTK9ta4boCPX33GpZKik=.5bf7587f-9dda-40c5-b07d-bc735b97869d@github.com>
 <eCPyVCm2rgj3kg3AM6QlhBYkgZru0VINrFiKmAQry70=.8bf41fba-84cf-4e10-bcf3-9f77107b9aab@github.com>
 <fDCtY1Zjp0_fvPv01xzD8QM-_IYFi-VO_Rza7EfDO3E=.883f1b8d-b744-4cf8-9105-435d2317e97f@github.com>
 <7uFWKUMMkDky6Qy3Z5-DW7tPyAMIXj3RDP6XbvQi_1s=.b2a9faea-99e6-4142-a159-d2e68280cfbd@github.com>
 <kYgCjjFpRIVk1b3XZG4IjDQhzxgSl5E0bu90SZoqkkA=.f2f4260c-7e60-4cdd-b687-0cb8e1f57535@github.com>
 <dieegetJczR5I_vfBROr9Usx2SYvklFBqGDSwrRgVA4=.e729fffa-8eaa-41f0-a6f9-39d73548d43d@github.com>
Message-ID: <KJXEGa7mY1mXnlJ2JHpo_1fB6a9monRWITwY4r0jrMg=.0f5ba9d3-6968-4661-a4b8-625c35c5a46f@github.com>

On Fri, 16 May 2025 21:53:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> it depends from the heap, but we may document it similar to what Clip(link above) currently say:
> 
> > * The {@code Clip} ........  can load all data prior to playback, instead of being streamed in real time.
> 
> at least we should check that similar "big boom" will not happen.

Then that's up to the app to not use such a big file, and its no different than the existing API.
Adding a new way of getting there doesn't require going to fix a  long time questionable problem.

And as I wrote before "The Applet case was historically even more constrained (64 Mb heap for applets once upon a time)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093726348

From prr at openjdk.org  Fri May 16 23:09:42 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 May 2025 23:09:42 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
Message-ID: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>

Update the some code examples and accompanying images to no longer mention or display as applets.

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

Commit messages:
 - 8357176

Changes: https://git.openjdk.org/jdk/pull/25278/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25278&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357176
  Stats: 164 lines in 17 files changed: 47 ins; 20 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/25278.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25278/head:pull/25278

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

From honkar at openjdk.org  Fri May 16 23:31:50 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 16 May 2025 23:31:50 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v2]
In-Reply-To: <XRQDe9qB8vtFFeCAbMRxRr5lB4vBCaFCAkDc9autvRc=.597810e7-8ce4-4879-bcf6-a4739273ccdf@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <XRQDe9qB8vtFFeCAbMRxRr5lB4vBCaFCAkDc9autvRc=.597810e7-8ce4-4879-bcf6-a4739273ccdf@github.com>
Message-ID: <olpdq-aMj48h6bbL-WxYpJY-8iWjre32YpzZo87V68s=.b2330798-fb88-4662-9879-e9c5b9a1f8d7@github.com>

On Fri, 16 May 2025 20:45:39 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The issue is the inability to move the mouse cursor using `java.awt.Robot` on Oracle Linux 10 (which has not yet been released). FIY, the OL10 is no longer provides an Xorg session, so only Wayland is available.
>> It is a JCK conformance failure. 
>> 
>> ---
>> 
>> In our robot implementation, we emulate mouse/keyboard actions using the XTEST extension protocol.
>> 
>> The XTEST calls are now wired to [libEI](https://libinput.pages.freedesktop.org/libei/api/index.html):
>> 
>> 1.
>> 
>> It now asks for a user confirmation to allow interaction, so we should now be able to click on native applications, window titles, etc.
>> 
>> However, our robot implementation is mostly uses XTEST, but there is an exception:
>> for mouse move we use XWarpPointer, which is not part of the XTEST, thus it is not propagated outside of Xwayland server.
>> 
>> So we have a situation where mouse is moving only inside Xwayland server, and we see the mouse enter/exit events,
>> on mouse press we call XTestFakeButtonEvent and it is handled by libei,
>> so the click happens where is the actual mouse cursor is in the system. That is why the test fails.
>> 
>> To avoid this situation we should use XTestFakeMotionEvent for mouseMove in Xwayland case.
>> 
>> It would be a simple solution, but
>> 
>> 
>> 2.
>> 
>> This permission granted by a user doesn't persist across reboots, it timeouts after a period of inactivity.
>> 
>> It still seems to conform to the specifications, but we will not be able to conveniently run automated tests in this case.
>> 
>> ---
>> 
>> So as a solution we can switch the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
>> It has session and `restore_token` functionality to keep permissions granted by a user, similar to what we use in a [Screencast](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html) for taking screenshots.
>> Most of the code can be reused, and it has everything we need.
>> 
>> 
>> * It is only enabled by default on Wayland and Gnome Shell 47 and higher due to XTEST API complications that first arose in this version. For earlier versions, Screencast is used instead.
>> * A new value has been introduced for the `awt.robot.screenshotMethod` system property - `dbusRemoteDesktop`. It works on Ubuntu 24.04 with Gnome 46, but is not enabled by default.
>> * extra mouse buttons are not supported yet, [JDK-8357142](https://bugs.openjdk.org/browse/JDK-8357142)
>> * Since w...
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only call getGnomeShellMajorVersion when the desktop is Gnome.

@azvegint 

> So as a solution we can switch the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
> It has session and restore_token functionality to keep permissions granted by a user, similar to what we use in a [Screencast](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html) for taking screenshots.

Since there is a manual part (i.e granting permission for the 1st time) , is it a good idea to convert the OELMouseTest.java (test attached to JBS) as a semi-automated PassFailJFrame test and run it on linux platforms with awt.robot.screenshotMethod property - dbusRemoteDesktop (and skipping if not) and this way there would be a dedicated jtreg test for this fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/25265#issuecomment-2887839657

From honkar at openjdk.org  Fri May 16 23:34:50 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 16 May 2025 23:34:50 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v2]
In-Reply-To: <XRQDe9qB8vtFFeCAbMRxRr5lB4vBCaFCAkDc9autvRc=.597810e7-8ce4-4879-bcf6-a4739273ccdf@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <XRQDe9qB8vtFFeCAbMRxRr5lB4vBCaFCAkDc9autvRc=.597810e7-8ce4-4879-bcf6-a4739273ccdf@github.com>
Message-ID: <yUJbAfDlYpHL7tc1WWdaTp8oQqO0Ckzgg22JCs8Ae0Y=.dfd58fca-0007-4b60-91cc-00328cd8b0f3@github.com>

On Fri, 16 May 2025 20:45:39 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The issue is the inability to move the mouse cursor using `java.awt.Robot` on Oracle Linux 10 (which has not yet been released). FIY, the OL10 is no longer provides an Xorg session, so only Wayland is available.
>> It is a JCK conformance failure. 
>> 
>> ---
>> 
>> In our robot implementation, we emulate mouse/keyboard actions using the XTEST extension protocol.
>> 
>> The XTEST calls are now wired to [libEI](https://libinput.pages.freedesktop.org/libei/api/index.html):
>> 
>> 1.
>> 
>> It now asks for a user confirmation to allow interaction, so we should now be able to click on native applications, window titles, etc.
>> 
>> However, our robot implementation is mostly uses XTEST, but there is an exception:
>> for mouse move we use XWarpPointer, which is not part of the XTEST, thus it is not propagated outside of Xwayland server.
>> 
>> So we have a situation where mouse is moving only inside Xwayland server, and we see the mouse enter/exit events,
>> on mouse press we call XTestFakeButtonEvent and it is handled by libei,
>> so the click happens where is the actual mouse cursor is in the system. That is why the test fails.
>> 
>> To avoid this situation we should use XTestFakeMotionEvent for mouseMove in Xwayland case.
>> 
>> It would be a simple solution, but
>> 
>> 
>> 2.
>> 
>> This permission granted by a user doesn't persist across reboots, it timeouts after a period of inactivity.
>> 
>> It still seems to conform to the specifications, but we will not be able to conveniently run automated tests in this case.
>> 
>> ---
>> 
>> So as a solution we can switch the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
>> It has session and `restore_token` functionality to keep permissions granted by a user, similar to what we use in a [Screencast](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html) for taking screenshots.
>> Most of the code can be reused, and it has everything we need.
>> 
>> 
>> * It is only enabled by default on Wayland and Gnome Shell 47 and higher due to XTEST API complications that first arose in this version. For earlier versions, Screencast is used instead.
>> * A new value has been introduced for the `awt.robot.screenshotMethod` system property - `dbusRemoteDesktop`. It works on Ubuntu 24.04 with Gnome 46, but is not enabled by default.
>> * extra mouse buttons are not supported yet, [JDK-8357142](https://bugs.openjdk.org/browse/JDK-8357142)
>> * Since w...
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only call getGnomeShellMajorVersion when the desktop is Gnome.

Review in-progress. 
I would require some time to go over the fix in detail to understand and test it.

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

PR Review: https://git.openjdk.org/jdk/pull/25265#pullrequestreview-2847762631

From honkar at openjdk.org  Fri May 16 23:39:51 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 16 May 2025 23:39:51 GMT
Subject: RFR: 8356966:
 java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails on Linux after
 JDK-8350203 [v3]
In-Reply-To: <Pob6jA6-9qJROD6s9JOTdSPcRMsx5cK0ba1kQ08cPjo=.9f850e75-2e1a-49c1-8a79-95a9d932b508@github.com>
References: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
 <Pob6jA6-9qJROD6s9JOTdSPcRMsx5cK0ba1kQ08cPjo=.9f850e75-2e1a-49c1-8a79-95a9d932b508@github.com>
Message-ID: <z3f4yBp1EfIgzBrnvwVVHn0gFuNAfCxQ2dwtoPqmD-w=.d58b6dc2-8697-4255-9572-6ec89618fe24@github.com>

On Thu, 15 May 2025 17:20:06 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> If the new test (`IgnoredWhitespaceTest`) runs on a system with Type1 physical fonts, it fails because the Type1 handling of ignorable whitespace characters does not match the behavior of the TrueType and macOS glyph mappers.
>> 
>> This PR updates the Type1 glyph mapper to follow the same rules in this area as the other glyph mappers.
>> 
>> It would probably be a good idea to consolidate all of this into the `CharToGlyphMapper` superclass at some point, so that we're not duplicating this handling across the subclasses, but some users are reporting failing builds and I wanted to keep the PR simple.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update bug tag in test class

Marked as reviewed by honkar (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25235#pullrequestreview-2847765614

From honkar at openjdk.org  Fri May 16 23:39:52 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 16 May 2025 23:39:52 GMT
Subject: RFR: 8356966:
 java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails on Linux after
 JDK-8350203 [v3]
In-Reply-To: <fJ-oM1LAsWC4VvBeAxk4h-tRC4wyi_yVwwBFotnefUE=.5d4aa724-2993-42d1-8495-792c56e96387@github.com>
References: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
 <fJ-oM1LAsWC4VvBeAxk4h-tRC4wyi_yVwwBFotnefUE=.5d4aa724-2993-42d1-8495-792c56e96387@github.com>
Message-ID: <jc-pAjiFYAaao4MgWDBcep79MmWg_lO9d-O0pKsxHII=.89d94f41-eb3f-4fd1-b623-d0c969e146b0@github.com>

On Wed, 14 May 2025 20:38:47 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update bug tag in test class
>
> I wasn't able replicate and verify the fix myself as I don't have specific linux  flavors (RHEL,SLES) to test it .

> @honkar-jdk Do you feel OK approving based on the test feedback above?

Sure. Approved. When this code is touched again adding isIgnorableWhitespace() to `CharToGlyphMapper` would be ideal.

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

PR Comment: https://git.openjdk.org/jdk/pull/25235#issuecomment-2887845552

From honkar at openjdk.org  Sat May 17 00:09:00 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Sat, 17 May 2025 00:09:00 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to CopyAreaOOB.java
Message-ID: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>

CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs.

Test failure is not reproducible when the test is run individually (multiple times) on CI.

Rewritten the test and added debug logs that will be helpful to figure out the issue. 

- Added code to capture screenshot (entire screen as well as the frame) in case of failure.
- Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException.

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

Commit messages:
 - copyright year
 - CopyAreaOOB: debug logs

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

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

From duke at openjdk.org  Sat May 17 02:01:01 2025
From: duke at openjdk.org (duke)
Date: Sat, 17 May 2025 02:01:01 GMT
Subject: Withdrawn: 6734168: BasicButtonUI uses wrong FontMetrics to Layout
 JButtons text
In-Reply-To: <4L7IZ1vyx4DQViAeZUzvA2LcoY7a-QKF-CUaAQBEO0c=.ec145df4-4e9b-40de-84c0-249b67cd9077@github.com>
References: <4L7IZ1vyx4DQViAeZUzvA2LcoY7a-QKF-CUaAQBEO0c=.ec145df4-4e9b-40de-84c0-249b67cd9077@github.com>
Message-ID: <fQX7MFnhTYUCi0MbIroyf5KLkO8h4oFufHKCK1lHi0o=.85f89551-1746-4d2b-b58d-b202e201c96f@github.com>

On Fri, 21 Mar 2025 11:26:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax.swing.plaf.basic.BasicButtonUI uses wrong FontMetrics object to layout the text on a JButton. 
> The paint(Graphics, JComponent) method of BasicButtonUI calculates the [FontMetrics](https://github.com/openjdk/jdk/blob/6656254c346ef505a48652fdf4dedd6edc020e33/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicButtonUI.java#L331) using the passed Graphics object without setting the buttons font before. If the buttons font varies from the currently set font of the passed graphics object, the font metrics do not fit the metrics of the expected font leading to truncated text on the button.
> In WindowsLookAndFeel, the font in passed graphics object differs from currently set font as in 
> 
> button font javax.swing.plaf.FontUIResource[family=Tahoma,name=Tahoma,style=plain,size=10] 
> graphics font java.awt.Font[family=Dialog,name=Dialog,style=plain,size=12]
> 
> whereas in Metal and other L&F it is 
> `font javax.swing.plaf.FontUIResource[family=Dialog,name=Dialog,style=bold,size=12]`
> 
> so the fix is made in Windows L&F to ensure to set the font of the button to the passed graphics object font before calculating the current FontMetrics.

This pull request has been closed without being integrated.

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

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

From mvs at openjdk.org  Sun May 18 13:20:46 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Sun, 18 May 2025 13:20:46 GMT
Subject: RFR: 8355515: Clarify the purpose of forcePass() and forceFail()
 methods [v2]
In-Reply-To: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
References: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
Message-ID: <gWOoBeYt3grJcZej6ROvX3MPijTpnYvaA2ywAsh6J-c=.c38cc6c2-7748-41a6-bf66-ad15af954011@github.com>

> Clarified the purpose of forcePass() and forceFail() methods and recommended usage of these methods.
> 
> forcePass() contained an incorrect sample; it's addressed by [JDK-8355441](https://bugs.openjdk.org/browse/JDK-8355441).
> 
> The description of forceFail() has been expanded, too.
> 
> 
> A new section in the description of the PassFailJFrame added to describe forcePass() and forceFail().

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed : Formatting changes, wordings changed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25091/files
  - new: https://git.openjdk.org/jdk/pull/25091/files/68f72e46..9f0a6321

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

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

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

From mvs at openjdk.org  Sun May 18 13:20:46 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Sun, 18 May 2025 13:20:46 GMT
Subject: RFR: 8355515: Clarify the purpose of forcePass() and forceFail()
 methods
In-Reply-To: <8gMOJCtNcN-Ou84pCTXuEV5h2AFnT0QMVOsYlPeD1EQ=.a967e9ae-1268-477a-8cb0-c503a7c63f39@github.com>
References: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
 <8gMOJCtNcN-Ou84pCTXuEV5h2AFnT0QMVOsYlPeD1EQ=.a967e9ae-1268-477a-8cb0-c503a7c63f39@github.com>
Message-ID: <GhGmV2rZoBhUA2-m5WfhW6PiuqKpUM-OI4udOyAMzdc=.67162755-3ac1-4b0e-ada5-fda05b2c390a@github.com>

On Fri, 16 May 2025 12:16:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> After reading the description again, I started to wonder which adverb suits better: [?forcibly?](https://en.wiktionary.org/wiki/forcibly) or [?forcefully?](https://en.wiktionary.org/wiki/forcefully). Does any native English speaker have an opinion?
I think forcefully is more apt compared to forcibly, changed it accordingly.

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

PR Comment: https://git.openjdk.org/jdk/pull/25091#issuecomment-2888984691

From serb at openjdk.org  Sun May 18 22:59:36 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 18 May 2025 22:59:36 GMT
Subject: RFR: 8355078: java.awt.Color.createContext() uses unnecessary
 synchronization [v2]
In-Reply-To: <0pWUD-E-stDoqVTXFmlRNJ2skEMIjeto6VFl6ydxyc0=.de5400a3-69a2-4621-a91a-45bdfbca4dd2@github.com>
References: <0pWUD-E-stDoqVTXFmlRNJ2skEMIjeto6VFl6ydxyc0=.de5400a3-69a2-4621-a91a-45bdfbca4dd2@github.com>
Message-ID: <K6mHIKkJuqUFYqyXFVY77bL_z7ymEUVJNz0A5LNV_K0=.449682a0-305a-46fd-82c7-f20895963e8d@github.com>

> At some point, java.awt.Color.createContext() was marked as synchronized to support caching of a ColorPaintContext instance. The cache was later removed, but the synchronized modifier remained. Since there is no shared mutable state anymore, the synchronization is no longer necessary and can be safely removed.
> 
> 
> Note: This code path is rarely executed because a special optimization was introduced in [SunGraphics2D.setPaint](https://github.com/openjdk/jdk/blob/c514f135ccf08c3be016a32ae8f2c055fb941857/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1003). As a result, unless a custom wrapper around the Color class is used, the Color.createContext() method is typically bypassed during rendering. 
> 
> Two tests are added:
>  - ColorPaintContextBasicTest: Checks if different image types (BufferedImage and VolatileImage) produce the same results when using different ways to fill the image (setColor, setPaint, and custom Paint). This test intentionally uses a custom Paint implementation to bypass the optimization and ensure that Color.createContext() is invoked verifying its correct behavior.
> - ColorPaintContextStateTrackerTest: Checks that the raster used in ColorPaintContext.getRaster() can be properly cached in video memory and we do not need to call icr.markDirty() in ColorPaintContext.getRaster()

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 six additional commits since the last revision:

 - Merge branch 'openjdk:master' into colorctx
 - Merge branch 'openjdk:master' into colorctx
 - Update ColorPaintContextBasicTest.java
 - handle VolatileImage properly
 - Update ColorPaintContext.java
 - 8355078: java.awt.Color.createContext() uses unnecessary synchronization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24771/files
  - new: https://git.openjdk.org/jdk/pull/24771/files/30008b2c..72876482

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

  Stats: 51757 lines in 1566 files changed: 25015 ins; 18534 del; 8208 mod
  Patch: https://git.openjdk.org/jdk/pull/24771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24771/head:pull/24771

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

From serb at openjdk.org  Mon May 19 00:06:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 00:06:54 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
In-Reply-To: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
Message-ID: <07s-WJJc4k0HyDey7NWxID39ua5z4xxbKbEJShmWBFo=.00b3686c-0e29-4e55-9d37-8210ed44f344@github.com>

On Fri, 16 May 2025 23:04:28 GMT, Phil Race <prr at openjdk.org> wrote:

> Update the some code examples and accompanying images to no longer mention or display as applets.

It seems the new screenshots could be improved by capturing them on a HiDPI (Retina) display, as the current images appear blurry. And to eliminate background elements in the corners, it might be better to capture screenshots of undecorated windows as was done in the old images.

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

PR Comment: https://git.openjdk.org/jdk/pull/25278#issuecomment-2889291657

From serb at openjdk.org  Mon May 19 02:10:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 02:10:50 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java
In-Reply-To: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
Message-ID: <45KN4daBBRbauQz-o9yzcmdYpZmQJTzRJOrT1axLf8U=.db20c011-ced6-41c1-ae49-cfd190373ca7@github.com>

On Sat, 17 May 2025 00:03:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs.
> 
> Test failure is not reproducible when the test is run individually (multiple times) on CI.
> 
> Rewritten the test and added debug logs that will be helpful to figure out the issue. 
> 
> - Added code to capture screenshot (entire screen as well as the frame) in case of failure.
> - Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException.

test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 88:

> 86: 
> 87:     private static void createTestUI() {
> 88:         frame = new Frame();

You do not need to call all these methods on the EDT, these are AWT components that should handle multithreaded usage (main/EDT/toolkit threads). It is possible that the issue is only reproducible on macOS due to synchronization problems related to the metal pipeline?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2094728292

From serb at openjdk.org  Mon May 19 02:15:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 02:15:51 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine [v2]
In-Reply-To: <myxGswD8nolzReIdvjkl3yd-KFTGlN4UVPQJjKBanoE=.ff638733-77b7-4526-94ba-4b8a229a2011@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
 <myxGswD8nolzReIdvjkl3yd-KFTGlN4UVPQJjKBanoE=.ff638733-77b7-4526-94ba-4b8a229a2011@github.com>
Message-ID: <mdIBopuVMGNt0NLaDdZpbsUKegBiKU9UrIqhSNRvzeg=.48276dc9-da27-4ced-9304-11006c0cc23f@github.com>

On Thu, 15 May 2025 19:22:06 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Unfortunately I'm unable to reproduce this failure. I slowed the test down; it passes on my machine before and after this PR.
>> 
>> I added a little bit of logging that might also help identify what's happening.
>> 
>> Does anyone have any more suggestions?
>
> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8356061: restructuring to move things to EDT
>    
>    This was requested here:
>    https://github.com/openjdk/jdk/pull/25244#discussion_r2091656355
>    
>    mrserb asked: "Also please move creation and access_to all Swing components to EDT"
>    
>    (I'm not sure this will help much? My understanding was *creation* of Swing components could happen off the EDT as long as they were made displayable on the EDT.)
>    
>    Now we still call jc.getLocationOnScreen off the EDT. If that posed a thread-based problem it'd probably manifest as a IllegalComponentStateException, which is not mentioned in 8356061.
>  - 8356061: adding 1000ms pause after window construction
>    
>    This was requested here:
>    https://github.com/openjdk/jdk/pull/25244#discussion_r2091656355
>    
>    So now we'll pause at least 1.1s before the first call to `jc.getLocationOnScreen`, and at least 2.1s before the first call to `robot.getPixelColor(x, y)`.
>    
>    (getLocationOnScreen has never failed with an IllegalStateException.)

I think the test can be greatly simplified if you redirect all rendering into a BufferedImage, in that case the use of robot can be removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25244#issuecomment-2889420453

From serb at openjdk.org  Mon May 19 02:15:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 02:15:52 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine [v2]
In-Reply-To: <Lp9r0fyFSOR2TkmuErsUWT1VhR38MycgfxhTPdZZj6Y=.c2953055-2756-48fb-a2fb-97bb050ecf3e@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
 <KtWy5PAcbJKIMzCdknC5d-YFGjs4dUqTA0p4WznpDE4=.cea2724e-4d1b-4c24-aefa-4d6ef09cc057@github.com>
 <Lp9r0fyFSOR2TkmuErsUWT1VhR38MycgfxhTPdZZj6Y=.c2953055-2756-48fb-a2fb-97bb050ecf3e@github.com>
Message-ID: <g6S1Js4vJqbf8U6l4ObczoQ9wY2Pp0nQvrTgZkYMb4Q=.36041bf1-0f44-4e5c-afc7-b595a2d8acfe@github.com>

On Thu, 15 May 2025 19:29:43 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> test/jdk/com/apple/laf/RootPane/RootPaneDefaultButtonTest.java line 131:
>> 
>>> 129:         robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
>>> 130: 
>>> 131:         robot.delay(1000);
>> 
>> it will be useful to add the same delay before the first call to test, right after invokeAndWait.....setVisible(...)
>> Also please move creation and access_to all Swing components to EDT(button, radioButton1)
>
> I added an additional delay. I'm not sure exactly what refactor you're looking for, but I rewrote the test to put more in the EDT.
> 
> (I double-checked that the test still passes, but that doesn't prove much since I've never reproduced a failure.)
> 
> I did try at one point blocking the testing thread until the EDT had a chance to complete an invokeLater runnable, but that didn't seem to make a difference so I didn't commit it.

The code in test() which access swing components(various buttons) also should be moved to EDT.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25244#discussion_r2094730331

From duke at openjdk.org  Mon May 19 05:37:05 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 19 May 2025 05:37:05 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine [v3]
In-Reply-To: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
Message-ID: <c2FRmUEOKhK0i4Mm1dHqdCyu5aCY6cMGE-xQFzSujmQ=.9a13234c-e073-4c12-946f-0d7d77d5f190@github.com>

> Unfortunately I'm unable to reproduce this failure. I slowed the test down; it passes on my machine before and after this PR.
> 
> I added a little bit of logging that might also help identify what's happening.
> 
> Does anyone have any more suggestions?

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

  8356061: removing robot
  
  This is in response to:
  https://github.com/openjdk/jdk/pull/25244#issuecomment-2889420453

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25244/files
  - new: https://git.openjdk.org/jdk/pull/25244/files/b076c964..9f91249a

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

  Stats: 285 lines in 1 file changed: 106 ins; 169 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25244/head:pull/25244

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

From duke at openjdk.org  Mon May 19 05:37:06 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 19 May 2025 05:37:06 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine [v3]
In-Reply-To: <g6S1Js4vJqbf8U6l4ObczoQ9wY2Pp0nQvrTgZkYMb4Q=.36041bf1-0f44-4e5c-afc7-b595a2d8acfe@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
 <KtWy5PAcbJKIMzCdknC5d-YFGjs4dUqTA0p4WznpDE4=.cea2724e-4d1b-4c24-aefa-4d6ef09cc057@github.com>
 <Lp9r0fyFSOR2TkmuErsUWT1VhR38MycgfxhTPdZZj6Y=.c2953055-2756-48fb-a2fb-97bb050ecf3e@github.com>
 <g6S1Js4vJqbf8U6l4ObczoQ9wY2Pp0nQvrTgZkYMb4Q=.36041bf1-0f44-4e5c-afc7-b595a2d8acfe@github.com>
Message-ID: <9R-BsAB7i3C9axKGhxezRSqNlTWhXl0C1qIlSMs9Qzs=.a2f1598b-313e-4c28-a3f7-a1f98a24dad1@github.com>

On Mon, 19 May 2025 02:11:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I added an additional delay. I'm not sure exactly what refactor you're looking for, but I rewrote the test to put more in the EDT.
>> 
>> (I double-checked that the test still passes, but that doesn't prove much since I've never reproduced a failure.)
>> 
>> I did try at one point blocking the testing thread until the EDT had a chance to complete an invokeLater runnable, but that didn't seem to make a difference so I didn't commit it.
>
> The code in test() which access swing components(various buttons) also should be moved to EDT.

I'm not sure I agree, but that becomes moot after https://github.com/openjdk/jdk/pull/25244/commits/9f91249a424b190990fc3056644b5aac8caa0a5b

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25244#discussion_r2094867526

From duke at openjdk.org  Mon May 19 05:39:51 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 19 May 2025 05:39:51 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine [v2]
In-Reply-To: <mdIBopuVMGNt0NLaDdZpbsUKegBiKU9UrIqhSNRvzeg=.48276dc9-da27-4ced-9304-11006c0cc23f@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
 <myxGswD8nolzReIdvjkl3yd-KFTGlN4UVPQJjKBanoE=.ff638733-77b7-4526-94ba-4b8a229a2011@github.com>
 <mdIBopuVMGNt0NLaDdZpbsUKegBiKU9UrIqhSNRvzeg=.48276dc9-da27-4ced-9304-11006c0cc23f@github.com>
Message-ID: <OiaKamfLII7FNYKL79dSZBy4aLDrixXkbSQsgwtI8kY=.65a5fe1d-3394-485c-8a63-e3ba23a88ce8@github.com>

On Mon, 19 May 2025 02:13:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I think the test can be greatly simplified if you redirect all rendering into a BufferedImage

OK, the test is rewritten to use a BufferedImage.

I'm still not convinced I understand the nature of the original failure (why, given the screenshot provided, would a pixel in this test be r=55,g=55,b=55?). I don't think these changes are bad, but since I don't understand the original failure I'm not convinced this work is addressing it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25244#issuecomment-2889678140

From psadhukhan at openjdk.org  Mon May 19 06:14:37 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 19 May 2025 06:14:37 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog()
Message-ID: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>

The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
Fixed by setting the divider location before rendering the left and right components..

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

Commit messages:
 - jcheck
 - 8356594: JSplitPane loses divider location when reopened via JOptionPane.createDialog()

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

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

From azvegint at openjdk.org  Mon May 19 06:19:53 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 19 May 2025 06:19:53 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v2]
In-Reply-To: <olpdq-aMj48h6bbL-WxYpJY-8iWjre32YpzZo87V68s=.b2330798-fb88-4662-9879-e9c5b9a1f8d7@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <XRQDe9qB8vtFFeCAbMRxRr5lB4vBCaFCAkDc9autvRc=.597810e7-8ce4-4879-bcf6-a4739273ccdf@github.com>
 <olpdq-aMj48h6bbL-WxYpJY-8iWjre32YpzZo87V68s=.b2330798-fb88-4662-9879-e9c5b9a1f8d7@github.com>
Message-ID: <XyHPBRWF4NFCV_-QI8Jf_ctiVCLY2PMPGM2-E_DoPRM=.f7461854-264a-422c-81e1-d35cda43f303@github.com>

On Fri, 16 May 2025 23:28:58 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Since you mentioned there is a manual part (i.e granting permission for the 1st time) , is it a good idea to convert the OELMouseTest.java (test attached to JBS) as a semi-automated PassFailJFrame test and run it on linux platforms with awt.robot.screenshotMethod property - dbusRemoteDesktop (and skipping if not) and this way there would be a dedicated jtreg test for this fix or is there an existing test we could re-use ?

I'm not sure if it's really needed, since many tests already depend on the `java.awt.Robot` itself,  CI has a one-time manual task to set up all the required permissions for the `java.awt.Robot`, so automated tests provide sufficient coverage.

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

PR Comment: https://git.openjdk.org/jdk/pull/25265#issuecomment-2889749455

From azvegint at openjdk.org  Mon May 19 06:19:54 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 19 May 2025 06:19:54 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v2]
In-Reply-To: <-5JfOcgmQU0aU4Zj_9GbtNHyCv2qbe-fK1jSTXqXIcc=.164fcc53-248f-4c08-802d-23276862149f@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <8JCrFisXgNtBSXxxVA_QkcG3LObiggKIPfEBVdb3NO0=.47a846aa-4a05-4a9b-85e7-5cd1d3b146eb@github.com>
 <tYVS4MtY0OV0S2YNjJBbykPzFhX06K-udfZjhRdCCn8=.4b4c573d-af88-405c-ab86-332299fae4f9@github.com>
 <ePRIvU-XVconvnSCLyh5IMfyCZdqMlkdg33p3h72IfE=.65b41519-6739-45bf-bddd-fafea41ce037@github.com>
 <dlqUdi1y-1JXnk_p2FgE33Ya2CDN6i9kbeHE6b3ZgpY=.15589d3f-1bdd-41b9-9111-0ec35aae030c@github.com>
 <-5JfOcgmQU0aU4Zj_9GbtNHyCv2qbe-fK1jSTXqXIcc=.164fcc53-248f-4c08-802d-23276862149f@github.com>
Message-ID: <cgUlp431lDMHOBwMmLxVw37AsUeeRHGanQbnt5gc2ks=.bee2d3b7-474c-479c-8602-e25f4ddc8ad9@github.com>

On Fri, 16 May 2025 22:01:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Maybe as a temporary solution, we can preload this property at Toolkit startup in a separate thread, and wait for XdgDesktopPortal/etc only if that thread hasn't completed yet?

Maybe, but not as part of this fix. I don't want to overcomplicate things, especially since there will be multiple backports.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25265#discussion_r2094914513

From aturbanov at openjdk.org  Mon May 19 08:11:04 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 19 May 2025 08:11:04 GMT
Subject: Integrated: 8356846: Remove unnecessary List.contains key from
 TIFFDirectory.removeTagSet
In-Reply-To: <nApYMgifHXmxIwNzIBbzcU8cLM6TBbTVVanCuQ-xj9s=.da62460b-ea8f-44bc-b750-52e93bdbe267@github.com>
References: <nApYMgifHXmxIwNzIBbzcU8cLM6TBbTVVanCuQ-xj9s=.da62460b-ea8f-44bc-b750-52e93bdbe267@github.com>
Message-ID: <8zSOCwrhe_9n6VAHFvY8_oTZ4SCV7unTglnbSPSZsGM=.62a727c9-1aeb-428a-98a6-0ade3d4dc923@github.com>

On Wed, 23 Apr 2025 08:38:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is no need to call List.contains before List.remove call.
> `tagSets` - is an ArrayList.

This pull request has now been integrated.

Changeset: 2fb3329d
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2fb3329d71532a4c40dba2e2698572e4ab5ceb19
Stats:     5 lines in 1 file changed: 0 ins; 3 del; 2 mod

8356846: Remove unnecessary List.contains key from TIFFDirectory.removeTagSet

Reviewed-by: aivanov, serb

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

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

From aturbanov at openjdk.org  Mon May 19 08:14:29 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 19 May 2025 08:14:29 GMT
Subject: RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
Message-ID: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>

Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`

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

Commit messages:
 - [PATCH] Avoid redundant WeakHashMap.get in Toolkit.removeAWTEventListener

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

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

From liach at openjdk.org  Mon May 19 08:14:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 May 2025 08:14:29 GMT
Subject: RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
Message-ID: <3fueyKPoeYAA-G-74gjNyqfJ8qE2HSa8g54Lq-ZSsyg=.8978ab07-e214-4c61-9ad6-0c2e19629335@github.com>

On Wed, 16 Apr 2025 15:07:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`

Makes sense. This map is private, and its value is always non-null (only one other put site), so I believe things are fine here.

Let another reviewer in area to confirm this change.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24692#pullrequestreview-2773119715
PR Comment: https://git.openjdk.org/jdk/pull/24692#issuecomment-2810091497

From serb at openjdk.org  Mon May 19 08:14:29 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 08:14:29 GMT
Subject: RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
Message-ID: <SFCwpT-pkIwJZKnh66ZmtS1JGRHuxVueCVL12ozC2AI=.559a9c87-79e4-403a-a5d8-fe9c83f7f465@github.com>

On Wed, 16 Apr 2025 15:07:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`

src/java.desktop/share/classes/java/awt/Toolkit.java line 1745:

> 1743:         synchronized (this) {
> 1744:             SelectiveAWTEventListener selectiveListener =
> 1745:                 listener2SelectiveListener.remove(localL);

While analyzing the implementation of this method, I noticed a potential bug at the beginning. Should it instead be:

if (localL == null) {
    return;
}

?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24692#discussion_r2089545502

From aturbanov at openjdk.org  Mon May 19 08:14:29 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 19 May 2025 08:14:29 GMT
Subject: RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <SFCwpT-pkIwJZKnh66ZmtS1JGRHuxVueCVL12ozC2AI=.559a9c87-79e4-403a-a5d8-fe9c83f7f465@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
 <SFCwpT-pkIwJZKnh66ZmtS1JGRHuxVueCVL12ozC2AI=.559a9c87-79e4-403a-a5d8-fe9c83f7f465@github.com>
Message-ID: <OOtQjOWTck5yF6VDjBVnfE-1_aa3vTN1vxeuiIrNjKY=.747aea97-b92c-47d0-937d-ae071468d7a9@github.com>

On Wed, 14 May 2025 18:52:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`
>
> src/java.desktop/share/classes/java/awt/Toolkit.java line 1745:
> 
>> 1743:         synchronized (this) {
>> 1744:             SelectiveAWTEventListener selectiveListener =
>> 1745:                 listener2SelectiveListener.remove(localL);
> 
> While analyzing the implementation of this method, I noticed a potential bug at the beginning. Should it instead be:
> 
> if (localL == null) {
>     return;
> }
> 
> ?

Looks like yes. I think it's worth to create a separate issue to fix it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24692#discussion_r2095112071

From abhiscxk at openjdk.org  Mon May 19 08:20:01 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 19 May 2025 08:20:01 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos
Message-ID: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>

Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.

Verified the updated test in CI on macOS 14.7 machine and there is no failure.

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

Commit messages:
 - Test Stabilization

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

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

From aturbanov at openjdk.org  Mon May 19 08:26:27 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 19 May 2025 08:26:27 GMT
Subject: RFR: 8357226: Remove unnecessary List.indexOf from
 RepaintManager.removeInvalidComponent
Message-ID: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>

No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner.
`invalidComponents` is an ArrayList.

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

Commit messages:
 - [PATCH] Remove unnecessary List.indexOf key from RepaintManager.removeInvalidComponent

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

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

From serb at openjdk.org  Mon May 19 08:26:28 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 08:26:28 GMT
Subject: RFR: 8357226: Remove unnecessary List.indexOf from
 RepaintManager.removeInvalidComponent
In-Reply-To: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
References: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
Message-ID: <hJ4PgOPmUJ1My31QgqDK7GyuPrWJMaOAROtlck4Qm3s=.180f2862-9ac7-4738-9383-c3346cc715d6@github.com>

On Thu, 24 Apr 2025 09:29:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner.
> `invalidComponents` is an ArrayList.

src/java.desktop/share/classes/javax/swing/RepaintManager.java line 394:

> 392:         }
> 393:         if (invalidComponents != null) {
> 394:             invalidComponents.remove(component);

I guess the `addInvalidComponent` above can be simplified as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24845#discussion_r2065042601

From aturbanov at openjdk.org  Mon May 19 08:26:28 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 19 May 2025 08:26:28 GMT
Subject: RFR: 8357226: Remove unnecessary List.indexOf from
 RepaintManager.removeInvalidComponent
In-Reply-To: <hJ4PgOPmUJ1My31QgqDK7GyuPrWJMaOAROtlck4Qm3s=.180f2862-9ac7-4738-9383-c3346cc715d6@github.com>
References: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
 <hJ4PgOPmUJ1My31QgqDK7GyuPrWJMaOAROtlck4Qm3s=.180f2862-9ac7-4738-9383-c3346cc715d6@github.com>
Message-ID: <55SDjO2Fj4yDEsB7Zbe3YacApuZZ5C-8x8VRO8aREJs=.3e97052f-7bd7-4dc2-83b2-4f4ecbe3bc47@github.com>

On Mon, 28 Apr 2025 23:48:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner.
>> `invalidComponents` is an ArrayList.
>
> src/java.desktop/share/classes/javax/swing/RepaintManager.java line 394:
> 
>> 392:         }
>> 393:         if (invalidComponents != null) {
>> 394:             invalidComponents.remove(component);
> 
> I guess the `addInvalidComponent` above can be simplified as well?

Simplified how?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24845#discussion_r2066621174

From serb at openjdk.org  Mon May 19 08:26:28 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 08:26:28 GMT
Subject: RFR: 8357226: Remove unnecessary List.indexOf from
 RepaintManager.removeInvalidComponent
In-Reply-To: <55SDjO2Fj4yDEsB7Zbe3YacApuZZ5C-8x8VRO8aREJs=.3e97052f-7bd7-4dc2-83b2-4f4ecbe3bc47@github.com>
References: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
 <hJ4PgOPmUJ1My31QgqDK7GyuPrWJMaOAROtlck4Qm3s=.180f2862-9ac7-4738-9383-c3346cc715d6@github.com>
 <55SDjO2Fj4yDEsB7Zbe3YacApuZZ5C-8x8VRO8aREJs=.3e97052f-7bd7-4dc2-83b2-4f4ecbe3bc47@github.com>
Message-ID: <BrAi6AEmVtlbCx37n70y4EuMZTXPgmQeox3h7rV5MdU=.a5166f6f-4455-4c60-8f2b-7b3721f5bbe1@github.com>

On Tue, 29 Apr 2025 14:09:51 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/RepaintManager.java line 394:
>> 
>>> 392:         }
>>> 393:         if (invalidComponents != null) {
>>> 394:             invalidComponents.remove(component);
>> 
>> I guess the `addInvalidComponent` above can be simplified as well?
>
> Simplified how?

the loop over invalidComponents

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24845#discussion_r2067799531

From aturbanov at openjdk.org  Mon May 19 08:26:28 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 19 May 2025 08:26:28 GMT
Subject: RFR: 8357226: Remove unnecessary List.indexOf from
 RepaintManager.removeInvalidComponent
In-Reply-To: <BrAi6AEmVtlbCx37n70y4EuMZTXPgmQeox3h7rV5MdU=.a5166f6f-4455-4c60-8f2b-7b3721f5bbe1@github.com>
References: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
 <hJ4PgOPmUJ1My31QgqDK7GyuPrWJMaOAROtlck4Qm3s=.180f2862-9ac7-4738-9383-c3346cc715d6@github.com>
 <55SDjO2Fj4yDEsB7Zbe3YacApuZZ5C-8x8VRO8aREJs=.3e97052f-7bd7-4dc2-83b2-4f4ecbe3bc47@github.com>
 <BrAi6AEmVtlbCx37n70y4EuMZTXPgmQeox3h7rV5MdU=.a5166f6f-4455-4c60-8f2b-7b3721f5bbe1@github.com>
Message-ID: <Cn3HZ3h1_q92LZiyEuioSfYl9dINZCbpu82JRqABtbo=.abb78b6c-bffd-4f97-8986-fffd4281ddd0@github.com>

On Wed, 30 Apr 2025 03:33:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Simplified how?
>
> the loop over invalidComponents

Do you suggest to use `List.indexOf` instead of manual loop?
https://github.com/openjdk/jdk/blob/375ac6d446332f0763ce294b200143ff63865cf6/src/java.desktop/share/classes/javax/swing/RepaintManager.java#L366-L371

This loop uses `==` comparison, while `List.indexOf` uses `equals()`. It could change semantic

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24845#discussion_r2068043227

From serb at openjdk.org  Mon May 19 08:26:28 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 08:26:28 GMT
Subject: RFR: 8357226: Remove unnecessary List.indexOf from
 RepaintManager.removeInvalidComponent
In-Reply-To: <Cn3HZ3h1_q92LZiyEuioSfYl9dINZCbpu82JRqABtbo=.abb78b6c-bffd-4f97-8986-fffd4281ddd0@github.com>
References: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
 <hJ4PgOPmUJ1My31QgqDK7GyuPrWJMaOAROtlck4Qm3s=.180f2862-9ac7-4738-9383-c3346cc715d6@github.com>
 <55SDjO2Fj4yDEsB7Zbe3YacApuZZ5C-8x8VRO8aREJs=.3e97052f-7bd7-4dc2-83b2-4f4ecbe3bc47@github.com>
 <BrAi6AEmVtlbCx37n70y4EuMZTXPgmQeox3h7rV5MdU=.a5166f6f-4455-4c60-8f2b-7b3721f5bbe1@github.com>
 <Cn3HZ3h1_q92LZiyEuioSfYl9dINZCbpu82JRqABtbo=.abb78b6c-bffd-4f97-8986-fffd4281ddd0@github.com>
Message-ID: <YDBfmXXO0wJyQq4ifNA0YoQiUcECNgSbLiO5bbBXxec=.a1b110ed-08da-4ca3-aeb4-9f17c3fcaeb2@github.com>

On Wed, 30 Apr 2025 07:23:06 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> the loop over invalidComponents
>
> Do you suggest to use `List.indexOf` instead of manual loop?
> https://github.com/openjdk/jdk/blob/375ac6d446332f0763ce294b200143ff63865cf6/src/java.desktop/share/classes/javax/swing/RepaintManager.java#L366-L371
> 
> This loop uses `==` comparison, while `List.indexOf` uses `equals()`. It could change semantic

ok, the it is fine as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24845#discussion_r2085735458

From duke at openjdk.org  Mon May 19 09:18:54 2025
From: duke at openjdk.org (duke)
Date: Mon, 19 May 2025 09:18:54 GMT
Subject: RFR: 8356966:
 java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails on Linux after
 JDK-8350203 [v3]
In-Reply-To: <Pob6jA6-9qJROD6s9JOTdSPcRMsx5cK0ba1kQ08cPjo=.9f850e75-2e1a-49c1-8a79-95a9d932b508@github.com>
References: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
 <Pob6jA6-9qJROD6s9JOTdSPcRMsx5cK0ba1kQ08cPjo=.9f850e75-2e1a-49c1-8a79-95a9d932b508@github.com>
Message-ID: <0mS3Twl3Ele2298nEB4g0IeJgupYV50zLiklKvUbsCo=.cf79a466-0921-4491-a647-7b7b241c9779@github.com>

On Thu, 15 May 2025 17:20:06 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> If the new test (`IgnoredWhitespaceTest`) runs on a system with Type1 physical fonts, it fails because the Type1 handling of ignorable whitespace characters does not match the behavior of the TrueType and macOS glyph mappers.
>> 
>> This PR updates the Type1 glyph mapper to follow the same rules in this area as the other glyph mappers.
>> 
>> It would probably be a good idea to consolidate all of this into the `CharToGlyphMapper` superclass at some point, so that we're not duplicating this handling across the subclasses, but some users are reporting failing builds and I wanted to keep the PR simple.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update bug tag in test class

@gredler 
Your change (at version fe1fda577f6797df4b1d7d8f062bf370971062a8) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25235#issuecomment-2890263679

From abhiscxk at openjdk.org  Mon May 19 10:24:50 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 19 May 2025 10:24:50 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos
In-Reply-To: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
Message-ID: <I2Utj5DRiTjfdBTu6tbAVR5ySLonDsPSMArwYnbVIac=.861e4a91-02a0-40a0-978e-af83a71542b4@github.com>

On Mon, 19 May 2025 08:15:29 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
> Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.
> 
> Verified the updated test in CI on macOS 14.7 machine and there is no failure.

Verified the test on different macOS versions and added the CI link in JBS

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

PR Comment: https://git.openjdk.org/jdk/pull/25299#issuecomment-2890482912

From jdv at openjdk.org  Mon May 19 11:12:51 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 19 May 2025 11:12:51 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos
In-Reply-To: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
Message-ID: <CS_Fzi-M_oKuDXmk693wHCU7Bmjc3pUp-EuVBXEFJZA=.e301d6d5-fb0d-4269-8148-91af651a29b8@github.com>

On Mon, 19 May 2025 08:15:29 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
> Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.
> 
> Verified the updated test in CI on macOS 14.7 machine and there is no failure.

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25299#pullrequestreview-2850370859

From aivanov at openjdk.org  Mon May 19 11:28:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 May 2025 11:28:54 GMT
Subject: RFR: 8355515: Clarify the purpose of forcePass() and forceFail()
 methods
In-Reply-To: <GhGmV2rZoBhUA2-m5WfhW6PiuqKpUM-OI4udOyAMzdc=.67162755-3ac1-4b0e-ada5-fda05b2c390a@github.com>
References: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
 <8gMOJCtNcN-Ou84pCTXuEV5h2AFnT0QMVOsYlPeD1EQ=.a967e9ae-1268-477a-8cb0-c503a7c63f39@github.com>
 <GhGmV2rZoBhUA2-m5WfhW6PiuqKpUM-OI4udOyAMzdc=.67162755-3ac1-4b0e-ada5-fda05b2c390a@github.com>
Message-ID: <5_HX1epfWLTiCKDe4F_U5dhaaeZ7CdU0E7IRVsNS_rs=.a6f1a09f-8c15-4175-9e65-2016030032d3@github.com>

On Sun, 18 May 2025 13:16:47 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> > After reading the description again, I started to wonder which adverb suits better: [?forcibly?](https://en.wiktionary.org/wiki/forcibly) or [?forcefully?](https://en.wiktionary.org/wiki/forcefully). Does any native English speaker have an opinion?
>
> I think forcefully is more apt compared to forcibly, changed it accordingly.

I talked to a native speaker, and _?forcibly?_ is the right word in this situation. Please revert.

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

PR Comment: https://git.openjdk.org/jdk/pull/25091#issuecomment-2890655051

From dgredler at openjdk.org  Mon May 19 11:31:59 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 19 May 2025 11:31:59 GMT
Subject: Integrated: 8356966:
 java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails on Linux after
 JDK-8350203
In-Reply-To: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
References: <MwLpa7sW8AAH4DFYA4rsju1zevaNLibf2ox0DDN0hWc=.d96c5560-1da7-4190-b9eb-dd0b59c43817@github.com>
Message-ID: <Yuu-HS3vWTCAGqxXC7kNVOYns_uQG9Sgmtuk3WPyWTg=.2a73afd6-5fd8-4c5f-ae60-7e2359add3b1@github.com>

On Wed, 14 May 2025 17:45:54 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> If the new test (`IgnoredWhitespaceTest`) runs on a system with Type1 physical fonts, it fails because the Type1 handling of ignorable whitespace characters does not match the behavior of the TrueType and macOS glyph mappers.
> 
> This PR updates the Type1 glyph mapper to follow the same rules in this area as the other glyph mappers.
> 
> It would probably be a good idea to consolidate all of this into the `CharToGlyphMapper` superclass at some point, so that we're not duplicating this handling across the subclasses, but some users are reporting failing builds and I wanted to keep the PR simple.

This pull request has now been integrated.

Changeset: 3acfa9e4
Author:    Daniel Gredler <dgredler at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0
Stats:     17 lines in 2 files changed: 8 ins; 0 del; 9 mod

8356966: java/awt/Graphics2D/DrawString/IgnoredWhitespaceTest.java fails on Linux after JDK-8350203

Reviewed-by: honkar, aivanov

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

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

From aivanov at openjdk.org  Mon May 19 12:19:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 May 2025 12:19:52 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos
In-Reply-To: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
Message-ID: <4Uo7SgKZMLYdTumK8iQgnU4tM2GIDKBaL-tnUZl2atU=.1821a43d-d262-4218-aec2-e69f0956f587@github.com>

On Mon, 19 May 2025 08:15:29 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
> Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.
> 
> Verified the updated test in CI on macOS 14.7 machine and there is no failure.

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/List/ListEnterExitTest.java line 1:

> 1: /*

I strongly suggest making `MouseEnterExitListener` a static nested class inside `ListEnterExitTest`. This prevents any duplicate class names from other classes when one works with tests in an IDE.

test/jdk/java/awt/List/ListEnterExitTest.java line 90:

> 88:             robot.waitForIdle();
> 89:             robot.delay(100);
> 90: 

I don't really understand why `waitForIdle` and `delay` are needed here at all.

Robot just moves mouse to generate mouse enter and exit events. It can do so without any delays, can't it?

test/jdk/java/awt/List/ListEnterExitTest.java line 92:

> 90: 
> 91:             robot.mousePress(InputEvent.BUTTON1_MASK);
> 92:             robot.mouseRelease(InputEvent.BUTTON1_MASK);

Is this mouse press needed only to release `mouseEnterExitListener.wait`?

I suggest using a `CountDownLatch` to replace `MouseEnterExitListener.passed_1` and `passed_2`. The code would need to time-await for both latches to be released.

Then `MouseEnterExitListener.mousePressed` can be removed completely together with the synchronized block above.

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

PR Review: https://git.openjdk.org/jdk/pull/25299#pullrequestreview-2850541693
PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2095578628
PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2095570577
PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2095576436

From aivanov at openjdk.org  Mon May 19 12:28:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 May 2025 12:28:52 GMT
Subject: RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <OOtQjOWTck5yF6VDjBVnfE-1_aa3vTN1vxeuiIrNjKY=.747aea97-b92c-47d0-937d-ae071468d7a9@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
 <SFCwpT-pkIwJZKnh66ZmtS1JGRHuxVueCVL12ozC2AI=.559a9c87-79e4-403a-a5d8-fe9c83f7f465@github.com>
 <OOtQjOWTck5yF6VDjBVnfE-1_aa3vTN1vxeuiIrNjKY=.747aea97-b92c-47d0-937d-ae071468d7a9@github.com>
Message-ID: <95g0weiARkYC01wgCQbJNJD1iwc_RpCUS3sH1i1K_-A=.333d4836-3718-41c3-a998-4e2bccad3c1b@github.com>

On Mon, 19 May 2025 08:10:42 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Toolkit.java line 1745:
>> 
>>> 1743:         synchronized (this) {
>>> 1744:             SelectiveAWTEventListener selectiveListener =
>>> 1745:                 listener2SelectiveListener.remove(localL);
>> 
>> While analyzing the implementation of this method, I noticed a potential bug at the beginning. Should it instead be:
>> 
>> if (localL == null) {
>>     return;
>> }
>> 
>> ?
>
> Looks like yes. I think it's worth to create a separate issue to fix it.

It doesn't matter, it looks? `localL` is `null` if and only if listener is `null`.

However, I'd put the null-check above the call to `deProxyAWTEventListener` to avoid any confusion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24692#discussion_r2095589937

From aivanov at openjdk.org  Mon May 19 12:28:51 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 May 2025 12:28:51 GMT
Subject: RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
Message-ID: <dvfbVAI16V4HtAH39OX-WJLFqp-Rro6MyHOq_ll_zEg=.5e3c9628-08b7-417d-9946-89dc0fec4fb7@github.com>

On Wed, 16 Apr 2025 15:07:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24692#pullrequestreview-2850572034

From dgredler at openjdk.org  Mon May 19 12:29:51 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 19 May 2025 12:29:51 GMT
Subject: RFR: 8356814: LineBreakMeasurer.nextLayout() slower than necessary
 when no break needed
In-Reply-To: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>
References: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>
Message-ID: <gEb88_bZtRzaF6s4Jj4VZMNODz7cFG2qLcn2CMGC6fc=.2bb02b0c-34d5-427c-a6fc-c892398b209e@github.com>

On Mon, 12 May 2025 20:35:52 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> `LineBreakMeasurer.nextLayout()` calls `nextOffset()` internally to calculate the layout limit. When this happens, a `GlyphVector` is created and the layout engine is invoked to shape the text. The `GlyphVector` is cached in the relevant `ExtendedTextSourceLabel` component.
> 
> `LineBreakMeasurer.nextLayout()` then calls `TextMeasurer.getLayout()` which eventually asks that same `ExtendedTextSourceLabel` component for a subset component. This triggers the creation of a fresh `ExtendedTextSourceLabel` without the cached `GlyphVector`.
> 
> However, this fresh `ExtendedTextSourceLabel` is not necessary if the subset requested perfectly matches the already-existing `ExtendedTextSourceLabel` component. This happens when the text is short enough that no line break is needed.
> 
> I think we should change `ExtendedTextSourceLabel.getSubset()` to return `this` if the requested subset is identical to the existing instance. This will allow us to use the existing cached `GlyphVector`, and the call to `LineBreakMeasurer.nextLayout()` will trigger text shaping once, rather than twice.
> 
> In local testing, the test program below ran in ~1250 ms before this optimization, and ran in ~960 ms after the change (a 23% reduction in run time).
> 
> The following three existing test classes provide good regression test coverage for this change:
> - test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTrackingAuto
> - test/jdk/java/awt/font/LineBreakMeasurer/TestLineBreakWithFontSub
> - test/jdk/java/awt/font/LineBreakMeasurer/FRCTest
> 
> 
> public class LineBreakMeasurerPerfTest {
> 
>     public static void main(String[] args) {
> 
>         float advance = 0;
>         long start = System.currentTimeMillis();
>         AttributedString string = new AttributedString("This is a test.");
>         FontRenderContext frc = new FontRenderContext(new AffineTransform(), true, true);
> 
>         for (int i = 0; i < 100_000; i++) {
>             LineBreakMeasurer measurer = new LineBreakMeasurer(string.getIterator(), frc);
>             TextLayout layout = measurer.nextLayout(999); // large enough to not require break
>             advance = Math.max(advance, layout.getAdvance());
>         }
> 
>         long end = System.currentTimeMillis();
>         System.out.println((end - start) + " ms elapsed (advance: " + advance + ")");
>     }
> 
> }

If any reviewers have some extra cycles, I'd appreciate a second review on this one. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/25193#issuecomment-2890826777

From aivanov at openjdk.org  Mon May 19 12:37:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 May 2025 12:37:54 GMT
Subject: RFR: 8357226: Remove unnecessary List.indexOf from
 RepaintManager.removeInvalidComponent
In-Reply-To: <YDBfmXXO0wJyQq4ifNA0YoQiUcECNgSbLiO5bbBXxec=.a1b110ed-08da-4ca3-aeb4-9f17c3fcaeb2@github.com>
References: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
 <hJ4PgOPmUJ1My31QgqDK7GyuPrWJMaOAROtlck4Qm3s=.180f2862-9ac7-4738-9383-c3346cc715d6@github.com>
 <55SDjO2Fj4yDEsB7Zbe3YacApuZZ5C-8x8VRO8aREJs=.3e97052f-7bd7-4dc2-83b2-4f4ecbe3bc47@github.com>
 <BrAi6AEmVtlbCx37n70y4EuMZTXPgmQeox3h7rV5MdU=.a5166f6f-4455-4c60-8f2b-7b3721f5bbe1@github.com>
 <Cn3HZ3h1_q92LZiyEuioSfYl9dINZCbpu82JRqABtbo=.abb78b6c-bffd-4f97-8986-fffd4281ddd0@github.com>
 <YDBfmXXO0wJyQq4ifNA0YoQiUcECNgSbLiO5bbBXxec=.a1b110ed-08da-4ca3-aeb4-9f17c3fcaeb2@github.com>
Message-ID: <DF8ukEr0pPYhRM8K5XbNHoQ1UBhMRzZcYuJn22HLfNg=.d9d22b75-f7e8-4489-8d84-37cc49adc8c0@github.com>

On Tue, 13 May 2025 00:47:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Do you suggest to use `List.indexOf` instead of manual loop?
>> https://github.com/openjdk/jdk/blob/375ac6d446332f0763ce294b200143ff63865cf6/src/java.desktop/share/classes/javax/swing/RepaintManager.java#L366-L371
>> 
>> This loop uses `==` comparison, while `List.indexOf` uses `equals()`. It could change semantic
>
> ok, the it is fine as is.

Yet there could be a logical error anyway? `addInvalidComponent` uses identity comparison when adding a component but `removeInvalidComponent` relies on `equals` method to remove a component.

If a component overrides `equals`, it could lead to unpredictable behaviour: a wrong component could be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24845#discussion_r2095611426

From aivanov at openjdk.org  Mon May 19 12:54:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 May 2025 12:54:58 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
In-Reply-To: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
Message-ID: <XcqAO2xvFvNB-I6F9LJbzDbZKjV4FgGCEAsZm2emO2k=.7cca3d51-104a-43cd-9fc0-2008ed905f7a@github.com>

On Fri, 16 May 2025 23:04:28 GMT, Phil Race <prr at openjdk.org> wrote:

> Update the some code examples and accompanying images to no longer mention or display as applets.

src/java.desktop/share/classes/java/awt/GridBagLayout.java line 243:

> 241:  * right-to-left container.
> 242:  *
> 243:  * <div style="margin:0 auto;width:850px;text-align:center;font-weight:bold">

Is it possible to keep the width small as it was?

src/java.desktop/share/classes/java/awt/GridBagLayout.java line 288:

> 286:  * public class GridBagLayoutExample {
> 287:  *
> 288:  *  static void addButton(String name,

Suggestion:

 *  private static void addButton(String name,

src/java.desktop/share/classes/java/awt/GridBagLayout.java line 295:

> 293:  *     gridbag.setConstraints(button, c);
> 294:  *     frame.add(button);
> 295:  *  }

The `add` method should indented by 4 spaces to the right.

src/java.desktop/share/classes/java/awt/GridBagLayout.java line 303:

> 301:  *       GridBagLayout gridbag = new GridBagLayout();
> 302:  *       GridBagConstraints c = new GridBagConstraints();
> 303:  *       frame.setLayout(gridbag);

The `main` method should be indented by 4 spaces to the right, it's inside `GridBagLayoutExample` class.

src/java.desktop/share/classes/java/awt/MediaTracker.java line 108:

> 106:  *          tracker.addImage(bg, 0);
> 107:  *          for (int i = 0; i < 5; i++) {
> 108:  *              anim[i] = tk.getImage("anim"+i+".gif");

Suggestion:

 *              anim[i] = tk.getImage("anim" + i + ".gif");

src/java.desktop/share/classes/java/awt/doc-files/BorderLayout-1.png line 1:

> 1: ?PNG

The images would look better with square borders? which are left on Windows 10 only.

If it's possible to make the pixels on the rounded corners transparent or at least white, the images would look better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2095631052
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2095624810
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2095625842
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2095627784
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2095635506
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2095643191

From mvs at openjdk.org  Mon May 19 12:57:43 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Mon, 19 May 2025 12:57:43 GMT
Subject: RFR: 8355515: Clarify the purpose of forcePass() and forceFail()
 methods [v3]
In-Reply-To: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
References: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
Message-ID: <M6IugbsjaJYGFtPlifOtgMBNiiRAzck__6I9n9F0uAg=.78fe2f17-f837-4313-87a6-885fa4842fb7@github.com>

> Clarified the purpose of forcePass() and forceFail() methods and recommended usage of these methods.
> 
> forcePass() contained an incorrect sample; it's addressed by [JDK-8355441](https://bugs.openjdk.org/browse/JDK-8355441).
> 
> The description of forceFail() has been expanded, too.
> 
> 
> A new section in the description of the PassFailJFrame added to describe forcePass() and forceFail().

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed : Forcibly wordings changed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25091/files
  - new: https://git.openjdk.org/jdk/pull/25091/files/9f0a6321..ff288f0e

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

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

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

From aivanov at openjdk.org  Mon May 19 13:05:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 May 2025 13:05:57 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
In-Reply-To: <07s-WJJc4k0HyDey7NWxID39ua5z4xxbKbEJShmWBFo=.00b3686c-0e29-4e55-9d37-8210ed44f344@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <07s-WJJc4k0HyDey7NWxID39ua5z4xxbKbEJShmWBFo=.00b3686c-0e29-4e55-9d37-8210ed44f344@github.com>
Message-ID: <l0mB342r4v7HiBw6SsySdCxKogWGWaV5WERE5lF-Lu4=.36591b19-e567-4d74-a3b2-2e2d995813eb@github.com>

On Mon, 19 May 2025 00:04:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> It seems the new screenshots could be improved by capturing them on a HiDPI (Retina) display, as the current images appear blurry. And to eliminate background elements in the corners, it might be better to capture screenshots of undecorated windows as was done in the old images.

To make the screenshots look good on High DPI displays, we need several images (preferably at 100%, 150% and 200% as the most common scales) and use the [**`srcset` attribute**](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/img#srcset) of the `<img>` element to provide different resolutions.

If you just create a screenshot on (Retina at 200% scale), the screenshots will be *too large* and still blurry as browsers will still scale up the screenshots to the scale of the display because the [`src` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/img#src) is treated as 100%-scale candidate only.

---

If we agree to go this way, I can create screenshots on Windows 10 (which still uses square window borders) in different resolutions.

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

PR Comment: https://git.openjdk.org/jdk/pull/25278#issuecomment-2890944411

From tr at openjdk.org  Mon May 19 13:52:16 2025
From: tr at openjdk.org (Tejesh R)
Date: Mon, 19 May 2025 13:52:16 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v3]
In-Reply-To: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
Message-ID: <JVyEYDeaC2nRhod516RnecC9xDNUAlJXt0yz4I5xgvo=.a64851ce-c2f6-4e9d-bbdc-d6ad36626f56@github.com>

> The rendering of the directory names are handled as JLabel w.r.t Look and feel and also either Details/List view. Though FilePane creates basic rendering for these two few Look and Feel define their own renderers and also ComboBox Directory directory name view. Since HTML filtering is not taken care in any of these renderers, JLabel renders them as HTML document if nothing is set or specified.
> The fix is to get "html.disable" property from JFileChooser and set the same to JLabel component which renders and set Directory name. Hence applications can either enable/disable this property and control HTML rendering of directory name.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24439/files
  - new: https://git.openjdk.org/jdk/pull/24439/files/ebe3d910..d4660c75

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

  Stats: 80 lines in 7 files changed: 16 ins; 21 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/24439.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24439/head:pull/24439

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

From tr at openjdk.org  Mon May 19 13:52:20 2025
From: tr at openjdk.org (Tejesh R)
Date: Mon, 19 May 2025 13:52:20 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v2]
In-Reply-To: <I2gu3h6HaCY36funo-uLbP-vtqTk49Mn8Ey_3Tb2vOk=.81f32408-dd1f-4e89-876e-4c04092f2247@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <JBqag_eOA8EpegeuHHyWg9X4sxDcuaDBx4wfLH_Gkjw=.bcb5562f-6f43-4294-be9a-791726e819a7@github.com>
 <I2gu3h6HaCY36funo-uLbP-vtqTk49Mn8Ey_3Tb2vOk=.81f32408-dd1f-4e89-876e-4c04092f2247@github.com>
Message-ID: <uFaqTffpnz93YTc_MAIxkpzs1te8iRgPSVs9nIqk0yI=.253dc22b-d700-4bc4-825c-34727668af7b@github.com>

On Fri, 16 May 2025 19:24:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R 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://git.openjdk.java.net/jdk into branch_8139228
>>  - Fix for windows L&F
>>  - Fix + Manual test
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java line 1195:
> 
>> 1193:             setIcon(fc.getIcon(file));
>> 1194:             setEnabled(isSelectableInList(file));
>> 1195:             this.putClientProperty("html.disable", getFileChooser().getClientProperty("html.disable"));
> 
> Suggestion:
> 
>             putClientProperty("html.disable", getFileChooser().getClientProperty("html.disable"));
> 
> No method call above uses explicit `this`, I see no reason to use it here either.
> 
> This comment applies to all the modified files.

Updated.

> src/java.desktop/share/classes/sun/swing/FilePane.java line 1238:
> 
>> 1236:             setText(text);
>> 1237:             this.putClientProperty("html.disable", getFileChooser().getClientProperty("html.disable"));
>> 1238:             return this;
> 
> Be consistent at least inside one file. Here you removed the blank line, but below at 1632?1635 you preserved the blank line.

Updated.

> src/java.desktop/share/classes/sun/swing/FilePane.java line 1635:
> 
>> 1633:             this.putClientProperty("html.disable", getFileChooser().getClientProperty("html.disable"));
>> 1634: 
>> 1635:             return this;
> 
> I prefer this style everywhere: all the code that sets up the component, a blank line followed by the `return` statement.
> 
> I'd add a blank line before `putClientProperty` as well ? setting the `"html.disable"` property isn't the part of previous statements which configure the renderer component one way or another, and, with blank lines around this call, it will stand out in the code.

Updated.

> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 68:
> 
>> 66:                     .instructions(INSTRUCTIONS)
>> 67:                     .columns(45)
>> 68:                     .testUI(initialize())
> 
> In majority of cases, you should pass a method reference rather than the result of a method call to `testUI`.
> 
> As it's written, the `initialize` is executed on the main thread, and its result?the list frames?is passed to `PassFailJFrame`.
> 
> What you actually want is `HTMLFileName::initialize`. In this case, the `PassFailJFrame` framework will call the `initialize` method on EDT when the time to create UI comes.

Updated.

> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 69:
> 
>> 67:                     .columns(45)
>> 68:                     .testUI(initialize())
>> 69:                     .position(PassFailJFrame.Position.TOP_LEFT_CORNER)
> 
> Suggestion:
> 
>                     .positionTestUIRightColumn()
> 
> I suggest using [**`positionTestUIRightColumnCentered`**](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.Builder.html#positionTestUIRightColumnCentered()) to lay out the entire test UI in the centre of the screen.
> 
> Since two file choosers take quite a lot of space, the file chooser at the bottom doesn't fit the screen if you use  [`positionTestUIRightColumn`](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.Builder.html#positionTestUIRightColumn()).
> 
> Alternatively, you can choose a horizontal layout with [`positionTestUIBottomRowCentered`](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.Builder.html#positionTestUIBottomRowCentered()).

Yeah, [positionTestUIBottomRowCentered](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.Builder.html#positionTestUIBottomRowCentered()) works better. Updated.

> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 79:
> 
>> 77:     }
>> 78: 
>> 79:     public static List<JFrame> initialize() {
> 
> Suggestion:
> 
>     private static List<JFrame> initialize() {

Updated

> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 84:
> 
>> 82:         String fileName = homeDir + File.separator +
>> 83:                 "<html><h1 color=#ff00ff><font face=\"Comic Sans MS\">Testing Name";
>> 84:         directory = new File(fileName);
> 
> You shouldn't create the files in the home directory of the user any way. Create them in the current directory which is a scratch directory when the test is run with jtreg; the contents of the scratch directory is automatically removed by jtreg when the test exits, even if the test itself fails to remove its own temporary files.
> 
> Yet if you create the files in the user's home, all these files and directories will be still be around if anything goes awry in the test.

Since I have used virtual file system, this would be skipped now.

> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 85:
> 
>> 83:                 "<html><h1 color=#ff00ff><font face=\"Comic Sans MS\">Testing Name";
>> 84:         directory = new File(fileName);
>> 85:         directory.mkdir();
> 
> Do you need the directory at all?
> 
> Use `VirtualFileSystemView` for all platforms. The fact that it's possible to create files with HTML tags in the name is irrelevant to the test.

I've used VirtualFileSystemView to all platforms. Having both directory and file with HTML tags in the virtual FSV is helpful in verifying both File Pane and Directory ComboBox view too.

> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 96:
> 
>> 94:             jfc = new JFileChooser(homeDir);
>> 95:             jfc_HTML_Enabled = new JFileChooser(homeDir);
>> 96:         }
> 
> I suggest creating a method that creates one file chooser placed in a frame; pass a boolean parameter to specify whether to set the `"html.disable"` property to `false` or keep its default value of `true`.
> 
> Then your `initialize` method would be as simple as a single return statement:
> 
> 
>     private static List<JFrame> initialize() {
>         return List.of(createFileChooser(true), createFileChooser(false));
>     }

Updated.

> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 107:
> 
>> 105:     }
>> 106: 
>> 107:     static class VirtualFileSystemView extends FileSystemView {
> 
> Suggestion:
> 
>     private static class VirtualFileSystemView extends FileSystemView {

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2095746398
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2095746660
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2095746841
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2095747011
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2095747986
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2095752012
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2095753291
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2095748627
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2095753544
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2095751839

From duke at openjdk.org  Mon May 19 14:19:51 2025
From: duke at openjdk.org (duke)
Date: Mon, 19 May 2025 14:19:51 GMT
Subject: RFR: 8355515: Clarify the purpose of forcePass() and forceFail()
 methods [v3]
In-Reply-To: <M6IugbsjaJYGFtPlifOtgMBNiiRAzck__6I9n9F0uAg=.78fe2f17-f837-4313-87a6-885fa4842fb7@github.com>
References: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
 <M6IugbsjaJYGFtPlifOtgMBNiiRAzck__6I9n9F0uAg=.78fe2f17-f837-4313-87a6-885fa4842fb7@github.com>
Message-ID: <TYxaug6GSjDEn5s5CiZ5hPLnNpBDz0RnXOTQhBNPtOg=.b3f43c31-3fe2-484c-996f-8ffa1de56688@github.com>

On Mon, 19 May 2025 12:57:43 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Clarified the purpose of forcePass() and forceFail() methods and recommended usage of these methods.
>> 
>> forcePass() contained an incorrect sample; it's addressed by [JDK-8355441](https://bugs.openjdk.org/browse/JDK-8355441).
>> 
>> The description of forceFail() has been expanded, too.
>> 
>> 
>> A new section in the description of the PassFailJFrame added to describe forcePass() and forceFail().
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed : Forcibly wordings changed

@manukumarvs 
Your change (at version ff288f0eb783215eabcfbe97a3d382fff91d7c76) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25091#issuecomment-2891205393

From aivanov at openjdk.org  Mon May 19 14:14:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 May 2025 14:14:52 GMT
Subject: RFR: 8355515: Clarify the purpose of forcePass() and forceFail()
 methods [v3]
In-Reply-To: <M6IugbsjaJYGFtPlifOtgMBNiiRAzck__6I9n9F0uAg=.78fe2f17-f837-4313-87a6-885fa4842fb7@github.com>
References: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
 <M6IugbsjaJYGFtPlifOtgMBNiiRAzck__6I9n9F0uAg=.78fe2f17-f837-4313-87a6-885fa4842fb7@github.com>
Message-ID: <b9QrkeQDk9bcRxtjV7aNNlYt4glgwVQ4WI1Q2uKICuY=.b975b8ea-dd64-41f3-9870-85cd623d21db@github.com>

On Mon, 19 May 2025 12:57:43 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Clarified the purpose of forcePass() and forceFail() methods and recommended usage of these methods.
>> 
>> forcePass() contained an incorrect sample; it's addressed by [JDK-8355441](https://bugs.openjdk.org/browse/JDK-8355441).
>> 
>> The description of forceFail() has been expanded, too.
>> 
>> 
>> A new section in the description of the PassFailJFrame added to describe forcePass() and forceFail().
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed : Forcibly wordings changed

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25091#pullrequestreview-2850924030

From aivanov at openjdk.org  Mon May 19 14:30:51 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 May 2025 14:30:51 GMT
Subject: RFR: 8355515: Clarify the purpose of forcePass() and forceFail()
 methods [v3]
In-Reply-To: <M6IugbsjaJYGFtPlifOtgMBNiiRAzck__6I9n9F0uAg=.78fe2f17-f837-4313-87a6-885fa4842fb7@github.com>
References: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
 <M6IugbsjaJYGFtPlifOtgMBNiiRAzck__6I9n9F0uAg=.78fe2f17-f837-4313-87a6-885fa4842fb7@github.com>
Message-ID: <RvLfZMpJV5i5Jh4K8VBus0gS_lJ75Mk-ljVq8GYqks0=.fdd64076-3965-4b42-a7c1-9d3a0379ea53@github.com>

On Mon, 19 May 2025 12:57:43 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Clarified the purpose of forcePass() and forceFail() methods and recommended usage of these methods.
>> 
>> forcePass() contained an incorrect sample; it's addressed by [JDK-8355441](https://bugs.openjdk.org/browse/JDK-8355441).
>> 
>> The description of forceFail() has been expanded, too.
>> 
>> 
>> A new section in the description of the PassFailJFrame added to describe forcePass() and forceFail().
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed : Forcibly wordings changed

I've regenerated the javadoc for `PassFailJFrame`:

* [Description of `forcePass` and `forceFail` methods](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.html#forcePassAndFail) in the top documentation;
* [`forcePass`](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.html#forcePass()),
* [`forceFail`](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.html#forceFail()),
* [`forceFail(String)`](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.html#forceFail(java.lang.String)).

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

PR Comment: https://git.openjdk.org/jdk/pull/25091#issuecomment-2891248330

From aivanov at openjdk.org  Mon May 19 14:35:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 May 2025 14:35:57 GMT
Subject: RFR: 8355515: Clarify the purpose of forcePass() and forceFail()
 methods
In-Reply-To: <GhGmV2rZoBhUA2-m5WfhW6PiuqKpUM-OI4udOyAMzdc=.67162755-3ac1-4b0e-ada5-fda05b2c390a@github.com>
References: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
 <8gMOJCtNcN-Ou84pCTXuEV5h2AFnT0QMVOsYlPeD1EQ=.a967e9ae-1268-477a-8cb0-c503a7c63f39@github.com>
 <GhGmV2rZoBhUA2-m5WfhW6PiuqKpUM-OI4udOyAMzdc=.67162755-3ac1-4b0e-ada5-fda05b2c390a@github.com>
Message-ID: <f1Ra5Mje-Nt4NEYhoK9nyV-STioFpM2bIr1yRiS0Ve0=.92a29f99-5523-44a0-9cfb-0f3b727bc477@github.com>

On Sun, 18 May 2025 13:16:47 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> After reading the description again, I started to wonder which adverb suits better: [?forcibly?](https://en.wiktionary.org/wiki/forcibly) or [?forcefully?](https://en.wiktionary.org/wiki/forcefully). Does any native English speaker have an opinion?
>
>> After reading the description again, I started to wonder which adverb suits better: [?forcibly?](https://en.wiktionary.org/wiki/forcibly) or [?forcefully?](https://en.wiktionary.org/wiki/forcefully). Does any native English speaker have an opinion?
> I think forcefully is more apt compared to forcibly, changed it accordingly.

@manukumarvs I'll leave the PR open for another day before sponsoring in case anyone else wants to leave a comment. Then I'll sponsor integration of the fix. Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/25091#issuecomment-2891263943

From aivanov at openjdk.org  Mon May 19 17:27:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 May 2025 17:27:53 GMT
Subject: RFR: 8356844: Missing @Serial annotation for
 sun.print.CustomOutputBin#serialVersionUID [v2]
In-Reply-To: <fpDOiYqI1fZyyJsB7L9ZpOva-N6Q-Sw8GBzRZRnD5Fc=.507b84ea-be57-4775-91ec-ad996f25b212@github.com>
References: <zH4YF8csdxwjpO7t7x7tWVZGQ4d77QkX2NzJfu4gRvc=.b8dcc685-f3cc-47de-b527-7a2523a93310@github.com>
 <fpDOiYqI1fZyyJsB7L9ZpOva-N6Q-Sw8GBzRZRnD5Fc=.507b84ea-be57-4775-91ec-ad996f25b212@github.com>
Message-ID: <082o5pddclhoK1wjwQicxbQiy2XZspFNObVuoY7TyhI=.0a8e21fc-f793-47b6-a594-9e079923254d@github.com>

On Tue, 13 May 2025 20:35:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The serialVersionUID field in sun.print.CustomOutputBin is missing the `@Serial` annotation. This is the only one missing usage of `@Serial` in the java.desktop module. The class was introduced in [JDK-8314070](https://bugs.openjdk.org/browse/JDK-8314070), after the `@Serial` annotation was applied to java.desktop in [JDK-8259522](https://bugs.openjdk.org/browse/JDK-8259522).
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.desktop/share/classes/sun/print/CustomOutputBin.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25202#pullrequestreview-2851537515

From prr at openjdk.org  Mon May 19 18:01:52 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 19 May 2025 18:01:52 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v2]
In-Reply-To: <XRQDe9qB8vtFFeCAbMRxRr5lB4vBCaFCAkDc9autvRc=.597810e7-8ce4-4879-bcf6-a4739273ccdf@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <XRQDe9qB8vtFFeCAbMRxRr5lB4vBCaFCAkDc9autvRc=.597810e7-8ce4-4879-bcf6-a4739273ccdf@github.com>
Message-ID: <X_NVLifZRa7ByjwfMPL_oz-F5EYchiDPb-tELgfFetE=.b2587e40-b23e-4f5d-bec8-b34206e90b22@github.com>

On Fri, 16 May 2025 20:45:39 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The issue is the inability to move the mouse cursor using `java.awt.Robot` on Oracle Linux 10 (which has not yet been released). FIY, the OL10 is no longer provides an Xorg session, so only Wayland is available.
>> It is a JCK conformance failure. 
>> 
>> ---
>> 
>> In our robot implementation, we emulate mouse/keyboard actions using the XTEST extension protocol.
>> 
>> The XTEST calls are now wired to [libEI](https://libinput.pages.freedesktop.org/libei/api/index.html):
>> 
>> 1.
>> 
>> It now asks for a user confirmation to allow interaction, so we should now be able to click on native applications, window titles, etc.
>> 
>> However, our robot implementation is mostly uses XTEST, but there is an exception:
>> for mouse move we use XWarpPointer, which is not part of the XTEST, thus it is not propagated outside of Xwayland server.
>> 
>> So we have a situation where mouse is moving only inside Xwayland server, and we see the mouse enter/exit events,
>> on mouse press we call XTestFakeButtonEvent and it is handled by libei,
>> so the click happens where is the actual mouse cursor is in the system. That is why the test fails.
>> 
>> To avoid this situation we should use XTestFakeMotionEvent for mouseMove in Xwayland case.
>> 
>> It would be a simple solution, but
>> 
>> 
>> 2.
>> 
>> This permission granted by a user doesn't persist across reboots, it timeouts after a period of inactivity.
>> 
>> It still seems to conform to the specifications, but we will not be able to conveniently run automated tests in this case.
>> 
>> ---
>> 
>> So as a solution we can switch the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
>> It has session and `restore_token` functionality to keep permissions granted by a user, similar to what we use in a [Screencast](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html) for taking screenshots.
>> Most of the code can be reused, and it has everything we need.
>> 
>> 
>> * It is only enabled by default on Wayland and Gnome Shell 47 and higher due to XTEST API complications that first arose in this version. For earlier versions, Screencast is used instead.
>> * A new value has been introduced for the `awt.robot.screenshotMethod` system property - `dbusRemoteDesktop`. It works on Ubuntu 24.04 with Gnome 46, but is not enabled by default.
>> * extra mouse buttons are not supported yet, [JDK-8357142](https://bugs.openjdk.org/browse/JDK-8357142)
>> * Since w...
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only call getGnomeShellMajorVersion when the desktop is Gnome.

I've looked at the code.
I've run a build from Alexander and another I did and done some testing on Fedora 42 - which is gnome 48. 
I see the expected tokens and the robot-based tests I did worked as expected.
Waiting to see some results from our internal CI testing systems on systems with gnome < 47 and wayland and if that looks good I will approve

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

PR Comment: https://git.openjdk.org/jdk/pull/25265#issuecomment-2891841152

From serb at openjdk.org  Mon May 19 19:11:09 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 19:11:09 GMT
Subject: RFR: 8356844: Missing @Serial annotation for
 sun.print.CustomOutputBin#serialVersionUID [v3]
In-Reply-To: <zH4YF8csdxwjpO7t7x7tWVZGQ4d77QkX2NzJfu4gRvc=.b8dcc685-f3cc-47de-b527-7a2523a93310@github.com>
References: <zH4YF8csdxwjpO7t7x7tWVZGQ4d77QkX2NzJfu4gRvc=.b8dcc685-f3cc-47de-b527-7a2523a93310@github.com>
Message-ID: <APlYiiTJ17SdMFDQXq9GEx5miID0tHTVp3OKuiRoKbA=.c7604b5f-2c9e-469a-9150-cf64044c4636@github.com>

> The serialVersionUID field in sun.print.CustomOutputBin is missing the `@Serial` annotation. This is the only one missing usage of `@Serial` in the java.desktop module. The class was introduced in [JDK-8314070](https://bugs.openjdk.org/browse/JDK-8314070), after the `@Serial` annotation was applied to java.desktop in [JDK-8259522](https://bugs.openjdk.org/browse/JDK-8259522).

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 branch 'openjdk:master' into JDK-8356844
 - Update src/java.desktop/share/classes/sun/print/CustomOutputBin.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - 8356844: Missing @Serial annotation for sun.print.CustomOutputBin#serialVersionUID

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25202/files
  - new: https://git.openjdk.org/jdk/pull/25202/files/901a1346..8b699711

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

  Stats: 29535 lines in 731 files changed: 11453 ins; 13953 del; 4129 mod
  Patch: https://git.openjdk.org/jdk/pull/25202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25202/head:pull/25202

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

From serb at openjdk.org  Mon May 19 21:35:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 21:35:56 GMT
Subject: Integrated: 8356844: Missing @Serial annotation for
 sun.print.CustomOutputBin#serialVersionUID
In-Reply-To: <zH4YF8csdxwjpO7t7x7tWVZGQ4d77QkX2NzJfu4gRvc=.b8dcc685-f3cc-47de-b527-7a2523a93310@github.com>
References: <zH4YF8csdxwjpO7t7x7tWVZGQ4d77QkX2NzJfu4gRvc=.b8dcc685-f3cc-47de-b527-7a2523a93310@github.com>
Message-ID: <qEM1jpzWC4J0ld_zkzT0qkov2qx-Le4i9y8wQucpNpM=.72808311-3bd2-4e73-b847-3c3f29f325c2@github.com>

On Tue, 13 May 2025 08:19:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The serialVersionUID field in sun.print.CustomOutputBin is missing the `@Serial` annotation. This is the only one missing usage of `@Serial` in the java.desktop module. The class was introduced in [JDK-8314070](https://bugs.openjdk.org/browse/JDK-8314070), after the `@Serial` annotation was applied to java.desktop in [JDK-8259522](https://bugs.openjdk.org/browse/JDK-8259522).

This pull request has now been integrated.

Changeset: fbeea1da
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fbeea1daef6a65875d713395c489483762d804fe
Stats:     4 lines in 1 file changed: 1 ins; 2 del; 1 mod

8356844: Missing @Serial annotation for sun.print.CustomOutputBin#serialVersionUID

Reviewed-by: aivanov, prr

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

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

From kizune at openjdk.org  Mon May 19 21:43:54 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 19 May 2025 21:43:54 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog()
In-Reply-To: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
Message-ID: <fnY7V_A-EgX0b6L6g8KPkXqln9mZx7x3zV6PWkNi80U=.7f11a7cb-6041-4589-9177-f4d1e00dc5cc@github.com>

On Mon, 19 May 2025 06:06:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
> Fixed by setting the divider location before rendering the left and right components..

Looks good.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25294#pullrequestreview-2852056409

From azvegint at openjdk.org  Mon May 19 23:06:39 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 19 May 2025 23:06:39 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v3]
In-Reply-To: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
Message-ID: <q-jAcupHO9xmaafZinbFmnYuoYs4fzHMAjiNtfldNx4=.8e1fb82b-a181-4610-9557-8c5be252e58e@github.com>

> The issue is the inability to move the mouse cursor using `java.awt.Robot` on Oracle Linux 10 (which has not yet been released). FIY, the OL10 is no longer provides an Xorg session, so only Wayland is available.
> It is a JCK conformance failure. 
> 
> ---
> 
> In our robot implementation, we emulate mouse/keyboard actions using the XTEST extension protocol.
> 
> The XTEST calls are now wired to [libEI](https://libinput.pages.freedesktop.org/libei/api/index.html):
> 
> 1.
> 
> It now asks for a user confirmation to allow interaction, so we should now be able to click on native applications, window titles, etc.
> 
> However, our robot implementation is mostly uses XTEST, but there is an exception:
> for mouse move we use XWarpPointer, which is not part of the XTEST, thus it is not propagated outside of Xwayland server.
> 
> So we have a situation where mouse is moving only inside Xwayland server, and we see the mouse enter/exit events,
> on mouse press we call XTestFakeButtonEvent and it is handled by libei,
> so the click happens where is the actual mouse cursor is in the system. That is why the test fails.
> 
> To avoid this situation we should use XTestFakeMotionEvent for mouseMove in Xwayland case.
> 
> It would be a simple solution, but
> 
> 
> 2.
> 
> This permission granted by a user doesn't persist across reboots, it timeouts after a period of inactivity.
> 
> It still seems to conform to the specifications, but we will not be able to conveniently run automated tests in this case.
> 
> ---
> 
> So as a solution we can switch the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
> It has session and `restore_token` functionality to keep permissions granted by a user, similar to what we use in a [Screencast](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html) for taking screenshots.
> Most of the code can be reused, and it has everything we need.
> 
> 
> * It is only enabled by default on Wayland and Gnome Shell 47 and higher due to XTEST API complications that first arose in this version. For earlier versions, Screencast is used instead.
> * A new value has been introduced for the `awt.robot.screenshotMethod` system property - `dbusRemoteDesktop`. It works on Ubuntu 24.04 with Gnome 46, but is not enabled by default.
> * extra mouse buttons are not supported yet, [JDK-8357142](https://bugs.openjdk.org/browse/JDK-8357142)
> * Since we are now moving the mouse using a non-X11 API and `MouseInfo.getPointerInfo().getLo...

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

  call OpenPipeWireRemote even for remote desktop session calls

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25265/files
  - new: https://git.openjdk.org/jdk/pull/25265/files/5d08133e..b8a430ef

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

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

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

From azvegint at openjdk.org  Mon May 19 23:06:39 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 19 May 2025 23:06:39 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v2]
In-Reply-To: <XRQDe9qB8vtFFeCAbMRxRr5lB4vBCaFCAkDc9autvRc=.597810e7-8ce4-4879-bcf6-a4739273ccdf@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <XRQDe9qB8vtFFeCAbMRxRr5lB4vBCaFCAkDc9autvRc=.597810e7-8ce4-4879-bcf6-a4739273ccdf@github.com>
Message-ID: <Zb0ta8o2e3TQtEGM4Nk17C1WNV1H6qt1PSVwwoyf0mQ=.580a1790-6108-4ef7-9845-8087db9cf742@github.com>

On Fri, 16 May 2025 20:45:39 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The issue is the inability to move the mouse cursor using `java.awt.Robot` on Oracle Linux 10 (which has not yet been released). FIY, the OL10 is no longer provides an Xorg session, so only Wayland is available.
>> It is a JCK conformance failure. 
>> 
>> ---
>> 
>> In our robot implementation, we emulate mouse/keyboard actions using the XTEST extension protocol.
>> 
>> The XTEST calls are now wired to [libEI](https://libinput.pages.freedesktop.org/libei/api/index.html):
>> 
>> 1.
>> 
>> It now asks for a user confirmation to allow interaction, so we should now be able to click on native applications, window titles, etc.
>> 
>> However, our robot implementation is mostly uses XTEST, but there is an exception:
>> for mouse move we use XWarpPointer, which is not part of the XTEST, thus it is not propagated outside of Xwayland server.
>> 
>> So we have a situation where mouse is moving only inside Xwayland server, and we see the mouse enter/exit events,
>> on mouse press we call XTestFakeButtonEvent and it is handled by libei,
>> so the click happens where is the actual mouse cursor is in the system. That is why the test fails.
>> 
>> To avoid this situation we should use XTestFakeMotionEvent for mouseMove in Xwayland case.
>> 
>> It would be a simple solution, but
>> 
>> 
>> 2.
>> 
>> This permission granted by a user doesn't persist across reboots, it timeouts after a period of inactivity.
>> 
>> It still seems to conform to the specifications, but we will not be able to conveniently run automated tests in this case.
>> 
>> ---
>> 
>> So as a solution we can switch the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
>> It has session and `restore_token` functionality to keep permissions granted by a user, similar to what we use in a [Screencast](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html) for taking screenshots.
>> Most of the code can be reused, and it has everything we need.
>> 
>> 
>> * It is only enabled by default on Wayland and Gnome Shell 47 and higher due to XTEST API complications that first arose in this version. For earlier versions, Screencast is used instead.
>> * A new value has been introduced for the `awt.robot.screenshotMethod` system property - `dbusRemoteDesktop`. It works on Ubuntu 24.04 with Gnome 46, but is not enabled by default.
>> * extra mouse buttons are not supported yet, [JDK-8357142](https://bugs.openjdk.org/browse/JDK-8357142)
>> * Since w...
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only call getGnomeShellMajorVersion when the desktop is Gnome.

Phil discovered a hang on Fedora 42, it happens when we call:

1. mouseMove 
2. createScreenCapture withing the same remote desktop session

We got the following error if:
- the remote desktop session [initialized without the OpenPipeWireRemote call](https://github.com/azvegint/jdk/blob/5d08133ed00c6f22b71ffe6349591e11ea2813ed/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L1131-L1135)
- reusing this session and trying to use pipewire

> startStream:471 screenId#65: stream connecting 0x7f026c84d0f0
onStreamStateChanged:417 screenId#65[loc(0,0) size(1280x832)] state 0 (unconnected) -> 1 (connecting) err (null)
onCoreError:614 !!! pipewire error: id 0, seq: 0, res: -88 (Unknown error -88): connection error

Although it didn't hang on other systems, but it still printed this error in debug mode. It worked because of [the retry](https://github.com/azvegint/jdk/blob/5d08133ed00c6f22b71ffe6349591e11ea2813ed/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L1034).

Fortunately, it hangs on Fedora 42.

Removing this "optimization" resolves the issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/25265#issuecomment-2892471853

From serb at openjdk.org  Mon May 19 23:06:39 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 23:06:39 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v2]
In-Reply-To: <XyHPBRWF4NFCV_-QI8Jf_ctiVCLY2PMPGM2-E_DoPRM=.f7461854-264a-422c-81e1-d35cda43f303@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <XRQDe9qB8vtFFeCAbMRxRr5lB4vBCaFCAkDc9autvRc=.597810e7-8ce4-4879-bcf6-a4739273ccdf@github.com>
 <olpdq-aMj48h6bbL-WxYpJY-8iWjre32YpzZo87V68s=.b2330798-fb88-4662-9879-e9c5b9a1f8d7@github.com>
 <XyHPBRWF4NFCV_-QI8Jf_ctiVCLY2PMPGM2-E_DoPRM=.f7461854-264a-422c-81e1-d35cda43f303@github.com>
Message-ID: <ovY_Iizjy6fx8bfvn2J1tI5QWihqFj2tW9mXwL36KRw=.6a7d5ce2-8958-4e64-a77a-c9f6cdfd821e@github.com>

On Mon, 19 May 2025 06:17:27 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> I'm not sure if it's really needed, since many tests already depend on the `java.awt.Robot` itself, CI has a one-time manual task to set up all the required permissions for the `java.awt.Robot`, so automated tests provide sufficient coverage.

Can this be documented in [GUI testing](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements)?

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

PR Comment: https://git.openjdk.org/jdk/pull/25265#issuecomment-2892474018

From serb at openjdk.org  Mon May 19 23:47:59 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 23:47:59 GMT
Subject: Integrated: 8355078: java.awt.Color.createContext() uses unnecessary
 synchronization
In-Reply-To: <0pWUD-E-stDoqVTXFmlRNJ2skEMIjeto6VFl6ydxyc0=.de5400a3-69a2-4621-a91a-45bdfbca4dd2@github.com>
References: <0pWUD-E-stDoqVTXFmlRNJ2skEMIjeto6VFl6ydxyc0=.de5400a3-69a2-4621-a91a-45bdfbca4dd2@github.com>
Message-ID: <zt5dfhKZoB4jtGUMe8xTK39RbF0ULPkDkthyGiAR9q8=.dbc57a59-94c1-48a2-84f0-0dbf9996cdbf@github.com>

On Sun, 20 Apr 2025 08:15:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> At some point, java.awt.Color.createContext() was marked as synchronized to support caching of a ColorPaintContext instance. The cache was later removed, but the synchronized modifier remained. Since there is no shared mutable state anymore, the synchronization is no longer necessary and can be safely removed.
> 
> 
> Note: This code path is rarely executed because a special optimization was introduced in [SunGraphics2D.setPaint](https://github.com/openjdk/jdk/blob/c514f135ccf08c3be016a32ae8f2c055fb941857/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1003). As a result, unless a custom wrapper around the Color class is used, the Color.createContext() method is typically bypassed during rendering. 
> 
> Two tests are added:
>  - ColorPaintContextBasicTest: Checks if different image types (BufferedImage and VolatileImage) produce the same results when using different ways to fill the image (setColor, setPaint, and custom Paint). This test intentionally uses a custom Paint implementation to bypass the optimization and ensure that Color.createContext() is invoked verifying its correct behavior.
> - ColorPaintContextStateTrackerTest: Checks that the raster used in ColorPaintContext.getRaster() can be properly cached in video memory and we do not need to call icr.markDirty() in ColorPaintContext.getRaster()

This pull request has now been integrated.

Changeset: 890456f0
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/890456f0f78cc37c72b438a50ddf2605e1dfd91b
Stats:     304 lines in 4 files changed: 270 ins; 21 del; 13 mod

8355078: java.awt.Color.createContext() uses unnecessary synchronization

Reviewed-by: prr

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

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

From serb at openjdk.org  Tue May 20 00:11:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 20 May 2025 00:11:51 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog()
In-Reply-To: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
Message-ID: <gNPx88hYiWWKGjXt5zQNXudQ80RIfCXeGrEQpjbAmsg=.9341d26b-219a-483c-9dff-c047cf576f8b@github.com>

On Mon, 19 May 2025 06:06:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
> Fixed by setting the divider location before rendering the left and right components..

test/jdk/javax/swing/JSplitPane/TestSplitPaneResetDividerLoc.java line 71:

> 69:                 point = openDialogButton.getLocationOnScreen();
> 70:             });
> 71:             robot.mouseMove(point.x, point.y);

When I run the test on my macOS laptop, it fails because the click occured on the window border instead of the button. It would be good to slightly shift the click position to ensure it reliably hits the button across platforms.

btw it is better to use EventQueue.invokeAndWait instead of SwingUtilities.invokeAndWait. The latter was added early on, while the former consolidates all event-dispatching utilities in one class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25294#discussion_r2096631099

From serb at openjdk.org  Tue May 20 00:11:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 20 May 2025 00:11:51 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog()
In-Reply-To: <gNPx88hYiWWKGjXt5zQNXudQ80RIfCXeGrEQpjbAmsg=.9341d26b-219a-483c-9dff-c047cf576f8b@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <gNPx88hYiWWKGjXt5zQNXudQ80RIfCXeGrEQpjbAmsg=.9341d26b-219a-483c-9dff-c047cf576f8b@github.com>
Message-ID: <hpDot1b0aYxHL90Zm3kVzxjOQkyKFp-AAxdxXvcYJxs=.3c1be996-224c-440d-9c67-c033add22a1f@github.com>

On Tue, 20 May 2025 00:08:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
>> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
>> Fixed by setting the divider location before rendering the left and right components..
>
> test/jdk/javax/swing/JSplitPane/TestSplitPaneResetDividerLoc.java line 71:
> 
>> 69:                 point = openDialogButton.getLocationOnScreen();
>> 70:             });
>> 71:             robot.mouseMove(point.x, point.y);
> 
> When I run the test on my macOS laptop, it fails because the click occured on the window border instead of the button. It would be good to slightly shift the click position to ensure it reliably hits the button across platforms.
> 
> btw it is better to use EventQueue.invokeAndWait instead of SwingUtilities.invokeAndWait. The latter was added early on, while the former consolidates all event-dispatching utilities in one class.

maybe we can loop over installed L&F?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25294#discussion_r2096631567

From honkar at openjdk.org  Tue May 20 01:10:52 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 20 May 2025 01:10:52 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v3]
In-Reply-To: <q-jAcupHO9xmaafZinbFmnYuoYs4fzHMAjiNtfldNx4=.8e1fb82b-a181-4610-9557-8c5be252e58e@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <q-jAcupHO9xmaafZinbFmnYuoYs4fzHMAjiNtfldNx4=.8e1fb82b-a181-4610-9557-8c5be252e58e@github.com>
Message-ID: <_eAwlEaVObxYp4H1oWrT9EMiPBmKbL96TsBSG2ddoRc=.6b4bda2b-a914-4266-bd2d-fa1956f2122a@github.com>

On Mon, 19 May 2025 23:06:39 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The issue is the inability to move the mouse cursor using `java.awt.Robot` on Oracle Linux 10 (which has not yet been released). FIY, the OL10 is no longer provides an Xorg session, so only Wayland is available.
>> It is a JCK conformance failure. 
>> 
>> ---
>> 
>> In our robot implementation, we emulate mouse/keyboard actions using the XTEST extension protocol.
>> 
>> The XTEST calls are now wired to [libEI](https://libinput.pages.freedesktop.org/libei/api/index.html):
>> 
>> 1.
>> 
>> It now asks for a user confirmation to allow interaction, so we should now be able to click on native applications, window titles, etc.
>> 
>> However, our robot implementation is mostly uses XTEST, but there is an exception:
>> for mouse move we use XWarpPointer, which is not part of the XTEST, thus it is not propagated outside of Xwayland server.
>> 
>> So we have a situation where mouse is moving only inside Xwayland server, and we see the mouse enter/exit events,
>> on mouse press we call XTestFakeButtonEvent and it is handled by libei,
>> so the click happens where is the actual mouse cursor is in the system. That is why the test fails.
>> 
>> To avoid this situation we should use XTestFakeMotionEvent for mouseMove in Xwayland case.
>> 
>> It would be a simple solution, but
>> 
>> 
>> 2.
>> 
>> This permission granted by a user doesn't persist across reboots, it timeouts after a period of inactivity.
>> 
>> It still seems to conform to the specifications, but we will not be able to conveniently run automated tests in this case.
>> 
>> ---
>> 
>> So as a solution we can switch the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
>> It has session and `restore_token` functionality to keep permissions granted by a user, similar to what we use in a [Screencast](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html) for taking screenshots.
>> Most of the code can be reused, and it has everything we need.
>> 
>> 
>> * It is only enabled by default on Wayland and Gnome Shell 47 and higher due to XTEST API complications that first arose in this version. For earlier versions, Screencast is used instead.
>> * A new value has been introduced for the `awt.robot.screenshotMethod` system property - `dbusRemoteDesktop`. It works on Ubuntu 24.04 with Gnome 46, but is not enabled by default.
>> * extra mouse buttons are not supported yet, [JDK-8357142](https://bugs.openjdk.org/browse/JDK-8357142)
>> * Since w...
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   call OpenPipeWireRemote even for remote desktop session calls

On Ubuntu 24.04 (Gnome 46) tested using default awt.robot.screenshotMethod(`dbusScreencast`) and by setting it to `dbusRemoteDesktop`, it works well in both cases, no regressions observed.

On Ubuntu25.04 (Gnome 48) the default -  dbusRemoteDesktop works well.

I haven't able to test the fix on OL10 yet.

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

PR Comment: https://git.openjdk.org/jdk/pull/25265#issuecomment-2892620300

From serb at openjdk.org  Tue May 20 02:00:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 20 May 2025 02:00:52 GMT
Subject: RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
Message-ID: <A4x1L9-wmenV3k7vDs_8VkQM9Px7uRWX8TTc1d5-dJE=.bfcd3b64-e2c0-4f88-80e9-239889738dea@github.com>

On Wed, 16 Apr 2025 15:07:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24692#pullrequestreview-2852324895

From serb at openjdk.org  Tue May 20 02:02:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 20 May 2025 02:02:51 GMT
Subject: RFR: 8357226: Remove unnecessary List.indexOf from
 RepaintManager.removeInvalidComponent
In-Reply-To: <DF8ukEr0pPYhRM8K5XbNHoQ1UBhMRzZcYuJn22HLfNg=.d9d22b75-f7e8-4489-8d84-37cc49adc8c0@github.com>
References: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
 <hJ4PgOPmUJ1My31QgqDK7GyuPrWJMaOAROtlck4Qm3s=.180f2862-9ac7-4738-9383-c3346cc715d6@github.com>
 <55SDjO2Fj4yDEsB7Zbe3YacApuZZ5C-8x8VRO8aREJs=.3e97052f-7bd7-4dc2-83b2-4f4ecbe3bc47@github.com>
 <BrAi6AEmVtlbCx37n70y4EuMZTXPgmQeox3h7rV5MdU=.a5166f6f-4455-4c60-8f2b-7b3721f5bbe1@github.com>
 <Cn3HZ3h1_q92LZiyEuioSfYl9dINZCbpu82JRqABtbo=.abb78b6c-bffd-4f97-8986-fffd4281ddd0@github.com>
 <YDBfmXXO0wJyQq4ifNA0YoQiUcECNgSbLiO5bbBXxec=.a1b110ed-08da-4ca3-aeb4-9f17c3fcaeb2@github.com>
 <DF8ukEr0pPYhRM8K5XbNHoQ1UBhMRzZcYuJn22HLfNg=.d9d22b75-f7e8-4489-8d84-37cc49adc8c0@github.com>
Message-ID: <7_E9lw5GWsglpDpKuOSrzGfg-TWZl5sJkwLoZOr9Ieg=.13505891-52f1-4eef-8a6d-8e45dbbcd08b@github.com>

On Mon, 19 May 2025 12:35:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ok, then it is fine as is.
>
> Yet there could be a logical error anyway? `addInvalidComponent` uses identity comparison when adding a component but `removeInvalidComponent` relies on `equals` method to remove a component.
> 
> If a component overrides `equals`, it could lead to unpredictable behaviour: a wrong component could be removed.

Then it's better to use "==" in all cases, what do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24845#discussion_r2096713898

From abhiscxk at openjdk.org  Tue May 20 04:15:52 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 20 May 2025 04:15:52 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos
In-Reply-To: <4Uo7SgKZMLYdTumK8iQgnU4tM2GIDKBaL-tnUZl2atU=.1821a43d-d262-4218-aec2-e69f0956f587@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
 <4Uo7SgKZMLYdTumK8iQgnU4tM2GIDKBaL-tnUZl2atU=.1821a43d-d262-4218-aec2-e69f0956f587@github.com>
Message-ID: <xIm-Paz5Q5kp9yEvpoVH6R5BOguC5KP1Cim9oQqsyBY=.47a02680-597b-4e4b-b26d-42c75537fb7e@github.com>

On Mon, 19 May 2025 12:12:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
>> Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.
>> 
>> Verified the updated test in CI on macOS 14.7 machine and there is no failure.
>
> test/jdk/java/awt/List/ListEnterExitTest.java line 90:
> 
>> 88:             robot.waitForIdle();
>> 89:             robot.delay(100);
>> 90: 
> 
> I don't really understand why `waitForIdle` and `delay` are needed here at all.
> 
> Robot just moves mouse to generate mouse enter and exit events. It can do so without any delays, can't it?

There is an intermittent failure observed only on macOS 14.7.1 machines. So, I added a small delay and after that on multiple runs in CI, I don't see any failures.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2096870648

From abhiscxk at openjdk.org  Tue May 20 04:20:54 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 20 May 2025 04:20:54 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos
In-Reply-To: <xIm-Paz5Q5kp9yEvpoVH6R5BOguC5KP1Cim9oQqsyBY=.47a02680-597b-4e4b-b26d-42c75537fb7e@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
 <4Uo7SgKZMLYdTumK8iQgnU4tM2GIDKBaL-tnUZl2atU=.1821a43d-d262-4218-aec2-e69f0956f587@github.com>
 <xIm-Paz5Q5kp9yEvpoVH6R5BOguC5KP1Cim9oQqsyBY=.47a02680-597b-4e4b-b26d-42c75537fb7e@github.com>
Message-ID: <OgclHJDkUS7_ZL6TtHIMkNUba1kGqmRNi0sbvj1qfaI=.6bfa8976-2f32-4364-acff-7f9043abae31@github.com>

On Tue, 20 May 2025 04:12:59 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> test/jdk/java/awt/List/ListEnterExitTest.java line 90:
>> 
>>> 88:             robot.waitForIdle();
>>> 89:             robot.delay(100);
>>> 90: 
>> 
>> I don't really understand why `waitForIdle` and `delay` are needed here at all.
>> 
>> Robot just moves mouse to generate mouse enter and exit events. It can do so without any delays, can't it?
>
> There is an intermittent failure observed only on macOS 14.7.1 machines. So, I added a small delay and after that on multiple runs in CI, I don't see any failures.

There is an intermittent failure observed only on macOS 14.7.1 machines. So, I added a small delay and after that on multiple runs in CI, I don't see any failures.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2096877644

From psadhukhan at openjdk.org  Tue May 20 04:34:36 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 20 May 2025 04:34:36 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v2]
In-Reply-To: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
Message-ID: <dEc4B--MJdbczbZaAooTdznvOgwL-xMcBh6VCaMj-Hg=.6b121ad8-79c6-4b45-b529-e989477bf208@github.com>

> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
> Fixed by setting the divider location before rendering the left and right components..

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

  Click position fixed..L&F iteration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25294/files
  - new: https://git.openjdk.org/jdk/pull/25294/files/25482e5c..d1671bdd

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

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

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

From psadhukhan at openjdk.org  Tue May 20 05:01:54 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 20 May 2025 05:01:54 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v2]
In-Reply-To: <hpDot1b0aYxHL90Zm3kVzxjOQkyKFp-AAxdxXvcYJxs=.3c1be996-224c-440d-9c67-c033add22a1f@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <gNPx88hYiWWKGjXt5zQNXudQ80RIfCXeGrEQpjbAmsg=.9341d26b-219a-483c-9dff-c047cf576f8b@github.com>
 <hpDot1b0aYxHL90Zm3kVzxjOQkyKFp-AAxdxXvcYJxs=.3c1be996-224c-440d-9c67-c033add22a1f@github.com>
Message-ID: <kHazzUKSEODX428oFpgBT-Rs7sgb0X0XDpOGns1Q6QA=.ad9d2e36-df11-480a-870a-1dc78255cccb@github.com>

On Tue, 20 May 2025 00:08:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> test/jdk/javax/swing/JSplitPane/TestSplitPaneResetDividerLoc.java line 71:
>> 
>>> 69:                 point = openDialogButton.getLocationOnScreen();
>>> 70:             });
>>> 71:             robot.mouseMove(point.x, point.y);
>> 
>> When I run the test on my macOS laptop, it fails because the click occured on the window border instead of the button. It would be good to slightly shift the click position to ensure it reliably hits the button across platforms.
>> 
>> btw it is better to use EventQueue.invokeAndWait instead of SwingUtilities.invokeAndWait. The latter was added early on, while the former consolidates all event-dispatching utilities in one class.
>
> maybe we can loop over installed L&F?

click position fixed......L&F iterated.....

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25294#discussion_r2096924822

From abhiscxk at openjdk.org  Tue May 20 07:08:08 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 20 May 2025 07:08:08 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v2]
In-Reply-To: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
Message-ID: <zNzKToPOgYNhfMp4oiAWIk4tYycVmsmwuJTDF693igo=.ef4e98cd-c15e-4753-9790-28796260ac31@github.com>

> Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
> Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.
> 
> Verified the updated test in CI on macOS 14.7 machine and there is no failure.

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

  Review comment fix, latch and other changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25299/files
  - new: https://git.openjdk.org/jdk/pull/25299/files/1f4d5e82..f7e1c2c3

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

  Stats: 54 lines in 1 file changed: 14 ins; 26 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25299.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25299/head:pull/25299

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

From mvs at openjdk.org  Tue May 20 07:37:26 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 20 May 2025 07:37:26 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java
Message-ID: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>

There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.

Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().

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

Commit messages:
 - 8357305: Compilation failure in javax/swing/JMenuItem/bug6197830.java

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

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

From abhiscxk at openjdk.org  Tue May 20 07:53:30 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 20 May 2025 07:53:30 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v3]
In-Reply-To: <4Uo7SgKZMLYdTumK8iQgnU4tM2GIDKBaL-tnUZl2atU=.1821a43d-d262-4218-aec2-e69f0956f587@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
 <4Uo7SgKZMLYdTumK8iQgnU4tM2GIDKBaL-tnUZl2atU=.1821a43d-d262-4218-aec2-e69f0956f587@github.com>
Message-ID: <3VPaWmqWO0DbnJkCHiARXQj8Kd1-IHP8CgrjZVh59yk=.39272ac6-ee13-4b77-a4f5-9afa134f7b7b@github.com>

On Mon, 19 May 2025 12:16:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - File merge
>>  - Review comment fix, latch and other changes
>>  - Test Stabilization
>
> test/jdk/java/awt/List/ListEnterExitTest.java line 1:
> 
>> 1: /*
> 
> I strongly suggest making `MouseEnterExitListener` a static nested class inside `ListEnterExitTest`. This prevents any duplicate class names from other classes when one works with tests in an IDE.

Updated.

> test/jdk/java/awt/List/ListEnterExitTest.java line 92:
> 
>> 90: 
>> 91:             robot.mousePress(InputEvent.BUTTON1_MASK);
>> 92:             robot.mouseRelease(InputEvent.BUTTON1_MASK);
> 
> Is this mouse press needed only to release `mouseEnterExitListener.wait`?
> 
> I suggest using a `CountDownLatch` to replace `MouseEnterExitListener.passed_1` and `passed_2`. The code would need to time-await for both latches to be released.
> 
> Then `MouseEnterExitListener.mousePressed` can be removed completely together with the synchronized block above.

Updated with CountDownlatch to track mouse enter and exit events.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2097240158
PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2097239878

From abhiscxk at openjdk.org  Tue May 20 07:53:30 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 20 May 2025 07:53:30 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v3]
In-Reply-To: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
Message-ID: <hxqp5b9_-Ok5rUQcGmmjO9tfksC-ID0bnc_fGgkCUb4=.aa648c7b-9535-4359-9a96-67cdcef425ba@github.com>

> Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
> Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.
> 
> Verified the updated test in CI on macOS 14.7 machine and there is no failure.

Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - File merge
 - Review comment fix, latch and other changes
 - Test Stabilization

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

Changes: https://git.openjdk.org/jdk/pull/25299/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25299&range=02
  Stats: 61 lines in 1 file changed: 20 ins; 25 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25299.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25299/head:pull/25299

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

From aivanov at openjdk.org  Tue May 20 10:18:04 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 10:18:04 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java
In-Reply-To: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
Message-ID: <SPP1eUvW35HYDQWsbIC7ui8Ezqxvmhi9ghYUQNfWjKY=.f13eb390-0229-4cb0-9d90-a2bf72312c39@github.com>

On Tue, 20 May 2025 07:32:41 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
> 
> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().

I see that `MenuItemTest` class exists in `bug4729669.java`:

https://github.com/openjdk/jdk/blob/e961b13cd68bc352b86af17c7e53df8537519beb/test/jdk/javax/swing/JMenuItem/bug4729669.java#L80

Is it similar to the one that you copied?

If that `MenuItemTest` class is identical, I suggest moving both tests into a subdirectory and promoting `MenuItemTest` into a public class in that subdirectory which is located in its own `.java` file.

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

PR Comment: https://git.openjdk.org/jdk/pull/25319#issuecomment-2893798782

From azvegint at openjdk.org  Tue May 20 10:35:50 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 20 May 2025 10:35:50 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v2]
In-Reply-To: <ovY_Iizjy6fx8bfvn2J1tI5QWihqFj2tW9mXwL36KRw=.6a7d5ce2-8958-4e64-a77a-c9f6cdfd821e@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <XRQDe9qB8vtFFeCAbMRxRr5lB4vBCaFCAkDc9autvRc=.597810e7-8ce4-4879-bcf6-a4739273ccdf@github.com>
 <olpdq-aMj48h6bbL-WxYpJY-8iWjre32YpzZo87V68s=.b2330798-fb88-4662-9879-e9c5b9a1f8d7@github.com>
 <XyHPBRWF4NFCV_-QI8Jf_ctiVCLY2PMPGM2-E_DoPRM=.f7461854-264a-422c-81e1-d35cda43f303@github.com>
 <ovY_Iizjy6fx8bfvn2J1tI5QWihqFj2tW9mXwL36KRw=.6a7d5ce2-8958-4e64-a77a-c9f6cdfd821e@github.com>
Message-ID: <P5zqV_ciVE8ik4glssalJ2bil6zA5k1BI2sTXsR13GU=.716dd834-2d6b-4344-aade-8ec9eec91abf@github.com>

On Mon, 19 May 2025 23:02:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I'm not sure if it's really needed, since many tests already depend on the `java.awt.Robot` itself, CI has a one-time manual task to set up all the required permissions for the `java.awt.Robot`, so automated tests provide sufficient coverage.
> 
> Can this be documented in [GUI testing](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements)?

Sure, [updated](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements#AutomatedclientGUItestingsystemsetuprequirements-Wayland).

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

PR Comment: https://git.openjdk.org/jdk/pull/25265#issuecomment-2893849751

From jdv at openjdk.org  Tue May 20 11:19:58 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 20 May 2025 11:19:58 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine [v3]
In-Reply-To: <c2FRmUEOKhK0i4Mm1dHqdCyu5aCY6cMGE-xQFzSujmQ=.9a13234c-e073-4c12-946f-0d7d77d5f190@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
 <c2FRmUEOKhK0i4Mm1dHqdCyu5aCY6cMGE-xQFzSujmQ=.9a13234c-e073-4c12-946f-0d7d77d5f190@github.com>
Message-ID: <h6uPRYX8jsYlzHlBx8rfCEXDyX_cCuSH_nSyW5oDk2E=.77b0c49f-8475-4307-b27e-4f2df3f5b4d5@github.com>

On Mon, 19 May 2025 05:37:05 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Unfortunately I'm unable to reproduce this failure. I slowed the test down; it passes on my machine before and after this PR.
>> 
>> I added a little bit of logging that might also help identify what's happening.
>> 
>> Does anyone have any more suggestions?
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356061: removing robot
>   
>   This is in response to:
>   https://github.com/openjdk/jdk/pull/25244#issuecomment-2889420453

I think the original issue of getting same RGB color for both default and non-default button is happening because when we move mouse pointer to a location and pick the color from the same location using robot, sometimes it picks the color of mouse pointer and not UI component(this issue is observed only in macOS aarch64 machines).

Since we have completely removed usage of robot in this test case, we should not see same color for default and non-default buttons anymore. LGTM.

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

Marked as reviewed by jdv (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25244#pullrequestreview-2853766216

From mvs at openjdk.org  Tue May 20 11:33:51 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 20 May 2025 11:33:51 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java
In-Reply-To: <SPP1eUvW35HYDQWsbIC7ui8Ezqxvmhi9ghYUQNfWjKY=.f13eb390-0229-4cb0-9d90-a2bf72312c39@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <SPP1eUvW35HYDQWsbIC7ui8Ezqxvmhi9ghYUQNfWjKY=.f13eb390-0229-4cb0-9d90-a2bf72312c39@github.com>
Message-ID: <On9eQexCD_yxL1YYlQeAwFknK0ULEu0Xrxy3tfmTO2A=.f2596000-29da-404a-a2bd-a0917bea8790@github.com>

On Tue, 20 May 2025 10:15:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I see that `MenuItemTest` class exists in `bug4729669.java`:
> 
> https://github.com/openjdk/jdk/blob/e961b13cd68bc352b86af17c7e53df8537519beb/test/jdk/javax/swing/JMenuItem/bug4729669.java#L80
> 
> Is it similar to the one that you copied?
> 
> If that `MenuItemTest` class is identical, I suggest moving both tests into a subdirectory and promoting `MenuItemTest` into a public class in that subdirectory which is located in its own `.java` file.

No, these are no exactly the same, the doMenuItemTest(boolean isLeft) method in bug4729669.java has only one parameter, but the doMenuItemTest(boolean isLeft, String lafName, int frameY) method has three parameters in bug6197830.java.

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

PR Comment: https://git.openjdk.org/jdk/pull/25319#issuecomment-2894001580

From aivanov at openjdk.org  Tue May 20 11:55:51 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 11:55:51 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java
In-Reply-To: <On9eQexCD_yxL1YYlQeAwFknK0ULEu0Xrxy3tfmTO2A=.f2596000-29da-404a-a2bd-a0917bea8790@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <SPP1eUvW35HYDQWsbIC7ui8Ezqxvmhi9ghYUQNfWjKY=.f13eb390-0229-4cb0-9d90-a2bf72312c39@github.com>
 <On9eQexCD_yxL1YYlQeAwFknK0ULEu0Xrxy3tfmTO2A=.f2596000-29da-404a-a2bd-a0917bea8790@github.com>
Message-ID: <PV4E3w1JPSc6poXySwiZaZHadeznZpwF0lwSSBaztM4=.a2321566-a0aa-47f7-a03e-9ba79fc5629d@github.com>

On Tue, 20 May 2025 11:31:01 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> > I see that `MenuItemTest` class exists in `bug4729669.java`:
> > https://github.com/openjdk/jdk/blob/e961b13cd68bc352b86af17c7e53df8537519beb/test/jdk/javax/swing/JMenuItem/bug4729669.java#L80
> > 
> > Is it similar to the one that you copied?
> > If that `MenuItemTest` class is identical, I suggest moving both tests into a subdirectory and promoting `MenuItemTest` into a public class in that subdirectory which is located in its own `.java` file.
> 
> No, these are no exactly the same, the doMenuItemTest(boolean isLeft) method in bug4729669.java has only one parameter, but the doMenuItemTest(boolean isLeft, String lafName, int frameY) method has three parameters in bug6197830.java.

Can they be merged together?

If possible, I'd like to eliminate code duplication and extract common code.

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

PR Comment: https://git.openjdk.org/jdk/pull/25319#issuecomment-2894100567

From aivanov at openjdk.org  Tue May 20 12:05:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 12:05:53 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java
In-Reply-To: <PV4E3w1JPSc6poXySwiZaZHadeznZpwF0lwSSBaztM4=.a2321566-a0aa-47f7-a03e-9ba79fc5629d@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <SPP1eUvW35HYDQWsbIC7ui8Ezqxvmhi9ghYUQNfWjKY=.f13eb390-0229-4cb0-9d90-a2bf72312c39@github.com>
 <On9eQexCD_yxL1YYlQeAwFknK0ULEu0Xrxy3tfmTO2A=.f2596000-29da-404a-a2bd-a0917bea8790@github.com>
 <PV4E3w1JPSc6poXySwiZaZHadeznZpwF0lwSSBaztM4=.a2321566-a0aa-47f7-a03e-9ba79fc5629d@github.com>
Message-ID: <N2z5RMjIFIjDYKRP4bZdt9z4wAA6nJv7Um3zkt4ZkZg=.8a332ad1-3dd9-4656-9b8d-1c6bf33f42ec@github.com>

On Tue, 20 May 2025 11:52:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > I see that `MenuItemTest` class exists in `bug4729669.java`:
> > > https://github.com/openjdk/jdk/blob/e961b13cd68bc352b86af17c7e53df8537519beb/test/jdk/javax/swing/JMenuItem/bug4729669.java#L80
> > > 
> > > Is it similar to the one that you copied?
> > > If that `MenuItemTest` class is identical, I suggest moving both tests into a subdirectory and promoting `MenuItemTest` into a public class in that subdirectory which is located in its own `.java` file.
> > 
> > 
> > No, these are no exactly the same, the doMenuItemTest(boolean isLeft) method in bug4729669.java has only one parameter, but the doMenuItemTest(boolean isLeft, String lafName, int frameY) method has three parameters in bug6197830.java.
> 
> Can they be merged together?
> 
> If possible, I'd like to eliminate code duplication and extract common code.

The only difference is the Look-and-Feel parameter, which can be abstracted by pulling out common code.

Then `frameY` is used to position the test frame. It's not needed if [`PassFailJFrame.Builder.positionTestUIBottomRowCentered`](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.Builder.html#positionTestUIBottomRowCentered()) or [`positionTestUIRightColumnCentered`](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.Builder.html#positionTestUIRightColumnCentered()) are used.

For the case where multiple L&Fs are tested, a custom layout could be implemented to position test windows in two columns and two rows, which is easy with [`WindowLayouts`](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/WindowLayouts.html).

Is Motif L&F still supported? I guess it is but it's deprecated.

https://github.com/openjdk/jdk/blob/ab985a7c5d313304e6d601571885dcb871967259/src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java#L51-L57

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

PR Comment: https://git.openjdk.org/jdk/pull/25319#issuecomment-2894154602

From mvs at openjdk.org  Tue May 20 12:09:00 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 20 May 2025 12:09:00 GMT
Subject: Integrated: 8355515: Clarify the purpose of forcePass() and
 forceFail() methods
In-Reply-To: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
References: <XALi_LXV4-kkzOw_-9KP6At6xl9bY7kyK__XYnW4mHE=.bb7ad6db-f2d2-4528-bd0d-bc3dfb310ae4@github.com>
Message-ID: <OW1A8QR72zGbSmTj2Q9S6wy6ecE6eYLp5olPNcOD4Y8=.5e709a9f-da3f-4e10-8fa3-b982ce5adb5a@github.com>

On Wed, 7 May 2025 12:28:52 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Clarified the purpose of forcePass() and forceFail() methods and recommended usage of these methods.
> 
> forcePass() contained an incorrect sample; it's addressed by [JDK-8355441](https://bugs.openjdk.org/browse/JDK-8355441).
> 
> The description of forceFail() has been expanded, too.
> 
> 
> A new section in the description of the PassFailJFrame added to describe forcePass() and forceFail().

This pull request has now been integrated.

Changeset: 1a97eb42
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a97eb429b520b7c4e625b97553c954d065c00cb
Stats:     33 lines in 1 file changed: 31 ins; 0 del; 2 mod

8355515: Clarify the purpose of forcePass() and forceFail() methods

Reviewed-by: aivanov, kizune

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

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

From mvs at openjdk.org  Tue May 20 12:10:51 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 20 May 2025 12:10:51 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java
In-Reply-To: <N2z5RMjIFIjDYKRP4bZdt9z4wAA6nJv7Um3zkt4ZkZg=.8a332ad1-3dd9-4656-9b8d-1c6bf33f42ec@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <SPP1eUvW35HYDQWsbIC7ui8Ezqxvmhi9ghYUQNfWjKY=.f13eb390-0229-4cb0-9d90-a2bf72312c39@github.com>
 <On9eQexCD_yxL1YYlQeAwFknK0ULEu0Xrxy3tfmTO2A=.f2596000-29da-404a-a2bd-a0917bea8790@github.com>
 <PV4E3w1JPSc6poXySwiZaZHadeznZpwF0lwSSBaztM4=.a2321566-a0aa-47f7-a03e-9ba79fc5629d@github.com>
 <N2z5RMjIFIjDYKRP4bZdt9z4wAA6nJv7Um3zkt4ZkZg=.8a332ad1-3dd9-4656-9b8d-1c6bf33f42ec@github.com>
Message-ID: <U_E6KpT8VzdENdgLY7wZnVhHe4rL29--1IrmngkriSk=.0c2a70ee-f984-49f4-b6f3-37b20c0e2241@github.com>

On Tue, 20 May 2025 12:03:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > I see that `MenuItemTest` class exists in `bug4729669.java`:
> > > https://github.com/openjdk/jdk/blob/e961b13cd68bc352b86af17c7e53df8537519beb/test/jdk/javax/swing/JMenuItem/bug4729669.java#L80
> > > 
> > > Is it similar to the one that you copied?
> > > If that `MenuItemTest` class is identical, I suggest moving both tests into a subdirectory and promoting `MenuItemTest` into a public class in that subdirectory which is located in its own `.java` file.
> > 
> > 
> > No, these are no exactly the same, the doMenuItemTest(boolean isLeft) method in bug4729669.java has only one parameter, but the doMenuItemTest(boolean isLeft, String lafName, int frameY) method has three parameters in bug6197830.java.
> 
> Can they be merged together?
> 
> If possible, I'd like to eliminate code duplication and extract common code.

Yes, I can try that.

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

PR Comment: https://git.openjdk.org/jdk/pull/25319#issuecomment-2894168382

From zzambers at openjdk.org  Tue May 20 14:21:58 2025
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Tue, 20 May 2025 14:21:58 GMT
Subject: RFR: 8343618: Stack smashing in awt_InputMethod.c on Linux s390x
In-Reply-To: <bQ6w0gWIgM4nzhRfaKzH8zGPmDZatws7RFN-wzcYbd4=.3ffaae38-ef06-4de4-bfb3-c3daa5c1b1ba@github.com>
References: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
 <5fiGZhiUeut1V4c4CAVraAsa4-Lv-B5z8Bvt19UK4X8=.72aa6db8-b7c7-40d7-9928-aa8ccf9567f9@github.com>
 <bQ6w0gWIgM4nzhRfaKzH8zGPmDZatws7RFN-wzcYbd4=.3ffaae38-ef06-4de4-bfb3-c3daa5c1b1ba@github.com>
Message-ID: <Cr31G3aYCkl-nWrCTqlgfbSqkGBVaEcwREHxRGMxyro=.c8bdf65a-b44a-44c4-9a50-021d6e67edd0@github.com>

On Fri, 16 May 2025 18:19:22 GMT, Phil Race <prr at openjdk.org> wrote:

> That looks right, and it should also be good for backports. The root cause must be a bug in Xlib, though. Has anyone found it, or reported it?

I have not identified the root cause. I think bug could also be in kinput2 or it's interaction with X11/Xlib (as scenario with kinput2 is problematic case as far as I understand).

Unfortunately this would be very difficult to debug for me, as I have no experience with input of Asian characters (kinput2) and RHEL (8) does not offer kinput2 package. In addition I can only do testing remotely on temporarily loaned s390x headless machine. So I do not plan to dig deeper into this myself and I rely on observations by @takiguc here.

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

PR Comment: https://git.openjdk.org/jdk/pull/24197#issuecomment-2894608187

From zzambers at openjdk.org  Tue May 20 14:42:57 2025
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Tue, 20 May 2025 14:42:57 GMT
Subject: RFR: 8343618: Stack smashing in awt_InputMethod.c on Linux s390x
In-Reply-To: <Cr31G3aYCkl-nWrCTqlgfbSqkGBVaEcwREHxRGMxyro=.c8bdf65a-b44a-44c4-9a50-021d6e67edd0@github.com>
References: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
 <5fiGZhiUeut1V4c4CAVraAsa4-Lv-B5z8Bvt19UK4X8=.72aa6db8-b7c7-40d7-9928-aa8ccf9567f9@github.com>
 <bQ6w0gWIgM4nzhRfaKzH8zGPmDZatws7RFN-wzcYbd4=.3ffaae38-ef06-4de4-bfb3-c3daa5c1b1ba@github.com>
 <Cr31G3aYCkl-nWrCTqlgfbSqkGBVaEcwREHxRGMxyro=.c8bdf65a-b44a-44c4-9a50-021d6e67edd0@github.com>
Message-ID: <BE-sj5FkKxnT887NmNI2Np8ie3B6UtP5e2n4d6Y345g=.3ce042b0-2b9c-4a26-92f4-6a12817914fe@github.com>

On Tue, 20 May 2025 14:18:06 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

>>> That looks right, and it should also be good for backports. The root cause must be a bug in Xlib, though. Has anyone found it, or reported it?
>> 
>> That was my thought too  : "Looks reasonable although it seems an odd behaviour (bug?) of XGetICValues"
>
>> That looks right, and it should also be good for backports. The root cause must be a bug in Xlib, though. Has anyone found it, or reported it?
> 
> I have not identified the root cause. I think bug could also be in kinput2 or it's interaction with X11/Xlib (as scenario with kinput2 is problematic case as far as I understand).
> 
> Unfortunately this would be very difficult to debug for me, as I have no experience with input of Asian characters (kinput2) and RHEL (8) does not offer kinput2 package. In addition I can only do testing remotely on temporarily loaned s390x headless machine. So I do not plan to dig deeper into this myself and I rely on observations by @takiguc here.

> @zzambers Sorry for my late reaction. Is it possible to add test result by using `XMODIFIERS=@im=local` ?

I have now also tested this scenario (fixed jdk + `XMODIFIERS=@im=local` + Xvfb):
- my reproducer -> ok (no crash)
- jdk_awt tests:

   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>> jtreg:test/jdk:jdk_awt                             2171  1218   260     6   687 <<

No crashes (stack smashing), even less failures (even though lot of changes in failures could probably be attributed to unstable tests... :/ )

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

PR Comment: https://git.openjdk.org/jdk/pull/24197#issuecomment-2894683771

From zzambers at openjdk.org  Tue May 20 14:45:57 2025
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Tue, 20 May 2025 14:45:57 GMT
Subject: RFR: 8343618: Stack smashing in awt_InputMethod.c on Linux s390x
In-Reply-To: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
References: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
Message-ID: <Xv7c8wFTZ1gvLw3X0XT4A-Zn0h7gfKq_VdPi278e1_E=.2f784b95-56d2-498a-9bf1-8e3060113af2@github.com>

On Mon, 24 Mar 2025 13:41:44 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> This fixes stack smashing issue in awt library on linux s390x. (jdk compiled with `-fstack-protector-strong`)
> 
> Fix is based on patch [submitted](https://mail.openjdk.org/pipermail/awt-dev/2019-July/015337.html) in JDK-8227919 review thread, rebased to master. They decided to go for Solaris only fix there, with [expected follow-up](https://mail.openjdk.org/pipermail/awt-dev/2019-July/015347.html) for linux/s390x. But that never happened.
> 
> I was not able to get response from original author for this issue, so I am creating PR myself.
> 
> **Testing:**
> I tested jdk with and without this fix on linux/s390x (using Xvfb). It fixes the issue (reproducer for this bug no longer crashes the JVM). I have also tried to run `jdk_awt` tests, where lot of tests was also affected by this. With this patch amount of failures dropped by ~100. 
> 
> Without fix:
> 
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/jdk:jdk_awt                             2171  1063   415     6   687 <<
> 
> 
> With fix
> 
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/jdk:jdk_awt                             2171  1162   316     6   687 <<
> 
> 
> Many tests are no longer crashing the VM:
> 
> -java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java                                                      Failed. Unexpected exit from test [exit code: 134]
> +java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java                                                      Passed. Execution successful
> 
> There seem to be few unstable tests in jdk_awt. (Ones that fail in one or another run, but seem unrelated to this fix)
> 
> I have not done any additional manual testing of XIM as did original author (in review thread mentioned higher), as I am not at all familiar with input method for Japanese (or other Asian characters), or how that supposed to work. (So I cannot verify that input of Asian characters works as expected on linux/s390x, but at least JVM no longer crashes.)

Attaching jdk_awt results with `XMODIFIERS=@im=local`:
[jdk-awt-results-im-local.tar.gz](https://github.com/user-attachments/files/20349889/jdk-awt-results-im-local.tar.gz)

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

PR Comment: https://git.openjdk.org/jdk/pull/24197#issuecomment-2894695574

From kizune at openjdk.org  Tue May 20 15:58:01 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 20 May 2025 15:58:01 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v3]
In-Reply-To: <hxqp5b9_-Ok5rUQcGmmjO9tfksC-ID0bnc_fGgkCUb4=.aa648c7b-9535-4359-9a96-67cdcef425ba@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
 <hxqp5b9_-Ok5rUQcGmmjO9tfksC-ID0bnc_fGgkCUb4=.aa648c7b-9535-4359-9a96-67cdcef425ba@github.com>
Message-ID: <LQyeJNLft0LR-ynxxQKrQ-oVQY8Hb7_Q9R-ygb_CwQc=.a39ee632-145b-4fb3-b094-5d9ae85a7f69@github.com>

On Tue, 20 May 2025 07:53:30 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
>> Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.
>> 
>> Verified the updated test in CI on macOS 14.7 machine and there is no failure.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - File merge
>  - Review comment fix, latch and other changes
>  - Test Stabilization

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25299#pullrequestreview-2854768458

From kizune at openjdk.org  Tue May 20 15:59:57 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 20 May 2025 15:59:57 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9 [v2]
In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
 <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
Message-ID: <5AbtaN3spDPIwctnzjsCh9jUGtqjx4A5SJB-_6ZZEPY=.7441f23a-794b-43e3-913c-934bf6db6543@github.com>

On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The following line results in unused-result warning on linux/clang.
>> 
>> 
>> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
>> 
>> 
>> There are two ways to handle it 
>> 
>> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
>> 
>> 
>> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html
>> 
>> 
>> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
>> 
>> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   DTRACE added

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25217#pullrequestreview-2854775307

From aivanov at openjdk.org  Tue May 20 16:04:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 16:04:55 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9 [v2]
In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
 <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
Message-ID: <QWHBHgzwX2-0QfyeM-MFoR8_7eo-XzqxboxZfmpL48Q=.1c478845-014e-425b-a885-f846cf1fd47b@github.com>

On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The following line results in unused-result warning on linux/clang.
>> 
>> 
>> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
>> 
>> 
>> There are two ways to handle it 
>> 
>> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
>> 
>> 
>> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html
>> 
>> 
>> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
>> 
>> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   DTRACE added

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c line 1:

> 1: /*

Bump the copyright year to 2025.

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

PR Review: https://git.openjdk.org/jdk/pull/25217#pullrequestreview-2854784582
PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2098346273

From mvs at openjdk.org  Tue May 20 16:18:48 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 20 May 2025 16:18:48 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v2]
In-Reply-To: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
Message-ID: <8raDo3FpSvhKD-OA21EHbKEYVEejYB4qtUipeGVNvJw=.b6f7a74f-392a-4541-82d1-b9301123f03b@github.com>

> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
> 
> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed : Rearranged and reused code by creating a new Helper MenuItemTestHelper.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25319/files
  - new: https://git.openjdk.org/jdk/pull/25319/files/adf3a94d..1f027147

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

  Stats: 710 lines in 5 files changed: 311 ins; 399 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25319/head:pull/25319

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

From aivanov at openjdk.org  Tue May 20 18:10:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 18:10:59 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v2]
In-Reply-To: <8raDo3FpSvhKD-OA21EHbKEYVEejYB4qtUipeGVNvJw=.b6f7a74f-392a-4541-82d1-b9301123f03b@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <8raDo3FpSvhKD-OA21EHbKEYVEejYB4qtUipeGVNvJw=.b6f7a74f-392a-4541-82d1-b9301123f03b@github.com>
Message-ID: <Up0J1fq1aI_x-78TvT1Zti9UuDg7viR6TOETEEfO3qQ=.fd4d6984-9f47-4280-a80c-b77653c1311c@github.com>

On Tue, 20 May 2025 16:18:48 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
>> 
>> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed : Rearranged and reused code by creating a new Helper MenuItemTestHelper.java

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 2:

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

I'd keep 2005 year as the start of the copyright ? it's not a brand new class, you just pulled it out of another class.

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 43:

> 41: import javax.swing.UIManager;
> 42: 
> 43: class MenuItemTestHelper {

I would've kept `MenuItemTest` as the name of the class. It's find either way.

I'd also mark this class as `final`. It may be `public` or be left with the default access.

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 53:

> 51:             } catch (Exception e) {
> 52:                 e.printStackTrace();
> 53:             }

I wonder if we should actually wrap the exception into `RuntimeException` and let it propagate to fail the test. I think we should; if Look and Feel wasn't set as expected, the test won't test that part of the functionality.

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 65:

> 63: 
> 64:             public int getIconWidth() { return 10; }
> 65:             public int getIconHeight() { return 10; }

I suggest keeping the multiline version of the methods, I find it easier to read. Let IDE collapse the code for you.

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 69:

> 67: 
> 68:         Icon myIcon2 = new Icon() {
> 69:             public void paintIcon(Component c, Graphics g, int x, int y) {

I'd add the `@Override` annotations to all the overridden methods.

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 74:

> 72:                 g.fillRect(x, y, 15, 10);
> 73:                 g.setColor(color);
> 74:             }

Perhaps, both `Icon` instances could even be refactored into its own class that accepts color, width and height.

However, this is close to over-engineering the test code?

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 85:

> 83:         menuBar.add(createSomeIconsMenu(myIcon, myIcon2));
> 84: 
> 85:         String title = "Menu Item Test " + (isLeft ? "(Left-to-right)" : "(Right-to-left)");

Suggestion:

        String title = (isLeft ? "(Left-to-right)" : "(Right-to-left)") + " - Menu Item Test";

I suggest flipping the title so that the most relevant part is always visible rather than truncated.

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 87:

> 85:         String title = "Menu Item Test " + (isLeft ? "(Left-to-right)" : "(Right-to-left)");
> 86:         JFrame frame = new JFrame(title);
> 87:         frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);

Closing the frame is handled by `PassFailJFrame`, so `setDefaultCloseOperation` is redundant.

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 89:

> 87:         frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
> 88:         frame.setJMenuBar(menuBar);
> 89:         frame.applyComponentOrientation(isLeft ? ComponentOrientation.LEFT_TO_RIGHT : ComponentOrientation.RIGHT_TO_LEFT);

Suggestion:

        frame.applyComponentOrientation(isLeft
                                        ? ComponentOrientation.LEFT_TO_RIGHT
                                        : ComponentOrientation.RIGHT_TO_LEFT);

This avoids a long line.

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 100:

> 98:         frame.setSize(300, 300);
> 99:         frame.setLocation(isLeft ? 0 : 600, frameY);
> 100:         frame.setVisible(true);

`setLocation` shouldn't be need if you use `PassFailJFrame` layouts for positioning. Then `frameY` becomes redundant.

`setVisible(true)` isn't need either.

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 120:

> 118: 
> 119:         JRadioButtonMenuItem rm2 = new JRadioButtonMenuItem("And icon.");
> 120:         rm2.setAccelerator(KeyStroke.getKeyStroke(KeyEvent.VK_F1, KeyEvent.SHIFT_MASK));

Suggestion:

        rm2.setAccelerator(KeyStroke.getKeyStroke(KeyEvent.VK_F1, KeyEvent.SHIFT_DOWN_MASK));

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 139:

> 137: 
> 138:     private static JMenu createNoNothingMenu() {
> 139:         final JMenu menu2 = new JMenu("No nothing");

Suggestion:

        final JMenu noMenu = new JMenu("No nothing");

I'd rename it to `noMenu` to represent `NoNothing` from the method name. Otherwise, it can be just `menu`, there's no other `menu` in scope any more.

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 148:

> 146:                     PassFailJFrame.log("menu.width = " + width);
> 147:                 }
> 148:             });

Suggestion:

            item.addActionListener((e) ->
                    PassFailJFrame.log("menu.width = "
                                       + menu2.getPopupMenu().getWidth()));

Let's be concise.

test/jdk/javax/swing/JMenuItem/MenuItemTest/bug4729669.java line 49:

> 47:                 .columns(35)
> 48:                 .testUI(bug4729669::createTestUI)
> 49:                 .position(PassFailJFrame.Position.TOP_LEFT_CORNER)

Suggestion:

                .positionTestUIRightColumn()

test/jdk/javax/swing/JMenuItem/MenuItemTest/bug6197830.java line 46:

> 44: 
> 45:     public static void main(String[] args) throws Exception {
> 46:         PassFailJFrame.builder()

Use `.positionTestUIBottomRowCentered()`, it works perfectly well.

Then remove all the `.setLocation` calls from `createTestUI`.

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

PR Review: https://git.openjdk.org/jdk/pull/25319#pullrequestreview-2854867797
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098398095
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098469033
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098479317
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098411293
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098429701
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098416620
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098533147
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098431170
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098545578
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098445060
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098588166
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098549320
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098543901
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098443874
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098560543

From aivanov at openjdk.org  Tue May 20 18:11:00 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 18:11:00 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v2]
In-Reply-To: <Up0J1fq1aI_x-78TvT1Zti9UuDg7viR6TOETEEfO3qQ=.fd4d6984-9f47-4280-a80c-b77653c1311c@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <8raDo3FpSvhKD-OA21EHbKEYVEejYB4qtUipeGVNvJw=.b6f7a74f-392a-4541-82d1-b9301123f03b@github.com>
 <Up0J1fq1aI_x-78TvT1Zti9UuDg7viR6TOETEEfO3qQ=.fd4d6984-9f47-4280-a80c-b77653c1311c@github.com>
Message-ID: <jz3lkJrekTKGtPkoZQ-ta-z1NpSURQgnrJZJPKD0mVw=.878f513d-3f1e-4a9b-a857-37dbaf36ee4c@github.com>

On Tue, 20 May 2025 16:33:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fixed : Rearranged and reused code by creating a new Helper MenuItemTestHelper.java
>
> test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 74:
> 
>> 72:                 g.fillRect(x, y, 15, 10);
>> 73:                 g.setColor(color);
>> 74:             }
> 
> Perhaps, both `Icon` instances could even be refactored into its own class that accepts color, width and height.
> 
> However, this is close to over-engineering the test code?

Anyway, it makes the code cleaner:


    private static final class ColoredIcon implements Icon {
        private final Color color;
        private final int width;
        private final int height;

        private ColoredIcon(Color color, int width, int height) {
            this.color = color;
            this.width = width;
            this.height = height;
        }

        @Override
        public void paintIcon(Component c, Graphics g, int x, int y) {
            Color oldColor = g.getColor();
            g.setColor(color);
            g.fillRect(x, y, width, height);
            g.setColor(oldColor);
        }

        @Override
        public int getIconWidth() {
            return width;
        }

        @Override
        public int getIconHeight() {
            return height;
        }
    }


It may be a record, yet using a class will make backporting to previous versions easier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098585654

From mvs at openjdk.org  Tue May 20 18:34:28 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 20 May 2025 18:34:28 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v3]
In-Reply-To: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
Message-ID: <Dd8HDFTgh9IUbl48-2wNTXn2I4vKIfEJGm9Q2hN3YiQ=.1c6295b9-3fea-4907-a316-fe06dfcaccf1@github.com>

> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
> 
> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed : Formatting changes,copyright,cosmetic changes,etc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25319/files
  - new: https://git.openjdk.org/jdk/pull/25319/files/1f027147..098ea0de

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

  Stats: 69 lines in 2 files changed: 22 ins; 35 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/25319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25319/head:pull/25319

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

From aivanov at openjdk.org  Tue May 20 18:52:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 18:52:55 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v3]
In-Reply-To: <JVyEYDeaC2nRhod516RnecC9xDNUAlJXt0yz4I5xgvo=.a64851ce-c2f6-4e9d-bbdc-d6ad36626f56@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <JVyEYDeaC2nRhod516RnecC9xDNUAlJXt0yz4I5xgvo=.a64851ce-c2f6-4e9d-bbdc-d6ad36626f56@github.com>
Message-ID: <8icaCzTbIOcszrNmqCYdzqI4telSGl3bM-9afdXEWbE=.7c5be52b-eb9e-41e0-b655-5148f135d72c@github.com>

On Mon, 19 May 2025 13:52:16 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The rendering of the directory names are handled as JLabel w.r.t Look and feel and also either Details/List view. Though FilePane creates basic rendering for these two few Look and Feel define their own renderers and also ComboBox Directory directory name view. Since HTML filtering is not taken care in any of these renderers, JLabel renders them as HTML document if nothing is set or specified.
>> The fix is to get "html.disable" property from JFileChooser and set the same to JLabel component which renders and set Directory name. Hence applications can either enable/disable this property and control HTML rendering of directory name.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 29:

> 27: import javax.swing.filechooser.FileSystemView;
> 28: import java.io.File;
> 29: import java.util.List;

Suggestion:

import java.io.File;
import java.util.List;
import javax.swing.Icon;
import javax.swing.JFileChooser;
import javax.swing.JFrame;
import javax.swing.filechooser.FileSystemView;

We haven't reached an agreement, yet `java.*` packages usually go before `javax.*` packages in the list of imports.

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 45:

> 43:         String INSTRUCTIONS = """
> 44:                 1. FileChooser shows up a virtual directory and file with name
> 45:                    "<html><h1 color=#ff00ff><font face="Comic Sans MS">Testing Name".

The file name is now `Swing Rocks!`

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 51:

> 49:                          ComboBox remains in plain text, then test PASS.
> 50:                          If it appears to be in HTML format with Pink color,
> 51:                          then test FAILS.

Suggestion:

                         ComboBox remains in plain text, then test passes.
                         If it appears to be in HTML format with Pink color,
                         then test fails.

You could be more specific: _?click **Fail**?_ if a condition isn't met. (Otherwise, continue with the test.) End the instructions with _?click **Pass**?_.

Anyway, the instructions are pretty clear as they are, so real change is required.

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 59:

> 57:                          ComboBox remains in HTML format string, then test PASS.
> 58:                          If it appears to be in plain text, then test FAILS.
> 59:                          (Verify for all Look and Feel).

How do I verify for all Look and Feels?

The test has to iterate over all L&F, and repeat the same thing for each L&F.

Ideally, it should be an automated test. However, I'm fine with postponing any efforts to automate the test but I'd like to try to automate it.

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 60:

> 58:                          If it appears to be in plain text, then test FAILS.
> 59:                          (Verify for all Look and Feel).
> 60:                  """;

Suggestion:

                """;

Avoid trailing space, it's not needed.

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 85:

> 83:         frame.pack();
> 84:         return frame;
> 85:     }

Suggestion:

    private static JFrame createFileChooser(boolean htmlEnabled) {
        JFileChooser jfc = new JFileChooser(new VirtualFileSystemView());
        jfc.putClientProperty("html.disable", htmlEnabled);
        jfc.setControlButtonsAreShown(false);

        JFrame frame = new JFrame((htmlEnabled) ? "HTML enabled" : "HTML disabled");
        frame.add(jfc);
        frame.pack();
        return frame;
    }

I think this way is cleaner: create the file chooser, configure it?; then create the frame, put the file chooser into the frame.

`html_enabled` ? `htmlEnabled`, which aligns to the Java style.

? I added `jfc.setControlButtonsAreShown(false)` to hide the *Open* and *Cancel* buttons.

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 96:

> 94:         public File[] getRoots() {
> 95:             return new File[]{
> 96:                     new File("/", "<html><h1 color=#ff00ff><font face=\"Comic Sans MS\">SWING ROCKS!!!111"),

Suggestion:

                    new File("/", "<html><h1 color=#ff00ff><font face="Comic Sans MS">Swing Rocks!"),

Use title case?

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

PR Review: https://git.openjdk.org/jdk/pull/24439#pullrequestreview-2855169377
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2098639699
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2098604737
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2098653423
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2098604212
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2098598944
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2098610838
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2098642534

From aivanov at openjdk.org  Tue May 20 18:52:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 18:52:56 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v3]
In-Reply-To: <9eWBFqqVGM6xc824gwLDzpRT6cYOORMC1bFkdzFrseA=.424e137c-e5d9-4fb9-a2b1-e5a675b8ac6b@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <vEWA2CeJs9SmRb8K81xVWRMko2w6xj9Q2hIGXlYUVZM=.e7d736f9-9b2c-4a48-b366-e3801a304f9e@github.com>
 <Ahgb4B8gkI9Cjqwdoq0-Acfcga0QYbiprxAS4k3Fa7U=.c36f229f-2529-4788-8d14-86a51422e373@github.com>
 <vmyVz_91nhgMmjLla6DKOkJGD-Xp_6qajAgUKfeXLoY=.89fefd83-43c9-476c-a951-70a633f9a5e2@github.com>
 <xrKZHsl3CpNOAmppgUcqtxPK_Pb8RinLTrj11RMxGOY=.a64e2fff-04cb-4001-acbb-3c10b24d54de@github.com>
 <f6oYZ6xLi4A9CLobrR9K5ENfgEmSBqTay1kQaf7f3yY=.29f79326-48e7-4ad8-9afb-055536cdb4b2@github.com>
 <isvH5l_2W5YQ-mbpXd3XJMLyp2XP8Yohrq9cxFi84Nc=.27fc812c-b5e4-43df-b9f8-55881331097c@github.com>
 <UzRKXFgBG_WyKaEF3Hjdb3qb2ExAFmUA3UNZI42zMm0=.48021bee-2600-47bf-8c26-bfdddf320592@github.com>
 <MsGQMdJVt_rqNfkj62DVrsBWPlQrx5lsxjnR5BKzl9k=.a8bbbc62-1b60-4982-9424-6af202a6304c@github.com>
 <PfOTt7diduByRh7oViyuN-gJ-3iiD_CnGHIY8Xmni8k=.b52391fd-f576-4c01-923b-209975713596@github.com>
 <HYVRAUlbtJyV9GVAKlTWbeUNMHzV8ugjNuP
 7B4ALY48=.134d9204-f8a9-48fa-85af-982aa124469a@github.com>
 <oTB8PeOedGLLoza4ALZkxGvEdJttzGQb3_eVKwwT0eE=.9f06dd2d-7485-45eb-8cae-af3bad0aa683@github.com>
 <kG1MjZyVmybZj-A8u7ak4GBJ-h06fy5fAxIjFObj45c=.c80b7530-2747-4e56-bb7c-72bc84a612cf@github.com>
 <mwA2kTMeaSXuWYCnqXlvhMAJYUA50J58c-8BPaPiLw8=.71bc0dea-2509-491d-878a-ae27b04ec5fd@github.com>
 <QhZ-yOsUL-Y-EFjbyDD98pdW-EqLQk9yIIyIZF-IAh0=.a2145cd5-59fe-437f-81f6-4b468a5e8cb3@github.com>
 <p019LdENzXf5VWn6bjL5itcebyP1FWZeacqqDwVERmA=.86fa1fe0-138d-4655-8046-0f7021a4f0f4@github.com>
 <9eWBFqqVGM6xc824gwLDzpRT6cYOORMC1bFkdzFrseA=.424e137c-e5d9-4fb9-a2b1-e5a675b8ac6b@github.com>
Message-ID: <rFUc3gXsLM7ksGnwgOST8p-3OTP-Vje4GGFPR_XIBEE=.70f8c341-1fdf-4b9b-9b52-1916ef3b3bd3@github.com>

On Tue, 13 May 2025 03:05:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Exception in thread "AWT-EventQueue-0" java.nio.file.InvalidPathException: Illegal char <<> at index 0: <html><h1 color=#ff00ff><font face="Comic Sans MS">SWING ROCKS!!!111
>>>         at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:191)
>>>         at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:142)
>>>         at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:46)
>>>         at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
>>>         at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:203)
>>>         at java.base/java.nio.file.Path.of(Path.java:148)
>>>         at java.base/java.nio.file.Paths.get(Paths.java:69)
>>>         at java.desktop/sun.awt.shell.ShellFolder.getShellFolder(ShellFolder.java:260)
>>>         at java.desktop/javax.swing.filechooser.FileSystemView.getShellFolder(FileSystemView.java:724)
>>>         at java.desktop/javax.swing.filechooser.FileSystemView.getSystemIcon(FileSystemView.java:242)
>>>         at java.desktop/com.sun.java.swing.plaf.windows.WindowsFileChooserUI$WindowsFileView.getIcon(WindowsFileChooserUI.java:1398)
>>>         at java.desktop/javax.swing.JFileChooser.getIcon(JFileChooser.java:1614)
>> 
>> 
>> This exception looks like a bug? I think if the file was not found then null is an expected result.
>> For now it can be bypassed by this:
>> 
>> 
>> import java.io.File;
>> import java.lang.Override;
>> 
>> import javax.swing.Icon;
>> import javax.swing.JFileChooser;
>> import javax.swing.SwingUtilities;
>> import javax.swing.UIManager;
>> import javax.swing.UnsupportedLookAndFeelException;
>> import javax.swing.filechooser.FileSystemView;
>> 
>> public class VirtualFileChooser {
>> 
>>     public static void main(String[] args) throws UnsupportedLookAndFeelException, ClassNotFoundException, InstantiationException, IllegalAccessException {
>>         UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");
>>         //UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel");
>> 
>> 
>>         SwingUtilities.invokeLater(() -> {
>>             JFileChooser chooser = new JFileChooser(new VirtualFileSystemView());
>> 
>>             int result = chooser.showOpenDialog(null);
>>             if (result == JFileChooser.APPROVE_OPTION) {
>>                 File selectedFile = chooser.getSelectedFile();
>>                 System.out.println("Selected: " + selectedFile.getAbsolutePath());
>>             }
>> ...
>
> Note that the bug occurs both in the list of roots (in the dropdown) and in the list of files.

Now @mrserb deserves being a co-author.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2098641113

From serb at openjdk.org  Tue May 20 19:01:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 20 May 2025 19:01:55 GMT
Subject: RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <95g0weiARkYC01wgCQbJNJD1iwc_RpCUS3sH1i1K_-A=.333d4836-3718-41c3-a998-4e2bccad3c1b@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
 <SFCwpT-pkIwJZKnh66ZmtS1JGRHuxVueCVL12ozC2AI=.559a9c87-79e4-403a-a5d8-fe9c83f7f465@github.com>
 <OOtQjOWTck5yF6VDjBVnfE-1_aa3vTN1vxeuiIrNjKY=.747aea97-b92c-47d0-937d-ae071468d7a9@github.com>
 <95g0weiARkYC01wgCQbJNJD1iwc_RpCUS3sH1i1K_-A=.333d4836-3718-41c3-a998-4e2bccad3c1b@github.com>
Message-ID: <9Lzt5tfT0nBGGv-3Bv2DEUil_hT4hV_sJZ4iXi8L5RU=.465ecb13-f771-482e-b085-bb704fa26e61@github.com>

On Mon, 19 May 2025 12:23:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Looks like yes. I think it's worth to create a separate issue to fix it.
>
> It doesn't matter, it looks? `localL` is `null` if and only if listener is `null`.
> 
> However, I'd put the null-check above the call to `deProxyAWTEventListener` to avoid any confusion.

listener and proxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So this method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. so it is just a code clarification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24692#discussion_r2098669264

From aivanov at openjdk.org  Tue May 20 19:17:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 19:17:52 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v3]
In-Reply-To: <Dd8HDFTgh9IUbl48-2wNTXn2I4vKIfEJGm9Q2hN3YiQ=.1c6295b9-3fea-4907-a316-fe06dfcaccf1@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <Dd8HDFTgh9IUbl48-2wNTXn2I4vKIfEJGm9Q2hN3YiQ=.1c6295b9-3fea-4907-a316-fe06dfcaccf1@github.com>
Message-ID: <rFuZzWm1xKWNl4xSpEZIArVS8P1OJrV1tOYndRFVyWU=.e2127e7f-4e93-4a12-97e0-f8d70a7247ea@github.com>

On Tue, 20 May 2025 18:34:28 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
>> 
>> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed : Formatting changes,copyright,cosmetic changes,etc

There are still unresolved comments, and I added new ones.

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 148:

> 146: 
> 147:     private record ColoredIcon(Color color, int width,
> 148:                                int height) implements Icon {

Suggestion:

    private record ColoredIcon(Color color, int width, int height)
            implements Icon {

This would be better. Otherwise, I'd wrap all the parameters, including `width` because both `width` and `height` are tightly connected.

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 150:

> 148:                                int height) implements Icon {
> 149:         @Override
> 150:             public void paintIcon(Component c, Graphics g, int x, int y) {

Suggestion:

        @Override
        public void paintIcon(Component c, Graphics g, int x, int y) {

You have reduce indentation of the entire `ColoredIcon` class.

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 161:

> 159:             }
> 160:             @Override
> 161:             public int getIconHeight() {

I'm still for having blank lines between the methods: it makes scanning the code easier as you clearly see where a method ends and another starts.

There's no penalty for additional lines, but they improve readability, in my opinion. In an IDE, you can always collapse unimportant sections, like this helper class, and get it out of your view.

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25319#pullrequestreview-2855300606
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098678566
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098679939
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098683738

From aivanov at openjdk.org  Tue May 20 19:20:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 19:20:53 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v2]
In-Reply-To: <Up0J1fq1aI_x-78TvT1Zti9UuDg7viR6TOETEEfO3qQ=.fd4d6984-9f47-4280-a80c-b77653c1311c@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <8raDo3FpSvhKD-OA21EHbKEYVEejYB4qtUipeGVNvJw=.b6f7a74f-392a-4541-82d1-b9301123f03b@github.com>
 <Up0J1fq1aI_x-78TvT1Zti9UuDg7viR6TOETEEfO3qQ=.fd4d6984-9f47-4280-a80c-b77653c1311c@github.com>
Message-ID: <SCAD8dMpd69FpFc1S2A_0-A-XVIMPrgea9xo3ZO54xM=.c8e175a7-b7d0-4a06-9a93-5ec631680f70@github.com>

On Tue, 20 May 2025 17:01:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fixed : Rearranged and reused code by creating a new Helper MenuItemTestHelper.java
>
> test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 43:
> 
>> 41: import javax.swing.UIManager;
>> 42: 
>> 43: class MenuItemTestHelper {
> 
> I would've kept `MenuItemTest` as the name of the class. It's fine either way.
> 
> I'd also mark this class as `final`. It may be `public` or be left with the default access.

However, `-Helper` could be better ? the name of the class clearly indicates that this class is not _a test_ but a helper class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2098697447

From prr at openjdk.org  Tue May 20 19:30:54 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 May 2025 19:30:54 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
In-Reply-To: <XcqAO2xvFvNB-I6F9LJbzDbZKjV4FgGCEAsZm2emO2k=.7cca3d51-104a-43cd-9fc0-2008ed905f7a@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <XcqAO2xvFvNB-I6F9LJbzDbZKjV4FgGCEAsZm2emO2k=.7cca3d51-104a-43cd-9fc0-2008ed905f7a@github.com>
Message-ID: <hV2gqB4dvSe4ZhFj3_Ox35XsmuPW3SxGnp6lpnjhGRM=.141f6a7b-658f-4a1d-9258-8d10628c8a61@github.com>

On Mon, 19 May 2025 12:44:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Update the some code examples and accompanying images to no longer mention or display as applets.
>
> src/java.desktop/share/classes/java/awt/GridBagLayout.java line 243:
> 
>> 241:  * right-to-left container.
>> 242:  *
>> 243:  * <div style="margin:0 auto;width:850px;text-align:center;font-weight:bold">
> 
> Is it possible to keep the width small as it was?

I doubt it - unless you make the font really small, maybe?
If you look at how it is today you'll see the buttons are packed together using Motif L&F
https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/GridBagLayout.html
BTW I tried a couple of times to upload javadoc to cr.openjdk.org so I could show the new rendered javadoc but uploads failed ...

> src/java.desktop/share/classes/java/awt/GridBagLayout.java line 288:
> 
>> 286:  * public class GridBagLayoutExample {
>> 287:  *
>> 288:  *  static void addButton(String name,
> 
> Suggestion:
> 
>  *  private static void addButton(String name,

ok ...

> src/java.desktop/share/classes/java/awt/GridBagLayout.java line 295:
> 
>> 293:  *     gridbag.setConstraints(button, c);
>> 294:  *     frame.add(button);
>> 295:  *  }
> 
> The `add` method should indented by 4 spaces to the right.

adjusting

> src/java.desktop/share/classes/java/awt/GridBagLayout.java line 303:
> 
>> 301:  *       GridBagLayout gridbag = new GridBagLayout();
>> 302:  *       GridBagConstraints c = new GridBagConstraints();
>> 303:  *       frame.setLayout(gridbag);
> 
> The `main` method should be indented by 4 spaces to the right, it's inside `GridBagLayoutExample` class.

will adjust

> src/java.desktop/share/classes/java/awt/MediaTracker.java line 108:
> 
>> 106:  *          tracker.addImage(bg, 0);
>> 107:  *          for (int i = 0; i < 5; i++) {
>> 108:  *              anim[i] = tk.getImage("anim"+i+".gif");
> 
> Suggestion:
> 
>  *              anim[i] = tk.getImage("anim" + i + ".gif");

ok ...

> src/java.desktop/share/classes/java/awt/doc-files/BorderLayout-1.png line 1:
> 
>> 1: ?PNG
> 
> The images would look better with square borders? which are left on Windows 10 only.
> 
> If it's possible to make the pixels on the rounded corners transparent or at least white, the images would look better.

I did not feel like getting into manual touch up of these images. In some cases they are a massive improvement over what was there before regardless eg this is how FlowLayout looks today
https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/doc-files/FlowLayout-1.gif

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2098687639
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2098711963
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2098711724
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2098711524
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2098712376
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2098711098

From aivanov at openjdk.org  Tue May 20 19:37:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 19:37:56 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v3]
In-Reply-To: <hxqp5b9_-Ok5rUQcGmmjO9tfksC-ID0bnc_fGgkCUb4=.aa648c7b-9535-4359-9a96-67cdcef425ba@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
 <hxqp5b9_-Ok5rUQcGmmjO9tfksC-ID0bnc_fGgkCUb4=.aa648c7b-9535-4359-9a96-67cdcef425ba@github.com>
Message-ID: <jO9sGqtsbsfl2r5Nk-rf1TDAg1vfugxXLIQF-HluIVM=.c796e81c-b82a-40f3-b4b5-eaf2ac51ad4c@github.com>

On Tue, 20 May 2025 07:53:30 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
>> Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.
>> 
>> Verified the updated test in CI on macOS 14.7 machine and there is no failure.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - File merge
>  - Review comment fix, latch and other changes
>  - Test Stabilization

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/List/ListEnterExitTest.java line 54:

> 52:     private final int LATCH_TIMEOUT = 3;
> 53:     private static volatile CountDownLatch mouseEnterLatch = new CountDownLatch(1);
> 54:     private static volatile CountDownLatch mouseExitLatch = new CountDownLatch(1);

Suggestion:


    private static final int X_OFFSET = 30;
    private static final int Y_OFFSET = 40;
    private static final int LATCH_TIMEOUT = 3;

    private final CountDownLatch mouseEnterLatch = new CountDownLatch(1);
    private final CountDownLatch mouseExitLatch = new CountDownLatch(1);

test/jdk/java/awt/List/ListEnterExitTest.java line 97:

> 95: 
> 96:             if (!mouseEnterLatch.await(LATCH_TIMEOUT, TimeUnit.SECONDS)) {
> 97:                 System.out.println("mouseEnterLatch count is : " + mouseEnterLatch.getCount());

This print is redundant: if `mouseEnterLatch` isn't released yet, its count is 1 ? it can't have any other value. At the same, the count could change right after the timeout occurred which would lead to a very confusing output.

Thus, I recommend removing printing the count of a latch.

test/jdk/java/awt/List/ListEnterExitTest.java line 114:

> 112:     }
> 113: 
> 114:     static class MouseEnterExitListener extends MouseAdapter {

Suggestion:

    private class MouseEnterExitListener extends MouseAdapter {

Removing `static` allows removing `static` modifier from the latches.

In fact, the `MouseEnterExitListener` class can be eliminated altogether? Yet the code could be clearer this way.

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

PR Review: https://git.openjdk.org/jdk/pull/25299#pullrequestreview-2855348060
PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2098709525
PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2098723381
PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2098717008

From aivanov at openjdk.org  Tue May 20 19:42:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 19:42:53 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v3]
In-Reply-To: <hxqp5b9_-Ok5rUQcGmmjO9tfksC-ID0bnc_fGgkCUb4=.aa648c7b-9535-4359-9a96-67cdcef425ba@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
 <hxqp5b9_-Ok5rUQcGmmjO9tfksC-ID0bnc_fGgkCUb4=.aa648c7b-9535-4359-9a96-67cdcef425ba@github.com>
Message-ID: <0UXVLm0ygz9yjB3TznU-sRYTvk4wIjzDZxwOSnL2YwM=.17c929b3-5d96-44a3-9ca5-06f012bc0cdc@github.com>

On Tue, 20 May 2025 07:53:30 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
>> Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.
>> 
>> Verified the updated test in CI on macOS 14.7 machine and there is no failure.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - File merge
>  - Review comment fix, latch and other changes
>  - Test Stabilization

test/jdk/java/awt/List/ListEnterExitTest.java line 40:

> 38: 
> 39: import java.awt.event.InputEvent;
> 40: import java.awt.event.MouseAdapter;

`InputEvent` isn't used in the class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2098730419

From aivanov at openjdk.org  Tue May 20 19:49:51 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 19:49:51 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
In-Reply-To: <hV2gqB4dvSe4ZhFj3_Ox35XsmuPW3SxGnp6lpnjhGRM=.141f6a7b-658f-4a1d-9258-8d10628c8a61@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <XcqAO2xvFvNB-I6F9LJbzDbZKjV4FgGCEAsZm2emO2k=.7cca3d51-104a-43cd-9fc0-2008ed905f7a@github.com>
 <hV2gqB4dvSe4ZhFj3_Ox35XsmuPW3SxGnp6lpnjhGRM=.141f6a7b-658f-4a1d-9258-8d10628c8a61@github.com>
Message-ID: <fDAzBlleodt7JZtPk_4WNoPGNGwtlwv1uztR_Ca0qZI=.eb949087-d7b8-430c-8ed3-6c669a9cd2c0@github.com>

On Tue, 20 May 2025 19:12:21 GMT, Phil Race <prr at openjdk.org> wrote:

> BTW I tried a couple of times to upload javadoc to cr.openjdk.org so I could show the new rendered javadoc but uploads failed ...

I experienced some issues with uploading files to cr.openjdk.org some time ago; recently it worked well, however, the login isn't instantaneous. I uploaded the updated javadoc for `PassFailJFrame` yesterday.

Yeah, it would be helpful to look at the updated javadoc. If I have some time, I'll build updated javadoc and upload it?

>> src/java.desktop/share/classes/java/awt/doc-files/BorderLayout-1.png line 1:
>> 
>>> 1: ?PNG
>> 
>> The images would look better with square borders? which are left on Windows 10 only.
>> 
>> If it's possible to make the pixels on the rounded corners transparent or at least white, the images would look better.
>
> I did not feel like getting into manual touch up of these images. In some cases they are a massive improvement over what was there before regardless eg this is how FlowLayout looks today
> https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/doc-files/FlowLayout-1.gif

I absolutely agree, the new screenshots are of a better quality.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2098739075
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2098739983

From aivanov at openjdk.org  Tue May 20 20:02:51 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 20:02:51 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
In-Reply-To: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
Message-ID: <-fB8yPUWis2KHIf76x2T6MX_orW3Ys4SKLzhAPYbwsA=.d3c81c1c-80e8-4e45-921f-d878a7fb7857@github.com>

On Fri, 16 May 2025 23:04:28 GMT, Phil Race <prr at openjdk.org> wrote:

> Update the some code examples and accompanying images to no longer mention or display as applets.

src/java.desktop/share/classes/java/awt/BorderLayout.java line 103:

> 101:  *
> 102:  * <hr><blockquote><pre>
> 103:  * import java.awt.BorderLayout;

Should we replace `<blockquote><pre>` with `{@snippet}` instead?

So, the sample could look like this:


 * {@snippet lang='java':
 * import java.awt.BorderLayout;
 * // all the other code
 *     });
 *   }
 * }
 * }

The last `}` closes the `{@snippet}`, the previous `}` closes `BorderLayoutExample` class.

I used `{@snippet}` in [`PassFailJFrame` javadocs](https://github.com/openjdk/jdk/blob/972f2ebe978280d22531a70116e79837632f6ebc/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L166-L185), and it looks like this in [the generated javadoc](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.html#sampleManualTestCode) with a *Copy* button embedded.

[Programmer's Guide to Snippets](https://docs.oracle.com/en/java/javase/21/javadoc/snippets.html) explains how to use this new javadoc feature available since Java 18 ([JDK-8201533](https://bugs.openjdk.org/browse/JDK-8201533)).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2098758600

From aivanov at openjdk.org  Tue May 20 20:08:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 20:08:52 GMT
Subject: RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <9Lzt5tfT0nBGGv-3Bv2DEUil_hT4hV_sJZ4iXi8L5RU=.465ecb13-f771-482e-b085-bb704fa26e61@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
 <SFCwpT-pkIwJZKnh66ZmtS1JGRHuxVueCVL12ozC2AI=.559a9c87-79e4-403a-a5d8-fe9c83f7f465@github.com>
 <OOtQjOWTck5yF6VDjBVnfE-1_aa3vTN1vxeuiIrNjKY=.747aea97-b92c-47d0-937d-ae071468d7a9@github.com>
 <95g0weiARkYC01wgCQbJNJD1iwc_RpCUS3sH1i1K_-A=.333d4836-3718-41c3-a998-4e2bccad3c1b@github.com>
 <9Lzt5tfT0nBGGv-3Bv2DEUil_hT4hV_sJZ4iXi8L5RU=.465ecb13-f771-482e-b085-bb704fa26e61@github.com>
Message-ID: <EYWOPSN7_Mot-70btErtr2PGIpZi4FyhnUziQknSHOg=.4de79c9d-bd15-4a1e-9c81-e233f81d9dc2@github.com>

On Tue, 20 May 2025 18:59:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> It doesn't matter, it looks? `localL` is `null` if and only if listener is `null`.
>> 
>> However, I'd put the null-check above the call to `deProxyAWTEventListener` to avoid any confusion.
>
> listener and proxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So this method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. so it is just a code clarification.

You're right!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24692#discussion_r2098766802

From aivanov at openjdk.org  Tue May 20 20:19:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 20:19:53 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine [v3]
In-Reply-To: <h6uPRYX8jsYlzHlBx8rfCEXDyX_cCuSH_nSyW5oDk2E=.77b0c49f-8475-4307-b27e-4f2df3f5b4d5@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
 <c2FRmUEOKhK0i4Mm1dHqdCyu5aCY6cMGE-xQFzSujmQ=.9a13234c-e073-4c12-946f-0d7d77d5f190@github.com>
 <h6uPRYX8jsYlzHlBx8rfCEXDyX_cCuSH_nSyW5oDk2E=.77b0c49f-8475-4307-b27e-4f2df3f5b4d5@github.com>
Message-ID: <cPkd_BT_6Mu33D1S2DYycmSSUyM5XGPD2HeOanCHt7c=.87d0cdac-ed67-439c-89e0-0a88a35710e3@github.com>

On Tue, 20 May 2025 11:17:39 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> I think the original issue of getting same RGB color for both default and non-default button is happening because when we move mouse pointer to a location and pick the color from the same location using robot, sometimes it picks the color of mouse pointer and not UI component(this issue is observed only in macOS aarch64 machines).
> 
> Since we have completely removed usage of robot in this test case, we should not see same color for default and non-default buttons anymore. LGTM.

Is it possible that the button hovered by mouse looks the same way as the default one?

Did the original test move the mouse before getting pixel color of a button?

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

PR Comment: https://git.openjdk.org/jdk/pull/25244#issuecomment-2895724466

From prr at openjdk.org  Tue May 20 20:30:21 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 May 2025 20:30:21 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v2]
In-Reply-To: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
Message-ID: <gfibyrL20Gfyy_gFKpgIHZwSFkrqA5qn7ylb78VnI4w=.f809d3bd-f1ac-4e53-b98b-eb49dd952630@github.com>

> Update the some code examples and accompanying images to no longer mention or display as applets.

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

  8357176

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25278/files
  - new: https://git.openjdk.org/jdk/pull/25278/files/d3d8a1cc..9bfba377

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

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

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

From prr at openjdk.org  Tue May 20 20:30:21 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 May 2025 20:30:21 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
In-Reply-To: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
Message-ID: <AxFLogCb12PTAZ5QdkFiSGzbTfXWJi2MMV7zIrXXrec=.528276f8-cfa5-4273-b6d3-ff4c3e78a8c1@github.com>

On Fri, 16 May 2025 23:04:28 GMT, Phil Race <prr at openjdk.org> wrote:

> Update the some code examples and accompanying images to no longer mention or display as applets.

> > It seems the new screenshots could be improved by capturing them on a HiDPI (Retina) display, as the current images appear blurry. And to eliminate background elements in the corners, it might be better to capture screenshots of undecorated windows as was done in the old images.
> 
> To make the screenshots look good on High DPI displays, we need several images (preferably at 100%, 150% and 200% as the most common scales) and use the [**`srcset` attribute**](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/img#srcset) of the `<img>` element to provide different resolutions.
> 
> If you just create a screenshot on (Retina at 200% scale), the screenshots will be _too large_ and still blurry as browsers will still scale up the screenshots to the scale of the display because the [`src` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/img#src) is treated as 100%-scale candidate only.
> 
> If we agree to go this way, I can create screenshots on Windows 10 (which still uses square window borders) in different resolutions.

Re-doing the images was necessary because they were obviously applets and extremely dated, so they are better (IMO) and good enough. I just figured out how to do the screen capture without the corners.  macOS screen capture included a massive shadow that doubled the size. There's a trick (or two)
(1) Cmd-Shift-4 to enable screen capture
(2) Space to say you want to capture a specific window
(3) Option-Enter or Option-Left-Click will capture WITHOUT the shadow  (phew)

I'll upload new images

If you want to do more in a follow-up fix, that's fine, although I am not sure about Windows 10 .. as its already on the way out.
I'm also not sure about any scaling of Windows 10 rendering as it will have LCD text which is notoriously bad when scaled.

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

PR Comment: https://git.openjdk.org/jdk/pull/25278#issuecomment-2895747242

From serb at openjdk.org  Tue May 20 21:19:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 20 May 2025 21:19:51 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v2]
In-Reply-To: <gfibyrL20Gfyy_gFKpgIHZwSFkrqA5qn7ylb78VnI4w=.f809d3bd-f1ac-4e53-b98b-eb49dd952630@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <gfibyrL20Gfyy_gFKpgIHZwSFkrqA5qn7ylb78VnI4w=.f809d3bd-f1ac-4e53-b98b-eb49dd952630@github.com>
Message-ID: <Wv2DHkaM6ALImqwqG13lu71Wdn9eOaPSM21SHSbwURk=.bbc1280f-1b7c-4d91-bf74-cf3660f530b8@github.com>

On Tue, 20 May 2025 20:30:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> Update the some code examples and accompanying images to no longer mention or display as applets.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357176

src/java.desktop/share/classes/java/awt/GridLayout.java line 50:

> 48:  *
> 49:  *     EventQueue.invokeAndWait(() -> {
> 50:  *        Frame frame = new Frame("GridLayout");

I would like to bring this to the discussion not necessarily suggesting any changes. I noticed that the example uses a "frame", while the description above refers to a "window" it might be worth unification. Also, regarding invokeAndWait: it?s not strictly necessary here since this is AWT but it does not break anything. However, I wonder if it?s worth discussing the use of invokeAndWait vs invokeLater. In tests, we usually prefer invokeAndWait because we need to wait for the action to complete, but in applications invokeLater should work fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2098892219

From prr at openjdk.org  Tue May 20 21:58:52 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 May 2025 21:58:52 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v2]
In-Reply-To: <Wv2DHkaM6ALImqwqG13lu71Wdn9eOaPSM21SHSbwURk=.bbc1280f-1b7c-4d91-bf74-cf3660f530b8@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <gfibyrL20Gfyy_gFKpgIHZwSFkrqA5qn7ylb78VnI4w=.f809d3bd-f1ac-4e53-b98b-eb49dd952630@github.com>
 <Wv2DHkaM6ALImqwqG13lu71Wdn9eOaPSM21SHSbwURk=.bbc1280f-1b7c-4d91-bf74-cf3660f530b8@github.com>
Message-ID: <sxhxknLCvcHCTm22sZOk6ACvFA7qWk1Ihs46Pg7MmP0=.5f9e5a33-554b-4cf5-a240-316f4e963e90@github.com>

On Tue, 20 May 2025 21:17:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357176
>
> src/java.desktop/share/classes/java/awt/GridLayout.java line 50:
> 
>> 48:  *
>> 49:  *     EventQueue.invokeAndWait(() -> {
>> 50:  *        Frame frame = new Frame("GridLayout");
> 
> I would like to bring this to the discussion not necessarily suggesting any changes. I noticed that the example uses a "frame", while the description above refers to a "window" it might be worth unification. Also, regarding invokeAndWait: it?s not strictly necessary here since this is AWT but it does not break anything. However, I wonder if it?s worth discussing the use of invokeAndWait vs invokeLater. In tests, we usually prefer invokeAndWait because we need to wait for the action to complete, but in applications invokeLater should work fine.

A Frame (the java class) creates a window (the desktop concept). I would not want to promote the java type Frame to mean the concept.
Regarding invokeAndWait vs invokeLater, either is fine in this case and main has nothing else to do whilst waiting and is the safest default.
I pondered whether to do either in this simple case, but we do generally these days recommend this pattern even for AWT as Swing classes may be used to implement AWT .. and if I did not I guarantee someone would have said I should use it ! Whether or not it matters in this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2098939094

From prr at openjdk.org  Tue May 20 22:09:37 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 May 2025 22:09:37 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v3]
In-Reply-To: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
Message-ID: <Jkcf9PT4djTDOsR3dC-apeE1--0K_59n0cbtbGKqZxs=.c77a8534-e038-4911-b1fc-59723b608f7f@github.com>

> Update the some code examples and accompanying images to no longer mention or display as applets.

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

  8357176

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25278/files
  - new: https://git.openjdk.org/jdk/pull/25278/files/9bfba377..21f4cba1

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

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

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

From prr at openjdk.org  Tue May 20 22:09:37 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 May 2025 22:09:37 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v3]
In-Reply-To: <-fB8yPUWis2KHIf76x2T6MX_orW3Ys4SKLzhAPYbwsA=.d3c81c1c-80e8-4e45-921f-d878a7fb7857@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <-fB8yPUWis2KHIf76x2T6MX_orW3Ys4SKLzhAPYbwsA=.d3c81c1c-80e8-4e45-921f-d878a7fb7857@github.com>
Message-ID: <AtkiIyS8SrvMW-C5GaFYaOc76-IUg3roarTP-EUezGk=.1fc94d6d-dc18-4174-a6ca-4efef1bc734e@github.com>

On Tue, 20 May 2025 20:00:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357176
>
> src/java.desktop/share/classes/java/awt/BorderLayout.java line 103:
> 
>> 101:  *
>> 102:  * <hr><blockquote><pre>
>> 103:  * import java.awt.BorderLayout;
> 
> Should we replace `<blockquote><pre>` with `{@snippet}` instead?
> 
> So, the sample could look like this:
> 
> 
>  * {@snippet lang='java':
>  * import java.awt.BorderLayout;
>  * // all the other code
>  *     });
>  *   }
>  * }
>  * }
> 
> The last `}` closes the `{@snippet}`, the previous `}` closes `BorderLayoutExample` class.
> 
> I used `{@snippet}` in [`PassFailJFrame` javadocs](https://github.com/openjdk/jdk/blob/972f2ebe978280d22531a70116e79837632f6ebc/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L166-L185), and it looks like this in [the generated javadoc](https://cr.openjdk.org/~aivanov/PassFailJFrame/api/PassFailJFrame.html#sampleManualTestCode) with a *Copy* button embedded.
> 
> [Programmer's Guide to Snippets](https://docs.oracle.com/en/java/javase/21/javadoc/snippets.html) explains how to use this new javadoc feature available since Java 18 ([JDK-8201533](https://bugs.openjdk.org/browse/JDK-8201533)).

updated to use snippets.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2098948465

From serb at openjdk.org  Tue May 20 22:27:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 20 May 2025 22:27:55 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
Message-ID: <3Cmz0u3qtiLRz6Dl-9SKjyQo3gvWGsz7eSn4sP2rzFM=.04b58489-d2a9-44ab-95c9-1f1e53a62703@github.com>

On Tue, 13 May 2025 21:28:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

btw why not mark this as an incubator/preview feature and look at the reviews?

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

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2895969770

From prr at openjdk.org  Tue May 20 22:36:56 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 May 2025 22:36:56 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <3Cmz0u3qtiLRz6Dl-9SKjyQo3gvWGsz7eSn4sP2rzFM=.04b58489-d2a9-44ab-95c9-1f1e53a62703@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <3Cmz0u3qtiLRz6Dl-9SKjyQo3gvWGsz7eSn4sP2rzFM=.04b58489-d2a9-44ab-95c9-1f1e53a62703@github.com>
Message-ID: <OzdnwmEPgcMzOXy9MMMn4wO2JILGU8-CKBV2gRbGRNs=.f3782e7f-6852-4b6a-b038-735ff308b007@github.com>

On Tue, 20 May 2025 22:25:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> btw why not mark this as an incubator/preview feature and look at the reviews?

I don't think that necessary for this case.

> I wonder about the limitation to `java.io.File` as source for sound clips. Allowing playback from an `InputStream` allows developers to use their own packaging, compression, bundling, or use dynamically generated sound clips, and to work around missing file access permissions. How about this additional factory method:
> 
> ```
>  public static SoundClip createSoundClip(InputStream file) throws IOException;
> ```
> 
> The implementation is simple, because it boils down to an InputStream internally anyway, and testing is equally simple.

InputStreams can be from anywhere - including a network. This isn't intended for that so it deliberately makes you supply a file.

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

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2895981120

From prr at openjdk.org  Tue May 20 22:43:53 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 May 2025 22:43:53 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v3]
In-Reply-To: <Jkcf9PT4djTDOsR3dC-apeE1--0K_59n0cbtbGKqZxs=.c77a8534-e038-4911-b1fc-59723b608f7f@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <Jkcf9PT4djTDOsR3dC-apeE1--0K_59n0cbtbGKqZxs=.c77a8534-e038-4911-b1fc-59723b608f7f@github.com>
Message-ID: <ip78QMW-PDEiKgadE_deBjsWKPIYn9Pwz-T0uWKwbS4=.0ba72771-4091-4af0-b27e-677a68014a0b@github.com>

On Tue, 20 May 2025 22:09:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> Update the some code examples and accompanying images to no longer mention or display as applets.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357176

Ok .. here's uploaded javadoc to view
https://cr.openjdk.org/~prr/8357176/api/java.desktop/java/awt/BorderLayout.html
https://cr.openjdk.org/~prr/8357176/api/java.desktop/java/awt/FlowLayout.html
https://cr.openjdk.org/~prr/8357176/api/java.desktop/java/awt/GridBagLayout.html
https://cr.openjdk.org/~prr/8357176/api/java.desktop/java/awt/GridLayout.html
https://cr.openjdk.org/~prr/8357176/api/java.desktop/java/awt/MediaTracker.html

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

PR Comment: https://git.openjdk.org/jdk/pull/25278#issuecomment-2895990587

From serb at openjdk.org  Tue May 20 23:12:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 20 May 2025 23:12:53 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v3]
In-Reply-To: <Jkcf9PT4djTDOsR3dC-apeE1--0K_59n0cbtbGKqZxs=.c77a8534-e038-4911-b1fc-59723b608f7f@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <Jkcf9PT4djTDOsR3dC-apeE1--0K_59n0cbtbGKqZxs=.c77a8534-e038-4911-b1fc-59723b608f7f@github.com>
Message-ID: <yeN2JsnYSouAc8n9ryuH-Qaq3fUMv0r8R3CVP-XHDTg=.98800227-b2d9-4d80-b025-fd72b7b31aef@github.com>

On Tue, 20 May 2025 22:09:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> Update the some code examples and accompanying images to no longer mention or display as applets.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357176

> Ok .. here's uploaded javadoc to view

>      // The background image fills the frame so we
>      // don't need to clear the applet on repaints.
>      // Just call the paint method.
>      public void update(Graphics g) {
>          paint(g);
>      }
https://cr.openjdk.org/~prr/8357176/api/java.desktop/java/awt/MediaTracker.html

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

PR Comment: https://git.openjdk.org/jdk/pull/25278#issuecomment-2896031531

From serb at openjdk.org  Tue May 20 23:15:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 20 May 2025 23:15:58 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <OzdnwmEPgcMzOXy9MMMn4wO2JILGU8-CKBV2gRbGRNs=.f3782e7f-6852-4b6a-b038-735ff308b007@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <3Cmz0u3qtiLRz6Dl-9SKjyQo3gvWGsz7eSn4sP2rzFM=.04b58489-d2a9-44ab-95c9-1f1e53a62703@github.com>
 <OzdnwmEPgcMzOXy9MMMn4wO2JILGU8-CKBV2gRbGRNs=.f3782e7f-6852-4b6a-b038-735ff308b007@github.com>
Message-ID: <AmP_hQd1BKUdvJJOJOFSdz-_L6KhPHfIcquwlgVsuXs=.8bd39ca1-9bbf-4cbe-a6af-a3ecd7181eae@github.com>

On Tue, 20 May 2025 22:33:57 GMT, Phil Race <prr at openjdk.org> wrote:

> I don't think that necessary for this case.

But it is possible and will not freeze this change in stone forever.

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

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2896035156

From honkar at openjdk.org  Tue May 20 23:55:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 20 May 2025 23:55:53 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v3]
In-Reply-To: <q-jAcupHO9xmaafZinbFmnYuoYs4fzHMAjiNtfldNx4=.8e1fb82b-a181-4610-9557-8c5be252e58e@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <q-jAcupHO9xmaafZinbFmnYuoYs4fzHMAjiNtfldNx4=.8e1fb82b-a181-4610-9557-8c5be252e58e@github.com>
Message-ID: <ZhMSFfwTTnEAQBVcr_RcVnLoL4lekFWIowGgADV8a4s=.b9f310f7-73dc-4cca-80c5-88447312aa46@github.com>

On Mon, 19 May 2025 23:06:39 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The issue is the inability to move the mouse cursor using `java.awt.Robot` on Oracle Linux 10 (which has not yet been released). FIY, the OL10 is no longer provides an Xorg session, so only Wayland is available.
>> It is a JCK conformance failure. 
>> 
>> ---
>> 
>> In our robot implementation, we emulate mouse/keyboard actions using the XTEST extension protocol.
>> 
>> The XTEST calls are now wired to [libEI](https://libinput.pages.freedesktop.org/libei/api/index.html):
>> 
>> 1.
>> 
>> It now asks for a user confirmation to allow interaction, so we should now be able to click on native applications, window titles, etc.
>> 
>> However, our robot implementation is mostly uses XTEST, but there is an exception:
>> for mouse move we use XWarpPointer, which is not part of the XTEST, thus it is not propagated outside of Xwayland server.
>> 
>> So we have a situation where mouse is moving only inside Xwayland server, and we see the mouse enter/exit events,
>> on mouse press we call XTestFakeButtonEvent and it is handled by libei,
>> so the click happens where is the actual mouse cursor is in the system. That is why the test fails.
>> 
>> To avoid this situation we should use XTestFakeMotionEvent for mouseMove in Xwayland case.
>> 
>> It would be a simple solution, but
>> 
>> 
>> 2.
>> 
>> This permission granted by a user doesn't persist across reboots, it timeouts after a period of inactivity.
>> 
>> It still seems to conform to the specifications, but we will not be able to conveniently run automated tests in this case.
>> 
>> ---
>> 
>> So as a solution we can switch the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
>> It has session and `restore_token` functionality to keep permissions granted by a user, similar to what we use in a [Screencast](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html) for taking screenshots.
>> Most of the code can be reused, and it has everything we need.
>> 
>> 
>> * It is only enabled by default on Wayland and Gnome Shell 47 and higher due to XTEST API complications that first arose in this version. For earlier versions, Screencast is used instead.
>> * A new value has been introduced for the `awt.robot.screenshotMethod` system property - `dbusRemoteDesktop`. It works on Ubuntu 24.04 with Gnome 46, but is not enabled by default.
>> * extra mouse buttons are not supported yet, [JDK-8357142](https://bugs.openjdk.org/browse/JDK-8357142)
>> * Since w...
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   call OpenPipeWireRemote even for remote desktop session calls

Tested on Ubuntu 24.04 (Gnome 46) and Ubuntu 25.04 (Gnome 48) (x11 & wayland sessions). Did not notice any regressions with the fix.

@azvegint  I have couple of inline questions.

src/java.desktop/unix/classes/sun/awt/screencast/XdgDesktopPortal.java line 65:

> 63:         }
> 64: 
> 65:         String m = System.getProperty("awt.robot.screenshotMethod", defaultMethod);

Do we allow user to change `awt.robot.screenshotMethod` to dbusScreencast/dbusRemoteDesktop on x11 sessions and to `x11` on wayland session?

Although all 3 methods work on both x11 & wayland sessions in Ubuntu.

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25265#pullrequestreview-2855817880
PR Review Comment: https://git.openjdk.org/jdk/pull/25265#discussion_r2099030982

From honkar at openjdk.org  Tue May 20 23:55:54 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 20 May 2025 23:55:54 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v2]
In-Reply-To: <P5zqV_ciVE8ik4glssalJ2bil6zA5k1BI2sTXsR13GU=.716dd834-2d6b-4344-aade-8ec9eec91abf@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <XRQDe9qB8vtFFeCAbMRxRr5lB4vBCaFCAkDc9autvRc=.597810e7-8ce4-4879-bcf6-a4739273ccdf@github.com>
 <olpdq-aMj48h6bbL-WxYpJY-8iWjre32YpzZo87V68s=.b2330798-fb88-4662-9879-e9c5b9a1f8d7@github.com>
 <XyHPBRWF4NFCV_-QI8Jf_ctiVCLY2PMPGM2-E_DoPRM=.f7461854-264a-422c-81e1-d35cda43f303@github.com>
 <ovY_Iizjy6fx8bfvn2J1tI5QWihqFj2tW9mXwL36KRw=.6a7d5ce2-8958-4e64-a77a-c9f6cdfd821e@github.com>
 <P5zqV_ciVE8ik4glssalJ2bil6zA5k1BI2sTXsR13GU=.716dd834-2d6b-4344-aade-8ec9eec91abf@github.com>
Message-ID: <0pLA7FZoYexqFKgWVXx666ZQ7tiQJMRajg5RxLweZOE=.cebd8a94-53b2-41a3-858d-fea292718083@github.com>

On Tue, 20 May 2025 10:33:21 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>>> I'm not sure if it's really needed, since many tests already depend on the `java.awt.Robot` itself, CI has a one-time manual task to set up all the required permissions for the `java.awt.Robot`, so automated tests provide sufficient coverage.
>> 
>> Can this be documented in [GUI testing](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements)?
>
>> > I'm not sure if it's really needed, since many tests already depend on the `java.awt.Robot` itself, CI has a one-time manual task to set up all the required permissions for the `java.awt.Robot`, so automated tests provide sufficient coverage.
>> 
>> Can this be documented in [GUI testing](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements)?
> 
> Sure, [updated](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements#AutomatedclientGUItestingsystemsetuprequirements-Wayland).

@azvegint
Generic question: While reading about libei, came across [Oeffis](https://libinput.pages.freedesktop.org/libei/api/index.html#sec-oeffis)- a wrapper for XDG portal.
Is the reason to connect to Remote Desktop XDG portal directly because of session length and token alive time?

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

PR Comment: https://git.openjdk.org/jdk/pull/25265#issuecomment-2896082061

From duke at openjdk.org  Wed May 21 00:24:53 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 21 May 2025 00:24:53 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine [v3]
In-Reply-To: <cPkd_BT_6Mu33D1S2DYycmSSUyM5XGPD2HeOanCHt7c=.87d0cdac-ed67-439c-89e0-0a88a35710e3@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
 <c2FRmUEOKhK0i4Mm1dHqdCyu5aCY6cMGE-xQFzSujmQ=.9a13234c-e073-4c12-946f-0d7d77d5f190@github.com>
 <h6uPRYX8jsYlzHlBx8rfCEXDyX_cCuSH_nSyW5oDk2E=.77b0c49f-8475-4307-b27e-4f2df3f5b4d5@github.com>
 <cPkd_BT_6Mu33D1S2DYycmSSUyM5XGPD2HeOanCHt7c=.87d0cdac-ed67-439c-89e0-0a88a35710e3@github.com>
Message-ID: <Q2N5GdV_fh7UPlXu6v33zk-FFpJBbqKAPD4PoLImb4g=.15522d00-42b8-43dd-9f5d-d62c9fa3ecc0@github.com>

On Tue, 20 May 2025 20:16:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Is it possible that the button hovered by mouse looks the same way as the default one?

That's the big question this unit test is trying to answer. (So: I'm not sure.)

> Did the original test move the mouse before getting pixel color of a button?

Yes.

<img width="633" alt="image" src="https://github.com/user-attachments/assets/a90b506a-3600-4378-ba56-232001850e40" />

If that was the problem: all we needed to do is delete this call to `robot.mouseMove`.

(But even so: I think the cursor on Mac is black -- so why would we detect a gray 0x373737 ?)

It may also be worth pointing out: this test has never failed. It was added as an extra precaution, but not because it demonstrated a fix for anything. I would not miss it if we delete it; I don't think it deserves the time spent discussing/refactoring it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25244#issuecomment-2896118497

From serb at openjdk.org  Wed May 21 01:49:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 21 May 2025 01:49:55 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v3]
In-Reply-To: <hxqp5b9_-Ok5rUQcGmmjO9tfksC-ID0bnc_fGgkCUb4=.aa648c7b-9535-4359-9a96-67cdcef425ba@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
 <hxqp5b9_-Ok5rUQcGmmjO9tfksC-ID0bnc_fGgkCUb4=.aa648c7b-9535-4359-9a96-67cdcef425ba@github.com>
Message-ID: <n9_LaEFp_l_hhlLV0JNMXzQfRY0Wj9bBtUhC2a11fnw=.1cd68a24-f97d-4c2e-8d4a-1ec9eb783919@github.com>

On Tue, 20 May 2025 07:53:30 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
>> Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.
>> 
>> Verified the updated test in CI on macOS 14.7 machine and there is no failure.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - File merge
>  - Review comment fix, latch and other changes
>  - Test Stabilization

Did you have a chance to reproduce this bug and see how it works?
When I run it on my laptop I can see the mouse moving out and in of the list and clicking inside of it, but for some reason the events are not sent.

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

PR Comment: https://git.openjdk.org/jdk/pull/25299#issuecomment-2896232431

From serb at openjdk.org  Wed May 21 02:33:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 21 May 2025 02:33:52 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v2]
In-Reply-To: <dEc4B--MJdbczbZaAooTdznvOgwL-xMcBh6VCaMj-Hg=.6b121ad8-79c6-4b45-b529-e989477bf208@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <dEc4B--MJdbczbZaAooTdznvOgwL-xMcBh6VCaMj-Hg=.6b121ad8-79c6-4b45-b529-e989477bf208@github.com>
Message-ID: <8ZpGicPyjB6ryJPd7uMP_25MeO3q7C34t_T-QPV5Q0E=.3d1b27d4-1a2d-4df6-b492-b2d68f5420d3@github.com>

On Tue, 20 May 2025 04:34:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
>> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
>> Fixed by setting the divider location before rendering the left and right components..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Click position fixed..L&F iteration

> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.

It seems a bit inconsistent: on one hand the bug description says that the initial value is used and the value set by the user is ignored but on the other hand, the fix just resets the same value to itself. Could you clarify how this change addresses the issue:
`+ this.setDividerLocation(this.getDividerLocation());`

I have found that for some reason an incorrect value is being set from `BasicSplitPaneUI$BasicHorizontalLayoutManager.layoutContainer`. Could it be that this class incorrectly initializes the dividerLocation to the initial value instead of using the one set by the user?

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

PR Comment: https://git.openjdk.org/jdk/pull/25294#issuecomment-2896302804

From mvs at openjdk.org  Wed May 21 03:00:15 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 21 May 2025 03:00:15 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v4]
In-Reply-To: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
Message-ID: <LKyt1Cg7AqQCm3CWdH76oJA7elvrXG7Hb8_waYST914=.c69fe092-a249-4c9b-bf83-33d0d091d4c4@github.com>

> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
> 
> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed : Formatting changes,cosmetic changes,PassFailJFrame changes, etc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25319/files
  - new: https://git.openjdk.org/jdk/pull/25319/files/098ea0de..22b05bbd

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

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

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

From serb at openjdk.org  Wed May 21 03:04:36 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 21 May 2025 03:04:36 GMT
Subject: RFR: 8357287: Unify usage of ICC profile "header size" constants in
 CMM-related code
Message-ID: <E0IDBFGhxM-z1VwcY4cYSCVXbu93tKcm5qnx_M3nWJ8=.475bec53-4c98-4ba3-accc-0613e0b8eb0f@github.com>

Small unification of "header size" constants, as of now the CMM code uses:
1. sun.java2d.cmm.ProfileDataVerifier.HEADER_SIZE introduced in JDK-8013430
2. java.awt.color.ICC_Profile.HEADER_SIZE introduced in [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377)
3. Hardcoded literal 128

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

Commit messages:
 - 8357287: Unify usage of ICC profile "header size" constants in CMM-related code

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

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

From psadhukhan at openjdk.org  Wed May 21 03:22:22 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 21 May 2025 03:22:22 GMT
Subject: RFR: 8357299: Graphics copyArea doesn't copy any pixels when there is
 overflow
Message-ID: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>

Graphics copyArea overflow check bails out of copying pixels if there is overflow.
The spec says ""If a portion of the source rectangle lies outside the bounds of the component, or is obscured by another window or component, {@code copyArea} *will be unable to copy* the associated pixels"

which suggests that we should always copy the parts inside the bounds and never the parts outside the bounds
but it seems currently, in the case of overflow it no longer copies any pixels, including the parts that are inside. 
So, the fix clips the copyarea region to clip bounds so it will only affect pixels within the valid bounds, and any pixels outside will be ignored.

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

Commit messages:
 - 8357299: Graphics copyArea doesn't copy any pixels when there is overflow

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

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

From psadhukhan at openjdk.org  Wed May 21 03:54:51 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 21 May 2025 03:54:51 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v2]
In-Reply-To: <8ZpGicPyjB6ryJPd7uMP_25MeO3q7C34t_T-QPV5Q0E=.3d1b27d4-1a2d-4df6-b492-b2d68f5420d3@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <dEc4B--MJdbczbZaAooTdznvOgwL-xMcBh6VCaMj-Hg=.6b121ad8-79c6-4b45-b529-e989477bf208@github.com>
 <8ZpGicPyjB6ryJPd7uMP_25MeO3q7C34t_T-QPV5Q0E=.3d1b27d4-1a2d-4df6-b492-b2d68f5420d3@github.com>
Message-ID: <a8kNSlNJBGIGRsonat8v_i-EmxlPJkQ7LQ5hCad93-g=.aea9e411-f5b0-4d37-a6a7-a41c4a143c57@github.com>

On Wed, 21 May 2025 02:30:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
> 
> It seems a bit inconsistent: on one hand the bug description says that the initial value is used and the value set by the user is ignored but on the other hand, the fix just resets the same value to itself. Could you clarify how this change addresses the issue: `+ this.setDividerLocation(this.getDividerLocation());`
> 
> I have found that for some reason an incorrect value is being set from `BasicSplitPaneUI$BasicHorizontalLayoutManager.layoutContainer`. Could it be that this class incorrectly initializes the dividerLocation to the initial value instead of using the one set by the user?

Since it is regression of 4265389: JSplitPane does not support ComponentOrientation where setComponentOrientation method is added, it made sense to me to set the divider location in that method explicitly as it was working before that fix..
If `BasicSplitPaneUI$BasicHorizontalLayoutManager.layoutContainer` had a problem it would have affected before the fix also as that method was not changed in 4265389 fix..

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

PR Comment: https://git.openjdk.org/jdk/pull/25294#issuecomment-2896478225

From abhiscxk at openjdk.org  Wed May 21 04:36:38 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 21 May 2025 04:36:38 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v4]
In-Reply-To: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
Message-ID: <nNtrFxzT76IHQVWYa0BhbruAi_IoSXWA3MtPbf7mv2g=.c6b88e91-c07e-4f3d-ba70-7b8e03b02f9f@github.com>

> Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
> Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.
> 
> Verified the updated test in CI on macOS 14.7 machine and there is no failure.

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

  Review comment fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25299/files
  - new: https://git.openjdk.org/jdk/pull/25299/files/eaac4364..4275fd95

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

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

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

From abhiscxk at openjdk.org  Wed May 21 04:36:42 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 21 May 2025 04:36:42 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v3]
In-Reply-To: <0UXVLm0ygz9yjB3TznU-sRYTvk4wIjzDZxwOSnL2YwM=.17c929b3-5d96-44a3-9ca5-06f012bc0cdc@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
 <hxqp5b9_-Ok5rUQcGmmjO9tfksC-ID0bnc_fGgkCUb4=.aa648c7b-9535-4359-9a96-67cdcef425ba@github.com>
 <0UXVLm0ygz9yjB3TznU-sRYTvk4wIjzDZxwOSnL2YwM=.17c929b3-5d96-44a3-9ca5-06f012bc0cdc@github.com>
Message-ID: <KYuYyQ_RanAgA8e-rfdw2t1hPvJryjHYArrSVYsmnvk=.dfada3c8-49ca-4282-a977-b700609d0125@github.com>

On Tue, 20 May 2025 19:40:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - File merge
>>  - Review comment fix, latch and other changes
>>  - Test Stabilization
>
> test/jdk/java/awt/List/ListEnterExitTest.java line 40:
> 
>> 38: 
>> 39: import java.awt.event.InputEvent;
>> 40: import java.awt.event.MouseAdapter;
> 
> `InputEvent` isn't used in the class.

Updated.

> test/jdk/java/awt/List/ListEnterExitTest.java line 97:
> 
>> 95: 
>> 96:             if (!mouseEnterLatch.await(LATCH_TIMEOUT, TimeUnit.SECONDS)) {
>> 97:                 System.out.println("mouseEnterLatch count is : " + mouseEnterLatch.getCount());
> 
> This print is redundant: if `mouseEnterLatch` isn't released yet, its count is 1 ? it can't have any other value. At the same, the count could change right after the timeout occurred which would lead to a very confusing output.
> 
> Thus, I recommend removing printing the count of a latch.

Updated.

> test/jdk/java/awt/List/ListEnterExitTest.java line 114:
> 
>> 112:     }
>> 113: 
>> 114:     static class MouseEnterExitListener extends MouseAdapter {
> 
> Suggestion:
> 
>     private class MouseEnterExitListener extends MouseAdapter {
> 
> Removing `static` allows removing `static` modifier from the latches.
> 
> In fact, the `MouseEnterExitListener` class can be eliminated altogether? Yet the code could be clearer this way.

I thought of removing the class but then found it ok to have.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2099282323
PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2099282467
PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2099282739

From abhiscxk at openjdk.org  Wed May 21 04:39:01 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 21 May 2025 04:39:01 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v3]
In-Reply-To: <n9_LaEFp_l_hhlLV0JNMXzQfRY0Wj9bBtUhC2a11fnw=.1cd68a24-f97d-4c2e-8d4a-1ec9eb783919@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
 <hxqp5b9_-Ok5rUQcGmmjO9tfksC-ID0bnc_fGgkCUb4=.aa648c7b-9535-4359-9a96-67cdcef425ba@github.com>
 <n9_LaEFp_l_hhlLV0JNMXzQfRY0Wj9bBtUhC2a11fnw=.1cd68a24-f97d-4c2e-8d4a-1ec9eb783919@github.com>
Message-ID: <F3aFJC7rNSrkk-T-ilHkOam94ToCZ4X1lB3jstwGra4=.4059d79c-da2a-465f-a265-ac72fc5c6fb8@github.com>

On Wed, 21 May 2025 01:45:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Did you have a chance to reproduce this bug and see how it works? When I run it on my laptop I can see the mouse moving out and in of the list and clicking inside of it, but for some reason the events are not sent.

I couldn't reproduce it on my system (macOS 15.4.1).
@jayathirthrao was able to reproduce it on macOS14.6 (probably) and the behaviour was same i.e. mouse is moving in and out and clicking inside but **mouse exit event is not triggered**.

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

PR Comment: https://git.openjdk.org/jdk/pull/25299#issuecomment-2896538631

From serb at openjdk.org  Wed May 21 04:41:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 21 May 2025 04:41:55 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v2]
In-Reply-To: <a8kNSlNJBGIGRsonat8v_i-EmxlPJkQ7LQ5hCad93-g=.aea9e411-f5b0-4d37-a6a7-a41c4a143c57@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <dEc4B--MJdbczbZaAooTdznvOgwL-xMcBh6VCaMj-Hg=.6b121ad8-79c6-4b45-b529-e989477bf208@github.com>
 <8ZpGicPyjB6ryJPd7uMP_25MeO3q7C34t_T-QPV5Q0E=.3d1b27d4-1a2d-4df6-b492-b2d68f5420d3@github.com>
 <a8kNSlNJBGIGRsonat8v_i-EmxlPJkQ7LQ5hCad93-g=.aea9e411-f5b0-4d37-a6a7-a41c4a143c57@github.com>
Message-ID: <9bBMGDdEf5NfTc_zAZbCPoaKpFlbZZh1bQcGP8sQkOg=.99975d0e-d7b2-4ff6-a201-c1c97fdfe30a@github.com>

On Wed, 21 May 2025 03:51:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>Since it is regression of 4265389: JSplitPane does not support ComponentOrientation where setComponentOrientation method is added, it made sense to me to set the divider location in that method before rendering the left and right components explicitly as it was working before that fix.

But it sets the same value that is already applied to the split pane:
>this.setDividerLocation(this.getDividerLocation());

It seems this call is required to refresh the UI of the component, which ends up with an incorrect divider location for some reason. But it is unclear whether this is actually caused by the setComponentOrientation method, since the component orientations are not changed in the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/25294#issuecomment-2896544587

From jdv at openjdk.org  Wed May 21 06:17:27 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 21 May 2025 06:17:27 GMT
Subject: RFR: 8312198: [macos] metal pipeline - window rendering stops after
 display sleep
Message-ID: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>

In stress based scenarios it is observed that nothing is drawn in UI content when display wakes up from sleep in Metal pipeline of macOS. Unfortunately i am not able to reproduce it, but based on details in the bug it looks like we are hitting a race condition. Call to CVDisplayLinkCreateWithActiveCGDisplays is becoming a no-op as there are no active displays right after NSWorkspaceScreensDidWakeNotification. Looks like if we continue to call CVDisplayLinkCreateWithActiveCGDisplays after screen wakeup we are able to get the list of ActiveDisplays and then able to create displayLink.

So now the code is modified to check whether CVDisplayLinkCreateWithActiveCGDisplays is successful or not. If not we will try to call CVDisplayLinkCreateWithActiveCGDisplays for 5 instances each with 1 second delay. There is no regression test for this change because it needs a stress based test with display wakeup/sleep(As captured in JBS, i am not able to reproduce this issue).

I have tested this change for sanity by running animation examples from SwingSet2 and continuously connecting/disconnecting external display. Also by multiple display sleep and wakeup scenarios, i don't see any regressions. Also whole clientlibs CI run is done with this patch and it is also green.

While working on this bug also noticed that many functions of CVDisplayLink is deprecated from macOS 14 and going forward we need to use CADisplayLink/CAMetalDisplayLink. I have raised [JDK-8357418](https://bugs.openjdk.org/browse/JDK-8357418) for the same.

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

Commit messages:
 - 8312198: [macos] metal pipeline - window rendering stops after display sleep

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

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

From psadhukhan at openjdk.org  Wed May 21 06:38:52 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 21 May 2025 06:38:52 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v2]
In-Reply-To: <9bBMGDdEf5NfTc_zAZbCPoaKpFlbZZh1bQcGP8sQkOg=.99975d0e-d7b2-4ff6-a201-c1c97fdfe30a@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <dEc4B--MJdbczbZaAooTdznvOgwL-xMcBh6VCaMj-Hg=.6b121ad8-79c6-4b45-b529-e989477bf208@github.com>
 <8ZpGicPyjB6ryJPd7uMP_25MeO3q7C34t_T-QPV5Q0E=.3d1b27d4-1a2d-4df6-b492-b2d68f5420d3@github.com>
 <a8kNSlNJBGIGRsonat8v_i-EmxlPJkQ7LQ5hCad93-g=.aea9e411-f5b0-4d37-a6a7-a41c4a143c57@github.com>
 <9bBMGDdEf5NfTc_zAZbCPoaKpFlbZZh1bQcGP8sQkOg=.99975d0e-d7b2-4ff6-a201-c1c97fdfe30a@github.com>
Message-ID: <lYNnD92k8CxEbRCLBItoCNKhLAGCajQ23rW2NiXUP20=.e0d5b381-b5bb-436d-a407-c0c0ece35e96@github.com>

On Wed, 21 May 2025 04:39:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Since it is regression of 4265389: JSplitPane does not support ComponentOrientation where setComponentOrientation method is added, it made sense to me to set the divider location in that method before rendering the left and right components explicitly as it was working before that fix.
> 
> But it sets the same value that is already applied to the split pane:
> 
> > this.setDividerLocation(this.getDividerLocation());
> 
> It seems this call is required to refresh the UI of the component, which ends up with an incorrect divider location for some reason. But it is unclear whether this is actually caused by the setComponentOrientation method, since the component orientations are not changed in the test.

componentOrientation is set in `BasicOptionPaneUI.installComponent` when it calls `applyComponentOrientation` test called by JOptionPane constructor in the test...
I presume since this solves the issue (even if it means it refreshes the UI indirectly) and is localised to the method which causes this issue and there is no further issue in CI, it should be good to go..

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

PR Comment: https://git.openjdk.org/jdk/pull/25294#issuecomment-2896767507

From tr at openjdk.org  Wed May 21 06:42:53 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 21 May 2025 06:42:53 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v3]
In-Reply-To: <8icaCzTbIOcszrNmqCYdzqI4telSGl3bM-9afdXEWbE=.7c5be52b-eb9e-41e0-b655-5148f135d72c@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <JVyEYDeaC2nRhod516RnecC9xDNUAlJXt0yz4I5xgvo=.a64851ce-c2f6-4e9d-bbdc-d6ad36626f56@github.com>
 <8icaCzTbIOcszrNmqCYdzqI4telSGl3bM-9afdXEWbE=.7c5be52b-eb9e-41e0-b655-5148f135d72c@github.com>
Message-ID: <yK6F84YwKXulAJU1uTfAIC7s6yN7FrvUn0mdrpy8r2g=.c33503fa-541c-465e-b470-ddcc92f3587f@github.com>

On Tue, 20 May 2025 18:18:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 59:
> 
>> 57:                          ComboBox remains in HTML format string, then test PASS.
>> 58:                          If it appears to be in plain text, then test FAILS.
>> 59:                          (Verify for all Look and Feel).
> 
> How do I verify for all Look and Feels?
> 
> The test has to iterate over all L&F, and repeat the same thing for each L&F.
> 
> Ideally, it should be an automated test. However, I'm fine with postponing any efforts to automate the test but I'd like to try to automate it.

`        for (UIManager.LookAndFeelInfo laf : UIManager.getInstalledLookAndFeels()) {
            System.out.println("Test for LookAndFeel " + laf.getClassName());
            UIManager.setLookAndFeel(laf.getClassName());
            PassFailJFrame.builder()
                    .instructions(INSTRUCTIONS)
                    .columns(45)
                    .testUI(HTMLFileName::initialize)
                    .positionTestUIBottomRowCentered()
                    .build()
                    .awaitAndCheck();
            System.out.println("Test passed for LookAndFeel " + laf.getClassName());
        }`
When I try to iterate the test for all L&F, the test result of first L&F is explicitly taken for other L&F too. Any idea why ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2099478001

From jdv at openjdk.org  Wed May 21 06:55:54 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 21 May 2025 06:55:54 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine [v3]
In-Reply-To: <c2FRmUEOKhK0i4Mm1dHqdCyu5aCY6cMGE-xQFzSujmQ=.9a13234c-e073-4c12-946f-0d7d77d5f190@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
 <c2FRmUEOKhK0i4Mm1dHqdCyu5aCY6cMGE-xQFzSujmQ=.9a13234c-e073-4c12-946f-0d7d77d5f190@github.com>
Message-ID: <Afzt8OPTETqp_uugoz4HORhRxlKJGd9UaOhBxM10AhM=.a2962263-ccbd-4a43-90f5-8a93234a3155@github.com>

On Mon, 19 May 2025 05:37:05 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Unfortunately I'm unable to reproduce this failure. I slowed the test down; it passes on my machine before and after this PR.
>> 
>> I added a little bit of logging that might also help identify what's happening.
>> 
>> Does anyone have any more suggestions?
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356061: removing robot
>   
>   This is in response to:
>   https://github.com/openjdk/jdk/pull/25244#issuecomment-2889420453

I understand that this is not a regression test. Mouse pointer color can be changed from default color. Just deleting `robot.mouseMove(x, y)` might also resolve the issue seen in our test environment.

But the current refactoring using BufferedImage is better than using Robot and deleting mouseMove() call.

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

PR Comment: https://git.openjdk.org/jdk/pull/25244#issuecomment-2896806185

From serb at openjdk.org  Wed May 21 07:07:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 21 May 2025 07:07:55 GMT
Subject: RFR: 8357299: Graphics copyArea doesn't copy any pixels when there
 is overflow
In-Reply-To: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
References: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
Message-ID: <9i8bgPuEvIgu_6bnHdDVaGkRIDzycUd3Dwj4uBw0lyU=.98be11bf-e80c-48b7-9a7b-0704b3de60c1@github.com>

On Wed, 21 May 2025 03:17:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Graphics copyArea overflow check bails out of copying pixels if there is overflow.
> The spec says ""If a portion of the source rectangle lies outside the bounds of the component, or is obscured by another window or component, {@code copyArea} *will be unable to copy* the associated pixels"
> 
> which suggests that we should always copy the parts inside the bounds and never the parts outside the bounds
> but it seems currently, in the case of overflow it no longer copies any pixels, including the parts that are inside. 
> So, the fix clips the copyarea region to clip bounds so it will only affect pixels within the valid bounds, and any pixels outside will be ignored.

src/java.desktop/share/native/libawt/java2d/loops/Blit.c line 77:

> 75:     srcInfo.bounds.x1 = srcx;
> 76:     srcInfo.bounds.y1 = srcy;
> 77:     if (UNSAFE_TO_ADD(srcx, width) ||

isn't the MaskBlit_MaskBlit use the same pattern?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25340#discussion_r2099524421

From psadhukhan at openjdk.org  Wed May 21 07:25:52 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 21 May 2025 07:25:52 GMT
Subject: RFR: 8357299: Graphics copyArea doesn't copy any pixels when there
 is overflow
In-Reply-To: <9i8bgPuEvIgu_6bnHdDVaGkRIDzycUd3Dwj4uBw0lyU=.98be11bf-e80c-48b7-9a7b-0704b3de60c1@github.com>
References: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
 <9i8bgPuEvIgu_6bnHdDVaGkRIDzycUd3Dwj4uBw0lyU=.98be11bf-e80c-48b7-9a7b-0704b3de60c1@github.com>
Message-ID: <ZrpxUiKqQJ3KZFneZmaXvqh-AdZDAoF64NHZjdNy17o=.61a74c54-f4d0-4c31-a98b-45de0c60354e@github.com>

On Wed, 21 May 2025 07:05:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Graphics copyArea overflow check bails out of copying pixels if there is overflow.
>> The spec says ""If a portion of the source rectangle lies outside the bounds of the component, or is obscured by another window or component, {@code copyArea} *will be unable to copy* the associated pixels"
>> 
>> which suggests that we should always copy the parts inside the bounds and never the parts outside the bounds
>> but it seems currently, in the case of overflow it no longer copies any pixels, including the parts that are inside. 
>> So, the fix clips the copyarea region to clip bounds so it will only affect pixels within the valid bounds, and any pixels outside will be ignored.
>
> src/java.desktop/share/native/libawt/java2d/loops/Blit.c line 77:
> 
>> 75:     srcInfo.bounds.x1 = srcx;
>> 76:     srcInfo.bounds.y1 = srcy;
>> 77:     if (UNSAFE_TO_ADD(srcx, width) ||
> 
> isn't the MaskBlit_MaskBlit use the same pattern?

But that doesn't cause any issue to the testcase given and existing testcase..Do you have any testcase which doesnt work because of MaskBlit pattern?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25340#discussion_r2099557371

From serb at openjdk.org  Wed May 21 07:35:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 21 May 2025 07:35:01 GMT
Subject: RFR: 8357299: Graphics copyArea doesn't copy any pixels when there
 is overflow
In-Reply-To: <ZrpxUiKqQJ3KZFneZmaXvqh-AdZDAoF64NHZjdNy17o=.61a74c54-f4d0-4c31-a98b-45de0c60354e@github.com>
References: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
 <9i8bgPuEvIgu_6bnHdDVaGkRIDzycUd3Dwj4uBw0lyU=.98be11bf-e80c-48b7-9a7b-0704b3de60c1@github.com>
 <ZrpxUiKqQJ3KZFneZmaXvqh-AdZDAoF64NHZjdNy17o=.61a74c54-f4d0-4c31-a98b-45de0c60354e@github.com>
Message-ID: <wLlvanWdUt0EngLAVznAyQN4mfki_pmb0NrTrWVwe1g=.fe14fe7a-78b7-4713-bd11-a84a391cc135@github.com>

On Wed, 21 May 2025 07:23:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/native/libawt/java2d/loops/Blit.c line 77:
>> 
>>> 75:     srcInfo.bounds.x1 = srcx;
>>> 76:     srcInfo.bounds.y1 = srcy;
>>> 77:     if (UNSAFE_TO_ADD(srcx, width) ||
>> 
>> isn't the MaskBlit_MaskBlit use the same pattern?
>
> But that doesn't cause any issue to the testcase given and existing testcase..Do you have any testcase which doesnt work because of MaskBlit pattern?

I have not tried to create a test for MaskBlit, only for a simple Blit. I will take a look at the possibility of reproducing it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25340#discussion_r2099573773

From psadhukhan at openjdk.org  Wed May 21 08:35:58 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 21 May 2025 08:35:58 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v2]
In-Reply-To: <dEc4B--MJdbczbZaAooTdznvOgwL-xMcBh6VCaMj-Hg=.6b121ad8-79c6-4b45-b529-e989477bf208@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <dEc4B--MJdbczbZaAooTdznvOgwL-xMcBh6VCaMj-Hg=.6b121ad8-79c6-4b45-b529-e989477bf208@github.com>
Message-ID: <4E77iDP7SuXUkZWoGilK72r3FJevFbABugEyzd9ZDGU=.6d0e3b19-0c82-43e6-a17c-2fc91137a9eb@github.com>

On Tue, 20 May 2025 04:34:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
>> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
>> Fixed by setting the divider location before rendering the left and right components..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Click position fixed..L&F iteration

setDividerLocation call is needed as when `BasicSplitPaneUI$BasicHorizontalLayoutManager.layoutContainer` is called to layout, it checks [`doReset ` and `dividerLocationIsSet` ](https://github.com/openjdk/jdk/blob/91194517c75a96fe7bcc2dcf5e9c42af9cf5975a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java#L1423-L1437)

Now, when `JSplitPane.setComponentOrientation `calls `setLeftComponent `it sets `doReset `to true (in `BasicSplitPaneUI.addLayoutComponent`) so `resetToPreferredSizes` is called when we open the dialog the 2nd time. so it causes this issue

Now if we call setDividerLocation it will set [dividerLocationIsSet](https://github.com/openjdk/jdk/blob/91194517c75a96fe7bcc2dcf5e9c42af9cf5975a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java#L1029) so even if `doReset `is true, it will not call `resetToPreferredSizes` but sets correct [divider location](https://github.com/openjdk/jdk/blob/91194517c75a96fe7bcc2dcf5e9c42af9cf5975a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java#L1436)

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

PR Comment: https://git.openjdk.org/jdk/pull/25294#issuecomment-2897083731

From aturbanov at openjdk.org  Wed May 21 08:43:03 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 21 May 2025 08:43:03 GMT
Subject: RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
Message-ID: <InWB-eEh49TDyxcZmRRDmzLkNaqz9wkZ1XWEcdePuQc=.53a8b65e-3a98-4e55-9e84-775c54988081@github.com>

On Wed, 16 Apr 2025 15:07:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`

Thank you for review.
Feel free to create a separate cleanup ticket to clarify code.

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

PR Comment: https://git.openjdk.org/jdk/pull/24692#issuecomment-2897100252

From aturbanov at openjdk.org  Wed May 21 08:43:03 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 21 May 2025 08:43:03 GMT
Subject: Integrated: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
Message-ID: <bwUD8rVEHgA2eq5ubFshiB2EnGWBONIxNIJGdvOq8OQ=.b766ed29-d2ee-4f93-99a5-d6b01116479f@github.com>

On Wed, 16 Apr 2025 15:07:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`

This pull request has now been integrated.

Changeset: a0cdf36b
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a0cdf36bdfeca9cd8b669859700d63d5ee627458
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8357224: Avoid redundant WeakHashMap.get in Toolkit.removeAWTEventListener

Reviewed-by: liach, aivanov, serb

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

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

From azvegint at openjdk.org  Wed May 21 08:55:52 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 21 May 2025 08:55:52 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v2]
In-Reply-To: <P5zqV_ciVE8ik4glssalJ2bil6zA5k1BI2sTXsR13GU=.716dd834-2d6b-4344-aade-8ec9eec91abf@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <XRQDe9qB8vtFFeCAbMRxRr5lB4vBCaFCAkDc9autvRc=.597810e7-8ce4-4879-bcf6-a4739273ccdf@github.com>
 <olpdq-aMj48h6bbL-WxYpJY-8iWjre32YpzZo87V68s=.b2330798-fb88-4662-9879-e9c5b9a1f8d7@github.com>
 <XyHPBRWF4NFCV_-QI8Jf_ctiVCLY2PMPGM2-E_DoPRM=.f7461854-264a-422c-81e1-d35cda43f303@github.com>
 <ovY_Iizjy6fx8bfvn2J1tI5QWihqFj2tW9mXwL36KRw=.6a7d5ce2-8958-4e64-a77a-c9f6cdfd821e@github.com>
 <P5zqV_ciVE8ik4glssalJ2bil6zA5k1BI2sTXsR13GU=.716dd834-2d6b-4344-aade-8ec9eec91abf@github.com>
Message-ID: <R-XM8vZw3V_D7CF3slaY-FlT5FClctQifyZ3DfdqE5Q=.e9f41b15-d36e-4eab-a850-8d19ee935413@github.com>

On Tue, 20 May 2025 10:33:21 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>>> I'm not sure if it's really needed, since many tests already depend on the `java.awt.Robot` itself, CI has a one-time manual task to set up all the required permissions for the `java.awt.Robot`, so automated tests provide sufficient coverage.
>> 
>> Can this be documented in [GUI testing](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements)?
>
>> > I'm not sure if it's really needed, since many tests already depend on the `java.awt.Robot` itself, CI has a one-time manual task to set up all the required permissions for the `java.awt.Robot`, so automated tests provide sufficient coverage.
>> 
>> Can this be documented in [GUI testing](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements)?
> 
> Sure, [updated](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements#AutomatedclientGUItestingsystemsetuprequirements-Wayland).

> @azvegint Generic question: While reading about libei, came across [Oeffis](https://libinput.pages.freedesktop.org/libei/api/index.html#sec-oeffis)- a wrapper for XDG portal. Is the reason to connect to Remote Desktop XDG portal directly because of session length and token alive time?

It is one of the points, the [current implementation](https://gitlab.freedesktop.org/libinput/libei/-/blob/main/src/liboeffis.c?ref_type=heads#L570) doesn't use `persist_mode` and `restore_token`. 

We are also using a single Remote Desktop session to also work with Screencast(the `SelectSources` call) to also get screenshots. However the oeffis dbus API wrapper doesn't allow that. 

In addition to adding the oeffis dependency to the JDK, we will also need to add  a [libei](https://libinput.pages.freedesktop.org/libei/api/group__libei-sender.html)  to make it work. We may want to add libei support at some point, but not now.

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

PR Comment: https://git.openjdk.org/jdk/pull/25265#issuecomment-2897146020

From duke at openjdk.org  Wed May 21 10:13:00 2025
From: duke at openjdk.org (duke)
Date: Wed, 21 May 2025 10:13:00 GMT
Subject: RFR: 8343618: Stack smashing in awt_InputMethod.c on Linux s390x
In-Reply-To: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
References: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
Message-ID: <5PU95Jawqz8NGYz2NPZkvTrQjHVzu8nCiJAdhbwKiGk=.95ae4db0-c920-4ca8-ade6-f91ae49068ec@github.com>

On Mon, 24 Mar 2025 13:41:44 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> This fixes stack smashing issue in awt library on linux s390x. (jdk compiled with `-fstack-protector-strong`)
> 
> Fix is based on patch [submitted](https://mail.openjdk.org/pipermail/awt-dev/2019-July/015337.html) in JDK-8227919 review thread, rebased to master. They decided to go for Solaris only fix there, with [expected follow-up](https://mail.openjdk.org/pipermail/awt-dev/2019-July/015347.html) for linux/s390x. But that never happened.
> 
> I was not able to get response from original author for this issue, so I am creating PR myself.
> 
> **Testing:**
> I tested jdk with and without this fix on linux/s390x (using Xvfb). It fixes the issue (reproducer for this bug no longer crashes the JVM). I have also tried to run `jdk_awt` tests, where lot of tests was also affected by this. With this patch amount of failures dropped by ~100. 
> 
> Without fix:
> 
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/jdk:jdk_awt                             2171  1063   415     6   687 <<
> 
> 
> With fix
> 
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/jdk:jdk_awt                             2171  1162   316     6   687 <<
> 
> 
> Many tests are no longer crashing the VM:
> 
> -java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java                                                      Failed. Unexpected exit from test [exit code: 134]
> +java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java                                                      Passed. Execution successful
> 
> There seem to be few unstable tests in jdk_awt. (Ones that fail in one or another run, but seem unrelated to this fix)
> 
> I have not done any additional manual testing of XIM as did original author (in review thread mentioned higher), as I am not at all familiar with input method for Japanese (or other Asian characters), or how that supposed to work. (So I cannot verify that input of Asian characters works as expected on linux/s390x, but at least JVM no longer crashes.)

@zzambers 
Your change (at version 21cf68276ed60c6b7c2a4f50ac448299db54d283) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24197#issuecomment-2897393789

From ngubarkov at openjdk.org  Wed May 21 11:16:46 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Wed, 21 May 2025 11:16:46 GMT
Subject: RFR: 8355904: Use variadic macros for J2dTrace [v3]
In-Reply-To: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
Message-ID: <L2Gga8Ao0zFDf1rkUXvcOKEpmcAZZss1eptyqfL9U7Y=.db6b35ea-4217-41a3-bc85-3dafa2584a5f@github.com>

> J2dTrace macros have multiple overloads specifying number of arguments, making it less convent to change number of arguments. There were cases when existing macros were not enough and people had to add new variants with even more arguments. We could simply use variadic macros instead.
> 
> Also, currently those macros expand to a { code block }, which doesn't require a semicolon at the end, so it can sometimes be missed, leading to an inconsistent code style. We could expand it directly to the function, forcing user to insert a semicolon after that, in a function-like style.

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

  Apply suggestions from code review
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24949/files
  - new: https://git.openjdk.org/jdk/pull/24949/files/867aee60..ad71f014

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24949&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24949&range=01-02

  Stats: 19 lines in 9 files changed: 2 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/24949.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24949/head:pull/24949

PR: https://git.openjdk.org/jdk/pull/24949

From aivanov at openjdk.org  Wed May 21 11:31:05 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 11:31:05 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v3]
In-Reply-To: <yK6F84YwKXulAJU1uTfAIC7s6yN7FrvUn0mdrpy8r2g=.c33503fa-541c-465e-b470-ddcc92f3587f@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <JVyEYDeaC2nRhod516RnecC9xDNUAlJXt0yz4I5xgvo=.a64851ce-c2f6-4e9d-bbdc-d6ad36626f56@github.com>
 <8icaCzTbIOcszrNmqCYdzqI4telSGl3bM-9afdXEWbE=.7c5be52b-eb9e-41e0-b655-5148f135d72c@github.com>
 <yK6F84YwKXulAJU1uTfAIC7s6yN7FrvUn0mdrpy8r2g=.c33503fa-541c-465e-b470-ddcc92f3587f@github.com>
Message-ID: <Y_UCstBWF-YCbbR28JVQQ_r7lPjalmeNV8kga-_ijBg=.83f8ef12-7057-4515-8c1b-2ca2c42c183b@github.com>

On Wed, 21 May 2025 06:39:47 GMT, Tejesh R <tr at openjdk.org> wrote:

> When I try to iterate the test for all L&F, the test result of first L&F is explicitly taken for other L&F too. Any idea why ?

Indeed, `PassFailJFrame` doesn't support repeating tests. It never was a scenario that we thought of. There are lots of static fields, including the latch that's used to wait for the test result. The instruction frame and list of windows are also static fields.

Supporting repeating tests such as in this scenario would require a substantial redesign of the internal structures? Everything should be an instance field instead, that instance could be stored in a static variable to support all the static methods provided. Redesigning the `PassFailJFrame` framework this way would take significant amount of time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100038079

From aivanov at openjdk.org  Wed May 21 11:49:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 11:49:55 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v3]
In-Reply-To: <Y_UCstBWF-YCbbR28JVQQ_r7lPjalmeNV8kga-_ijBg=.83f8ef12-7057-4515-8c1b-2ca2c42c183b@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <JVyEYDeaC2nRhod516RnecC9xDNUAlJXt0yz4I5xgvo=.a64851ce-c2f6-4e9d-bbdc-d6ad36626f56@github.com>
 <8icaCzTbIOcszrNmqCYdzqI4telSGl3bM-9afdXEWbE=.7c5be52b-eb9e-41e0-b655-5148f135d72c@github.com>
 <yK6F84YwKXulAJU1uTfAIC7s6yN7FrvUn0mdrpy8r2g=.c33503fa-541c-465e-b470-ddcc92f3587f@github.com>
 <Y_UCstBWF-YCbbR28JVQQ_r7lPjalmeNV8kga-_ijBg=.83f8ef12-7057-4515-8c1b-2ca2c42c183b@github.com>
Message-ID: <8std4x81X6gh2QeRqA41O0ww5Q1X6RC-IS8lyWxNm8g=.42c576aa-b904-430e-87a9-a2351e8b3e60@github.com>

On Wed, 21 May 2025 11:27:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > When I try to iterate the test for all L&F, the test result of first L&F is explicitly taken for other L&F too. Any idea why ?
> 
> Indeed, `PassFailJFrame` doesn't support repeating tests. It never was a scenario that we thought of. There are lots of static fields, including the latch that's used to wait for the test result. The instruction frame and list of windows are also static fields.
> 
> Supporting repeating tests such as in this scenario would require a substantial redesign of the internal structures? Everything should be an instance field instead, that instance could be stored in a static variable to support all the static methods provided. Redesigning the `PassFailJFrame` framework this way would take significant amount of time.

I submitted the following enhancements:

* [JDK-8357455](https://bugs.openjdk.org/browse/JDK-8357455): Support running multiple PassFailJFrame test cases in one process;
* [JDK-8357456](https://bugs.openjdk.org/browse/JDK-8357456): Ensure JFileChooser doesn't render file names as HTML in all L&Fs support.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100074287

From aivanov at openjdk.org  Wed May 21 12:03:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 12:03:56 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v3]
In-Reply-To: <8std4x81X6gh2QeRqA41O0ww5Q1X6RC-IS8lyWxNm8g=.42c576aa-b904-430e-87a9-a2351e8b3e60@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <JVyEYDeaC2nRhod516RnecC9xDNUAlJXt0yz4I5xgvo=.a64851ce-c2f6-4e9d-bbdc-d6ad36626f56@github.com>
 <8icaCzTbIOcszrNmqCYdzqI4telSGl3bM-9afdXEWbE=.7c5be52b-eb9e-41e0-b655-5148f135d72c@github.com>
 <yK6F84YwKXulAJU1uTfAIC7s6yN7FrvUn0mdrpy8r2g=.c33503fa-541c-465e-b470-ddcc92f3587f@github.com>
 <Y_UCstBWF-YCbbR28JVQQ_r7lPjalmeNV8kga-_ijBg=.83f8ef12-7057-4515-8c1b-2ca2c42c183b@github.com>
 <8std4x81X6gh2QeRqA41O0ww5Q1X6RC-IS8lyWxNm8g=.42c576aa-b904-430e-87a9-a2351e8b3e60@github.com>
Message-ID: <IZVljMLDk0gCCbEzEmsYI13JiILF8XXyrtiL2gzMWlM=.d6c8080d-e714-4426-b0fd-09b24784306b@github.com>

On Wed, 21 May 2025 11:46:50 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> When I try to iterate the test for all L&F, the test result of first L&F is explicitly taken for other L&F too. Any idea why ?
>> 
>> Indeed, `PassFailJFrame` doesn't support repeating tests. It never was a scenario that we thought of. There are lots of static fields, including the latch that's used to wait for the test result. The instruction frame and list of windows are also static fields.
>> 
>> Supporting repeating tests such as in this scenario would require a substantial redesign of the internal structures? Everything should be an instance field instead, that instance could be stored in a static variable to support all the static methods provided. Redesigning the `PassFailJFrame` framework this way would take significant amount of time.
>
>> > When I try to iterate the test for all L&F, the test result of first L&F is explicitly taken for other L&F too. Any idea why ?
>> 
>> Indeed, `PassFailJFrame` doesn't support repeating tests. It never was a scenario that we thought of. There are lots of static fields, including the latch that's used to wait for the test result. The instruction frame and list of windows are also static fields.
>> 
>> Supporting repeating tests such as in this scenario would require a substantial redesign of the internal structures? Everything should be an instance field instead, that instance could be stored in a static variable to support all the static methods provided. Redesigning the `PassFailJFrame` framework this way would take significant amount of time.
> 
> I submitted the following enhancements:
> 
> * [JDK-8357455](https://bugs.openjdk.org/browse/JDK-8357455): Support running multiple PassFailJFrame test cases in one process;
> * [JDK-8357456](https://bugs.openjdk.org/browse/JDK-8357456): Ensure JFileChooser doesn't render file names as HTML in all L&Fs support.

As a workaround, I suggest testing Metal, the default L&F, and the system L&F on the platforms.

This can be achieved by having two sets of jtreg test tags:


/*
 * @test id=metal
 * @bug 8139228
 * @summary JFileChooser should not render Directory names in HTML format
 * @library /java/awt/regtesthelpers
 * @build PassFailJFrame
 * @run main/manual HTMLFileName metal
 */

/*
 * @test id=system
 * @bug 8139228
 * @summary JFileChooser should not render Directory names in HTML format
 * @library /java/awt/regtesthelpers
 * @build PassFailJFrame
 * @run main/manual HTMLFileName system
 */


Then add the following to your `main` method:


    public static void main(String[] args) throws Exception {
        if (args.length < 1) {
            throw new IllegalArgumentException("Look-and-Feel keyword is required");
        }

        final String lafClassName;
        switch (args[0]) {
            case "metal" -> lafClassName = UIManager.getCrossPlatformLookAndFeelClassName();
            case "system" -> lafClassName = UIManager.getSystemLookAndFeelClassName();
            default -> throw new IllegalArgumentException("Unsupported Look-and-Feel keyword: " + args[0]);
        }

        SwingUtilities.invokeAndWait(() -> {
            try {
                UIManager.setLookAndFeel(lafClassName);
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
        });

        PassFailJFrame.builder()
                // other configuration
                .awaitAndCheck();


I tested it, and it works perfectly on Windows.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100110185

From ngubarkov at openjdk.org  Wed May 21 12:06:42 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Wed, 21 May 2025 12:06:42 GMT
Subject: RFR: 8355904: Use variadic macros for J2dTrace [v4]
In-Reply-To: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
Message-ID: <8P-UBCr62SByYXXXOZon1xrUILk7D5SQIE7JLDu4Gqc=.4249bf75-3942-4ba2-8488-38c7e8f9131d@github.com>

> J2dTrace macros have multiple overloads specifying number of arguments, making it less convent to change number of arguments. There were cases when existing macros were not enough and people had to add new variants with even more arguments. We could simply use variadic macros instead.
> 
> Also, currently those macros expand to a { code block }, which doesn't require a semicolon at the end, so it can sometimes be missed, leading to an inconsistent code style. We could expand it directly to the function, forcing user to insert a semicolon after that, in a function-like style.

Nikita Gubarkov has updated the pull request incrementally with two additional commits since the last revision:

 - fixup! 8355904: Use variadic macros for J2dTrace
 - fixup! 8355904: Use variadic macros for J2dTrace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24949/files
  - new: https://git.openjdk.org/jdk/pull/24949/files/ad71f014..df5781f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24949&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24949&range=02-03

  Stats: 670 lines in 64 files changed: 63 ins; 4 del; 603 mod
  Patch: https://git.openjdk.org/jdk/pull/24949.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24949/head:pull/24949

PR: https://git.openjdk.org/jdk/pull/24949

From aivanov at openjdk.org  Wed May 21 12:08:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 12:08:59 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v3]
In-Reply-To: <JVyEYDeaC2nRhod516RnecC9xDNUAlJXt0yz4I5xgvo=.a64851ce-c2f6-4e9d-bbdc-d6ad36626f56@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <JVyEYDeaC2nRhod516RnecC9xDNUAlJXt0yz4I5xgvo=.a64851ce-c2f6-4e9d-bbdc-d6ad36626f56@github.com>
Message-ID: <GWPFrIXKFIcb4sBJb2fMScckR8NtuxUiCNquVyIU98U=.36f4d9ee-4777-4a36-afd9-908b784be764@github.com>

On Mon, 19 May 2025 13:52:16 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The rendering of the directory names are handled as JLabel w.r.t Look and feel and also either Details/List view. Though FilePane creates basic rendering for these two few Look and Feel define their own renderers and also ComboBox Directory directory name view. Since HTML filtering is not taken care in any of these renderers, JLabel renders them as HTML document if nothing is set or specified.
>> The fix is to get "html.disable" property from JFileChooser and set the same to JLabel component which renders and set Directory name. Hence applications can either enable/disable this property and control HTML rendering of directory name.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 43:

> 41: 
> 42:     public static void main(String[] args) throws Exception {
> 43:         String INSTRUCTIONS = """

Please make `INSTRUCTIONS` a `private static final` field at the top of the class. This is the most common way in tests, and it'll make the `main` method cleaner especially after adding additional logic for switching Look-and-Feels as I [suggested in a discussion thread](https://github.com/openjdk/jdk/pull/24439#discussion_r2100110185).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100116456

From aivanov at openjdk.org  Wed May 21 12:09:02 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 12:09:02 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v3]
In-Reply-To: <8icaCzTbIOcszrNmqCYdzqI4telSGl3bM-9afdXEWbE=.7c5be52b-eb9e-41e0-b655-5148f135d72c@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <JVyEYDeaC2nRhod516RnecC9xDNUAlJXt0yz4I5xgvo=.a64851ce-c2f6-4e9d-bbdc-d6ad36626f56@github.com>
 <8icaCzTbIOcszrNmqCYdzqI4telSGl3bM-9afdXEWbE=.7c5be52b-eb9e-41e0-b655-5148f135d72c@github.com>
Message-ID: <ZshfrOL5XDcLWMt6nfLjhaurK_H_hfqa9ARQoI8dT2E=.49decca5-183d-4b39-b66a-26480e4eaf28@github.com>

On Tue, 20 May 2025 18:48:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 51:
> 
>> 49:                          ComboBox remains in plain text, then test PASS.
>> 50:                          If it appears to be in HTML format with Pink color,
>> 51:                          then test FAILS.
> 
> Suggestion:
> 
>                          ComboBox remains in plain text, then test passes.
>                          If it appears to be in HTML format with Pink color,
>                          then test fails.
> 
> You could be more specific: _?click **Fail**?_ if a condition isn't met. (Otherwise, continue with the test.) End the instructions with _?click **Pass**?_.
> 
> Anyway, the instructions are pretty clear as they are, so real change is required.

You may want to switch to HTML-formatted instructions to alleviate differences in the default fonts in different L&Fs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100119989

From aivanov at openjdk.org  Wed May 21 12:13:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 12:13:55 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v4]
In-Reply-To: <nNtrFxzT76IHQVWYa0BhbruAi_IoSXWA3MtPbf7mv2g=.c6b88e91-c07e-4f3d-ba70-7b8e03b02f9f@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
 <nNtrFxzT76IHQVWYa0BhbruAi_IoSXWA3MtPbf7mv2g=.c6b88e91-c07e-4f3d-ba70-7b8e03b02f9f@github.com>
Message-ID: <xmeqwOokZFAP-2LID_4dlMMssQct4ZPEQPT0oRIWUmA=.d3a226f1-2b1a-4862-922c-0b29dd8f0f44@github.com>

On Wed, 21 May 2025 04:36:38 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
>> Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.
>> 
>> Verified the updated test in CI on macOS 14.7 machine and there is no failure.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Looks good to me except for a few nits.

test/jdk/java/awt/List/ListEnterExitTest.java line 49:

> 47:     Frame frame;
> 48:     volatile Point p;
> 49:     private static final int X_OFFSET = 30;

Suggestion:

    volatile Point p;

    private static final int X_OFFSET = 30;

I'd add a blank line between these two blocks.

test/jdk/java/awt/List/ListEnterExitTest.java line 113:

> 111: 
> 112:     private class MouseEnterExitListener extends MouseAdapter {
> 113:         public void mouseEntered(MouseEvent e) {

Suggestion:

    private class MouseEnterExitListener extends MouseAdapter {
        @Override
        public void mouseEntered(MouseEvent e) {

test/jdk/java/awt/List/ListEnterExitTest.java line 118:

> 116:         }
> 117: 
> 118:         public void mouseExited(MouseEvent e) {

Suggestion:

        @Override
        public void mouseExited(MouseEvent e) {

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25299#pullrequestreview-2857464612
PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2100129084
PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2100125431
PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2100127395

From abhiscxk at openjdk.org  Wed May 21 12:21:32 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 21 May 2025 12:21:32 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v5]
In-Reply-To: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
Message-ID: <Rvkq8Q6MTdHix83SzKqoT7asvvKls4EWuGmxGHW6h-w=.28cca30c-5456-41d9-aad5-dce4ab2cae48@github.com>

> Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
> Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.
> 
> Verified the updated test in CI on macOS 14.7 machine and there is no failure.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  minor fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25299/files
  - new: https://git.openjdk.org/jdk/pull/25299/files/4275fd95..2ea05dfe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25299&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25299&range=03-04

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25299.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25299/head:pull/25299

PR: https://git.openjdk.org/jdk/pull/25299

From aivanov at openjdk.org  Wed May 21 12:21:32 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 12:21:32 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v3]
In-Reply-To: <F3aFJC7rNSrkk-T-ilHkOam94ToCZ4X1lB3jstwGra4=.4059d79c-da2a-465f-a265-ac72fc5c6fb8@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
 <hxqp5b9_-Ok5rUQcGmmjO9tfksC-ID0bnc_fGgkCUb4=.aa648c7b-9535-4359-9a96-67cdcef425ba@github.com>
 <n9_LaEFp_l_hhlLV0JNMXzQfRY0Wj9bBtUhC2a11fnw=.1cd68a24-f97d-4c2e-8d4a-1ec9eb783919@github.com>
 <F3aFJC7rNSrkk-T-ilHkOam94ToCZ4X1lB3jstwGra4=.4059d79c-da2a-465f-a265-ac72fc5c6fb8@github.com>
Message-ID: <Cyx88ER4B1SsZt9yZfg5Kq6872n45Ihr1yqkhdD5UmY=.05341efb-373b-4513-98f7-d5963241dbb1@github.com>

On Wed, 21 May 2025 04:36:11 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> > Did you have a chance to reproduce this bug and see how it works? When I run it on my laptop I can see the mouse moving out and in of the list and clicking inside of it, but for some reason the events are not sent.
> 
> I couldn't reproduce it on my system (macOS 15.4.1). @jayathirthrao was able to reproduce it on macOS 14.7.5 and the behaviour was same i.e. mouse is moving in and out and clicking inside but **mouse exit event is not triggered**.

I wonder if this system reproduces other bugs where expected events aren't received? such as `java/awt/event/KeyEvent/FunctionKeyTest.java` ([JDK-8343104](https://bugs.openjdk.org/browse/JDK-8343104)) and `java/awt/List/ItemEventTest/ItemEventTest.java` ([JDK-8204221](https://bugs.openjdk.org/browse/JDK-8204221)).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25299#issuecomment-2897737976

From abhiscxk at openjdk.org  Wed May 21 12:21:32 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 21 May 2025 12:21:32 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v4]
In-Reply-To: <xmeqwOokZFAP-2LID_4dlMMssQct4ZPEQPT0oRIWUmA=.d3a226f1-2b1a-4862-922c-0b29dd8f0f44@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
 <nNtrFxzT76IHQVWYa0BhbruAi_IoSXWA3MtPbf7mv2g=.c6b88e91-c07e-4f3d-ba70-7b8e03b02f9f@github.com>
 <xmeqwOokZFAP-2LID_4dlMMssQct4ZPEQPT0oRIWUmA=.d3a226f1-2b1a-4862-922c-0b29dd8f0f44@github.com>
Message-ID: <6q4HsgHsPntpKgYoaqBo3syw--wrsBGaLpgbY_lvgTw=.ede6cd2e-8e68-45be-8fde-ce46bfba9724@github.com>

On Wed, 21 May 2025 12:09:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fix
>
> test/jdk/java/awt/List/ListEnterExitTest.java line 113:
> 
>> 111: 
>> 112:     private class MouseEnterExitListener extends MouseAdapter {
>> 113:         public void mouseEntered(MouseEvent e) {
> 
> Suggestion:
> 
>     private class MouseEnterExitListener extends MouseAdapter {
>         @Override
>         public void mouseEntered(MouseEvent e) {

Updated

> test/jdk/java/awt/List/ListEnterExitTest.java line 118:
> 
>> 116:         }
>> 117: 
>> 118:         public void mouseExited(MouseEvent e) {
> 
> Suggestion:
> 
>         @Override
>         public void mouseExited(MouseEvent e) {

Updated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2100143184
PR Review Comment: https://git.openjdk.org/jdk/pull/25299#discussion_r2100143048

From aivanov at openjdk.org  Wed May 21 12:26:51 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 12:26:51 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v5]
In-Reply-To: <Rvkq8Q6MTdHix83SzKqoT7asvvKls4EWuGmxGHW6h-w=.28cca30c-5456-41d9-aad5-dce4ab2cae48@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
 <Rvkq8Q6MTdHix83SzKqoT7asvvKls4EWuGmxGHW6h-w=.28cca30c-5456-41d9-aad5-dce4ab2cae48@github.com>
Message-ID: <Qxb1zi0Cfz8_MIcYo2VtKuOkY1tYGUlyttPXNo_Ju5U=.f26ca1c4-20f1-4636-b95b-7983a93f15ee@github.com>

On Wed, 21 May 2025 12:21:32 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
>> Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.
>> 
>> Verified the updated test in CI on macOS 14.7 machine and there is no failure.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor fix

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25299#pullrequestreview-2857509857

From ngubarkov at openjdk.org  Wed May 21 12:33:40 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Wed, 21 May 2025 12:33:40 GMT
Subject: RFR: 8355904: Use variadic macros for J2dTrace [v5]
In-Reply-To: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
Message-ID: <BWWuwKtEvZFmcq-x0ApZ2lfuABe0hz0EvmYn-rnl63w=.0d49cda1-a111-42b0-b795-3153628d2d8f@github.com>

> J2dTrace macros have multiple overloads specifying number of arguments, making it less convent to change number of arguments. There were cases when existing macros were not enough and people had to add new variants with even more arguments. We could simply use variadic macros instead.
> 
> Also, currently those macros expand to a { code block }, which doesn't require a semicolon at the end, so it can sometimes be missed, leading to an inconsistent code style. We could expand it directly to the function, forcing user to insert a semicolon after that, in a function-like style.

Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:

  fixup! 8355904: Use variadic macros for J2dTrace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24949/files
  - new: https://git.openjdk.org/jdk/pull/24949/files/df5781f7..98ec5087

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24949&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24949&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24949.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24949/head:pull/24949

PR: https://git.openjdk.org/jdk/pull/24949

From aivanov at openjdk.org  Wed May 21 12:41:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 12:41:57 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine [v3]
In-Reply-To: <c2FRmUEOKhK0i4Mm1dHqdCyu5aCY6cMGE-xQFzSujmQ=.9a13234c-e073-4c12-946f-0d7d77d5f190@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
 <c2FRmUEOKhK0i4Mm1dHqdCyu5aCY6cMGE-xQFzSujmQ=.9a13234c-e073-4c12-946f-0d7d77d5f190@github.com>
Message-ID: <gNu4OYdhFU3e-dXz0cy9CCvZlW3HaZ63jQSb424o--E=.e5cd28ce-ca3d-4814-a09e-ba14e4913029@github.com>

On Mon, 19 May 2025 05:37:05 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Unfortunately I'm unable to reproduce this failure. I slowed the test down; it passes on my machine before and after this PR.
>> 
>> I added a little bit of logging that might also help identify what's happening.
>> 
>> Does anyone have any more suggestions?
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356061: removing robot
>   
>   This is in response to:
>   https://github.com/openjdk/jdk/pull/25244#issuecomment-2889420453

> > Is it possible that the button hovered by mouse looks the same way as the default one?
> 
> That's the big question this unit test is trying to answer. (So: I'm not sure.)
> 
> > Did the original test move the mouse before getting pixel color of a button?
> 
> Yes.
>
> If that was the problem: all we needed to do is delete this call to `robot.mouseMove`.

So, the mouse cursor hovered over the button? which could essentially make a non-default button look the same way as the default button? because it's hovered.

I don't have a Mac to test it right away, but on Windows the default button has a brighter border and a slightly bluish background; hovering over any button gives it the same border and a blue background.

> (But even so: I think the cursor on Mac is black -- so why would we detect a gray 0x373737 ?)

The cursor isn't always captured?

---

> > It may also be worth pointing out: this test has never failed. It was added as an extra precaution, but not because it demonstrated a fix for anything. I would not miss it if we delete it; I don't think it deserves the time spent discussing/refactoring it.
>
> Just deleting robot.mouseMove(x, y) might also resolve the issue seen in our test environment.

Yeah, likely removing `mouseMove` would resolve the failure.

> But the current refactoring using BufferedImage is better than using Robot and deleting mouseMove() call.

It's always better, in my opinion? I just wonder whether this test has any value. But I haven't looked thoroughly enough into either of the fixes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25244#issuecomment-2897823434

From mvs at openjdk.org  Wed May 21 13:20:28 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 21 May 2025 13:20:28 GMT
Subject: RFR: 8341370: Test
 java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails
 intermittently on macOS-aarch64
Message-ID: <BHAutQbvJdvqeYgVWy9bdtDxVJCcVebFPNvAaZMPyHI=.9e80138c-6024-436c-ba6b-70a380a475db@github.com>

ShapeNotSetSometimes.java fails intermittently with a RuntimeException on macOS-aarch64
Test threw exception: java.lang.RuntimeException: Test failed. The shape has not been applied.

Fix:
The test has been modified to take a screenshot of the area and then analyse the pixel color in the screenshot rather than getting individual pixels from the screen for each test.
Also the timeout of the test has been increased to 5 minutes(300 seconds) as sometimes it times out with the default timeout of 2 minutes(120 seconds).

Testing:
After fixing the test, it has been run 40 times per platform(Windows, Linux, MacOS x64 and MacOS aarch64) using Mach5 and got 100% pass rate .

-------------

Commit messages:
 - 8341370: Test java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails intermittently on macOS-aarch64

Changes: https://git.openjdk.org/jdk/pull/25354/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25354&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341370
  Stats: 14 lines in 2 files changed: 3 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25354/head:pull/25354

PR: https://git.openjdk.org/jdk/pull/25354

From prr at openjdk.org  Wed May 21 15:30:52 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 21 May 2025 15:30:52 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v3]
In-Reply-To: <q-jAcupHO9xmaafZinbFmnYuoYs4fzHMAjiNtfldNx4=.8e1fb82b-a181-4610-9557-8c5be252e58e@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <q-jAcupHO9xmaafZinbFmnYuoYs4fzHMAjiNtfldNx4=.8e1fb82b-a181-4610-9557-8c5be252e58e@github.com>
Message-ID: <QR-SilMY84q0nA5HcVryyb7IHoSAIqpUBmU3fp0BgcQ=.721b1902-f108-497c-b45f-188874e6ec96@github.com>

On Mon, 19 May 2025 23:06:39 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The issue is the inability to move the mouse cursor using `java.awt.Robot` on Oracle Linux 10 (which has not yet been released). FIY, the OL10 is no longer provides an Xorg session, so only Wayland is available.
>> It is a JCK conformance failure. 
>> 
>> ---
>> 
>> In our robot implementation, we emulate mouse/keyboard actions using the XTEST extension protocol.
>> 
>> The XTEST calls are now wired to [libEI](https://libinput.pages.freedesktop.org/libei/api/index.html):
>> 
>> 1.
>> 
>> It now asks for a user confirmation to allow interaction, so we should now be able to click on native applications, window titles, etc.
>> 
>> However, our robot implementation is mostly uses XTEST, but there is an exception:
>> for mouse move we use XWarpPointer, which is not part of the XTEST, thus it is not propagated outside of Xwayland server.
>> 
>> So we have a situation where mouse is moving only inside Xwayland server, and we see the mouse enter/exit events,
>> on mouse press we call XTestFakeButtonEvent and it is handled by libei,
>> so the click happens where is the actual mouse cursor is in the system. That is why the test fails.
>> 
>> To avoid this situation we should use XTestFakeMotionEvent for mouseMove in Xwayland case.
>> 
>> It would be a simple solution, but
>> 
>> 
>> 2.
>> 
>> This permission granted by a user doesn't persist across reboots, it timeouts after a period of inactivity.
>> 
>> It still seems to conform to the specifications, but we will not be able to conveniently run automated tests in this case.
>> 
>> ---
>> 
>> So as a solution we can switch the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
>> It has session and `restore_token` functionality to keep permissions granted by a user, similar to what we use in a [Screencast](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html) for taking screenshots.
>> Most of the code can be reused, and it has everything we need.
>> 
>> 
>> * It is only enabled by default on Wayland and Gnome Shell 47 and higher due to XTEST API complications that first arose in this version. For earlier versions, Screencast is used instead.
>> * A new value has been introduced for the `awt.robot.screenshotMethod` system property - `dbusRemoteDesktop`. It works on Ubuntu 24.04 with Gnome 46, but is not enabled by default.
>> * extra mouse buttons are not supported yet, [JDK-8357142](https://bugs.openjdk.org/browse/JDK-8357142)
>> * Since w...
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   call OpenPipeWireRemote even for remote desktop session calls

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25265#pullrequestreview-2858213254

From tr at openjdk.org  Wed May 21 16:00:12 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 21 May 2025 16:00:12 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v4]
In-Reply-To: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
Message-ID: <MZ4qxb0APA2o_r3OJ21MNa1hmmcS3ApThNHjKW43vjg=.8d42dd5d-9f46-4676-8cbc-6b6d23acfa34@github.com>

> The rendering of the directory names are handled as JLabel w.r.t Look and feel and also either Details/List view. Though FilePane creates basic rendering for these two few Look and Feel define their own renderers and also ComboBox Directory directory name view. Since HTML filtering is not taken care in any of these renderers, JLabel renders them as HTML document if nothing is set or specified.
> The fix is to get "html.disable" property from JFileChooser and set the same to JLabel component which renders and set Directory name. Hence applications can either enable/disable this property and control HTML rendering of directory name.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24439/files
  - new: https://git.openjdk.org/jdk/pull/24439/files/d4660c75..4f8c759a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24439&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24439&range=02-03

  Stats: 72 lines in 1 file changed: 42 ins; 11 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24439.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24439/head:pull/24439

PR: https://git.openjdk.org/jdk/pull/24439

From tr at openjdk.org  Wed May 21 16:00:13 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 21 May 2025 16:00:13 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v3]
In-Reply-To: <ZshfrOL5XDcLWMt6nfLjhaurK_H_hfqa9ARQoI8dT2E=.49decca5-183d-4b39-b66a-26480e4eaf28@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <JVyEYDeaC2nRhod516RnecC9xDNUAlJXt0yz4I5xgvo=.a64851ce-c2f6-4e9d-bbdc-d6ad36626f56@github.com>
 <8icaCzTbIOcszrNmqCYdzqI4telSGl3bM-9afdXEWbE=.7c5be52b-eb9e-41e0-b655-5148f135d72c@github.com>
 <ZshfrOL5XDcLWMt6nfLjhaurK_H_hfqa9ARQoI8dT2E=.49decca5-183d-4b39-b66a-26480e4eaf28@github.com>
Message-ID: <RU2IO1w2LAZ8O3AxseaznyXKM5O5erdybYfXdTX2nlc=.0c127e7d-c5d1-409e-85ba-2ac921476ecb@github.com>

On Wed, 21 May 2025 12:06:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 51:
>> 
>>> 49:                          ComboBox remains in plain text, then test PASS.
>>> 50:                          If it appears to be in HTML format with Pink color,
>>> 51:                          then test FAILS.
>> 
>> Suggestion:
>> 
>>                          ComboBox remains in plain text, then test passes.
>>                          If it appears to be in HTML format with Pink color,
>>                          then test fails.
>> 
>> You could be more specific: _?click **Fail**?_ if a condition isn't met. (Otherwise, continue with the test.) End the instructions with _?click **Pass**?_.
>> 
>> Anyway, the instructions are pretty clear as they are, so real change is required.
>
> You may want to switch to HTML-formatted instructions to alleviate differences in the default fonts in different L&Fs.

Why would we need HTML-formatted instructions btw ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100649064

From tr at openjdk.org  Wed May 21 16:00:14 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 21 May 2025 16:00:14 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v3]
In-Reply-To: <IZVljMLDk0gCCbEzEmsYI13JiILF8XXyrtiL2gzMWlM=.d6c8080d-e714-4426-b0fd-09b24784306b@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <JVyEYDeaC2nRhod516RnecC9xDNUAlJXt0yz4I5xgvo=.a64851ce-c2f6-4e9d-bbdc-d6ad36626f56@github.com>
 <8icaCzTbIOcszrNmqCYdzqI4telSGl3bM-9afdXEWbE=.7c5be52b-eb9e-41e0-b655-5148f135d72c@github.com>
 <yK6F84YwKXulAJU1uTfAIC7s6yN7FrvUn0mdrpy8r2g=.c33503fa-541c-465e-b470-ddcc92f3587f@github.com>
 <Y_UCstBWF-YCbbR28JVQQ_r7lPjalmeNV8kga-_ijBg=.83f8ef12-7057-4515-8c1b-2ca2c42c183b@github.com>
 <8std4x81X6gh2QeRqA41O0ww5Q1X6RC-IS8lyWxNm8g=.42c576aa-b904-430e-87a9-a2351e8b3e60@github.com>
 <IZVljMLDk0gCCbEzEmsYI13JiILF8XXyrtiL2gzMWlM=.d6c8080d-e714-4426-b0fd-09b24784306b@github.com>
Message-ID: <kIoFTyPVdwc2_pcjl0-tMbGhfAh59vEE_hSP2zeBRyA=.964b8f10-7222-46a9-b050-b2ad107580fe@github.com>

On Wed, 21 May 2025 12:00:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> > When I try to iterate the test for all L&F, the test result of first L&F is explicitly taken for other L&F too. Any idea why ?
>>> 
>>> Indeed, `PassFailJFrame` doesn't support repeating tests. It never was a scenario that we thought of. There are lots of static fields, including the latch that's used to wait for the test result. The instruction frame and list of windows are also static fields.
>>> 
>>> Supporting repeating tests such as in this scenario would require a substantial redesign of the internal structures? Everything should be an instance field instead, that instance could be stored in a static variable to support all the static methods provided. Redesigning the `PassFailJFrame` framework this way would take significant amount of time.
>> 
>> I submitted the following enhancements:
>> 
>> * [JDK-8357455](https://bugs.openjdk.org/browse/JDK-8357455): Support running multiple PassFailJFrame test cases in one process;
>> * [JDK-8357456](https://bugs.openjdk.org/browse/JDK-8357456): Ensure JFileChooser doesn't render file names as HTML in all L&Fs support.
>
> As a workaround, I suggest testing Metal, the default L&F, and the system L&F on the platforms.
> 
> This can be achieved by having two sets of jtreg test tags:
> 
> 
> /*
>  * @test id=metal
>  * @bug 8139228
>  * @summary JFileChooser should not render Directory names in HTML format
>  * @library /java/awt/regtesthelpers
>  * @build PassFailJFrame
>  * @run main/manual HTMLFileName metal
>  */
> 
> /*
>  * @test id=system
>  * @bug 8139228
>  * @summary JFileChooser should not render Directory names in HTML format
>  * @library /java/awt/regtesthelpers
>  * @build PassFailJFrame
>  * @run main/manual HTMLFileName system
>  */
> 
> 
> Then add the following to your `main` method:
> 
> 
>     public static void main(String[] args) throws Exception {
>         if (args.length < 1) {
>             throw new IllegalArgumentException("Look-and-Feel keyword is required");
>         }
> 
>         final String lafClassName;
>         switch (args[0]) {
>             case "metal" -> lafClassName = UIManager.getCrossPlatformLookAndFeelClassName();
>             case "system" -> lafClassName = UIManager.getSystemLookAndFeelClassName();
>             default -> throw new IllegalArgumentException("Unsupported Look-and-Feel keyword: " + args[0]);
>         }
> 
>         SwingUtilities.invokeAndWait(() -> {
>             try {
>                 UIManager.setLookAndFeel(lafClassName);
>             } catch (Exception e) {
>                 throw new RuntimeException(e);
>             }
>         });
> 
>         PassFailJFrame.builder()
>                 // other configuration
>                 .awaitAndCheck();
> 
> 
> I tested it, and it works perfectly on Windows.

Yes, its working on windows too. Thank you. I have updated the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100646531

From tr at openjdk.org  Wed May 21 16:00:13 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 21 May 2025 16:00:13 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v3]
In-Reply-To: <8icaCzTbIOcszrNmqCYdzqI4telSGl3bM-9afdXEWbE=.7c5be52b-eb9e-41e0-b655-5148f135d72c@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <JVyEYDeaC2nRhod516RnecC9xDNUAlJXt0yz4I5xgvo=.a64851ce-c2f6-4e9d-bbdc-d6ad36626f56@github.com>
 <8icaCzTbIOcszrNmqCYdzqI4telSGl3bM-9afdXEWbE=.7c5be52b-eb9e-41e0-b655-5148f135d72c@github.com>
Message-ID: <HOjLGCGM8m6ZyJwLjjXxo_UMZrWcd1Vp_xXf9sNHpXs=.2962932d-2e83-488a-a623-30bbde845d74@github.com>

On Tue, 20 May 2025 18:40:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 29:
> 
>> 27: import javax.swing.filechooser.FileSystemView;
>> 28: import java.io.File;
>> 29: import java.util.List;
> 
> Suggestion:
> 
> import java.io.File;
> import java.util.List;
> import javax.swing.Icon;
> import javax.swing.JFileChooser;
> import javax.swing.JFrame;
> import javax.swing.filechooser.FileSystemView;
> 
> We haven't reached an agreement, yet `java.*` packages usually go before `javax.*` packages in the list of imports.

Updated.

> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 43:
> 
>> 41: 
>> 42:     public static void main(String[] args) throws Exception {
>> 43:         String INSTRUCTIONS = """
> 
> Please make `INSTRUCTIONS` a `private static final` field at the top of the class. This is the most common way in tests, and it'll make the `main` method cleaner especially after adding additional logic for switching Look-and-Feels as I [suggested in a discussion thread](https://github.com/openjdk/jdk/pull/24439#discussion_r2100110185).

Updated.

> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 45:
> 
>> 43:         String INSTRUCTIONS = """
>> 44:                 1. FileChooser shows up a virtual directory and file with name
>> 45:                    "<html><h1 color=#ff00ff><font face="Comic Sans MS">Testing Name".
> 
> The file name is now `Swing Rocks!`

Updated.

> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 60:
> 
>> 58:                          If it appears to be in plain text, then test FAILS.
>> 59:                          (Verify for all Look and Feel).
>> 60:                  """;
> 
> Suggestion:
> 
>                 """;
> 
> Avoid trailing space, it's not needed.

Updated.

> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 85:
> 
>> 83:         frame.pack();
>> 84:         return frame;
>> 85:     }
> 
> Suggestion:
> 
>     private static JFrame createFileChooser(boolean htmlEnabled) {
>         JFileChooser jfc = new JFileChooser(new VirtualFileSystemView());
>         jfc.putClientProperty("html.disable", htmlEnabled);
>         jfc.setControlButtonsAreShown(false);
> 
>         JFrame frame = new JFrame((htmlEnabled) ? "HTML enabled" : "HTML disabled");
>         frame.add(jfc);
>         frame.pack();
>         return frame;
>     }
> 
> I think this way is cleaner: create the file chooser, configure it?; then create the frame, put the file chooser into the frame.
> 
> `html_enabled` ? `htmlEnabled`, which aligns to the Java style.
> 
> ? I added `jfc.setControlButtonsAreShown(false)` to hide the *Open* and *Cancel* buttons.

Updated.

> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 96:
> 
>> 94:         public File[] getRoots() {
>> 95:             return new File[]{
>> 96:                     new File("/", "<html><h1 color=#ff00ff><font face=\"Comic Sans MS\">SWING ROCKS!!!111"),
> 
> Suggestion:
> 
>                     new File("/", "<html><h1 color=#ff00ff><font face="Comic Sans MS">Swing Rocks!"),
> 
> Use title case?

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100650539
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100649554
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100653203
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100644786
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100652050
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100646865

From aivanov at openjdk.org  Wed May 21 16:18:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 16:18:53 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v4]
In-Reply-To: <LKyt1Cg7AqQCm3CWdH76oJA7elvrXG7Hb8_waYST914=.c69fe092-a249-4c9b-bf83-33d0d091d4c4@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <LKyt1Cg7AqQCm3CWdH76oJA7elvrXG7Hb8_waYST914=.c69fe092-a249-4c9b-bf83-33d0d091d4c4@github.com>
Message-ID: <XuVp9M2NCJivKAjJhJBDIXy0Byz1at_ROLwx8rVFpdg=.d68421b3-6429-471f-b0c2-7f20d2a4341f@github.com>

On Wed, 21 May 2025 03:00:15 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
>> 
>> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed : Formatting changes,cosmetic changes,PassFailJFrame changes, etc

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JMenuItem/MenuItemTest/bug4729669.java line 34:

> 32: 
> 33: import javax.swing.JFrame;
> 34: import java.util.List;

Suggestion:

import java.util.List;
import javax.swing.JFrame;

Be consistent at least in a single changeset.

Although it wasn't agreed upon, the most common style is `java.*` packages go first followed by `javax.*` packages.

test/jdk/javax/swing/JMenuItem/MenuItemTest/bug4729669.java line 60:

> 58:         JFrame f2 = MenuItemTestHelper.getMenuItemTestFrame(false);
> 59:         f2.setLocation(500, 300);
> 60:         return List.of(f1, f2);

Suggestion:

        JFrame f1 = MenuItemTestHelper.getMenuItemTestFrame(true);
        JFrame f2 = MenuItemTestHelper.getMenuItemTestFrame(false);
        return List.of(f1, f2);

Remove `setLocation`, the `PassFailJFrame` framework fully handles the positioning of the windows.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25319#pullrequestreview-2858062350
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2100519744
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2100515611

From aivanov at openjdk.org  Wed May 21 16:18:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 16:18:56 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v2]
In-Reply-To: <Up0J1fq1aI_x-78TvT1Zti9UuDg7viR6TOETEEfO3qQ=.fd4d6984-9f47-4280-a80c-b77653c1311c@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <8raDo3FpSvhKD-OA21EHbKEYVEejYB4qtUipeGVNvJw=.b6f7a74f-392a-4541-82d1-b9301123f03b@github.com>
 <Up0J1fq1aI_x-78TvT1Zti9UuDg7viR6TOETEEfO3qQ=.fd4d6984-9f47-4280-a80c-b77653c1311c@github.com>
Message-ID: <9v_f6HbDb95d3TAqSNPF_14KDXoxJhmQi_cdlheIsf0=.8e9553e8-3f66-44a4-bbc4-55129b6ee394@github.com>

On Tue, 20 May 2025 17:07:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fixed : Rearranged and reused code by creating a new Helper MenuItemTestHelper.java
>
> test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 53:
> 
>> 51:             } catch (Exception e) {
>> 52:                 e.printStackTrace();
>> 53:             }
> 
> I wonder if we should actually wrap the exception into `RuntimeException` and let it propagate to fail the test. I think we should; if Look and Feel wasn't set as expected, the test won't test that part of the functionality.

I'm for propagating the exception if setting L&F fails.

> test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 100:
> 
>> 98:         frame.setSize(300, 300);
>> 99:         frame.setLocation(isLeft ? 0 : 600, frameY);
>> 100:         frame.setVisible(true);
> 
> `setLocation` shouldn't be need if you use `PassFailJFrame` layouts for positioning. Then `frameY` becomes redundant.
> 
> `setVisible(true)` isn't need either.

Drop `setLocation` and `setVisible` as well as `frameY` parameter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2100508682
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2100510915

From aivanov at openjdk.org  Wed May 21 16:31:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 16:31:58 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v3]
In-Reply-To: <Jkcf9PT4djTDOsR3dC-apeE1--0K_59n0cbtbGKqZxs=.c77a8534-e038-4911-b1fc-59723b608f7f@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <Jkcf9PT4djTDOsR3dC-apeE1--0K_59n0cbtbGKqZxs=.c77a8534-e038-4911-b1fc-59723b608f7f@github.com>
Message-ID: <q3vNR7vx4Mjdz0arW3cOZrgFQevk2lvLKQGLIx6kMl8=.4b513f34-4dd8-4a5b-b95c-0214cc660dcb@github.com>

On Tue, 20 May 2025 22:09:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> Update the some code examples and accompanying images to no longer mention or display as applets.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357176

I still have some minor nits.

src/java.desktop/share/classes/java/awt/BorderLayout.java line 102:

> 100:  * The code for this program is as follows:
> 101:  *
> 102:  * <hr>

Suggestion:


Drop the horizontal line. It separates the code from the paragraph that introduces it.

src/java.desktop/share/classes/java/awt/BorderLayout.java line 115:

> 113:  *     EventQueue.invokeAndWait(() -> {
> 114:  *        Frame frame = new Frame("BorderLayout");
> 115:  *        frame.setLayout(new BorderLayout());

Suggestion:

 * public class BorderLayoutExample {
 *
 *     public static void main(String[] args) throws Exception {
 *         EventQueue.invokeAndWait(() -> {
 *             Frame frame = new Frame("BorderLayout");
 *             frame.setLayout(new BorderLayout());

I suggest following the standard indentation of 4 spaces to align with the recommended Java code style and dropping the blank line inside the `main` method.

Is there any particular reason for using `invokeAndWait` instead of `invokeLater`? Most Java UI tutorials use `invokeLater`.

(In the tests, we have to use `invokeAndWait`.)

src/java.desktop/share/classes/java/awt/FlowLayout.java line 63:

> 61:  * Here is the code for this program:
> 62:  *
> 63:  * <hr>

Suggestion:


I suggest dropping the horizontal line from all the sample code.

src/java.desktop/share/classes/java/awt/FlowLayout.java line 64:

> 62:  *
> 63:  * <hr>
> 64:  * {@snippet  lang='java':

Suggestion:

 * {@snippet lang='java':

Not really an issue, however, other instances have just one space.

src/java.desktop/share/classes/java/awt/FlowLayout.java line 75:

> 73:  *
> 74:  *     EventQueue.invokeAndWait(() -> {
> 75:  *        Frame frame = new Frame("FlowLayout");

The same comment: let's follow the standard Java code style and indent blocks by 4 spaces.

Here, the `main` method declaration and `EventQueue.invokeAndWait` are indented by 2 spaces, but the body of the lambda expression is indented by 4 spaces. This is inconsistent.

src/java.desktop/share/classes/java/awt/GridBagLayout.java line 279:

> 277:  * Here is the code that implements the example shown above:
> 278:  *
> 279:  * <hr>

Suggestion:

src/java.desktop/share/classes/java/awt/GridBagLayout.java line 287:

> 285:  * import java.awt.GridBagLayout;
> 286:  *
> 287:  * public class GridBagLayoutExample {

This sample indents each code block by 4 spaces, which is good.

src/java.desktop/share/classes/java/awt/GridLayout.java line 40:

> 38:  * <hr>
> 39:  * {@snippet lang='java':
> 40:  * <pre>

Suggestion:

 * {@snippet lang='java':

`<pre>` is inside the sample code.

src/java.desktop/share/classes/java/awt/GridLayout.java line 51:

> 49:  *
> 50:  *     EventQueue.invokeAndWait(() -> {
> 51:  *        Frame frame = new Frame("GridLayout");

Let's indent the code by 4 spaces.

I'm also for removing the blank line that starts the `main` method.

src/java.desktop/share/classes/java/awt/MediaTracker.java line 70:

> 68:  * Here is an example of using {@code MediaTracker}:
> 69:  *
> 70:  * <hr>

Suggestion:

src/java.desktop/share/classes/java/awt/MediaTracker.java line 117:

> 115:  *          animator = new Thread(this);
> 116:  *          animator.start();
> 117:  *     }

Suggestion:

 *      }

Correct the indentation.

-------------

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25278#pullrequestreview-2858047334
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2100501264
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2100498882
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2100697034
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2100714553
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2100701896
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2100705020
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2100707123
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2100683735
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2100712282
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2100712613
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2100718917

From aivanov at openjdk.org  Wed May 21 16:31:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 16:31:59 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v2]
In-Reply-To: <sxhxknLCvcHCTm22sZOk6ACvFA7qWk1Ihs46Pg7MmP0=.5f9e5a33-554b-4cf5-a240-316f4e963e90@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <gfibyrL20Gfyy_gFKpgIHZwSFkrqA5qn7ylb78VnI4w=.f809d3bd-f1ac-4e53-b98b-eb49dd952630@github.com>
 <Wv2DHkaM6ALImqwqG13lu71Wdn9eOaPSM21SHSbwURk=.bbc1280f-1b7c-4d91-bf74-cf3660f530b8@github.com>
 <sxhxknLCvcHCTm22sZOk6ACvFA7qWk1Ihs46Pg7MmP0=.5f9e5a33-554b-4cf5-a240-316f4e963e90@github.com>
Message-ID: <Koux9laNR_JrUHKvxyunPQTG4qV7tfixZAIHeuF_RRI=.b2b2f748-f42f-41c9-a980-59c448a242ce@github.com>

On Tue, 20 May 2025 21:56:28 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/GridLayout.java line 50:
>> 
>>> 48:  *
>>> 49:  *     EventQueue.invokeAndWait(() -> {
>>> 50:  *        Frame frame = new Frame("GridLayout");
>> 
>> I would like to bring this to the discussion not necessarily suggesting any changes. I noticed that the example uses a "frame", while the description above refers to a "window" it might be worth unification. Also, regarding invokeAndWait: it?s not strictly necessary here since this is AWT but it does not break anything. However, I wonder if it?s worth discussing the use of invokeAndWait vs invokeLater. In tests, we usually prefer invokeAndWait because we need to wait for the action to complete, but in applications invokeLater should work fine.
>
> A Frame (the java class) creates a window (the desktop concept). I would not want to promote the java type Frame to mean the concept.
> Regarding invokeAndWait vs invokeLater, either is fine in this case and main has nothing else to do whilst waiting and is the safest default.
> I pondered whether to do either in this simple case, but we do generally these days recommend this pattern even for AWT as Swing classes may be used to implement AWT .. and if I did not I guarantee someone would have said I should use it ! Whether or not it matters in this case.

I'm in favour of using `invokeLater` (or `invokeAndWait`) even for AWT components.

AWT doesn't explicitly declares its threading model. It's safer to create UI on EDT either way?it'll work for both AWT and Swing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2100689626

From aivanov at openjdk.org  Wed May 21 16:41:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 16:41:55 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v3]
In-Reply-To: <Jkcf9PT4djTDOsR3dC-apeE1--0K_59n0cbtbGKqZxs=.c77a8534-e038-4911-b1fc-59723b608f7f@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <Jkcf9PT4djTDOsR3dC-apeE1--0K_59n0cbtbGKqZxs=.c77a8534-e038-4911-b1fc-59723b608f7f@github.com>
Message-ID: <1Bh6NPTX85YzDUj_R6mvUesZRor88gGcmbnwgKiid3A=.dd93b454-9ee0-4b8a-874b-8be24829a590@github.com>

On Tue, 20 May 2025 22:09:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> Update the some code examples and accompanying images to no longer mention or display as applets.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357176

src/java.desktop/share/classes/java/awt/BorderLayout.java line 98:

> 96:  * demonstrating BorderLayout. Each section of the BorderLayout contains a
> 97:  * Button corresponding to its position in the layout, one of: North, West,
> 98:  * Center, East, or South." style="margin: 7px 10px;">

I'd drop this `style` attribute, too.

src/java.desktop/share/classes/java/awt/FlowLayout.java line 59:

> 57:  * <img src="doc-files/FlowLayout-1.png"
> 58:  * ALT="Graphic of Layout for Three Buttons"
> 59:  * style="margin: 7px 10px;">

I'd drop this `style` attribute. It indents the image by 10 pixels to the right so that it doesn't align to the left edge of the surrounding text.

I see no value in increasing the vertical margins by 7px. Each paragraph has already 14px top/bottom margins.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2100738012
PR Review Comment: https://git.openjdk.org/jdk/pull/25278#discussion_r2100737154

From aivanov at openjdk.org  Wed May 21 16:50:01 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 16:50:01 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v4]
In-Reply-To: <MZ4qxb0APA2o_r3OJ21MNa1hmmcS3ApThNHjKW43vjg=.8d42dd5d-9f46-4676-8cbc-6b6d23acfa34@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <MZ4qxb0APA2o_r3OJ21MNa1hmmcS3ApThNHjKW43vjg=.8d42dd5d-9f46-4676-8cbc-6b6d23acfa34@github.com>
Message-ID: <JepKp3SCjDVdjl5uOmhuaNgRjRpRGfRSMP-qu0DUjNk=.1009d38b-01ed-4799-b7a2-fc1bc5724997@github.com>

On Wed, 21 May 2025 16:00:12 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The rendering of the directory names are handled as JLabel w.r.t Look and feel and also either Details/List view. Though FilePane creates basic rendering for these two few Look and Feel define their own renderers and also ComboBox Directory directory name view. Since HTML filtering is not taken care in any of these renderers, JLabel renders them as HTML document if nothing is set or specified.
>> The fix is to get "html.disable" property from JFileChooser and set the same to JLabel component which renders and set Directory name. Hence applications can either enable/disable this property and control HTML rendering of directory name.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated review comments

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 61:

> 59:                      If it appears to be in HTML format with Pink color,
> 60:                      then test fails.
> 61:                      (Verify for all Look and Feel).

There's no way for the tester to verify all Look and Feels, unless they go out of their way and launch the test manually with different look and feels.

For this reason, I'd remove this line altogether.

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 110:

> 108:         jfc.putClientProperty("html.disable", htmlEnabled);
> 109:         jfc.setControlButtonsAreShown(false);
> 110:         JFrame frame = new JFrame((htmlEnabled) ? "HTML enabled" : "HTML disabled");

Suggestion:

        jfc.setControlButtonsAreShown(false);

        JFrame frame = new JFrame((htmlEnabled) ? "HTML enabled" : "HTML disabled");

It's better with a blank line that separates the two blocks of code.

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 126:

> 124:             return new File[]{
> 125:                     new File("/", "<html><h1 color=#ff00ff><font " +
> 126:                             "face=\"Comic Sans MS\">Swing Rocks!!!!111"),

Suggestion:

                            "face="Comic Sans MS">Swing Rocks!"),

Update this too.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24439#pullrequestreview-2858481116
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100751517
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100748073
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2100748940

From honkar at openjdk.org  Wed May 21 17:09:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 21 May 2025 17:09:53 GMT
Subject: RFR: 8357287: Unify usage of ICC profile "header size" constants
 in CMM-related code
In-Reply-To: <E0IDBFGhxM-z1VwcY4cYSCVXbu93tKcm5qnx_M3nWJ8=.475bec53-4c98-4ba3-accc-0613e0b8eb0f@github.com>
References: <E0IDBFGhxM-z1VwcY4cYSCVXbu93tKcm5qnx_M3nWJ8=.475bec53-4c98-4ba3-accc-0613e0b8eb0f@github.com>
Message-ID: <hvSEPqYQgil4aven3dAQcCzEBnfPh6aHxbRtDRGu_MM=.05a9f766-e377-43b7-b338-2d85547603de@github.com>

On Tue, 20 May 2025 00:37:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Small unification of "header size" constants, as of now the CMM code uses:
> 1. sun.java2d.cmm.ProfileDataVerifier.HEADER_SIZE introduced in JDK-8013430
> 2. java.awt.color.ICC_Profile.HEADER_SIZE introduced in [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377)
> 3. Hardcoded literal 128

LGTM

src/java.desktop/share/classes/sun/java2d/cmm/ProfileDataVerifier.java line 111:

> 109:     public static final int HEADER_SIZE = 128;
> 110:     private static final int TOC_OFFSET = HEADER_SIZE + 4;
> 111:     private static final int TOC_RECORD_SIZE = 12;

Minor: All the constants are defined at the end of file, is it better to move them to the beginning ?

-------------

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25313#pullrequestreview-2858535241
PR Review Comment: https://git.openjdk.org/jdk/pull/25313#discussion_r2100782673

From mvs at openjdk.org  Wed May 21 17:16:18 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 21 May 2025 17:16:18 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v5]
In-Reply-To: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
Message-ID: <7QIJEGqmDtHo-IfhvZoFs-EgVbBiER8lBxMCwlh29UE=.684a8d37-0227-4808-ac9e-a40374126210@github.com>

> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
> 
> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed : Removed unwanted code, location of imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25319/files
  - new: https://git.openjdk.org/jdk/pull/25319/files/22b05bbd..996bc9e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25319&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25319&range=03-04

  Stats: 17 lines in 3 files changed: 1 ins; 9 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25319/head:pull/25319

PR: https://git.openjdk.org/jdk/pull/25319

From mvs at openjdk.org  Wed May 21 17:23:18 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 21 May 2025 17:23:18 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v2]
In-Reply-To: <SCAD8dMpd69FpFc1S2A_0-A-XVIMPrgea9xo3ZO54xM=.c8e175a7-b7d0-4a06-9a93-5ec631680f70@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <8raDo3FpSvhKD-OA21EHbKEYVEejYB4qtUipeGVNvJw=.b6f7a74f-392a-4541-82d1-b9301123f03b@github.com>
 <Up0J1fq1aI_x-78TvT1Zti9UuDg7viR6TOETEEfO3qQ=.fd4d6984-9f47-4280-a80c-b77653c1311c@github.com>
 <SCAD8dMpd69FpFc1S2A_0-A-XVIMPrgea9xo3ZO54xM=.c8e175a7-b7d0-4a06-9a93-5ec631680f70@github.com>
Message-ID: <Bp2O8svOmSwReXHB2nNd67WWT2feO4oyIurg3vu4bTc=.f3e9d8b5-fe14-4623-b035-428bb445dcc1@github.com>

On Tue, 20 May 2025 19:18:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 43:
>> 
>>> 41: import javax.swing.UIManager;
>>> 42: 
>>> 43: class MenuItemTestHelper {
>> 
>> I would've kept `MenuItemTest` as the name of the class. It's fine either way.
>> 
>> I'd also mark this class as `final`. It may be `public` or be left with the default access.
>
> However, `-Helper` could be better ? the name of the class clearly indicates that this class is not _a test_ but a helper class.

Added final modifier

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2100806967

From mvs at openjdk.org  Wed May 21 17:23:17 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 21 May 2025 17:23:17 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v6]
In-Reply-To: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
Message-ID: <UNCxoczmrdt-jHUUD69VxCKuZZisODLTyTjhY6hyiXk=.d430d350-68a9-4238-ae0d-57710761e1ab@github.com>

> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
> 
> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Added final modifier to the class MenuItemTestHelper

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25319/files
  - new: https://git.openjdk.org/jdk/pull/25319/files/996bc9e3..b04155cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25319&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25319&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25319/head:pull/25319

PR: https://git.openjdk.org/jdk/pull/25319

From azvegint at openjdk.org  Wed May 21 17:24:08 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 21 May 2025 17:24:08 GMT
Subject: RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place [v3]
In-Reply-To: <ZhMSFfwTTnEAQBVcr_RcVnLoL4lekFWIowGgADV8a4s=.b9f310f7-73dc-4cca-80c5-88447312aa46@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
 <q-jAcupHO9xmaafZinbFmnYuoYs4fzHMAjiNtfldNx4=.8e1fb82b-a181-4610-9557-8c5be252e58e@github.com>
 <ZhMSFfwTTnEAQBVcr_RcVnLoL4lekFWIowGgADV8a4s=.b9f310f7-73dc-4cca-80c5-88447312aa46@github.com>
Message-ID: <qgxLyG1W2QpeI8NVa8okypcS4MTfyGaLZPb5Y-ZBQik=.f62a49ad-f002-4728-9d32-b143411feedf@github.com>

On Tue, 20 May 2025 23:35:27 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   call OpenPipeWireRemote even for remote desktop session calls
>
> src/java.desktop/unix/classes/sun/awt/screencast/XdgDesktopPortal.java line 65:
> 
>> 63:         }
>> 64: 
>> 65:         String m = System.getProperty("awt.robot.screenshotMethod", defaultMethod);
> 
> Do we allow user to set `awt.robot.screenshotMethod` to `dbusScreencast/dbusRemoteDesktop` on x11 sessions and to `x11` on wayland session?
> 
> Although all 3 methods work on both x11 & wayland sessions in Ubuntu.

We don't say anything about it. If the user wants to, why not? 
However, it won't be a priority if there are issues.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25265#discussion_r2100807570

From azvegint at openjdk.org  Wed May 21 17:24:10 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 21 May 2025 17:24:10 GMT
Subject: Integrated: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered
 to wrong place
In-Reply-To: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
References: <IeN9zSCYBQAG8hYkI5uWRfjMPlCqS9hN-GoW_-Cf4FA=.141025b7-edbe-4b4b-984c-3c2185069689@github.com>
Message-ID: <NyoCsdAeaImQIbTygJN_xiapxyaEE84ZCgyMhj8-lrY=.381feebc-bf05-4eb6-81f4-c02f1bcf96d0@github.com>

On Fri, 16 May 2025 10:40:22 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The issue is the inability to move the mouse cursor using `java.awt.Robot` on Oracle Linux 10 (which has not yet been released). FIY, the OL10 is no longer provides an Xorg session, so only Wayland is available.
> It is a JCK conformance failure. 
> 
> ---
> 
> In our robot implementation, we emulate mouse/keyboard actions using the XTEST extension protocol.
> 
> The XTEST calls are now wired to [libEI](https://libinput.pages.freedesktop.org/libei/api/index.html):
> 
> 1.
> 
> It now asks for a user confirmation to allow interaction, so we should now be able to click on native applications, window titles, etc.
> 
> However, our robot implementation is mostly uses XTEST, but there is an exception:
> for mouse move we use XWarpPointer, which is not part of the XTEST, thus it is not propagated outside of Xwayland server.
> 
> So we have a situation where mouse is moving only inside Xwayland server, and we see the mouse enter/exit events,
> on mouse press we call XTestFakeButtonEvent and it is handled by libei,
> so the click happens where is the actual mouse cursor is in the system. That is why the test fails.
> 
> To avoid this situation we should use XTestFakeMotionEvent for mouseMove in Xwayland case.
> 
> It would be a simple solution, but
> 
> 
> 2.
> 
> This permission granted by a user doesn't persist across reboots, it timeouts after a period of inactivity.
> 
> It still seems to conform to the specifications, but we will not be able to conveniently run automated tests in this case.
> 
> ---
> 
> So as a solution we can switch the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
> It has session and `restore_token` functionality to keep permissions granted by a user, similar to what we use in a [Screencast](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html) for taking screenshots.
> Most of the code can be reused, and it has everything we need.
> 
> 
> * It is only enabled by default on Wayland and Gnome Shell 47 and higher due to XTEST API complications that first arose in this version. For earlier versions, Screencast is used instead.
> * A new value has been introduced for the `awt.robot.screenshotMethod` system property - `dbusRemoteDesktop`. It works on Ubuntu 24.04 with Gnome 46, but is not enabled by default.
> * extra mouse buttons are not supported yet, [JDK-8357142](https://bugs.openjdk.org/browse/JDK-8357142)
> * Since we are now moving the mouse using a non-X11 API and `MouseInfo.getPointerInfo().getLo...

This pull request has now been integrated.

Changeset: 2dfbf41d
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2dfbf41d2a3dbcd44f9ed9a58a1b0932d7536977
Stats:     938 lines in 13 files changed: 801 ins; 51 del; 86 mod

8351907: [XWayland] [OL10] Robot.mousePress() is delivered to wrong place

Reviewed-by: honkar, prr

-------------

PR: https://git.openjdk.org/jdk/pull/25265

From prr at openjdk.org  Wed May 21 17:34:22 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 21 May 2025 17:34:22 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v4]
In-Reply-To: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
Message-ID: <okYE19v_u7IqG1-ElaDWPfUcDZQ4s5eWQ6iuyraFM6Y=.2575d60a-74e2-488f-9708-913f73ea099b@github.com>

> Update the some code examples and accompanying images to no longer mention or display as applets.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8357176

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25278/files
  - new: https://git.openjdk.org/jdk/pull/25278/files/21f4cba1..42242c34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25278&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25278&range=02-03

  Stats: 52 lines in 5 files changed: 0 ins; 10 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/25278.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25278/head:pull/25278

PR: https://git.openjdk.org/jdk/pull/25278

From prr at openjdk.org  Wed May 21 17:34:22 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 21 May 2025 17:34:22 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v3]
In-Reply-To: <Jkcf9PT4djTDOsR3dC-apeE1--0K_59n0cbtbGKqZxs=.c77a8534-e038-4911-b1fc-59723b608f7f@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <Jkcf9PT4djTDOsR3dC-apeE1--0K_59n0cbtbGKqZxs=.c77a8534-e038-4911-b1fc-59723b608f7f@github.com>
Message-ID: <5wO4R1vro09BN4I-6vszV0wUlYrq-k1MTdboSRCwW1Y=.2925c88f-86fe-4889-9ba7-a9abd073551b@github.com>

On Tue, 20 May 2025 22:09:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> Update the some code examples and accompanying images to no longer mention or display as applets.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357176

I think I have addressed all the "nits"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25278#issuecomment-2898724994

From serb at openjdk.org  Wed May 21 19:01:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 21 May 2025 19:01:03 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v3]
In-Reply-To: <yeN2JsnYSouAc8n9ryuH-Qaq3fUMv0r8R3CVP-XHDTg=.98800227-b2d9-4d80-b025-fd72b7b31aef@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <Jkcf9PT4djTDOsR3dC-apeE1--0K_59n0cbtbGKqZxs=.c77a8534-e038-4911-b1fc-59723b608f7f@github.com>
 <yeN2JsnYSouAc8n9ryuH-Qaq3fUMv0r8R3CVP-XHDTg=.98800227-b2d9-4d80-b025-fd72b7b31aef@github.com>
Message-ID: <WF9T6MF47BrXKU1h-1v-Ci01R3BklWSm7theS-PNI3k=.fd9987d9-303a-4278-b261-63f63ef97078@github.com>

On Tue, 20 May 2025 23:09:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Ok .. here's uploaded javadoc to view
> 
> > ```
> >  // The background image fills the frame so we
> >  // don't need to clear the applet on repaints.
> >  // Just call the paint method.
> >  public void update(Graphics g) {
> >      paint(g);
> >  }
> > ```
> 
> https://cr.openjdk.org/~prr/8357176/api/java.desktop/java/awt/MediaTracker.html

this reference to applet still exists.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25278#issuecomment-2898930522

From serb at openjdk.org  Wed May 21 19:01:04 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 21 May 2025 19:01:04 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v4]
In-Reply-To: <okYE19v_u7IqG1-ElaDWPfUcDZQ4s5eWQ6iuyraFM6Y=.2575d60a-74e2-488f-9708-913f73ea099b@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <okYE19v_u7IqG1-ElaDWPfUcDZQ4s5eWQ6iuyraFM6Y=.2575d60a-74e2-488f-9708-913f73ea099b@github.com>
Message-ID: <Ub75HIftlLhN5-iO83gMn0Jxms-ISHsWs8CXcL95UQE=.52fa343b-4360-4b4b-8e15-e3baaaf8a265@github.com>

On Wed, 21 May 2025 17:34:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> Update the some code examples and accompanying images to no longer mention or display as applets.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357176

btw maybe it is better to present these layouts using swing(and its components)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25278#issuecomment-2898934515

From aivanov at openjdk.org  Wed May 21 19:30:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 19:30:53 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v4]
In-Reply-To: <okYE19v_u7IqG1-ElaDWPfUcDZQ4s5eWQ6iuyraFM6Y=.2575d60a-74e2-488f-9708-913f73ea099b@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <okYE19v_u7IqG1-ElaDWPfUcDZQ4s5eWQ6iuyraFM6Y=.2575d60a-74e2-488f-9708-913f73ea099b@github.com>
Message-ID: <9vnDwgAYAetNOy8Tp3JbQ0R4yWT8b4flHo7rB5MKpBQ=.99e80ffc-f68c-4c10-ad08-c8fdfa6b4ae9@github.com>

On Wed, 21 May 2025 17:34:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> Update the some code examples and accompanying images to no longer mention or display as applets.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357176

It looks good to me.

Sergey's comment hasn't been resolved: `MediaTracker.java` still references *applets* in the code sample at line 148:

https://github.com/openjdk/jdk/blob/42242c34ddc0aeb7f97954e956bb2644f83beac2/src/java.desktop/share/classes/java/awt/MediaTracker.java#L147-L150

-------------

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25278#pullrequestreview-2858894330

From aivanov at openjdk.org  Wed May 21 19:46:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 19:46:55 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v3]
In-Reply-To: <RU2IO1w2LAZ8O3AxseaznyXKM5O5erdybYfXdTX2nlc=.0c127e7d-c5d1-409e-85ba-2ac921476ecb@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <JVyEYDeaC2nRhod516RnecC9xDNUAlJXt0yz4I5xgvo=.a64851ce-c2f6-4e9d-bbdc-d6ad36626f56@github.com>
 <8icaCzTbIOcszrNmqCYdzqI4telSGl3bM-9afdXEWbE=.7c5be52b-eb9e-41e0-b655-5148f135d72c@github.com>
 <ZshfrOL5XDcLWMt6nfLjhaurK_H_hfqa9ARQoI8dT2E=.49decca5-183d-4b39-b66a-26480e4eaf28@github.com>
 <RU2IO1w2LAZ8O3AxseaznyXKM5O5erdybYfXdTX2nlc=.0c127e7d-c5d1-409e-85ba-2ac921476ecb@github.com>
Message-ID: <q3EMNgG5RL1qv0uyexiYtZUY3BZAJgeADAF_X81Cu0g=.0af59826-8485-4e31-ad4b-41e6a1e8449a@github.com>

On Wed, 21 May 2025 15:56:49 GMT, Tejesh R <tr at openjdk.org> wrote:

> Why would we need HTML-formatted instructions btw ?

Because the instructions are really hard to read in Windows L&F (because of the monospace font):

![HTMLFileName Instructions in Windows L&F: the text doesn't fit nicely in the window and gets wrapped](https://github.com/user-attachments/assets/ecd39482-e448-4436-96e5-8d6b96c888d9)

The image isn't clear, but you get the idea: all the text gets wrapped, so it's hard to keep track of the instructions. Anyway, I'm fine with it.

Harshitha had [a similar problem](https://github.com/openjdk/jdk/pull/24456#discussion_r2054468745), and she switched to [using HTML formatting](https://github.com/openjdk/jdk/pull/24456#discussion_r2054516242) which works reliably across different OS.

You can check [`JFileChooser/bug4943900.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JFileChooser/bug4943900.java) on how it looks and works in different OS.

https://github.com/openjdk/jdk/blob/81536830ed096005c4f09ab446238ce50989cea9/test/jdk/javax/swing/JFileChooser/bug4943900.java#L40-L47

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2101040424

From prr at openjdk.org  Wed May 21 20:21:54 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 21 May 2025 20:21:54 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v5]
In-Reply-To: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
Message-ID: <DEIpf0BK_yfxezmyfs_YqR5N478EtJyRODQhvKVUC0E=.4f3026e8-6f6f-4142-8302-43e22bff2ab5@github.com>

> Update the some code examples and accompanying images to no longer mention or display as applets.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8357176

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25278/files
  - new: https://git.openjdk.org/jdk/pull/25278/files/42242c34..9104493a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25278&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25278&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25278.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25278/head:pull/25278

PR: https://git.openjdk.org/jdk/pull/25278

From aivanov at openjdk.org  Wed May 21 20:21:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 May 2025 20:21:54 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v5]
In-Reply-To: <DEIpf0BK_yfxezmyfs_YqR5N478EtJyRODQhvKVUC0E=.4f3026e8-6f6f-4142-8302-43e22bff2ab5@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <DEIpf0BK_yfxezmyfs_YqR5N478EtJyRODQhvKVUC0E=.4f3026e8-6f6f-4142-8302-43e22bff2ab5@github.com>
Message-ID: <EwQuSPRjawteWfgbnw_Ma4GrHpQb0grvZtZf6Y5BBdg=.b7d49cfe-eaa9-405b-8042-199f3fe733c7@github.com>

On Wed, 21 May 2025 20:18:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> Update the some code examples and accompanying images to no longer mention or display as applets.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357176

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25278#pullrequestreview-2859003270

From prr at openjdk.org  Wed May 21 20:21:56 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 21 May 2025 20:21:56 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v3]
In-Reply-To: <WF9T6MF47BrXKU1h-1v-Ci01R3BklWSm7theS-PNI3k=.fd9987d9-303a-4278-b261-63f63ef97078@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <Jkcf9PT4djTDOsR3dC-apeE1--0K_59n0cbtbGKqZxs=.c77a8534-e038-4911-b1fc-59723b608f7f@github.com>
 <yeN2JsnYSouAc8n9ryuH-Qaq3fUMv0r8R3CVP-XHDTg=.98800227-b2d9-4d80-b025-fd72b7b31aef@github.com>
 <WF9T6MF47BrXKU1h-1v-Ci01R3BklWSm7theS-PNI3k=.fd9987d9-303a-4278-b261-63f63ef97078@github.com>
Message-ID: <rAMk_pRNsVi8eQ541LYqNOVY3XjIAayuA_eI_zvJobw=.cc51dee5-4a61-4a29-b68f-a9c1fac6ff7a@github.com>

On Wed, 21 May 2025 18:56:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > > Ok .. here's uploaded javadoc to view
> > 
> > 
> > > ```
> > >  // The background image fills the frame so we
> > >  // don't need to clear the applet on repaints.
> > >  // Just call the paint method.
> > >  public void update(Graphics g) {
> > >      paint(g);
> > >  }
> > > ```
> > 
> > 
> > https://cr.openjdk.org/~prr/8357176/api/java.desktop/java/awt/MediaTracker.html
> 
> this reference to applet still exists.

oops. I missed what that comment was about

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25278#issuecomment-2899120305

From prr at openjdk.org  Wed May 21 20:21:57 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 21 May 2025 20:21:57 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v4]
In-Reply-To: <okYE19v_u7IqG1-ElaDWPfUcDZQ4s5eWQ6iuyraFM6Y=.2575d60a-74e2-488f-9708-913f73ea099b@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <okYE19v_u7IqG1-ElaDWPfUcDZQ4s5eWQ6iuyraFM6Y=.2575d60a-74e2-488f-9708-913f73ea099b@github.com>
Message-ID: <bSYgJVpKCybEqVCibxAp7sY5a0NCvylyQRi6Rx8iCb4=.8b9cf6ac-0949-4598-b228-35153829a548@github.com>

On Wed, 21 May 2025 17:34:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> Update the some code examples and accompanying images to no longer mention or display as applets.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357176

> btw maybe it is better to present these layouts using swing(and its components)?



> btw maybe it is better to present these layouts using swing(and its components)?

This is in the AWT package so I think AWT components is better.
And the goal is just to get rid of the applet mentions and I've now done that (after the last one)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25278#issuecomment-2899125757

From serb at openjdk.org  Wed May 21 20:23:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 21 May 2025 20:23:56 GMT
Subject: RFR: 8357287: Unify usage of ICC profile "header size" constants
 in CMM-related code
In-Reply-To: <hvSEPqYQgil4aven3dAQcCzEBnfPh6aHxbRtDRGu_MM=.05a9f766-e377-43b7-b338-2d85547603de@github.com>
References: <E0IDBFGhxM-z1VwcY4cYSCVXbu93tKcm5qnx_M3nWJ8=.475bec53-4c98-4ba3-accc-0613e0b8eb0f@github.com>
 <hvSEPqYQgil4aven3dAQcCzEBnfPh6aHxbRtDRGu_MM=.05a9f766-e377-43b7-b338-2d85547603de@github.com>
Message-ID: <nwDklSAqumbmmaIV1V_gXWN_rWkIWAS0ichlYNWGAec=.d9c4396b-2274-44e5-9e15-7b1fc150db50@github.com>

On Wed, 21 May 2025 17:06:00 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Small unification of "header size" constants, as of now the CMM code uses:
>> 1. sun.java2d.cmm.ProfileDataVerifier.HEADER_SIZE introduced in JDK-8013430
>> 2. java.awt.color.ICC_Profile.HEADER_SIZE introduced in [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377)
>> 3. Hardcoded literal 128
>
> src/java.desktop/share/classes/sun/java2d/cmm/ProfileDataVerifier.java line 111:
> 
>> 109:     public static final int HEADER_SIZE = 128;
>> 110:     private static final int TOC_OFFSET = HEADER_SIZE + 4;
>> 111:     private static final int TOC_RECORD_SIZE = 12;
> 
> Minor: All the constants are defined at the end of file, is it better to move them to the beginning ?

Perhaps someday when we go for this kind of unification

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25313#discussion_r2101096420

From serb at openjdk.org  Wed May 21 20:55:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 21 May 2025 20:55:52 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v4]
In-Reply-To: <bSYgJVpKCybEqVCibxAp7sY5a0NCvylyQRi6Rx8iCb4=.8b9cf6ac-0949-4598-b228-35153829a548@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <okYE19v_u7IqG1-ElaDWPfUcDZQ4s5eWQ6iuyraFM6Y=.2575d60a-74e2-488f-9708-913f73ea099b@github.com>
 <bSYgJVpKCybEqVCibxAp7sY5a0NCvylyQRi6Rx8iCb4=.8b9cf6ac-0949-4598-b228-35153829a548@github.com>
Message-ID: <LxjMnKsyWhkWjjJD9nUZQVh64Q3G--PrAUzO6BX6Y0w=.b27d0ca4-5090-4e95-b1bd-d89bd519143d@github.com>

On Wed, 21 May 2025 20:15:43 GMT, Phil Race <prr at openjdk.org> wrote:

> This is in the AWT package so I think AWT components is better.
> And the goal is just to get rid of the applet mentions and I've now done that (after the last one)

But these layout classes are used for both awt and swing libraries. And since we modernize the example and drop outdated applets we may change them to jframe instead+jbutton, on mac the images will be the same as for awt.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25278#issuecomment-2899206760

From prr at openjdk.org  Wed May 21 21:00:54 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 21 May 2025 21:00:54 GMT
Subject: RFR: 8357287: Unify usage of ICC profile "header size" constants
 in CMM-related code
In-Reply-To: <E0IDBFGhxM-z1VwcY4cYSCVXbu93tKcm5qnx_M3nWJ8=.475bec53-4c98-4ba3-accc-0613e0b8eb0f@github.com>
References: <E0IDBFGhxM-z1VwcY4cYSCVXbu93tKcm5qnx_M3nWJ8=.475bec53-4c98-4ba3-accc-0613e0b8eb0f@github.com>
Message-ID: <Ns0gl4lmAGZpshKejiuDROMM84DtCvSv7Jnq-Twua28=.26416977-ea84-4cbc-9875-46f10072ae9b@github.com>

On Tue, 20 May 2025 00:37:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Small unification of "header size" constants, as of now the CMM code uses:
> 1. sun.java2d.cmm.ProfileDataVerifier.HEADER_SIZE introduced in JDK-8013430
> 2. java.awt.color.ICC_Profile.HEADER_SIZE introduced in [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377)
> 3. Hardcoded literal 128

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25313#pullrequestreview-2859099087

From vyazici at openjdk.org  Wed May 21 21:02:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 May 2025 21:02:04 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
Message-ID: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>

There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.

### Fixing strategy

* Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
* Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
* Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.

@naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.

### Scanning strategy

The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:


# Perl is used for multi-line matching
find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
git grep -H 'FileDescriptor.in' "*.java"


All calls to `InputStreamReader::new` and `Scanner::new` are checked too.

### Problems encountered

1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:

    ```
    DOMImplementationRegistry 
    InputRC 
    ListingErrorHandler 
    PandocFilter 
    ```
2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

-------------

Commit messages:
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations

Changes: https://git.openjdk.org/jdk/pull/25368/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25368&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356893
  Stats: 244 lines in 58 files changed: 111 ins; 20 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/25368.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25368/head:pull/25368

PR: https://git.openjdk.org/jdk/pull/25368

From prr at openjdk.org  Wed May 21 21:02:58 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 21 May 2025 21:02:58 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v4]
In-Reply-To: <LxjMnKsyWhkWjjJD9nUZQVh64Q3G--PrAUzO6BX6Y0w=.b27d0ca4-5090-4e95-b1bd-d89bd519143d@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <okYE19v_u7IqG1-ElaDWPfUcDZQ4s5eWQ6iuyraFM6Y=.2575d60a-74e2-488f-9708-913f73ea099b@github.com>
 <bSYgJVpKCybEqVCibxAp7sY5a0NCvylyQRi6Rx8iCb4=.8b9cf6ac-0949-4598-b228-35153829a548@github.com>
 <LxjMnKsyWhkWjjJD9nUZQVh64Q3G--PrAUzO6BX6Y0w=.b27d0ca4-5090-4e95-b1bd-d89bd519143d@github.com>
Message-ID: <ZQDkOeEUMUcLlDgG6LfdlPENfm04srNJ1mzeU9ZtAPc=.f8290e77-d3f8-4a4b-9a3a-e0884b60b224@github.com>

On Wed, 21 May 2025 20:53:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > This is in the AWT package so I think AWT components is better.
> > And the goal is just to get rid of the applet mentions and I've now done that (after the last one)
> 
> But these layout classes are used for both awt and swing libraries. And since we modernize the example and drop outdated applets we may change them to jframe instead+jbutton, on mac the images will be the same as for awt.

I really don't see that as being the right thing to do here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25278#issuecomment-2899220414

From rriggs at openjdk.org  Wed May 21 21:39:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 May 2025 21:39:53 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

There too many changes in too many different areas to be in a single PR.
Please break it down by review areas.  Client, core libs, tools, etc.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25368#pullrequestreview-2859185030

From serb at openjdk.org  Wed May 21 21:54:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 21 May 2025 21:54:54 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v5]
In-Reply-To: <DEIpf0BK_yfxezmyfs_YqR5N478EtJyRODQhvKVUC0E=.4f3026e8-6f6f-4142-8302-43e22bff2ab5@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <DEIpf0BK_yfxezmyfs_YqR5N478EtJyRODQhvKVUC0E=.4f3026e8-6f6f-4142-8302-43e22bff2ab5@github.com>
Message-ID: <7c528mbl1GQsxEIke_7dmPXixVki0Vfx7o7MZvc1YmQ=.d06fd881-a946-43c7-9db9-b3bc1b2ce1d7@github.com>

On Wed, 21 May 2025 20:21:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> Update the some code examples and accompanying images to no longer mention or display as applets.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357176

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25278#pullrequestreview-2859213283

From serb at openjdk.org  Wed May 21 21:58:00 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 21 May 2025 21:58:00 GMT
Subject: RFR: 8357176: java.awt javadoc code examples still use Applet API
 [v4]
In-Reply-To: <ZQDkOeEUMUcLlDgG6LfdlPENfm04srNJ1mzeU9ZtAPc=.f8290e77-d3f8-4a4b-9a3a-e0884b60b224@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
 <okYE19v_u7IqG1-ElaDWPfUcDZQ4s5eWQ6iuyraFM6Y=.2575d60a-74e2-488f-9708-913f73ea099b@github.com>
 <bSYgJVpKCybEqVCibxAp7sY5a0NCvylyQRi6Rx8iCb4=.8b9cf6ac-0949-4598-b228-35153829a548@github.com>
 <LxjMnKsyWhkWjjJD9nUZQVh64Q3G--PrAUzO6BX6Y0w=.b27d0ca4-5090-4e95-b1bd-d89bd519143d@github.com>
 <ZQDkOeEUMUcLlDgG6LfdlPENfm04srNJ1mzeU9ZtAPc=.f8290e77-d3f8-4a4b-9a3a-e0884b60b224@github.com>
Message-ID: <mnIJWmkwVrlj-T1XEYol5jS447nnfBOk5CxwHIUcCNg=.f0e5c3ef-869e-4d23-9bb1-70975601e5df@github.com>

On Wed, 21 May 2025 21:00:24 GMT, Phil Race <prr at openjdk.org> wrote:

> I really don't see that as being the right thing to do here.

The goal of this change is to delete the usage of applet, but as a replacement the change uses the awt frame, while i think the right thing to use in our examples are "modern" swing components

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25278#issuecomment-2899340978

From serb at openjdk.org  Thu May 22 03:06:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 May 2025 03:06:50 GMT
Subject: RFR: 8312198: [macos] metal pipeline - window rendering stops
 after display sleep
In-Reply-To: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
References: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
Message-ID: <d6zgy_4sAT6kmbFndfpL_MWucjhDu5mQIihLctsCgTk=.afec4640-5587-482d-8ffd-215fd06df834@github.com>

On Wed, 21 May 2025 06:11:18 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> In stress based scenarios it is observed that nothing is drawn in UI content when display wakes up from sleep in Metal pipeline of macOS. Unfortunately i am not able to reproduce it, but based on details in the bug it looks like we are hitting a race condition. Call to CVDisplayLinkCreateWithActiveCGDisplays is becoming a no-op as there are no active displays right after NSWorkspaceScreensDidWakeNotification. Looks like if we continue to call CVDisplayLinkCreateWithActiveCGDisplays after screen wakeup we are able to get the list of ActiveDisplays and then able to create displayLink.
> 
> So now the code is modified to check whether CVDisplayLinkCreateWithActiveCGDisplays is successful or not. If not we will try to call CVDisplayLinkCreateWithActiveCGDisplays for 5 instances each with 1 second delay. There is no regression test for this change because it needs a stress based test with display wakeup/sleep(As captured in JBS, i am not able to reproduce this issue).
> 
> I have tested this change for sanity by running animation examples from SwingSet2 and continuously connecting/disconnecting external display. Also by multiple display sleep and wakeup scenarios, i don't see any regressions. Also whole clientlibs CI run is done with this patch and it is also green.
> 
> While working on this bug also noticed that many functions of CVDisplayLink is deprecated from macOS 14 and going forward we need to use CADisplayLink/CAMetalDisplayLink. I have raised [JDK-8357418](https://bugs.openjdk.org/browse/JDK-8357418) for the same.

Is it possible that it is somehow related to 8304825? could be the layer created "during display sleep" and that might be in "sleep" more that 5 seconds?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25342#issuecomment-2899764689

From zzambers at openjdk.org  Thu May 22 03:42:58 2025
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Thu, 22 May 2025 03:42:58 GMT
Subject: Integrated: 8343618: Stack smashing in awt_InputMethod.c on Linux
 s390x
In-Reply-To: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
References: <Fj3nXZU0MN_hfIS8hnPPEP22ZNL7vePjqXEA2lROIb0=.1d9aa666-519f-4cf8-81ad-03e0d11a3ea8@github.com>
Message-ID: <iBMvulgfq08hsWNSUiNDeJhuPdeVnlVJGqc4DnI1F4Y=.a113a4af-56e7-4909-be8f-a44413f68c66@github.com>

On Mon, 24 Mar 2025 13:41:44 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> This fixes stack smashing issue in awt library on linux s390x. (jdk compiled with `-fstack-protector-strong`)
> 
> Fix is based on patch [submitted](https://mail.openjdk.org/pipermail/awt-dev/2019-July/015337.html) in JDK-8227919 review thread, rebased to master. They decided to go for Solaris only fix there, with [expected follow-up](https://mail.openjdk.org/pipermail/awt-dev/2019-July/015347.html) for linux/s390x. But that never happened.
> 
> I was not able to get response from original author for this issue, so I am creating PR myself.
> 
> **Testing:**
> I tested jdk with and without this fix on linux/s390x (using Xvfb). It fixes the issue (reproducer for this bug no longer crashes the JVM). I have also tried to run `jdk_awt` tests, where lot of tests was also affected by this. With this patch amount of failures dropped by ~100. 
> 
> Without fix:
> 
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/jdk:jdk_awt                             2171  1063   415     6   687 <<
> 
> 
> With fix
> 
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/jdk:jdk_awt                             2171  1162   316     6   687 <<
> 
> 
> Many tests are no longer crashing the VM:
> 
> -java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java                                                      Failed. Unexpected exit from test [exit code: 134]
> +java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java                                                      Passed. Execution successful
> 
> There seem to be few unstable tests in jdk_awt. (Ones that fail in one or another run, but seem unrelated to this fix)
> 
> I have not done any additional manual testing of XIM as did original author (in review thread mentioned higher), as I am not at all familiar with input method for Japanese (or other Asian characters), or how that supposed to work. (So I cannot verify that input of Asian characters works as expected on linux/s390x, but at least JVM no longer crashes.)

This pull request has now been integrated.

Changeset: ee689145
Author:    Zdenek Zambersky <zzambers at openjdk.org>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee6891456ed672305d9b48846b5a7977373e1284
Stats:     20 lines in 1 file changed: 10 ins; 10 del; 0 mod

8343618: Stack smashing in awt_InputMethod.c on Linux s390x

Co-authored-by: Ichiroh Takiguchi <itakiguchi at openjdk.org>
Reviewed-by: prr, aph, amitkumar

-------------

PR: https://git.openjdk.org/jdk/pull/24197

From serb at openjdk.org  Thu May 22 04:34:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 May 2025 04:34:56 GMT
Subject: Integrated: 8357287: Unify usage of ICC profile "header size"
 constants in CMM-related code
In-Reply-To: <E0IDBFGhxM-z1VwcY4cYSCVXbu93tKcm5qnx_M3nWJ8=.475bec53-4c98-4ba3-accc-0613e0b8eb0f@github.com>
References: <E0IDBFGhxM-z1VwcY4cYSCVXbu93tKcm5qnx_M3nWJ8=.475bec53-4c98-4ba3-accc-0613e0b8eb0f@github.com>
Message-ID: <yOWHTQmsKHWPpulmWPUUTlmyO3Ye1PjrWv3kzZtt6pA=.04d04b50-2556-41b4-bca4-f8c107d4fd2a@github.com>

On Tue, 20 May 2025 00:37:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Small unification of "header size" constants, as of now the CMM code uses:
> 1. sun.java2d.cmm.ProfileDataVerifier.HEADER_SIZE introduced in JDK-8013430
> 2. java.awt.color.ICC_Profile.HEADER_SIZE introduced in [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377)
> 3. Hardcoded literal 128

This pull request has now been integrated.

Changeset: 68c1d305
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68c1d305e726f3f4d7209b857f58cc10de5c0132
Stats:     10 lines in 2 files changed: 2 ins; 2 del; 6 mod

8357287: Unify usage of ICC profile "header size" constants in CMM-related code

Reviewed-by: honkar, prr

-------------

PR: https://git.openjdk.org/jdk/pull/25313

From alanb at openjdk.org  Thu May 22 05:54:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 May 2025 05:54:52 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <wrtUfsbfcWNXz5eMaykcIbLOPC5019cvCsig_cLn7L4=.bd0dab1a-ad1e-465c-852b-8fb66d81f401@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

javax.swing.text.DefaultEditorKit.read(InputStream ...)  is one example changed in the PR. If that is changed to special case System.in then it will require a spec change. It also means that `read(System.in)` will behave differently to say `new BufferedInputStream(System.in)`.  From a quick scan, I suspect changes that impact the APIs will need to dropped from the PR, maybe replaced with spec clarification to document the charset that is actually used. In the DefaultEditorKit.read example it might direct folks to the read(Reader ..) method so that code can control which charset to use.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2899998753

From syan at openjdk.org  Thu May 22 06:30:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 22 May 2025 06:30:58 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9 [v2]
In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
 <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
Message-ID: <dUST51huLMfYRtpn1njlmy71DW2k1nXRKPE6CVBuedU=.865eda15-4200-4887-9b8e-35844582d3a7@github.com>

On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The following line results in unused-result warning on linux/clang.
>> 
>> 
>> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
>> 
>> 
>> There are two ways to handle it 
>> 
>> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
>> 
>> 
>> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html
>> 
>> 
>> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
>> 
>> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   DTRACE added

Duplicated to https://bugs.openjdk.org/browse/JDK-8346103

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25217#issuecomment-2900065310

From tr at openjdk.org  Thu May 22 06:57:38 2025
From: tr at openjdk.org (Tejesh R)
Date: Thu, 22 May 2025 06:57:38 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v5]
In-Reply-To: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
Message-ID: <wXNo-gw_B0ukNg01ZLtpxk2gEDiftPVcDxBdV-Tq4mU=.70de0eb0-60e8-4cbf-9256-63765f485d0d@github.com>

> The rendering of the directory names are handled as JLabel w.r.t Look and feel and also either Details/List view. Though FilePane creates basic rendering for these two few Look and Feel define their own renderers and also ComboBox Directory directory name view. Since HTML filtering is not taken care in any of these renderers, JLabel renders them as HTML document if nothing is set or specified.
> The fix is to get "html.disable" property from JFileChooser and set the same to JLabel component which renders and set Directory name. Hence applications can either enable/disable this property and control HTML rendering of directory name.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24439/files
  - new: https://git.openjdk.org/jdk/pull/24439/files/4f8c759a..5157249b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24439&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24439&range=03-04

  Stats: 25 lines in 1 file changed: 8 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/24439.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24439/head:pull/24439

PR: https://git.openjdk.org/jdk/pull/24439

From tr at openjdk.org  Thu May 22 06:57:38 2025
From: tr at openjdk.org (Tejesh R)
Date: Thu, 22 May 2025 06:57:38 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v3]
In-Reply-To: <q3EMNgG5RL1qv0uyexiYtZUY3BZAJgeADAF_X81Cu0g=.0af59826-8485-4e31-ad4b-41e6a1e8449a@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <JVyEYDeaC2nRhod516RnecC9xDNUAlJXt0yz4I5xgvo=.a64851ce-c2f6-4e9d-bbdc-d6ad36626f56@github.com>
 <8icaCzTbIOcszrNmqCYdzqI4telSGl3bM-9afdXEWbE=.7c5be52b-eb9e-41e0-b655-5148f135d72c@github.com>
 <ZshfrOL5XDcLWMt6nfLjhaurK_H_hfqa9ARQoI8dT2E=.49decca5-183d-4b39-b66a-26480e4eaf28@github.com>
 <RU2IO1w2LAZ8O3AxseaznyXKM5O5erdybYfXdTX2nlc=.0c127e7d-c5d1-409e-85ba-2ac921476ecb@github.com>
 <q3EMNgG5RL1qv0uyexiYtZUY3BZAJgeADAF_X81Cu0g=.0af59826-8485-4e31-ad4b-41e6a1e8449a@github.com>
Message-ID: <vAz5yqtSJbTheLY7Uutgr37Bw_yLxFHsiUYmUlRCvvg=.11dfa686-ea56-4344-b402-2d103ed50938@github.com>

On Wed, 21 May 2025 19:44:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Why would we need HTML-formatted instructions btw ?
>
>> Why would we need HTML-formatted instructions btw ?
> 
> Because the instructions are really hard to read in Windows L&F (because of the monospace font):
> 
> ![HTMLFileName Instructions in Windows L&F: the text doesn't fit nicely in the window and gets wrapped](https://github.com/user-attachments/assets/ecd39482-e448-4436-96e5-8d6b96c888d9)
> 
> The image isn't clear, but you get the idea: all the text gets wrapped, so it's hard to keep track of the instructions. Anyway, I'm fine with it.
> 
> Harshitha had [a similar problem](https://github.com/openjdk/jdk/pull/24456#discussion_r2054468745), and she switched to [using HTML formatting](https://github.com/openjdk/jdk/pull/24456#discussion_r2054516242) which works reliably across different OS.
> 
> You can check [`JFileChooser/bug4943900.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JFileChooser/bug4943900.java) on how it looks and works in different OS.
> 
> https://github.com/openjdk/jdk/blob/81536830ed096005c4f09ab446238ce50989cea9/test/jdk/javax/swing/JFileChooser/bug4943900.java#L40-L47

Yup got it. I've update the test instructions to HTML-formatted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2101780723

From tr at openjdk.org  Thu May 22 06:57:38 2025
From: tr at openjdk.org (Tejesh R)
Date: Thu, 22 May 2025 06:57:38 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v4]
In-Reply-To: <JepKp3SCjDVdjl5uOmhuaNgRjRpRGfRSMP-qu0DUjNk=.1009d38b-01ed-4799-b7a2-fc1bc5724997@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <MZ4qxb0APA2o_r3OJ21MNa1hmmcS3ApThNHjKW43vjg=.8d42dd5d-9f46-4676-8cbc-6b6d23acfa34@github.com>
 <JepKp3SCjDVdjl5uOmhuaNgRjRpRGfRSMP-qu0DUjNk=.1009d38b-01ed-4799-b7a2-fc1bc5724997@github.com>
Message-ID: <6UEOlSjAROoDC18-Y-m0kN_YQ6GLIHZV3j5Kxmp_61w=.dcd7a30d-5659-4b9c-acd9-b3fe5b4200bd@github.com>

On Wed, 21 May 2025 16:47:29 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 review comments
>
> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 61:
> 
>> 59:                      If it appears to be in HTML format with Pink color,
>> 60:                      then test fails.
>> 61:                      (Verify for all Look and Feel).
> 
> There's no way for the tester to verify all Look and Feels, unless they go out of their way and launch the test manually with different look and feels.
> 
> For this reason, I'd remove this line altogether.

Removed.

> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 110:
> 
>> 108:         jfc.putClientProperty("html.disable", htmlEnabled);
>> 109:         jfc.setControlButtonsAreShown(false);
>> 110:         JFrame frame = new JFrame((htmlEnabled) ? "HTML enabled" : "HTML disabled");
> 
> Suggestion:
> 
>         jfc.setControlButtonsAreShown(false);
> 
>         JFrame frame = new JFrame((htmlEnabled) ? "HTML enabled" : "HTML disabled");
> 
> It's better with a blank line that separates the two blocks of code.

Updated.

> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 126:
> 
>> 124:             return new File[]{
>> 125:                     new File("/", "<html><h1 color=#ff00ff><font " +
>> 126:                             "face=\"Comic Sans MS\">Swing Rocks!!!!111"),
> 
> Suggestion:
> 
>                             "face="Comic Sans MS">Swing Rocks!"),
> 
> Update this too.

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2101781284
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2101780937
PR Review Comment: https://git.openjdk.org/jdk/pull/24439#discussion_r2101781523

From vyazici at openjdk.org  Thu May 22 07:59:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:09 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
 <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>
Message-ID: <JR9YcwtR6e9rtwHNRjzrc_f3vDzGlX5P7HbsynNMOmQ=.58dcd998-ff73-4547-b619-1ba8fa12bd7d@github.com>

On Wed, 21 May 2025 21:37:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
>> 
>> ### Fixing strategy
>> 
>> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
>> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
>> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
>> 
>> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
>> 
>> ### Scanning strategy
>> 
>> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
>> 
>> 
>> # Perl is used for multi-line matching
>> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
>> git grep -H 'FileDescriptor.in' "*.java"
>> 
>> 
>> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
>> 
>> ### Problems encountered
>> 
>> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
>> 
>>     ```
>>     DOMImplementationRegistry 
>>     InputRC 
>>     ListingErrorHandler 
>>     PandocFilter 
>>     ```
>> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property
>
> There too many changes in too many different areas to be in a single PR.
> Please break it down by review areas.  Client, core libs, tools, etc.

@RogerRiggs, @AlanBateman, thanks so much for the quick review. I see your points. I will

1. withdraw this PR,
2. convert certain changes to spec clarifications,
3. and break it down to multiple PRs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2900262422

From vyazici at openjdk.org  Thu May 22 07:59:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:10 GMT
Subject: Withdrawn: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <cRfyJRr23DS3mw4U7XMBE6rBHXIWxlQiEcNpKG-wZBw=.6a7bcbb9-9cb6-45dc-8ce6-40fefbd328ff@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25368

From aivanov at openjdk.org  Thu May 22 10:37:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 May 2025 10:37:59 GMT
Subject: RFR: 8334016: Make PrintNullString.java automatic [v5]
In-Reply-To: <iEY6OFtcWs-6rGPPmDKT7iWIf_rIShQsSLmGihVv-_8=.6894dceb-63c7-403f-b957-17d2c7b7608d@github.com>
References: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
 <KbR5cg-JnmcfXjribGtlGn4ORjQofQfYABhVdh3zSPk=.bea9aad6-351b-4048-8d0f-4856aa494dd0@github.com>
 <aCAW9bHw9bvfWD7L4yx2rV1IJ-AsEjbeQDOjVVbHnXM=.33ff1e6d-afbc-4c21-aecc-f43d6ad1c279@github.com>
 <iEY6OFtcWs-6rGPPmDKT7iWIf_rIShQsSLmGihVv-_8=.6894dceb-63c7-403f-b957-17d2c7b7608d@github.com>
Message-ID: <kFWGjNe9IyPrFDJG22y0Ee947SSkgCjEO7YhTMJAlcw=.adba866c-bb67-4c4e-809e-5724bb3f322d@github.com>

On Wed, 9 Apr 2025 09:27:38 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> This **builder** is for PassFailJFrame (user instruction window).
>
> @Renjithkannath apologies, I meant the constructor, line 64 ?

> Minor: Don't you think It's a bit unusual to have the test be executed with the builder of the class? Seems a bit odd to me, but if you prefer it, it's fine as is

Maybe? There are other tests that use this code style.

> I understand, but this is a string value which is always set to null. Wouldn't it be easier to read if it was `null` straight in the method call? Something like this: `g2d.drawString((String) null, 20, 40);`
> 
> If you prefer it as is, it's fine too

@myankelev It's not a new test. Explicit `null` requires cast to either `String` or `AttributedCharacterIterator`. The name of the variable have a type associated with it. In addition to that, it keeps the code consistent where null values are tested and where non-null values are tested, and it's clear from the parameter name what is tested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24501#discussion_r2102222223
PR Review Comment: https://git.openjdk.org/jdk/pull/24501#discussion_r2102231520

From aivanov at openjdk.org  Thu May 22 10:37:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 May 2025 10:37:59 GMT
Subject: RFR: 8334016: Make PrintNullString.java automatic [v5]
In-Reply-To: <TU550HE7vdwVBAfasjoUWnLsLNXMEq-9AhfSOOQ6bhw=.af24780f-9677-4a8b-a9fb-8ec51bd71d23@github.com>
References: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
 <TU550HE7vdwVBAfasjoUWnLsLNXMEq-9AhfSOOQ6bhw=.af24780f-9677-4a8b-a9fb-8ec51bd71d23@github.com>
Message-ID: <0mHuo9tjO5jTGrXp9dTyRZqZRywPGopOxKy83WW9evw=.a9d7a996-6312-49ed-bac1-653103bac763@github.com>

On Wed, 14 May 2025 04:07:08 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> I have updated the test and made it semi-automatic (need to click "Print") . Test will initiate a print and result will be generated automatic. 
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved main fuction to top

Looks good to me except for a minor nit.

test/jdk/java/awt/print/PrinterJob/PrintNullString.java line 56:

> 54:             throw new RuntimeException("Printer not configured or available.");
> 55:         }
> 56:         new PrintNullString();

Suggestion:


        new PrintNullString();

Leave a blank line between the skipped condition and the real test code.

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24501#pullrequestreview-2860700039
PR Review Comment: https://git.openjdk.org/jdk/pull/24501#discussion_r2102225612

From aivanov at openjdk.org  Thu May 22 10:47:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 May 2025 10:47:54 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v6]
In-Reply-To: <UNCxoczmrdt-jHUUD69VxCKuZZisODLTyTjhY6hyiXk=.d430d350-68a9-4238-ae0d-57710761e1ab@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <UNCxoczmrdt-jHUUD69VxCKuZZisODLTyTjhY6hyiXk=.d430d350-68a9-4238-ae0d-57710761e1ab@github.com>
Message-ID: <BX2cVsJlrgYDnzol7-9VKTzGyBZIg5kC9rUd6buYMvg=.6f45128b-047c-46c8-b44b-dafc250bc560@github.com>

On Wed, 21 May 2025 17:23:17 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
>> 
>> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added final modifier to the class MenuItemTestHelper

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 52:

> 50:             }
> 51:         }
> 52:         Icon myIcon = new ColoredIcon(Color.RED, 10, 10);

The blank here was in its own place. It separated the code that sets L&F from creating icons.

I think there should be a blank line after the icons are created, too.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25319#pullrequestreview-2860741769
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2102249558

From aivanov at openjdk.org  Thu May 22 10:53:08 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 May 2025 10:53:08 GMT
Subject: RFR: 8346436: Compilation with clang fails [v2]
In-Reply-To: <bK9m9DFlFmNv7F5ofuCE8H2C2WoeFJM9kuQLFuVbdz4=.662bc01f-4ffa-4fb4-80e9-a86c93ffe2b3@github.com>
References: <2T1MSOZ5x2Aui8EwMvWvLEXeUGmty5PLl1nuAWSZZ74=.02465712-ad35-48c7-83e9-8e825b92f35a@github.com>
 <bK9m9DFlFmNv7F5ofuCE8H2C2WoeFJM9kuQLFuVbdz4=.662bc01f-4ffa-4fb4-80e9-a86c93ffe2b3@github.com>
Message-ID: <Luiq8pGL-JHkv_XV_aownHBAN4MNgDhwA5oDKb70xlo=.ff677666-b51b-45d1-b664-1166cf470995@github.com>

On Fri, 3 Jan 2025 09:19:34 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> clang-18.1.8-1.fc40.x86_64
>> Fedora 40 x86_64
>> fbd76ca8edd756ff2ebbc9f6477cc1a827df67b0
>> 
>> 
>> src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>>   695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 );
>>       | ^~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:375:9: error: ignoring return value of function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>>   375 | write(splash->controlpipe[1], &code, 1);
>>       | ^~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:713:5: error: ignoring return value of function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>>   713 | pipe(splash->controlpipe);
>>       | ^~~~ ~~~~~~~~~~~~~~~~~~~
>> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/j2secmod.h:45:9: error: 'dprintf' macro redefined [-Werror,-Wmacro-redefined]
>>    45 | #define dprintf(s)
>>       | ^
>> /usr/include/bits/stdio2.h:121:12: note: previous definition is here
>>   121 | # define dprintf(fd, ...) \
>>       | ^
>> src/java.smartcardio/share/native/libj2pcsc/pcsc.c:48:9: error: 'dprintf' macro redefined [-Werror,-Wmacro-redefined]
>>    48 | #define dprintf(s)
>>       | ^
>> /usr/include/bits/stdio2.h:121:12: note: previous definition is here
>>   121 | # define dprintf(fd, ...) \
>>       | ^
>
> Jan Kratochvil 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:
> 
>  - Use only (void) casts
>  - Merge branch 'master' into clangbuild
>  - 8346436: Compilation with clang fails

@jankratochvil Seemingly, the same problem is being addressed in #25217 for [JDK-8354316](https://bugs.openjdk.org/browse/JDK-8354316).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22794#issuecomment-2900771105

From aivanov at openjdk.org  Thu May 22 10:55:02 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 May 2025 10:55:02 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9 [v2]
In-Reply-To: <dUST51huLMfYRtpn1njlmy71DW2k1nXRKPE6CVBuedU=.865eda15-4200-4887-9b8e-35844582d3a7@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
 <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
 <dUST51huLMfYRtpn1njlmy71DW2k1nXRKPE6CVBuedU=.865eda15-4200-4887-9b8e-35844582d3a7@github.com>
Message-ID: <c3ZfuJOZi0kU_4dilhcCYy-TtMuIQYhJMi8Lq2EoKuY=.188d89f6-24ff-4ba7-9349-18b4f9055096@github.com>

On Thu, 22 May 2025 06:28:07 GMT, SendaoYan <syan at openjdk.org> wrote:

> Duplicated to https://bugs.openjdk.org/browse/JDK-8346103

So, [JDK-8346103](https://bugs.openjdk.org/browse/JDK-8346103) is closed as duplicate of [JDK-8346436](https://bugs.openjdk.org/browse/JDK-8346436). The latter has a closed code review #22794.

I like this approach better because it doesn't simply ignore the return value but prints a trace if `write` returns the unexpected value.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25217#issuecomment-2900778127

From rkannathpari at openjdk.org  Thu May 22 11:24:34 2025
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Thu, 22 May 2025 11:24:34 GMT
Subject: RFR: 8334016: Make PrintNullString.java automatic [v6]
In-Reply-To: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
References: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
Message-ID: <UzDDzT8FgOY5buBaM7KsGiDqsjTzJbKeEL_9wEJLthE=.e4af3bb5-8b5a-4f75-93bb-cba3f6dc1ef6@github.com>

> Hi Reviewers,
> 
> I have updated the test and made it semi-automatic (need to click "Print") . Test will initiate a print and result will be generated automatic. 
> 
> Please review and let me know your suggestions.

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/awt/print/PrinterJob/PrintNullString.java
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24501/files
  - new: https://git.openjdk.org/jdk/pull/24501/files/2c9f9901..01041aa3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24501&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24501&range=04-05

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24501/head:pull/24501

PR: https://git.openjdk.org/jdk/pull/24501

From syan at openjdk.org  Thu May 22 12:34:57 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 22 May 2025 12:34:57 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9 [v2]
In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
 <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
Message-ID: <o4ARG4dHsIboWx4HCs5qmMlpH0iDjQu82ptINRYO0mg=.6c49f6d4-ca0e-418c-9b65-4f4f723523a8@github.com>

On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The following line results in unused-result warning on linux/clang.
>> 
>> 
>> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
>> 
>> 
>> There are two ways to handle it 
>> 
>> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
>> 
>> 
>> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html
>> 
>> 
>> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
>> 
>> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   DTRACE added

LGTM

-------------

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25217#pullrequestreview-2861046664

From mvs at openjdk.org  Thu May 22 13:07:14 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Thu, 22 May 2025 13:07:14 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v7]
In-Reply-To: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
Message-ID: <uBPXVquKyaeIG0g6iIM9Wo9sSwAI0Q2KXcPpTn_GrJ0=.ab448e8b-6fd5-44c3-bb66-14d080e0aaa9@github.com>

> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
> 
> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Added blank lines to seperate logic code pieces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25319/files
  - new: https://git.openjdk.org/jdk/pull/25319/files/b04155cd..db537cb8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25319&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25319&range=05-06

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25319/head:pull/25319

PR: https://git.openjdk.org/jdk/pull/25319

From mvs at openjdk.org  Thu May 22 13:07:15 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Thu, 22 May 2025 13:07:15 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v6]
In-Reply-To: <BX2cVsJlrgYDnzol7-9VKTzGyBZIg5kC9rUd6buYMvg=.6f45128b-047c-46c8-b44b-dafc250bc560@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <UNCxoczmrdt-jHUUD69VxCKuZZisODLTyTjhY6hyiXk=.d430d350-68a9-4238-ae0d-57710761e1ab@github.com>
 <BX2cVsJlrgYDnzol7-9VKTzGyBZIg5kC9rUd6buYMvg=.6f45128b-047c-46c8-b44b-dafc250bc560@github.com>
Message-ID: <pttOdqH9kE7yxhNuWaJEje6zU8mHLBycZXriQeSG0eo=.f2f95d84-4534-48ec-97cc-5fbe507aeb80@github.com>

On Thu, 22 May 2025 10:44:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added final modifier to the class MenuItemTestHelper
>
> test/jdk/javax/swing/JMenuItem/MenuItemTest/MenuItemTestHelper.java line 52:
> 
>> 50:             }
>> 51:         }
>> 52:         Icon myIcon = new ColoredIcon(Color.RED, 10, 10);
> 
> The blank here was in its own place. It separated the code that sets L&F from creating icons.
> 
> I think there should be a blank line after the icons are created, too.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2102510295

From mvs at openjdk.org  Thu May 22 13:19:43 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Thu, 22 May 2025 13:19:43 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v8]
In-Reply-To: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
Message-ID: <n6POjQ2WxpLAopmy7njkz2F3gaE8e6TRHDDLV_cmdO4=.e2756648-a6ee-4095-b736-2dc71c24c83e@github.com>

> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
> 
> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Removed trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25319/files
  - new: https://git.openjdk.org/jdk/pull/25319/files/db537cb8..64134a5e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25319&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25319&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25319/head:pull/25319

PR: https://git.openjdk.org/jdk/pull/25319

From aivanov at openjdk.org  Thu May 22 13:57:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 May 2025 13:57:55 GMT
Subject: RFR: 8334016: Make PrintNullString.java automatic [v6]
In-Reply-To: <UzDDzT8FgOY5buBaM7KsGiDqsjTzJbKeEL_9wEJLthE=.e4af3bb5-8b5a-4f75-93bb-cba3f6dc1ef6@github.com>
References: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
 <UzDDzT8FgOY5buBaM7KsGiDqsjTzJbKeEL_9wEJLthE=.e4af3bb5-8b5a-4f75-93bb-cba3f6dc1ef6@github.com>
Message-ID: <RVxjK-owBDT-P-Sd9Z08hF_DWhxdJ0tAvrqIILq--Ic=.2cc9dc5b-c118-49ee-b53c-7c608a79eca6@github.com>

On Thu, 22 May 2025 11:24:34 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> I have updated the test and made it semi-automatic (need to click "Print") . Test will initiate a print and result will be generated automatic. 
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/awt/print/PrinterJob/PrintNullString.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24501#pullrequestreview-2861349517

From aivanov at openjdk.org  Thu May 22 14:12:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 May 2025 14:12:55 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v8]
In-Reply-To: <n6POjQ2WxpLAopmy7njkz2F3gaE8e6TRHDDLV_cmdO4=.e2756648-a6ee-4095-b736-2dc71c24c83e@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <n6POjQ2WxpLAopmy7njkz2F3gaE8e6TRHDDLV_cmdO4=.e2756648-a6ee-4095-b736-2dc71c24c83e@github.com>
Message-ID: <V7lx1LQOrE8oAfBBRuv-oU2noAkLt2GgH3pRADkmv0M=.b287055f-a787-45e5-a6f5-1db118108c83@github.com>

On Thu, 22 May 2025 13:19:43 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
>> 
>> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed trailing whitespace

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JMenuItem/MenuItemTest/bug6197830.java line 52:

> 50:                 .testUI(bug6197830::createTestUI)
> 51:                 .position(PassFailJFrame.Position.TOP_LEFT_CORNER)
> 52:                 .positionTestUIBottomRowCentered()

Suggestion:

                .positionTestUIBottomRowCentered()

-------------

PR Review: https://git.openjdk.org/jdk/pull/25319#pullrequestreview-2861403996
PR Review Comment: https://git.openjdk.org/jdk/pull/25319#discussion_r2102665677

From mvs at openjdk.org  Thu May 22 14:31:43 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Thu, 22 May 2025 14:31:43 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v9]
In-Reply-To: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
Message-ID: <j44yX2hDFp3M-POzT5RjdlEMvUz_03-UUtFi-pXmt-Q=.dae7a7a4-f912-4bc3-a940-b5012e2b94b6@github.com>

> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
> 
> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Removed unwanted code for positioning the UI

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25319/files
  - new: https://git.openjdk.org/jdk/pull/25319/files/64134a5e..36338cac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25319&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25319&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25319/head:pull/25319

PR: https://git.openjdk.org/jdk/pull/25319

From aivanov at openjdk.org  Thu May 22 14:31:43 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 May 2025 14:31:43 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v9]
In-Reply-To: <j44yX2hDFp3M-POzT5RjdlEMvUz_03-UUtFi-pXmt-Q=.dae7a7a4-f912-4bc3-a940-b5012e2b94b6@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <j44yX2hDFp3M-POzT5RjdlEMvUz_03-UUtFi-pXmt-Q=.dae7a7a4-f912-4bc3-a940-b5012e2b94b6@github.com>
Message-ID: <K73xsNubPSCSV2kf7m9n8dfyIP2eCymHuG9thLvn2bI=.45b6d249-5fd6-4cfc-82c7-14b2cbb43b31@github.com>

On Thu, 22 May 2025 14:28:37 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
>> 
>> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unwanted code for positioning the UI

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25319#pullrequestreview-2861465239

From duke at openjdk.org  Thu May 22 14:31:44 2025
From: duke at openjdk.org (duke)
Date: Thu, 22 May 2025 14:31:44 GMT
Subject: RFR: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java [v8]
In-Reply-To: <n6POjQ2WxpLAopmy7njkz2F3gaE8e6TRHDDLV_cmdO4=.e2756648-a6ee-4095-b736-2dc71c24c83e@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
 <n6POjQ2WxpLAopmy7njkz2F3gaE8e6TRHDDLV_cmdO4=.e2756648-a6ee-4095-b736-2dc71c24c83e@github.com>
Message-ID: <oyWoLcg1X3IzXGK1LtIcXw1UgQBnpOheEOfsRhgWcOs=.adbc4cfc-44dc-4ad1-93de-c835a6d2d697@github.com>

On Thu, 22 May 2025 13:19:43 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
>> 
>> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed trailing whitespace

@manukumarvs 
Your change (at version 36338cac228a816a230ab707c1cb18ef9efe7f3d) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25319#issuecomment-2901447729

From jdv at openjdk.org  Thu May 22 14:32:55 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 22 May 2025 14:32:55 GMT
Subject: RFR: 8312198: [macos] metal pipeline - window rendering stops
 after display sleep
In-Reply-To: <d6zgy_4sAT6kmbFndfpL_MWucjhDu5mQIihLctsCgTk=.afec4640-5587-482d-8ffd-215fd06df834@github.com>
References: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
 <d6zgy_4sAT6kmbFndfpL_MWucjhDu5mQIihLctsCgTk=.afec4640-5587-482d-8ffd-215fd06df834@github.com>
Message-ID: <oqGmny5SJSoY2_zAmPiGgQ_O_QzOAXL14bI1uSBefHU=.04d775fb-0ba1-4619-bd8b-31f2d237cef2@github.com>

On Thu, 22 May 2025 03:04:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Is it possible that it is somehow related to 8304825? could be the layer created "during display sleep" and that might be in "sleep" more that 5 seconds?

This is follow-up fix for JDK-8304825. Basically we have a race condition because of timing issue when we are rendering many frame with animations. On screen wakeup CVDisplayLinkCreateWithActiveCGDisplays is failing because Active display list is still empty and we never create a displayLink and content to MTLLayer are never updated. By adding 5 retries with 1 secons gap after screen wakeup we are making sure that we are able to create displayLink for all active displays.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25342#issuecomment-2901453421

From serb at openjdk.org  Thu May 22 16:05:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 May 2025 16:05:50 GMT
Subject: RFR: 8312198: [macos] metal pipeline - window rendering stops
 after display sleep
In-Reply-To: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
References: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
Message-ID: <TZSK0mJdjbYfxaN9ICBHBCQrrBqhoHkEzV49euS3oRk=.ac35256b-1b76-4aa7-b82d-bf1b9bb601b1@github.com>

On Wed, 21 May 2025 06:11:18 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> In stress based scenarios it is observed that nothing is drawn in UI content when display wakes up from sleep in Metal pipeline of macOS. Unfortunately i am not able to reproduce it, but based on details in the bug it looks like we are hitting a race condition. Call to CVDisplayLinkCreateWithActiveCGDisplays is becoming a no-op as there are no active displays right after NSWorkspaceScreensDidWakeNotification. Looks like if we continue to call CVDisplayLinkCreateWithActiveCGDisplays after screen wakeup we are able to get the list of ActiveDisplays and then able to create displayLink.
> 
> So now the code is modified to check whether CVDisplayLinkCreateWithActiveCGDisplays is successful or not. If not we will try to call CVDisplayLinkCreateWithActiveCGDisplays for 5 instances each with 1 second delay. There is no regression test for this change because it needs a stress based test with display wakeup/sleep(As captured in JBS, i am not able to reproduce this issue).
> 
> I have tested this change for sanity by running animation examples from SwingSet2 and continuously connecting/disconnecting external display. Also by multiple display sleep and wakeup scenarios, i don't see any regressions. Also whole clientlibs CI run is done with this patch and it is also green.
> 
> While working on this bug also noticed that many functions of CVDisplayLink is deprecated from macOS 14 and going forward we need to use CADisplayLink/CAMetalDisplayLink. I have raised [JDK-8357418](https://bugs.openjdk.org/browse/JDK-8357418) for the same.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25342#pullrequestreview-2861806946

From kizune at openjdk.org  Thu May 22 16:06:52 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 22 May 2025 16:06:52 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v2]
In-Reply-To: <dEc4B--MJdbczbZaAooTdznvOgwL-xMcBh6VCaMj-Hg=.6b121ad8-79c6-4b45-b529-e989477bf208@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <dEc4B--MJdbczbZaAooTdznvOgwL-xMcBh6VCaMj-Hg=.6b121ad8-79c6-4b45-b529-e989477bf208@github.com>
Message-ID: <GaRDsd4MHZ7RHErct2iUuw-1MfhxlXr4HQtHpkXRHOk=.e373d84a-4d19-456a-a16e-a75c2d84c365@github.com>

On Tue, 20 May 2025 04:34:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
>> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
>> Fixed by setting the divider location before rendering the left and right components..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Click position fixed..L&F iteration

test/jdk/javax/swing/JSplitPane/TestSplitPaneResetDividerLoc.java line 65:

> 63:     private static volatile int curLoc;
> 64: 
> 65:      private static void setLookAndFeel(UIManager.LookAndFeelInfo laf) {

Cosmetic: invalid indentation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25294#discussion_r2102925156

From kizune at openjdk.org  Thu May 22 16:13:55 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 22 May 2025 16:13:55 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v2]
In-Reply-To: <dEc4B--MJdbczbZaAooTdznvOgwL-xMcBh6VCaMj-Hg=.6b121ad8-79c6-4b45-b529-e989477bf208@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <dEc4B--MJdbczbZaAooTdznvOgwL-xMcBh6VCaMj-Hg=.6b121ad8-79c6-4b45-b529-e989477bf208@github.com>
Message-ID: <bzVIqR5K2j_MvB5BWGRm1_Mz5SWC4Ihnlm7B_AwPljA=.fce36da7-e58f-423e-83da-9a9b78f7fafe@github.com>

On Tue, 20 May 2025 04:34:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
>> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
>> Fixed by setting the divider location before rendering the left and right components..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Click position fixed..L&F iteration

test/jdk/javax/swing/JSplitPane/TestSplitPaneResetDividerLoc.java line 80:

> 78:             System.out.println("Testing LAF : " + laf.getClassName());
> 79:             try {
> 80:                 setLookAndFeel(laf);

If setLookAndFeel encounters UnsupportedLookAndFeelException we will output the exception into stdout but we will do the entire test again with the previously installed LAF. Shall we do so? If we consider that exception as non-fatal for the test maybe we can make setLookAndFeel  method boolean instead of void returning true only if it was successfully installed new LAF and skip test iteration if it returns false?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25294#discussion_r2102938557

From jdv at openjdk.org  Thu May 22 16:15:54 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 22 May 2025 16:15:54 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine [v3]
In-Reply-To: <c2FRmUEOKhK0i4Mm1dHqdCyu5aCY6cMGE-xQFzSujmQ=.9a13234c-e073-4c12-946f-0d7d77d5f190@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
 <c2FRmUEOKhK0i4Mm1dHqdCyu5aCY6cMGE-xQFzSujmQ=.9a13234c-e073-4c12-946f-0d7d77d5f190@github.com>
Message-ID: <62roKFLSK75XExM2OcIjmkKomf7XbbOGT5j52X3j93Y=.12eed2fc-f2ee-445d-8c3b-0157222306c4@github.com>

On Mon, 19 May 2025 05:37:05 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Unfortunately I'm unable to reproduce this failure. I slowed the test down; it passes on my machine before and after this PR.
>> 
>> I added a little bit of logging that might also help identify what's happening.
>> 
>> Does anyone have any more suggestions?
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356061: removing robot
>   
>   This is in response to:
>   https://github.com/openjdk/jdk/pull/25244#issuecomment-2889420453

I think we can continue to keep this test case in its updated form of using BufferedImage as it is testing specific functional scenario.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25244#issuecomment-2901819937

From psadhukhan at openjdk.org  Thu May 22 16:27:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 22 May 2025 16:27:10 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v3]
In-Reply-To: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
Message-ID: <c8rvhtKVyoiVzKMHlFnTdQRgW-eCQgdOos8vrEo90gs=.dd26a998-c387-4a58-bbf6-3e4b462f5478@github.com>

> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
> Fixed by setting the divider location before rendering the left and right components..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Test fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25294/files
  - new: https://git.openjdk.org/jdk/pull/25294/files/d1671bdd..42c7c575

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25294&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25294&range=01-02

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25294/head:pull/25294

PR: https://git.openjdk.org/jdk/pull/25294

From psadhukhan at openjdk.org  Thu May 22 16:27:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 22 May 2025 16:27:10 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v2]
In-Reply-To: <bzVIqR5K2j_MvB5BWGRm1_Mz5SWC4Ihnlm7B_AwPljA=.fce36da7-e58f-423e-83da-9a9b78f7fafe@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <dEc4B--MJdbczbZaAooTdznvOgwL-xMcBh6VCaMj-Hg=.6b121ad8-79c6-4b45-b529-e989477bf208@github.com>
 <bzVIqR5K2j_MvB5BWGRm1_Mz5SWC4Ihnlm7B_AwPljA=.fce36da7-e58f-423e-83da-9a9b78f7fafe@github.com>
Message-ID: <oMCPQqkmr17xGjBYUf8_9YXXk-Sf1o4JgdcI53fRgIk=.c15de657-c38c-4a54-a32d-7dc0ae837e69@github.com>

On Thu, 22 May 2025 16:11:12 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Click position fixed..L&F iteration
>
> test/jdk/javax/swing/JSplitPane/TestSplitPaneResetDividerLoc.java line 80:
> 
>> 78:             System.out.println("Testing LAF : " + laf.getClassName());
>> 79:             try {
>> 80:                 setLookAndFeel(laf);
> 
> If setLookAndFeel encounters UnsupportedLookAndFeelException we will output the exception into stdout but we will do the entire test again with the previously installed LAF. Shall we do so? If we consider that exception as non-fatal for the test maybe we can make setLookAndFeel  method boolean instead of void returning true only if it was successfully installed new LAF and skip test iteration if it returns false?

ok..modified..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25294#discussion_r2102961779

From honkar at openjdk.org  Thu May 22 17:39:54 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 22 May 2025 17:39:54 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java
In-Reply-To: <45KN4daBBRbauQz-o9yzcmdYpZmQJTzRJOrT1axLf8U=.db20c011-ced6-41c1-ae49-cfd190373ca7@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
 <45KN4daBBRbauQz-o9yzcmdYpZmQJTzRJOrT1axLf8U=.db20c011-ced6-41c1-ae49-cfd190373ca7@github.com>
Message-ID: <zwpkD7LsHwsi-ALKlT12mmopurQsWHLc6bVWfndwrLk=.8586b593-09b7-40d5-97b7-5b0b129b1bc6@github.com>

On Mon, 19 May 2025 02:08:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs.
>> 
>> Test failure is not reproducible when the test is run individually (multiple times) on CI.
>> 
>> Rewritten the test and added debug logs that will be helpful to figure out the issue. 
>> 
>> - Added code to capture screenshot (entire screen as well as the frame) in case of failure.
>> - Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException.
>
> test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 88:
> 
>> 86: 
>> 87:     private static void createTestUI() {
>> 88:         frame = new Frame();
> 
> You do not need to call all these methods on the EDT, these are AWT components that should handle multithreaded usage (main/EDT/toolkit threads). It is possible that the issue is only reproducible on macOS due to synchronization problems related to the metal pipeline?

Recent AWT test updates have UI creation wrapped in EDT. I have seen many reviewers recommend using EDT even with AWT components.

Recently came across another PR where EDT is recommended. 
https://github.com/openjdk/jdk/pull/25278#discussion_r2100689626

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2103088406

From serb at openjdk.org  Thu May 22 19:03:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 May 2025 19:03:53 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine [v3]
In-Reply-To: <c2FRmUEOKhK0i4Mm1dHqdCyu5aCY6cMGE-xQFzSujmQ=.9a13234c-e073-4c12-946f-0d7d77d5f190@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
 <c2FRmUEOKhK0i4Mm1dHqdCyu5aCY6cMGE-xQFzSujmQ=.9a13234c-e073-4c12-946f-0d7d77d5f190@github.com>
Message-ID: <O5OnjbgUjkCWVrMWHSOrZHfrVy4iijIj4AlNPZNJjso=.d45ac8a2-1c5e-44a8-96f7-aa1f6a36ac36@github.com>

On Mon, 19 May 2025 05:37:05 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Unfortunately I'm unable to reproduce this failure. I slowed the test down; it passes on my machine before and after this PR.
>> 
>> I added a little bit of logging that might also help identify what's happening.
>> 
>> Does anyone have any more suggestions?
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356061: removing robot
>   
>   This is in response to:
>   https://github.com/openjdk/jdk/pull/25244#issuecomment-2889420453

It looks fine if mach5 is green

-------------

Marked as reviewed by serb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25244#pullrequestreview-2862294785

From prr at openjdk.org  Thu May 22 19:23:01 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 19:23:01 GMT
Subject: Integrated: 8357176: java.awt javadoc code examples still use Applet
 API
In-Reply-To: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
References: <WoouZwIyHbUaQpU4IslpzPjKCdG0XzlbjSXnovQnqyQ=.8d09e37b-5569-47f0-b18c-f3088fe16e68@github.com>
Message-ID: <145EscYp3RF-sYk1VOwrWLL-_pQQ_9CHsEnDKhSkNO0=.b84e053f-24fb-40b1-acc6-8ea520f6b420@github.com>

On Fri, 16 May 2025 23:04:28 GMT, Phil Race <prr at openjdk.org> wrote:

> Update the some code examples and accompanying images to no longer mention or display as applets.

This pull request has now been integrated.

Changeset: 139a05d0
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/139a05d05959a84541a29dfae6151f92ce579ae6
Stats:     176 lines in 17 files changed: 50 ins; 28 del; 98 mod

8357176: java.awt javadoc code examples still use Applet API

Reviewed-by: aivanov, serb

-------------

PR: https://git.openjdk.org/jdk/pull/25278

From duke at openjdk.org  Thu May 22 19:27:51 2025
From: duke at openjdk.org (duke)
Date: Thu, 22 May 2025 19:27:51 GMT
Subject: RFR: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine [v3]
In-Reply-To: <c2FRmUEOKhK0i4Mm1dHqdCyu5aCY6cMGE-xQFzSujmQ=.9a13234c-e073-4c12-946f-0d7d77d5f190@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
 <c2FRmUEOKhK0i4Mm1dHqdCyu5aCY6cMGE-xQFzSujmQ=.9a13234c-e073-4c12-946f-0d7d77d5f190@github.com>
Message-ID: <jmrXFzFwyWznNJKwwIHUS7tKPxvXFCtq0S0jwRH-qJA=.68b5f7b2-a316-4655-afec-6fd36e7cd9b6@github.com>

On Mon, 19 May 2025 05:37:05 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Unfortunately I'm unable to reproduce this failure. I slowed the test down; it passes on my machine before and after this PR.
>> 
>> I added a little bit of logging that might also help identify what's happening.
>> 
>> Does anyone have any more suggestions?
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356061: removing robot
>   
>   This is in response to:
>   https://github.com/openjdk/jdk/pull/25244#issuecomment-2889420453

@mickleness 
Your change (at version 9f91249a424b190990fc3056644b5aac8caa0a5b) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25244#issuecomment-2902317257

From prr at openjdk.org  Thu May 22 19:32:54 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 19:32:54 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v5]
In-Reply-To: <wXNo-gw_B0ukNg01ZLtpxk2gEDiftPVcDxBdV-Tq4mU=.70de0eb0-60e8-4cbf-9256-63765f485d0d@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <wXNo-gw_B0ukNg01ZLtpxk2gEDiftPVcDxBdV-Tq4mU=.70de0eb0-60e8-4cbf-9256-63765f485d0d@github.com>
Message-ID: <Gf6cJlC8Gkwrmhr-8RQncCtUxwmVE88ogJIqb-TFCVI=.57fd7524-25fe-4db6-9806-cf40c659401a@github.com>

On Thu, 22 May 2025 06:57:38 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The rendering of the directory names are handled as JLabel w.r.t Look and feel and also either Details/List view. Though FilePane creates basic rendering for these two few Look and Feel define their own renderers and also ComboBox Directory directory name view. Since HTML filtering is not taken care in any of these renderers, JLabel renders them as HTML document if nothing is set or specified.
>> The fix is to get "html.disable" property from JFileChooser and set the same to JLabel component which renders and set Directory name. Hence applications can either enable/disable this property and control HTML rendering of directory name.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated review comments

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24439#pullrequestreview-2862368075

From serb at openjdk.org  Thu May 22 19:48:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 May 2025 19:48:53 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v2]
In-Reply-To: <4E77iDP7SuXUkZWoGilK72r3FJevFbABugEyzd9ZDGU=.6d0e3b19-0c82-43e6-a17c-2fc91137a9eb@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <dEc4B--MJdbczbZaAooTdznvOgwL-xMcBh6VCaMj-Hg=.6b121ad8-79c6-4b45-b529-e989477bf208@github.com>
 <4E77iDP7SuXUkZWoGilK72r3FJevFbABugEyzd9ZDGU=.6d0e3b19-0c82-43e6-a17c-2fc91137a9eb@github.com>
Message-ID: <m-fe747i5r6xGNI092Y4I7fT2nFEMEJsznROuxF0sBo=.8a809fd9-404d-441b-aa26-1df62ae788d0@github.com>

On Wed, 21 May 2025 08:32:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Now if we call setDividerLocation it will set [dividerLocationIsSet](https://github.com/openjdk/jdk/blob/91194517c75a96fe7bcc2dcf5e9c42af9cf5975a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java#L1029) so even if `doReset `is true, it will not call `resetToPreferredSizes` but sets correct [divider location](https://github.com/openjdk/jdk/blob/91194517c75a96fe7bcc2dcf5e9c42af9cf5975a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java#L1436)

I am looking into this.

Just one unrelated question, why did we implemented in a way so we add and delete the left/right comps even if the orientation is not changed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25294#issuecomment-2902381713

From serb at openjdk.org  Thu May 22 19:57:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 May 2025 19:57:53 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java
In-Reply-To: <zwpkD7LsHwsi-ALKlT12mmopurQsWHLc6bVWfndwrLk=.8586b593-09b7-40d5-97b7-5b0b129b1bc6@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
 <45KN4daBBRbauQz-o9yzcmdYpZmQJTzRJOrT1axLf8U=.db20c011-ced6-41c1-ae49-cfd190373ca7@github.com>
 <zwpkD7LsHwsi-ALKlT12mmopurQsWHLc6bVWfndwrLk=.8586b593-09b7-40d5-97b7-5b0b129b1bc6@github.com>
Message-ID: <icxnrvZ3SZvVwQptHPyIuZyy4bvPStIcAPGM1Q2NTqM=.8159186e-1535-4be4-ba9c-681544fb1336@github.com>

On Thu, 22 May 2025 17:37:42 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 88:
>> 
>>> 86: 
>>> 87:     private static void createTestUI() {
>>> 88:         frame = new Frame();
>> 
>> You do not need to call all these methods on the EDT, these are AWT components that should handle multithreaded usage (main/EDT/toolkit threads). It is possible that the issue is only reproducible on macOS due to synchronization problems related to the metal pipeline?
>
> Recent AWT test updates have UI creation wrapped in EDT. I have seen many reviewers recommend using EDT even with AWT components.
> 
> Recently came across another PR where EDT is recommended. 
> https://github.com/openjdk/jdk/pull/25278#discussion_r2098939094
> https://github.com/openjdk/jdk/pull/25278#discussion_r2100689626

For external use in apps we can recommend it so it will be unified for swing and awt, but for internal use we cannot simply switch to EDT as a cleanup or a bug fix. The code related to awt/2d runs in various threads and must be properly synchronized.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2103303179

From serb at openjdk.org  Thu May 22 20:01:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 May 2025 20:01:54 GMT
Subject: RFR: 8139228: JFileChooser renders file names as HTML document
 [v5]
In-Reply-To: <wXNo-gw_B0ukNg01ZLtpxk2gEDiftPVcDxBdV-Tq4mU=.70de0eb0-60e8-4cbf-9256-63765f485d0d@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
 <wXNo-gw_B0ukNg01ZLtpxk2gEDiftPVcDxBdV-Tq4mU=.70de0eb0-60e8-4cbf-9256-63765f485d0d@github.com>
Message-ID: <tXtSitrV2PPdMu3J1vJbwM2CZlf-cadHNGoij9Q4yD0=.493fcc45-f8ed-44e9-8f7a-c0601128c5b1@github.com>

On Thu, 22 May 2025 06:57:38 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The rendering of the directory names are handled as JLabel w.r.t Look and feel and also either Details/List view. Though FilePane creates basic rendering for these two few Look and Feel define their own renderers and also ComboBox Directory directory name view. Since HTML filtering is not taken care in any of these renderers, JLabel renders them as HTML document if nothing is set or specified.
>> The fix is to get "html.disable" property from JFileChooser and set the same to JLabel component which renders and set Directory name. Hence applications can either enable/disable this property and control HTML rendering of directory name.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated review comments

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24439#pullrequestreview-2862429352

From serb at openjdk.org  Thu May 22 20:11:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 May 2025 20:11:53 GMT
Subject: RFR: 8355904: Use variadic macros for J2dTrace [v5]
In-Reply-To: <BWWuwKtEvZFmcq-x0ApZ2lfuABe0hz0EvmYn-rnl63w=.0d49cda1-a111-42b0-b795-3153628d2d8f@github.com>
References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
 <BWWuwKtEvZFmcq-x0ApZ2lfuABe0hz0EvmYn-rnl63w=.0d49cda1-a111-42b0-b795-3153628d2d8f@github.com>
Message-ID: <LzPiitaZvoY6XwEiMCcs8bVBuaYEfy_8EjdWZ9VBPmw=.30df864f-2bfc-493b-a591-1445271b1d8e@github.com>

On Wed, 21 May 2025 12:33:40 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> J2dTrace macros have multiple overloads specifying number of arguments, making it less convent to change number of arguments. There were cases when existing macros were not enough and people had to add new variants with even more arguments. We could simply use variadic macros instead.
>> 
>> Also, currently those macros expand to a { code block }, which doesn't require a semicolon at the end, so it can sometimes be missed, leading to an inconsistent code style. We could expand it directly to the function, forcing user to insert a semicolon after that, in a function-like style.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! 8355904: Use variadic macros for J2dTrace

src/java.desktop/windows/native/libawt/java2d/d3d/D3DShaderGen.c line 59:

> 57: // REMIND
> 58: //#define J2dTraceLn(a, b) fprintf(stderr, "%s\n", b);
> 59: //#define J2dTraceLn(a, b, c) fprintf(stderr, b, c);

It looks like the above commented J2dTraceLn for arguments 0 and 1 now conflicts?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2103321639

From dnguyen at openjdk.org  Thu May 22 20:21:49 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 22 May 2025 20:21:49 GMT
Subject: RFR: 8356814: LineBreakMeasurer.nextLayout() slower than necessary
 when no break needed
In-Reply-To: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>
References: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>
Message-ID: <eALXiueXlp7Z6fGehVjvOy9mzzARhcLjVpf_U3fvdcw=.4f740ccd-a654-4556-a528-518c40889498@github.com>

On Mon, 12 May 2025 20:35:52 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> `LineBreakMeasurer.nextLayout()` calls `nextOffset()` internally to calculate the layout limit. When this happens, a `GlyphVector` is created and the layout engine is invoked to shape the text. The `GlyphVector` is cached in the relevant `ExtendedTextSourceLabel` component.
> 
> `LineBreakMeasurer.nextLayout()` then calls `TextMeasurer.getLayout()` which eventually asks that same `ExtendedTextSourceLabel` component for a subset component. This triggers the creation of a fresh `ExtendedTextSourceLabel` without the cached `GlyphVector`.
> 
> However, this fresh `ExtendedTextSourceLabel` is not necessary if the subset requested perfectly matches the already-existing `ExtendedTextSourceLabel` component. This happens when the text is short enough that no line break is needed.
> 
> I think we should change `ExtendedTextSourceLabel.getSubset()` to return `this` if the requested subset is identical to the existing instance. This will allow us to use the existing cached `GlyphVector`, and the call to `LineBreakMeasurer.nextLayout()` will trigger text shaping once, rather than twice.
> 
> In local testing, the test program below ran in ~1250 ms before this optimization, and ran in ~960 ms after the change (a 23% reduction in run time).
> 
> The following three existing test classes provide good regression test coverage for this change:
> - test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTrackingAuto
> - test/jdk/java/awt/font/LineBreakMeasurer/TestLineBreakWithFontSub
> - test/jdk/java/awt/font/LineBreakMeasurer/FRCTest
> 
> 
> public class LineBreakMeasurerPerfTest {
> 
>     public static void main(String[] args) {
> 
>         float advance = 0;
>         long start = System.currentTimeMillis();
>         AttributedString string = new AttributedString("This is a test.");
>         FontRenderContext frc = new FontRenderContext(new AffineTransform(), true, true);
> 
>         for (int i = 0; i < 100_000; i++) {
>             LineBreakMeasurer measurer = new LineBreakMeasurer(string.getIterator(), frc);
>             TextLayout layout = measurer.nextLayout(999); // large enough to not require break
>             advance = Math.max(advance, layout.getAdvance());
>         }
> 
>         long end = System.currentTimeMillis();
>         System.out.println((end - start) + " ms elapsed (advance: " + advance + ")");
>     }
> 
> }

The conditions for the case where we'd return "as-is" makes sense to me. I tested these with & without the changes as well and saw some reductions to the total elapsed runtime. Although some are small, there's some variance and I never saw an increase to the runtime total. Change LGTM.

-------------

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25193#pullrequestreview-2862472099

From duke at openjdk.org  Thu May 22 20:26:51 2025
From: duke at openjdk.org (duke)
Date: Thu, 22 May 2025 20:26:51 GMT
Subject: RFR: 8356814: LineBreakMeasurer.nextLayout() slower than necessary
 when no break needed
In-Reply-To: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>
References: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>
Message-ID: <tv4DVrrvJKM94a-g2W-uC-qnW17JinuF6TAuDVUHUEo=.6c7ddc32-7d23-41c2-b336-6261bcd660cd@github.com>

On Mon, 12 May 2025 20:35:52 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> `LineBreakMeasurer.nextLayout()` calls `nextOffset()` internally to calculate the layout limit. When this happens, a `GlyphVector` is created and the layout engine is invoked to shape the text. The `GlyphVector` is cached in the relevant `ExtendedTextSourceLabel` component.
> 
> `LineBreakMeasurer.nextLayout()` then calls `TextMeasurer.getLayout()` which eventually asks that same `ExtendedTextSourceLabel` component for a subset component. This triggers the creation of a fresh `ExtendedTextSourceLabel` without the cached `GlyphVector`.
> 
> However, this fresh `ExtendedTextSourceLabel` is not necessary if the subset requested perfectly matches the already-existing `ExtendedTextSourceLabel` component. This happens when the text is short enough that no line break is needed.
> 
> I think we should change `ExtendedTextSourceLabel.getSubset()` to return `this` if the requested subset is identical to the existing instance. This will allow us to use the existing cached `GlyphVector`, and the call to `LineBreakMeasurer.nextLayout()` will trigger text shaping once, rather than twice.
> 
> In local testing, the test program below ran in ~1250 ms before this optimization, and ran in ~960 ms after the change (a 23% reduction in run time).
> 
> The following three existing test classes provide good regression test coverage for this change:
> - test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTrackingAuto
> - test/jdk/java/awt/font/LineBreakMeasurer/TestLineBreakWithFontSub
> - test/jdk/java/awt/font/LineBreakMeasurer/FRCTest
> 
> 
> public class LineBreakMeasurerPerfTest {
> 
>     public static void main(String[] args) {
> 
>         float advance = 0;
>         long start = System.currentTimeMillis();
>         AttributedString string = new AttributedString("This is a test.");
>         FontRenderContext frc = new FontRenderContext(new AffineTransform(), true, true);
> 
>         for (int i = 0; i < 100_000; i++) {
>             LineBreakMeasurer measurer = new LineBreakMeasurer(string.getIterator(), frc);
>             TextLayout layout = measurer.nextLayout(999); // large enough to not require break
>             advance = Math.max(advance, layout.getAdvance());
>         }
> 
>         long end = System.currentTimeMillis();
>         System.out.println((end - start) + " ms elapsed (advance: " + advance + ")");
>     }
> 
> }

@gredler 
Your change (at version b0f194a43769d3d5a6b4d2befe03d96a5b01ef8a) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25193#issuecomment-2902464077

From honkar at openjdk.org  Thu May 22 20:35:52 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 22 May 2025 20:35:52 GMT
Subject: RFR: 8356814: LineBreakMeasurer.nextLayout() slower than necessary
 when no break needed
In-Reply-To: <gEb88_bZtRzaF6s4Jj4VZMNODz7cFG2qLcn2CMGC6fc=.2bb02b0c-34d5-427c-a6fc-c892398b209e@github.com>
References: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>
 <gEb88_bZtRzaF6s4Jj4VZMNODz7cFG2qLcn2CMGC6fc=.2bb02b0c-34d5-427c-a6fc-c892398b209e@github.com>
Message-ID: <kPaNK5jnaXKM_Fud_hzE_t_fdGTxPOEE0Q12nrp-0FM=.525fda7d-6c56-496f-b59d-932ca61899a7@github.com>

On Mon, 19 May 2025 12:26:54 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> `LineBreakMeasurer.nextLayout()` calls `nextOffset()` internally to calculate the layout limit. When this happens, a `GlyphVector` is created and the layout engine is invoked to shape the text. The `GlyphVector` is cached in the relevant `ExtendedTextSourceLabel` component.
>> 
>> `LineBreakMeasurer.nextLayout()` then calls `TextMeasurer.getLayout()` which eventually asks that same `ExtendedTextSourceLabel` component for a subset component. This triggers the creation of a fresh `ExtendedTextSourceLabel` without the cached `GlyphVector`.
>> 
>> However, this fresh `ExtendedTextSourceLabel` is not necessary if the subset requested perfectly matches the already-existing `ExtendedTextSourceLabel` component. This happens when the text is short enough that no line break is needed.
>> 
>> I think we should change `ExtendedTextSourceLabel.getSubset()` to return `this` if the requested subset is identical to the existing instance. This will allow us to use the existing cached `GlyphVector`, and the call to `LineBreakMeasurer.nextLayout()` will trigger text shaping once, rather than twice.
>> 
>> In local testing, the test program below ran in ~1250 ms before this optimization, and ran in ~960 ms after the change (a 23% reduction in run time).
>> 
>> The following three existing test classes provide good regression test coverage for this change:
>> - test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTrackingAuto
>> - test/jdk/java/awt/font/LineBreakMeasurer/TestLineBreakWithFontSub
>> - test/jdk/java/awt/font/LineBreakMeasurer/FRCTest
>> 
>> 
>> public class LineBreakMeasurerPerfTest {
>> 
>>     public static void main(String[] args) {
>> 
>>         float advance = 0;
>>         long start = System.currentTimeMillis();
>>         AttributedString string = new AttributedString("This is a test.");
>>         FontRenderContext frc = new FontRenderContext(new AffineTransform(), true, true);
>> 
>>         for (int i = 0; i < 100_000; i++) {
>>             LineBreakMeasurer measurer = new LineBreakMeasurer(string.getIterator(), frc);
>>             TextLayout layout = measurer.nextLayout(999); // large enough to not require break
>>             advance = Math.max(advance, layout.getAdvance());
>>         }
>> 
>>         long end = System.currentTimeMillis();
>>         System.out.println((end - start) + " ms elapsed (advance: " + advance + ")");
>>     }
>> 
>> }
>
> If any reviewers have some extra cycles, I'd appreciate a second review on this one. Thanks!

@gredler I'm in the process of reviewing it. I can sponsor the PR once done with testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25193#issuecomment-2902500432

From ngubarkov at openjdk.org  Thu May 22 20:44:30 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Thu, 22 May 2025 20:44:30 GMT
Subject: RFR: 8355904: Use variadic macros for J2dTrace [v6]
In-Reply-To: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
Message-ID: <rNnbkM8NpX0HYVUh0rPOnohIycsaLtvTDFBx4Un38G8=.b2e95ecc-8e7e-4f41-85ca-51c7556fd573@github.com>

> J2dTrace macros have multiple overloads specifying number of arguments, making it less convent to change number of arguments. There were cases when existing macros were not enough and people had to add new variants with even more arguments. We could simply use variadic macros instead.
> 
> Also, currently those macros expand to a { code block }, which doesn't require a semicolon at the end, so it can sometimes be missed, leading to an inconsistent code style. We could expand it directly to the function, forcing user to insert a semicolon after that, in a function-like style.

Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:

  Update D3DShaderGen.c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24949/files
  - new: https://git.openjdk.org/jdk/pull/24949/files/98ec5087..41ce75f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24949&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24949&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24949.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24949/head:pull/24949

PR: https://git.openjdk.org/jdk/pull/24949

From ngubarkov at openjdk.org  Thu May 22 20:44:30 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Thu, 22 May 2025 20:44:30 GMT
Subject: RFR: 8355904: Use variadic macros for J2dTrace [v5]
In-Reply-To: <LzPiitaZvoY6XwEiMCcs8bVBuaYEfy_8EjdWZ9VBPmw=.30df864f-2bfc-493b-a591-1445271b1d8e@github.com>
References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
 <BWWuwKtEvZFmcq-x0ApZ2lfuABe0hz0EvmYn-rnl63w=.0d49cda1-a111-42b0-b795-3153628d2d8f@github.com>
 <LzPiitaZvoY6XwEiMCcs8bVBuaYEfy_8EjdWZ9VBPmw=.30df864f-2bfc-493b-a591-1445271b1d8e@github.com>
Message-ID: <EnZ1mmHQBO19ovcyu13FB4IK1ec6wloR7izSGdKgEik=.7ee30edf-e483-4df7-8365-6cd46aeb5b4f@github.com>

On Thu, 22 May 2025 20:09:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! 8355904: Use variadic macros for J2dTrace
>
> src/java.desktop/windows/native/libawt/java2d/d3d/D3DShaderGen.c line 59:
> 
>> 57: // REMIND
>> 58: //#define J2dTraceLn(a, b) fprintf(stderr, "%s\n", b);
>> 59: //#define J2dTraceLn(a, b, c) fprintf(stderr, b, c);
> 
> It looks like the above commented J2dTraceLn for arguments 0 and 1 now conflicts?

Should be better now

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24949#discussion_r2103367518

From prr at openjdk.org  Thu May 22 21:11:54 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 21:11:54 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v13]
In-Reply-To: <CntGph5PSS5ifIZ9p2tEKs4wruI69vd5JRNkxn5GMmI=.573d97a7-1462-4800-8966-5afb9538e14a@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
 <bNRrYna0tu4wKw1EVwHGweiHDx0wRwPGS9KKPIeX5HA=.4305b22a-a2fe-4ed3-a2f2-4ef6875e757b@github.com>
 <CntGph5PSS5ifIZ9p2tEKs4wruI69vd5JRNkxn5GMmI=.573d97a7-1462-4800-8966-5afb9538e14a@github.com>
Message-ID: <aoKbedJ6s9VFmJjWB54D8UHHAmgLjq9S4JqaX9tn2kg=.c5f1bc44-1af9-44de-a342-e2e20ea2ead3@github.com>

On Tue, 13 May 2025 03:42:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Moreover, it looks like as part of the "unification" the fix dropped clamping code in Robot (!)
> > https://cr.openjdk.org/%7Epchelko/9/8035568/webrev.02/src/macosx/native/sun/awt/CRobot.m.udiff.html
> 
> That code executed only if the current mouse position is unknown or outside of the mainscreen, that native code was moved to the java level into the CRobot class by the patch: https://cr.openjdk.org/~pchelko/9/8035568/webrev.02/src/macosx/classes/sun/lwawt/macosx/CRobot.java.sdiff.html

ah, that's the code that executes only once, first time when robot doesn't yet "know" where it believes the pointer is.
interesting that it clamps in this case. But it isn't multi-display capable.

The native reproducer shows the same behaviour as the JDK.
We can send it to Apple but the code in this PR should be pushed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2902578649

From honkar at openjdk.org  Thu May 22 21:22:51 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 22 May 2025 21:22:51 GMT
Subject: RFR: 8356814: LineBreakMeasurer.nextLayout() slower than necessary
 when no break needed
In-Reply-To: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>
References: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>
Message-ID: <mBgpGJ0Npt3JoDlUw21UcPhR9CP6IWgH0fUNZu0QcU4=.6b6c8c84-a762-40e7-ba16-9fc7def5da30@github.com>

On Mon, 12 May 2025 20:35:52 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> `LineBreakMeasurer.nextLayout()` calls `nextOffset()` internally to calculate the layout limit. When this happens, a `GlyphVector` is created and the layout engine is invoked to shape the text. The `GlyphVector` is cached in the relevant `ExtendedTextSourceLabel` component.
> 
> `LineBreakMeasurer.nextLayout()` then calls `TextMeasurer.getLayout()` which eventually asks that same `ExtendedTextSourceLabel` component for a subset component. This triggers the creation of a fresh `ExtendedTextSourceLabel` without the cached `GlyphVector`.
> 
> However, this fresh `ExtendedTextSourceLabel` is not necessary if the subset requested perfectly matches the already-existing `ExtendedTextSourceLabel` component. This happens when the text is short enough that no line break is needed.
> 
> I think we should change `ExtendedTextSourceLabel.getSubset()` to return `this` if the requested subset is identical to the existing instance. This will allow us to use the existing cached `GlyphVector`, and the call to `LineBreakMeasurer.nextLayout()` will trigger text shaping once, rather than twice.
> 
> In local testing, the test program below ran in ~1250 ms before this optimization, and ran in ~960 ms after the change (a 23% reduction in run time).
> 
> The following three existing test classes provide good regression test coverage for this change:
> - test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTrackingAuto
> - test/jdk/java/awt/font/LineBreakMeasurer/TestLineBreakWithFontSub
> - test/jdk/java/awt/font/LineBreakMeasurer/FRCTest
> 
> 
> public class LineBreakMeasurerPerfTest {
> 
>     public static void main(String[] args) {
> 
>         float advance = 0;
>         long start = System.currentTimeMillis();
>         AttributedString string = new AttributedString("This is a test.");
>         FontRenderContext frc = new FontRenderContext(new AffineTransform(), true, true);
> 
>         for (int i = 0; i < 100_000; i++) {
>             LineBreakMeasurer measurer = new LineBreakMeasurer(string.getIterator(), frc);
>             TextLayout layout = measurer.nextLayout(999); // large enough to not require break
>             advance = Math.max(advance, layout.getAdvance());
>         }
> 
>         long end = System.currentTimeMillis();
>         System.out.println((end - start) + " ms elapsed (advance: " + advance + ")");
>     }
> 
> }

LGTM. Ran LineBreakMeasurer tests, in particular the manual test LineBreakWithTracking.java to see if there was an effect of tracking + manual window resize on the line break lengths. There were multiple instances when the same object was returned so the fix looks beneficial in those case. Did not observe any regressions.

With the POC, noticed ~1000ms difference without and with fix on some runs.

-------------

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25193#pullrequestreview-2862595417

From dgredler at openjdk.org  Thu May 22 21:27:55 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 22 May 2025 21:27:55 GMT
Subject: Integrated: 8356814: LineBreakMeasurer.nextLayout() slower than
 necessary when no break needed
In-Reply-To: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>
References: <aDSlSlCtGefk1hw_nQd5sJiComVicW2oJhiKA1W4G8g=.651e8afb-0b99-4c8c-8203-4c532f11070f@github.com>
Message-ID: <jjDhXqMI_ezdouBsnPx0HHhCW3Gklkl5EEqsxw5k6Gs=.99fc8074-e43e-45ec-aaa5-87eeec25c438@github.com>

On Mon, 12 May 2025 20:35:52 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> `LineBreakMeasurer.nextLayout()` calls `nextOffset()` internally to calculate the layout limit. When this happens, a `GlyphVector` is created and the layout engine is invoked to shape the text. The `GlyphVector` is cached in the relevant `ExtendedTextSourceLabel` component.
> 
> `LineBreakMeasurer.nextLayout()` then calls `TextMeasurer.getLayout()` which eventually asks that same `ExtendedTextSourceLabel` component for a subset component. This triggers the creation of a fresh `ExtendedTextSourceLabel` without the cached `GlyphVector`.
> 
> However, this fresh `ExtendedTextSourceLabel` is not necessary if the subset requested perfectly matches the already-existing `ExtendedTextSourceLabel` component. This happens when the text is short enough that no line break is needed.
> 
> I think we should change `ExtendedTextSourceLabel.getSubset()` to return `this` if the requested subset is identical to the existing instance. This will allow us to use the existing cached `GlyphVector`, and the call to `LineBreakMeasurer.nextLayout()` will trigger text shaping once, rather than twice.
> 
> In local testing, the test program below ran in ~1250 ms before this optimization, and ran in ~960 ms after the change (a 23% reduction in run time).
> 
> The following three existing test classes provide good regression test coverage for this change:
> - test/jdk/java/awt/font/LineBreakMeasurer/LineBreakWithTrackingAuto
> - test/jdk/java/awt/font/LineBreakMeasurer/TestLineBreakWithFontSub
> - test/jdk/java/awt/font/LineBreakMeasurer/FRCTest
> 
> 
> public class LineBreakMeasurerPerfTest {
> 
>     public static void main(String[] args) {
> 
>         float advance = 0;
>         long start = System.currentTimeMillis();
>         AttributedString string = new AttributedString("This is a test.");
>         FontRenderContext frc = new FontRenderContext(new AffineTransform(), true, true);
> 
>         for (int i = 0; i < 100_000; i++) {
>             LineBreakMeasurer measurer = new LineBreakMeasurer(string.getIterator(), frc);
>             TextLayout layout = measurer.nextLayout(999); // large enough to not require break
>             advance = Math.max(advance, layout.getAdvance());
>         }
> 
>         long end = System.currentTimeMillis();
>         System.out.println((end - start) + " ms elapsed (advance: " + advance + ")");
>     }
> 
> }

This pull request has now been integrated.

Changeset: fdda7661
Author:    Daniel Gredler <dgredler at openjdk.org>
Committer: Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fdda7661906eab63d939e9f482449e21cc143c8f
Stats:     8 lines in 1 file changed: 7 ins; 0 del; 1 mod

8356814: LineBreakMeasurer.nextLayout() slower than necessary when no break needed

Reviewed-by: prr, dnguyen, honkar

-------------

PR: https://git.openjdk.org/jdk/pull/25193

From prr at openjdk.org  Thu May 22 21:28:53 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 21:28:53 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
 <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
 <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>
 <bffWy8H4d6xnje0Gz_jIyv5jPBMuqp7S-iBFZTioTng=.7ee33246-76c2-470f-b608-894b5ba93988@github.com>
 <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com>
Message-ID: <2QcYZvy5pjx8J6Fi6j59uiHSfnqkp1yUHakx2qsxzKw=.d5720f94-adb8-4f86-aeed-e403c8e43066@github.com>

On Thu, 15 May 2025 12:33:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>>> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?
>> 
>> That seems unlikely. The pattern is used consistently in the French translations, where `Foo:` in the original is replaced with `Foo :` with a non-breaking space. I guess it is a French orthographic rule to have a space before the colon, and I understand why it really must be non-breaking in that case.
>
> FYI, the style guide for France [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France):
> 
> - U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark, and exclamation mark.
> - U+00A0 (No-Break Space NBSP) preceding colon.
> 
> Similar conventions are used in other French speaking countries.

> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences.

> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space.


I didn't say it reversed that entire changeset. I am saying that the previous changeset for L10N changed

the Java unicode escape to UTF-8 for the localised message string.

You propose restoring it to Java escape.


I wouldn't be surprised if the next message drop reverses what you reversed.

I don't know what tools the L10N team use but there's a chance it doesn't handle Java escapes

since that is very much a Java thing. So you are probably making the translation job harder.


So I am suggesting you leave all of the translation files as is.
Which might mean withdrawing this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2103421828

From prr at openjdk.org  Thu May 22 21:34:50 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 21:34:50 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <zS5WZR4Cen8tmwZk_Y4kSHU3wpLpMysoCv5WfF4yRUM=.4c035191-6fb5-46f2-ab11-f35701183529@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Just speaking for the one client demo.
Someone else will need to review the other 98% of this PR

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25229#pullrequestreview-2862613813

From serb at openjdk.org  Thu May 22 21:35:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 May 2025 21:35:55 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v13]
In-Reply-To: <aoKbedJ6s9VFmJjWB54D8UHHAmgLjq9S4JqaX9tn2kg=.c5f1bc44-1af9-44de-a342-e2e20ea2ead3@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
 <bNRrYna0tu4wKw1EVwHGweiHDx0wRwPGS9KKPIeX5HA=.4305b22a-a2fe-4ed3-a2f2-4ef6875e757b@github.com>
 <CntGph5PSS5ifIZ9p2tEKs4wruI69vd5JRNkxn5GMmI=.573d97a7-1462-4800-8966-5afb9538e14a@github.com>
 <aoKbedJ6s9VFmJjWB54D8UHHAmgLjq9S4JqaX9tn2kg=.c5f1bc44-1af9-44de-a342-e2e20ea2ead3@github.com>
Message-ID: <bevGfJBruLf2-ykL6A_ZcDH_7081qf-vuYajPvyPD3M=.a410050d-d3a3-47de-a53d-c7f4e417fff0@github.com>

On Thu, 22 May 2025 21:09:33 GMT, Phil Race <prr at openjdk.org> wrote:

> The native reproducer shows the same behaviour as the JDK.
> We can send it to Apple but the code in this PR should be pushed

So Java works like any other native apps that emits native events, let's see what the response will be. This is not a regression and is not reported by some customers, it is not even clear if this is a bug and not an OS feature, no need to rush w/o Apple's response.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2902622708

From prr at openjdk.org  Thu May 22 21:45:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 21:45:52 GMT
Subject: RFR: 8356977: UTF-8 cleanups
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>

On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49:

> 47:  * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by
> 48:  * <p>
> 49:  * <code>MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false);</code>

This is javadoc inJava SE specification. As is the Action case below.
I can't think of any actual harm from this change, so OK,  but I am not seeing why it is needed.

test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:

> 61: 
> 62:     private static final String INSTRUCTIONS =
> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "

I really don't like these tests being changed. It isn't part of the JDK build.
People compile these in all sorts of locales.
Please revert all the changes in the client tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103439338
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103431874

From prr at openjdk.org  Thu May 22 21:51:54 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 21:51:54 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v13]
In-Reply-To: <bevGfJBruLf2-ykL6A_ZcDH_7081qf-vuYajPvyPD3M=.a410050d-d3a3-47de-a53d-c7f4e417fff0@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
 <bNRrYna0tu4wKw1EVwHGweiHDx0wRwPGS9KKPIeX5HA=.4305b22a-a2fe-4ed3-a2f2-4ef6875e757b@github.com>
 <CntGph5PSS5ifIZ9p2tEKs4wruI69vd5JRNkxn5GMmI=.573d97a7-1462-4800-8966-5afb9538e14a@github.com>
 <aoKbedJ6s9VFmJjWB54D8UHHAmgLjq9S4JqaX9tn2kg=.c5f1bc44-1af9-44de-a342-e2e20ea2ead3@github.com>
 <bevGfJBruLf2-ykL6A_ZcDH_7081qf-vuYajPvyPD3M=.a410050d-d3a3-47de-a53d-c7f4e417fff0@github.com>
Message-ID: <6B_XF-1U3nX2mJ6lQbA4XDgCAOV_CowpksH2OcY1QVw=.79131b1b-d2bc-4d00-aaf1-6c3e3a65bdc8@github.com>

On Thu, 22 May 2025 21:33:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > The native reproducer shows the same behaviour as the JDK.
> > We can send it to Apple but the code in this PR should be pushed
> 
> So Java works like any other native apps that emits native events, let's see what the response will be. This is not a regression and is not reported by some customers, it is not even clear if this is a bug and not an OS feature, no need to rush w/o Apple's response.

Let's look at the outcomes
- No answer from Apple 
 - Apple say its a feature
-  Apple say it is a bug but they won't fix it
- Apple say its a bug and will be fixed in a future macOS

even in the last case a fix in JDK would help all existing OSes.

So I don't follow the reasoning of waiting for any of the above answers - likely for many months but most likely (the 90% case) forever.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2902650268

From achung at openjdk.org  Thu May 22 22:02:55 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 22 May 2025 22:02:55 GMT
Subject: RFR: 8357299: Graphics copyArea doesn't copy any pixels when there
 is overflow
In-Reply-To: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
References: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
Message-ID: <FqXvZkVNDkn3O1eCmK5ZwBy1tyoWykNu9PTefLp_ODc=.6fec035e-42a2-410d-ba80-12bcfa01c754@github.com>

On Wed, 21 May 2025 03:17:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Graphics copyArea overflow check bails out of copying pixels if there is overflow.
> The spec says ""If a portion of the source rectangle lies outside the bounds of the component, or is obscured by another window or component, {@code copyArea} *will be unable to copy* the associated pixels"
> 
> which suggests that we should always copy the parts inside the bounds and never the parts outside the bounds
> but it seems currently, in the case of overflow it no longer copies any pixels, including the parts that are inside. 
> So, the fix clips the copyarea region to clip bounds so it will only affect pixels within the valid bounds, and any pixels outside will be ignored.

Tested locally on macOS and test fails before the change and passes after the change.

-------------

Marked as reviewed by achung (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25340#pullrequestreview-2862659052

From kizune at openjdk.org  Thu May 22 22:25:52 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 22 May 2025 22:25:52 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v3]
In-Reply-To: <c8rvhtKVyoiVzKMHlFnTdQRgW-eCQgdOos8vrEo90gs=.dd26a998-c387-4a58-bbf6-3e4b462f5478@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <c8rvhtKVyoiVzKMHlFnTdQRgW-eCQgdOos8vrEo90gs=.dd26a998-c387-4a58-bbf6-3e4b462f5478@github.com>
Message-ID: <FpEzEOKh0FxGgrS91PduESrm0HcBXu7GzKebuVHgylk=.107dd21e-542b-40ff-a72e-d46404aca090@github.com>

On Thu, 22 May 2025 16:27:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
>> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
>> Fixed by setting the divider location before rendering the left and right components..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

Marked as reviewed by kizune (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25294#pullrequestreview-2862701456

From prr at openjdk.org  Thu May 22 22:33:54 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 22:33:54 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
Message-ID: <eLWg0Ie5Yo4Kirp8Bg_4Yklh9zRPa706CKgEMpWnvNw=.0ba1fb1d-a842-4c43-89f1-acffa176245c@github.com>

On Tue, 13 May 2025 21:28:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

This API is not so different than the Applet AudioClip because it is a simple replacement for that which is intended to be used by desktop apps - not browsers any more.
In that sense the preview of it has been there since 1995 so I think we are good.
In the future, like any class, new methods can be added but the ones it has now are the ones that it needs to start with.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2902750767

From prr at openjdk.org  Thu May 22 22:38:53 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 22:38:53 GMT
Subject: RFR: 8312198: [macos] metal pipeline - window rendering stops
 after display sleep
In-Reply-To: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
References: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
Message-ID: <k173WQP6bqQ_q_kYFid1YAbHIZR_W25p35udxuabP8I=.a3c5d2e2-7faf-449b-86c4-b24dd9f7591b@github.com>

On Wed, 21 May 2025 06:11:18 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> In stress based scenarios it is observed that nothing is drawn in UI content when display wakes up from sleep in Metal pipeline of macOS. Unfortunately i am not able to reproduce it, but based on details in the bug it looks like we are hitting a race condition. Call to CVDisplayLinkCreateWithActiveCGDisplays is becoming a no-op as there are no active displays right after NSWorkspaceScreensDidWakeNotification. Looks like if we continue to call CVDisplayLinkCreateWithActiveCGDisplays after screen wakeup we are able to get the list of ActiveDisplays and then able to create displayLink.
> 
> So now the code is modified to check whether CVDisplayLinkCreateWithActiveCGDisplays is successful or not. If not we will try to call CVDisplayLinkCreateWithActiveCGDisplays for 5 instances each with 1 second delay. There is no regression test for this change because it needs a stress based test with display wakeup/sleep(As captured in JBS, i am not able to reproduce this issue).
> 
> I have tested this change for sanity by running animation examples from SwingSet2 and continuously connecting/disconnecting external display. Also by multiple display sleep and wakeup scenarios, i don't see any regressions. Also whole clientlibs CI run is done with this patch and it is also green.
> 
> While working on this bug also noticed that many functions of CVDisplayLink is deprecated from macOS 14 and going forward we need to use CADisplayLink/CAMetalDisplayLink. I have raised [JDK-8357418](https://bugs.openjdk.org/browse/JDK-8357418) for the same.

I build and tested this on x64 - subjecting it to abuse running SwingSet .. unplugging and plugging back the external monitor, sleeping .. plugging in a monitor while asleep etc etc.
No bad behaviour.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25342#pullrequestreview-2862716745

From serb at openjdk.org  Thu May 22 22:44:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 May 2025 22:44:57 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v13]
In-Reply-To: <6B_XF-1U3nX2mJ6lQbA4XDgCAOV_CowpksH2OcY1QVw=.79131b1b-d2bc-4d00-aaf1-6c3e3a65bdc8@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
 <bNRrYna0tu4wKw1EVwHGweiHDx0wRwPGS9KKPIeX5HA=.4305b22a-a2fe-4ed3-a2f2-4ef6875e757b@github.com>
 <CntGph5PSS5ifIZ9p2tEKs4wruI69vd5JRNkxn5GMmI=.573d97a7-1462-4800-8966-5afb9538e14a@github.com>
 <aoKbedJ6s9VFmJjWB54D8UHHAmgLjq9S4JqaX9tn2kg=.c5f1bc44-1af9-44de-a342-e2e20ea2ead3@github.com>
 <bevGfJBruLf2-ykL6A_ZcDH_7081qf-vuYajPvyPD3M=.a410050d-d3a3-47de-a53d-c7f4e417fff0@github.com>
 <6B_XF-1U3nX2mJ6lQbA4XDgCAOV_CowpksH2OcY1QVw=.79131b1b-d2bc-4d00-aaf1-6c3e3a65bdc8@github.com>
Message-ID: <2n9mu-N3o0vaLwsOFRq6vhXzYU3MZSiShd-JAffaPGs=.cb1dd1ec-c0b7-4668-8e9c-e09d2f9cd75d@github.com>

On Thu, 22 May 2025 21:48:48 GMT, Phil Race <prr at openjdk.org> wrote:

> So I don't follow the reasoning of waiting for any of the above answers - likely for many months but most likely (the 90% case) forever.

We won?t wait forever of course, and will review the proposal carefully soon. But it would be great if macOS gets updated and we can skip the change on our side.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2902765444

From serb at openjdk.org  Thu May 22 23:35:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 May 2025 23:35:57 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <eLWg0Ie5Yo4Kirp8Bg_4Yklh9zRPa706CKgEMpWnvNw=.0ba1fb1d-a842-4c43-89f1-acffa176245c@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <eLWg0Ie5Yo4Kirp8Bg_4Yklh9zRPa706CKgEMpWnvNw=.0ba1fb1d-a842-4c43-89f1-acffa176245c@github.com>
Message-ID: <1e7XIETciaopHgtZIUEcjZ6pfOoj3PrvtXJLr3xZyFk=.0d55067f-af6d-4aef-8653-9e501e938c5f@github.com>

On Thu, 22 May 2025 22:31:33 GMT, Phil Race <prr at openjdk.org> wrote:

>This API is not so different than the Applet AudioClip because it is a simple replacement for that which is intended to be used by desktop apps - not browsers any more.

Sure the implementation here is identical to the decades old Applet.AudioClip (deprecated for 9 years!), but is that really a good thing? Shouldn?t we take this opportunity to improve the API or at the very least, document its limitations and intended use more clearly?

JavaFX, for example, is better documented. There may also be other patterns or audio playback features "in the wild" Java that would be worth considering as part of a more modern solution.

Regarding the current patch, I still have a few questions and suggestions:

 - Why is IllegalArgumentException used instead of NullPointerException? The entire sound/media stack consistently uses NPE for null checks, and most recent JavaSE APIs (e.g., FFM, StableValue, ScopedValue, etc.) follow this pattern. NPE is just better. what are the pros for IAE?
 - Why we do not document that the application will not exit if a clip is playing (and will never exit if loop() was called)? This is an important behavioral detail, similar to what is documented in [AWT threading issues](https://github.com/openjdk/jdk/blob/fdda7661906eab63d939e9f482449e21cc143c8f/src/java.desktop/share/classes/java/awt/doc-files/AWTThreadIssues.html#L108).
 - The synchronized keyword appears unnecessary in the current implementation. It can be dropped now and reconsidered later - possibly with another concurrency primitives.
 - The multithreaded behavior and asynchronous nature of the API are not described.
 - There?s no mention of preloading behavior. For example, JavaFX explicitly documents this.
 - The tests don't cover the next part of the spec:
>         ?If the implementation does not find a suitable output device for the data, playing the clip will be a no-op.?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2902853177

From dnguyen at openjdk.org  Thu May 22 23:37:53 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 22 May 2025 23:37:53 GMT
Subject: RFR: 8341370: Test
 java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails
 intermittently on macOS-aarch64
In-Reply-To: <BHAutQbvJdvqeYgVWy9bdtDxVJCcVebFPNvAaZMPyHI=.9e80138c-6024-436c-ba6b-70a380a475db@github.com>
References: <BHAutQbvJdvqeYgVWy9bdtDxVJCcVebFPNvAaZMPyHI=.9e80138c-6024-436c-ba6b-70a380a475db@github.com>
Message-ID: <LhXnJDdOWjgLdyu32MvxJjdM2UUcBpyr9ZTfG2SmRZw=.f02f8f01-694c-4c74-9502-c05eff3bcb43@github.com>

On Wed, 21 May 2025 13:13:46 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> ShapeNotSetSometimes.java fails intermittently with a RuntimeException on macOS-aarch64
> Test threw exception: java.lang.RuntimeException: Test failed. The shape has not been applied.
> 
> Fix:
> The test has been modified to take a screenshot of the area and then analyse the pixel color in the screenshot rather than getting individual pixels from the screen for each test.
> Also the timeout of the test has been increased to 5 minutes(300 seconds) as sometimes it times out with the default timeout of 2 minutes(120 seconds).
> 
> Testing:
> After fixing the test, it has been run 40 times per platform(Windows, Linux, MacOS x64 and MacOS aarch64) using Mach5 and got 100% pass rate .

I tested the changes locally and through CI. The test now passes seemingly consistently when removed from the problem list. I ran it with 50 repeats on all OS's with no failures. 

In addition to testing the changes as shown in this PR, I also tested with just adding the timeout (without the screen capture change), and it still passes (which might hint at the timeout being related to the primary issue here). However, I still prefer the changes made.

test/jdk/java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java line 175:

> 173:     }
> 174: 
> 175:     private void colorCheck(int x, int y, Color expectedColor, boolean mustBeExpectedColor,BufferedImage screenCapture) {

Suggestion:

    private void colorCheck(int x, int y, Color expectedColor, boolean mustBeExpectedColor, BufferedImage screenCapture) {

-------------

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25354#pullrequestreview-2862625754
PR Review Comment: https://git.openjdk.org/jdk/pull/25354#discussion_r2103436161

From kbarrett at openjdk.org  Thu May 22 23:53:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 22 May 2025 23:53:52 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9 [v2]
In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
 <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
Message-ID: <XbQH8X9VbacvJP9QqbPBPHJ5AMRXFaFXtUp2eF4k7oE=.f1f378aa-f70e-4bbc-b08b-909a0ad9ecc3@github.com>

On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The following line results in unused-result warning on linux/clang.
>> 
>> 
>> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
>> 
>> 
>> There are two ways to handle it 
>> 
>> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
>> 
>> 
>> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html
>> 
>> 
>> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
>> 
>> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   DTRACE added

Change builds without warning with clang 19.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25217#issuecomment-2902873876

From honkar at openjdk.org  Fri May 23 00:35:02 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 23 May 2025 00:35:02 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v13]
In-Reply-To: <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
Message-ID: <G5jb5umVFs0_AwPP-cDyMVVM5YKfN86Yg1yqkS_hM1E=.832abde9-4671-4232-8484-f03a7117878f@github.com>

On Wed, 30 Apr 2025 21:13:12 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Currently on macOS when mouseMove is given an offscreen coordinate to move the mouse to, mouseMove will physically clamp to the edge of the screen, but if you try to grab the mouse location immediately after by using MouseInfo.getPointerInfo().getLocation() you will get the value of the offscreen point.
>> 
>> Windows and linux do this clamping and coordinate handling for us, but new distributions may not necessarily handle clamping the same way, so Robot should be checking for clamping rather than delegating it to native.
>> 
>> This fix updates shared code to cache the screen bounds and adds a check to not exceed the bounds in mouseMove. The caching is done in the Robot constructor, so if the screen bounds changes the constructor must be called again to update to the new bounds.
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8345538
>  - move clamping code into macos
>  - use absolute distance to choose correct screen for offscreen clamping
>  - helper function
>  - grab screen data on mouseMove
>  - fix bounds
>  - peer.mouseMove
>  - fix implementation
>  - robot update
>  - Revert "robot multimonitor fix"
>    
>    This reverts commit 5734165881a66dc48d5a9f19e02bf63fac57cdc9.
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8b16897b...e0a5c872

Tested the fix on macOS it works as expected and the native reproducer (attached to JBS) highlights the offscreen point issue and the need for clamping.

The fix looks good to me, I may require some time to catch up on the previous review comments before approving (there has been a lot of update since I last reviewed).

src/java.desktop/macosx/classes/sun/lwawt/macosx/CRobot.java line 102:

> 100:     private Point calcClosestPoint(int x, int y, Rectangle screenBounds) {
> 101:         return new Point(Math.min(Math.max(x, screenBounds.x), screenBounds.x + screenBounds.width-1),
> 102:                 Math.min(Math.max(y, screenBounds.y), screenBounds.y + screenBounds.height-1));

Suggestion:

        return new Point(Math.min(Math.max(x, screenBounds.x), screenBounds.x + screenBounds.width - 1),
                Math.min(Math.max(y, screenBounds.y), screenBounds.y + screenBounds.height - 1));

test/jdk/java/awt/Robot/MouseMoveOffScreen.java line 80:

> 78:         }
> 79:         return p;
> 80:     }

I believe validateOffScreen() was added to prevent edge or boundary case rounding error as observed here - https://github.com/openjdk/jdk/pull/22781/files#r1926210713

-------------

PR Review: https://git.openjdk.org/jdk/pull/22781#pullrequestreview-2862874069
PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r2103597214
PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r2103598862

From mvs at openjdk.org  Fri May 23 02:27:04 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Fri, 23 May 2025 02:27:04 GMT
Subject: Integrated: 8357305: Compilation failure in
 javax/swing/JMenuItem/bug6197830.java
In-Reply-To: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
References: <8kFcDBl8MwgKZR_8NNwnkyH7wfe5gUyjTIc9tKNAVL8=.c02ed18e-d7ac-4b30-9f00-9c460db4c0ee@github.com>
Message-ID: <3sSf2YyVM6upNng2YNSq273bMBsoLHSEKN0r4XTIqf4=.a40e0c41-86cc-4e08-a94d-7d09647ed54b@github.com>

On Tue, 20 May 2025 07:32:41 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> There are some compilation failures noticed in the recently open sourced test javax/swing/JMenuItem/bug6197830.java. The compilation failures are due to missing import statements and a missing dependency file MenuItemTest.java.
> 
> Fix: I have added the required import statements and added the code-piece from MenuItemTest.java as a method getMenuItemTestFrame().

This pull request has now been integrated.

Changeset: a94d1a04
Author:    Manukumar V S <mvs at openjdk.org>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a94d1a04076c64f983e508c4da2e59a8aab5e4c5
Stats:     551 lines in 5 files changed: 291 ins; 260 del; 0 mod

8357305: Compilation failure in javax/swing/JMenuItem/bug6197830.java

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/25319

From duke at openjdk.org  Fri May 23 02:27:59 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 23 May 2025 02:27:59 GMT
Subject: Integrated: 8356061: [macos]
 com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on
 macosx-aarch64 machine
In-Reply-To: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
References: <jPVSS2JGZZMYYgaEmGqrFaVCS7j1NcRgHD9R9duUrSw=.c7a129eb-c6ba-495d-907b-ac0a06e4b433@github.com>
Message-ID: <ZUciUqkkdQ2SwKVQLxQypOagRj1pkw14rVnc-Xrujvw=.1e379ac3-e81a-4a25-93e5-6a862a39546a@github.com>

On Thu, 15 May 2025 04:05:38 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> Unfortunately I'm unable to reproduce this failure. I slowed the test down; it passes on my machine before and after this PR.
> 
> I added a little bit of logging that might also help identify what's happening.
> 
> Does anyone have any more suggestions?

This pull request has now been integrated.

Changeset: 4193d052
Author:    jeremy <jeremy.wood at mac.com>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4193d052c0ae2336d816d0e76dec5420aa386465
Stats:     225 lines in 1 file changed: 58 ins; 98 del; 69 mod

8356061: [macos] com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on macosx-aarch64 machine

Reviewed-by: jdv, serb

-------------

PR: https://git.openjdk.org/jdk/pull/25244

From mvs at openjdk.org  Fri May 23 02:53:51 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Fri, 23 May 2025 02:53:51 GMT
Subject: RFR: 8341370: Test
 java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails
 intermittently on macOS-aarch64 [v2]
In-Reply-To: <BHAutQbvJdvqeYgVWy9bdtDxVJCcVebFPNvAaZMPyHI=.9e80138c-6024-436c-ba6b-70a380a475db@github.com>
References: <BHAutQbvJdvqeYgVWy9bdtDxVJCcVebFPNvAaZMPyHI=.9e80138c-6024-436c-ba6b-70a380a475db@github.com>
Message-ID: <fs6vjiw_wqkzW3Dx0vHqo7nF_JMMGNFqFZSdybiQBjc=.b62132a8-0ddd-4c4f-b35f-7d7f532a3d15@github.com>

> ShapeNotSetSometimes.java fails intermittently with a RuntimeException on macOS-aarch64
> Test threw exception: java.lang.RuntimeException: Test failed. The shape has not been applied.
> 
> Fix:
> The test has been modified to take a screenshot of the area and then analyse the pixel color in the screenshot rather than getting individual pixels from the screen for each test.
> Also the timeout of the test has been increased to 5 minutes(300 seconds) as sometimes it times out with the default timeout of 2 minutes(120 seconds).
> 
> Testing:
> After fixing the test, it has been run 40 times per platform(Windows, Linux, MacOS x64 and MacOS aarch64) using Mach5 and got 100% pass rate .

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Formatting changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25354/files
  - new: https://git.openjdk.org/jdk/pull/25354/files/7512d0e2..9beabcbb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25354&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25354&range=00-01

  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25354/head:pull/25354

PR: https://git.openjdk.org/jdk/pull/25354

From abhiscxk at openjdk.org  Fri May 23 04:38:07 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 23 May 2025 04:38:07 GMT
Subject: Integrated: 8356145: ListEnterExitTest.java fails on macos
In-Reply-To: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
Message-ID: <3N4ke7kqMG-Z0XFCoNsQePl5DEcGGODm00RaPoD1rgs=.0dc42407-c3f9-498f-82dd-6b9b12d1258f@github.com>

On Mon, 19 May 2025 08:15:29 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Test was failing on macOS 14.7.1 system in CI pipeline. Logged output suggests that the mouse exit event is not triggered and thus the test fails.
> Increased number of list items and adjusted the X and Y offset for mouse move events, so the mouse pointer will be within the frame and added robot delay to stabilize the test.
> 
> Verified the updated test in CI on macOS 14.7 machine and there is no failure.

This pull request has now been integrated.

Changeset: 99e01301
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99e01301cd7f063f167db107d31468b1d3f901aa
Stats:     64 lines in 1 file changed: 22 ins; 26 del; 16 mod

8356145: ListEnterExitTest.java fails on macos

Reviewed-by: aivanov, jdv, kizune

-------------

PR: https://git.openjdk.org/jdk/pull/25299

From serb at openjdk.org  Fri May 23 05:45:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 23 May 2025 05:45:56 GMT
Subject: RFR: 8356145: ListEnterExitTest.java fails on macos [v3]
In-Reply-To: <Cyx88ER4B1SsZt9yZfg5Kq6872n45Ihr1yqkhdD5UmY=.05341efb-373b-4513-98f7-d5963241dbb1@github.com>
References: <F_3BZ4IdfbpyDyvrDAwh9UwWHCjQ6AX5xyiRFaD_3EA=.7fb92ce7-767c-4be0-ae94-0810c67fd9ac@github.com>
 <hxqp5b9_-Ok5rUQcGmmjO9tfksC-ID0bnc_fGgkCUb4=.aa648c7b-9535-4359-9a96-67cdcef425ba@github.com>
 <n9_LaEFp_l_hhlLV0JNMXzQfRY0Wj9bBtUhC2a11fnw=.1cd68a24-f97d-4c2e-8d4a-1ec9eb783919@github.com>
 <F3aFJC7rNSrkk-T-ilHkOam94ToCZ4X1lB3jstwGra4=.4059d79c-da2a-465f-a265-ac72fc5c6fb8@github.com>
 <Cyx88ER4B1SsZt9yZfg5Kq6872n45Ihr1yqkhdD5UmY=.05341efb-373b-4513-98f7-d5963241dbb1@github.com>
Message-ID: <vJ4ke37AfkU66a7sfMzW6q3fOSVUoIX_b_SJo5FG2EU=.6860dc53-aecb-4f25-b7fe-5bd06eb76431@github.com>

On Wed, 21 May 2025 12:15:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>I wonder if this system reproduces other bugs where expected events aren't received? such as java/awt/event/KeyEvent/FunctionKeyTest.java ([JDK-8343104](https://bugs.openjdk.org/browse/JDK-8343104)) and java/awt/List/ItemEventTest/ItemEventTest.java ([JDK-8204221](https://bugs.openjdk.org/browse/JDK-8204221)).

Was it actually a testbug?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25299#issuecomment-2903328952

From psadhukhan at openjdk.org  Fri May 23 08:05:38 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 23 May 2025 08:05:38 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v4]
In-Reply-To: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
Message-ID: <TeBe9DI5AuCjtP4iTp7g1UAhafKnpdz-4DHaRISktd8=.9dbeb508-ac06-4319-91d4-97e6a0108a33@github.com>

> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
> Fixed by setting the divider location before rendering the left and right components..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Set orientation only if changed...add headful in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25294/files
  - new: https://git.openjdk.org/jdk/pull/25294/files/42c7c575..32fe70f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25294&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25294&range=02-03

  Stats: 19 lines in 2 files changed: 2 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/25294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25294/head:pull/25294

PR: https://git.openjdk.org/jdk/pull/25294

From psadhukhan at openjdk.org  Fri May 23 08:05:38 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 23 May 2025 08:05:38 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v3]
In-Reply-To: <c8rvhtKVyoiVzKMHlFnTdQRgW-eCQgdOos8vrEo90gs=.dd26a998-c387-4a58-bbf6-3e4b462f5478@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <c8rvhtKVyoiVzKMHlFnTdQRgW-eCQgdOos8vrEo90gs=.dd26a998-c387-4a58-bbf6-3e4b462f5478@github.com>
Message-ID: <4lP3w55MV3fs3q8skCPRzfiUk5MguC9rXzBUVTvTIjY=.e9e2c269-de66-4e55-8369-7b44459ddcd3@github.com>

On Thu, 22 May 2025 16:27:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
>> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
>> Fixed by setting the divider location before rendering the left and right components..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

OK..Modified PR so SpliPane components orientation set newly only if orientation is changed..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25294#issuecomment-2903616419

From kizune at openjdk.org  Fri May 23 08:57:54 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 23 May 2025 08:57:54 GMT
Subject: RFR: 8341370: Test
 java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails
 intermittently on macOS-aarch64 [v2]
In-Reply-To: <fs6vjiw_wqkzW3Dx0vHqo7nF_JMMGNFqFZSdybiQBjc=.b62132a8-0ddd-4c4f-b35f-7d7f532a3d15@github.com>
References: <BHAutQbvJdvqeYgVWy9bdtDxVJCcVebFPNvAaZMPyHI=.9e80138c-6024-436c-ba6b-70a380a475db@github.com>
 <fs6vjiw_wqkzW3Dx0vHqo7nF_JMMGNFqFZSdybiQBjc=.b62132a8-0ddd-4c4f-b35f-7d7f532a3d15@github.com>
Message-ID: <cIfoAXa-f8R0Oo1C5HezE7B1Lg1rJz8h8wLGKcL3EPM=.d7edb5db-776b-47fb-a5b0-66c798d944aa@github.com>

On Fri, 23 May 2025 02:53:51 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> ShapeNotSetSometimes.java fails intermittently with a RuntimeException on macOS-aarch64
>> Test threw exception: java.lang.RuntimeException: Test failed. The shape has not been applied.
>> 
>> Fix:
>> The test has been modified to take a screenshot of the area and then analyse the pixel color in the screenshot rather than getting individual pixels from the screen for each test.
>> Also the timeout of the test has been increased to 5 minutes(300 seconds) as sometimes it times out with the default timeout of 2 minutes(120 seconds).
>> 
>> Testing:
>> After fixing the test, it has been run 40 times per platform(Windows, Linux, MacOS x64 and MacOS aarch64) using Mach5 and got 100% pass rate .
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Formatting changes

Looks fine.

-------------

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25354#pullrequestreview-2863722947

From kizune at openjdk.org  Fri May 23 08:58:51 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 23 May 2025 08:58:51 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v4]
In-Reply-To: <TeBe9DI5AuCjtP4iTp7g1UAhafKnpdz-4DHaRISktd8=.9dbeb508-ac06-4319-91d4-97e6a0108a33@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <TeBe9DI5AuCjtP4iTp7g1UAhafKnpdz-4DHaRISktd8=.9dbeb508-ac06-4319-91d4-97e6a0108a33@github.com>
Message-ID: <TQC3cFW5xnE56z6pmrXmU1ohAu7OcpGpZ17vAtonIfs=.8546c376-13c1-4653-9f2c-840abb16b52d@github.com>

On Fri, 23 May 2025 08:05:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
>> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
>> Fixed by setting the divider location before rendering the left and right components..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set orientation only if changed...add headful in test

Marked as reviewed by kizune (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25294#pullrequestreview-2863725229

From duke at openjdk.org  Fri May 23 09:06:52 2025
From: duke at openjdk.org (duke)
Date: Fri, 23 May 2025 09:06:52 GMT
Subject: RFR: 8341370: Test
 java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails
 intermittently on macOS-aarch64 [v2]
In-Reply-To: <fs6vjiw_wqkzW3Dx0vHqo7nF_JMMGNFqFZSdybiQBjc=.b62132a8-0ddd-4c4f-b35f-7d7f532a3d15@github.com>
References: <BHAutQbvJdvqeYgVWy9bdtDxVJCcVebFPNvAaZMPyHI=.9e80138c-6024-436c-ba6b-70a380a475db@github.com>
 <fs6vjiw_wqkzW3Dx0vHqo7nF_JMMGNFqFZSdybiQBjc=.b62132a8-0ddd-4c4f-b35f-7d7f532a3d15@github.com>
Message-ID: <1HQZdyfRYMn9t0wFD32n0047AisfhkzKAfoHUihkwUM=.48a974ab-2474-4a9e-9077-7d96dd29ff78@github.com>

On Fri, 23 May 2025 02:53:51 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> ShapeNotSetSometimes.java fails intermittently with a RuntimeException on macOS-aarch64
>> Test threw exception: java.lang.RuntimeException: Test failed. The shape has not been applied.
>> 
>> Fix:
>> The test has been modified to take a screenshot of the area and then analyse the pixel color in the screenshot rather than getting individual pixels from the screen for each test.
>> Also the timeout of the test has been increased to 5 minutes(300 seconds) as sometimes it times out with the default timeout of 2 minutes(120 seconds).
>> 
>> Testing:
>> After fixing the test, it has been run 40 times per platform(Windows, Linux, MacOS x64 and MacOS aarch64) using Mach5 and got 100% pass rate .
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Formatting changes

@manukumarvs 
Your change (at version 9beabcbb5a55298c46db897b85ee7d9031599bf2) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25354#issuecomment-2903778221

From avu at openjdk.org  Fri May 23 10:23:53 2025
From: avu at openjdk.org (Alexey Ushakov)
Date: Fri, 23 May 2025 10:23:53 GMT
Subject: RFR: 8312198: [macos] metal pipeline - window rendering stops
 after display sleep
In-Reply-To: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
References: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
Message-ID: <XvQjEdWn5v8Kkgbc-Tq_l_MSQRVNB4pIL0gtdtMIUKs=.d65f4b55-b23c-4b33-ae90-364a105cbc23@github.com>

On Wed, 21 May 2025 06:11:18 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> In stress based scenarios it is observed that nothing is drawn in UI content when display wakes up from sleep in Metal pipeline of macOS. Unfortunately i am not able to reproduce it, but based on details in the bug it looks like we are hitting a race condition. Call to CVDisplayLinkCreateWithActiveCGDisplays is becoming a no-op as there are no active displays right after NSWorkspaceScreensDidWakeNotification. Looks like if we continue to call CVDisplayLinkCreateWithActiveCGDisplays after screen wakeup we are able to get the list of ActiveDisplays and then able to create displayLink.
> 
> So now the code is modified to check whether CVDisplayLinkCreateWithActiveCGDisplays is successful or not. If not we will try to call CVDisplayLinkCreateWithActiveCGDisplays for 5 instances each with 1 second delay. There is no regression test for this change because it needs a stress based test with display wakeup/sleep(As captured in JBS, i am not able to reproduce this issue).
> 
> I have tested this change for sanity by running animation examples from SwingSet2 and continuously connecting/disconnecting external display. Also by multiple display sleep and wakeup scenarios, i don't see any regressions. Also whole clientlibs CI run is done with this patch and it is also green.
> 
> While working on this bug also noticed that many functions of CVDisplayLink is deprecated from macOS 14 and going forward we need to use CADisplayLink/CAMetalDisplayLink. I have raised [JDK-8357418](https://bugs.openjdk.org/browse/JDK-8357418) for the same.

Changes requested by avu (Committer).

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 52:

> 50: - (void) createDisplayLink {
> 51:     CVReturn r = CVDisplayLinkCreateWithActiveCGDisplays(&displayLink);
> 52:     if (r != kCVReturnSuccess) {

We may still miss an update of the window for a noticeable time (depending on the application code) because DisplayLink will not work during the retry period.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 54:

> 52:     if (r != kCVReturnSuccess) {
> 53:         if (self.displayLinkFailCount == 5) {
> 54:             // We have tried for 5 seconds to create CVDisplayLink

It would be better to move this magic number to the beginning of the file as a verbose constant. Also, for reliability reasons, I would prefer the `>=` check here.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25342#pullrequestreview-2860218856
PR Review Comment: https://git.openjdk.org/jdk/pull/25342#discussion_r2101917612
PR Review Comment: https://git.openjdk.org/jdk/pull/25342#discussion_r2101924670

From avu at openjdk.org  Fri May 23 10:23:54 2025
From: avu at openjdk.org (Alexey Ushakov)
Date: Fri, 23 May 2025 10:23:54 GMT
Subject: RFR: 8312198: [macos] metal pipeline - window rendering stops
 after display sleep
In-Reply-To: <oqGmny5SJSoY2_zAmPiGgQ_O_QzOAXL14bI1uSBefHU=.04d775fb-0ba1-4619-bd8b-31f2d237cef2@github.com>
References: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
 <d6zgy_4sAT6kmbFndfpL_MWucjhDu5mQIihLctsCgTk=.afec4640-5587-482d-8ffd-215fd06df834@github.com>
 <oqGmny5SJSoY2_zAmPiGgQ_O_QzOAXL14bI1uSBefHU=.04d775fb-0ba1-4619-bd8b-31f2d237cef2@github.com>
Message-ID: <P2JY_4WN5WdE_Huzv8H_AviRxRrSl8lJleUDqwMVDgY=.2d803687-fbe2-4eb1-897d-0cce2cbe8a32@github.com>

On Thu, 22 May 2025 14:30:13 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Is it possible that it is somehow related to 8304825? could be the layer created "during display sleep" and that might be in "sleep" more that 5 seconds?
>
>> Is it possible that it is somehow related to 8304825? could be the layer created "during display sleep" and that might be in "sleep" more that 5 seconds?
> 
> This is a follow-up fix for JDK-8304825. Basically we have a race condition because of timing issue when we are rendering many frame with animations. On screen wakeup CVDisplayLinkCreateWithActiveCGDisplays is failing because Active display list is still empty and we never create a displayLink and content to MTLLayer are never updated. By adding 5 retries with 1 second gap after screen wakeup we are making sure that we are able to create displayLink for all active displays.

@jayathirthrao What is about my comments?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25342#issuecomment-2903974626

From duke at openjdk.org  Fri May 23 10:26:54 2025
From: duke at openjdk.org (duke)
Date: Fri, 23 May 2025 10:26:54 GMT
Subject: RFR: 8334016: Make PrintNullString.java automatic [v6]
In-Reply-To: <UzDDzT8FgOY5buBaM7KsGiDqsjTzJbKeEL_9wEJLthE=.e4af3bb5-8b5a-4f75-93bb-cba3f6dc1ef6@github.com>
References: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
 <UzDDzT8FgOY5buBaM7KsGiDqsjTzJbKeEL_9wEJLthE=.e4af3bb5-8b5a-4f75-93bb-cba3f6dc1ef6@github.com>
Message-ID: <1EQYX0DTHBjACg3iUPnuvp4cY8S3ldV22a6Cicc4gl4=.6f05b241-17c4-478d-ae5d-2ceea598bb62@github.com>

On Thu, 22 May 2025 11:24:34 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> I have updated the test and made it semi-automatic (need to click "Print") . Test will initiate a print and result will be generated automatic. 
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/awt/print/PrinterJob/PrintNullString.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

@Renjithkannath 
Your change (at version 01041aa340e75fac16d8addef4270476552e9a92) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24501#issuecomment-2903985497

From jdv at openjdk.org  Fri May 23 11:38:32 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 23 May 2025 11:38:32 GMT
Subject: RFR: 8312198: [macos] metal pipeline - window rendering stops
 after display sleep [v2]
In-Reply-To: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
References: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
Message-ID: <Y63JtEnqw4NSdnwVxyrNh8PIFQqShKuwp7GJoO18YWw=.3b07f876-0319-44a1-bf75-ab2cf7988761@github.com>

> In stress based scenarios it is observed that nothing is drawn in UI content when display wakes up from sleep in Metal pipeline of macOS. Unfortunately i am not able to reproduce it, but based on details in the bug it looks like we are hitting a race condition. Call to CVDisplayLinkCreateWithActiveCGDisplays is becoming a no-op as there are no active displays right after NSWorkspaceScreensDidWakeNotification. Looks like if we continue to call CVDisplayLinkCreateWithActiveCGDisplays after screen wakeup we are able to get the list of ActiveDisplays and then able to create displayLink.
> 
> So now the code is modified to check whether CVDisplayLinkCreateWithActiveCGDisplays is successful or not. If not we will try to call CVDisplayLinkCreateWithActiveCGDisplays for 5 instances each with 1 second delay. There is no regression test for this change because it needs a stress based test with display wakeup/sleep(As captured in JBS, i am not able to reproduce this issue).
> 
> I have tested this change for sanity by running animation examples from SwingSet2 and continuously connecting/disconnecting external display. Also by multiple display sleep and wakeup scenarios, i don't see any regressions. Also whole clientlibs CI run is done with this patch and it is also green.
> 
> While working on this bug also noticed that many functions of CVDisplayLink is deprecated from macOS 14 and going forward we need to use CADisplayLink/CAMetalDisplayLink. I have raised [JDK-8357418](https://bugs.openjdk.org/browse/JDK-8357418) for the same.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Add macro

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25342/files
  - new: https://git.openjdk.org/jdk/pull/25342/files/1e193339..549f825f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25342&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25342&range=00-01

  Stats: 5 lines in 2 files changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25342/head:pull/25342

PR: https://git.openjdk.org/jdk/pull/25342

From rmarchenko at openjdk.org  Fri May 23 11:48:38 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 23 May 2025 11:48:38 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v13]
In-Reply-To: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
Message-ID: <ZBP2gR52LbACfOwuS7dhQhEzKIKrRQjynqVp4tPFp9Q=.fe7b9661-4d6f-4dc4-a85c-a18738a74eb2@github.com>

> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
> 
> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
> 
> ---------
> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default and static methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses.
> 
> When a subclass "overrides" a static method from a parent class `getMethodDescriptors()` behaves as follows:
> 
> - In case of a clash with a class method, the class version will take precedence rather than interface's one. 
> - If the same method appears in multiple classes/interfaces within the same hierarchy, the version from the most specific sub-interface will be selected.
> - If the method appears in classes/interfaces from different hierarchies, the result is undefined, either version can be returned.
> 
> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
> 
> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
> * Gettters/setters declared and not implemented are not considered.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  Restored the original order processing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23443/files
  - new: https://git.openjdk.org/jdk/pull/23443/files/980ebde5..431705a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23443/head:pull/23443

PR: https://git.openjdk.org/jdk/pull/23443

From rmarchenko at openjdk.org  Fri May 23 11:48:39 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 23 May 2025 11:48:39 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v12]
In-Reply-To: <aH2OGm0MehkfeSmjxPlrXi6S7WSW7QVjvjTYVhK7RB0=.59766878-c0be-453a-9b02-c0ad2f48c1c6@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <0645YLoDLjcLbjQxBs3QFCFVvenQjAeJlZANZ0hay_8=.e50b8551-4a2f-4cc5-b910-5f5544beb1f7@github.com>
 <DI66Dw96G2BdXyunw_IR6MSicF3qYOLqB_sR-eAkxfk=.c38e46e3-7b8b-479a-a665-7457623ebe71@github.com>
 <aH2OGm0MehkfeSmjxPlrXi6S7WSW7QVjvjTYVhK7RB0=.59766878-c0be-453a-9b02-c0ad2f48c1c6@github.com>
Message-ID: <-76yVSjHyZOGJGVcySdiBScPH6Si-zEztJ1rMNhG_OE=.5809f733-8a59-49d4-bf38-b7b7041ce9e3@github.com>

On Wed, 30 Apr 2025 12:25:50 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/beans/Introspector.java line 1060:
>> 
>>> 1058:                 MethodDescriptor composite = new MethodDescriptor(old, md);
>>> 1059:                 methods.put(name, composite);
>>> 1060:             }
>> 
>> FYI, one of the JCK introspector tests fails because of this change. 
>> The test is quite complicated, so I am not able to provide a simple reproducer right away. But I'll post it later.
>
>> FYI, one of the JCK introspector tests fails because of this change. The test is quite complicated, so I am not able to provide a simple reproducer right away. But I'll post it later.
> 
> Indeed, there are some failures of JCK Introspector tests.

I restored the original order processing, now seems OK for me locally.
Could you review, please?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2104418535

From rmarchenko at openjdk.org  Fri May 23 11:48:38 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 23 May 2025 11:48:38 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v12]
In-Reply-To: <0645YLoDLjcLbjQxBs3QFCFVvenQjAeJlZANZ0hay_8=.e50b8551-4a2f-4cc5-b910-5f5544beb1f7@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <0645YLoDLjcLbjQxBs3QFCFVvenQjAeJlZANZ0hay_8=.e50b8551-4a2f-4cc5-b910-5f5544beb1f7@github.com>
Message-ID: <8QULiCj0kBzOqwNOKeb5uhPgtZ-5ni_q6akOEufB3_w=.796c48f8-2e1a-45c3-af33-2abb318beec7@github.com>

On Thu, 3 Apr 2025 09:21:38 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
>> 
>> ---------
>> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default and static methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses.
>> 
>> When a subclass "overrides" a static method from a parent class `getMethodDescriptors()` behaves as follows:
>> 
>> - In case of a clash with a class method, the class version will take precedence rather than interface's one. 
>> - If the same method appears in multiple classes/interfaces within the same hierarchy, the version from the most specific sub-interface will be selected.
>> - If the method appears in classes/interfaces from different hierarchies, the result is undefined, either version can be returned.
>> 
>> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
>> 
>> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
>> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
>> * Gettters/setters declared and not implemented are not considered.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing review comments

Could you review, please?
@aivanov-jdk @mrserb @azvegint

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2904162661

From jdv at openjdk.org  Fri May 23 11:48:51 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 23 May 2025 11:48:51 GMT
Subject: RFR: 8312198: [macos] metal pipeline - window rendering stops
 after display sleep [v2]
In-Reply-To: <XvQjEdWn5v8Kkgbc-Tq_l_MSQRVNB4pIL0gtdtMIUKs=.d65f4b55-b23c-4b33-ae90-364a105cbc23@github.com>
References: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
 <XvQjEdWn5v8Kkgbc-Tq_l_MSQRVNB4pIL0gtdtMIUKs=.d65f4b55-b23c-4b33-ae90-364a105cbc23@github.com>
Message-ID: <BURkfD1ejO-XxcGa0jRPNZn6543r3-7K7Bgt8w8Xwi4=.005262eb-8afd-4f8e-ad83-5544f8e9c095@github.com>

On Thu, 22 May 2025 08:07:34 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add macro
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 52:
> 
>> 50: - (void) createDisplayLink {
>> 51:     CVReturn r = CVDisplayLinkCreateWithActiveCGDisplays(&displayLink);
>> 52:     if (r != kCVReturnSuccess) {
> 
> We may still miss an update of the window for a noticeable time (depending on the application code) because DisplayLink will not work during the retry period.

This timing issue is happening is very rare stress based scenario and we don't want to continuously query for active displays to create DisplayLink. Having a delay of 1 sec is to make sure we can create DisplayLink reliably. It's okay if there are no updates to UI in such scenario right after we wake up the screen from sleep.

> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 54:
> 
>> 52:     if (r != kCVReturnSuccess) {
>> 53:         if (self.displayLinkFailCount == 5) {
>> 54:             // We have tried for 5 seconds to create CVDisplayLink
> 
> It would be better to move this magic number to the beginning of the file as a verbose constant. Also, for reliability reasons, I would prefer the `>=` check here.

I added comment to explain 5 seconds count, but its better to use constant i have added the same.

All selectors will be queued into same thread run loops, i don't see any way where we will skip 5th count. To be extra cautious i have updated the check to `>=`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25342#discussion_r2104420999
PR Review Comment: https://git.openjdk.org/jdk/pull/25342#discussion_r2104421094

From mvs at openjdk.org  Fri May 23 11:58:56 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Fri, 23 May 2025 11:58:56 GMT
Subject: Integrated: 8341370: Test
 java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails
 intermittently on macOS-aarch64
In-Reply-To: <BHAutQbvJdvqeYgVWy9bdtDxVJCcVebFPNvAaZMPyHI=.9e80138c-6024-436c-ba6b-70a380a475db@github.com>
References: <BHAutQbvJdvqeYgVWy9bdtDxVJCcVebFPNvAaZMPyHI=.9e80138c-6024-436c-ba6b-70a380a475db@github.com>
Message-ID: <3ukjAwjiG2X27glC8w5f7OsXy6NCTX5h3qC_EsTZ-FY=.2146b111-5bc4-4904-bc45-1cd4cc54c13b@github.com>

On Wed, 21 May 2025 13:13:46 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> ShapeNotSetSometimes.java fails intermittently with a RuntimeException on macOS-aarch64
> Test threw exception: java.lang.RuntimeException: Test failed. The shape has not been applied.
> 
> Fix:
> The test has been modified to take a screenshot of the area and then analyse the pixel color in the screenshot rather than getting individual pixels from the screen for each test.
> Also the timeout of the test has been increased to 5 minutes(300 seconds) as sometimes it times out with the default timeout of 2 minutes(120 seconds).
> 
> Testing:
> After fixing the test, it has been run 40 times per platform(Windows, Linux, MacOS x64 and MacOS aarch64) using Mach5 and got 100% pass rate .

This pull request has now been integrated.

Changeset: 84a67e83
Author:    Manukumar V S <mvs at openjdk.org>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84a67e83e3f4fcb6be6802d12b0788850a3845b5
Stats:     18 lines in 2 files changed: 7 ins; 5 del; 6 mod

8341370: Test java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails intermittently on macOS-aarch64

Reviewed-by: kizune, dnguyen

-------------

PR: https://git.openjdk.org/jdk/pull/25354

From rkannathpari at openjdk.org  Fri May 23 12:00:01 2025
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 23 May 2025 12:00:01 GMT
Subject: Integrated: 8334016: Make PrintNullString.java automatic
In-Reply-To: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
References: <fDuwzUACg2HmOl5a-tE6e1NsTyuvkjNa3W67GqaqtEo=.c004ea54-4b22-464c-b8d1-d86d4e551832@github.com>
Message-ID: <39BIalxhf_wvNilAyWr-AD7phOMyefjofx-kSSExFjo=.211d7be5-c273-47b4-ac70-b1e50f7a5c07@github.com>

On Tue, 8 Apr 2025 08:58:45 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers,
> 
> I have updated the test and made it semi-automatic (need to click "Print") . Test will initiate a print and result will be generated automatic. 
> 
> Please review and let me know your suggestions.

This pull request has now been integrated.

Changeset: f5e6d2c9
Author:    Renjith Kannath Pariyangad <rkannathpari at openjdk.org>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5e6d2c93c3274e465c42709b7634463899fdf2e
Stats:     163 lines in 1 file changed: 37 ins; 88 del; 38 mod

8334016: Make PrintNullString.java automatic

Reviewed-by: aivanov, prr, dnguyen

-------------

PR: https://git.openjdk.org/jdk/pull/24501

From erikj at openjdk.org  Fri May 23 13:13:03 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 23 May 2025 13:13:03 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9 [v2]
In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
 <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com>
Message-ID: <1o9tnuwmzueQpfYaQv_aBRS59u-YQJH2Mo6SUFEL--w=.22557300-24f2-4c52-aec0-3d5581cf331a@github.com>

On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The following line results in unused-result warning on linux/clang.
>> 
>> 
>> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
>> 
>> 
>> There are two ways to handle it 
>> 
>> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
>> 
>> 
>> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html
>> 
>> 
>> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
>> 
>> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   DTRACE added

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25217#pullrequestreview-2864360229

From erikj at openjdk.org  Fri May 23 13:13:04 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 23 May 2025 13:13:04 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9 [v2]
In-Reply-To: <mfESXOoDKToRvOX2SiR3xtqDa3hRvbXSXdFRpOPkvF0=.2a4b461d-5a2d-4ff6-a0aa-42ea91360066@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
 <H_UxlxeowDOSVY5hrBBO-5OjIQvqgNpFx0VPPqMPayE=.ccd6b076-ae32-4931-8bbb-6fe6cc402609@github.com>
 <mfESXOoDKToRvOX2SiR3xtqDa3hRvbXSXdFRpOPkvF0=.2a4b461d-5a2d-4ff6-a0aa-42ea91360066@github.com>
Message-ID: <0Etgi_kK2tLB7ENsbgdH8vlRnHmVyd-VgYcAqmEMw-8=.0721912a-0d89-4118-9456-f5dcb633d9a8@github.com>

On Tue, 13 May 2025 18:33:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> make/modules/java.desktop/lib/AwtLibraries.gmk line 281:
>> 
>>> 279:       DISABLED_WARNINGS_gcc_XlibWrapper.c := type-limits pointer-to-int-cast, \
>>> 280:       DISABLED_WARNINGS_gcc_XRBackendNative.c := maybe-uninitialized, \
>>> 281:       DISABLED_WARNINGS_gcc_XToolkit.c := unused-result, \
>> 
>> Probably a question for build team -
>> One thing to be noted here is that:  With unused-result line removed and WITHOUT the if block changes in XToolkit.c, I expected the build to fail due to unused-result on linux/gcc but it did not.
>> So is there any chance that this disabled warning is being added from else where for gcc ?
>
> Maybe gcc doesn't detect this specific case.
> 
> There could've been other cases which triggered the warning in gcc.

It could be that not all versions of GCC trigger this warning in this particular case. We don't track disabling of warnings on a per version granularity, as that would be incredibly tedious, so it's hard to know. It could also be that this disabling of `unused-result` was added for a different case that has since disappeared.

Regardless, since you are fixing such an issue in the code and no longer see this warning with a reasonably new GCC, it should be safe to remove this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2104557140

From honkar at openjdk.org  Fri May 23 16:36:23 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 23 May 2025 16:36:23 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9 [v3]
In-Reply-To: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
Message-ID: <7UXyNl4k25yf_QXDsWbTwNydMieQS6Hrv2lq7C8O9QM=.12f497be-0849-476b-8ce7-0fa223b18065@github.com>

> The following line results in unused-result warning on linux/clang.
> 
> 
> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
> 
> 
> There are two ways to handle it 
> 
> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
> 
> 
> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html
> 
> 
> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
> 
> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25217/files
  - new: https://git.openjdk.org/jdk/pull/25217/files/91f3d409..ef89c987

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25217&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25217&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25217.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25217/head:pull/25217

PR: https://git.openjdk.org/jdk/pull/25217

From aivanov at openjdk.org  Fri May 23 16:40:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 May 2025 16:40:53 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9 [v3]
In-Reply-To: <7UXyNl4k25yf_QXDsWbTwNydMieQS6Hrv2lq7C8O9QM=.12f497be-0849-476b-8ce7-0fa223b18065@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
 <7UXyNl4k25yf_QXDsWbTwNydMieQS6Hrv2lq7C8O9QM=.12f497be-0849-476b-8ce7-0fa223b18065@github.com>
Message-ID: <a28cbta61zRkat4AiIZyeCmKcJDLB3zrC2YMbEn8oYE=.24ddce36-a3aa-4e82-99f5-d6fe4ad12147@github.com>

On Fri, 23 May 2025 16:36:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The following line results in unused-result warning on linux/clang.
>> 
>> 
>> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
>> 
>> 
>> There are two ways to handle it 
>> 
>> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
>> 
>> 
>> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html
>> 
>> 
>> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
>> 
>> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25217#pullrequestreview-2865037159

From tr at openjdk.org  Fri May 23 17:02:29 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 23 May 2025 17:02:29 GMT
Subject: Integrated: 8139228: JFileChooser renders file names as HTML document
In-Reply-To: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
References: <UKfKXpbRFdm8nclZDn81R1-MQYMrqxrYU7XOc71-Nv0=.876245c8-58b6-408f-9af3-009fdf225507@github.com>
Message-ID: <PRiP6XX4vzUzU7cUBUjFDcja7lggZF-hc3T6sSdYU6E=.f313c96f-02ae-47dc-8933-0c7079fd9798@github.com>

On Fri, 4 Apr 2025 07:21:35 GMT, Tejesh R <tr at openjdk.org> wrote:

> The rendering of the directory names are handled as JLabel w.r.t Look and feel and also either Details/List view. Though FilePane creates basic rendering for these two few Look and Feel define their own renderers and also ComboBox Directory directory name view. Since HTML filtering is not taken care in any of these renderers, JLabel renders them as HTML document if nothing is set or specified.
> The fix is to get "html.disable" property from JFileChooser and set the same to JLabel component which renders and set Directory name. Hence applications can either enable/disable this property and control HTML rendering of directory name.

This pull request has now been integrated.

Changeset: 917c1546
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/917c1546f353c2814de8465d1dfad66b01561f12
Stats:     189 lines in 8 files changed: 189 ins; 0 del; 0 mod

8139228: JFileChooser renders file names as HTML document

Reviewed-by: prr, serb, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/24439

From ihse at openjdk.org  Fri May 23 17:38:54 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 May 2025 17:38:54 GMT
Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9 [v3]
In-Reply-To: <7UXyNl4k25yf_QXDsWbTwNydMieQS6Hrv2lq7C8O9QM=.12f497be-0849-476b-8ce7-0fa223b18065@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
 <7UXyNl4k25yf_QXDsWbTwNydMieQS6Hrv2lq7C8O9QM=.12f497be-0849-476b-8ce7-0fa223b18065@github.com>
Message-ID: <NwLEzFkJkyfCCZKA6t86wj04sdBS6UuYhrXUZM7QlfM=.2edff069-4b78-4d81-9ffa-c1c8a021ba8d@github.com>

On Fri, 23 May 2025 16:36:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The following line results in unused-result warning on linux/clang.
>> 
>> 
>> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
>> 
>> 
>> There are two ways to handle it 
>> 
>> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
>> 
>> 
>> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html
>> 
>> 
>> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
>> 
>> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25217#pullrequestreview-2865224400

From honkar at openjdk.org  Fri May 23 18:05:57 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 23 May 2025 18:05:57 GMT
Subject: Integrated: JDK-8354316 : clang/linux build fails with -Wunused-result
 warning at XToolkit.c:695:9
In-Reply-To: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
References: <vj5xvkSUxcjMlwkL5_uqdqdIUiqYWOt1cAgmxI7i2pQ=.76a5647a-8558-46b4-b5f5-5bafcdd96a2e@github.com>
Message-ID: <kUGf4jtdQE9sGYmJjv_t16Z9SisZ36cgKT4EinU-T1M=.9547da53-aa5f-4a63-bbfa-076c56f0d89d@github.com>

On Tue, 13 May 2025 18:19:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> The following line results in unused-result warning on linux/clang.
> 
> 
> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function
>  declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>  695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); 
> 
> 
> There are two ways to handle it 
> 
> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment.
> 
> 
> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html
> 
> 
> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option.
> 
> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang.

This pull request has now been integrated.

Changeset: 85ca0813
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85ca0813f1624141993b20b3d8e404f86da2cef3
Stats:     5 lines in 2 files changed: 2 ins; 1 del; 2 mod

8354316: clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9

Reviewed-by: aivanov, ihse, serb, kizune, syan, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/25217

From kizune at openjdk.org  Fri May 23 19:57:55 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 23 May 2025 19:57:55 GMT
Subject: RFR: 8357299: Graphics copyArea doesn't copy any pixels when there
 is overflow
In-Reply-To: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
References: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
Message-ID: <XmXoex0XDhxBjEHkFFtaQw2OxbwJVVU8MJ1yW8KZQ40=.8da154a0-4686-4b9c-912f-e135018d6505@github.com>

On Wed, 21 May 2025 03:17:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Graphics copyArea overflow check bails out of copying pixels if there is overflow.
> The spec says ""If a portion of the source rectangle lies outside the bounds of the component, or is obscured by another window or component, {@code copyArea} *will be unable to copy* the associated pixels"
> 
> which suggests that we should always copy the parts inside the bounds and never the parts outside the bounds
> but it seems currently, in the case of overflow it no longer copies any pixels, including the parts that are inside. 
> So, the fix clips the copyarea region to clip bounds so it will only affect pixels within the valid bounds, and any pixels outside will be ignored.

Looks good.

-------------

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25340#pullrequestreview-2865565717

From prr at openjdk.org  Fri May 23 21:01:52 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 23 May 2025 21:01:52 GMT
Subject: RFR: 8357299: Graphics copyArea doesn't copy any pixels when there
 is overflow
In-Reply-To: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
References: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
Message-ID: <rYu0g4fVWaCX7yxGhNgYijkzsYIUjWnnGdwiq3u5ZeU=.09c39483-6204-4490-b952-5c4ed8cfdc6b@github.com>

On Wed, 21 May 2025 03:17:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Graphics copyArea overflow check bails out of copying pixels if there is overflow.
> The spec says ""If a portion of the source rectangle lies outside the bounds of the component, or is obscured by another window or component, {@code copyArea} *will be unable to copy* the associated pixels"
> 
> which suggests that we should always copy the parts inside the bounds and never the parts outside the bounds
> but it seems currently, in the case of overflow it no longer copies any pixels, including the parts that are inside. 
> So, the fix clips the copyarea region to clip bounds so it will only affect pixels within the valid bounds, and any pixels outside will be ignored.

src/java.desktop/share/native/libawt/java2d/loops/Blit.c line 85:

> 83:     dstInfo.bounds.x2 = UNSAFE_TO_ADD(dstx, width)
> 84:                         ? clipInfo.bounds.x2 : (dstx + width);
> 85:     dstInfo.bounds.y2 = UNSAFE_TO_ADD(dsty, height)

why wouldn't you always want to limit it to the clip ?
I mean shouldn't it be like this ?
dstInfo.bounds.x2 = UNSAFE_TO_ADD(dstx, width)  ? clipInfo.bounds.x2 : (((dstx + width) > clipInfo.bounds.x2) ? clipInfo.bounds.x2 : (dstx + width));
or maybe a bit more readable as 
dstInfo.bounds.x2 = ((UNSAFE_TO_ADD(dstx, width) || ((dstx + width) > clipInfo.bounds.x2)) ? clipInfo.bounds.x2 : (dstx + width);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25340#discussion_r2105414616

From avu at openjdk.org  Fri May 23 22:14:51 2025
From: avu at openjdk.org (Alexey Ushakov)
Date: Fri, 23 May 2025 22:14:51 GMT
Subject: RFR: 8312198: [macos] metal pipeline - window rendering stops
 after display sleep [v2]
In-Reply-To: <Y63JtEnqw4NSdnwVxyrNh8PIFQqShKuwp7GJoO18YWw=.3b07f876-0319-44a1-bf75-ab2cf7988761@github.com>
References: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
 <Y63JtEnqw4NSdnwVxyrNh8PIFQqShKuwp7GJoO18YWw=.3b07f876-0319-44a1-bf75-ab2cf7988761@github.com>
Message-ID: <ezlokRkfs9i6cb4Elsc7JeLmw_ukKVNvUR4uCok3g7M=.1b1ca762-8fbc-4a11-bbe1-823dd8eeb351@github.com>

On Fri, 23 May 2025 11:38:32 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> In stress based scenarios it is observed that nothing is drawn in UI content when display wakes up from sleep in Metal pipeline of macOS. Unfortunately i am not able to reproduce it, but based on details in the bug it looks like we are hitting a race condition. Call to CVDisplayLinkCreateWithActiveCGDisplays is becoming a no-op as there are no active displays right after NSWorkspaceScreensDidWakeNotification. Looks like if we continue to call CVDisplayLinkCreateWithActiveCGDisplays after screen wakeup we are able to get the list of ActiveDisplays and then able to create displayLink.
>> 
>> So now the code is modified to check whether CVDisplayLinkCreateWithActiveCGDisplays is successful or not. If not we will try to call CVDisplayLinkCreateWithActiveCGDisplays for 5 instances each with 1 second delay. There is no regression test for this change because it needs a stress based test with display wakeup/sleep(As captured in JBS, i am not able to reproduce this issue).
>> 
>> I have tested this change for sanity by running animation examples from SwingSet2 and continuously connecting/disconnecting external display. Also by multiple display sleep and wakeup scenarios, i don't see any regressions. Also whole clientlibs CI run is done with this patch and it is also green.
>> 
>> While working on this bug also noticed that many functions of CVDisplayLink is deprecated from macOS 14 and going forward we need to use CADisplayLink/CAMetalDisplayLink. I have raised [JDK-8357418](https://bugs.openjdk.org/browse/JDK-8357418) for the same.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add macro

LGTM

-------------

Marked as reviewed by avu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25342#pullrequestreview-2865818213

From prr at openjdk.org  Fri May 23 22:37:41 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 23 May 2025 22:37:41 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v7]
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <mbZJBoPb7C-uwHk-xQ-m1BuYxWcuKPuOjP34Yc3BjPM=.3deeb2c1-76d6-46a8-b3c9-10070e3ce56c@github.com>

> A simple API to replace java.applet.AudioClip
> 
> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8356049

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24991/files
  - new: https://git.openjdk.org/jdk/pull/24991/files/b3cda856..040e8ddd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=05-06

  Stats: 24 lines in 1 file changed: 17 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24991/head:pull/24991

PR: https://git.openjdk.org/jdk/pull/24991

From prr at openjdk.org  Fri May 23 22:39:57 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 23 May 2025 22:39:57 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
Message-ID: <yUidlMhPIJvuilGLl9nXIdO65Y4V8ojLAesbYbUSZGc=.e5df5135-8f9d-4361-b69b-5dd25569cd5f@github.com>

On Tue, 13 May 2025 21:28:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

OK. I don't agree with some of the above, but not enough to repeat previous points.
So I've made most of the doc changes you ask for.
Take a look ASAP, and I have a question
I added text about potentially "not exiting" but I don't actually see any such problem.
Maybe its some platform thing that you've seen ?
For me, once the end of "main()" is reached the VM exits. Even if a sound is playing and looping.
And even then, are you suggesting this would block System.exit() ?
Where have you actually seen this problem or why are you sure it is a problem ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2905954203

From serb at openjdk.org  Sat May 24 02:59:00 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 24 May 2025 02:59:00 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <yUidlMhPIJvuilGLl9nXIdO65Y4V8ojLAesbYbUSZGc=.e5df5135-8f9d-4361-b69b-5dd25569cd5f@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <yUidlMhPIJvuilGLl9nXIdO65Y4V8ojLAesbYbUSZGc=.e5df5135-8f9d-4361-b69b-5dd25569cd5f@github.com>
Message-ID: <Cd0xLMGf_ZbLoMS3aV7J2546_3y3dvK7zkDLBFwHpK4=.47fb4baa-abfe-44a7-993c-eacd49e81bbf@github.com>

On Fri, 23 May 2025 22:37:35 GMT, Phil Race <prr at openjdk.org> wrote:

> Take a look ASAP, and I have a question

Looking into that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2906329383

From serb at openjdk.org  Sat May 24 03:25:07 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 24 May 2025 03:25:07 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <yUidlMhPIJvuilGLl9nXIdO65Y4V8ojLAesbYbUSZGc=.e5df5135-8f9d-4361-b69b-5dd25569cd5f@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <yUidlMhPIJvuilGLl9nXIdO65Y4V8ojLAesbYbUSZGc=.e5df5135-8f9d-4361-b69b-5dd25569cd5f@github.com>
Message-ID: <d4p1Z_E1gab4JnUxjBYtE40lGE51_uIF1nn8fp2uR74=.29b21360-1b3f-446a-b216-a0c885650712@github.com>

On Fri, 23 May 2025 22:37:35 GMT, Phil Race <prr at openjdk.org> wrote:

>For me, once the end of "main()" is reached the VM exits. Even if a sound is playing and looping.
>And even then, are you suggesting this would block System.exit() ?
>Where have you actually seen this problem or why are you sure it is a problem ?

It does not prevent the application from exiting via `System.exit()`, but it does prevent it from exiting naturally when the main method completes. This is consistent with how AWT behaves (as [documented here](https://github.com/openjdk/jdk/blob/fdda7661906eab63d939e9f482449e21cc143c8f/src/java.desktop/share/classes/java/awt/doc-files/AWTThreadIssues.html#L108)): the application should dispose of all Windows/Frames to be shutdown.

Similarly, this new API appears to follow the same logic: all playable clips must be stopped, otherwise the application will keep running indefinitely.

I tested this behavior on macOS using [this MIDI file](https://en.wikipedia.org/wiki/File:MIDI_sample.mid?oldformat=true).

import java.io.File;

import javax.sound.SoundClip;

public final class TestClip {
    public static void main(String[] args) throws Exception {
        SoundClip soundClip = SoundClip.createSoundClip(new File("MIDI_sample.mid"));
        soundClip.loop();
        System.out.println("end main");
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2906346048

From serb at openjdk.org  Sat May 24 03:36:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 24 May 2025 03:36:01 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v4]
In-Reply-To: <TeBe9DI5AuCjtP4iTp7g1UAhafKnpdz-4DHaRISktd8=.9dbeb508-ac06-4319-91d4-97e6a0108a33@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <TeBe9DI5AuCjtP4iTp7g1UAhafKnpdz-4DHaRISktd8=.9dbeb508-ac06-4319-91d4-97e6a0108a33@github.com>
Message-ID: <tAHygDZOrjsNIxY2viFQ3CK5oD0gzaJsJ6CbR1kzc20=.c446c35e-6db9-4628-950c-058d77b5aad2@github.com>

On Fri, 23 May 2025 08:05:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
>> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
>> Fixed by setting the divider location before rendering the left and right components..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set orientation only if changed...add headful in test

src/java.desktop/share/classes/javax/swing/JSplitPane.java line 373:

> 371:     public void setComponentOrientation(ComponentOrientation orientation) {
> 372:         if (!orientation.equals(this.getComponentOrientation())) {
> 373:             super.setComponentOrientation(orientation);

I would like to bring up for discussion whether we should move this line outside the if block. From what I can tell, it was always executed before the initial fix, so this change might affect the original behavior.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25294#discussion_r2105687915

From serb at openjdk.org  Sat May 24 10:45:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 24 May 2025 10:45:57 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v7]
In-Reply-To: <mbZJBoPb7C-uwHk-xQ-m1BuYxWcuKPuOjP34Yc3BjPM=.3deeb2c1-76d6-46a8-b3c9-10070e3ce56c@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <mbZJBoPb7C-uwHk-xQ-m1BuYxWcuKPuOjP34Yc3BjPM=.3deeb2c1-76d6-46a8-b3c9-10070e3ce56c@github.com>
Message-ID: <Ef2ng7_ZdMhn_LEO-3T4Ykuc31YktUlBNHb-ltuAKtM=.4bd212e5-cb8b-4fa2-bb12-e6c95db275a2@github.com>

On Fri, 23 May 2025 22:37:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24991#pullrequestreview-2866256512

From aturbanov at openjdk.org  Sat May 24 16:36:04 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 24 May 2025 16:36:04 GMT
Subject: RFR: 8357686: Remove unnecessary Map.get from
 AWTAutoShutdown.unregisterPeer
Message-ID: <WJzTsQXeUxbCwz6_LdLb8zhjUAai49Rf07JjQk3pa9Y=.a24c1287-fc15-4a0c-a1bf-683dd8e18c08@github.com>

Instead of separate `.get(Key)`+`.remove(Key)` calls we can call `.remove(Key, Value)`.
`peerMap` is an `IdentityHashMap`. IdentityHashMap.remove compares values with == since Java 20 ([JDK-8178355](https://bugs.openjdk.org/browse/JDK-8178355))

-------------

Commit messages:
 - [PATCH] Remove unnecessary Map.get from AWTAutoShutdown.unregisterPeer

Changes: https://git.openjdk.org/jdk/pull/24858/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24858&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357686
  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24858.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24858/head:pull/24858

PR: https://git.openjdk.org/jdk/pull/24858

From serb at openjdk.org  Sat May 24 16:36:04 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 24 May 2025 16:36:04 GMT
Subject: RFR: 8357686: Remove unnecessary Map.get from
 AWTAutoShutdown.unregisterPeer
In-Reply-To: <WJzTsQXeUxbCwz6_LdLb8zhjUAai49Rf07JjQk3pa9Y=.a24c1287-fc15-4a0c-a1bf-683dd8e18c08@github.com>
References: <WJzTsQXeUxbCwz6_LdLb8zhjUAai49Rf07JjQk3pa9Y=.a24c1287-fc15-4a0c-a1bf-683dd8e18c08@github.com>
Message-ID: <9iAV69pP620sOtr4J53qkvqJWUnauvO_iTevk6hBzQs=.22f5de1d-ee92-4d2e-ae5b-dc811b91d5c5@github.com>

On Thu, 24 Apr 2025 20:18:01 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate `.get(Key)`+`.remove(Key)` calls we can call `.remove(Key, Value)`.
> `peerMap` is an `IdentityHashMap`. IdentityHashMap.remove compares values with == since Java 20 ([JDK-8178355](https://bugs.openjdk.org/browse/JDK-8178355))

looks fine

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24858#issuecomment-2882061238

From aturbanov at openjdk.org  Sat May 24 16:42:28 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 24 May 2025 16:42:28 GMT
Subject: RFR: 8357687: Remove unnecessary Map.containsKey from
 GraphicsEnvironment implementations
Message-ID: <1uiKqIpG8uZ6YKrglYBxK7nMYaqioOirqfiRAp5z7Dw=.813063e1-e218-4794-8bc1-fd8f543c4a74@github.com>

`devices` contains only non-null values. It means instead of separate `containsKey` call we can just call `HashMap.get` and then compare result with `null`.

-------------

Commit messages:
 - [PATCH] Remove unnecessary Map.containsKey from CGraphicsEnvironment.initDevices
 - [PATCH] Remove unnecessary Map.containsKey from X11GraphicsEnvironment.initDevices

Changes: https://git.openjdk.org/jdk/pull/24907/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24907&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357687
  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24907/head:pull/24907

PR: https://git.openjdk.org/jdk/pull/24907

From serb at openjdk.org  Sat May 24 16:42:29 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 24 May 2025 16:42:29 GMT
Subject: RFR: 8357687: Remove unnecessary Map.containsKey from
 GraphicsEnvironment implementations
In-Reply-To: <1uiKqIpG8uZ6YKrglYBxK7nMYaqioOirqfiRAp5z7Dw=.813063e1-e218-4794-8bc1-fd8f543c4a74@github.com>
References: <1uiKqIpG8uZ6YKrglYBxK7nMYaqioOirqfiRAp5z7Dw=.813063e1-e218-4794-8bc1-fd8f543c4a74@github.com>
Message-ID: <OiY5enOwhiRlPwlaKN1OUJIcZM5fenZR_FolQ4M_bbY=.fb1b32bb-1fe9-4a9b-bbe6-a941bf770ad3@github.com>

On Sun, 27 Apr 2025 21:04:34 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `devices` contains only non-null values. It means instead of separate `containsKey` call we can just call `HashMap.get` and then compare result with `null`.

src/java.desktop/unix/classes/sun/awt/X11GraphicsEnvironment.java line 236:

> 234:         for (int id = 0; id < numScreens; ++id) {
> 235:             X11GraphicsDevice d = old.remove(id);
> 236:             devices.put(id, d != null ? d : new X11GraphicsDevice(id));

same can be done in CGraphicsEnvironment.java

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24907#discussion_r2067795484

From aturbanov at openjdk.org  Sat May 24 16:42:29 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 24 May 2025 16:42:29 GMT
Subject: RFR: 8357687: Remove unnecessary Map.containsKey from
 GraphicsEnvironment implementations
In-Reply-To: <OiY5enOwhiRlPwlaKN1OUJIcZM5fenZR_FolQ4M_bbY=.fb1b32bb-1fe9-4a9b-bbe6-a941bf770ad3@github.com>
References: <1uiKqIpG8uZ6YKrglYBxK7nMYaqioOirqfiRAp5z7Dw=.813063e1-e218-4794-8bc1-fd8f543c4a74@github.com>
 <OiY5enOwhiRlPwlaKN1OUJIcZM5fenZR_FolQ4M_bbY=.fb1b32bb-1fe9-4a9b-bbe6-a941bf770ad3@github.com>
Message-ID: <8KI3_JdatrKQHuZTvFg8R4XB3qML-kX2Rg3Qv97zxRA=.ed55db62-f96f-4637-b3c6-42a7e87d2941@github.com>

On Wed, 30 Apr 2025 03:26:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> `devices` contains only non-null values. It means instead of separate `containsKey` call we can just call `HashMap.get` and then compare result with `null`.
>
> src/java.desktop/unix/classes/sun/awt/X11GraphicsEnvironment.java line 236:
> 
>> 234:         for (int id = 0; id < numScreens; ++id) {
>> 235:             X11GraphicsDevice d = old.remove(id);
>> 236:             devices.put(id, d != null ? d : new X11GraphicsDevice(id));
> 
> same can be done in CGraphicsEnvironment.java

Do you suggest to update it in this PR? Or file a separate issue?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24907#discussion_r2074196187

From serb at openjdk.org  Sat May 24 16:42:29 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 24 May 2025 16:42:29 GMT
Subject: RFR: 8357687: Remove unnecessary Map.containsKey from
 GraphicsEnvironment implementations
In-Reply-To: <8KI3_JdatrKQHuZTvFg8R4XB3qML-kX2Rg3Qv97zxRA=.ed55db62-f96f-4637-b3c6-42a7e87d2941@github.com>
References: <1uiKqIpG8uZ6YKrglYBxK7nMYaqioOirqfiRAp5z7Dw=.813063e1-e218-4794-8bc1-fd8f543c4a74@github.com>
 <OiY5enOwhiRlPwlaKN1OUJIcZM5fenZR_FolQ4M_bbY=.fb1b32bb-1fe9-4a9b-bbe6-a941bf770ad3@github.com>
 <8KI3_JdatrKQHuZTvFg8R4XB3qML-kX2Rg3Qv97zxRA=.ed55db62-f96f-4637-b3c6-42a7e87d2941@github.com>
Message-ID: <now8JUsurTYr-7sggV5oQgaJ_4s3ux37YnF7Y9sgS_4=.8075f028-34cd-46f0-bd9b-ee583194b85b@github.com>

On Mon, 5 May 2025 21:00:37 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.desktop/unix/classes/sun/awt/X11GraphicsEnvironment.java line 236:
>> 
>>> 234:         for (int id = 0; id < numScreens; ++id) {
>>> 235:             X11GraphicsDevice d = old.remove(id);
>>> 236:             devices.put(id, d != null ? d : new X11GraphicsDevice(id));
>> 
>> same can be done in CGraphicsEnvironment.java
>
> Do you suggest to update it in this PR? Or file a separate issue?

same PR, code in x11 was copied from macOS

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24907#discussion_r2085733953

From aturbanov at openjdk.org  Sat May 24 16:44:28 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 24 May 2025 16:44:28 GMT
Subject: RFR: 8357688: Remove unnecessary List.get before remove in
 PopupFactory
Message-ID: <3fcUgHLShP5HamE2sRaXGbXg2gJzO9xOu28IQ_eVZyo=.1de88e4f-9519-4160-97b8-41072221fc07@github.com>

Instead of separate List.get+List.remove calls we can use single `removeFirst`. It's clearer.

-------------

Commit messages:
 - [PATCH] Remove unnecessary List.get before remove in PopupFactory

Changes: https://git.openjdk.org/jdk/pull/25283/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25283&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357688
  Stats: 13 lines in 1 file changed: 0 ins; 6 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25283.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25283/head:pull/25283

PR: https://git.openjdk.org/jdk/pull/25283

From serb at openjdk.org  Sat May 24 16:44:28 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 24 May 2025 16:44:28 GMT
Subject: RFR: 8357688: Remove unnecessary List.get before remove in
 PopupFactory
In-Reply-To: <3fcUgHLShP5HamE2sRaXGbXg2gJzO9xOu28IQ_eVZyo=.1de88e4f-9519-4160-97b8-41072221fc07@github.com>
References: <3fcUgHLShP5HamE2sRaXGbXg2gJzO9xOu28IQ_eVZyo=.1de88e4f-9519-4160-97b8-41072221fc07@github.com>
Message-ID: <Zs4KTwOwDHc6BvWamwjC5Fq_mViEvux27Z4qg3zBgFU=.9afbd9db-91ff-490b-ac88-75c946e9b839@github.com>

On Sat, 17 May 2025 07:42:59 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate List.get+List.remove calls we can use single `removeFirst`. It's clearer.

loos fine

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25283#issuecomment-2889282702

From prr at openjdk.org  Sat May 24 17:59:47 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 24 May 2025 17:59:47 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v8]
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <Dwh8vVPHscYG9yLzZMFiz2rnT2R4eJmJGPadS9wQOUc=.3d437738-d28a-439f-8888-69b3cbba2000@github.com>

> A simple API to replace java.applet.AudioClip
> 
> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8356049

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24991/files
  - new: https://git.openjdk.org/jdk/pull/24991/files/040e8ddd..f31ce649

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=06-07

  Stats: 13 lines in 2 files changed: 8 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24991/head:pull/24991

PR: https://git.openjdk.org/jdk/pull/24991

From prr at openjdk.org  Sat May 24 17:59:48 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 24 May 2025 17:59:48 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <d4p1Z_E1gab4JnUxjBYtE40lGE51_uIF1nn8fp2uR74=.29b21360-1b3f-446a-b216-a0c885650712@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <yUidlMhPIJvuilGLl9nXIdO65Y4V8ojLAesbYbUSZGc=.e5df5135-8f9d-4361-b69b-5dd25569cd5f@github.com>
 <d4p1Z_E1gab4JnUxjBYtE40lGE51_uIF1nn8fp2uR74=.29b21360-1b3f-446a-b216-a0c885650712@github.com>
Message-ID: <VhY_4HC0yCxL-zhJJ-OTEmajbolFugM0KBgdpof_KsI=.aa258f42-4c45-4998-ac17-149534e9ec4f@github.com>

On Sat, 24 May 2025 03:22:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > For me, once the end of "main()" is reached the VM exits. Even if a sound is playing and looping.
> > And even then, are you suggesting this would block System.exit() ?
> > Where have you actually seen this problem or why are you sure it is a problem ?
> 
> It does not prevent the application from exiting via `System.exit()`, but it does prevent it from exiting naturally when the main method completes. This is consistent with how AWT behaves (as [documented here](https://github.com/openjdk/jdk/blob/fdda7661906eab63d939e9f482449e21cc143c8f/src/java.desktop/share/classes/java/awt/doc-files/AWTThreadIssues.html#L108)): the application should dispose of all Windows/Frames to be shutdown.
> 
> Similarly, this new API appears to follow the same logic: all playable clips must be stopped, otherwise the application will keep running indefinitely.
> 
> I tested this behavior on macOS using [this MIDI file](https://en.wikipedia.org/wiki/File:MIDI_sample.mid?oldformat=true).
> 
> ```
> import java.io.File;
> 
> import javax.sound.SoundClip;
> 
> public final class TestClip {
>     public static void main(String[] args) throws Exception {
>         SoundClip soundClip = SoundClip.createSoundClip(new File("MIDI_sample.mid"));
>         soundClip.loop();
>         System.out.println("end main");
>     }
> }
> ```

So it seems it varies depending on content-type.

This midi case creates a DataPusher which creates a non-daemon thread.

                pushThread = JSSecurityManager.createThread(this,
                                                            "DataPusher", // name
                                                            false,  // daemon <<<<<<<<<<<<<<
                                                            -1,    // priority
                                                            true); // doStart


DataPusher is only used by JavaAudioSoundClip although that is used by a few content handlers as well as the *Clip APIs.
Other than this only MidiInDevice creates a non-daemon thread and that won't be used by SoundClip

So I am sure it is possible to pass in a parameter to tell DataPusher it should use a daemon thread for this case - leaving other cases unaffected - and then we'd consistently terminate and can remove all the words in the javadoc about this.

Take a look at the commit I am pushing now - updates the implementation but not (yet) revising the javadoc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2906952672

From prr at openjdk.org  Sat May 24 18:35:20 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 24 May 2025 18:35:20 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v9]
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <tYJOtkztqE50q9CiGrWTbWRMljeiOlhiIDLkckw4stI=.ac7bc907-10ad-4aa9-be66-677c79dd4d17@github.com>

> A simple API to replace java.applet.AudioClip
> 
> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8356049

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24991/files
  - new: https://git.openjdk.org/jdk/pull/24991/files/f31ce649..88202603

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=07-08

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24991/head:pull/24991

PR: https://git.openjdk.org/jdk/pull/24991

From prr at openjdk.org  Sat May 24 18:35:20 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 24 May 2025 18:35:20 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <VhY_4HC0yCxL-zhJJ-OTEmajbolFugM0KBgdpof_KsI=.aa258f42-4c45-4998-ac17-149534e9ec4f@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <yUidlMhPIJvuilGLl9nXIdO65Y4V8ojLAesbYbUSZGc=.e5df5135-8f9d-4361-b69b-5dd25569cd5f@github.com>
 <d4p1Z_E1gab4JnUxjBYtE40lGE51_uIF1nn8fp2uR74=.29b21360-1b3f-446a-b216-a0c885650712@github.com>
 <VhY_4HC0yCxL-zhJJ-OTEmajbolFugM0KBgdpof_KsI=.aa258f42-4c45-4998-ac17-149534e9ec4f@github.com>
Message-ID: <XgV21mIhlFBmUHX3cvNDoUWUKtNP5_uqTUF66redohk=.e5b12e0a-dea6-4efb-83ae-64ec9fb55b4c@github.com>

On Sat, 24 May 2025 17:54:08 GMT, Phil Race <prr at openjdk.org> wrote:

> Take a look at the commit I am pushing now - updates the implementation but not (yet) revising the javadoc.

that commit wasn't all of it - one more commit just pushed to restrict it to SoundClip

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2906967775

From serb at openjdk.org  Sat May 24 23:29:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 24 May 2025 23:29:56 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <XgV21mIhlFBmUHX3cvNDoUWUKtNP5_uqTUF66redohk=.e5b12e0a-dea6-4efb-83ae-64ec9fb55b4c@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <yUidlMhPIJvuilGLl9nXIdO65Y4V8ojLAesbYbUSZGc=.e5df5135-8f9d-4361-b69b-5dd25569cd5f@github.com>
 <d4p1Z_E1gab4JnUxjBYtE40lGE51_uIF1nn8fp2uR74=.29b21360-1b3f-446a-b216-a0c885650712@github.com>
 <VhY_4HC0yCxL-zhJJ-OTEmajbolFugM0KBgdpof_KsI=.aa258f42-4c45-4998-ac17-149534e9ec4f@github.com>
 <XgV21mIhlFBmUHX3cvNDoUWUKtNP5_uqTUF66redohk=.e5b12e0a-dea6-4efb-83ae-64ec9fb55b4c@github.com>
Message-ID: <karDECU28Z2s5C6C6Z_bHq-BTG_xZHkt1lA2bOZ_Iag=.07588ce0-48a4-47e5-82cc-561cf65d4906@github.com>

On Sat, 24 May 2025 18:32:09 GMT, Phil Race <prr at openjdk.org> wrote:

> that commit wasn't all of it - one more commit just pushed to restrict it to SoundClip

How is the new implementation supposed to implement applications that will simply play audio, such as `./bin/play audio.mid`, looping at the end?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2907396294

From prr at openjdk.org  Sun May 25 00:24:57 2025
From: prr at openjdk.org (Phil Race)
Date: Sun, 25 May 2025 00:24:57 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <karDECU28Z2s5C6C6Z_bHq-BTG_xZHkt1lA2bOZ_Iag=.07588ce0-48a4-47e5-82cc-561cf65d4906@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <yUidlMhPIJvuilGLl9nXIdO65Y4V8ojLAesbYbUSZGc=.e5df5135-8f9d-4361-b69b-5dd25569cd5f@github.com>
 <d4p1Z_E1gab4JnUxjBYtE40lGE51_uIF1nn8fp2uR74=.29b21360-1b3f-446a-b216-a0c885650712@github.com>
 <VhY_4HC0yCxL-zhJJ-OTEmajbolFugM0KBgdpof_KsI=.aa258f42-4c45-4998-ac17-149534e9ec4f@github.com>
 <XgV21mIhlFBmUHX3cvNDoUWUKtNP5_uqTUF66redohk=.e5b12e0a-dea6-4efb-83ae-64ec9fb55b4c@github.com>
 <karDECU28Z2s5C6C6Z_bHq-BTG_xZHkt1lA2bOZ_Iag=.07588ce0-48a4-47e5-82cc-561cf65d4906@github.com>
Message-ID: <M5jhbc-05U-zAFngTQoH14ZGN3UYVVccxdbqfD4Cxyo=.1fed6131-bf56-4869-b9ef-7f10cdac1df3@github.com>

On Sat, 24 May 2025 23:26:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > that commit wasn't all of it - one more commit just pushed to restrict it to SoundClip
> 
> How is the new implementation supposed to implement applications that will simply play audio, such as `./bin/play audio.mid`, looping at the end?

Do mean, "oh now it doesn't block exit, but what if I want it to?"
It already didn't block exit for many cases, maybe almost all typical cases,
so this last change just makes it consistent.
And that would be the typical case for Applet.AudioClip today.

I don't think I want to flip the other way and make all the cases non-daemon.

So the answer would have to be, you don't let main exit, and so perhaps the docs "advice"
would be partially the other way around, like
"Play back is managed in a background thread, which may be a daemon thread.
Applications therefore need to ensure at least one application thread (such as the "main" thread) remains alive to prevent the VM from exiting. Conversely calling stop() is recommended to ensure the play back thread is terminated."

That advice as written is true of Applet.AudioClip today and might be prudent for an application to follow but I do think it would be best if it is as consistent as possible - in the daemon mode.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2907521415

From serb at openjdk.org  Sun May 25 04:59:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 25 May 2025 04:59:02 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v6]
In-Reply-To: <M5jhbc-05U-zAFngTQoH14ZGN3UYVVccxdbqfD4Cxyo=.1fed6131-bf56-4869-b9ef-7f10cdac1df3@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <FAEr664K_R5sf-xeHQOrDP4wEYgZUjmuacBYr7iy53w=.96dae036-80f3-4e01-b7d5-d545c1034a53@github.com>
 <yUidlMhPIJvuilGLl9nXIdO65Y4V8ojLAesbYbUSZGc=.e5df5135-8f9d-4361-b69b-5dd25569cd5f@github.com>
 <d4p1Z_E1gab4JnUxjBYtE40lGE51_uIF1nn8fp2uR74=.29b21360-1b3f-446a-b216-a0c885650712@github.com>
 <VhY_4HC0yCxL-zhJJ-OTEmajbolFugM0KBgdpof_KsI=.aa258f42-4c45-4998-ac17-149534e9ec4f@github.com>
 <XgV21mIhlFBmUHX3cvNDoUWUKtNP5_uqTUF66redohk=.e5b12e0a-dea6-4efb-83ae-64ec9fb55b4c@github.com>
 <karDECU28Z2s5C6C6Z_bHq-BTG_xZHkt1lA2bOZ_Iag=.07588ce0-48a4-47e5-82cc-561cf65d4906@github.com>
 <M5jhbc-05U-zAFngTQoH14ZGN3UYVVccxdbqfD4Cxyo=.1fed6131-bf56-4869-b9ef-7f10cdac1df3@github.com>
Message-ID: <d7UgyWTft99DDw_JS-q4SMTczDbKmM-DjqQChTVOosk=.1fcb3cea-0216-4e62-83f4-1e894fccbcdb@github.com>

On Sun, 25 May 2025 00:22:40 GMT, Phil Race <prr at openjdk.org> wrote:

>"Play back is managed in a background thread, which may be a daemon thread.
Applications therefore need to ensure at least one application thread (such as the "main" thread) remains alive to prevent the VM from exiting. Conversely calling stop() is recommended to ensure the play back thread is terminated."

But how applications can do that? How to check that the sound is playing w/o busy loop at the end?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2907609192

From serb at openjdk.org  Sun May 25 04:59:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 25 May 2025 04:59:02 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v9]
In-Reply-To: <tYJOtkztqE50q9CiGrWTbWRMljeiOlhiIDLkckw4stI=.ac7bc907-10ad-4aa9-be66-677c79dd4d17@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <tYJOtkztqE50q9CiGrWTbWRMljeiOlhiIDLkckw4stI=.ac7bc907-10ad-4aa9-be66-677c79dd4d17@github.com>
Message-ID: <OdMo8kjJ1CZcnWrJVeNZ1PHs555BxW-TGEZzm1vn5IA=.286e9fd3-8e86-48fb-a79e-2431d79b71ed@github.com>

On Sat, 24 May 2025 18:35:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

possibly we can extend this by two group of methods `asyncPlay/play` and `asyncLoop/loop` to make it easy to use in a different situations?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2907609826

From serb at openjdk.org  Sun May 25 07:55:38 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 25 May 2025 07:55:38 GMT
Subject: RFR: 8357598: Toolkit.removeAWTEventListener should handle null
 listener in AWTEventListenerProxy
Message-ID: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>

The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502

AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.

One of the test is updated just to touch that codepath.

-------------

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8357598
 - Update AWTEventListenerProxyTest.java
 - Update AWTEventListenerProxyTest.java
 - 8357598:  Toolkit.removeAWTEventListener should handle null listener in AWTEventListenerProxy

Changes: https://git.openjdk.org/jdk/pull/25401/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25401&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357598
  Stats: 48 lines in 2 files changed: 28 ins; 15 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25401/head:pull/25401

PR: https://git.openjdk.org/jdk/pull/25401

From serb at openjdk.org  Sun May 25 07:55:39 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 25 May 2025 07:55:39 GMT
Subject: RFR: 8357598: Toolkit.removeAWTEventListener should handle null
 listener in AWTEventListenerProxy
In-Reply-To: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
Message-ID: <jwhwGriP0VdxUuGYrZDVUCUt-PfL5GvqG2kozdKiHs4=.26602fee-b25c-4f74-a531-d5828b9fbef8@github.com>

On Thu, 22 May 2025 21:21:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
> 
> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
> 
> One of the test is updated just to touch that codepath.

test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java line 41:

> 39:         EventQueue.invokeAndWait(() -> {
> 40:             Toolkit tk = Toolkit.getDefaultToolkit();
> 41: 

I do not know why it was disabled on XToolkit, seems to work fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25401#discussion_r2106117597

From prr at openjdk.org  Sun May 25 16:42:55 2025
From: prr at openjdk.org (Phil Race)
Date: Sun, 25 May 2025 16:42:55 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v9]
In-Reply-To: <OdMo8kjJ1CZcnWrJVeNZ1PHs555BxW-TGEZzm1vn5IA=.286e9fd3-8e86-48fb-a79e-2431d79b71ed@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <tYJOtkztqE50q9CiGrWTbWRMljeiOlhiIDLkckw4stI=.ac7bc907-10ad-4aa9-be66-677c79dd4d17@github.com>
 <OdMo8kjJ1CZcnWrJVeNZ1PHs555BxW-TGEZzm1vn5IA=.286e9fd3-8e86-48fb-a79e-2431d79b71ed@github.com>
Message-ID: <Rhg5ulcW6zY7saHY1nJYsG8iOhKi56OHtsxkO1mgy7E=.5d9f5605-f672-4fa0-8eaa-505a98ee897a@github.com>

On Sun, 25 May 2025 04:56:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> possibly we can extend this by two group of methods `asyncPlay/play` and `asyncLoop/loop` to make it easy to use in a different situations?
There are probably going to be zero to a handful of apps anywhere that use this API without a UI.
And such an app which is quite focused on the sound playing is quite capable of managing the lifecycle
as part of that.

The needs/uses I see for this API are in UI apps - which aren't about to exit because a clip ends.
For example an audible alert, or effect, reading out tooltip messages (like an AT would do).
Perhaps occasionally a longer clip.

So in almost all such cases apps just want to call play() and have it not block and let it end naturally,
and there's no need to worry about any effect on app termination.

Playing in a loop is likely be much less common that just playing once.
And if you use loop() and it blocks the thread then you've either got to spin up another thread
for when you want to stop it, or more likely call it in a different thread to begin with,
so that's harder to program and you might as well not use the synchronous version and probably won't.
The sole use case is that single thread main program without a UI and that's not enough reason to do it.

Also migrating could be a bit harder if it was exactly the way round you suggested.
playAsync() is what play() does today .. so you'd not want to do change that
And a blocking play() means it couldn't be called on the EDT - might well make migrating to this API harder,
so I think few cases would want to block.

So in summary, I don't see any need to add variants that block by any name.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2907933747

From prr at openjdk.org  Sun May 25 17:06:49 2025
From: prr at openjdk.org (Phil Race)
Date: Sun, 25 May 2025 17:06:49 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v10]
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <lSJejgcB_mZzWCbMR0fZfb-5n49Njlu3A9dztyfDO-s=.7967740d-1e43-47e1-8a5d-3bab8786bb9a@github.com>

> A simple API to replace java.applet.AudioClip
> 
> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8356049

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24991/files
  - new: https://git.openjdk.org/jdk/pull/24991/files/88202603..c92a8ba9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=08-09

  Stats: 26 lines in 1 file changed: 18 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24991/head:pull/24991

PR: https://git.openjdk.org/jdk/pull/24991

From psadhukhan at openjdk.org  Mon May 26 02:41:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 26 May 2025 02:41:10 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v4]
In-Reply-To: <tAHygDZOrjsNIxY2viFQ3CK5oD0gzaJsJ6CbR1kzc20=.c446c35e-6db9-4628-950c-058d77b5aad2@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <TeBe9DI5AuCjtP4iTp7g1UAhafKnpdz-4DHaRISktd8=.9dbeb508-ac06-4319-91d4-97e6a0108a33@github.com>
 <tAHygDZOrjsNIxY2viFQ3CK5oD0gzaJsJ6CbR1kzc20=.c446c35e-6db9-4628-950c-058d77b5aad2@github.com>
Message-ID: <DMhK2yhL3IOU9aq6N1J2Im-EhC_L6IH2qw17aMugygE=.4acbdfe3-3350-4986-9f20-9353a7bc4273@github.com>

On Sat, 24 May 2025 03:32:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set orientation only if changed...add headful in test
>
> src/java.desktop/share/classes/javax/swing/JSplitPane.java line 373:
> 
>> 371:     public void setComponentOrientation(ComponentOrientation orientation) {
>> 372:         if (!orientation.equals(this.getComponentOrientation())) {
>> 373:             super.setComponentOrientation(orientation);
> 
> I would like to bring up for discussion whether we should move this line outside the if block. From what I can tell, it was always executed before the initial fix, so this change might affect the original behavior.

If we call setComponentOrientation in test (like in TestSplitPaneOrientationTest.java which was added for JDK-4265389) then this check would fail as ComponentOrientation object would change if we call super.setComponentOrientation outside the if block and so left/right component would not be set..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25294#discussion_r2106421423

From psadhukhan at openjdk.org  Mon May 26 02:49:58 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 26 May 2025 02:49:58 GMT
Subject: RFR: 8357299: Graphics copyArea doesn't copy any pixels when there
 is overflow
In-Reply-To: <rYu0g4fVWaCX7yxGhNgYijkzsYIUjWnnGdwiq3u5ZeU=.09c39483-6204-4490-b952-5c4ed8cfdc6b@github.com>
References: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
 <rYu0g4fVWaCX7yxGhNgYijkzsYIUjWnnGdwiq3u5ZeU=.09c39483-6204-4490-b952-5c4ed8cfdc6b@github.com>
Message-ID: <ML8SkROb2_eqhMCvsuhTsK3P1SblC-wIf36Bbcxd6EE=.8a395b00-d910-4bf6-bc9e-694636119275@github.com>

On Fri, 23 May 2025 20:59:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> Graphics copyArea overflow check bails out of copying pixels if there is overflow.
>> The spec says ""If a portion of the source rectangle lies outside the bounds of the component, or is obscured by another window or component, {@code copyArea} *will be unable to copy* the associated pixels"
>> 
>> which suggests that we should always copy the parts inside the bounds and never the parts outside the bounds
>> but it seems currently, in the case of overflow it no longer copies any pixels, including the parts that are inside. 
>> So, the fix clips the copyarea region to clip bounds so it will only affect pixels within the valid bounds, and any pixels outside will be ignored.
>
> src/java.desktop/share/native/libawt/java2d/loops/Blit.c line 85:
> 
>> 83:     dstInfo.bounds.x2 = UNSAFE_TO_ADD(dstx, width)
>> 84:                         ? clipInfo.bounds.x2 : (dstx + width);
>> 85:     dstInfo.bounds.y2 = UNSAFE_TO_ADD(dsty, height)
> 
> why wouldn't you always want to limit it to the clip ?
> I mean shouldn't it be like this ?
> dstInfo.bounds.x2 = UNSAFE_TO_ADD(dstx, width)  ? clipInfo.bounds.x2 : (((dstx + width) > clipInfo.bounds.x2) ? clipInfo.bounds.x2 : (dstx + width));
> or maybe a bit more readable as 
> dstInfo.bounds.x2 = ((UNSAFE_TO_ADD(dstx, width) || ((dstx + width) > clipInfo.bounds.x2)) ? clipInfo.bounds.x2 : (dstx + width);

That is because down below it anyway calls
`SurfaceData_IntersectBounds(&dstInfo.bounds, &clipInfo.bounds); `
so it should clip to clipInfo.bounds there I presume..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25340#discussion_r2106426836

From duke at openjdk.org  Mon May 26 05:02:20 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 26 May 2025 05:02:20 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v5]
In-Reply-To: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
Message-ID: <0b4c7bMrktRPr3uiDEiRgvIVQG2HndqAKo5yJg61qhY=.4850c18f-19ac-4f08-81d6-ee3c3d6d5bf3@github.com>

> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
> 
> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
> 2. The transparent pixel is non-zero
> 3. There's more than one such consecutive frame
> 
> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.

Jeremy Wood 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 28 additional commits since the last revision:

 - 8356320: trivial whitespace and comment changes
 - Merge branch 'master' into JDK-8356137
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - 8356137: readding transparency check at (20, 20)
 - GifComparison: fixing error message
 - GifComparison: code cleanup
 - 8356137: change package to access GifComparison
 - GifComparison: adding common helper class for gif bugs
 - 8356120: updating (c) year
 - ... and 18 more: https://git.openjdk.org/jdk/compare/aba76ce9...6caefc11

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25044/files
  - new: https://git.openjdk.org/jdk/pull/25044/files/cfa679a8..6caefc11

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=03-04

  Stats: 125129 lines in 2773 files changed: 76967 ins; 33009 del; 15153 mod
  Patch: https://git.openjdk.org/jdk/pull/25044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25044/head:pull/25044

PR: https://git.openjdk.org/jdk/pull/25044

From duke at openjdk.org  Mon May 26 05:13:50 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 26 May 2025 05:13:50 GMT
Subject: RFR: 8351913: ToolkitImage renders some gifs wrong [v5]
In-Reply-To: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com>
References: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com>
Message-ID: <udQr_KSss-e9-djolQS96tYHNkBj_EWbFK_STLqHcW0=.8edd57f4-c275-46be-ac7e-e5a957f3b119@github.com>

> I do not have much background in LZW compression or in C, but I'm reasonably confident this resolves the problem I'm observing. It looks like the GifImageDecoder was not always correctly handling compression codes after the table reached its limit of ~4096. If anyone has suggestions for improvements I'm happy to make adjustments.
> 
> Luckily while debugging this: I was able to compare the flawed implementation (GifImageDecoder) with ImageIO's implementation (GIFImageReader) to help identify how the suffix/prefix tables are supposed to work.
> 
> ImageIO's implementation may have suffered a similar bug (maybe https://bugs.openjdk.org/browse/JDK-7131823 ?), and that appears to have been backported.
> 
> I have dozens of additional test cases for this problem, but unfortunately I don't have the rights to commit them to the OpenJDK repo. Feel free to email me for additional context/test cases.

Jeremy Wood 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 29 additional commits since the last revision:

 - 8356320: trivial whitespace and comment changes
 - Merge branch 'master' into JDK-8351913
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - 8351913: renaming class, rewording comment
   
   There's a cluster of 4 related gif tickets I intend to put in this /gif/ directory. I want to better clarify exactly what this test focuses on.
 - GifComparison: fixing error message
 - GifComparison: code cleanup
 - 8351913: change package to access GifComparison
 - GifComparison: adding common helper class for gif bugs
 - Merge branch 'master' into JDK-8351913
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - ... and 19 more: https://git.openjdk.org/jdk/compare/088fc5f5...e5dbed64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24271/files
  - new: https://git.openjdk.org/jdk/pull/24271/files/1733a85e..e5dbed64

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24271&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24271&range=03-04

  Stats: 125812 lines in 2777 files changed: 77417 ins; 33246 del; 15149 mod
  Patch: https://git.openjdk.org/jdk/pull/24271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24271/head:pull/24271

PR: https://git.openjdk.org/jdk/pull/24271

From duke at openjdk.org  Mon May 26 05:23:36 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 26 May 2025 05:23:36 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v2]
In-Reply-To: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
Message-ID: <xq-jEN3xzPwk9uicVs21wXhzANrKqMnMM4FMpjiNzjI=.06139166-4a9b-4b9a-bb98-ee3b6b92496f@github.com>

> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer.
> 
> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block.
> 
> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
> 
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one)
> 2. [8356137](https://github.com/openjdk/jdk/pull/25044)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)

Jeremy Wood 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 21 additional commits since the last revision:

 - 8357034: fixing classname
 - 8356320: trivial whitespace and comment changes
 - Merge branch 'master' into JDK-8357034
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - 8357034: fixing ticket number
 - GifComparison: fixing error message
 - Incident 9078482: fix when new trans index is in saved images
   
   This bug hasn't made it out of triage yet; it's incident report # is 9078482
 - GifComparison: code cleanup
 - GifComparison: adding common helper class for gif bugs
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - ... and 11 more: https://git.openjdk.org/jdk/compare/adb906b3...b1a1d7ec

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25264/files
  - new: https://git.openjdk.org/jdk/pull/25264/files/5b982b12..b1a1d7ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25264&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25264&range=00-01

  Stats: 63230 lines in 984 files changed: 37170 ins; 21012 del; 5048 mod
  Patch: https://git.openjdk.org/jdk/pull/25264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25264/head:pull/25264

PR: https://git.openjdk.org/jdk/pull/25264

From duke at openjdk.org  Mon May 26 05:29:45 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 26 May 2025 05:29:45 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v6]
In-Reply-To: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
Message-ID: <io7ydMxQ0hS2b8QqAFfG15cdS8mHUgS_7r9K_bTRCjM=.57de6ddd-621e-479e-b2a8-b687e0d7e322@github.com>

> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
> 
> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
> 2. The transparent pixel is non-zero
> 3. There's more than one such consecutive frame
> 
> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.
> 
> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
> 
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
> 2. [8356137](https://github.com/openjdk/jdk/pull/25044) (this one)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)

Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:

  8356137: Adding copyright to GifComparison

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25044/files
  - new: https://git.openjdk.org/jdk/pull/25044/files/6caefc11..19804549

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=04-05

  Stats: 22 lines in 1 file changed: 22 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25044/head:pull/25044

PR: https://git.openjdk.org/jdk/pull/25044

From duke at openjdk.org  Mon May 26 05:30:44 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 26 May 2025 05:30:44 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v3]
In-Reply-To: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
Message-ID: <LEEgmYFLmKZXBfKsmUItY1pjfOiD5z59TcurHZoyczM=.3bba3934-0a84-4407-bae3-08e29876a8c8@github.com>

> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer.
> 
> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block.
> 
> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
> 
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one)
> 2. [8356137](https://github.com/openjdk/jdk/pull/25044)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)

Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:

  8356137: Adding copyright to GifComparison

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25264/files
  - new: https://git.openjdk.org/jdk/pull/25264/files/b1a1d7ec..3d94c434

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25264&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25264&range=01-02

  Stats: 22 lines in 1 file changed: 22 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25264/head:pull/25264

PR: https://git.openjdk.org/jdk/pull/25264

From duke at openjdk.org  Mon May 26 05:30:55 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 26 May 2025 05:30:55 GMT
Subject: RFR: 8351913: ToolkitImage renders some gifs wrong [v6]
In-Reply-To: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com>
References: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com>
Message-ID: <RZbjIG4YAOBo2P1gglFwOA8rNk46XbbfeFhwWXB9tT8=.0e2c7fc0-74f2-42a4-b4b8-a1f83f32ae30@github.com>

> I do not have much background in LZW compression or in C, but I'm reasonably confident this resolves the problem I'm observing. It looks like the GifImageDecoder was not always correctly handling compression codes after the table reached its limit of ~4096. If anyone has suggestions for improvements I'm happy to make adjustments.
> 
> Luckily while debugging this: I was able to compare the flawed implementation (GifImageDecoder) with ImageIO's implementation (GIFImageReader) to help identify how the suffix/prefix tables are supposed to work.
> 
> ImageIO's implementation may have suffered a similar bug (maybe https://bugs.openjdk.org/browse/JDK-7131823 ?), and that appears to have been backported.
> 
> I have dozens of additional test cases for this problem, but unfortunately I don't have the rights to commit them to the OpenJDK repo. Feel free to email me for additional context/test cases.
> 
> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
> 2. [8356137](https://github.com/openjdk/jdk/pull/25044)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271) (this one)

Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:

  8356137: Adding copyright to GifComparison

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24271/files
  - new: https://git.openjdk.org/jdk/pull/24271/files/e5dbed64..7c45a736

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24271&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24271&range=04-05

  Stats: 22 lines in 1 file changed: 22 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24271/head:pull/24271

PR: https://git.openjdk.org/jdk/pull/24271

From serb at openjdk.org  Mon May 26 05:49:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 26 May 2025 05:49:51 GMT
Subject: RFR: 8312198: [macos] metal pipeline - window rendering stops
 after display sleep [v2]
In-Reply-To: <Y63JtEnqw4NSdnwVxyrNh8PIFQqShKuwp7GJoO18YWw=.3b07f876-0319-44a1-bf75-ab2cf7988761@github.com>
References: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
 <Y63JtEnqw4NSdnwVxyrNh8PIFQqShKuwp7GJoO18YWw=.3b07f876-0319-44a1-bf75-ab2cf7988761@github.com>
Message-ID: <z_D7rcV3w_FDU8lDk5pStL2S9No0k3AfiuuCaZq6wFk=.3bf3a4f1-3b50-45b2-b426-577d8fa7b82d@github.com>

On Fri, 23 May 2025 11:38:32 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> In stress based scenarios it is observed that nothing is drawn in UI content when display wakes up from sleep in Metal pipeline of macOS. Unfortunately i am not able to reproduce it, but based on details in the bug it looks like we are hitting a race condition. Call to CVDisplayLinkCreateWithActiveCGDisplays is becoming a no-op as there are no active displays right after NSWorkspaceScreensDidWakeNotification. Looks like if we continue to call CVDisplayLinkCreateWithActiveCGDisplays after screen wakeup we are able to get the list of ActiveDisplays and then able to create displayLink.
>> 
>> So now the code is modified to check whether CVDisplayLinkCreateWithActiveCGDisplays is successful or not. If not we will try to call CVDisplayLinkCreateWithActiveCGDisplays for 5 instances each with 1 second delay. There is no regression test for this change because it needs a stress based test with display wakeup/sleep(As captured in JBS, i am not able to reproduce this issue).
>> 
>> I have tested this change for sanity by running animation examples from SwingSet2 and continuously connecting/disconnecting external display. Also by multiple display sleep and wakeup scenarios, i don't see any regressions. Also whole clientlibs CI run is done with this patch and it is also green.
>> 
>> While working on this bug also noticed that many functions of CVDisplayLink is deprecated from macOS 14 and going forward we need to use CADisplayLink/CAMetalDisplayLink. I have raised [JDK-8357418](https://bugs.openjdk.org/browse/JDK-8357418) for the same.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add macro

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25342#pullrequestreview-2867286353

From jdv at openjdk.org  Mon May 26 06:06:03 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 26 May 2025 06:06:03 GMT
Subject: RFR: 8312198: [macos] metal pipeline - window rendering stops
 after display sleep [v2]
In-Reply-To: <Y63JtEnqw4NSdnwVxyrNh8PIFQqShKuwp7GJoO18YWw=.3b07f876-0319-44a1-bf75-ab2cf7988761@github.com>
References: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
 <Y63JtEnqw4NSdnwVxyrNh8PIFQqShKuwp7GJoO18YWw=.3b07f876-0319-44a1-bf75-ab2cf7988761@github.com>
Message-ID: <wDCxZ4-HkyA9P8AjVFQl3Q8fVfaUqG4PC7H9BluKCWg=.6c1e29b9-182a-4392-bc3f-cdb693a0d6da@github.com>

On Fri, 23 May 2025 11:38:32 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> In stress based scenarios it is observed that nothing is drawn in UI content when display wakes up from sleep in Metal pipeline of macOS. Unfortunately i am not able to reproduce it, but based on details in the bug it looks like we are hitting a race condition. Call to CVDisplayLinkCreateWithActiveCGDisplays is becoming a no-op as there are no active displays right after NSWorkspaceScreensDidWakeNotification. Looks like if we continue to call CVDisplayLinkCreateWithActiveCGDisplays after screen wakeup we are able to get the list of ActiveDisplays and then able to create displayLink.
>> 
>> So now the code is modified to check whether CVDisplayLinkCreateWithActiveCGDisplays is successful or not. If not we will try to call CVDisplayLinkCreateWithActiveCGDisplays for 5 instances each with 1 second delay. There is no regression test for this change because it needs a stress based test with display wakeup/sleep(As captured in JBS, i am not able to reproduce this issue).
>> 
>> I have tested this change for sanity by running animation examples from SwingSet2 and continuously connecting/disconnecting external display. Also by multiple display sleep and wakeup scenarios, i don't see any regressions. Also whole clientlibs CI run is done with this patch and it is also green.
>> 
>> While working on this bug also noticed that many functions of CVDisplayLink is deprecated from macOS 14 and going forward we need to use CADisplayLink/CAMetalDisplayLink. I have raised [JDK-8357418](https://bugs.openjdk.org/browse/JDK-8357418) for the same.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add macro

With updated changes also I have again tested SwingSet2(multi monitor & sleep/wakeup scenarios) and full clientlibs CI test run and there are no issues seen.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25342#issuecomment-2908629578

From jdv at openjdk.org  Mon May 26 06:06:03 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 26 May 2025 06:06:03 GMT
Subject: Integrated: 8312198: [macos] metal pipeline - window rendering stops
 after display sleep
In-Reply-To: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
References: <vPtG44bCNNp_I0SlywIdNkpNSpWowSEpMGmTEYufb-8=.abc6c2d9-1a46-4b4c-8fae-97947f23e971@github.com>
Message-ID: <L3AUuloiooA5aKHUv4utBuBLP5JGtDRhy4KRRAj2wlk=.11c3e0c8-faaa-4aab-be4a-8839881e375a@github.com>

On Wed, 21 May 2025 06:11:18 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> In stress based scenarios it is observed that nothing is drawn in UI content when display wakes up from sleep in Metal pipeline of macOS. Unfortunately i am not able to reproduce it, but based on details in the bug it looks like we are hitting a race condition. Call to CVDisplayLinkCreateWithActiveCGDisplays is becoming a no-op as there are no active displays right after NSWorkspaceScreensDidWakeNotification. Looks like if we continue to call CVDisplayLinkCreateWithActiveCGDisplays after screen wakeup we are able to get the list of ActiveDisplays and then able to create displayLink.
> 
> So now the code is modified to check whether CVDisplayLinkCreateWithActiveCGDisplays is successful or not. If not we will try to call CVDisplayLinkCreateWithActiveCGDisplays for 5 instances each with 1 second delay. There is no regression test for this change because it needs a stress based test with display wakeup/sleep(As captured in JBS, i am not able to reproduce this issue).
> 
> I have tested this change for sanity by running animation examples from SwingSet2 and continuously connecting/disconnecting external display. Also by multiple display sleep and wakeup scenarios, i don't see any regressions. Also whole clientlibs CI run is done with this patch and it is also green.
> 
> While working on this bug also noticed that many functions of CVDisplayLink is deprecated from macOS 14 and going forward we need to use CADisplayLink/CAMetalDisplayLink. I have raised [JDK-8357418](https://bugs.openjdk.org/browse/JDK-8357418) for the same.

This pull request has now been integrated.

Changeset: a50d3bee
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a50d3bee12cd2f528067bc15b404cf2289977af5
Stats:     24 lines in 2 files changed: 19 ins; 0 del; 5 mod

8312198: [macos] metal pipeline - window rendering stops after display sleep

Reviewed-by: serb, avu, prr

-------------

PR: https://git.openjdk.org/jdk/pull/25342

From ihse at openjdk.org  Mon May 26 07:47:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 07:47:02 GMT
Subject: RFR: 8356977: UTF-8 cleanups
In-Reply-To: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
Message-ID: <lt8vg3M1QU-xbe_E0l4n1j9V9sM_0VsM8kOt11Mk1L0=.d6e6845c-ff78-45f2-8f8e-6a40b9e12ba1@github.com>

On Thu, 15 May 2025 18:30:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> test/jdk/sun/text/resources/LocaleDataTest.java line 106:
> 
>> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
>> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
>> 106:  *        LocaleNames/fr_FR/US=?tats-Unis
> 
> This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.

ISO-8859-1 does not sound good, and got me worried. But in fact it seems like the file is pure ASCII, and that is fine. 

However, if the file should ever be changed to include actual ISO-8859-1 encoding, this might break if tools assume it is UTF-8-encoding, since not all ISO-8859-1 encodings are valid UTF-8.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160

From ihse at openjdk.org  Mon May 26 08:20:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:20:19 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Restore MenuShortcut.java
 - Restore LocaleDataTest.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25228/files
  - new: https://git.openjdk.org/jdk/pull/25228/files/9c904992..7184e685

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25228.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25228/head:pull/25228

PR: https://git.openjdk.org/jdk/pull/25228

From ihse at openjdk.org  Mon May 26 08:20:46 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:20:46 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>
Message-ID: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>

On Thu, 22 May 2025 21:43:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore MenuShortcut.java
>>  - Restore LocaleDataTest.java
>
> src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49:
> 
>> 47:  * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by
>> 48:  * <p>
>> 49:  * <code>MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false);</code>
> 
> This is javadoc inJava SE specification. As is the Action case below.
> I can't think of any actual harm from this change, so OK,  but I am not seeing why it is needed.

The resulting Javadoc html files will contain the same character before and after this fix, so there is no specification change. 

I did this since I thought it increased readability of the source code, but I can just as well revert it.

> test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:
> 
>> 61: 
>> 62:     private static final String INSTRUCTIONS =
>> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "
> 
> I really don't like these tests being changed. It isn't part of the JDK build.
> People compile these in all sorts of locales.
> Please revert all the changes in the client tests.

Just a clarification. What I did was convert curly quotes and an em dash to normal ASCII quotes and an ASCII hyphen, just as it is in all other `INSTRUCTIONS` in the tests. This is similar to what was done in JDK-8354273 and JDK-8354213, and should have been made as part of those PRs if I only had noticed this place by then.

The user's locale should not really matter. When have stringent locale requirements for building, and automatically setup the correct locale while building. I don't think the locale will matter at runtime either, but it n the rare case that it should matter, then pure ASCII would be prefer, wouldn't it?

Let me know if you still want me to revert it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106769659
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106791184

From ihse at openjdk.org  Mon May 26 08:21:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:21:16 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
Message-ID: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>

On Mon, 26 May 2025 08:10:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java

test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java line 90:

> 88:                 printKey(e);
> 89:                 int keychar = e.getKeyChar();
> 90:                 if (keychar == 27) { // Escape character is 27 or \u001b

@prrace I think this is an actual bug. `\u0021` codes to `!`, and I don't think that is what was meant. Do you still want me to revert it?

test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java line 188:

> 186:                     +          "\"After\" lists.\n"
> 187:                     + "              Added printers are highlighted with "
> 188:                     +               "green color, removed ones \u2014 with "

@prrace This too seems like a bug, or rather a typo. The text currently reads `Added printers are highlighted with green color, removed ones ? with red color.`. The Em dash does not make any sense to me, and seems to be a copy paste error.

Do you still want me to revert it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106774492
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106778974

From ihse at openjdk.org  Mon May 26 08:24:36 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:24:36 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <2QcYZvy5pjx8J6Fi6j59uiHSfnqkp1yUHakx2qsxzKw=.d5720f94-adb8-4f86-aeed-e403c8e43066@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
 <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
 <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>
 <bffWy8H4d6xnje0Gz_jIyv5jPBMuqp7S-iBFZTioTng=.7ee33246-76c2-470f-b608-894b5ba93988@github.com>
 <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com>
 <2QcYZvy5pjx8J6Fi6j59uiHSfnqkp1yUHakx2qsxzKw=.d5720f94-adb8-4f86-aeed-e403c8e43066@github.com>
Message-ID: <C8kpgkckLXbObd9FCCt4nkuI9QAc7A9qZHWZsj0Oaz4=.505c65b6-1685-47ef-a4d6-cc48982f6329@github.com>

On Thu, 22 May 2025 21:26:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> FYI, the style guide for France [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France):
>> 
>> - U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark, and exclamation mark.
>> - U+00A0 (No-Break Space NBSP) preceding colon.
>> 
>> Similar conventions are used in other French speaking countries.
>
>> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences.
> 
>> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space.
> 
> 
> I didn't say it reversed that entire changeset. I am saying that the previous changeset for L10N changed
> 
> the Java unicode escape to UTF-8 for the localised message string.
> 
> You propose restoring it to Java escape.
> 
> 
> I wouldn't be surprised if the next message drop reverses what you reversed.
> 
> I don't know what tools the L10N team use but there's a chance it doesn't handle Java escapes
> 
> since that is very much a Java thing. So you are probably making the translation job harder.
> 
> 
> So I am suggesting you leave all of the translation files as is.
> Which might mean withdrawing this PR.

Fair enough. This was meant to be an improvement in readability, not a hindrance for working efficiently. I'll withdraw this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2106804794

From ihse at openjdk.org  Mon May 26 08:24:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:24:38 GMT
Subject: Withdrawn: 8356980: Better handling of non-breaking space
In-Reply-To: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
Message-ID: <e4LLN-RARXr9ONGJ35PikxdOZFdsem63EHsN5ZlOr3I=.cd96d653-af8b-4868-b0e0-5c869835d66c@github.com>

On Wed, 14 May 2025 15:11:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences.
> 
> I have checked:
> * U+00A0 NO-BREAK SPACE (NBSP)
> * U+202F NARROW NO-BREAK SPACE (NNBSP)
> * U+2007 FIGURE SPACE
> * U+2060 WORD JOINER
> 
> In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25234

From ihse at openjdk.org  Mon May 26 08:25:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:25:07 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <-HdnkBjrOxo3jUA8jSYhmElKM55oIcSRYYgu70KPR8M=.24dfddf4-6890-4a61-9cef-85f1a2c1238a@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

@JoeWang-Java @naotoj Can you help review this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2908936863

From ihse at openjdk.org  Mon May 26 08:27:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:27:45 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <rtLeXcGYPjdVH16A5db5VvNl3AFbcqwVQYzbrrYZrZo=.5bdee26b-cc5f-4834-9cf3-f710cb34c0a0@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

@justin-curtis-lu Are these files handled by the translation team?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2908942083

From duke at openjdk.org  Mon May 26 08:39:25 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 26 May 2025 08:39:25 GMT
Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a
 password when double clicked at the starting and end of the text
Message-ID: <zz-73SqK7SlO2jnHNxCWunPOE7iHZiZVrN-PkqIMFfg=.18c45065-f8a3-48eb-9ae5-d6dd4a5c02dc@github.com>

Make sure AquaTextPasswordFieldUI can't use selectWordAction.

The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI, but the AquaTextPasswordFieldUI (and SynthPasswordFieldUI) do NOT extend the BasicPasswordFieldUI, so they weren't inheriting this solution.

So the problem is partially about multiple inheritance.

My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields.

There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions.

-------------

Commit messages:
 - 8354646: Make sure AquaTextPasswordFieldUI can't use selectWordAction
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge pull request #5 from openjdk/master
 - ... and 4 more: https://git.openjdk.org/jdk/compare/4a4209ff...ccf24d73

Changes: https://git.openjdk.org/jdk/pull/25443/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354646
  Stats: 100 lines in 3 files changed: 81 ins; 19 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443

PR: https://git.openjdk.org/jdk/pull/25443

From psadhukhan at openjdk.org  Mon May 26 09:38:33 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 26 May 2025 09:38:33 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v24]
In-Reply-To: <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
Message-ID: <TY_z1ANWBOslFeBPw7TxAFiqo0FnBhbEXe4c1ZK3h-I=.ae03dc6e-f497-4b22-a051-aeee6da08e36@github.com>

On Wed, 12 Mar 2025 11:00:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fix

I checked rbma.cpp output where I think we can only support the 4th item in the list (which is this)
![image](https://github.com/user-attachments/assets/32067d1a-8ab2-444c-8db3-265f0e64f6ec)

This is because we have [JRadioButtonMenuItem](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/JRadioButtonMenuItem.html#%3Cinit%3E(java.lang.String,javax.swing.Icon,boolean))([String](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/String.html) text, [Icon](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/Icon.html) icon, boolean selected)
API which only supports one icon image (so checked/unchecked icon image **in addition** to item icon as below image is not possible in my opinion in Java swing)

![image](https://github.com/user-attachments/assets/581f4e36-6b55-4a1c-8a5a-465741e43858)

 
The current state of PR supports this 4th item. 
Only thing different is when there is no imageicon and menuitem is selected, then the text seems to be in same vertical line as the other items (in native rbma output)
![image](https://github.com/user-attachments/assets/897f3277-df2e-4827-8381-e51ad8007251)

but current PR the text is shifted to left (when there is no imageicon ie 3rd item in list) and occupies icon space, as below
![image](https://github.com/user-attachments/assets/43fb1ccc-b475-4147-8131-22f2fc918375)

This is because in most cases (and in SwingSet2) the radiomenu items are drawn without imageicon and there is no extra space between radio bullet and menu text

![image](https://github.com/user-attachments/assets/c5cd5840-d58e-4456-8217-cf7f3ba9bb4e)

so if we cater to text shifting to same vertical line, there will be difference in behavior w.r.t existing one and user will notice a shift in text to accomodate non-existing image icon)

but it is fixable, 
so if we are in consensus about supporting the 4th item in rbma.cpp output in Java swing with text in same vertical offset, then let mw know..Anything else in addition needs discussion whether we can support...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2909069636

From abaya at openjdk.org  Mon May 26 09:50:58 2025
From: abaya at openjdk.org (Anass Baya)
Date: Mon, 26 May 2025 09:50:58 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v3]
In-Reply-To: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
Message-ID: <ax_h1SOxZ8rSs1I0QhD2MAGRzICK_1JaopLQVDkvjD0=.1f6a14d8-3036-4bea-8ead-6abb69fc1b81@github.com>

> **Analysis :**
> 
> Whether the test passes on the main line or fails, the behavior is still incorrect.
> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly.
> 
> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt.
> 
> This causes the test to proceed immediately to the validation step:
> 
> if (fd.isVisible()) {
>     throw new RuntimeException("File Dialog is not closed");
> }
> 
> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet)
> 
> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation.
> 
> **Proposed fix:**
> 
> set the CountDownLatch to 2
> 
> **Proposed enhancements :**
> 
> Remove unnecessary threads (Thread and Thread-2)
> Properly handle delays and robot.waitForIdle()
> Avoid indefinite blocking on latch.await()
> 
> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds
> 
> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details

Anass Baya has updated the pull request incrementally with one additional commit since the last revision:

  Reduce delay to 500
  Invoke isvisble() method under EDT

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25184/files
  - new: https://git.openjdk.org/jdk/pull/25184/files/0e234a54..31472930

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25184&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25184&range=01-02

  Stats: 13 lines in 1 file changed: 7 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25184/head:pull/25184

PR: https://git.openjdk.org/jdk/pull/25184

From aivanov at openjdk.org  Mon May 26 16:43:28 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 26 May 2025 16:43:28 GMT
Subject: RFR: 8357675: Amend headless message
Message-ID: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>

Currently, the default headless message ends with a comma instead of full stop and has an additional line break.


Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException:
No X11 DISPLAY variable was set,
or no headful library support was found,
but this program performed an operation which requires it,

        at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:158)
        at java.desktop/java.awt.Window.<init>(Window.java:518)
        at java.desktop/java.awt.Frame.<init>(Frame.java:428)
        at java.desktop/javax.swing.JFrame.<init>(JFrame.java:224) 


**Fix:**

Amend the message so that it ends with a full stop and remove the line break.


Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException:
No X11 DISPLAY variable was set,
or no headful library support was found,
but this program performed an operation which requires it.
        at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:158)
        at java.desktop/java.awt.Window.<init>(Window.java:518)
        at java.desktop/java.awt.Frame.<init>(Frame.java:428)
        at java.desktop/javax.swing.JFrame.<init>(JFrame.java:224)


**Testing:**

Build a headless-only JDK (pass `--enable-headless-only` to the `configure` script) and create a `JFrame`.

It's impossible to create an automated test for this change, and I don't think a test is required, it's a cosmetic change.

-------------

Commit messages:
 - 8357675: Amend headless message

Changes: https://git.openjdk.org/jdk/pull/25453/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25453&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357675
  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25453.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25453/head:pull/25453

PR: https://git.openjdk.org/jdk/pull/25453

From duke at openjdk.org  Mon May 26 16:51:11 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 26 May 2025 16:51:11 GMT
Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in
 a password when double clicked at the starting and end of the text
 [v2]
In-Reply-To: <zz-73SqK7SlO2jnHNxCWunPOE7iHZiZVrN-PkqIMFfg=.18c45065-f8a3-48eb-9ae5-d6dd4a5c02dc@github.com>
References: <zz-73SqK7SlO2jnHNxCWunPOE7iHZiZVrN-PkqIMFfg=.18c45065-f8a3-48eb-9ae5-d6dd4a5c02dc@github.com>
Message-ID: <s3OIzucQgCh3B3WRjrTo8igD3OvZa7hQ8vkjTyEPN-4=.ef1de180-7366-4ff4-8838-f216f306d673@github.com>

> Make sure AquaTextPasswordFieldUI can't use selectWordAction.
> 
> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI, but the AquaTextPasswordFieldUI (and SynthPasswordFieldUI) do NOT extend the BasicPasswordFieldUI, so they weren't inheriting this solution.
> 
> So the problem is partially about multiple inheritance.
> 
> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields.
> 
> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions.

Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:

  8354646: Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25443/files
  - new: https://git.openjdk.org/jdk/pull/25443/files/ccf24d73..bdbd51b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443

PR: https://git.openjdk.org/jdk/pull/25443

From aivanov at openjdk.org  Mon May 26 17:05:26 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 26 May 2025 17:05:26 GMT
Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java
Message-ID: <gh770JpwLKNbDOyw93THX4bMjvhTbgN9VO7l2-jZds8=.c8b9dd45-e498-4b25-bc02-ff4d445703d5@github.com>

The instructions for the `javax/swing/JFileChooser/HTMLFileName.java` test are still not as clear.

The file name in the instructions is rendered as HTML, which, I believe, is unexpected. It should be displayed as the plain text.

The instructions also say about file and directory which have HTML in their name; this was true in the initial version of the test in #24439 that created files and directories on the real file system. 

The final version of test uses a virtual file system that displays *three files*, there's no way to navigate.

I also clarified the instructions: look at how the file name of the first file is rendered in _the file pane_ and _the navigation combo box_ (**Look in** in Metal L&F).

In the `VirtualFileSystemView` class, I changed the name of the third file from `virtualFolder` to `virtualFile2.log`, and made the file array a field which ensures `getRoots` and `getFiles` return the same list.


In addition to this, I reduced the number of rows allocated for the instructions. Since the instructions are in HTML format, the number of lines of HTML code makes no sense for determining the size.

-------------

Commit messages:
 - Improve instructions for HTMLFileName.java

Changes: https://git.openjdk.org/jdk/pull/25455/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25455&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357799
  Stats: 43 lines in 1 file changed: 17 ins; 10 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25455.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25455/head:pull/25455

PR: https://git.openjdk.org/jdk/pull/25455

From prr at openjdk.org  Mon May 26 17:13:51 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 26 May 2025 17:13:51 GMT
Subject: RFR: 8357675: Amend headless message
In-Reply-To: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
References: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
Message-ID: <KpMWzxJaxnC5eGy8c4SN96MwUbPWqIKF5yiYIqyWR6A=.c5dcb6b2-4dce-4635-9bf3-88d533284f82@github.com>

On Mon, 26 May 2025 16:38:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Currently, the default headless message ends with a comma instead of full stop and has an additional line break.
> 
> 
> Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException:
> No X11 DISPLAY variable was set,
> or no headful library support was found,
> but this program performed an operation which requires it,
> 
>         at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:158)
>         at java.desktop/java.awt.Window.<init>(Window.java:518)
>         at java.desktop/java.awt.Frame.<init>(Frame.java:428)
>         at java.desktop/javax.swing.JFrame.<init>(JFrame.java:224) 
> 
> 
> **Fix:**
> 
> Amend the message so that it ends with a full stop and remove the line break.
> 
> 
> Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException:
> No X11 DISPLAY variable was set,
> or no headful library support was found,
> but this program performed an operation which requires it.
>         at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:158)
>         at java.desktop/java.awt.Window.<init>(Window.java:518)
>         at java.desktop/java.awt.Frame.<init>(Frame.java:428)
>         at java.desktop/javax.swing.JFrame.<init>(JFrame.java:224)
> 
> 
> **Testing:**
> 
> Build a headless-only JDK (pass `--enable-headless-only` to the `configure` script) and create a `JFrame`.
> 
> It's impossible to create an automated test for this change, and I don't think a test is required, it's a cosmetic change.

The existing message is fine. The comma is because it isn't done. It introduces the exception text and the blank line adds some clarity. So nothing to change here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25453#issuecomment-2910292746

From aivanov at openjdk.org  Mon May 26 17:18:06 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 26 May 2025 17:18:06 GMT
Subject: RFR: 8357799: Improve instructions for
 JFileChooser/HTMLFileName.java [v2]
In-Reply-To: <gh770JpwLKNbDOyw93THX4bMjvhTbgN9VO7l2-jZds8=.c8b9dd45-e498-4b25-bc02-ff4d445703d5@github.com>
References: <gh770JpwLKNbDOyw93THX4bMjvhTbgN9VO7l2-jZds8=.c8b9dd45-e498-4b25-bc02-ff4d445703d5@github.com>
Message-ID: <IH33ksFeozNTUrlZHv9JPgvl_1fBDLsgShnb1PLHioE=.a2c29c45-94f5-4ebf-9c3d-b40fbd8fe075@github.com>

> The instructions for the `javax/swing/JFileChooser/HTMLFileName.java` test are still not as clear.
> 
> The file name in the instructions is rendered as HTML, which, I believe, is unexpected. It should be displayed as the plain text.
> 
> The instructions also say about file and directory which have HTML in their name; this was true in the initial version of the test in #24439 that created files and directories on the real file system. 
> 
> The final version of test uses a virtual file system that displays *three files*, there's no way to navigate.
> 
> I also clarified the instructions: look at how the file name of the first file is rendered in _the file pane_ and _the navigation combo box_ (**Look in** in Metal L&F).
> 
> In the `VirtualFileSystemView` class, I changed the name of the third file from `virtualFolder` to `virtualFile2.log`, and made the file array a field which ensures `getRoots` and `getFiles` return the same list.
> 
> 
> In addition to this, I reduced the number of rows allocated for the instructions. Since the instructions are in HTML format, the number of lines of HTML code makes no sense for determining the size.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Correct the title of the test frames

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25455/files
  - new: https://git.openjdk.org/jdk/pull/25455/files/d6cebfd0..f0633abd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25455&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25455&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25455.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25455/head:pull/25455

PR: https://git.openjdk.org/jdk/pull/25455

From aivanov at openjdk.org  Mon May 26 17:51:50 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 26 May 2025 17:51:50 GMT
Subject: RFR: 8357675: Amend headless message
In-Reply-To: <KpMWzxJaxnC5eGy8c4SN96MwUbPWqIKF5yiYIqyWR6A=.c5dcb6b2-4dce-4635-9bf3-88d533284f82@github.com>
References: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
 <KpMWzxJaxnC5eGy8c4SN96MwUbPWqIKF5yiYIqyWR6A=.c5dcb6b2-4dce-4635-9bf3-88d533284f82@github.com>
Message-ID: <kDdu8uah9J-ppU1K_ebOaxKr1GbQEnJEjYyiqryvuyM=.43166f34-7473-4abd-a87a-a02a94526976@github.com>

On Mon, 26 May 2025 17:11:03 GMT, Phil Race <prr at openjdk.org> wrote:

> The existing message is fine. The comma is because it isn't done.

How is it not done?

> It introduces the exception text and the blank line adds some clarity. So nothing to change here.

Nothing goes after the comma, the exception message ends here, and the stack trace follows.

The blank line between the message and the stack trace is very uncommon.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25453#issuecomment-2910351416

From prr at openjdk.org  Mon May 26 18:27:49 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 26 May 2025 18:27:49 GMT
Subject: RFR: 8357675: Amend headless message
In-Reply-To: <kDdu8uah9J-ppU1K_ebOaxKr1GbQEnJEjYyiqryvuyM=.43166f34-7473-4abd-a87a-a02a94526976@github.com>
References: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
 <KpMWzxJaxnC5eGy8c4SN96MwUbPWqIKF5yiYIqyWR6A=.c5dcb6b2-4dce-4635-9bf3-88d533284f82@github.com>
 <kDdu8uah9J-ppU1K_ebOaxKr1GbQEnJEjYyiqryvuyM=.43166f34-7473-4abd-a87a-a02a94526976@github.com>
Message-ID: <ITsuPsT9r8hk4JxYPcEEIVEziTYwOtTpv-FPwtr7Sjc=.a6d189c3-20d5-447b-95c6-95484d289ee7@github.com>

On Mon, 26 May 2025 17:49:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > The existing message is fine. The comma is because it isn't done.
> 
> How is it not done?
> 
> > It introduces the exception text and the blank line adds some clarity. So nothing to change here.
> 
> Nothing goes after the comma, the exception message ends here, and the stack trace follows.

stack trace is what I mean by exception text. 
The full text in the bug report reads better with a comma than a full stop.
Is this text ever displayed without the stack trace following ? I can't remember.

> 
> The blank line between the message and the stack trace is very uncommon.

It looks OK to me, but its obviously a matter of preference.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25453#issuecomment-2910406690

From aivanov at openjdk.org  Mon May 26 18:33:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 26 May 2025 18:33:54 GMT
Subject: RFR: 8357675: Amend headless message
In-Reply-To: <ITsuPsT9r8hk4JxYPcEEIVEziTYwOtTpv-FPwtr7Sjc=.a6d189c3-20d5-447b-95c6-95484d289ee7@github.com>
References: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
 <KpMWzxJaxnC5eGy8c4SN96MwUbPWqIKF5yiYIqyWR6A=.c5dcb6b2-4dce-4635-9bf3-88d533284f82@github.com>
 <kDdu8uah9J-ppU1K_ebOaxKr1GbQEnJEjYyiqryvuyM=.43166f34-7473-4abd-a87a-a02a94526976@github.com>
 <ITsuPsT9r8hk4JxYPcEEIVEziTYwOtTpv-FPwtr7Sjc=.a6d189c3-20d5-447b-95c6-95484d289ee7@github.com>
Message-ID: <fVlAsTjyvMKUWO6_O31IsWMn6jZgOrpjM1KjWm51QwQ=.51e8bb93-9f46-4edb-9dab-e02e0ed8c83f@github.com>

On Mon, 26 May 2025 18:25:36 GMT, Phil Race <prr at openjdk.org> wrote:

> > > The existing message is fine. The comma is because it isn't done.
> > 
> > How is it not done?
> > > It introduces the exception text and the blank line adds some clarity. So nothing to change here.
> > 
> > 
> > Nothing goes after the comma, the exception message ends here, and the stack trace follows.
> 
> stack trace is what I mean by exception text.\
> The full text in the bug report reads better with a comma than a full stop. Is this text ever displayed without the stack trace following ? I can't remember.

The message can be extracted by [`Throwable.getMessage()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Throwable.html#getMessage()), then it can be displayed without the stack trace.

The stack trace is optional.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25453#issuecomment-2910416396

From dgredler at openjdk.org  Mon May 26 18:55:31 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 26 May 2025 18:55:31 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377 [v2]
In-Reply-To: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
Message-ID: <60kmeJC9Cx6cT2nhfVlBmHL1S79b8alMeS7WpXIK4MQ=.09712512-e558-4da9-b214-6e29cf8ce177@github.com>

> It looks like this regression actually fits into a longer series of fixes / regressions in this area:
> 
> - [JDK-4517298](https://bugs.openjdk.org/browse/JDK-4517298) fixed metrics for zero-width characters, but broke some ligatures / glyph substitutions
> - [JDK-7017058](https://bugs.openjdk.org/browse/JDK-7017058) fixed the ligatures / glyph substitutions, but broke some zero-width metrics
> - [JDK-8208377](https://bugs.openjdk.org/browse/JDK-8208377) fixed some metrics and rendering for zero-width characters, but broke some ligatures / glyph substitutions
> - Now, with this PR, we aim to fix the ligatures without re-breaking zero-width metrics and display
> 
> We have two different types of use cases pulling `CharToGlyphMapper` in two different directions: the users who need raw, untransformed glyph info, and the users who need normalized / transformed glyph info.
> 
> It looks to me like, in the current code base, the only `CharToGlyphMapper` user which requires raw font data is HarfBuzz (explicitly confirmed with the HarfBuzz team here: https://github.com/harfbuzz/harfbuzz/discussions/5234).
> 
> The regression mechanism at play here is that the HarfBuzz font callbacks are currently providing HarfBuzz with transformed glyph info (e.g. ZWJ -> INVISIBLE_GLYPH_ID), which prevents HarfBuzz from recognizing and applying the correct font GSUB substitutions (which involve ZWJ).
> 
> In order to fix this without (yet again) breaking metrics and display behavior elsewhere, I've added two methods to `CharToGlyphMapper` which provide access to raw glyph info, to be used by the HarfBuzz font callbacks: `charToGlyphRaw(int)` and `charToVariationGlyphRaw(int)`.
> 
> Note two intricacies related to `CompositeGlyphMapper`:
> 1. We need to be careful to only cache raw (untransformed) values, to avoid conflicts between requests for a raw version of a glyph and a transformed version of the same glyph. Another option would have been two separate caches, but I don't think that's necessary.
> 2. Consumers who are using `CompositeGlyphMapper.SLOTMASK` to check glyph slots (e.g. `FontRunIterator` and `CTextPipe`) will "see" invisible glyphs as having come from slot 0. This isn't new, and I think it's OK, but something to be aware of.
> 
> The glyph cache handling in `CCharToGlyphMapper` (for macOS) also requires care to avoid mixing value types.
> 
> Please also note that I'm not sure if the tweak to `sunFont.c` is being tested, since FFM is being used by default for HarfBuzz integration. (Is there a plan to remove...

Daniel Gredler 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 branch 'master' into JDK-8353230
 - Finish macOS implementation
 - Differentiate CharToGlyphMapper users who want raw vs normalized glyph info

-------------

Changes: https://git.openjdk.org/jdk/pull/24412/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24412&range=01
  Stats: 305 lines in 10 files changed: 229 ins; 27 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/24412.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24412/head:pull/24412

PR: https://git.openjdk.org/jdk/pull/24412

From aivanov at openjdk.org  Mon May 26 20:13:50 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 26 May 2025 20:13:50 GMT
Subject: RFR: 8357675: Amend headless message
In-Reply-To: <ITsuPsT9r8hk4JxYPcEEIVEziTYwOtTpv-FPwtr7Sjc=.a6d189c3-20d5-447b-95c6-95484d289ee7@github.com>
References: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
 <KpMWzxJaxnC5eGy8c4SN96MwUbPWqIKF5yiYIqyWR6A=.c5dcb6b2-4dce-4635-9bf3-88d533284f82@github.com>
 <kDdu8uah9J-ppU1K_ebOaxKr1GbQEnJEjYyiqryvuyM=.43166f34-7473-4abd-a87a-a02a94526976@github.com>
 <ITsuPsT9r8hk4JxYPcEEIVEziTYwOtTpv-FPwtr7Sjc=.a6d189c3-20d5-447b-95c6-95484d289ee7@github.com>
Message-ID: <5_1q6Wy_Jd2A8LPetIvKBE-MrUWQYSDNDtFwKRi0u8M=.3e0285d5-b3b3-456a-90ad-978875a9fc2b@github.com>

On Mon, 26 May 2025 18:25:36 GMT, Phil Race <prr at openjdk.org> wrote:

> > The blank line between the message and the stack trace is very uncommon.
> 
> It looks OK to me, but its obviously a matter of preference.

It could be a matter of preference, but it's also a matter of _consistency_, and I can't remember if I've ever seen an exception message which had a line break as its last character.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25453#issuecomment-2910565870

From prr at openjdk.org  Mon May 26 20:28:54 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 26 May 2025 20:28:54 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377 [v2]
In-Reply-To: <60kmeJC9Cx6cT2nhfVlBmHL1S79b8alMeS7WpXIK4MQ=.09712512-e558-4da9-b214-6e29cf8ce177@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
 <60kmeJC9Cx6cT2nhfVlBmHL1S79b8alMeS7WpXIK4MQ=.09712512-e558-4da9-b214-6e29cf8ce177@github.com>
Message-ID: <T3-SccT_p5ujaYN1LGUF5rzf8xq2PgFbKP0kBjYlYKw=.31001716-460d-4a5c-9aab-5c5ba43f5780@github.com>

On Mon, 26 May 2025 18:55:31 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> It looks like this regression actually fits into a longer series of fixes / regressions in this area:
>> 
>> - [JDK-4517298](https://bugs.openjdk.org/browse/JDK-4517298) fixed metrics for zero-width characters, but broke some ligatures / glyph substitutions
>> - [JDK-7017058](https://bugs.openjdk.org/browse/JDK-7017058) fixed the ligatures / glyph substitutions, but broke some zero-width metrics
>> - [JDK-8208377](https://bugs.openjdk.org/browse/JDK-8208377) fixed some metrics and rendering for zero-width characters, but broke some ligatures / glyph substitutions
>> - Now, with this PR, we aim to fix the ligatures without re-breaking zero-width metrics and display
>> 
>> We have two different types of use cases pulling `CharToGlyphMapper` in two different directions: the users who need raw, untransformed glyph info, and the users who need normalized / transformed glyph info.
>> 
>> It looks to me like, in the current code base, the only `CharToGlyphMapper` user which requires raw font data is HarfBuzz (explicitly confirmed with the HarfBuzz team here: https://github.com/harfbuzz/harfbuzz/discussions/5234).
>> 
>> The regression mechanism at play here is that the HarfBuzz font callbacks are currently providing HarfBuzz with transformed glyph info (e.g. ZWJ -> INVISIBLE_GLYPH_ID), which prevents HarfBuzz from recognizing and applying the correct font GSUB substitutions (which involve ZWJ).
>> 
>> In order to fix this without (yet again) breaking metrics and display behavior elsewhere, I've added two methods to `CharToGlyphMapper` which provide access to raw glyph info, to be used by the HarfBuzz font callbacks: `charToGlyphRaw(int)` and `charToVariationGlyphRaw(int)`.
>> 
>> Note two intricacies related to `CompositeGlyphMapper`:
>> 1. We need to be careful to only cache raw (untransformed) values, to avoid conflicts between requests for a raw version of a glyph and a transformed version of the same glyph. Another option would have been two separate caches, but I don't think that's necessary.
>> 2. Consumers who are using `CompositeGlyphMapper.SLOTMASK` to check glyph slots (e.g. `FontRunIterator` and `CTextPipe`) will "see" invisible glyphs as having come from slot 0. This isn't new, and I think it's OK, but something to be aware of.
>> 
>> The glyph cache handling in `CCharToGlyphMapper` (for macOS) also requires care to avoid mixing value types.
>> 
>> Please also note that I'm not sure if the tweak to `sunFont.c` is being tested, since FFM is being used by default for Harf...
>
> Daniel Gredler 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 branch 'master' into JDK-8353230
>  - Finish macOS implementation
>  - Differentiate CharToGlyphMapper users who want raw vs normalized glyph info

Sorry, this one fell off the radar. I see my testing - a long time ago now - passed.
The code changes make sense, so I'm ready to approve. 
But its been so long I think I should re-test with the latest version on the latest repo.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24412#pullrequestreview-2869124733

From prr at openjdk.org  Mon May 26 20:41:51 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 26 May 2025 20:41:51 GMT
Subject: RFR: 8357675: Amend headless message
In-Reply-To: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
References: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
Message-ID: <tP31avN54wBOxHKeOIp9ADFeTBoMMTyIGfeMHX6IFUM=.25f98f14-e576-4a43-9fcf-3e97d5094e28@github.com>

On Mon, 26 May 2025 16:38:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Currently, the default headless message ends with a comma instead of full stop and has an additional line break.
> 
> 
> Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException:
> No X11 DISPLAY variable was set,
> or no headful library support was found,
> but this program performed an operation which requires it,
> 
>         at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:158)
>         at java.desktop/java.awt.Window.<init>(Window.java:518)
>         at java.desktop/java.awt.Frame.<init>(Frame.java:428)
>         at java.desktop/javax.swing.JFrame.<init>(JFrame.java:224) 
> 
> 
> **Fix:**
> 
> Amend the message so that it ends with a full stop and remove the line break.
> 
> 
> Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException:
> No X11 DISPLAY variable was set,
> or no headful library support was found,
> but this program performed an operation which requires it.
>         at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:158)
>         at java.desktop/java.awt.Window.<init>(Window.java:518)
>         at java.desktop/java.awt.Frame.<init>(Frame.java:428)
>         at java.desktop/javax.swing.JFrame.<init>(JFrame.java:224)
> 
> 
> **Testing:**
> 
> Build a headless-only JDK (pass `--enable-headless-only` to the `configure` script) and create a `JFrame`.
> 
> It's impossible to create an automated test for this change, and I don't think a test is required, it's a cosmetic change.

ok

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25453#pullrequestreview-2869136372

From dgredler at openjdk.org  Mon May 26 21:37:51 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 26 May 2025 21:37:51 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377
In-Reply-To: <7qRLx0aLwArI3Md49dSXjXVR_aqNzSfRWCo-59TcyYo=.e75861cf-bd30-4118-ab4b-53e6fe86b8f8@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
 <qAXldHcR9uja7Lnj-LCAkQvYUqcxsbc0LXC7pS6gsmo=.41fd8ffb-bee5-4358-a4ff-b86c7fd6bb5e@github.com>
 <7qRLx0aLwArI3Md49dSXjXVR_aqNzSfRWCo-59TcyYo=.e75861cf-bd30-4118-ab4b-53e6fe86b8f8@github.com>
Message-ID: <W3X0gMzEuD6k9PEqTz9-OBUVCyW1-_qAV0FDWUNBe8s=.e411e2f6-c2d8-4648-a371-e1c3e85889ed@github.com>

On Thu, 24 Apr 2025 03:04:36 GMT, Phil Race <prr at openjdk.org> wrote:

>> We had similar emoji-related regressions at JetBrains. Although our font-related code diverged from OpenJDK a bit, porting this patch seems to resolve them too. I am not an OpenJDK reviewer, but LGTM nevertheless.
>
>> @YaaZ Thanks for the information!
>> 
>> @prrace Have you had a chance to look at this PR?
> 
> It passed all the testing I did. I still need to look hard at the changes.

@prrace Please don't approve yet. I was able to fix the code conflicts caused by PR #23665, but it looks like the logic does not layer nicely as there is now a test failure on macOS after the merge. I'm having a look and will let you know what I find.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24412#issuecomment-2910660492

From prr at openjdk.org  Mon May 26 23:46:51 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 26 May 2025 23:46:51 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377
In-Reply-To: <7qRLx0aLwArI3Md49dSXjXVR_aqNzSfRWCo-59TcyYo=.e75861cf-bd30-4118-ab4b-53e6fe86b8f8@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
 <qAXldHcR9uja7Lnj-LCAkQvYUqcxsbc0LXC7pS6gsmo=.41fd8ffb-bee5-4358-a4ff-b86c7fd6bb5e@github.com>
 <7qRLx0aLwArI3Md49dSXjXVR_aqNzSfRWCo-59TcyYo=.e75861cf-bd30-4118-ab4b-53e6fe86b8f8@github.com>
Message-ID: <o-RfCz8vaxQpRihpmsKQakcsMJTVoxh2tE1sQcM1rYI=.3b80a35f-ed45-4558-a88d-4b6d51ad4ef0@github.com>

On Thu, 24 Apr 2025 03:04:36 GMT, Phil Race <prr at openjdk.org> wrote:

>> We had similar emoji-related regressions at JetBrains. Although our font-related code diverged from OpenJDK a bit, porting this patch seems to resolve them too. I am not an OpenJDK reviewer, but LGTM nevertheless.
>
>> @YaaZ Thanks for the information!
>> 
>> @prrace Have you had a chance to look at this PR?
> 
> It passed all the testing I did. I still need to look hard at the changes.

> @prrace Please don't approve yet. I was able to fix the code conflicts caused by PR #23665, but it looks like the logic does not layer nicely as there is now a test failure on macOS after the merge. I'm having a look and will let you know what I find.

And indeed the tests just finished and a test (not the new one, a previous one : IgnoredWhitespaceTest.java) failed on macOS x64 and ARM ..

java.lang.RuntimeException: for text '\t\t\t\t\tXXXXX' with font java.awt.Font[family=Dialog,name=Dialog,style=plain,size=40]: java.awt.Rectangle[x=300,y=271,width=123,height=28] != java.awt.Rectangle[x=365,y=271,width=123,height=28]
	at IgnoredWhitespaceTest.assertEqual(IgnoredWhitespaceTest.java:127)
	at IgnoredWhitespaceTest.test(IgnoredWhitespaceTest.java:103)
	at IgnoredWhitespaceTest.test(IgnoredWhitespaceTest.java:69)
	at IgnoredWhitespaceTest.main(IgnoredWhitespaceTest.java:49)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1447)

JavaTest Message: Test threw exception: java.lang.RuntimeException: for text '\t\t\t\t\tXXXXX' with font java.awt.Font[family=Dialog,name=Dialog,style=plain,size=40]: java.awt.Rectangle[x=300,y=271,width=123,height=28] != java.awt.Rectangle[x=365,y=271,width=123,height=28]
JavaTest Message: shutting down test

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24412#issuecomment-2910773893

From dgredler at openjdk.org  Tue May 27 00:39:55 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Tue, 27 May 2025 00:39:55 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377 [v2]
In-Reply-To: <60kmeJC9Cx6cT2nhfVlBmHL1S79b8alMeS7WpXIK4MQ=.09712512-e558-4da9-b214-6e29cf8ce177@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
 <60kmeJC9Cx6cT2nhfVlBmHL1S79b8alMeS7WpXIK4MQ=.09712512-e558-4da9-b214-6e29cf8ce177@github.com>
Message-ID: <KM6K-cQxYk_zkdBdLpht6aTuVHCm86VYeO9JXDdu7EE=.b95f7d97-950a-4700-b9e5-24b869d8e44f@github.com>

On Mon, 26 May 2025 18:55:31 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> It looks like this regression actually fits into a longer series of fixes / regressions in this area:
>> 
>> - [JDK-4517298](https://bugs.openjdk.org/browse/JDK-4517298) fixed metrics for zero-width characters, but broke some ligatures / glyph substitutions
>> - [JDK-7017058](https://bugs.openjdk.org/browse/JDK-7017058) fixed the ligatures / glyph substitutions, but broke some zero-width metrics
>> - [JDK-8208377](https://bugs.openjdk.org/browse/JDK-8208377) fixed some metrics and rendering for zero-width characters, but broke some ligatures / glyph substitutions
>> - Now, with this PR, we aim to fix the ligatures without re-breaking zero-width metrics and display
>> 
>> We have two different types of use cases pulling `CharToGlyphMapper` in two different directions: the users who need raw, untransformed glyph info, and the users who need normalized / transformed glyph info.
>> 
>> It looks to me like, in the current code base, the only `CharToGlyphMapper` user which requires raw font data is HarfBuzz (explicitly confirmed with the HarfBuzz team here: https://github.com/harfbuzz/harfbuzz/discussions/5234).
>> 
>> The regression mechanism at play here is that the HarfBuzz font callbacks are currently providing HarfBuzz with transformed glyph info (e.g. ZWJ -> INVISIBLE_GLYPH_ID), which prevents HarfBuzz from recognizing and applying the correct font GSUB substitutions (which involve ZWJ).
>> 
>> In order to fix this without (yet again) breaking metrics and display behavior elsewhere, I've added two methods to `CharToGlyphMapper` which provide access to raw glyph info, to be used by the HarfBuzz font callbacks: `charToGlyphRaw(int)` and `charToVariationGlyphRaw(int)`.
>> 
>> Note two intricacies related to `CompositeGlyphMapper`:
>> 1. We need to be careful to only cache raw (untransformed) values, to avoid conflicts between requests for a raw version of a glyph and a transformed version of the same glyph. Another option would have been two separate caches, but I don't think that's necessary.
>> 2. Consumers who are using `CompositeGlyphMapper.SLOTMASK` to check glyph slots (e.g. `FontRunIterator` and `CTextPipe`) will "see" invisible glyphs as having come from slot 0. This isn't new, and I think it's OK, but something to be aware of.
>> 
>> The glyph cache handling in `CCharToGlyphMapper` (for macOS) also requires care to avoid mixing value types.
>> 
>> Please also note that I'm not sure if the tweak to `sunFont.c` is being tested, since FFM is being used by default for Harf...
>
> Daniel Gredler 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 branch 'master' into JDK-8353230
>  - Finish macOS implementation
>  - Differentiate CharToGlyphMapper users who want raw vs normalized glyph info

Yep, that's the test added in PR #23665 (with which this PR had a conflict).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24412#issuecomment-2910819637

From aturbanov at openjdk.org  Tue May 27 08:13:53 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 27 May 2025 08:13:53 GMT
Subject: RFR: 8354944: Remove unnecessary PartiallyOrderedSet.nodes
In-Reply-To: <11dR4gRM1RWgmx8FloFzy3dfZOwn3zIPjiD0690ZdEw=.2662d35c-e7bf-400f-a224-df53967202eb@github.com>
References: <11dR4gRM1RWgmx8FloFzy3dfZOwn3zIPjiD0690ZdEw=.2662d35c-e7bf-400f-a224-df53967202eb@github.com>
Message-ID: <-wbPMxP9hryZU9vd4Ju420iIdZ9gaUDJ5D8rPQczAwA=.27d50609-74bc-4ca7-bf09-c49769cf7d79@github.com>

On Wed, 16 Apr 2025 20:50:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> We can use `javax.imageio.spi.PartiallyOrderedSet#poNodes` directly

@aivanov-jdk @TejeshR13 can you please review and put the second approve?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24699#issuecomment-2911589976

From shade at openjdk.org  Tue May 27 09:53:57 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 27 May 2025 09:53:57 GMT
Subject: RFR: 8357675: Amend headless message
In-Reply-To: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
References: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
Message-ID: <syTXms_LQw4vWtysLlwJ9m2jNkznnhHasRpUfl5vxJ4=.13ca97d9-190a-4467-9c9c-e7f4e042ab89@github.com>

On Mon, 26 May 2025 16:38:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Currently, the default headless message ends with a comma instead of full stop and has an additional line break.
> 
> 
> Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException:
> No X11 DISPLAY variable was set,
> or no headful library support was found,
> but this program performed an operation which requires it,
> 
>         at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:158)
>         at java.desktop/java.awt.Window.<init>(Window.java:518)
>         at java.desktop/java.awt.Frame.<init>(Frame.java:428)
>         at java.desktop/javax.swing.JFrame.<init>(JFrame.java:224) 
> 
> 
> **Fix:**
> 
> Amend the message so that it ends with a full stop and remove the line break.
> 
> 
> Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException:
> No X11 DISPLAY variable was set,
> or no headful library support was found,
> but this program performed an operation which requires it.
>         at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:158)
>         at java.desktop/java.awt.Window.<init>(Window.java:518)
>         at java.desktop/java.awt.Frame.<init>(Frame.java:428)
>         at java.desktop/javax.swing.JFrame.<init>(JFrame.java:224)
> 
> 
> **Testing:**
> 
> Build a headless-only JDK (pass `--enable-headless-only` to the `configure` script) and create a `JFrame`.
> 
> It's impossible to create an automated test for this change, and I don't think a test is required, it's a cosmetic change.

Looks reasonable. FWIW, the period matches the format for `getDefaultHeadlessMessage()` in other platforms. I would probably even collapse first two lines into one, up to you:


No X11 DISPLAY variable was set, or no headful library support was found,
but this program performed an operation which requires it.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25453#pullrequestreview-2870428082

From aivanov at openjdk.org  Tue May 27 11:02:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 27 May 2025 11:02:58 GMT
Subject: RFR: 8357675: Amend headless message
In-Reply-To: <syTXms_LQw4vWtysLlwJ9m2jNkznnhHasRpUfl5vxJ4=.13ca97d9-190a-4467-9c9c-e7f4e042ab89@github.com>
References: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
 <syTXms_LQw4vWtysLlwJ9m2jNkznnhHasRpUfl5vxJ4=.13ca97d9-190a-4467-9c9c-e7f4e042ab89@github.com>
Message-ID: <j7vK-HDbGhfOKnXm2lDUJC-ZSsxYcg3UR-vPBqUUnSQ=.d4fd4148-371e-437a-bb09-51f1fc75f5ea@github.com>

On Tue, 27 May 2025 09:51:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks reasonable. FWIW, the period matches the format for `getDefaultHeadlessMessage()` in other platforms.

Yes, it does.

> I would probably even collapse first two lines into one, up to you:
> 
> ```
> No X11 DISPLAY variable was set, or no headful library support was found,
> but this program performed an operation which requires it.
> ```

@shipilev That's also a possibility? The message will still fit into 80 columns, however, I think the message is easier to read when the two reasons are on their own lines, so I'll keep it this way unless someone else is also for joining the first two lines.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25453#issuecomment-2912093596

From shade at openjdk.org  Tue May 27 12:03:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 27 May 2025 12:03:53 GMT
Subject: RFR: 8357675: Amend headless message
In-Reply-To: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
References: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
Message-ID: <h3lz3PJClnPCWTB0Bzf2FQoxT-GNos3S7Eqh_rJfN4U=.a34b412c-8b94-452b-b186-23d18fea9369@github.com>

On Mon, 26 May 2025 16:38:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Currently, the default headless message ends with a comma instead of full stop and has an additional line break.
> 
> 
> Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException:
> No X11 DISPLAY variable was set,
> or no headful library support was found,
> but this program performed an operation which requires it,
> 
>         at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:158)
>         at java.desktop/java.awt.Window.<init>(Window.java:518)
>         at java.desktop/java.awt.Frame.<init>(Frame.java:428)
>         at java.desktop/javax.swing.JFrame.<init>(JFrame.java:224) 
> 
> 
> **Fix:**
> 
> Amend the message so that it ends with a full stop and remove the line break.
> 
> 
> Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException:
> No X11 DISPLAY variable was set,
> or no headful library support was found,
> but this program performed an operation which requires it.
>         at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:158)
>         at java.desktop/java.awt.Window.<init>(Window.java:518)
>         at java.desktop/java.awt.Frame.<init>(Frame.java:428)
>         at java.desktop/javax.swing.JFrame.<init>(JFrame.java:224)
> 
> 
> **Testing:**
> 
> Build a headless-only JDK (pass `--enable-headless-only` to the `configure` script) and create a `JFrame`.
> 
> It's impossible to create an automated test for this change, and I don't think a test is required, it's a cosmetic change.

Yeah, that's fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25453#issuecomment-2912251413

From jdv at openjdk.org  Tue May 27 14:21:57 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 27 May 2025 14:21:57 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v6]
In-Reply-To: <io7ydMxQ0hS2b8QqAFfG15cdS8mHUgS_7r9K_bTRCjM=.57de6ddd-621e-479e-b2a8-b687e0d7e322@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
 <io7ydMxQ0hS2b8QqAFfG15cdS8mHUgS_7r9K_bTRCjM=.57de6ddd-621e-479e-b2a8-b687e0d7e322@github.com>
Message-ID: <j24c66IWHzZX-CVnK_8M9tZHjsW4TbJFMpoRYqxM1os=.6f4734ee-9386-46c4-868e-e66e6d5d4ec8@github.com>

On Mon, 26 May 2025 05:29:45 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
>> 
>> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
>> 2. The transparent pixel is non-zero
>> 3. There's more than one such consecutive frame
>> 
>> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.
>> 
>> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
>> 2. [8356137](https://github.com/openjdk/jdk/pull/25044) (this one)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356137: Adding copyright to GifComparison

I think we a need a gif with only 2 frames having transpixel>0 and disposal method save to reproduce this scenario.

Also its better if we can actually create test gif file using ImageIO(There are examples in test/jdk/javax/imageio/plugins/gif/) programatically and use it instead of external GIF files for testing.

> For reference, the commented out lines here are my first approach at resolving this problem.
> <img alt="image" width="687" src="https://private-user-images.githubusercontent.com/7669569/440467227-8caa3372-ee42-412d-959c-6d55d258e4ba.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDgzNTU3OTUsIm5iZiI6MTc0ODM1NTQ5NSwicGF0aCI6Ii83NjY5NTY5LzQ0MDQ2NzIyNy04Y2FhMzM3Mi1lZTQyLTQxMmQtOTU5Yy02ZDU1ZDI1OGU0YmEucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MDUyNyUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTA1MjdUMTQxODE1WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9NGUzNmFkYjg1MjEyOTk4OWMwZWNiMzViOTg3NzY5M2QyMmFjMjNkMGY4YTdhOTJiNzEzOTQzM2UwN2Y0OGU1YSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.p-JV9ycUKEB7RuDArvsHhWTNGWwnCcYOpwZH9UvpyiE">
> 
> This works, and it may be more readable/intuitive than this current PR. When we initialize saved_image we should flood fill it with transparent pixels.
> 
> I chose the approach in this PR though because it's lazier. (That is: it should be a little bit less work, CPU-wise.)
> 
> If anyone wants we can switch to this approach.

I think this is better then current approach of having check multiple times.

src/java.desktop/share/classes/sun/awt/image/GifImageDecoder.java line 419:

> 417:                 // are NOT the transparent pixel: we need to replace it
> 418:                 // with the appropriate transparent pixel.
> 419:                 boolean replaceTransPixelsInSavedImage = save &&

We can move this check to the place where we actually create and initialize saved image.

src/java.desktop/share/classes/sun/awt/image/GifImageDecoder.java line 436:

> 434:                         }
> 435:                         runstart = -1;
> 436:                         if (replaceTransPixelsInSavedImage) {

We are hitting this check for each transparent pixel for all frames with transparent pixel index > 0 and not initial frame until saved_image is not null. In the .gif present in this PR we are checking this condition for each transparent pixel of 2nd and 3rd frame. If GIF contains many frames and disposal method save comes in later part of animation we will hit this check many times.

I think its better to just initialize saved_image with proper transparent pixel index when it is getting created. Then we can completely remove state management of `replaceTransPixelsInSavedImage` and this check.

test/jdk/sun/awt/image/gif/GifComparison.java line 117:

> 115:      *         conditions are met.
> 116:      */
> 117:     public static BufferedImage run(URL srcURL) throws Throwable {

If we can actually update this helper to check a specific frame is GIF and not run throw all the frame its better.
In this PR we just need the info of 4th frame.

Is this way of checking all frames useful in any other PR's which you have raised?

test/jdk/sun/awt/image/gif/GifEmptyBackgroundTest.java line 40:

> 38:         BufferedImage bi = GifComparison.run(srcURL);
> 39: 
> 40:         if (new Color(bi.getRGB(20, 20), true).getAlpha() != 0) {

Without the product fix this test fails while checking opacity of (0,0) itself and we don't hit this check.

`Exception in thread "main" java.lang.Error: pixels at (0, 0) have different opacities: 0 vs ff000000`

-------------

PR Review: https://git.openjdk.org/jdk/pull/25044#pullrequestreview-2871107750
PR Comment: https://git.openjdk.org/jdk/pull/25044#issuecomment-2912699099
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2109208157
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2109288435
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2109298270
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2109318427

From joehw at openjdk.org  Tue May 27 16:27:56 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 27 May 2025 16:27:56 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <L9gE2vcTtRmCj8sVb2Mf80vASRun10hEhdF8OJDXDQs=.f32fe500-e46b-4bab-b73c-b78f80723449@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

java.xml changes look good to me. But as you already asked, the translation team owns most of these files.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25229#pullrequestreview-2871771071

From jlu at openjdk.org  Tue May 27 16:34:52 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 27 May 2025 16:34:52 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <rtLeXcGYPjdVH16A5db5VvNl3AFbcqwVQYzbrrYZrZo=.5bdee26b-cc5f-4834-9cf3-f710cb34c0a0@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <rtLeXcGYPjdVH16A5db5VvNl3AFbcqwVQYzbrrYZrZo=.5bdee26b-cc5f-4834-9cf3-f710cb34c0a0@github.com>
Message-ID: <oD07jz4sbaXmrAQXxWt9B31R7oYM1rYfg30hH9d0-Kc=.f3b6cd24-8e2e-4e77-b9dd-4ea4511b64c5@github.com>

On Mon, 26 May 2025 08:25:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> @justin-curtis-lu Are these files handled by the translation team?

@magicus The ones under java.xml and jdk.jdi are updated by the translation team, I think it'd be best to remove those files from this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2913234396

From naoto at openjdk.org  Tue May 27 16:37:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 16:37:56 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <lt8vg3M1QU-xbe_E0l4n1j9V9sM_0VsM8kOt11Mk1L0=.d6e6845c-ff78-45f2-8f8e-6a40b9e12ba1@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
 <lt8vg3M1QU-xbe_E0l4n1j9V9sM_0VsM8kOt11Mk1L0=.d6e6845c-ff78-45f2-8f8e-6a40b9e12ba1@github.com>
Message-ID: <rUvIFs4xs4inLQJ40ELv5mF0_MjWmQMrZ5VTSmltBnk=.80b73a56-2930-4ce3-ace5-c25766698954@github.com>

On Mon, 26 May 2025 07:44:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/jdk/sun/text/resources/LocaleDataTest.java line 106:
>> 
>>> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
>>> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
>>> 106:  *        LocaleNames/fr_FR/US=?tats-Unis
>> 
>> This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.
>
> ISO-8859-1 does not sound good, and got me worried. But in fact it seems like the file is pure ASCII, and that is fine. 
> 
> However, if the file should ever be changed to include actual ISO-8859-1 encoding, this might break if tools assume it is UTF-8-encoding, since not all ISO-8859-1 encodings are valid UTF-8.

Thanks. Filed an issue to change the encoding in the test to UTF-8: https://bugs.openjdk.org/browse/JDK-8357882

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2109668481

From naoto at openjdk.org  Tue May 27 17:03:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 17:03:53 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <b0f0ldjIu6qI6gHCIZj-QuqZdUZ87_2s2znpk2gkmwY=.8d297170-8ec9-4710-9cea-be3b3fe9db03@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Those TimeZoneNames* resource bundles are in fact leftovers from COMPAT locale provider removal. I am going to remove those files later so you can exclude them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2913310841

From aivanov at openjdk.org  Tue May 27 17:12:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 27 May 2025 17:12:53 GMT
Subject: RFR: 8354944: Remove unnecessary PartiallyOrderedSet.nodes
In-Reply-To: <11dR4gRM1RWgmx8FloFzy3dfZOwn3zIPjiD0690ZdEw=.2662d35c-e7bf-400f-a224-df53967202eb@github.com>
References: <11dR4gRM1RWgmx8FloFzy3dfZOwn3zIPjiD0690ZdEw=.2662d35c-e7bf-400f-a224-df53967202eb@github.com>
Message-ID: <Pd0DCfpuklUmQv7smMRV_aaE_CCC7lj07VwDWtVP4yk=.4b58d7dc-c127-4b0e-8785-6e7b59c837fc@github.com>

On Wed, 16 Apr 2025 20:50:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> We can use `javax.imageio.spi.PartiallyOrderedSet#poNodes` directly

Looks reasonable.

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24699#pullrequestreview-2871902920

From aivanov at openjdk.org  Tue May 27 17:19:07 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 27 May 2025 17:19:07 GMT
Subject: RFR: 8357598: Toolkit.removeAWTEventListener should handle null
 listener in AWTEventListenerProxy
In-Reply-To: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
Message-ID: <_jvr0WzcP-UyJuR_N75_POTFnJNkKaV8gk1r1oI3PkE=.d35f882a-dc77-47a9-b4ec-e8bbd3983f33@github.com>

On Thu, 22 May 2025 21:21:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
> 
> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
> 
> One of the test is updated just to touch that codepath.

Looks good.

I'll submit a test job.

test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java line 171:

> 169:             System.out.println("[Simple test failed!!]");
> 170:             throw new RuntimeException(
> 171:                     "Test failed didn't return " + expected + "-sized array");

Suggestion:

                    "Test didn't return " + expected + "-sized array");

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25401#pullrequestreview-2871915591
PR Review Comment: https://git.openjdk.org/jdk/pull/25401#discussion_r2109746291

From honkar at openjdk.org  Tue May 27 17:23:04 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 27 May 2025 17:23:04 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v3]
In-Reply-To: <7env98PduHPZ06t99_jkG0988p4Ri1pE5O2l-ddORgA=.43c48f8a-4552-45c9-a29f-a28917f3d654@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <NggIVYoDwmwCATsDTNkYXdPC2bQRQv8OcKUBOVra4EU=.3ed921ca-3306-4d8b-bcac-652019da10b2@github.com>
 <pD-HlWCeQoKzOuGTcZKD9QE04mMOqFEc1ZZO7C6cFoE=.45171e4e-2a52-4195-96eb-2e2613e0d44b@github.com>
 <WJoit7XNEHggPxbrJYAfAauHhFbXeq6R7J2pIfnso6g=.07cd8e24-e3d3-4299-9ba1-4f43cbbd69e2@github.com>
 <wN-Mle3RuuyjBapb5MtgzytDsnd7AM-v7XUzdTJBflE=.2760136e-1b4b-4d4d-a0c0-23a8cd89bdc6@github.com>
 <aSABGliIkisyxYU2XDAXez5lItp-d2j2TBGnx6cgXTk=.ad0351e6-e1f9-48af-a685-7c4c9f3516ec@github.com>
 <7env98PduHPZ06t99_jkG0988p4Ri1pE5O2l-ddORgA=.43c48f8a-4552-45c9-a29f-a28917f3d654@github.com>
Message-ID: <XZQBdp0QoJJPICokXYPT9PTxUGYozeik_CB1GfmxgOM=.af308d81-ab10-4ffd-bbe3-736b8f2486ba@github.com>

On Thu, 23 Jan 2025 01:00:00 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Interesting. Does this also happen after the fix with Robot clamping coordinates in shared code?
>
> @alisenchung 
> 
>> I also tested windows and found different behavior from what Harshitha found - robot.mouseMove was already clamping on my primary screen, would not move to the second monitor, and did not throw any NPEs.
> 
> Tested it on windows again on different scales and found a possible rounding error that might be the cause for NPE on windows. [Corner case]
> 
> To save time you can run the test with multiple `@run` and different uiScales and do not have to change it manually in settings.
> 
> 
>  * @run main/othervm -Dsun.java2d.uiScale=1    MouseMoveOffScreen
>  * @run main/othervm -Dsun.java2d.uiScale=1.25 MouseMoveOffScreen
>  * @run main/othervm -Dsun.java2d.uiScale=1.75 MouseMoveOffScreen
>  * @run main/othervm -Dsun.java2d.uiScale=2    MouseMoveOffScreen
>  * @run main/othervm -Dsun.java2d.uiScale=1.5  MouseMoveOffScreen
> 
> 
> Following are the logs. 
> Observe the width of the primary screen and the point returned from fillPointWithCoords() in getPointerInfo().
> 
> uiScale: 1 - Passes
> Win32GraphicsDevice[screen=0]:java.awt.Rectangle[x=-1920,y=363,width=1920,height=1080]
> Win32GraphicsDevice[screen=1]:java.awt.Rectangle[x=0,y=0,**width=3440**,height=1440]
> Point: java.awt.Point[**x=3439**,y=200] 
> 
> uiScale: 1.25 - Passes
> Win32GraphicsDevice[screen=0]:java.awt.Rectangle[x=-1920,y=363,width=1536,height=864]
> Win32GraphicsDevice[screen=1]:java.awt.Rectangle[x=0,y=0,**width=2752**,height=1152]
> Point: java.awt.Point[**x=2751**,y=200]
> 
> **uiScale: 1.5 - Fails**
> Win32GraphicsDevice[screen=0]:java.awt.Rectangle[x=-1920,y=363,width=1280,height=720]
> Win32GraphicsDevice[screen=1]:java.awt.Rectangle[x=0,y=0,**width=2293**,height=960]
> Point: java.awt.Point[**x=2293**,y=200] =>  **Since x coordinate = width, bounds.contains(point) returns false for point on the edge/bounds of the screen.**
> 
> uiScale: 1.75 - Passes
> Win32GraphicsDevice[screen=0]:java.awt.Rectangle[x=-1920,y=363,width=1097,height=617]
> Win32GraphicsDevice[screen=1]:java.awt.Rectangle[x=0,y=0,width=1966,height=823]
> Point: java.awt.Point[x=0,y=200] => clamps to zero once coordinates are past the width of the screen.
> 
> We probably need to look into `fillPointWithCoords()`  too and check if is implemented differently on different platforms.

MouseMoveOffScreen.java still fails on windows on uiScale =1.5, 2.5 for reasons mentioned above.

Since the fix is macOS specific:
To handle this corner case either the test can be made macOS specific OR another way is to set uiScale=1 and run on all platforms. Maybe we can see what other reviewers suggest.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r2109750018

From honkar at openjdk.org  Tue May 27 17:23:03 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 27 May 2025 17:23:03 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v13]
In-Reply-To: <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
Message-ID: <oEP9q4DfdDBpZ4wlsPWnNZ-uFIi63QvaR147HoGq_Uw=.41dd3f45-1550-43c3-a020-9598326e2f40@github.com>

On Wed, 30 Apr 2025 21:13:12 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Currently on macOS when mouseMove is given an offscreen coordinate to move the mouse to, mouseMove will physically clamp to the edge of the screen, but if you try to grab the mouse location immediately after by using MouseInfo.getPointerInfo().getLocation() you will get the value of the offscreen point.
>> 
>> Windows and linux do this clamping and coordinate handling for us, but new distributions may not necessarily handle clamping the same way, so Robot should be checking for clamping rather than delegating it to native.
>> 
>> This fix updates shared code to cache the screen bounds and adds a check to not exceed the bounds in mouseMove. The caching is done in the Robot constructor, so if the screen bounds changes the constructor must be called again to update to the new bounds.
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8345538
>  - move clamping code into macos
>  - use absolute distance to choose correct screen for offscreen clamping
>  - helper function
>  - grab screen data on mouseMove
>  - fix bounds
>  - peer.mouseMove
>  - fix implementation
>  - robot update
>  - Revert "robot multimonitor fix"
>    
>    This reverts commit 5734165881a66dc48d5a9f19e02bf63fac57cdc9.
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8b16897b...e0a5c872

Changes requested by honkar (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22781#pullrequestreview-2871921531

From honkar at openjdk.org  Tue May 27 17:31:05 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 27 May 2025 17:31:05 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v13]
In-Reply-To: <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
Message-ID: <CNvSa3dx4RSnZDQeUCySBoJRPSHsNQ2fcRylZsrw4uk=.7132792f-63a6-49e1-8a6a-ee2d318e738b@github.com>

On Wed, 30 Apr 2025 21:13:12 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Currently on macOS when mouseMove is given an offscreen coordinate to move the mouse to, mouseMove will physically clamp to the edge of the screen, but if you try to grab the mouse location immediately after by using MouseInfo.getPointerInfo().getLocation() you will get the value of the offscreen point.
>> 
>> Windows and linux do this clamping and coordinate handling for us, but new distributions may not necessarily handle clamping the same way, so Robot should be checking for clamping rather than delegating it to native.
>> 
>> This fix updates shared code to cache the screen bounds and adds a check to not exceed the bounds in mouseMove. The caching is done in the Robot constructor, so if the screen bounds changes the constructor must be called again to update to the new bounds.
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8345538
>  - move clamping code into macos
>  - use absolute distance to choose correct screen for offscreen clamping
>  - helper function
>  - grab screen data on mouseMove
>  - fix bounds
>  - peer.mouseMove
>  - fix implementation
>  - robot update
>  - Revert "robot multimonitor fix"
>    
>    This reverts commit 5734165881a66dc48d5a9f19e02bf63fac57cdc9.
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8b16897b...e0a5c872

test/jdk/java/awt/Robot/MouseMoveOffScreen.java line 52:

> 50:         for (int i = 0; i < gs.length; i++) {
> 51:             r[i] = gs[i].getDefaultConfiguration().getBounds();
> 52:         }

@alisenchung 
I would suggest logging screen bounds (provides better debug info for anyone running the test)

Suggestion:

        for (int i = 0; i < gs.length; i++) {
            r[i] = gs[i].getDefaultConfiguration().getBounds();
            System.out.println("Screen: "+ gs[i].getIDstring() + "  Bounds: " + r[i]);
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r2109774604

From achung at openjdk.org  Tue May 27 17:31:05 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 27 May 2025 17:31:05 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v13]
In-Reply-To: <G5jb5umVFs0_AwPP-cDyMVVM5YKfN86Yg1yqkS_hM1E=.832abde9-4671-4232-8484-f03a7117878f@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <9AGmijUihfKByG0s85OTZWydgd_Njke32gzQ4CgYI_g=.343e3960-d0c5-419a-9baa-2e031da66665@github.com>
 <G5jb5umVFs0_AwPP-cDyMVVM5YKfN86Yg1yqkS_hM1E=.832abde9-4671-4232-8484-f03a7117878f@github.com>
Message-ID: <uEf29Uz4gtnB3uKTlbzSVRcAfderOKfeNR_zAQTXark=.fada9985-6c84-4cff-98c7-38c1eecb431b@github.com>

On Fri, 23 May 2025 00:24:17 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8345538
>>  - move clamping code into macos
>>  - use absolute distance to choose correct screen for offscreen clamping
>>  - helper function
>>  - grab screen data on mouseMove
>>  - fix bounds
>>  - peer.mouseMove
>>  - fix implementation
>>  - robot update
>>  - Revert "robot multimonitor fix"
>>    
>>    This reverts commit 5734165881a66dc48d5a9f19e02bf63fac57cdc9.
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8b16897b...e0a5c872
>
> test/jdk/java/awt/Robot/MouseMoveOffScreen.java line 80:
> 
>> 78:         }
>> 79:         return p;
>> 80:     }
> 
> I believe validateOffScreen() was added to prevent edge or boundary case rounding error as observed here - https://github.com/openjdk/jdk/pull/22781/files#r1926210713

This check was added to ensure that the offscreen point chosen was indeed offscreen. https://github.com/openjdk/jdk/pull/22781#discussion_r1929111847

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r2109775306

From duke at openjdk.org  Tue May 27 17:32:22 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Tue, 27 May 2025 17:32:22 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v7]
In-Reply-To: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
Message-ID: <WL5C8GMjy4_rzyVJ9bxWPHy_a3pJVJ4QnVFt74VJbQo=.3aa7c119-62e9-475e-aaec-064b145d0935@github.com>

> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
> 
> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
> 2. The transparent pixel is non-zero
> 3. There's more than one such consecutive frame
> 
> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.
> 
> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
> 
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
> 2. [8356137](https://github.com/openjdk/jdk/pull/25044) (this one)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)

Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:

 - 8356137: remove the redundant transparency check
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#discussion_r2109318427
 - 8356137: flood fill saved_image at initialization
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#issuecomment-2912699099

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25044/files
  - new: https://git.openjdk.org/jdk/pull/25044/files/19804549..62c2bf0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=05-06

  Stats: 20 lines in 2 files changed: 4 ins; 16 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25044/head:pull/25044

PR: https://git.openjdk.org/jdk/pull/25044

From duke at openjdk.org  Tue May 27 17:32:23 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Tue, 27 May 2025 17:32:23 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v6]
In-Reply-To: <j24c66IWHzZX-CVnK_8M9tZHjsW4TbJFMpoRYqxM1os=.6f4734ee-9386-46c4-868e-e66e6d5d4ec8@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
 <io7ydMxQ0hS2b8QqAFfG15cdS8mHUgS_7r9K_bTRCjM=.57de6ddd-621e-479e-b2a8-b687e0d7e322@github.com>
 <j24c66IWHzZX-CVnK_8M9tZHjsW4TbJFMpoRYqxM1os=.6f4734ee-9386-46c4-868e-e66e6d5d4ec8@github.com>
Message-ID: <2PRW76xBqSJF6YSpfP3A-NdD8W16S8ucJMwKY1vTFGc=.36f686f7-c4fa-4d92-baaa-e25a5d139258@github.com>

On Tue, 27 May 2025 14:19:23 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> I think this is better then current approach of having check multiple times.

OK. I switched back to this approach.

(The downside being: now we'll invoke Arrays.fill(..) for *all* gifs with that disposal method. I assume (?) gifs with this architecture/problem are a small subset of that group; but it's impossible to quantify that hunch.)

> test/jdk/sun/awt/image/gif/GifEmptyBackgroundTest.java line 40:
> 
>> 38:         BufferedImage bi = GifComparison.run(srcURL);
>> 39: 
>> 40:         if (new Color(bi.getRGB(20, 20), true).getAlpha() != 0) {
> 
> Without the product fix this test fails while checking opacity of (0,0) itself and we don't hit this check.
> 
> `Exception in thread "main" java.lang.Error: pixels at (0, 0) have different opacities: 0 vs ff000000`

OK, this is removed.

That was a redundant check intended to:
A. Reinforce what inspired this test
B. Double-check that ImageIO also did the right thing. (That is: the new GifComparison makes sure ImageIO and ToolkitImage are identical. But if they happened to *both* be wrong then GifComparison would be satisfied, so this confirmed the test gif file really was parsed correctly.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25044#issuecomment-2913381669
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2109776140

From achung at openjdk.org  Tue May 27 17:35:17 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 27 May 2025 17:35:17 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v14]
In-Reply-To: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
Message-ID: <-wufduQaG7bNR6MZksflsgCitkejQfKDFxXKNhB-2bQ=.998703db-0369-4d4c-98fc-1036e0479ed8@github.com>

> Currently on macOS when mouseMove is given an offscreen coordinate to move the mouse to, mouseMove will physically clamp to the edge of the screen, but if you try to grab the mouse location immediately after by using MouseInfo.getPointerInfo().getLocation() you will get the value of the offscreen point.
> 
> Windows and linux do this clamping and coordinate handling for us, but new distributions may not necessarily handle clamping the same way, so Robot should be checking for clamping rather than delegating it to native.
> 
> This fix updates shared code to cache the screen bounds and adds a check to not exceed the bounds in mouseMove. The caching is done in the Robot constructor, so if the screen bounds changes the constructor must be called again to update to the new bounds.

Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:

 - add logging to test
 - test require macos, spacing in crobot

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22781/files
  - new: https://git.openjdk.org/jdk/pull/22781/files/e0a5c872..01a31976

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=12-13

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22781.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22781/head:pull/22781

PR: https://git.openjdk.org/jdk/pull/22781

From serb at openjdk.org  Tue May 27 17:38:32 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 27 May 2025 17:38:32 GMT
Subject: RFR: 8357598: Toolkit.removeAWTEventListener should handle null
 listener in AWTEventListenerProxy [v2]
In-Reply-To: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
Message-ID: <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>

> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
> 
> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
> 
> One of the test is updated just to touch that codepath.

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25401/files
  - new: https://git.openjdk.org/jdk/pull/25401/files/36560145..afb10b6d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25401&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25401&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25401/head:pull/25401

PR: https://git.openjdk.org/jdk/pull/25401

From abhiscxk at openjdk.org  Tue May 27 17:58:31 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 27 May 2025 17:58:31 GMT
Subject: RFR: 8341311: [Accessibility,macOS,VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu
Message-ID: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>

VoiceOver announce incorrect number of child for a submenu of JPopupMenu when it is visible for the first time only. After that VO is able to announce the number of items correctly.

Issue: Problem is with the a11y subsystem method call to get the accessible children details.

Analysis: When the Submenu of a JPopupMenu is opened, accessible component of PopupMenu is created dynamically in the native side implementation and `PostMenuOpened` notification is sent to the a11y subsystem for the newly created PopupMenu. Once the notification is sent to a11y sub-system, it invokes the `accessibilityChildren` method to get the children details for the menu component. A11y subsystem always retrieve the information of the root level PopupMenu irrespective of the submenu's PopupMenu (PopupMenu is associated with each JMenu) and thus announce the root level PopupMenu child count which is incorrect.

Proposed Fix: Proposed fix is to ensure the correct child details are sent back to a11y sub-system for correct announcement. So, whenever the `accessibilityChildren` method is invoked, first try to find out the current accessible PopupMenu which is opened for the Submenu and then return the child details.

Testing : Manual test case is attached to verify the fix and there is no failure with fix in CI pipeline.

`Current fix also ensures the correct child counts are announced for the JMenu's Submenu which are present in the JMenubar.`

**Note :** While verifying the fix, a new issue is unearthed for multi-level submenu where VO is failed to announce the Submenu's text. Since the issue exists without the proposed fix too, it shall be treated as a new bug finding and will raise a separate JBS issue.

-------------

Commit messages:
 - Popupmenu child count fix

Changes: https://git.openjdk.org/jdk/pull/25470/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25470&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341311
  Stats: 178 lines in 3 files changed: 176 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25470/head:pull/25470

PR: https://git.openjdk.org/jdk/pull/25470

From abhiscxk at openjdk.org  Tue May 27 17:58:31 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 27 May 2025 17:58:31 GMT
Subject: RFR: 8341311: [Accessibility, macOS,
 VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu
In-Reply-To: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
Message-ID: <nDp4rEZ1AgkRlgK7GWTVB-_9IkY5rgMoe8wPrB2fVk0=.9bb9c683-ccd1-4ab8-9e11-50c7f5212aec@github.com>

On Tue, 27 May 2025 17:01:16 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> VoiceOver announce incorrect number of child for a submenu of JPopupMenu when it is visible for the first time only. After that VO is able to announce the number of items correctly.
> 
> Issue: Problem is with the a11y subsystem method call to get the accessible children details.
> 
> Analysis: When the Submenu of a JPopupMenu is opened, accessible component of PopupMenu is created dynamically in the native side implementation and `PostMenuOpened` notification is sent to the a11y subsystem for the newly created PopupMenu. Once the notification is sent to a11y sub-system, it invokes the `accessibilityChildren` method to get the children details for the menu component. A11y subsystem always retrieve the information of the root level PopupMenu irrespective of the submenu's PopupMenu (PopupMenu is associated with each JMenu) and thus announce the root level PopupMenu child count which is incorrect.
> 
> Proposed Fix: Proposed fix is to ensure the correct child details are sent back to a11y sub-system for correct announcement. So, whenever the `accessibilityChildren` method is invoked, first try to find out the current accessible PopupMenu which is opened for the Submenu and then return the child details.
> 
> Testing : Manual test case is attached to verify the fix and there is no failure with fix in CI pipeline.
> 
> `Current fix also ensures the correct child counts are announced for the JMenu's Submenu which are present in the JMenubar.`
> 
> **Note :** While verifying the fix, a new issue is unearthed for multi-level submenu where VO is failed to announce the Submenu's text. Since the issue exists without the proposed fix too, it shall be treated as a new bug finding and will raise a separate JBS issue.

@azuev-java Please review the proposed fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25470#issuecomment-2913335444

From duke at openjdk.org  Tue May 27 18:21:40 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Tue, 27 May 2025 18:21:40 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v8]
In-Reply-To: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
Message-ID: <eVxgo9YhNa7jjnEuWH2Fb3QOrx3pLhQE14St2XTo4X4=.c177e69b-a4ec-4c9b-9e96-39c61b3627bb@github.com>

> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
> 
> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
> 2. The transparent pixel is non-zero
> 3. There's more than one such consecutive frame
> 
> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.
> 
> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
> 
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
> 2. [8356137](https://github.com/openjdk/jdk/pull/25044) (this one)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)

Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:

 - 8356137: trivial javadoc update
 - 8356137: only inspect last frame of gif
   
   This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.)
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25044/files
  - new: https://git.openjdk.org/jdk/pull/25044/files/62c2bf0d..e0546b1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=06-07

  Stats: 92 lines in 1 file changed: 0 ins; 53 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/25044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25044/head:pull/25044

PR: https://git.openjdk.org/jdk/pull/25044

From duke at openjdk.org  Tue May 27 18:21:41 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Tue, 27 May 2025 18:21:41 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v6]
In-Reply-To: <j24c66IWHzZX-CVnK_8M9tZHjsW4TbJFMpoRYqxM1os=.6f4734ee-9386-46c4-868e-e66e6d5d4ec8@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
 <io7ydMxQ0hS2b8QqAFfG15cdS8mHUgS_7r9K_bTRCjM=.57de6ddd-621e-479e-b2a8-b687e0d7e322@github.com>
 <j24c66IWHzZX-CVnK_8M9tZHjsW4TbJFMpoRYqxM1os=.6f4734ee-9386-46c4-868e-e66e6d5d4ec8@github.com>
Message-ID: <9J0uONYi0i2h5am63nTXe-uFszJsi0jzstPvzRJ5Ngg=.22c64492-71e7-4a35-9455-62698f78752e@github.com>

On Tue, 27 May 2025 13:32:33 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356137: Adding copyright to GifComparison
>
> src/java.desktop/share/classes/sun/awt/image/GifImageDecoder.java line 419:
> 
>> 417:                 // are NOT the transparent pixel: we need to replace it
>> 418:                 // with the appropriate transparent pixel.
>> 419:                 boolean replaceTransPixelsInSavedImage = save &&
> 
> We can move this check to the place where we actually create and initialize saved image.

I think this thread is moot having addressed https://github.com/openjdk/jdk/pull/25044#issuecomment-2912699099 .

> src/java.desktop/share/classes/sun/awt/image/GifImageDecoder.java line 436:
> 
>> 434:                         }
>> 435:                         runstart = -1;
>> 436:                         if (replaceTransPixelsInSavedImage) {
> 
> We are hitting this check for each transparent pixel for all frames with transparent pixel index > 0 and not initial frame until saved_image is not null. In the .gif present in this PR we are checking this condition for each transparent pixel of 2nd and 3rd frame. If GIF contains many frames and disposal method save comes in later part of animation we will hit this check many times.
> 
> I think its better to just initialize saved_image with proper transparent pixel index when it is getting created. Then we can completely remove state management of `replaceTransPixelsInSavedImage` and this check.

OK; I think this thread is moot having addressed https://github.com/openjdk/jdk/pull/25044#issuecomment-2912699099 .

> Is this way of checking all frames useful in any other PR's which you have raised?

No, I don't think so. (I liked the assurance that every frame was identical, but technically that is beyond the scope of each individual unit test.)

I changed this method to only inspect the last frame.

This made the GifComparison's main() class much less useful, so I removed it. So now the GifComparison class is more limited in scope to unit tests -- and it's no longer a generic tool to identify new problems.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2109860678
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2109860766
PR Review Comment: https://git.openjdk.org/jdk/pull/25044#discussion_r2109856464

From azvegint at openjdk.org  Tue May 27 18:23:01 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 27 May 2025 18:23:01 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v12]
In-Reply-To: <-76yVSjHyZOGJGVcySdiBScPH6Si-zEztJ1rMNhG_OE=.5809f733-8a59-49d4-bf38-b7b7041ce9e3@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <0645YLoDLjcLbjQxBs3QFCFVvenQjAeJlZANZ0hay_8=.e50b8551-4a2f-4cc5-b910-5f5544beb1f7@github.com>
 <DI66Dw96G2BdXyunw_IR6MSicF3qYOLqB_sR-eAkxfk=.c38e46e3-7b8b-479a-a665-7457623ebe71@github.com>
 <aH2OGm0MehkfeSmjxPlrXi6S7WSW7QVjvjTYVhK7RB0=.59766878-c0be-453a-9b02-c0ad2f48c1c6@github.com>
 <-76yVSjHyZOGJGVcySdiBScPH6Si-zEztJ1rMNhG_OE=.5809f733-8a59-49d4-bf38-b7b7041ce9e3@github.com>
Message-ID: <lwA-9X7rN1YuAbDu_4eK-3S4cvOE-V6sDNc41wUNobo=.d0bce611-86a3-44e9-a42a-b9e52ccc024d@github.com>

On Fri, 23 May 2025 11:44:13 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>>> FYI, one of the JCK introspector tests fails because of this change. The test is quite complicated, so I am not able to provide a simple reproducer right away. But I'll post it later.
>> 
>> Indeed, there are some failures of JCK Introspector tests.
>
> I restored the original order processing, now seems OK for me locally.
> Could you review, please?

Everything seems to be fine now. Thank you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r2109864011

From azvegint at openjdk.org  Tue May 27 18:23:00 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 27 May 2025 18:23:00 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v13]
In-Reply-To: <ZBP2gR52LbACfOwuS7dhQhEzKIKrRQjynqVp4tPFp9Q=.fe7b9661-4d6f-4dc4-a85c-a18738a74eb2@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <ZBP2gR52LbACfOwuS7dhQhEzKIKrRQjynqVp4tPFp9Q=.fe7b9661-4d6f-4dc4-a85c-a18738a74eb2@github.com>
Message-ID: <2HBylkhP8syMAMr_zclzuwNzlD7YPlPp137fSQXJ_Pw=.e5391b4b-d3f9-4d8f-ae78-11a88ca2176b@github.com>

On Fri, 23 May 2025 11:48:38 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
>> 
>> ---------
>> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default and static methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses.
>> 
>> When a subclass "overrides" a static method from a parent class `getMethodDescriptors()` behaves as follows:
>> 
>> - In case of a clash with a class method, the class version will take precedence rather than interface's one. 
>> - If the same method appears in multiple classes/interfaces within the same hierarchy, the version from the most specific sub-interface will be selected.
>> - If the method appears in classes/interfaces from different hierarchies, the result is undefined, either version can be returned.
>> 
>> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
>> 
>> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
>> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
>> * Gettters/setters declared and not implemented are not considered.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restored the original order processing

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23443#pullrequestreview-2872097632

From serb at openjdk.org  Tue May 27 18:27:00 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 27 May 2025 18:27:00 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v10]
In-Reply-To: <lSJejgcB_mZzWCbMR0fZfb-5n49Njlu3A9dztyfDO-s=.7967740d-1e43-47e1-8a5d-3bab8786bb9a@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <lSJejgcB_mZzWCbMR0fZfb-5n49Njlu3A9dztyfDO-s=.7967740d-1e43-47e1-8a5d-3bab8786bb9a@github.com>
Message-ID: <9Oco8sXX2wF_26udEZoISllR58JH5Qs1m22_UDdXK78=.465a992c-4304-4f23-944e-ca67203393d3@github.com>

On Sun, 25 May 2025 17:06:49 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

Is it possible to cover the latest change(for the hang) by the test?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2913523700

From serb at openjdk.org  Tue May 27 18:31:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 27 May 2025 18:31:55 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <frXGWTXYtH-H1BhL_FptSkfRX-wMgEWQhv6rbZg5zAo=.aadb952d-ebbd-47ef-ba61-f56ad9e7e2fd@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
 <W-JTwAa8hkC2Y-QuqFNehMbY6pbjzY6whOXhHSH549A=.c1c8ba4b-4651-47d2-9148-6d4613703b72@github.com>
 <frXGWTXYtH-H1BhL_FptSkfRX-wMgEWQhv6rbZg5zAo=.aadb952d-ebbd-47ef-ba61-f56ad9e7e2fd@github.com>
Message-ID: <rmSHoWetlonSXoP6V8sburEHr777b8Dgiydvn_XzbqI=.02733e77-8730-47a4-98ea-8c8046552f7b@github.com>

On Mon, 14 Apr 2025 13:28:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I ran this changes through CI testing, and the results are good.
>
>> I do not have any other comments, @aivanov-jdk please take a look.
>> 
>> @aivanov-jdk ?\
>> Could you review the PR, please?
> 
> I'm currently busy, I'll get to look at this PR as soon as I can.
> 
> Does it make sense to expand tests to cover cases that @mrserb brought up? With module system and exported vs non-exported classes and interfaces?

> Could you review, please? @aivanov-jdk @mrserb @azvegint

Please update the test to cover the latest change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2913536248

From myankelevich at openjdk.org  Tue May 27 18:59:56 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 27 May 2025 18:59:56 GMT
Subject: RFR: 8341311: [Accessibility, macOS,
 VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu
In-Reply-To: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
Message-ID: <_sXctfl4hH0eURjW3o_R0DLJp03F6VPioRzxcJ93xRQ=.263c5f31-f5ed-4975-865f-11721a0bdc1a@github.com>

On Tue, 27 May 2025 17:01:16 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> VoiceOver announce incorrect number of child for a submenu of JPopupMenu when it is visible for the first time only. After that VO is able to announce the number of items correctly.
> 
> Issue: Problem is with the a11y subsystem method call to get the accessible children details.
> 
> Analysis: When the Submenu of a JPopupMenu is opened, accessible component of PopupMenu is created dynamically in the native side implementation and `PostMenuOpened` notification is sent to the a11y subsystem for the newly created PopupMenu. Once the notification is sent to a11y sub-system, it invokes the `accessibilityChildren` method to get the children details for the menu component. A11y subsystem always retrieve the information of the root level PopupMenu irrespective of the submenu's PopupMenu (PopupMenu is associated with each JMenu) and thus announce the root level PopupMenu child count which is incorrect.
> 
> Proposed Fix: Proposed fix is to ensure the correct child details are sent back to a11y sub-system for correct announcement. So, whenever the `accessibilityChildren` method is invoked, first try to find out the current accessible PopupMenu which is opened for the Submenu and then return the child details.
> 
> Testing : Manual test case is attached to verify the fix and there is no failure with fix in CI pipeline.
> 
> `Current fix also ensures the correct child counts are announced for the JMenu's Submenu which are present in the JMenubar.`
> 
> **Note :** While verifying the fix, a new issue is unearthed for multi-level submenu where VO is failed to announce the Submenu's text. Since the issue exists without the proposed fix too, it shall be treated as a new bug finding and will raise a separate JBS issue.

test/jdk/javax/accessibility/TestPopupMenuChildCount.java line 42:

> 40:  */
> 41: 
> 42: public class TestPopupMenuChildCount {

Nitpick: as far as I understand, this is for macOS only. Do you think it would make more sense to have a name mention that the test is Mac only? The same for test description. Seems to me a bit confusing otherwise 

It's fine with me if you leave it as it is though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25470#discussion_r2109947825

From honkar at openjdk.org  Tue May 27 19:03:00 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 27 May 2025 19:03:00 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v14]
In-Reply-To: <-wufduQaG7bNR6MZksflsgCitkejQfKDFxXKNhB-2bQ=.998703db-0369-4d4c-98fc-1036e0479ed8@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <-wufduQaG7bNR6MZksflsgCitkejQfKDFxXKNhB-2bQ=.998703db-0369-4d4c-98fc-1036e0479ed8@github.com>
Message-ID: <_MbhPx0hjMYzsivvzGyhbsufrngTpK3cikZzS6CWfM8=.36f30463-35da-46b3-a29c-26cf820e0f6e@github.com>

On Tue, 27 May 2025 17:35:17 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Currently on macOS when mouseMove is given an offscreen coordinate to move the mouse to, mouseMove will physically clamp to the edge of the screen, but if you try to grab the mouse location immediately after by using MouseInfo.getPointerInfo().getLocation() you will get the value of the offscreen point.
>> 
>> Windows and linux do this clamping and coordinate handling for us, but new distributions may not necessarily handle clamping the same way, so Robot should be checking for clamping rather than delegating it to native.
>> 
>> This fix updates shared code to cache the screen bounds and adds a check to not exceed the bounds in mouseMove. The caching is done in the Robot constructor, so if the screen bounds changes the constructor must be called again to update to the new bounds.
>
> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add logging to test
>  - test require macos, spacing in crobot

Latest changes LGTM on macOS (single and dual-monitor setup). Please ensure to sync mainline and run CI for sanity check.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CRobot.java line 85:

> 83:             int currXDiff = Math.abs(x - cP.x);
> 84:             int currYDiff = Math.abs(y - cP.y);
> 85:             int currDiff = (int) Math.round(Math.hypot(currXDiff, currYDiff));

Since `Math.hypot(currXDiff, currYDiff)`  translates to `sqrt(currXDiff^2, currYDiff^2)`,  ideally Math.abs in redundant on previous lines. But no harm in keeping it.

Suggestion:

            int currXDiff = x - cP.x;
            int currYDiff = y - cP.y;
            int currDiff = (int) Math.round(Math.hypot(currXDiff, currYDiff));

-------------

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22781#pullrequestreview-2872218256
PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r2109944370

From prr at openjdk.org  Tue May 27 19:04:50 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 27 May 2025 19:04:50 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v11]
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <fsFn6PMDcJ_hT_EH9tpIpolUPdlR-I7UrstRe42TkzA=.74013928-e811-41db-a8a1-697994a98e8b@github.com>

> A simple API to replace java.applet.AudioClip
> 
> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8356049

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24991/files
  - new: https://git.openjdk.org/jdk/pull/24991/files/c92a8ba9..e04dd106

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=09-10

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24991/head:pull/24991

PR: https://git.openjdk.org/jdk/pull/24991

From prr at openjdk.org  Tue May 27 19:04:50 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 27 May 2025 19:04:50 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v10]
In-Reply-To: <9Oco8sXX2wF_26udEZoISllR58JH5Qs1m22_UDdXK78=.465a992c-4304-4f23-944e-ca67203393d3@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <lSJejgcB_mZzWCbMR0fZfb-5n49Njlu3A9dztyfDO-s=.7967740d-1e43-47e1-8a5d-3bab8786bb9a@github.com>
 <9Oco8sXX2wF_26udEZoISllR58JH5Qs1m22_UDdXK78=.465a992c-4304-4f23-944e-ca67203393d3@github.com>
Message-ID: <LefVaWAeoNVS5ywzjxQakFN0zH3fDoJSaR6eeM3N--U=.bdff8200-41de-4487-af2e-430083f5dc0b@github.com>

On Tue, 27 May 2025 18:24:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Is it possible to cover the latest change(for the hang) by the test?

Do you mean show that calling loop() doesn't prevent exit ?
I can just add a call to loop() at the end of the test. If it doesn't terminate the test will fail with a timeout.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2913617031

From aturbanov at openjdk.org  Tue May 27 20:46:03 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 27 May 2025 20:46:03 GMT
Subject: Integrated: 8354944: Remove unnecessary PartiallyOrderedSet.nodes
In-Reply-To: <11dR4gRM1RWgmx8FloFzy3dfZOwn3zIPjiD0690ZdEw=.2662d35c-e7bf-400f-a224-df53967202eb@github.com>
References: <11dR4gRM1RWgmx8FloFzy3dfZOwn3zIPjiD0690ZdEw=.2662d35c-e7bf-400f-a224-df53967202eb@github.com>
Message-ID: <F3wWbXYVeuxJCNBGjiCsHClpuUaohD1_GJJv2fGRqXY=.e99dea42-fff8-40e8-b235-6e43234a0398@github.com>

On Wed, 16 Apr 2025 20:50:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> We can use `javax.imageio.spi.PartiallyOrderedSet#poNodes` directly

This pull request has now been integrated.

Changeset: 11ad1733
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/11ad1733f8db3d8e868383fc9826963b9ffd620f
Stats:     9 lines in 1 file changed: 0 ins; 4 del; 5 mod

8354944: Remove unnecessary PartiallyOrderedSet.nodes

Reviewed-by: serb, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/24699

From prr at openjdk.org  Tue May 27 21:31:22 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 27 May 2025 21:31:22 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v12]
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <a9zN5mOB4qxVfeZ2_O3RCjpNhtSSBKnW6WzDXj54kRo=.af0c2f15-d834-411e-966e-4587d66183e2@github.com>

> A simple API to replace java.applet.AudioClip
> 
> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8356049

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24991/files
  - new: https://git.openjdk.org/jdk/pull/24991/files/e04dd106..9a282d2a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24991/head:pull/24991

PR: https://git.openjdk.org/jdk/pull/24991

From prr at openjdk.org  Tue May 27 22:17:20 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 27 May 2025 22:17:20 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v13]
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <IETwyB9EMggVpw6_0SxU16HzgIZKFxCe0RbvrT_ud_k=.5d13e9e3-2d49-49e8-9cf8-591ca1b31ad7@github.com>

> A simple API to replace java.applet.AudioClip
> 
> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8356049

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24991/files
  - new: https://git.openjdk.org/jdk/pull/24991/files/9a282d2a..58649f22

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24991/head:pull/24991

PR: https://git.openjdk.org/jdk/pull/24991

From serb at openjdk.org  Tue May 27 22:27:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 27 May 2025 22:27:56 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v10]
In-Reply-To: <LefVaWAeoNVS5ywzjxQakFN0zH3fDoJSaR6eeM3N--U=.bdff8200-41de-4487-af2e-430083f5dc0b@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <lSJejgcB_mZzWCbMR0fZfb-5n49Njlu3A9dztyfDO-s=.7967740d-1e43-47e1-8a5d-3bab8786bb9a@github.com>
 <9Oco8sXX2wF_26udEZoISllR58JH5Qs1m22_UDdXK78=.465a992c-4304-4f23-944e-ca67203393d3@github.com>
 <LefVaWAeoNVS5ywzjxQakFN0zH3fDoJSaR6eeM3N--U=.bdff8200-41de-4487-af2e-430083f5dc0b@github.com>
Message-ID: <hl0ZjpPuV7rSw0ljHiSXNQIbFt4FHrv_DHFg5h20g1E=.f332eaff-c4ae-4b3a-a594-7f863db83e40@github.com>

On Tue, 27 May 2025 19:00:18 GMT, Phil Race <prr at openjdk.org> wrote:

> Do you mean show that calling loop() doesn't prevent exit ? I can just add a call to loop() at the end of the test. If it doesn't terminate the test will fail with a timeout.

jtreg terminates all threads and the test vm after the main method completes, so I believe the updated test would pass even before this change (when a non-daemon thread was used).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2914318955

From prr at openjdk.org  Tue May 27 23:13:00 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 27 May 2025 23:13:00 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v24]
In-Reply-To: <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
Message-ID: <8nB0Stxw9Qbs2FRElahZWOK5AVkSpOftlgcKuSFnPsI=.edda5259-7541-421d-a8af-2aa6605ae4bf@github.com>

On Wed, 12 Mar 2025 11:00:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fix

> I checked rbma.cpp output where I think we can only support the 4th item in the list (which is this) ![image](https://private-user-images.githubusercontent.com/43534309/447489844-32067d1a-8ab2-444c-8db3-265f0e64f6ec.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDgzODU5OTgsIm5iZiI6MTc0ODM4NTY5OCwicGF0aCI6Ii80MzUzNDMwOS80NDc0ODk4NDQtMzIwNjdkMWEtOGFiMi00NDRjLThkYjMtMjY1ZjBlNjRmNmVjLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA1MjclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwNTI3VDIyNDEzOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWVmN2Q3MTJmMGNhNWM5YzE4MWI5YjMxNDYwYmQ1MWJiNmJjY2VjMzI4M2I2YTQwNTI5ZDUwYWE4MDNlMzA0N2MmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.IKs2UKVCkF23JhYXnMGG5D78UdFV8o974fA74X6zelk)
> 
> This is because we have [JRadioButtonMenuItem](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/JRadioButtonMenuItem.html#%3Cinit%3E(java.lang.String,javax.swing.Icon,boolean))([String](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/String.html) text, [Icon](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/Icon.html) icon, boolean selected) API which only supports one icon image (so checked/unchecked icon image **in addition** to item icon as below image is not possible in my opinion in Java swing)


Not sure I know what you mean by 4th item, but clearly we aren't going to add an API to supply checked/unchecked images.
But we should support *rendering* like you show above. 
- app supplies icon image and text, WE supply the radio button.
- 
> 
> ![image](https://private-user-images.githubusercontent.com/43534309/447492462-581f4e36-6b55-4a1c-8a5a-465741e43858.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDgzODU5OTgsIm5iZiI6MTc0ODM4NTY5OCwicGF0aCI6Ii80MzUzNDMwOS80NDc0OTI0NjItNTgxZjRlMzYtNmI1NS00YTFjLThhNWEtNDY1NzQxZTQzODU4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA1MjclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwNTI3VDIyNDEzOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTU5ZmFiYmZmYzUyN2NlYTQyMTg2NTZkYjM3YjI5YmU5OTViOTllY2E0YTRkOWFhM2U5ZDhjNGNmZGU5NTNiZjAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.HndjszTSwBDh3V39rS-aoDZI8G6JEsxOAxn95BSpFIA)
> 
> The current state of PR supports this 4th item. 

What is "this 4th item" ?  You mean the case of image + text from app, and WE display a radio button checked ?

Only thing different is when there is no imageicon and menuitem is selected, then the text seems to be in same vertical line as the other items (in native rbma output) ![image](https://private-user-images.githubusercontent.com/43534309/447490318-897f3277-df2e-4827-8381-e51ad8007251.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDgzODU5OTgsIm5iZiI6MTc0ODM4NTY5OCwicGF0aCI6Ii80MzUzNDMwOS80NDc0OTAzMTgtODk3ZjMyNzctZGYyZS00ODI3LTgzODEtZTUxYWQ4MDA3MjUxLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA1MjclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwNTI3VDIyNDEzOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTNhNjM1MTU5OTg1Njc0ZTNlOGI3NmQ1MDU0Y2EzYjUyNzM0ZTQ5ZjI2NmQyYzFmMWM1OTViNjEwZGY2MmExY2QmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.NJqfKGrADw05FVzfOtTbNoHLr8w3WsUNv98kf8GaHaM)
> 
> but current PR the text is shifted to left (when there is no imageicon ie 3rd item in list) and occupies icon space, as below !

If you mean windows always lines up the start of the text, that seems to be true.
So we should do the same.

[image](https://private-user-images.githubusercontent.com/43534309/447504446-43fb1ccc-b475-4147-8131-22f2fc918375.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDgzODU5OTgsIm5iZiI6MTc0ODM4NTY5OCwicGF0aCI6Ii80MzUzNDMwOS80NDc1MDQ0NDYtNDNmYjFjY2MtYjQ3NS00MTQ3LTgxMzEtMjJmMmZjOTE4Mzc1LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA1MjclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwNTI3VDIyNDEzOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTg3NTVkZmM3OWM4NTI1Zjg3ZTI4NTg1MmNlMTc2NDZkYmM4YmQ4MTk4MWFkMDkwYTQyYjMwZDNhNWIyNDQ5NjgmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.vyGdZfku-sAx05JjUijTBsjXg9BWoIjjwUe3x6CMxcM)
> 
> This is because in most cases (and in SwingSet2) the radiomenu items are drawn without imageicon and there is no extra space between radio bullet and menu text

it seems to me that if there's an image in ANY menu item, Windows reserves the space in all items, hence getting the text aligned.
It just does the funky thing of moving where it displays the item image if there's no checked image.

> 
> ![image](https://private-user-images.githubusercontent.com/43534309/447499626-c5cd5840-d58e-4456-8217-cf7f3ba9bb4e.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDgzODU5OTgsIm5iZiI6MTc0ODM4NTY5OCwicGF0aCI6Ii80MzUzNDMwOS80NDc0OTk2MjYtYzVjZDU4NDAtZDU4ZS00NDU2LTgyMTctY2Y3ZjNiYTliYjRlLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA1MjclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwNTI3VDIyNDEzOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTVjOTNiZDc3YWY5ZDZlMjZhOTFmODg1NjkxZGFlMDk2YzE2OGY3ODdhOGY2MjQxNzU5MDNkNWFmYjY0Y2QxNjgmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.yDEGF7-fRybLIyfHX1AnEqL-76nHD-b17g3p-9xmShg)
> 
> so if we cater to text shifting to same vertical line, there will be difference in behavior w.r.t existing one and user will notice a shift in text to accomodate non-existing image icon)

You mean user will notice text is now aligned ? I think that's fine.
> 
> but it is fixable, so if we are in consensus about supporting the 4th item in rbma.cpp output in Java swing with text in same vertical offset, then let mw know..Anything else in addition needs discussion whether we can support...

I hope (!) we are on the same page. Let me try and say it so we are ..
- WE will always draw a check (tick)  or radio button to show the selected item
- WE will always reserve space for that tick
- WE will never over-write the check/tick with the icon image.
- Icon images will never move  (unlike the funky windows case which is the root of all of this)  because we will always reserve space for it.
- If ANY item has an icon image, ALL items reserve the space, even if not used, this is needed for the next item :
- Text strings will all align. Always

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2914400828

From honkar at openjdk.org  Tue May 27 23:36:50 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 27 May 2025 23:36:50 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java
In-Reply-To: <icxnrvZ3SZvVwQptHPyIuZyy4bvPStIcAPGM1Q2NTqM=.8159186e-1535-4be4-ba9c-681544fb1336@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
 <45KN4daBBRbauQz-o9yzcmdYpZmQJTzRJOrT1axLf8U=.db20c011-ced6-41c1-ae49-cfd190373ca7@github.com>
 <zwpkD7LsHwsi-ALKlT12mmopurQsWHLc6bVWfndwrLk=.8586b593-09b7-40d5-97b7-5b0b129b1bc6@github.com>
 <icxnrvZ3SZvVwQptHPyIuZyy4bvPStIcAPGM1Q2NTqM=.8159186e-1535-4be4-ba9c-681544fb1336@github.com>
Message-ID: <jaR_MvuEioFBA6eE3Qe0Mmpnaa94eq56jTgXfkJKgjg=.f44a0a83-6d82-497f-9ace-b85d3de538f3@github.com>

On Thu, 22 May 2025 19:55:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Recent AWT test updates have UI creation wrapped in EDT. I have seen many reviewers recommend using EDT even with AWT components.
>> 
>> Recently came across another PR where EDT is recommended. 
>> https://github.com/openjdk/jdk/pull/25278#discussion_r2098939094
>> https://github.com/openjdk/jdk/pull/25278#discussion_r2100689626
>
> For external use in apps we can recommend it so it will be unified for swing and awt, but for internal use we cannot simply switch to EDT as a cleanup or a bug fix. The code related to awt/2d runs in various threads and must be properly synchronized.

@mrserb 

I can remove the EDT but I do think retaining them will stabilize this test based on the context of test failure.

- Test does NOT fail when it is run multiple times on macos-aarch64 but only when entire test suite is run. Can it still be synchronization issue if it is not reproducible when test is run multiple times?   

- The test repeated fails on macos-aarch64 only when the entire test suite is run so I suspect this could be the effect of couple of Graphics tests that was recently open-sourced and indeed this matches with the timeline that this test started to fail repeatedly on macos-aarch64.

- I didn't see any recent source code changesets that has direct relation to this test failure. There was one recent change to copyArea and ongoing subsequent change https://github.com/openjdk/jdk/pull/25340 but the test does not hit the code path in Blit.c or MaskBlit.c so that eliminates these changes as the cause.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2110529825

From honkar at openjdk.org  Tue May 27 23:53:51 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 27 May 2025 23:53:51 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java
In-Reply-To: <jaR_MvuEioFBA6eE3Qe0Mmpnaa94eq56jTgXfkJKgjg=.f44a0a83-6d82-497f-9ace-b85d3de538f3@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
 <45KN4daBBRbauQz-o9yzcmdYpZmQJTzRJOrT1axLf8U=.db20c011-ced6-41c1-ae49-cfd190373ca7@github.com>
 <zwpkD7LsHwsi-ALKlT12mmopurQsWHLc6bVWfndwrLk=.8586b593-09b7-40d5-97b7-5b0b129b1bc6@github.com>
 <icxnrvZ3SZvVwQptHPyIuZyy4bvPStIcAPGM1Q2NTqM=.8159186e-1535-4be4-ba9c-681544fb1336@github.com>
 <jaR_MvuEioFBA6eE3Qe0Mmpnaa94eq56jTgXfkJKgjg=.f44a0a83-6d82-497f-9ace-b85d3de538f3@github.com>
Message-ID: <gAEy7ej82lUVH91C8BPMu4FOhk78SV7ZITs3xZILKvo=.0bd12457-a3f1-4c33-8bb9-a14c6219f1e7@github.com>

On Tue, 27 May 2025 23:34:32 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> For external use in apps we can recommend it so it will be unified for swing and awt, but for internal use we cannot simply switch to EDT as a cleanup or a bug fix. The code related to awt/2d runs in various threads and must be properly synchronized.
>
> @mrserb 
> 
> I can remove the EDT but I do think retaining them will stabilize this test based on the context of test failure.
> 
> - Test does NOT fail when it is run multiple times on macos-aarch64 but only when entire test suite is run. Can it still be synchronization issue if it is not reproducible when test is run multiple times?   
> 
> - The test repeated fails on macos-aarch64 only when the entire test suite is run so I suspect this could be the effect of couple of Graphics tests that was recently open-sourced and indeed this matches with the timeline that this test started to fail repeatedly on macos-aarch64.
> 
> - I didn't see any recent source code changesets that has direct relation to this test failure. There was one recent change to copyArea and ongoing subsequent change https://github.com/openjdk/jdk/pull/25340 but the test does not hit the code path in Blit.c or MaskBlit.c so that eliminates these changes as the cause.

At the very least test requires to be de-problemlisted to obtain the screenshots at the time of failure to see the state of the Frame.

This test repeatedly fails due to the same error at the same point (at x=267 y=212) which is about mid-way of the frame where the color is expected to be black but the actual is white.


java.lang.RuntimeException: Test failed for background region at x=267 y=212 (expected=ff000000 actual=ffffffff)
at CopyAreaOOB.testRegion(CopyAreaOOB.java:97)
at CopyAreaOOB.paint(CopyAreaOOB.java:77)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2110553753

From serb at openjdk.org  Wed May 28 01:10:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 28 May 2025 01:10:02 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java
In-Reply-To: <gAEy7ej82lUVH91C8BPMu4FOhk78SV7ZITs3xZILKvo=.0bd12457-a3f1-4c33-8bb9-a14c6219f1e7@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
 <45KN4daBBRbauQz-o9yzcmdYpZmQJTzRJOrT1axLf8U=.db20c011-ced6-41c1-ae49-cfd190373ca7@github.com>
 <zwpkD7LsHwsi-ALKlT12mmopurQsWHLc6bVWfndwrLk=.8586b593-09b7-40d5-97b7-5b0b129b1bc6@github.com>
 <icxnrvZ3SZvVwQptHPyIuZyy4bvPStIcAPGM1Q2NTqM=.8159186e-1535-4be4-ba9c-681544fb1336@github.com>
 <jaR_MvuEioFBA6eE3Qe0Mmpnaa94eq56jTgXfkJKgjg=.f44a0a83-6d82-497f-9ace-b85d3de538f3@github.com>
 <gAEy7ej82lUVH91C8BPMu4FOhk78SV7ZITs3xZILKvo=.0bd12457-a3f1-4c33-8bb9-a14c6219f1e7@github.com>
Message-ID: <MB04oCFbZM3_5bniz7LhS4SBeszRK6_1o9-zSgA4Qv4=.7d2d6f74-f25f-4fc4-853c-1983747d122f@github.com>

On Tue, 27 May 2025 23:51:05 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> @mrserb 
>> 
>> I can remove the EDT but I do think retaining them will stabilize this test based on the context of test failure.
>> 
>> - Test does NOT fail when it is run multiple times on macos-aarch64 but only when entire test suite is run. Can it still be synchronization issue if it is not reproducible when test is run multiple times?   
>> 
>> - The test repeated fails on macos-aarch64 only when the entire test suite is run so I suspect this could be the effect of couple of Graphics tests that was recently open-sourced and indeed this matches with the timeline that this test started to fail repeatedly on macos-aarch64.
>> 
>> - I didn't see any recent source code changesets that has direct relation to this test failure. There was one recent change to copyArea and ongoing subsequent change https://github.com/openjdk/jdk/pull/25340 but the test does not hit the code path in Blit.c or MaskBlit.c so that eliminates these changes as the cause.
>
> At the very least this test requires to be de-problemlisted to obtain the screenshots at the time of failure to see the state of the Frame.
> 
> This test repeatedly fails due to the same error at the same point (at x=267 y=212) which is about mid-way of the frame where the color is expected to be black but the actual is white.
> 
> 
> java.lang.RuntimeException: Test failed for background region at x=267 y=212 (expected=ff000000 actual=ffffffff)
> at CopyAreaOOB.testRegion(CopyAreaOOB.java:97)
> at CopyAreaOOB.paint(CopyAreaOOB.java:77) 
> 
> 
> **Expected Frame**
> 
> <img src="https://github.com/user-attachments/assets/b0af326e-f99f-474b-81a8-bb110cb0a37c" alt="background" width="150" height="150">

So it does not seems to be a test bug?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2110640053

From abhiscxk at openjdk.org  Wed May 28 02:24:02 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 28 May 2025 02:24:02 GMT
Subject: RFR: 8341311: [Accessibility, macOS,
 VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu
In-Reply-To: <_sXctfl4hH0eURjW3o_R0DLJp03F6VPioRzxcJ93xRQ=.263c5f31-f5ed-4975-865f-11721a0bdc1a@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
 <_sXctfl4hH0eURjW3o_R0DLJp03F6VPioRzxcJ93xRQ=.263c5f31-f5ed-4975-865f-11721a0bdc1a@github.com>
Message-ID: <-ik2Ehk-SMPAQCfVkToxWLiqC_3a7-LqJtkIRGfBaSc=.16a8a6c8-7d79-45ed-97cd-47ceb9853f9b@github.com>

On Tue, 27 May 2025 18:57:32 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> VoiceOver announce incorrect number of child for a submenu of JPopupMenu when it is visible for the first time only. After that VO is able to announce the number of items correctly.
>> 
>> Issue: Problem is with the a11y subsystem method call to get the accessible children details.
>> 
>> Analysis: When the Submenu of a JPopupMenu is opened, accessible component of PopupMenu is created dynamically in the native side implementation and `PostMenuOpened` notification is sent to the a11y subsystem for the newly created PopupMenu. Once the notification is sent to a11y sub-system, it invokes the `accessibilityChildren` method to get the children details for the menu component. A11y subsystem always retrieve the information of the root level PopupMenu irrespective of the submenu's PopupMenu (PopupMenu is associated with each JMenu) and thus announce the root level PopupMenu child count which is incorrect.
>> 
>> Proposed Fix: Proposed fix is to ensure the correct child details are sent back to a11y sub-system for correct announcement. So, whenever the `accessibilityChildren` method is invoked, first try to find out the current accessible PopupMenu which is opened for the Submenu and then return the child details.
>> 
>> Testing : Manual test case is attached to verify the fix and there is no failure with fix in CI pipeline.
>> 
>> `Current fix also ensures the correct child counts are announced for the JMenu's Submenu which are present in the JMenubar.`
>> 
>> **Note :** While verifying the fix, a new issue is unearthed for multi-level submenu where VO is failed to announce the Submenu's text. Since the issue exists without the proposed fix too, it shall be treated as a new bug finding and will raise a separate JBS issue.
>
> test/jdk/javax/accessibility/TestPopupMenuChildCount.java line 42:
> 
>> 40:  */
>> 41: 
>> 42: public class TestPopupMenuChildCount {
> 
> Nitpick: as far as I understand, this is for macOS only. Do you think it would make more sense to have a name mention that the test is Mac only? The same for test description. Seems to me a bit confusing otherwise 
> 
> It's fine with me if you leave it as it is though.

This test is only for macOS and that is conveyed through the jtreg tag [here](https://github.com/openjdk/jdk/blob/a225bf4bbe75aefffa63d54d2dff5577b3268339/test/jdk/javax/accessibility/TestPopupMenuChildCount.java#L36). I don't think test name needs to be changed.

Although it is not essentially required but will update the test summary and instruction.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25470#discussion_r2110743375

From abhiscxk at openjdk.org  Wed May 28 02:28:40 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 28 May 2025 02:28:40 GMT
Subject: RFR: 8341311: [Accessibility, macOS,
 VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu [v2]
In-Reply-To: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
Message-ID: <4FutPE0d1Zw2D3INL_ZhNEmhv2F1I2cQ9ElGGvC1qq0=.9bcd49be-cbf2-4cb9-969a-6d73ee951a40@github.com>

> VoiceOver announce incorrect number of child for a submenu of JPopupMenu when it is visible for the first time only. After that VO is able to announce the number of items correctly.
> 
> Issue: Problem is with the a11y subsystem method call to get the accessible children details.
> 
> Analysis: When the Submenu of a JPopupMenu is opened, accessible component of PopupMenu is created dynamically in the native side implementation and `PostMenuOpened` notification is sent to the a11y subsystem for the newly created PopupMenu. Once the notification is sent to a11y sub-system, it invokes the `accessibilityChildren` method to get the children details for the menu component. A11y subsystem always retrieve the information of the root level PopupMenu irrespective of the submenu's PopupMenu (PopupMenu is associated with each JMenu) and thus announce the root level PopupMenu child count which is incorrect.
> 
> Proposed Fix: Proposed fix is to ensure the correct child details are sent back to a11y sub-system for correct announcement. So, whenever the `accessibilityChildren` method is invoked, first try to find out the current accessible PopupMenu which is opened for the Submenu and then return the child details.
> 
> Testing : Manual test case is attached to verify the fix and there is no failure with fix in CI pipeline.
> 
> `Current fix also ensures the correct child counts are announced for the JMenu's Submenu which are present in the JMenubar.`
> 
> **Note :** While verifying the fix, a new issue is unearthed for multi-level submenu where VO is failed to announce the Submenu's text. Since the issue exists without the proposed fix too, it shall be treated as a new bug finding and will raise a separate JBS issue.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Minor update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25470/files
  - new: https://git.openjdk.org/jdk/pull/25470/files/a225bf4b..6cebdff4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25470&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25470&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25470/head:pull/25470

PR: https://git.openjdk.org/jdk/pull/25470

From serb at openjdk.org  Wed May 28 02:33:04 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 28 May 2025 02:33:04 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v13]
In-Reply-To: <ZBP2gR52LbACfOwuS7dhQhEzKIKrRQjynqVp4tPFp9Q=.fe7b9661-4d6f-4dc4-a85c-a18738a74eb2@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <ZBP2gR52LbACfOwuS7dhQhEzKIKrRQjynqVp4tPFp9Q=.fe7b9661-4d6f-4dc4-a85c-a18738a74eb2@github.com>
Message-ID: <k7VncC6_GdcO1oCwmpqEOUaqeNC4yp9jGpC1zh9upYM=.4d4ceade-3888-4a88-8b9f-2e8620d5949e@github.com>

On Fri, 23 May 2025 11:48:38 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
>> 
>> ---------
>> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default and static methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses.
>> 
>> When a subclass "overrides" a static method from a parent class `getMethodDescriptors()` behaves as follows:
>> 
>> - In case of a clash with a class method, the class version will take precedence rather than interface's one. 
>> - If the same method appears in multiple classes/interfaces within the same hierarchy, the version from the most specific sub-interface will be selected.
>> - If the method appears in classes/interfaces from different hierarchies, the result is undefined, either version can be returned.
>> 
>> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
>> 
>> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
>> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
>> * Gettters/setters declared and not implemented are not considered.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restored the original order processing

It would be nice to merge the master, the branch is quite outdated

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2914701595

From serb at openjdk.org  Wed May 28 02:40:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 28 May 2025 02:40:58 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v4]
In-Reply-To: <DMhK2yhL3IOU9aq6N1J2Im-EhC_L6IH2qw17aMugygE=.4acbdfe3-3350-4986-9f20-9353a7bc4273@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <TeBe9DI5AuCjtP4iTp7g1UAhafKnpdz-4DHaRISktd8=.9dbeb508-ac06-4319-91d4-97e6a0108a33@github.com>
 <tAHygDZOrjsNIxY2viFQ3CK5oD0gzaJsJ6CbR1kzc20=.c446c35e-6db9-4628-950c-058d77b5aad2@github.com>
 <DMhK2yhL3IOU9aq6N1J2Im-EhC_L6IH2qw17aMugygE=.4acbdfe3-3350-4986-9f20-9353a7bc4273@github.com>
Message-ID: <miQMydzf40ruao9E1mTYUK5Ouw5tMoFVLGh0qjFXS0o=.0f2fec72-ca0e-4d45-a642-0bb55c25525c@github.com>

On Mon, 26 May 2025 02:38:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JSplitPane.java line 373:
>> 
>>> 371:     public void setComponentOrientation(ComponentOrientation orientation) {
>>> 372:         if (!orientation.equals(this.getComponentOrientation())) {
>>> 373:             super.setComponentOrientation(orientation);
>> 
>> I would like to bring up for discussion whether we should move this line outside the if block. From what I can tell, it was always executed before the initial fix, so this change might affect the original behavior.
>
> If we call setComponentOrientation in test (like in TestSplitPaneOrientationTest.java which was added for JDK-4265389) then this check would fail as ComponentOrientation object would change if we call super.setComponentOrientation outside the if block (that is because `setComponentOrientation `stores the passed orientation so `this.getComponentOrientation` would always be same as `orientation `after `super.setComponentOrientation `call) and so left/right component would not be set..
> Also, the initial fix didn't have the ComponentOrientation support so that code is anyway redundant..

But we can read/save orientation, then call super, then make a check? 
I am not sure how important to always call super.setComponentOrientation(orientation);
can we miss some notification fired from that method?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25294#discussion_r2110762409

From serb at openjdk.org  Wed May 28 02:44:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 28 May 2025 02:44:52 GMT
Subject: RFR: 8355904: Use variadic macros for J2dTrace [v6]
In-Reply-To: <rNnbkM8NpX0HYVUh0rPOnohIycsaLtvTDFBx4Un38G8=.b2e95ecc-8e7e-4f41-85ca-51c7556fd573@github.com>
References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
 <rNnbkM8NpX0HYVUh0rPOnohIycsaLtvTDFBx4Un38G8=.b2e95ecc-8e7e-4f41-85ca-51c7556fd573@github.com>
Message-ID: <FL3jXk3_Xy8pufGej82sn8PnckAof-ZFmqK_sL_tA5g=.ab1f0967-d80d-4b9a-a9e0-df74128656e0@github.com>

On Thu, 22 May 2025 20:44:30 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> J2dTrace macros have multiple overloads specifying number of arguments, making it less convent to change number of arguments. There were cases when existing macros were not enough and people had to add new variants with even more arguments. We could simply use variadic macros instead.
>> 
>> Also, currently those macros expand to a { code block }, which doesn't require a semicolon at the end, so it can sometimes be missed, leading to an inconsistent code style. We could expand it directly to the function, forcing user to insert a semicolon after that, in a function-like style.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update D3DShaderGen.c

Please confirm that you have built the debug versions on all platforms and checked the output for at least some of these methods.

-------------

Marked as reviewed by serb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24949#pullrequestreview-2873376948

From psadhukhan at openjdk.org  Wed May 28 03:21:45 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 May 2025 03:21:45 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v5]
In-Reply-To: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
Message-ID: <RI0QhBcF4ytQvLXlFrBy31ed35u_EG5XWmE54ogtRBc=.dd1693b3-15e5-4ba2-9754-b34a145bacfb@github.com>

> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
> Fixed by setting the divider location before rendering the left and right components..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Store current orientation for check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25294/files
  - new: https://git.openjdk.org/jdk/pull/25294/files/32fe70f5..f721cedc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25294&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25294&range=03-04

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25294/head:pull/25294

PR: https://git.openjdk.org/jdk/pull/25294

From psadhukhan at openjdk.org  Wed May 28 03:23:51 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 May 2025 03:23:51 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v4]
In-Reply-To: <miQMydzf40ruao9E1mTYUK5Ouw5tMoFVLGh0qjFXS0o=.0f2fec72-ca0e-4d45-a642-0bb55c25525c@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <TeBe9DI5AuCjtP4iTp7g1UAhafKnpdz-4DHaRISktd8=.9dbeb508-ac06-4319-91d4-97e6a0108a33@github.com>
 <tAHygDZOrjsNIxY2viFQ3CK5oD0gzaJsJ6CbR1kzc20=.c446c35e-6db9-4628-950c-058d77b5aad2@github.com>
 <DMhK2yhL3IOU9aq6N1J2Im-EhC_L6IH2qw17aMugygE=.4acbdfe3-3350-4986-9f20-9353a7bc4273@github.com>
 <miQMydzf40ruao9E1mTYUK5Ouw5tMoFVLGh0qjFXS0o=.0f2fec72-ca0e-4d45-a642-0bb55c25525c@github.com>
Message-ID: <61tykjKijk-xkAT398xNxGXuqaSEBw88B4begSzHndo=.2a5c38cf-cef0-473d-bd86-516d7e21c47c@github.com>

On Wed, 28 May 2025 02:38:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> If we call setComponentOrientation in test (like in TestSplitPaneOrientationTest.java which was added for JDK-4265389) then this check would fail as ComponentOrientation object would change if we call super.setComponentOrientation outside the if block (that is because `setComponentOrientation `stores the passed orientation so `this.getComponentOrientation` would always be same as `orientation `after `super.setComponentOrientation `call) and so left/right component would not be set..
>> Also, the initial fix didn't have the ComponentOrientation support so that code is anyway redundant..
>
> But we can read/save orientation, then call super, then make a check? 
> I am not sure how important to always call super.setComponentOrientation(orientation);
> can we miss some notification fired from that method?

OK. Current orientation is stored and then checked and super.setComponentOrientation is called before check.
I guess that method fires PropertyChangeEvent for orientation set and now it will be fired always like before..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25294#discussion_r2110805437

From psadhukhan at openjdk.org  Wed May 28 03:31:53 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 May 2025 03:31:53 GMT
Subject: RFR: 8357299: Graphics copyArea doesn't copy any pixels when there
 is overflow
In-Reply-To: <rYu0g4fVWaCX7yxGhNgYijkzsYIUjWnnGdwiq3u5ZeU=.09c39483-6204-4490-b952-5c4ed8cfdc6b@github.com>
References: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
 <rYu0g4fVWaCX7yxGhNgYijkzsYIUjWnnGdwiq3u5ZeU=.09c39483-6204-4490-b952-5c4ed8cfdc6b@github.com>
Message-ID: <tugH2JMkemfDK7hiEvhXNORN7OxSyLsKGPO0bjNicn8=.27d05a6d-4659-4bc6-96ad-fd31fd8ae56f@github.com>

On Fri, 23 May 2025 20:59:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> Graphics copyArea overflow check bails out of copying pixels if there is overflow.
>> The spec says ""If a portion of the source rectangle lies outside the bounds of the component, or is obscured by another window or component, {@code copyArea} *will be unable to copy* the associated pixels"
>> 
>> which suggests that we should always copy the parts inside the bounds and never the parts outside the bounds
>> but it seems currently, in the case of overflow it no longer copies any pixels, including the parts that are inside. 
>> So, the fix clips the copyarea region to clip bounds so it will only affect pixels within the valid bounds, and any pixels outside will be ignored.
>
> src/java.desktop/share/native/libawt/java2d/loops/Blit.c line 85:
> 
>> 83:     dstInfo.bounds.x2 = UNSAFE_TO_ADD(dstx, width)
>> 84:                         ? clipInfo.bounds.x2 : (dstx + width);
>> 85:     dstInfo.bounds.y2 = UNSAFE_TO_ADD(dsty, height)
> 
> why wouldn't you always want to limit it to the clip ?
> I mean shouldn't it be like this ?
> dstInfo.bounds.x2 = UNSAFE_TO_ADD(dstx, width)  ? clipInfo.bounds.x2 : (((dstx + width) > clipInfo.bounds.x2) ? clipInfo.bounds.x2 : (dstx + width));
> or maybe a bit more readable as 
> dstInfo.bounds.x2 = ((UNSAFE_TO_ADD(dstx, width) || ((dstx + width) > clipInfo.bounds.x2)) ? clipInfo.bounds.x2 : (dstx + width);

@prrace Since it is going to clip dstInfo.bounds to clipInfo.bounds in SurfaceData_IntersectBounds, I believe is not necessary to do the duplicate clip here.
Let me know if you think otherwise..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25340#discussion_r2110814256

From psadhukhan at openjdk.org  Wed May 28 03:41:06 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 May 2025 03:41:06 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v24]
In-Reply-To: <8nB0Stxw9Qbs2FRElahZWOK5AVkSpOftlgcKuSFnPsI=.edda5259-7541-421d-a8af-2aa6605ae4bf@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <r2rc8bQXcTBsfUdjau7I_N8uKGqF907DetuVJF83L3M=.df59aaf6-a461-440b-a20e-0aeefa05d327@github.com>
 <8nB0Stxw9Qbs2FRElahZWOK5AVkSpOftlgcKuSFnPsI=.edda5259-7541-421d-a8af-2aa6605ae4bf@github.com>
Message-ID: <crOfCXICMzTnSSZ2y9hwxyAE8GswOxnzNkvc9teAzZA=.5a13b7f9-fcf3-4816-a61d-f7232327c888@github.com>

On Tue, 27 May 2025 23:10:11 GMT, Phil Race <prr at openjdk.org> wrote:

> I hope (!) we are on the same page. Let me try and say it so we are ..
> 
>     * WE will always draw a check (tick)  or radio button to show the selected item
> 
Yes, current PR does this..

>     * WE will always reserve space for that tick
>
Yes, current PR does this.
 
>     * WE will never over-write the check/tick with the icon image.
>
Yes, current PR does this.
 
>     * Icon images will never move  (unlike the funky windows case which is the root of all of this)  because we will always reserve space for it.
> 
Yes, icon image has its own space in current PR

>     * If ANY item has an icon image, ALL items reserve the space, even if not used, this is needed for the next item :
> 
>     * Text strings will all align. Always

Current PR doesnt have this..Text string is not aligned for item that doesn't have iconimage with item that does have iconimage. I will fix this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2914795445

From psadhukhan at openjdk.org  Wed May 28 03:48:03 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 May 2025 03:48:03 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v25]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <fQ2SnRlesdfXreT8kQAwxeX1HXknYaCWv1qOfXOue2k=.b05d4088-d6ac-4c96-8363-9372096c718a@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan 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 29 additional commits since the last revision:

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
 - Review comments fix
 - Expand wildcard imports
 - Remove unneeded methods
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
 - Code duplication removed
 - Remove Windows L&F check from BasicMenuItemUI
 - Review comment fix
 - Test rename
 - Revert to non-CSR needed fix
 - ... and 19 more: https://git.openjdk.org/jdk/compare/fad5797e...ba7ecae3

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/e20cfc05..ba7ecae3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=23-24

  Stats: 505436 lines in 6900 files changed: 196150 ins; 275956 del; 33330 mod
  Patch: https://git.openjdk.org/jdk/pull/23324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324

PR: https://git.openjdk.org/jdk/pull/23324

From psadhukhan at openjdk.org  Wed May 28 05:38:17 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 May 2025 05:38:17 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v26]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <zyFTmi3ronKWVWIt2FcdF05eNbpWqG3i3Uhxp-Cs4To=.4e2eabfb-b9d3-4409-b8e6-7d7e3965f71e@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Text alignment fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/ba7ecae3..bfc108e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=24-25

  Stats: 8 lines in 1 file changed: 0 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324

PR: https://git.openjdk.org/jdk/pull/23324

From rmarchenko at openjdk.org  Wed May 28 05:45:56 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 28 May 2025 05:45:56 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v14]
In-Reply-To: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
Message-ID: <EdUI2bfXIkeFm84pTYVnemPcUzNF2SougytI3CI5TfU=.37c0b721-35ab-4236-9658-ded2541d9ee8@github.com>

> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
> 
> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
> 
> ---------
> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default and static methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses.
> 
> When a subclass "overrides" a static method from a parent class `getMethodDescriptors()` behaves as follows:
> 
> - In case of a clash with a class method, the class version will take precedence rather than interface's one. 
> - If the same method appears in multiple classes/interfaces within the same hierarchy, the version from the most specific sub-interface will be selected.
> - If the method appears in classes/interfaces from different hierarchies, the result is undefined, either version can be returned.
> 
> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
> 
> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
> * Gettters/setters declared and not implemented are not considered.

Roman Marchenko 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 18 additional commits since the last revision:

 - Merge branch 'openjdk:master' into jdk-8347826
 - Restored the original order processing
 - Fixing review comments
 - Implementing new requirements
 - Merge branch 'master' into jdk-8347826
 - Fixing review comments
 - Fixing review comments 2
 - Symmetric fix
 - minor fix
 - minor fix
 - ... and 8 more: https://git.openjdk.org/jdk/compare/b63c9c9a...779194f1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23443/files
  - new: https://git.openjdk.org/jdk/pull/23443/files/431705a0..779194f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=12-13

  Stats: 436893 lines in 5240 files changed: 174030 ins; 237687 del; 25176 mod
  Patch: https://git.openjdk.org/jdk/pull/23443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23443/head:pull/23443

PR: https://git.openjdk.org/jdk/pull/23443

From psadhukhan at openjdk.org  Wed May 28 05:49:59 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 May 2025 05:49:59 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v26]
In-Reply-To: <zyFTmi3ronKWVWIt2FcdF05eNbpWqG3i3Uhxp-Cs4To=.4e2eabfb-b9d3-4409-b8e6-7d7e3965f71e@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <zyFTmi3ronKWVWIt2FcdF05eNbpWqG3i3Uhxp-Cs4To=.4e2eabfb-b9d3-4409-b8e6-7d7e3965f71e@github.com>
Message-ID: <mNTPINW3gUPOEW5urA6cR63IYDkyrt-6cap8RSP3RpI=.bd53c6a5-e102-441a-83a9-3cf733a0511b@github.com>

On Wed, 28 May 2025 05:38:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Text alignment fix

Text alignment fixed .. Current PR now looks like this

![image](https://github.com/user-attachments/assets/9dff3831-7216-434a-b809-ed95dcf9c598)

In SwingSet2, now there will be gap between bullet and text to accomodate non-existing imageicon

![image](https://github.com/user-attachments/assets/f305fdc4-47e2-48ad-a28f-a578d7a4aeff)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2915019457

From serb at openjdk.org  Wed May 28 06:57:32 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 28 May 2025 06:57:32 GMT
Subject: RFR: 8357696: Enhance code consistency: java.desktop/unix:sun
Message-ID: <STnj3-XhfIKP3W8Z4ysYaKmKpvFpU8VW3uJTEtB7Ge8=.f1fee560-1d04-4b53-8fcb-a74b03757ed3@github.com>

This is a request to update the remaining parts of the java.desktop/unix package.
The sun.awt subpackage under java.desktop/unix was previously addressed by https://github.com/openjdk/jdk/pull/24941.

====================================================

The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency.

The public API was not affected so there is no need to worry about a CSR

Note: I will submit additional patches in this area later because:

1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797))
2. I skipped adding `@Override` for anonymous classes

Any feedback or suggestions are welcome!

Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25439.diff) to a simple diff file, it might be more convenient for reviewing the changes.

To download the diff file and filter only the modified lines you can use the following script:


curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25439.diff -o d.txt && grep -E '^+|^-' d.txt


The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected by these changes. It would be good to verify this by mach5 to ensure everything works as expected.

-------------

Commit messages:
 - Merge branch 'openjdk:master' into over_all_unix
 - final in java.desktop/unix
 - override in java.desktop/unix

Changes: https://git.openjdk.org/jdk/pull/25439/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25439&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357696
  Stats: 390 lines in 64 files changed: 294 ins; 0 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/25439.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25439/head:pull/25439

PR: https://git.openjdk.org/jdk/pull/25439

From serb at openjdk.org  Wed May 28 09:01:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 28 May 2025 09:01:55 GMT
Subject: RFR: 8357687: Remove unnecessary Map.containsKey from
 GraphicsEnvironment implementations
In-Reply-To: <1uiKqIpG8uZ6YKrglYBxK7nMYaqioOirqfiRAp5z7Dw=.813063e1-e218-4794-8bc1-fd8f543c4a74@github.com>
References: <1uiKqIpG8uZ6YKrglYBxK7nMYaqioOirqfiRAp5z7Dw=.813063e1-e218-4794-8bc1-fd8f543c4a74@github.com>
Message-ID: <mF3Fnmn2237IVlqBZQJeEp-JFJJYT2Ni28mn0E85MqM=.bd4e7df7-5606-4a6d-83e3-809410744419@github.com>

On Sun, 27 Apr 2025 21:04:34 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `devices` contains only non-null values. It means instead of separate `containsKey` call we can just call `HashMap.get` and then compare result with `null`.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24907#pullrequestreview-2874193509

From duke at openjdk.org  Wed May 28 10:34:41 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Wed, 28 May 2025 10:34:41 GMT
Subject: RFR: 8251928: [macos] the printer DPI always be 72,
 cause some content lost when print out
Message-ID: <rR0Z3tgI9pY3Bh5XTqUr2Q_wf4kspUitnygW5CgxHE4=.1f2586f7-b715-457f-88ed-247155d6fb90@github.com>

The fix for the https://bugs.openjdk.org/browse/JDK-8251928.

**Description**.
This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob.

As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ):
1. Convert the user-space point, size, or rectangle value to device space coordinates;
2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary;
3. Convert the normalized value back to user space;
4. Draw your content using the adjusted value. 
    
The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI.
The 2-nd step is a drawing process in the java code (without changes).
The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI.
The 4-th step is a drawing process in the native code (without changes).

**Tests**.
I run all tests from javax.print package and there is no any regression.
New test covers macOS and Linux only because we know its default DPI - 300.

-------------

Commit messages:
 - [macos] the printer DPI always be 72

Changes: https://git.openjdk.org/jdk/pull/25489/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25489&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8251928
  Stats: 311 lines in 5 files changed: 284 ins; 8 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25489.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25489/head:pull/25489

PR: https://git.openjdk.org/jdk/pull/25489

From dgredler at openjdk.org  Wed May 28 11:21:53 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 28 May 2025 11:21:53 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377
In-Reply-To: <d6b4WxmTSTAL3soxfcjQZeEhteydDfd0GexPIUVedLY=.b77d056e-6d1e-463e-9cb8-c30ecabe4695@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
 <d6b4WxmTSTAL3soxfcjQZeEhteydDfd0GexPIUVedLY=.b77d056e-6d1e-463e-9cb8-c30ecabe4695@github.com>
Message-ID: <KgkJbqO4cq5XrnUHfmakwrA0uQRVQDfThedE1cCW230=.a491f8cf-8c8d-4b8a-bc43-a6f8b89962f2@github.com>

On Thu, 1 May 2025 21:55:00 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> It looks like this regression actually fits into a longer series of fixes / regressions in this area:
>> 
>> - [JDK-4517298](https://bugs.openjdk.org/browse/JDK-4517298) fixed metrics for zero-width characters, but broke some ligatures / glyph substitutions
>> - [JDK-7017058](https://bugs.openjdk.org/browse/JDK-7017058) fixed the ligatures / glyph substitutions, but broke some zero-width metrics
>> - [JDK-8208377](https://bugs.openjdk.org/browse/JDK-8208377) fixed some metrics and rendering for zero-width characters, but broke some ligatures / glyph substitutions
>> - Now, with this PR, we aim to fix the ligatures without re-breaking zero-width metrics and display
>> 
>> We have two different types of use cases pulling `CharToGlyphMapper` in two different directions: the users who need raw, untransformed glyph info, and the users who need normalized / transformed glyph info.
>> 
>> It looks to me like, in the current code base, the only `CharToGlyphMapper` user which requires raw font data is HarfBuzz (explicitly confirmed with the HarfBuzz team here: https://github.com/harfbuzz/harfbuzz/discussions/5234).
>> 
>> The regression mechanism at play here is that the HarfBuzz font callbacks are currently providing HarfBuzz with transformed glyph info (e.g. ZWJ -> INVISIBLE_GLYPH_ID), which prevents HarfBuzz from recognizing and applying the correct font GSUB substitutions (which involve ZWJ).
>> 
>> In order to fix this without (yet again) breaking metrics and display behavior elsewhere, I've added two methods to `CharToGlyphMapper` which provide access to raw glyph info, to be used by the HarfBuzz font callbacks: `charToGlyphRaw(int)` and `charToVariationGlyphRaw(int)`.
>> 
>> Note two intricacies related to `CompositeGlyphMapper`:
>> 1. We need to be careful to only cache raw (untransformed) values, to avoid conflicts between requests for a raw version of a glyph and a transformed version of the same glyph. Another option would have been two separate caches, but I don't think that's necessary.
>> 2. Consumers who are using `CompositeGlyphMapper.SLOTMASK` to check glyph slots (e.g. `FontRunIterator` and `CTextPipe`) will "see" invisible glyphs as having come from slot 0. This isn't new, and I think it's OK, but something to be aware of.
>> 
>> The glyph cache handling in `CCharToGlyphMapper` (for macOS) also requires care to avoid mixing value types.
>> 
>> Please also note that I'm not sure if the tweak to `sunFont.c` is being tested, since FFM is being used by default for Harf...
>
> I was talking about the explosion because there is a scenario in my mind, which I didn't make clear for everybody else. There is a change which I didn't have time to contribute, but would like to: it's related to composite fonts and variation selectors. We may need 2 variants for retrieving a glyph with a variation selector - one strictly matching a variation selector and another with a fallback to the base glyph, multiplied by raw/transformed versions, which adds 2 more methods. Not like it's a big problem, but given that they all end up calling a single method anyway... You get the point.
> 
>> there may be other scenarios in the future, e.g. \r, \n and \t which currently are handled elsewhere).
> 
> Are those scenarios specific to a patricular mapper/font type? I was thinking that those transformations are generic.
> 
>> Any ideas for what this refactoring might look like?
> 
> I was thinking about moving this default-ignorable or any potential generic transformation into base `CharToGlyphMapper` or even `Font2D`. For example, make default implementation of `CharToGlyphMapper.charToGlyph` check ignorable characters and then call `charToGlyphRaw` - then other implementations would only need to override `charToGlyphRaw`.

@YaaZ I had a look at your suggestion to push up the `raw` checks into the `CharToGlyphMapper` superclass and the complicating factor are the three `charsToGlyphs` methods which take arrays. These are handled differently in each subclass, and even if we were able to refactor all subclass implementations to ensure that they all call into the public single-char superclass methods (where we would add the `raw` checks), it would be relatively brittle (not obvious to future maintainers that the call to the superclass method cannot be removed). The current approach does require each subclass to handle the `raw` boolean, but it also allows each subclass to internally do that in a unified, simplified way. Please feel free to prototype something on your end -- I'm open to helping with future improvements in this area, if feasible.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24412#issuecomment-2915937125

From aivanov at openjdk.org  Wed May 28 12:37:51 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 May 2025 12:37:51 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java
In-Reply-To: <gAEy7ej82lUVH91C8BPMu4FOhk78SV7ZITs3xZILKvo=.0bd12457-a3f1-4c33-8bb9-a14c6219f1e7@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
 <45KN4daBBRbauQz-o9yzcmdYpZmQJTzRJOrT1axLf8U=.db20c011-ced6-41c1-ae49-cfd190373ca7@github.com>
 <zwpkD7LsHwsi-ALKlT12mmopurQsWHLc6bVWfndwrLk=.8586b593-09b7-40d5-97b7-5b0b129b1bc6@github.com>
 <icxnrvZ3SZvVwQptHPyIuZyy4bvPStIcAPGM1Q2NTqM=.8159186e-1535-4be4-ba9c-681544fb1336@github.com>
 <jaR_MvuEioFBA6eE3Qe0Mmpnaa94eq56jTgXfkJKgjg=.f44a0a83-6d82-497f-9ace-b85d3de538f3@github.com>
 <gAEy7ej82lUVH91C8BPMu4FOhk78SV7ZITs3xZILKvo=.0bd12457-a3f1-4c33-8bb9-a14c6219f1e7@github.com>
Message-ID: <k3h3vEvdaausCje0R6QskmFOvaqBNb8q7fZvZHdftIg=.a9d85c09-ccd7-4b33-b43f-fe92eeb5a741@github.com>

On Tue, 27 May 2025 23:51:05 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> @mrserb 
>> 
>> I can remove the EDT but I do think retaining them will stabilize this test based on the context of test failure.
>> 
>> - Test does NOT fail when it is run multiple times on macos-aarch64 but only when entire test suite is run. Can it still be synchronization issue if it is not reproducible when test is run multiple times?   
>> 
>> - The test repeated fails on macos-aarch64 only when the entire test suite is run so I suspect this could be the effect of couple of Graphics tests that was recently open-sourced and indeed this matches with the timeline that this test started to fail repeatedly on macos-aarch64.
>> 
>> - I didn't see any recent source code changesets that has direct relation to this test failure. There was one recent change to copyArea and ongoing subsequent change https://github.com/openjdk/jdk/pull/25340 but the test does not hit the code path in Blit.c or MaskBlit.c so that eliminates these changes as the cause.
>
> At the very least this test requires to be de-problemlisted to obtain the screenshots at the time of failure to see the state of the Frame.
> 
> This test repeatedly fails due to the same error at the same point (at x=267 y=212) which is about mid-way of the frame where the color is expected to be black but the actual is white.
> 
> 
> java.lang.RuntimeException: Test failed for background region at x=267 y=212 (expected=ff000000 actual=ffffffff)
> at CopyAreaOOB.testRegion(CopyAreaOOB.java:97)
> at CopyAreaOOB.paint(CopyAreaOOB.java:77) 
> 
> 
> **Expected Frame**
> 
> <img src="https://github.com/user-attachments/assets/b0af326e-f99f-474b-81a8-bb110cb0a37c" alt="background" width="150" height="150">

@honkar-jdk This does seem weird? Since the test is _headful_, it starts a new JVM for each execution and the JVM is shut down after the `main` method exits. I don't think the test runs long enough for synchronisation issues to manifest themselves, especially during the initial startup.

At the same time, aarch64 is usually more sensitive to the lack of proper synchronisation than x86_64.

If the test test fails only when it's run together with other tests in CI, could it be that the test frame is covered by anything?

Re: `expected=ff000000 actual=ffffffff` ? I can't see a while pixel on the screenshot. Does the test save both images: the expected and the actual one?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2111744123

From dgredler at openjdk.org  Wed May 28 13:10:08 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 28 May 2025 13:10:08 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377 [v3]
In-Reply-To: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
Message-ID: <U2lFov564x2YaVy_kemnR3WKxstet7-91gjWqN6cZxY=.646930be-961f-4948-a10a-142caf4a7ecc@github.com>

> It looks like this regression actually fits into a longer series of fixes / regressions in this area:
> 
> - [JDK-4517298](https://bugs.openjdk.org/browse/JDK-4517298) fixed metrics for zero-width characters, but broke some ligatures / glyph substitutions
> - [JDK-7017058](https://bugs.openjdk.org/browse/JDK-7017058) fixed the ligatures / glyph substitutions, but broke some zero-width metrics
> - [JDK-8208377](https://bugs.openjdk.org/browse/JDK-8208377) fixed some metrics and rendering for zero-width characters, but broke some ligatures / glyph substitutions
> - Now, with this PR, we aim to fix the ligatures without re-breaking zero-width metrics and display
> 
> We have two different types of use cases pulling `CharToGlyphMapper` in two different directions: the users who need raw, untransformed glyph info, and the users who need normalized / transformed glyph info.
> 
> It looks to me like, in the current code base, the only `CharToGlyphMapper` user which requires raw font data is HarfBuzz (explicitly confirmed with the HarfBuzz team here: https://github.com/harfbuzz/harfbuzz/discussions/5234).
> 
> The regression mechanism at play here is that the HarfBuzz font callbacks are currently providing HarfBuzz with transformed glyph info (e.g. ZWJ -> INVISIBLE_GLYPH_ID), which prevents HarfBuzz from recognizing and applying the correct font GSUB substitutions (which involve ZWJ).
> 
> In order to fix this without (yet again) breaking metrics and display behavior elsewhere, I've added two methods to `CharToGlyphMapper` which provide access to raw glyph info, to be used by the HarfBuzz font callbacks: `charToGlyphRaw(int)` and `charToVariationGlyphRaw(int)`.
> 
> Note two intricacies related to `CompositeGlyphMapper`:
> 1. We need to be careful to only cache raw (untransformed) values, to avoid conflicts between requests for a raw version of a glyph and a transformed version of the same glyph. Another option would have been two separate caches, but I don't think that's necessary.
> 2. Consumers who are using `CompositeGlyphMapper.SLOTMASK` to check glyph slots (e.g. `FontRunIterator` and `CTextPipe`) will "see" invisible glyphs as having come from slot 0. This isn't new, and I think it's OK, but something to be aware of.
> 
> The glyph cache handling in `CCharToGlyphMapper` (for macOS) also requires care to avoid mixing value types.
> 
> Please also note that I'm not sure if the tweak to `sunFont.c` is being tested, since FFM is being used by default for HarfBuzz integration. (Is there a plan to remove...

Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:

  Fix conflict with whitespace logic handling updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24412/files
  - new: https://git.openjdk.org/jdk/pull/24412/files/fb272367..c68240b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24412&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24412&range=01-02

  Stats: 77 lines in 7 files changed: 28 ins; 32 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/24412.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24412/head:pull/24412

PR: https://git.openjdk.org/jdk/pull/24412

From abaya at openjdk.org  Wed May 28 13:40:45 2025
From: abaya at openjdk.org (Anass Baya)
Date: Wed, 28 May 2025 13:40:45 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v4]
In-Reply-To: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
Message-ID: <Iobja6T_U-M5Fe_iqYblGwwgQXGXMMTRzyWwoqi261E=.f6b51bee-fa1f-49c1-b8c9-874b20cc5332@github.com>

> **Analysis :**
> 
> Whether the test passes on the main line or fails, the behavior is still incorrect.
> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly.
> 
> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt.
> 
> This causes the test to proceed immediately to the validation step:
> 
> if (fd.isVisible()) {
>     throw new RuntimeException("File Dialog is not closed");
> }
> 
> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet)
> 
> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation.
> 
> **Proposed fix:**
> 
> set the CountDownLatch to 2
> 
> **Proposed enhancements :**
> 
> Remove unnecessary threads (Thread and Thread-2)
> Properly handle delays and robot.waitForIdle()
> Avoid indefinite blocking on latch.await()
> 
> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds
> 
> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details

Anass Baya has updated the pull request incrementally with two additional commits since the last revision:

 - add DoubleActionESCWithGtkDisabled
 - Tests that FileDialog can be closed by ESC any time when GtkFileDialog is disabled

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25184/files
  - new: https://git.openjdk.org/jdk/pull/25184/files/31472930..2b0cf0ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25184&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25184&range=02-03

  Stats: 39 lines in 2 files changed: 37 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25184/head:pull/25184

PR: https://git.openjdk.org/jdk/pull/25184

From abaya at openjdk.org  Wed May 28 13:49:40 2025
From: abaya at openjdk.org (Anass Baya)
Date: Wed, 28 May 2025 13:49:40 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v5]
In-Reply-To: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
Message-ID: <HzKfp432_nUHOlmXDyARd9IWq1vV7K_nVpQs7lCZaew=.8f5fb58e-d188-4a40-9921-6f0ac12eabd8@github.com>

> **Analysis :**
> 
> Whether the test passes on the main line or fails, the behavior is still incorrect.
> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly.
> 
> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt.
> 
> This causes the test to proceed immediately to the validation step:
> 
> if (fd.isVisible()) {
>     throw new RuntimeException("File Dialog is not closed");
> }
> 
> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet)
> 
> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation.
> 
> **Proposed fix:**
> 
> set the CountDownLatch to 2
> 
> **Proposed enhancements :**
> 
> Remove unnecessary threads (Thread and Thread-2)
> Properly handle delays and robot.waitForIdle()
> Avoid indefinite blocking on latch.await()
> 
> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds
> 
> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details

Anass Baya has updated the pull request incrementally with two additional commits since the last revision:

 - Remove whitespace
 - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java
   
   Alexey's proposed changes
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25184/files
  - new: https://git.openjdk.org/jdk/pull/25184/files/2b0cf0ac..c5718772

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25184&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25184&range=03-04

  Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25184/head:pull/25184

PR: https://git.openjdk.org/jdk/pull/25184

From abaya at openjdk.org  Wed May 28 13:49:40 2025
From: abaya at openjdk.org (Anass Baya)
Date: Wed, 28 May 2025 13:49:40 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v2]
In-Reply-To: <Tb8wCoSGNxrXbmWsx0UYegv2BbteRHBZcYQUP3qnZaQ=.d733e1cc-82d6-4d34-b9fb-27532b6c1731@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
 <iNjn5dg1IjU_fT_ajdxgdO5iuk030EZtkrPT34_wjFs=.4e8c3708-36fc-4bcc-9f70-a3779416b501@github.com>
 <Tb8wCoSGNxrXbmWsx0UYegv2BbteRHBZcYQUP3qnZaQ=.d733e1cc-82d6-4d34-b9fb-27532b6c1731@github.com>
Message-ID: <P10bBXVVnmLh1REf4zYXY6SVzR0XlPn0CEa0VVRV1sY=.825afc99-1cc7-4e00-a0f7-beee4fc23797@github.com>

On Thu, 15 May 2025 16:23:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/ProblemList.txt
>>   
>>   Co-authored-by: Abhishek Kumar <abhishek.cx.kumar at oracle.com>
>
> test/jdk/java/awt/FileDialog/DoubleActionESC.java line 81:
> 
>> 79:                 robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
>> 80:                 robot.waitForIdle();
>> 81:                 robot.delay(1000);
> 
> Can the delay be reduced to `500`?

Yes, it can be reduced to 500 without impacting the behavior or changing the failure frequency

> test/jdk/java/awt/FileDialog/DoubleActionESC.java line 90:
> 
>> 88: 
>> 89:             latch.await(LATCH_TIMEOUT, SECONDS);
>> 90:             if (fd.isVisible()) {
> 
> I'm on the fence here? Calling `fd.isVisible()` on EDT is more reliable; but it's not strictly required for AWT components.

I have added it. However, as you assumed, it's not required for AWT components, so the test is still failing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2111958642
PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2111954795

From abaya at openjdk.org  Wed May 28 13:56:13 2025
From: abaya at openjdk.org (Anass Baya)
Date: Wed, 28 May 2025 13:56:13 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v6]
In-Reply-To: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
Message-ID: <FkJhH0XGFU8JX23kDFOeJmjOCtMmoyToCai2beXjp9o=.6637c8a1-7635-40b9-9515-cd3874f731a0@github.com>

> **Analysis :**
> 
> Whether the test passes on the main line or fails, the behavior is still incorrect.
> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly.
> 
> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt.
> 
> This causes the test to proceed immediately to the validation step:
> 
> if (fd.isVisible()) {
>     throw new RuntimeException("File Dialog is not closed");
> }
> 
> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet)
> 
> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation.
> 
> **Proposed fix:**
> 
> set the CountDownLatch to 2
> 
> **Proposed enhancements :**
> 
> Remove unnecessary threads (Thread and Thread-2)
> Properly handle delays and robot.waitForIdle()
> Avoid indefinite blocking on latch.await()
> 
> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds
> 
> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details

Anass Baya has updated the pull request incrementally with one additional commit since the last revision:

  Remove latch count assignment from the main

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25184/files
  - new: https://git.openjdk.org/jdk/pull/25184/files/c5718772..d686cda8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25184&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25184&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25184/head:pull/25184

PR: https://git.openjdk.org/jdk/pull/25184

From abaya at openjdk.org  Wed May 28 14:01:37 2025
From: abaya at openjdk.org (Anass Baya)
Date: Wed, 28 May 2025 14:01:37 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v7]
In-Reply-To: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
Message-ID: <fJq1jRsbK0Ej5jRN12toSx0akVb8UDnTeCArE6CCdss=.5e6ccbb8-bcf3-4a31-b2b0-ef74b1cae1be@github.com>

> **Analysis :**
> 
> Whether the test passes on the main line or fails, the behavior is still incorrect.
> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly.
> 
> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt.
> 
> This causes the test to proceed immediately to the validation step:
> 
> if (fd.isVisible()) {
>     throw new RuntimeException("File Dialog is not closed");
> }
> 
> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet)
> 
> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation.
> 
> **Proposed fix:**
> 
> set the CountDownLatch to 2
> 
> **Proposed enhancements :**
> 
> Remove unnecessary threads (Thread and Thread-2)
> Properly handle delays and robot.waitForIdle()
> Avoid indefinite blocking on latch.await()
> 
> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds
> 
> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details

Anass Baya has updated the pull request incrementally with one additional commit since the last revision:

  Throw exception if the Latch timeout is reached

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25184/files
  - new: https://git.openjdk.org/jdk/pull/25184/files/d686cda8..5d7644b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25184&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25184&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25184/head:pull/25184

PR: https://git.openjdk.org/jdk/pull/25184

From asemenov at openjdk.org  Wed May 28 15:28:58 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 28 May 2025 15:28:58 GMT
Subject: RFR: 8341311: [Accessibility, macOS,
 VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu [v2]
In-Reply-To: <4FutPE0d1Zw2D3INL_ZhNEmhv2F1I2cQ9ElGGvC1qq0=.9bcd49be-cbf2-4cb9-969a-6d73ee951a40@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
 <4FutPE0d1Zw2D3INL_ZhNEmhv2F1I2cQ9ElGGvC1qq0=.9bcd49be-cbf2-4cb9-969a-6d73ee951a40@github.com>
Message-ID: <FFMsPmRrB25QGkuicnQ_XWHT7fxnyBal0ox9MkA__00=.181d000b-0623-4beb-95c6-a82b0b1981e8@github.com>

On Wed, 28 May 2025 02:28:40 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver announce incorrect number of child for a submenu of JPopupMenu when it is visible for the first time only. After that VO is able to announce the number of items correctly.
>> 
>> Issue: Problem is with the a11y subsystem method call to get the accessible children details.
>> 
>> Analysis: When the Submenu of a JPopupMenu is opened, accessible component of PopupMenu is created dynamically in the native side implementation and `PostMenuOpened` notification is sent to the a11y subsystem for the newly created PopupMenu. Once the notification is sent to a11y sub-system, it invokes the `accessibilityChildren` method to get the children details for the menu component. A11y subsystem always retrieve the information of the root level PopupMenu irrespective of the submenu's PopupMenu (PopupMenu is associated with each JMenu) and thus announce the root level PopupMenu child count which is incorrect.
>> 
>> Proposed Fix: Proposed fix is to ensure the correct child details are sent back to a11y sub-system for correct announcement. So, whenever the `accessibilityChildren` method is invoked, first try to find out the current accessible PopupMenu which is opened for the Submenu and then return the child details.
>> 
>> Testing : Manual test case is attached to verify the fix and there is no failure with fix in CI pipeline.
>> 
>> `Current fix also ensures the correct child counts are announced for the JMenu's Submenu which are present in the JMenubar.`
>> 
>> **Note :** While verifying the fix, a new issue is unearthed for multi-level submenu where VO is failed to announce the Submenu's text. Since the issue exists without the proposed fix too, it shall be treated as a new bug finding and will raise a separate JBS issue.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor update

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 877:

> 875:         if (ac != null) {
> 876:             Accessible aComp = null;
> 877:             for (int i = 0; i < ac.getAccessibleChildrenCount(); i++) {

I suggest replacing for with while. If the desired submenu is at the beginning of the list, there?s no need to traverse it further.

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.m line 65:

> 63:     GET_CACCESSIBILITY_CLASS_RETURN(nil);
> 64:     DECLARE_STATIC_METHOD_RETURN(sjm_getCurrentAccessiblePopupMenu, sjc_CAccessibility,
> 65:             "getCurrentAccessiblePopupMenu",

Won?t it be possible to get the correct object like this, as it?s done in ```outlineRowAccessibility.m```?

jobject currentAccessible = [self currentAccessibleWithENV:env];

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25470#discussion_r2112139362
PR Review Comment: https://git.openjdk.org/jdk/pull/25470#discussion_r2112188590

From asemenov at openjdk.org  Wed May 28 15:33:51 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 28 May 2025 15:33:51 GMT
Subject: RFR: 8341311: [Accessibility, macOS,
 VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu [v2]
In-Reply-To: <-ik2Ehk-SMPAQCfVkToxWLiqC_3a7-LqJtkIRGfBaSc=.16a8a6c8-7d79-45ed-97cd-47ceb9853f9b@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
 <_sXctfl4hH0eURjW3o_R0DLJp03F6VPioRzxcJ93xRQ=.263c5f31-f5ed-4975-865f-11721a0bdc1a@github.com>
 <-ik2Ehk-SMPAQCfVkToxWLiqC_3a7-LqJtkIRGfBaSc=.16a8a6c8-7d79-45ed-97cd-47ceb9853f9b@github.com>
Message-ID: <EZJ45ohd6tXQ1mAgGDAs21axf3mm2mk1qimMf-WolIo=.ca282680-4360-46df-8f90-d19f6a0984bb@github.com>

On Wed, 28 May 2025 02:21:40 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> This test is only for macOS and that is conveyed through the jtreg tag [here](https://github.com/openjdk/jdk/blob/a225bf4bbe75aefffa63d54d2dff5577b3268339/test/jdk/javax/accessibility/TestPopupMenuChildCount.java#L36). I don't think test name needs to be changed.
> 
> Although it is not essentially required but will update the test summary and instruction.

It seems to me that this test should be generalized for all a11y platforms, since it is a regression test and can help identify regression of this functionality on other platforms.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25470#discussion_r2112200183

From honkar at openjdk.org  Wed May 28 16:31:52 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 28 May 2025 16:31:52 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java
In-Reply-To: <k3h3vEvdaausCje0R6QskmFOvaqBNb8q7fZvZHdftIg=.a9d85c09-ccd7-4b33-b43f-fe92eeb5a741@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
 <45KN4daBBRbauQz-o9yzcmdYpZmQJTzRJOrT1axLf8U=.db20c011-ced6-41c1-ae49-cfd190373ca7@github.com>
 <zwpkD7LsHwsi-ALKlT12mmopurQsWHLc6bVWfndwrLk=.8586b593-09b7-40d5-97b7-5b0b129b1bc6@github.com>
 <icxnrvZ3SZvVwQptHPyIuZyy4bvPStIcAPGM1Q2NTqM=.8159186e-1535-4be4-ba9c-681544fb1336@github.com>
 <jaR_MvuEioFBA6eE3Qe0Mmpnaa94eq56jTgXfkJKgjg=.f44a0a83-6d82-497f-9ace-b85d3de538f3@github.com>
 <gAEy7ej82lUVH91C8BPMu4FOhk78SV7ZITs3xZILKvo=.0bd12457-a3f1-4c33-8bb9-a14c6219f1e7@github.com>
 <k3h3vEvdaausCje0R6QskmFOvaqBNb8q7fZvZHdftIg=.a9d85c09-ccd7-4b33-b43f-fe92eeb5a741@github.com>
Message-ID: <ODZ2K0hEHfMiQ6O2-VdP7lS_7z1lS8fd07Wh0cyBGvE=.36c39bae-de19-46b2-b8fa-cf8ebd8bc483@github.com>

On Wed, 28 May 2025 12:35:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Re: expected=ff000000 actual=ffffffff ? I can't see a while pixel on the screenshot. 

This is screenshot of the frame when the test passes. Added it to show what the Frame looks like when the test passes.

> Does the test save both images: the expected and the actual one? 

No it doesn't. The updated test saves the frame and the whole screen (I wanted to see if there are any stray windows overlapping the test frame). Since I haven't gotten the test to fail on personal CI job, I thought it might be a good idea to de-problemlist the test and see what is going on.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2112309665

From aivanov at openjdk.org  Wed May 28 16:52:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 May 2025 16:52:52 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java
In-Reply-To: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
Message-ID: <007h3vC751kD1jOaYk_XAoK9SF3T-uolq0iDAPrfXbg=.9b1c60d9-14f1-460a-b0b8-b500501af278@github.com>

On Sat, 17 May 2025 00:03:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs.
> 
> Test failure is not reproducible when the test is run individually (multiple times) on CI.
> 
> Rewritten the test and added debug logs that will be helpful to figure out the issue. 
> 
> - Added code to capture screenshot (entire screen as well as the frame) in case of failure.
> - Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException.

test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 67:

> 65:                 Point pt1 = frame.getLocationOnScreen();
> 66:                 Rectangle rect = new Rectangle(pt1.x, pt1.y, 400, 400);
> 67:                 captureImg = robot.createScreenCapture(rect);

~~The captured image includes the frame decorations.~~ I see the frame is not decorated. Yet, the suggestion still applies.

You can use the location and the size of the canvas itself as the area to capture. For simplicity, save the canvas instance into a static variable.

I'd avoid hard-coding the width and height like this; constants would be serve the purpose, and if either width or height, or both, changes, all the code automatically updates to use the new values.

test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 114:

> 112:         // destination surface
> 113:         g2d.copyArea(0, 10, 50, h - 10, 60, 10);
> 114:         g2d.dispose();

Why do you disposed of `g2d`? It's a parameter that's passed to you as argument to the `paint` method.

test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 147:

> 145:                 .getLocalGraphicsEnvironment().getDefaultScreenDevice()
> 146:                 .getDefaultConfiguration();
> 147:         BufferedImage screenCapture = robot.createScreenCapture(ge.getBounds());

Using a multi-resolution screen capture could shed some light on failures? If Mac uses a Retina-like display, the captured image is scaled down, which affects the colors on the image.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2112341094
PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2112326767
PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2112330528

From aivanov at openjdk.org  Wed May 28 16:52:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 May 2025 16:52:54 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java
In-Reply-To: <ODZ2K0hEHfMiQ6O2-VdP7lS_7z1lS8fd07Wh0cyBGvE=.36c39bae-de19-46b2-b8fa-cf8ebd8bc483@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
 <45KN4daBBRbauQz-o9yzcmdYpZmQJTzRJOrT1axLf8U=.db20c011-ced6-41c1-ae49-cfd190373ca7@github.com>
 <zwpkD7LsHwsi-ALKlT12mmopurQsWHLc6bVWfndwrLk=.8586b593-09b7-40d5-97b7-5b0b129b1bc6@github.com>
 <icxnrvZ3SZvVwQptHPyIuZyy4bvPStIcAPGM1Q2NTqM=.8159186e-1535-4be4-ba9c-681544fb1336@github.com>
 <jaR_MvuEioFBA6eE3Qe0Mmpnaa94eq56jTgXfkJKgjg=.f44a0a83-6d82-497f-9ace-b85d3de538f3@github.com>
 <gAEy7ej82lUVH91C8BPMu4FOhk78SV7ZITs3xZILKvo=.0bd12457-a3f1-4c33-8bb9-a14c6219f1e7@github.com>
 <k3h3vEvdaausCje0R6QskmFOvaqBNb8q7fZvZHdftIg=.a9d85c09-ccd7-4b33-b43f-fe92eeb5a741@github.com>
 <ODZ2K0hEHfMiQ6O2-VdP7lS_7z1lS8fd07Wh0cyBGvE=.36c39bae-de19-46b2-b8fa-cf8ebd8bc483@github.com>
Message-ID: <8IxUcx9JeMootKUwgQgOxmi1Hd-G6YMUuIC3E94DPX0=.ab1abd09-5455-495a-a605-4a1990d86207@github.com>

On Wed, 28 May 2025 16:29:35 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> > Does the test save both images: the expected and the actual one?
> 
> No it doesn't. The updated test saves the frame and the whole screen (I wanted to see if there are any stray windows overlapping the test frame). Since I haven't gotten the test to fail on personal CI job, I thought it might be a good idea to de-problemlist the test and see what is going on.

You can test it by submitting a test job without integrating these changes.

You can do it with the test in its original form where the UI is created on the main thread rather than EDT.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2112343628

From honkar at openjdk.org  Wed May 28 18:08:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 28 May 2025 18:08:53 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java
In-Reply-To: <8IxUcx9JeMootKUwgQgOxmi1Hd-G6YMUuIC3E94DPX0=.ab1abd09-5455-495a-a605-4a1990d86207@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
 <45KN4daBBRbauQz-o9yzcmdYpZmQJTzRJOrT1axLf8U=.db20c011-ced6-41c1-ae49-cfd190373ca7@github.com>
 <zwpkD7LsHwsi-ALKlT12mmopurQsWHLc6bVWfndwrLk=.8586b593-09b7-40d5-97b7-5b0b129b1bc6@github.com>
 <icxnrvZ3SZvVwQptHPyIuZyy4bvPStIcAPGM1Q2NTqM=.8159186e-1535-4be4-ba9c-681544fb1336@github.com>
 <jaR_MvuEioFBA6eE3Qe0Mmpnaa94eq56jTgXfkJKgjg=.f44a0a83-6d82-497f-9ace-b85d3de538f3@github.com>
 <gAEy7ej82lUVH91C8BPMu4FOhk78SV7ZITs3xZILKvo=.0bd12457-a3f1-4c33-8bb9-a14c6219f1e7@github.com>
 <k3h3vEvdaausCje0R6QskmFOvaqBNb8q7fZvZHdftIg=.a9d85c09-ccd7-4b33-b43f-fe92eeb5a741@github.com>
 <ODZ2K0hEHfMiQ6O2-VdP7lS_7z1lS8fd07Wh0cyBGvE=.36c39bae-de19-46b2-b8fa-cf8ebd8bc483@github.com>
 <8IxUcx9JeMootKUwgQgOxmi1Hd-G6YMUuIC3E94DPX0=.ab1abd09-5455-495a-a605-4a1990d86207@github.com>
Message-ID: <xWUzK--7yE4ntc5dv4dMX5wZ0Mi-y9pfoAdhb_szh-k=.a88106f1-70fd-4297-8736-4bae530e24f9@github.com>

On Wed, 28 May 2025 16:47:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Re: expected=ff000000 actual=ffffffff ? I can't see a while pixel on the screenshot. 
>> 
>> This is screenshot of the frame when the test passes. Added it to show what the Frame looks like when the test passes.
>> 
>>> Does the test save both images: the expected and the actual one? 
>> 
>> No it doesn't. The updated test saves the frame and the whole screen (I wanted to see if there are any stray windows overlapping the test frame). Since I haven't gotten the test to fail on personal CI job, I thought it might be a good idea to de-problemlist the test and see what is going on.
>
>> > Does the test save both images: the expected and the actual one?
>> 
>> No it doesn't. The updated test saves the frame and the whole screen (I wanted to see if there are any stray windows overlapping the test frame). Since I haven't gotten the test to fail on personal CI job, I thought it might be a good idea to de-problemlist the test and see what is going on.
> 
> You can test it by submitting a test job without integrating these changes.
> 
> You can do it with the test in its original form where the UI is created on the main thread rather than EDT.

The personal CI job that was referring to was with the original test + screenshot capture. IIRC it did not fail during those runs. I have triggered another round of testing with original test + MultiResolution screen capture as suggested to see if the test failure is reproducible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2112475497

From prr at openjdk.org  Wed May 28 20:07:33 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 May 2025 20:07:33 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v14]
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <-Tq2lspXz6bsSzTFYwvE2A9Hg1_e6o8ggKZ49JaFMOU=.92145686-50b0-49ed-aaef-6c8e4106019c@github.com>

> A simple API to replace java.applet.AudioClip
> 
> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8356049

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24991/files
  - new: https://git.openjdk.org/jdk/pull/24991/files/58649f22..f654b89c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24991&range=12-13

  Stats: 105 lines in 1 file changed: 105 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24991/head:pull/24991

PR: https://git.openjdk.org/jdk/pull/24991

From prr at openjdk.org  Wed May 28 20:07:33 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 May 2025 20:07:33 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v10]
In-Reply-To: <hl0ZjpPuV7rSw0ljHiSXNQIbFt4FHrv_DHFg5h20g1E=.f332eaff-c4ae-4b3a-a594-7f863db83e40@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <lSJejgcB_mZzWCbMR0fZfb-5n49Njlu3A9dztyfDO-s=.7967740d-1e43-47e1-8a5d-3bab8786bb9a@github.com>
 <9Oco8sXX2wF_26udEZoISllR58JH5Qs1m22_UDdXK78=.465a992c-4304-4f23-944e-ca67203393d3@github.com>
 <LefVaWAeoNVS5ywzjxQakFN0zH3fDoJSaR6eeM3N--U=.bdff8200-41de-4487-af2e-430083f5dc0b@github.com>
 <hl0ZjpPuV7rSw0ljHiSXNQIbFt4FHrv_DHFg5h20g1E=.f332eaff-c4ae-4b3a-a594-7f863db83e40@github.com>
Message-ID: <5lFY0yxbxX5NRZBXZ2GoBjLd2tGRbmGhQaBJLxik_Wk=.8f07b625-f737-4e77-8926-44021e0c1f77@github.com>

On Tue, 27 May 2025 22:25:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Do you mean show that calling loop() doesn't prevent exit ? I can just add a call to loop() at the end of the test. If it doesn't terminate the test will fail with a timeout.
> 
> jtreg terminates all threads and the test vm after the main method completes, so I believe the updated test would pass even before this change (when a non-daemon thread was used).

That's difficult to do in this test. In fact it is a problem to do in any jtreg test. It needs another process.
So I've added a new test that monitors a child VM that jtreg will not terminate in this way.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2917474894

From prr at openjdk.org  Wed May 28 20:24:03 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 May 2025 20:24:03 GMT
Subject: RFR: 8357672: Extreme font sizes can cause font substitution
Message-ID: <imS2Qz_axrs-7PXyPFbW52X1aG0ToIcW1zztWP3eB90=.f0398502-dd47-4545-a9c3-c23f6ea7e679@github.com>

Instrumenting the existing ExtremeFontSizeTest.java, it was noted that the freetype code, when encountering a null return from getting a scaler context, would over-interpret this as a bad font.
The test was intended to check this wasn't happening by verifying metrics before and after using extreme sizes.
But the scenaro was not being detected by the test because a replacement font was substituted and it did not have zero metrics.
So the updated test checks that the metrics before and after are the same.
This new version of the test failed on Linux before the JDK source updates and passes afterwards.

-------------

Commit messages:
 - 8357672
 - 8357672

Changes: https://git.openjdk.org/jdk/pull/25511/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25511&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357672
  Stats: 104 lines in 3 files changed: 92 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25511.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25511/head:pull/25511

PR: https://git.openjdk.org/jdk/pull/25511

From dgredler at openjdk.org  Wed May 28 20:27:54 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 28 May 2025 20:27:54 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377
In-Reply-To: <o-RfCz8vaxQpRihpmsKQakcsMJTVoxh2tE1sQcM1rYI=.3b80a35f-ed45-4558-a88d-4b6d51ad4ef0@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
 <qAXldHcR9uja7Lnj-LCAkQvYUqcxsbc0LXC7pS6gsmo=.41fd8ffb-bee5-4358-a4ff-b86c7fd6bb5e@github.com>
 <7qRLx0aLwArI3Md49dSXjXVR_aqNzSfRWCo-59TcyYo=.e75861cf-bd30-4118-ab4b-53e6fe86b8f8@github.com>
 <o-RfCz8vaxQpRihpmsKQakcsMJTVoxh2tE1sQcM1rYI=.3b80a35f-ed45-4558-a88d-4b6d51ad4ef0@github.com>
Message-ID: <yhi-ey0BSjzpDd9AetSugVTAfS79UEPSsVgByqxSRYY=.3f6bcb5e-0d22-4b32-8b79-cb64b10d6686@github.com>

On Mon, 26 May 2025 23:44:34 GMT, Phil Race <prr at openjdk.org> wrote:

>>> @YaaZ Thanks for the information!
>>> 
>>> @prrace Have you had a chance to look at this PR?
>> 
>> It passed all the testing I did. I still need to look hard at the changes.
>
>> @prrace Please don't approve yet. I was able to fix the code conflicts caused by PR #23665, but it looks like the logic does not layer nicely as there is now a test failure on macOS after the merge. I'm having a look and will let you know what I find.
> 
> And indeed the tests just finished and a test (not the new one, a previous one : IgnoredWhitespaceTest.java) failed on macOS x64 and ARM ..
> 
> java.lang.RuntimeException: for text '\t\t\t\t\tXXXXX' with font java.awt.Font[family=Dialog,name=Dialog,style=plain,size=40]: java.awt.Rectangle[x=300,y=271,width=123,height=28] != java.awt.Rectangle[x=365,y=271,width=123,height=28]
> 	at IgnoredWhitespaceTest.assertEqual(IgnoredWhitespaceTest.java:127)
> 	at IgnoredWhitespaceTest.test(IgnoredWhitespaceTest.java:103)
> 	at IgnoredWhitespaceTest.test(IgnoredWhitespaceTest.java:69)
> 	at IgnoredWhitespaceTest.main(IgnoredWhitespaceTest.java:49)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> 	at java.base/java.lang.Thread.run(Thread.java:1447)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException: for text '\t\t\t\t\tXXXXX' with font java.awt.Font[family=Dialog,name=Dialog,style=plain,size=40]: java.awt.Rectangle[x=300,y=271,width=123,height=28] != java.awt.Rectangle[x=365,y=271,width=123,height=28]
> JavaTest Message: shutting down test

@prrace This is ready for review again. I've updated the code to combine nicely with the recent whitespace fixes. The `test/jdk/java/awt/font`, `test/jdk/java/awt/print` and `test/jdk/java/awt/Graphics2D/DrawString` tests all pass for me locally on Windows, Linux and macOS.

Once these changes are integrated it should be relatively simple to address JDK-8356803 ("Test TextLayout/TestControls fails on windows & linux: line and paragraph separator show non-zero advance") and JDK-8356812 ("Create an automated version of TextLayout/TestControls").

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24412#issuecomment-2917521742

From prr at openjdk.org  Wed May 28 20:55:03 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 May 2025 20:55:03 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
 <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>
Message-ID: <Dq8Agr8pnvykN7oNGPzTQnNO77rhD_M8j1caxF-mY4M=.867b19b6-ce18-4656-b52b-4fd5ec84d834@github.com>

On Mon, 26 May 2025 07:55:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore MenuShortcut.java
>>  - Restore LocaleDataTest.java
>
> test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java line 90:
> 
>> 88:                 printKey(e);
>> 89:                 int keychar = e.getKeyChar();
>> 90:                 if (keychar == 27) { // Escape character is 27 or \u001b
> 
> @prrace I think this is an actual bug. `\u0021` codes to `!`, and I don't think that is what was meant. Do you still want me to revert it?

You are right, that's a typo. Keep your change.
And I don't know why the code uses literal 27 instead of KeyEvent.VK_ESCAPE .. but that's not your problem.

https://docs.oracle.com/en/java/javase/21/docs/api/constant-values.html#java.awt.event.KeyEvent.VK_ESCAPE

> test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java line 188:
> 
>> 186:                     +          "\"After\" lists.\n"
>> 187:                     + "              Added printers are highlighted with "
>> 188:                     +               "green color, removed ones \u2014 with "
> 
> @prrace This too seems like a bug, or rather a typo. The text currently reads `Added printers are highlighted with green color, removed ones ? with red color.`. The Em dash does not make any sense to me, and seems to be a copy paste error.
> 
> Do you still want me to revert it?

I agree. Keep your change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112722311
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112731040

From prr at openjdk.org  Wed May 28 20:55:04 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 May 2025 20:55:04 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>
 <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>
Message-ID: <BW-jmv0CMo_qRngDZcLpY3s8yH_WYkD_YyhGiDyDeVU=.5292f832-a0ab-4a8f-9792-6c8005697e45@github.com>

On Mon, 26 May 2025 08:07:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:
>> 
>>> 61: 
>>> 62:     private static final String INSTRUCTIONS =
>>> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "
>> 
>> I really don't like these tests being changed. It isn't part of the JDK build.
>> People compile these in all sorts of locales.
>> Please revert all the changes in the client tests.
>
> Just a clarification. What I did was convert curly quotes and an em dash to normal ASCII quotes and an ASCII hyphen, just as it is in all other `INSTRUCTIONS` in the tests. This is similar to what was done in JDK-8354273 and JDK-8354213, and should have been made as part of those PRs if I only had noticed this place by then.
> 
> The user's locale should not really matter. When have stringent locale requirements for building, and automatically setup the correct locale while building. I don't think the locale will matter at runtime either, but it n the rare case that it should matter, then pure ASCII would be prefer, wouldn't it?
> 
> Let me know if you still want me to revert it.

I'd like this reverted.
People *build* these tests in their local repos using javac and whatever their locale is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112728971

From serb at openjdk.org  Wed May 28 22:35:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 28 May 2025 22:35:58 GMT
Subject: RFR: 8356049: Need a simple way to play back a sound clip [v14]
In-Reply-To: <-Tq2lspXz6bsSzTFYwvE2A9Hg1_e6o8ggKZ49JaFMOU=.92145686-50b0-49ed-aaef-6c8e4106019c@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
 <-Tq2lspXz6bsSzTFYwvE2A9Hg1_e6o8ggKZ49JaFMOU=.92145686-50b0-49ed-aaef-6c8e4106019c@github.com>
Message-ID: <OBjWpbXnQatpbUOxA26qns2dyLsWQDGDNU3sYA3-Ndo=.bba0bc25-1e78-4654-bb4f-05326d60c5ef@github.com>

On Wed, 28 May 2025 20:07:33 GMT, Phil Race <prr at openjdk.org> wrote:

>> A simple API to replace java.applet.AudioClip
>> 
>> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356049

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24991#pullrequestreview-2876621898

From honkar at openjdk.org  Thu May 29 00:22:13 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 29 May 2025 00:22:13 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java [v2]
In-Reply-To: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
Message-ID: <bm4VjlGJJwFiUgOVw23IOoWf44yfdmFVgM31InwjFas=.2ba5dc82-de69-4c1f-93d5-ce68ea2da171@github.com>

> CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs.
> 
> Test failure is not reproducible when the test is run individually (multiple times) on CI.
> 
> Rewritten the test and added debug logs that will be helpful to figure out the issue. 
> 
> - Added code to capture screenshot (entire screen as well as the frame) in case of failure.
> - Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  test update: Mouse move to off frame loc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25279/files
  - new: https://git.openjdk.org/jdk/pull/25279/files/ee307064..8cc8fa24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25279&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25279&range=00-01

  Stats: 32 lines in 1 file changed: 20 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/25279.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25279/head:pull/25279

PR: https://git.openjdk.org/jdk/pull/25279

From honkar at openjdk.org  Thu May 29 00:37:52 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 29 May 2025 00:37:52 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java [v2]
In-Reply-To: <bm4VjlGJJwFiUgOVw23IOoWf44yfdmFVgM31InwjFas=.2ba5dc82-de69-4c1f-93d5-ce68ea2da171@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
 <bm4VjlGJJwFiUgOVw23IOoWf44yfdmFVgM31InwjFas=.2ba5dc82-de69-4c1f-93d5-ce68ea2da171@github.com>
Message-ID: <GpKG0gY6a1Fm_LnuKo6yHuIBfBmTBrCTkzb1dr4Fnp4=.5eecfb86-9479-4b07-8a53-45e56c8e3646@github.com>

On Thu, 29 May 2025 00:22:13 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs.
>> 
>> Test failure is not reproducible when the test is run individually (multiple times) on CI.
>> 
>> Rewritten the test and added debug logs that will be helpful to figure out the issue. 
>> 
>> - Added code to capture screenshot (entire screen as well as the frame) in case of failure.
>> - Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test update: Mouse move to off frame loc

@mrserb @aivanov-jdk 

I got the test to fail after some iterations. The issue is with the mouse pointer being at the place where robot.getRGB() is called as seen below. The fix is to move the mouse pointer to a location away from the test UI before taking a screenshot.

This happens on macos-aarch64 and I think the mouse pointer remains at the location last moved to by previous test (It explains why it happens only when certain tests run before it during entire test suite run and not when the test is run individually).
I'm still not sure as to why the mouse pointer is captured during screencapture on macos-aarch64 as I don't see it happening on macosx-x64.

<img src="https://github.com/user-attachments/assets/081780c5-3d88-48b3-86b5-10ed9d4a0114" alt="background" width="200" height="200">

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25279#issuecomment-2917904917

From honkar at openjdk.org  Thu May 29 00:37:54 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 29 May 2025 00:37:54 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java [v2]
In-Reply-To: <007h3vC751kD1jOaYk_XAoK9SF3T-uolq0iDAPrfXbg=.9b1c60d9-14f1-460a-b0b8-b500501af278@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
 <007h3vC751kD1jOaYk_XAoK9SF3T-uolq0iDAPrfXbg=.9b1c60d9-14f1-460a-b0b8-b500501af278@github.com>
Message-ID: <Opqw4IOO28Ismwt5VJe4cBRNGEFGwEOqqmAOALr62Wo=.33ed9d3f-1f0b-48a0-acd1-c5fa66315380@github.com>

On Wed, 28 May 2025 16:46:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test update: Mouse move to off frame loc
>
> test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 67:
> 
>> 65:                 Point pt1 = frame.getLocationOnScreen();
>> 66:                 Rectangle rect = new Rectangle(pt1.x, pt1.y, 400, 400);
>> 67:                 captureImg = robot.createScreenCapture(rect);
> 
> ~~The captured image includes the frame decorations.~~ I see the frame is not decorated. Yet, the suggestion still applies.
> 
> You can use the location and the size of the canvas itself as the area to capture. For simplicity, save the canvas instance into a static variable.
> 
> I'd avoid hard-coding the width and height like this; constants would be serve the purpose, and if either width or height, or both, changes, all the code automatically updates to use the new values.

Updated

> test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 147:
> 
>> 145:                 .getLocalGraphicsEnvironment().getDefaultScreenDevice()
>> 146:                 .getDefaultConfiguration();
>> 147:         BufferedImage screenCapture = robot.createScreenCapture(ge.getBounds());
> 
> Using a multi-resolution screen capture could shed some light on failures? If Mac uses a Retina-like display, the captured image is scaled down, which affects the colors on the image.

Updated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2112965381
PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2112965528

From honkar at openjdk.org  Thu May 29 01:47:47 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 29 May 2025 01:47:47 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java [v3]
In-Reply-To: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
Message-ID: <-lBIVrQXyxII4hEx6bRTJaM9dtFYWTgu7ULBFS-5kOQ=.a653a92e-702d-48d2-b6fa-50d134d4996d@github.com>

> CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs.
> 
> Test failure is not reproducible when the test is run individually (multiple times) on CI.
> 
> Rewritten the test and added debug logs that will be helpful to figure out the issue. 
> 
> - Added code to capture screenshot (entire screen as well as the frame) in case of failure.
> - Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  minor update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25279/files
  - new: https://git.openjdk.org/jdk/pull/25279/files/8cc8fa24..707ed6df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25279&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25279&range=01-02

  Stats: 12 lines in 1 file changed: 6 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25279.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25279/head:pull/25279

PR: https://git.openjdk.org/jdk/pull/25279

From prr at openjdk.org  Thu May 29 05:55:06 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 29 May 2025 05:55:06 GMT
Subject: Integrated: 8356049: Need a simple way to play back a sound clip
In-Reply-To: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
References: <oJrDcYjHhlZRNh2bsQlxGvDWaBdrDFnCl-PqC59UAwA=.7d48bf35-2e27-43b9-8230-1abf7c400104@github.com>
Message-ID: <hzSFpcdMEeWoY3URokMkHG_ZS8ZKWR76-Csd2KNNnbU=.7fa48052-9331-4a61-bf76-47e061831130@github.com>

On Thu, 1 May 2025 22:31:32 GMT, Phil Race <prr at openjdk.org> wrote:

> A simple API to replace java.applet.AudioClip
> 
> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200

This pull request has now been integrated.

Changeset: 04e0fe00
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/04e0fe00abcf1d7919a50e0c9dd44ce2856984ea
Stats:     497 lines in 9 files changed: 486 ins; 1 del; 10 mod

8356049: Need a simple way to play back a sound clip

Reviewed-by: serb, aivanov, kizune

-------------

PR: https://git.openjdk.org/jdk/pull/24991

From abhiscxk at openjdk.org  Thu May 29 06:19:51 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 29 May 2025 06:19:51 GMT
Subject: RFR: 8341311: [Accessibility, macOS,
 VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu [v2]
In-Reply-To: <FFMsPmRrB25QGkuicnQ_XWHT7fxnyBal0ox9MkA__00=.181d000b-0623-4beb-95c6-a82b0b1981e8@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
 <4FutPE0d1Zw2D3INL_ZhNEmhv2F1I2cQ9ElGGvC1qq0=.9bcd49be-cbf2-4cb9-969a-6d73ee951a40@github.com>
 <FFMsPmRrB25QGkuicnQ_XWHT7fxnyBal0ox9MkA__00=.181d000b-0623-4beb-95c6-a82b0b1981e8@github.com>
Message-ID: <JP9Zz-Pob7dZ2FV8H5w2YicKb6pUg2XFxqdQnpJvLgs=.42ac8632-36df-4068-b470-e58cf72e16b3@github.com>

On Wed, 28 May 2025 15:25:40 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor update
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.m line 65:
> 
>> 63:     GET_CACCESSIBILITY_CLASS_RETURN(nil);
>> 64:     DECLARE_STATIC_METHOD_RETURN(sjm_getCurrentAccessiblePopupMenu, sjc_CAccessibility,
>> 65:             "getCurrentAccessiblePopupMenu",
> 
> Won?t it be possible to get the correct object like this, as it?s done in ```outlineRowAccessibility.m```?
> 
> jobject currentAccessible = [self currentAccessibleWithENV:env];

I tried to utilize this method but `getCurrentAccessiblePopupMenu ` throws NPE.
`java.lang.NullPointerException: Cannot invoke "sun.swing.SwingAccessor$AccessibleComponentAccessor.getCurrentAccessible(javax.accessibility.AccessibleContext)" because the return value of "sun.swing.SwingAccessor.getAccessibleComponentAccessor()" is null`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25470#discussion_r2113286295

From abhiscxk at openjdk.org  Thu May 29 06:35:51 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 29 May 2025 06:35:51 GMT
Subject: RFR: 8341311: [Accessibility, macOS,
 VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu [v2]
In-Reply-To: <FFMsPmRrB25QGkuicnQ_XWHT7fxnyBal0ox9MkA__00=.181d000b-0623-4beb-95c6-a82b0b1981e8@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
 <4FutPE0d1Zw2D3INL_ZhNEmhv2F1I2cQ9ElGGvC1qq0=.9bcd49be-cbf2-4cb9-969a-6d73ee951a40@github.com>
 <FFMsPmRrB25QGkuicnQ_XWHT7fxnyBal0ox9MkA__00=.181d000b-0623-4beb-95c6-a82b0b1981e8@github.com>
Message-ID: <EqGZkkQHWFvc0cY1xkq-rwsR95x7IaETSd_UisaH86s=.eeebac2d-7473-4ef7-b463-57fffbea539c@github.com>

On Wed, 28 May 2025 15:01:47 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor update
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 877:
> 
>> 875:         if (ac != null) {
>> 876:             Accessible aComp = null;
>> 877:             for (int i = 0; i < ac.getAccessibleChildrenCount(); i++) {
> 
> I suggest replacing for with while. If the desired submenu is at the beginning of the list, there?s no need to traverse it further.

I think even though the submenu is at the beginning but if it is not visible then we need to traverse further to check for other submenu if present.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25470#discussion_r2113306623

From abhiscxk at openjdk.org  Thu May 29 07:03:58 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 29 May 2025 07:03:58 GMT
Subject: RFR: 8341311: [Accessibility, macOS,
 VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu [v3]
In-Reply-To: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
Message-ID: <xMzFldszd76f1p5RCDnTP-DZNBOmO1X4jQsWasiMMq8=.a51a8ff4-7ec6-47f2-a66f-5674601405d3@github.com>

> VoiceOver announce incorrect number of child for a submenu of JPopupMenu when it is visible for the first time only. After that VO is able to announce the number of items correctly.
> 
> Issue: Problem is with the a11y subsystem method call to get the accessible children details.
> 
> Analysis: When the Submenu of a JPopupMenu is opened, accessible component of PopupMenu is created dynamically in the native side implementation and `PostMenuOpened` notification is sent to the a11y subsystem for the newly created PopupMenu. Once the notification is sent to a11y sub-system, it invokes the `accessibilityChildren` method to get the children details for the menu component. A11y subsystem always retrieve the information of the root level PopupMenu irrespective of the submenu's PopupMenu (PopupMenu is associated with each JMenu) and thus announce the root level PopupMenu child count which is incorrect.
> 
> Proposed Fix: Proposed fix is to ensure the correct child details are sent back to a11y sub-system for correct announcement. So, whenever the `accessibilityChildren` method is invoked, first try to find out the current accessible PopupMenu which is opened for the Submenu and then return the child details.
> 
> Testing : Manual test case is attached to verify the fix and there is no failure with fix in CI pipeline.
> 
> `Current fix also ensures the correct child counts are announced for the JMenu's Submenu which are present in the JMenubar.`
> 
> **Note :** While verifying the fix, a new issue is unearthed for multi-level submenu where VO is failed to announce the Submenu's text. Since the issue exists without the proposed fix too, it shall be treated as a new bug finding and will raise a separate JBS issue.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  code optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25470/files
  - new: https://git.openjdk.org/jdk/pull/25470/files/6cebdff4..0984d036

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25470&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25470&range=01-02

  Stats: 10 lines in 1 file changed: 1 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25470/head:pull/25470

PR: https://git.openjdk.org/jdk/pull/25470

From abhiscxk at openjdk.org  Thu May 29 07:03:59 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 29 May 2025 07:03:59 GMT
Subject: RFR: 8341311: [Accessibility, macOS,
 VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu [v2]
In-Reply-To: <EqGZkkQHWFvc0cY1xkq-rwsR95x7IaETSd_UisaH86s=.eeebac2d-7473-4ef7-b463-57fffbea539c@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
 <4FutPE0d1Zw2D3INL_ZhNEmhv2F1I2cQ9ElGGvC1qq0=.9bcd49be-cbf2-4cb9-969a-6d73ee951a40@github.com>
 <FFMsPmRrB25QGkuicnQ_XWHT7fxnyBal0ox9MkA__00=.181d000b-0623-4beb-95c6-a82b0b1981e8@github.com>
 <EqGZkkQHWFvc0cY1xkq-rwsR95x7IaETSd_UisaH86s=.eeebac2d-7473-4ef7-b463-57fffbea539c@github.com>
Message-ID: <BpMTELEJbwMSVeeOEjegLmrPl0K1lwh4MmbuQCuFejo=.7d6e5a2b-1ec1-4885-9eaf-ffb75aef93d3@github.com>

On Thu, 29 May 2025 06:33:37 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 877:
>> 
>>> 875:         if (ac != null) {
>>> 876:             Accessible aComp = null;
>>> 877:             for (int i = 0; i < ac.getAccessibleChildrenCount(); i++) {
>> 
>> I suggest replacing for with while. If the desired submenu is at the beginning of the list, there?s no need to traverse it further.
>
> I think even though the submenu is at the beginning but if it is not visible then we need to traverse further to check for other submenu if present.

Optimized the code to not traverse further if the desired submenu is fetched. Verified the recent change with the test code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25470#discussion_r2113344471

From asemenov at openjdk.org  Thu May 29 07:21:53 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 29 May 2025 07:21:53 GMT
Subject: RFR: 8341311: [Accessibility, macOS,
 VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu [v2]
In-Reply-To: <BpMTELEJbwMSVeeOEjegLmrPl0K1lwh4MmbuQCuFejo=.7d6e5a2b-1ec1-4885-9eaf-ffb75aef93d3@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
 <4FutPE0d1Zw2D3INL_ZhNEmhv2F1I2cQ9ElGGvC1qq0=.9bcd49be-cbf2-4cb9-969a-6d73ee951a40@github.com>
 <FFMsPmRrB25QGkuicnQ_XWHT7fxnyBal0ox9MkA__00=.181d000b-0623-4beb-95c6-a82b0b1981e8@github.com>
 <EqGZkkQHWFvc0cY1xkq-rwsR95x7IaETSd_UisaH86s=.eeebac2d-7473-4ef7-b463-57fffbea539c@github.com>
 <BpMTELEJbwMSVeeOEjegLmrPl0K1lwh4MmbuQCuFejo=.7d6e5a2b-1ec1-4885-9eaf-ffb75aef93d3@github.com>
Message-ID: <igg4_EKl61Xp_IspW6QtqD0Dg1zUjlP337On4oFRpr8=.eea72c4e-3132-4c08-80f4-7c347dce6347@github.com>

On Thu, 29 May 2025 07:00:34 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Optimized the code to not traverse further if the desired submenu is fetched. Verified the recent change with the test code.

You could, of course, put this in the while condition, but this way is also fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25470#discussion_r2113370915

From asemenov at openjdk.org  Thu May 29 07:24:51 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 29 May 2025 07:24:51 GMT
Subject: RFR: 8341311: [Accessibility, macOS,
 VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu [v3]
In-Reply-To: <xMzFldszd76f1p5RCDnTP-DZNBOmO1X4jQsWasiMMq8=.a51a8ff4-7ec6-47f2-a66f-5674601405d3@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
 <xMzFldszd76f1p5RCDnTP-DZNBOmO1X4jQsWasiMMq8=.a51a8ff4-7ec6-47f2-a66f-5674601405d3@github.com>
Message-ID: <PdVAW-wtCO1KCNyIXj73fcKy-qjn4K_IcyoLxoFS7Z8=.16773725-51cb-4cc1-92f3-a85150fbafc0@github.com>

On Thu, 29 May 2025 07:03:58 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver announce incorrect number of child for a submenu of JPopupMenu when it is visible for the first time only. After that VO is able to announce the number of items correctly.
>> 
>> Issue: Problem is with the a11y subsystem method call to get the accessible children details.
>> 
>> Analysis: When the Submenu of a JPopupMenu is opened, accessible component of PopupMenu is created dynamically in the native side implementation and `PostMenuOpened` notification is sent to the a11y subsystem for the newly created PopupMenu. Once the notification is sent to a11y sub-system, it invokes the `accessibilityChildren` method to get the children details for the menu component. A11y subsystem always retrieve the information of the root level PopupMenu irrespective of the submenu's PopupMenu (PopupMenu is associated with each JMenu) and thus announce the root level PopupMenu child count which is incorrect.
>> 
>> Proposed Fix: Proposed fix is to ensure the correct child details are sent back to a11y sub-system for correct announcement. So, whenever the `accessibilityChildren` method is invoked, first try to find out the current accessible PopupMenu which is opened for the Submenu and then return the child details.
>> 
>> Testing : Manual test case is attached to verify the fix and there is no failure with fix in CI pipeline.
>> 
>> `Current fix also ensures the correct child counts are announced for the JMenu's Submenu which are present in the JMenubar.`
>> 
>> **Note :** While verifying the fix, a new issue is unearthed for multi-level submenu where VO is failed to announce the Submenu's text. Since the issue exists without the proposed fix too, it shall be treated as a new bug finding and will raise a separate JBS issue.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code optimization

LGTM

-------------

Marked as reviewed by asemenov (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25470#pullrequestreview-2877352903

From abhiscxk at openjdk.org  Thu May 29 08:27:53 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 29 May 2025 08:27:53 GMT
Subject: RFR: 8341311: [Accessibility, macOS,
 VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu [v3]
In-Reply-To: <EZJ45ohd6tXQ1mAgGDAs21axf3mm2mk1qimMf-WolIo=.ca282680-4360-46df-8f90-d19f6a0984bb@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
 <_sXctfl4hH0eURjW3o_R0DLJp03F6VPioRzxcJ93xRQ=.263c5f31-f5ed-4975-865f-11721a0bdc1a@github.com>
 <-ik2Ehk-SMPAQCfVkToxWLiqC_3a7-LqJtkIRGfBaSc=.16a8a6c8-7d79-45ed-97cd-47ceb9853f9b@github.com>
 <EZJ45ohd6tXQ1mAgGDAs21axf3mm2mk1qimMf-WolIo=.ca282680-4360-46df-8f90-d19f6a0984bb@github.com>
Message-ID: <1-3uZy9W3whv_ah6Iwwn5qOGd5yj4j5gOk1_Is0ILIg=.84a16f1e-f2a5-411f-a907-e525e7c31a71@github.com>

On Wed, 28 May 2025 15:31:15 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> This test is only for macOS and that is conveyed through the jtreg tag [here](https://github.com/openjdk/jdk/blob/a225bf4bbe75aefffa63d54d2dff5577b3268339/test/jdk/javax/accessibility/TestPopupMenuChildCount.java#L36). I don't think test name needs to be changed.
>> 
>> Although it is not essentially required but will update the test summary and instruction.
>
>> This test is only for macOS and that is conveyed through the jtreg tag [here](https://github.com/openjdk/jdk/blob/a225bf4bbe75aefffa63d54d2dff5577b3268339/test/jdk/javax/accessibility/TestPopupMenuChildCount.java#L36). I don't think test name needs to be changed.
>> 
>> Although it is not essentially required but will update the test summary and instruction.
> 
> It seems to me that this test should be generalized for all a11y platforms, since it is a regression test and can help identify regression of this functionality on other platforms.

The behaviour on Windows with a11y clients (JAWS or NVDA) is different. They don't announce the child count for the menu and submenus for java application and it is similar to the native application (notepad++) too.

So, the regression test restricted for macOS seems suitable for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25470#discussion_r2113468220

From duke at openjdk.org  Thu May 29 10:15:03 2025
From: duke at openjdk.org (ScientificWare)
Date: Thu, 29 May 2025 10:15:03 GMT
Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image
 type input HTML tag [v10]
In-Reply-To: <by1L3sa9jQ2bs5TPpK5Mx6dlE9lyfVEDcpJDYH3Cvow=.12d23c02-e3df-4172-af83-7c72c0955a21@github.com>
References: <ZsMXtiW2DnayIHuAemRjnYqKYJf1T0-sYT7KBwRP7v8=.d7948ddf-cb2e-482d-8d85-cdce763b2aa2@github.com>
 <by1L3sa9jQ2bs5TPpK5Mx6dlE9lyfVEDcpJDYH3Cvow=.12d23c02-e3df-4172-af83-7c72c0955a21@github.com>
Message-ID: <rI6cC25pzqfrkmVcHWDnp631ZkzOB4oiHmNXWZCQlYA=.d0fa9be9-5fb5-4fdd-8a86-1ad22bd47d52@github.com>

On Mon, 9 Dec 2024 09:56:15 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8314731 : Adds support for the alt attribute in the image type input HTML tag.](https://bugs.java.com/bugdatabase/view_bug?bug_id=8314731)
>> 
>> This is tracked in JBS as
>> - [JDK-8314731 : Add support for the alt attribute in the image type input HTML tag](https://bugs.openjdk.java.net/browse/JDK-8314731)
>> 
>> According [HTML 3.2 specification](https://www.w3.org/TR/2018/SPSD-html32-20180315/#input)
>> 
>> `alt` is not an attribute of the `input` element.
>> 
>> According [HTML 4.01 specifications](https://www.w3.org/TR/html4/interact/forms.html#h-17.4) : 
>> 
>>> ... For accessibility reasons, authors should provide [alternate text](https://www.w3.org/TR/html4/struct/objects.html#alternate-text) for the image via the [alt](https://www.w3.org/TR/html4/struct/objects.html#adef-alt) attribute. ...
>> 
>> This feature is not implemented in `FormView.java`.
>> 
>> ??  ~~This also affects the HTML 32 DTD~~
>> 
>> ![Screenshot_20230817_025316](https://github.com/openjdk/jdk/assets/19194678/8e580574-d842-4a65-884b-26e33cd12138)
>> 
>> Left before the patch and right after the patch.
>> 
>> 
>> import java.awt.BorderLayout;
>> import java.awt.Dimension;
>> import javax.swing.JEditorPane;
>> import javax.swing.JFrame;
>> import javax.swing.JScrollPane;
>> import javax.swing.SwingUtilities;
>> import javax.swing.text.Document;
>> import javax.swing.text.html.HTMLEditorKit;
>> import javax.swing.text.html.StyleSheet;
>> 
>> public class HTMLAddsSupportAltInputTag {
>>   public static void main(String[] args) {
>>     new HTMLAddsSupportAltInputTag();
>>   }
>>   
>>   public HTMLAddsSupportAltInputTag() {
>>     SwingUtilities.invokeLater(new Runnable(){
>>       public void run(){
>>         JEditorPane jEditorPane = new JEditorPane();
>>         jEditorPane.setEditable(false);
>>         JScrollPane scrollPane = new JScrollPane(jEditorPane);
>>         HTMLEditorKit kit = new HTMLEditorKit();
>>         jEditorPane.setEditorKit(kit);
>>         StyleSheet styleSheet = kit.getStyleSheet();
>>         styleSheet.addRule("""
>>             body {
>>                 color: #000;
>>                 font-family:times;
>>                 margin: 4px;
>>             }
>>             """);
>>         String htmlString = """
>>             <html>
>>                 <body>
>>                     <input type=image name=point src="file:oracle_logo_50x50.jpg" alt="Logo Oracle JPG">
>>                     <p>
>>                     <input type=image name=point src="file:none_ora...
>
> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge master
>  - JDK-8314731 : Remove all indentations accidentally introduced by the previous commit.
>  - Merge master
>  - Merge master
>  - jdk-8314731 : FormView Alt Support.
>    
>    FormView.java :
>    - revert ALL unrelated changing to formatting.
>    
>    bug8314731.java :
>    - Fix the test description.
>    - Change where the user interface is created.
>    - Add a finall block to be sure the Frame is disposed.
>    - Replace "testPassed" with "testFailed".
>  - Merge master
>  - Replaces this title with "alt attribute test in HTML image type input".
>    
>    Moves this test to /jdk/test/jdk/javax/swing/text/html.
>  - bug8314731.java : Corrects the CopyRight date.
>  - FormView.java :
>    Removes a whitespace
>    
>    bug8314731.java :
>    Adds a newline at end of file.
>  - getMaximumSpan(int axis) method
>    doc -> Not used
>    
>    mouseReleased(MouseEvent evt) method
>    elem and hdoc -> not used
>    return -> could be removed, method returns void
>    
>    loadElementDataIntoBuffer(Element elem, StringBuilder buffer) method
>    value != null -> name can't be null at this point
>    
>    getInputElementData(AttributeSet attr) method
>    value = null -> Already set at null
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/69e664de...9b423808

Awaiting review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15319#issuecomment-2918939622

From dmarkov at openjdk.org  Thu May 29 10:25:52 2025
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Thu, 29 May 2025 10:25:52 GMT
Subject: RFR: 8357672: Extreme font sizes can cause font substitution
In-Reply-To: <imS2Qz_axrs-7PXyPFbW52X1aG0ToIcW1zztWP3eB90=.f0398502-dd47-4545-a9c3-c23f6ea7e679@github.com>
References: <imS2Qz_axrs-7PXyPFbW52X1aG0ToIcW1zztWP3eB90=.f0398502-dd47-4545-a9c3-c23f6ea7e679@github.com>
Message-ID: <25yiMYq7efwejhVkwRA5O6YaugBQEOpIUajdtfSK62c=.643db0a5-6635-4276-8339-41facd50b809@github.com>

On Wed, 28 May 2025 20:19:42 GMT, Phil Race <prr at openjdk.org> wrote:

> Instrumenting the existing ExtremeFontSizeTest.java, it was noted that the freetype code, when encountering a null return from getting a scaler context, would over-interpret this as a bad font.
> The test was intended to check this wasn't happening by verifying metrics before and after using extreme sizes.
> But the scenaro was not being detected by the test because a replacement font was substituted and it did not have zero metrics.
> So the updated test checks that the metrics before and after are the same.
> This new version of the test failed on Linux before the JDK source updates and passes afterwards.

Marked as reviewed by dmarkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25511#pullrequestreview-2877798577

From serb at openjdk.org  Thu May 29 10:54:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 29 May 2025 10:54:52 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java [v3]
In-Reply-To: <-lBIVrQXyxII4hEx6bRTJaM9dtFYWTgu7ULBFS-5kOQ=.a653a92e-702d-48d2-b6fa-50d134d4996d@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
 <-lBIVrQXyxII4hEx6bRTJaM9dtFYWTgu7ULBFS-5kOQ=.a653a92e-702d-48d2-b6fa-50d134d4996d@github.com>
Message-ID: <vHSyErxHa9Qj3AXT--S2xsTeHcz06CmVbLq3IRuCnPs=.10076546-bcde-409a-84be-9e4f403de898@github.com>

On Thu, 29 May 2025 01:47:47 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs.
>> 
>> Test failure is not reproducible when the test is run individually (multiple times) on CI.
>> 
>> Rewritten the test and added debug logs that will be helpful to figure out the issue. 
>> 
>> - Added code to capture screenshot (entire screen as well as the frame) in case of failure.
>> - Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor update

test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 57:

> 55:         // copy the region such that part of it goes below the bottom of the
> 56:         // destination surface
> 57:         g2d.copyArea(0, 10, 50, h-10, 60, 10);

The new version looks like a different test, previously we copyArea from the paint method for the awt frame, then call sync to flush all rendering, then check the rendering on screen, and all of that on "each render frame".

Now it will draw everything in paint then sometime later(or even after a few repaints) we check the actual rendering(waitForIdle/delay(100))....

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2113703881

From dgredler at openjdk.org  Thu May 29 11:10:38 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 29 May 2025 11:10:38 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377 [v4]
In-Reply-To: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
Message-ID: <DVwbyup3ory0QwNRsyxVu7zjhVMDI-xjK82V9_DRy6k=.502c6320-ae1a-4919-9260-fb879f9f2994@github.com>

> It looks like this regression actually fits into a longer series of fixes / regressions in this area:
> 
> - [JDK-4517298](https://bugs.openjdk.org/browse/JDK-4517298) fixed metrics for zero-width characters, but broke some ligatures / glyph substitutions
> - [JDK-7017058](https://bugs.openjdk.org/browse/JDK-7017058) fixed the ligatures / glyph substitutions, but broke some zero-width metrics
> - [JDK-8208377](https://bugs.openjdk.org/browse/JDK-8208377) fixed some metrics and rendering for zero-width characters, but broke some ligatures / glyph substitutions
> - Now, with this PR, we aim to fix the ligatures without re-breaking zero-width metrics and display
> 
> We have two different types of use cases pulling `CharToGlyphMapper` in two different directions: the users who need raw, untransformed glyph info, and the users who need normalized / transformed glyph info.
> 
> It looks to me like, in the current code base, the only `CharToGlyphMapper` user which requires raw font data is HarfBuzz (explicitly confirmed with the HarfBuzz team here: https://github.com/harfbuzz/harfbuzz/discussions/5234).
> 
> The regression mechanism at play here is that the HarfBuzz font callbacks are currently providing HarfBuzz with transformed glyph info (e.g. ZWJ -> INVISIBLE_GLYPH_ID), which prevents HarfBuzz from recognizing and applying the correct font GSUB substitutions (which involve ZWJ).
> 
> In order to fix this without (yet again) breaking metrics and display behavior elsewhere, I've added two methods to `CharToGlyphMapper` which provide access to raw glyph info, to be used by the HarfBuzz font callbacks: `charToGlyphRaw(int)` and `charToVariationGlyphRaw(int)`.
> 
> Note two intricacies related to `CompositeGlyphMapper`:
> 1. We need to be careful to only cache raw (untransformed) values, to avoid conflicts between requests for a raw version of a glyph and a transformed version of the same glyph. Another option would have been two separate caches, but I don't think that's necessary.
> 2. Consumers who are using `CompositeGlyphMapper.SLOTMASK` to check glyph slots (e.g. `FontRunIterator` and `CTextPipe`) will "see" invisible glyphs as having come from slot 0. This isn't new, and I think it's OK, but something to be aware of.
> 
> The glyph cache handling in `CCharToGlyphMapper` (for macOS) also requires care to avoid mixing value types.
> 
> Please also note that I'm not sure if the tweak to `sunFont.c` is being tested, since FFM is being used by default for HarfBuzz integration. (Is there a plan to remove...

Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:

  Remove one last now-unnecessary whitespace check inside CMap

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24412/files
  - new: https://git.openjdk.org/jdk/pull/24412/files/c68240b2..95652a11

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24412&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24412&range=02-03

  Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24412.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24412/head:pull/24412

PR: https://git.openjdk.org/jdk/pull/24412

From kizune at openjdk.org  Thu May 29 15:34:52 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 29 May 2025 15:34:52 GMT
Subject: RFR: 8341311: [Accessibility, macOS,
 VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu [v3]
In-Reply-To: <xMzFldszd76f1p5RCDnTP-DZNBOmO1X4jQsWasiMMq8=.a51a8ff4-7ec6-47f2-a66f-5674601405d3@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
 <xMzFldszd76f1p5RCDnTP-DZNBOmO1X4jQsWasiMMq8=.a51a8ff4-7ec6-47f2-a66f-5674601405d3@github.com>
Message-ID: <lSicrPolHZXTLiDIiBCoMmAKRj0qBQHUzbzCpG-10qg=.dec3fe07-8106-45bb-bf87-c7517461f4fe@github.com>

On Thu, 29 May 2025 07:03:58 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver announce incorrect number of child for a submenu of JPopupMenu when it is visible for the first time only. After that VO is able to announce the number of items correctly.
>> 
>> **Issue:** Problem is with the a11y subsystem method call to get the accessible children details.
>> 
>> **Analysis:** When the Submenu of a JPopupMenu is opened, accessible component of PopupMenu is created dynamically in the native side implementation and `PostMenuOpened` notification is sent to the a11y subsystem for the newly created PopupMenu. Once the notification is sent to a11y sub-system, it invokes the `accessibilityChildren` method to get the children details for the menu component. A11y subsystem always retrieve the information of the root level PopupMenu irrespective of the submenu's PopupMenu (PopupMenu is associated with each JMenu) and thus announce the root level PopupMenu child count which is incorrect.
>> 
>> **Proposed Fix:** Proposed fix is to ensure the correct child details are sent back to a11y sub-system for correct announcement. So, whenever the `accessibilityChildren` method is invoked, first try to find out the current accessible PopupMenu which is opened for the Submenu and then return the child details.
>> 
>> **Testing :** Manual test case is attached to verify the fix and there is no failure with fix in CI pipeline.
>> 
>> `Current fix also ensures the correct child counts are announced for the JMenu's Submenu which are present in the JMenubar.`
>> 
>> **Note :** While verifying the fix, a new issue is unearthed for multi-level submenu where VO is failed to announce the Submenu's text. Since the issue exists without the proposed fix too, it shall be treated as a new bug finding and will raise a separate JBS issue.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code optimization

Looks good.

-------------

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25470#pullrequestreview-2878711796

From mblaesing at openjdk.org  Thu May 29 15:39:56 2025
From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=)
Date: Thu, 29 May 2025 15:39:56 GMT
Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v2]
In-Reply-To: <IVseDGLFBp2TAQMrbsgvCgX1wBOALL0QZXwMwHxp7Hw=.d305f8ac-3a89-42c0-b626-08ae327f1cb1@github.com>
References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com>
 <HYQ237abKwF9M1jfKX3VQG_ytVIfbXo_m3OioPFbd4s=.f1ecbd3e-c630-457d-8b78-73292bbb39d4@github.com>
 <IVseDGLFBp2TAQMrbsgvCgX1wBOALL0QZXwMwHxp7Hw=.d305f8ac-3a89-42c0-b626-08ae327f1cb1@github.com>
Message-ID: <2WRXCTX7XfUiOZzWFQAfIMRUzwn8Z63St1KDrmuO-lw=.b3dd6e99-4778-4083-b8d1-d3112512fdf3@github.com>

On Tue, 13 May 2025 02:11:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adress review comments: Update copyright years and fix whitespace in if condition
>
> is it possible to create a jtreg test for this issue?

@mrserb would you mind having another look at this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24614#issuecomment-2919785018

From kizune at openjdk.org  Thu May 29 16:29:53 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 29 May 2025 16:29:53 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v5]
In-Reply-To: <RI0QhBcF4ytQvLXlFrBy31ed35u_EG5XWmE54ogtRBc=.dd1693b3-15e5-4ba2-9754-b34a145bacfb@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <RI0QhBcF4ytQvLXlFrBy31ed35u_EG5XWmE54ogtRBc=.dd1693b3-15e5-4ba2-9754-b34a145bacfb@github.com>
Message-ID: <DRp8soYGB6K2-norkdY9g3COw40fiADmMxJ0Dr-bmHE=.1f7fecb6-7524-428a-b061-4047a3e03c45@github.com>

On Wed, 28 May 2025 03:21:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. 
>> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user.
>> Fixed by setting the divider location before rendering the left and right components..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Store current orientation for check

Marked as reviewed by kizune (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25294#pullrequestreview-2878886416

From dnguyen at openjdk.org  Thu May 29 16:50:55 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 29 May 2025 16:50:55 GMT
Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v3]
In-Reply-To: <eMVuk6CjTRjfvR6UUtz4FsRN4wqGOoZRedYLQMtY24g=.1988f3cd-3d59-4f2c-9886-1f038f0d834d@github.com>
References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com>
 <eMVuk6CjTRjfvR6UUtz4FsRN4wqGOoZRedYLQMtY24g=.1988f3cd-3d59-4f2c-9886-1f038f0d834d@github.com>
Message-ID: <4WgqjhL3ZIJAYKUp8CHG-mQDyvfp8wmWIaGqlkjpLOs=.914fd1b8-de37-4386-96a5-98cc0f8b2052@github.com>

On Thu, 15 May 2025 16:48:47 GMT, Matthias Bl?sing <mblaesing at openjdk.org> wrote:

>> - Introduce a lock into WClipboard that protects the code between
>>   openClipboard/closeClipboard invocations.
>>   The native side does not allow to open the clipboard multiple
>>   times or share the opened clipboard between multiple threads.
>> 
>> - Remove of need to call openClipboard/closeClipboard from
>>   getClipboardFormats by using the win32 call
>>   GetUpdatedClipboardFormats
>> 
>> - Prevent a race-condition by not registering the connection
>>   between java and native side of clipboard multiple time, but
>>   just at construction time.
>
> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add crash reproducer as jtreg test

src/java.desktop/share/classes/sun/awt/datatransfer/SunClipboard.java line 208:

> 206: 
> 207:         try {
> 208:             openClipboard(null);

Can you help me understand why this is better? Seems odd that the try/finally block has `closeClipboard` in the finally block but the `openClipboard` was moved out of the try.

src/java.desktop/windows/classes/sun/awt/windows/WClipboard.java line 189:

> 187:             checkChange(formats);
> 188:         } catch (Throwable ex) {
> 189:             System.getLogger(WClipboard.class.getName()).log(Level.WARNING, "Failed to process handleContentsChanged", ex);

I'm not saying not to necessarily change this, but what are we hoping to see with logging this warning here?

test/jdk/java/awt/Clipboard/ConcurrentClipboardAccessTest.java line 29:

> 27:   @summary tests that concurrent access to the clipboard does not crash the JVM
> 28:   @run main ConcurrentClipboardAccessTest
> 29:  */

It has been brought to my attention that this test needs to be headful since we're dealing with clipboard behavior.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2114346429
PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2114337249
PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2114349984

From mblaesing at openjdk.org  Thu May 29 17:11:12 2025
From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=)
Date: Thu, 29 May 2025 17:11:12 GMT
Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v4]
In-Reply-To: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com>
References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com>
Message-ID: <IFc-6ibCLcruM5bgWczfmI7AAfNxfuMgGutYf1JVQD4=.d56e4cc8-9e59-49b6-b3df-c9ae29d1ccb0@github.com>

> - Introduce a lock into WClipboard that protects the code between
>   openClipboard/closeClipboard invocations.
>   The native side does not allow to open the clipboard multiple
>   times or share the opened clipboard between multiple threads.
> 
> - Remove of need to call openClipboard/closeClipboard from
>   getClipboardFormats by using the win32 call
>   GetUpdatedClipboardFormats
> 
> - Prevent a race-condition by not registering the connection
>   between java and native side of clipboard multiple time, but
>   just at construction time.

Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision:

  Add headful key to the jtreg description

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24614/files
  - new: https://git.openjdk.org/jdk/pull/24614/files/e5ebf59f..bfa99a71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24614&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24614&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24614/head:pull/24614

PR: https://git.openjdk.org/jdk/pull/24614

From mblaesing at openjdk.org  Thu May 29 17:11:12 2025
From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=)
Date: Thu, 29 May 2025 17:11:12 GMT
Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v3]
In-Reply-To: <4WgqjhL3ZIJAYKUp8CHG-mQDyvfp8wmWIaGqlkjpLOs=.914fd1b8-de37-4386-96a5-98cc0f8b2052@github.com>
References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com>
 <eMVuk6CjTRjfvR6UUtz4FsRN4wqGOoZRedYLQMtY24g=.1988f3cd-3d59-4f2c-9886-1f038f0d834d@github.com>
 <4WgqjhL3ZIJAYKUp8CHG-mQDyvfp8wmWIaGqlkjpLOs=.914fd1b8-de37-4386-96a5-98cc0f8b2052@github.com>
Message-ID: <YaGUbfmtwqy4J-RShfSBDGdkeAuw9EGaJPhEbwc-ReU=.bec75cc7-908a-4e1b-8ba3-c8f3d9d60e8d@github.com>

On Thu, 29 May 2025 16:44:48 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add crash reproducer as jtreg test
>
> test/jdk/java/awt/Clipboard/ConcurrentClipboardAccessTest.java line 29:
> 
>> 27:   @summary tests that concurrent access to the clipboard does not crash the JVM
>> 28:   @run main ConcurrentClipboardAccessTest
>> 29:  */
> 
> It has been brought to my attention that this test needs to be headful since we're dealing with clipboard behavior.

You are right, thanks for catching this. Pushed an updated version.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2114389500

From mblaesing at openjdk.org  Thu May 29 17:16:59 2025
From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=)
Date: Thu, 29 May 2025 17:16:59 GMT
Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v3]
In-Reply-To: <4WgqjhL3ZIJAYKUp8CHG-mQDyvfp8wmWIaGqlkjpLOs=.914fd1b8-de37-4386-96a5-98cc0f8b2052@github.com>
References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com>
 <eMVuk6CjTRjfvR6UUtz4FsRN4wqGOoZRedYLQMtY24g=.1988f3cd-3d59-4f2c-9886-1f038f0d834d@github.com>
 <4WgqjhL3ZIJAYKUp8CHG-mQDyvfp8wmWIaGqlkjpLOs=.914fd1b8-de37-4386-96a5-98cc0f8b2052@github.com>
Message-ID: <tG5NiVTQjQJziitgmM4ehKirnVvxW3LR6p0atUV-u1M=.b22f3a56-47cc-4696-9ad8-3f7f8c222154@github.com>

On Thu, 29 May 2025 16:36:47 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add crash reproducer as jtreg test
>
> src/java.desktop/windows/classes/sun/awt/windows/WClipboard.java line 189:
> 
>> 187:             checkChange(formats);
>> 188:         } catch (Throwable ex) {
>> 189:             System.getLogger(WClipboard.class.getName()).log(Level.WARNING, "Failed to process handleContentsChanged", ex);
> 
> I'm not saying not to necessarily change this, but what are we hoping to see with logging this warning here?

The idea here is to not silently swallow exceptions. This code is called from `AwtToolkit::WndProc`, which from my reading will not report exceptions/throwables. Pushing the exception to the system logger gives a chance to detect problems here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2114399911

From mblaesing at openjdk.org  Thu May 29 17:30:54 2025
From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=)
Date: Thu, 29 May 2025 17:30:54 GMT
Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v4]
In-Reply-To: <IFc-6ibCLcruM5bgWczfmI7AAfNxfuMgGutYf1JVQD4=.d56e4cc8-9e59-49b6-b3df-c9ae29d1ccb0@github.com>
References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com>
 <IFc-6ibCLcruM5bgWczfmI7AAfNxfuMgGutYf1JVQD4=.d56e4cc8-9e59-49b6-b3df-c9ae29d1ccb0@github.com>
Message-ID: <hln7P4BmiJg164hV5I7TIDWVBMSLdFBf_hkeQFBTYKI=.e5d1e35e-8fe9-499b-b1c6-312348612315@github.com>

On Thu, 29 May 2025 17:11:12 GMT, Matthias Bl?sing <mblaesing at openjdk.org> wrote:

>> - Introduce a lock into WClipboard that protects the code between
>>   openClipboard/closeClipboard invocations.
>>   The native side does not allow to open the clipboard multiple
>>   times or share the opened clipboard between multiple threads.
>> 
>> - Remove of need to call openClipboard/closeClipboard from
>>   getClipboardFormats by using the win32 call
>>   GetUpdatedClipboardFormats
>> 
>> - Prevent a race-condition by not registering the connection
>>   between java and native side of clipboard multiple time, but
>>   just at construction time.
>
> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add headful key to the jtreg description

@DamonGuy thanks for your check. I updated the PR and added replies. If more changes/informations are required, I'm willing to help.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24614#issuecomment-2920085712

From mblaesing at openjdk.org  Thu May 29 17:30:55 2025
From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=)
Date: Thu, 29 May 2025 17:30:55 GMT
Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v4]
In-Reply-To: <4WgqjhL3ZIJAYKUp8CHG-mQDyvfp8wmWIaGqlkjpLOs=.914fd1b8-de37-4386-96a5-98cc0f8b2052@github.com>
References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com>
 <eMVuk6CjTRjfvR6UUtz4FsRN4wqGOoZRedYLQMtY24g=.1988f3cd-3d59-4f2c-9886-1f038f0d834d@github.com>
 <4WgqjhL3ZIJAYKUp8CHG-mQDyvfp8wmWIaGqlkjpLOs=.914fd1b8-de37-4386-96a5-98cc0f8b2052@github.com>
Message-ID: <IMJuHN3R0K2I-3LAA-KiYdQtJYE1WGtQlFPtUgmSmRE=.13f7a17e-85e4-4010-9ecf-35c5966b0848@github.com>

On Thu, 29 May 2025 16:42:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add headful key to the jtreg description
>
> src/java.desktop/share/classes/sun/awt/datatransfer/SunClipboard.java line 208:
> 
>> 206: 
>> 207:         try {
>> 208:             openClipboard(null);
> 
> Can you help me understand why this is better? Seems odd that the try/finally block has `closeClipboard` in the finally block but the `openClipboard` was moved out of the try.

Before the change the call order was inconsistent:

- `ClipboardTransferable`: one call, `openClipboard` is called before the `try`-block
- `WClipboard`: one call with `openClipboard` before the `try`-block, one call with `openClipboard` as first statement in the `try`-block
- `SunClipboard`: three calls with `openClipboard` as first statement inside the `try`-block

I unified these so that in all cases `openClipboard` is called as the last statement before the try-block. The assumption is, that only if `openClipboard` succeeds (does not raise an exception), calling `closeClipboard` makes sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2114423928

From prr at openjdk.org  Thu May 29 18:56:56 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 29 May 2025 18:56:56 GMT
Subject: RFR: 8357675: Amend headless message
In-Reply-To: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
References: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
Message-ID: <slD0C6T4XGh8njqQyiJuMkQej7P8usKetTl-sIKOB7A=.6d34decc-a77d-4823-b10c-4062c333ea20@github.com>

On Mon, 26 May 2025 16:38:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Currently, the default headless message ends with a comma instead of full stop and has an additional line break.
> 
> 
> Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException:
> No X11 DISPLAY variable was set,
> or no headful library support was found,
> but this program performed an operation which requires it,
> 
>         at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:158)
>         at java.desktop/java.awt.Window.<init>(Window.java:518)
>         at java.desktop/java.awt.Frame.<init>(Frame.java:428)
>         at java.desktop/javax.swing.JFrame.<init>(JFrame.java:224) 
> 
> 
> **Fix:**
> 
> Amend the message so that it ends with a full stop and remove the line break.
> 
> 
> Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException:
> No X11 DISPLAY variable was set,
> or no headful library support was found,
> but this program performed an operation which requires it.
>         at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:158)
>         at java.desktop/java.awt.Window.<init>(Window.java:518)
>         at java.desktop/java.awt.Frame.<init>(Frame.java:428)
>         at java.desktop/javax.swing.JFrame.<init>(JFrame.java:224)
> 
> 
> **Testing:**
> 
> Build a headless-only JDK (pass `--enable-headless-only` to the `configure` script) and create a `JFrame`.
> 
> It's impossible to create an automated test for this change, and I don't think a test is required, it's a cosmetic change.

BTW there's a good reason for the newline. It's there on all platforms and has been there since at least 1.5
If its not there then when you do "System.out.println(new HeadlessException("foo").getMessage());
and there's a default message, you'll get
fooNo X11 Display variable was set ...

instead of the current more legible
foo
No X11 Display variable was set ...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25453#issuecomment-2920295348

From prr at openjdk.org  Thu May 29 19:06:56 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 29 May 2025 19:06:56 GMT
Subject: RFR: 8357299: Graphics copyArea doesn't copy any pixels when there
 is overflow
In-Reply-To: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
References: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
Message-ID: <jLxshAvvhW-32cPJNsShRX7f04sH1xLIVKXJftT1z4g=.beb2859f-311d-4ea5-95b4-4a080f5f5ea7@github.com>

On Wed, 21 May 2025 03:17:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Graphics copyArea overflow check bails out of copying pixels if there is overflow.
> The spec says ""If a portion of the source rectangle lies outside the bounds of the component, or is obscured by another window or component, {@code copyArea} *will be unable to copy* the associated pixels"
> 
> which suggests that we should always copy the parts inside the bounds and never the parts outside the bounds
> but it seems currently, in the case of overflow it no longer copies any pixels, including the parts that are inside. 
> So, the fix clips the copyarea region to clip bounds so it will only affect pixels within the valid bounds, and any pixels outside will be ignored.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25340#pullrequestreview-2879322755

From prr at openjdk.org  Thu May 29 19:06:57 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 29 May 2025 19:06:57 GMT
Subject: RFR: 8357299: Graphics copyArea doesn't copy any pixels when there
 is overflow
In-Reply-To: <tugH2JMkemfDK7hiEvhXNORN7OxSyLsKGPO0bjNicn8=.27d05a6d-4659-4bc6-96ad-fd31fd8ae56f@github.com>
References: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
 <rYu0g4fVWaCX7yxGhNgYijkzsYIUjWnnGdwiq3u5ZeU=.09c39483-6204-4490-b952-5c4ed8cfdc6b@github.com>
 <tugH2JMkemfDK7hiEvhXNORN7OxSyLsKGPO0bjNicn8=.27d05a6d-4659-4bc6-96ad-fd31fd8ae56f@github.com>
Message-ID: <vbcJsxfrOgq8jE5MsCxXKfyYt4E_MTT6Fin2tOLgrEg=.a88f543a-1284-4a15-bdeb-08a3b6e9620e@github.com>

On Wed, 28 May 2025 03:29:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/native/libawt/java2d/loops/Blit.c line 85:
>> 
>>> 83:     dstInfo.bounds.x2 = UNSAFE_TO_ADD(dstx, width)
>>> 84:                         ? clipInfo.bounds.x2 : (dstx + width);
>>> 85:     dstInfo.bounds.y2 = UNSAFE_TO_ADD(dsty, height)
>> 
>> why wouldn't you always want to limit it to the clip ?
>> I mean shouldn't it be like this ?
>> dstInfo.bounds.x2 = UNSAFE_TO_ADD(dstx, width)  ? clipInfo.bounds.x2 : (((dstx + width) > clipInfo.bounds.x2) ? clipInfo.bounds.x2 : (dstx + width));
>> or maybe a bit more readable as 
>> dstInfo.bounds.x2 = ((UNSAFE_TO_ADD(dstx, width) || ((dstx + width) > clipInfo.bounds.x2)) ? clipInfo.bounds.x2 : (dstx + width);
>
> @prrace Since it is going to clip dstInfo.bounds to clipInfo.bounds in SurfaceData_IntersectBounds, I believe is not necessary to do the duplicate clip here.
> Let me know if you think otherwise..

ok

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25340#discussion_r2114574302

From prr at openjdk.org  Thu May 29 19:08:54 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 29 May 2025 19:08:54 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
Message-ID: <dVw-4Yl3AI2y1kYAwY1rgjjRrqCSiIVv2UN-UHuJtB0=.81a20509-7795-4ad7-b7c9-f42970d65318@github.com>

On Mon, 26 May 2025 08:20:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java

Approving client changes

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25228#pullrequestreview-2879326497

From aivanov at openjdk.org  Thu May 29 20:14:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 29 May 2025 20:14:56 GMT
Subject: RFR: 8357675: Amend headless message
In-Reply-To: <slD0C6T4XGh8njqQyiJuMkQej7P8usKetTl-sIKOB7A=.6d34decc-a77d-4823-b10c-4062c333ea20@github.com>
References: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
 <slD0C6T4XGh8njqQyiJuMkQej7P8usKetTl-sIKOB7A=.6d34decc-a77d-4823-b10c-4062c333ea20@github.com>
Message-ID: <0FhBEOKrjGTcCUIbgEUsoIToSqVLleXC1ZH5Vdqg-zM=.337a9e1d-2720-4a38-a8a5-176c0d1289b2@github.com>

On Thu, 29 May 2025 18:54:17 GMT, Phil Race <prr at openjdk.org> wrote:

> BTW there's a good reason for the newline. It's there on all platforms and has been there since at least 1.5\
> If its not there then when you do "System.out.println(new HeadlessException("foo").getMessage());\
> and there's a default message, you'll get\
> ```
> fooNo X11 Display variable was set ...
> ```
> 
> instead of the current more legible
> ```
> foo
> No X11 Display variable was set ...
> ```

@prrace This hasn't changed: the new line character at the start of the default headless message is preserved as it has always been there.

What I remove is the new line character in the end of the message which wasn't there until [JDK-8286447](https://bugs.openjdk.org/browse/JDK-8286447) and which isn't there for macOS or Windows.

In other words, currently you get

foo
No X11 Display variable was set ...

and you'll get the same after applying the proposed patch too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25453#issuecomment-2920470181

From honkar at openjdk.org  Thu May 29 21:29:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 29 May 2025 21:29:53 GMT
Subject: RFR: 8357799: Improve instructions for
 JFileChooser/HTMLFileName.java [v2]
In-Reply-To: <IH33ksFeozNTUrlZHv9JPgvl_1fBDLsgShnb1PLHioE=.a2c29c45-94f5-4ebf-9c3d-b40fbd8fe075@github.com>
References: <gh770JpwLKNbDOyw93THX4bMjvhTbgN9VO7l2-jZds8=.c8b9dd45-e498-4b25-bc02-ff4d445703d5@github.com>
 <IH33ksFeozNTUrlZHv9JPgvl_1fBDLsgShnb1PLHioE=.a2c29c45-94f5-4ebf-9c3d-b40fbd8fe075@github.com>
Message-ID: <k3GOPPVw3TQt98b8A936gPoNBh8SpedaIvs1l_4sgiA=.5179077e-b35c-4eae-980a-09b6e7af5e97@github.com>

On Mon, 26 May 2025 17:18:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The instructions for the `javax/swing/JFileChooser/HTMLFileName.java` test are still not as clear.
>> 
>> The file name in the instructions is rendered as HTML, which, I believe, is unexpected. It should be displayed as the plain text.
>> 
>> The instructions also say about file and directory which have HTML in their name; this was true in the initial version of the test in #24439 that created files and directories on the real file system. 
>> 
>> The final version of test uses a virtual file system that displays *three files*, there's no way to navigate.
>> 
>> I also clarified the instructions: look at how the file name of the first file is rendered in _the file pane_ and _the navigation combo box_ (**Look in** in Metal L&F).
>> 
>> In the `VirtualFileSystemView` class, I changed the name of the third file from `virtualFolder` to `virtualFile2.log`, and made the file array a field which ensures `getRoots` and `getFiles` return the same list.
>> 
>> 
>> In addition to this, I reduced the number of rows allocated for the instructions. Since the instructions are in HTML format, the number of lines of HTML code makes no sense for determining the size.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct the title of the test frames

test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 81:

> 79:                       in the navigation combo box above is displayed
> 80:                       as HTML, then press <b>Pass</b>.<br>
> 81:                       If it is in plain text, then press <b>Fail</b>.

According to test instructions it states that the file name in the **file pane** and navigation combo box must be displayed as HTML. When I'm testing with system (Aqua) LaF on macOS the file name in file pane shows up empty (with the original as well as updated test).

<img src="https://github.com/user-attachments/assets/5b78d972-4d2f-41d3-ab6b-c9c4b0a8b767" alt="HTML_Enabled" width=400 height=300 />

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25455#discussion_r2114776660

From prr at openjdk.org  Thu May 29 22:01:54 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 29 May 2025 22:01:54 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377 [v4]
In-Reply-To: <DVwbyup3ory0QwNRsyxVu7zjhVMDI-xjK82V9_DRy6k=.502c6320-ae1a-4919-9260-fb879f9f2994@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
 <DVwbyup3ory0QwNRsyxVu7zjhVMDI-xjK82V9_DRy6k=.502c6320-ae1a-4919-9260-fb879f9f2994@github.com>
Message-ID: <Exw_xAvebaFaPnU85goD4Iq-6ayndgcniCIEL9zufZE=.7c3dad4a-d994-4b55-b1e3-047f1ed4b2c1@github.com>

On Thu, 29 May 2025 11:10:38 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> It looks like this regression actually fits into a longer series of fixes / regressions in this area:
>> 
>> - [JDK-4517298](https://bugs.openjdk.org/browse/JDK-4517298) fixed metrics for zero-width characters, but broke some ligatures / glyph substitutions
>> - [JDK-7017058](https://bugs.openjdk.org/browse/JDK-7017058) fixed the ligatures / glyph substitutions, but broke some zero-width metrics
>> - [JDK-8208377](https://bugs.openjdk.org/browse/JDK-8208377) fixed some metrics and rendering for zero-width characters, but broke some ligatures / glyph substitutions
>> - Now, with this PR, we aim to fix the ligatures without re-breaking zero-width metrics and display
>> 
>> We have two different types of use cases pulling `CharToGlyphMapper` in two different directions: the users who need raw, untransformed glyph info, and the users who need normalized / transformed glyph info.
>> 
>> It looks to me like, in the current code base, the only `CharToGlyphMapper` user which requires raw font data is HarfBuzz (explicitly confirmed with the HarfBuzz team here: https://github.com/harfbuzz/harfbuzz/discussions/5234).
>> 
>> The regression mechanism at play here is that the HarfBuzz font callbacks are currently providing HarfBuzz with transformed glyph info (e.g. ZWJ -> INVISIBLE_GLYPH_ID), which prevents HarfBuzz from recognizing and applying the correct font GSUB substitutions (which involve ZWJ).
>> 
>> In order to fix this without (yet again) breaking metrics and display behavior elsewhere, I've added two methods to `CharToGlyphMapper` which provide access to raw glyph info, to be used by the HarfBuzz font callbacks: `charToGlyphRaw(int)` and `charToVariationGlyphRaw(int)`.
>> 
>> Note two intricacies related to `CompositeGlyphMapper`:
>> 1. We need to be careful to only cache raw (untransformed) values, to avoid conflicts between requests for a raw version of a glyph and a transformed version of the same glyph. Another option would have been two separate caches, but I don't think that's necessary.
>> 2. Consumers who are using `CompositeGlyphMapper.SLOTMASK` to check glyph slots (e.g. `FontRunIterator` and `CTextPipe`) will "see" invisible glyphs as having come from slot 0. This isn't new, and I think it's OK, but something to be aware of.
>> 
>> The glyph cache handling in `CCharToGlyphMapper` (for macOS) also requires care to avoid mixing value types.
>> 
>> Please also note that I'm not sure if the tweak to `sunFont.c` is being tested, since FFM is being used by default for Harf...
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove one last now-unnecessary whitespace check inside CMap

Took me a while, but I think the code looks OK.
Automated testing passed, and I did some manual playing around in Font2DTest.

src/java.desktop/share/classes/sun/print/RasterPrinterJob.java line 2485:

> 2483:         for (int i = 0; i < len; i++) {
> 2484:             char c = in_chars[i];
> 2485:             if (c > '\r' || c < '\t' || c == '\u000b' || c == '\u000c')  {

hmm. looks like you are fixing a bug here. I think those == were supposed to be !=

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24412#pullrequestreview-2879703562
PR Review Comment: https://git.openjdk.org/jdk/pull/24412#discussion_r2114809326

From prr at openjdk.org  Thu May 29 22:19:50 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 29 May 2025 22:19:50 GMT
Subject: RFR: 8357696: Enhance code consistency: java.desktop/unix
In-Reply-To: <STnj3-XhfIKP3W8Z4ysYaKmKpvFpU8VW3uJTEtB7Ge8=.f1fee560-1d04-4b53-8fcb-a74b03757ed3@github.com>
References: <STnj3-XhfIKP3W8Z4ysYaKmKpvFpU8VW3uJTEtB7Ge8=.f1fee560-1d04-4b53-8fcb-a74b03757ed3@github.com>
Message-ID: <9V6dXGFu7iwpjbJc7-Zi_Y-bVug3JoUQLPJVy-iB5pw=.1cbb72b8-34de-4a2b-9109-1a33893324e7@github.com>

On Mon, 26 May 2025 03:10:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is a request to update the remaining parts of the java.desktop/unix package.
> The sun.awt subpackage under java.desktop/unix was previously addressed by https://github.com/openjdk/jdk/pull/24941.
> 
> ====================================================
> 
> The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency.
> 
> The public API was not affected so there is no need to worry about a CSR
> 
> Note: I will submit additional patches in this area later because:
> 
> 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797))
> 2. I skipped adding `@Override` for anonymous classes
> 
> Any feedback or suggestions are welcome!
> 
> Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25439.diff) to a simple diff file, it might be more convenient for reviewing the changes.
> 
> To download the diff file and filter only the modified lines you can use the following script:
> 
> 
> curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25439.diff -o d.txt && grep -E '^+|^-' d.txt
> 
> 
> The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected by these changes. It would be good to verify this by mach5 to ensure everything works as expected.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25439#pullrequestreview-2879735349

From prr at openjdk.org  Thu May 29 22:23:53 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 29 May 2025 22:23:53 GMT
Subject: RFR: 8357687: Remove unnecessary Map.containsKey from
 GraphicsEnvironment implementations
In-Reply-To: <1uiKqIpG8uZ6YKrglYBxK7nMYaqioOirqfiRAp5z7Dw=.813063e1-e218-4794-8bc1-fd8f543c4a74@github.com>
References: <1uiKqIpG8uZ6YKrglYBxK7nMYaqioOirqfiRAp5z7Dw=.813063e1-e218-4794-8bc1-fd8f543c4a74@github.com>
Message-ID: <1nYamt71cfy9hTc1IsaAjrMFQmP4EBMPW2pdHm4KHhk=.63abbeb6-6b90-4dfc-a166-e326c86cd228@github.com>

On Sun, 27 Apr 2025 21:04:34 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `devices` contains only non-null values. It means instead of separate `containsKey` call we can just call `HashMap.get` and then compare result with `null`.

Myself, I like the existing code because
- it is one succinct line
- it is more readable (subjective)
- there is nothing wrong with it
- performance is not a concern for this code, and any improvement will be miniscule

-------------

PR Review: https://git.openjdk.org/jdk/pull/24907#pullrequestreview-2879741097

From serb at openjdk.org  Thu May 29 23:34:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 29 May 2025 23:34:53 GMT
Subject: RFR: 8357299: Graphics copyArea doesn't copy any pixels when there
 is overflow
In-Reply-To: <vbcJsxfrOgq8jE5MsCxXKfyYt4E_MTT6Fin2tOLgrEg=.a88f543a-1284-4a15-bdeb-08a3b6e9620e@github.com>
References: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
 <rYu0g4fVWaCX7yxGhNgYijkzsYIUjWnnGdwiq3u5ZeU=.09c39483-6204-4490-b952-5c4ed8cfdc6b@github.com>
 <tugH2JMkemfDK7hiEvhXNORN7OxSyLsKGPO0bjNicn8=.27d05a6d-4659-4bc6-96ad-fd31fd8ae56f@github.com>
 <vbcJsxfrOgq8jE5MsCxXKfyYt4E_MTT6Fin2tOLgrEg=.a88f543a-1284-4a15-bdeb-08a3b6e9620e@github.com>
Message-ID: <2AKd-LMlhNMKnrNUXmxwYyyfDGIvFOESfwSAK-hJRfw=.7de2e85d-8412-4d25-bff8-5d4f6c9d1854@github.com>

On Thu, 29 May 2025 19:04:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> @prrace Since it is going to clip dstInfo.bounds to clipInfo.bounds in SurfaceData_IntersectBounds, I believe is not necessary to do the duplicate clip here.
>> Let me know if you think otherwise..
>
> ok

>That is because down below it anyway calls SurfaceData_IntersectBounds(&dstInfo.bounds, &clipInfo.bounds); 
so it should clip to clipInfo.bounds there.

In addition to intersecting dst with clip, you're also intersecting src with clip, which seems incorrect. A better approach might be to compute the drawable width based on the non-overflowing range for both src and dst, and then proceed with the original logic.

BTW I have not checked MaskBlit_MaskBlit yet it might require a similar update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25340#discussion_r2114890068

From serb at openjdk.org  Thu May 29 23:34:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 29 May 2025 23:34:54 GMT
Subject: RFR: 8357299: Graphics copyArea doesn't copy any pixels when there
 is overflow
In-Reply-To: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
References: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
Message-ID: <iLd3-Qy7wF35V3S9PEfPwCthJrho_V4NQ-WASBefN2M=.61701d6d-8248-4f12-b41b-94961565fc6d@github.com>

On Wed, 21 May 2025 03:17:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Graphics copyArea overflow check bails out of copying pixels if there is overflow.
> The spec says ""If a portion of the source rectangle lies outside the bounds of the component, or is obscured by another window or component, {@code copyArea} *will be unable to copy* the associated pixels"
> 
> which suggests that we should always copy the parts inside the bounds and never the parts outside the bounds
> but it seems currently, in the case of overflow it no longer copies any pixels, including the parts that are inside. 
> So, the fix clips the copyarea region to clip bounds so it will only affect pixels within the valid bounds, and any pixels outside will be ignored.

src/java.desktop/share/native/libawt/java2d/loops/Blit.c line 88:

> 86:                         ? clipInfo.bounds.y2 : (dsty + height);
> 87:     if (UNSAFE_TO_SUB(srcx, dstx) ||
> 88:         UNSAFE_TO_SUB(srcy, dsty)) {

we also should check this part of the code, is it correct to simply exit here, or should we instead calculate and use the maximum distance we can handle?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25340#discussion_r2114891163

From serb at openjdk.org  Thu May 29 23:42:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 29 May 2025 23:42:50 GMT
Subject: RFR: 8357687: Remove unnecessary Map.containsKey from
 GraphicsEnvironment implementations
In-Reply-To: <1nYamt71cfy9hTc1IsaAjrMFQmP4EBMPW2pdHm4KHhk=.63abbeb6-6b90-4dfc-a166-e326c86cd228@github.com>
References: <1uiKqIpG8uZ6YKrglYBxK7nMYaqioOirqfiRAp5z7Dw=.813063e1-e218-4794-8bc1-fd8f543c4a74@github.com>
 <1nYamt71cfy9hTc1IsaAjrMFQmP4EBMPW2pdHm4KHhk=.63abbeb6-6b90-4dfc-a166-e326c86cd228@github.com>
Message-ID: <XgLxo4kSCzsWM4yl-K4LTDzilsK8IT11uNqnQwJuyzA=.7456783b-fe89-45a7-ac1a-db6c0d19eb39@github.com>

On Thu, 29 May 2025 22:21:12 GMT, Phil Race <prr at openjdk.org> wrote:

> it is more readable (subjective)

Funny... when I first wrote this code I thought that style was better, but now I see it differently. But yeah, it is subjective.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24907#issuecomment-2920818521

From serb at openjdk.org  Fri May 30 00:06:04 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 30 May 2025 00:06:04 GMT
Subject: RFR: 8358057: Update validation of ICC_Profile header data
Message-ID: <mYmaF_Bcw_3vxMlSpjTi6pxk19ISh4_OWMs7lgQs47w=.cf6eecf8-1faf-4d0f-af41-dcb9ea6d8770@github.com>

The [next PR](https://github.com/openjdk/jdk/pull/23044) introduces several new methods to the ICC_Profile class:
-  getProfileClass(byte[])
-  getColorSpaceType(byte[])
-  getPCSType(byte[])
-  checkRenderingIntent(byte[])

These new methods extract data directly from the provided byte array rather than relying on the profile instance. The first three methods essentially duplicate the existing ones (getProfileClass(), getColorSpaceType(), getPCSType()).

It is possible to update implementation:
- The existing methods getColorSpaceType() and getPCSType() could delegate to the new getColorSpaceType(byte[]) and getPCSType(byte[]) methods.
- The checkRenderingIntent(byte[]) method could be updated to report the actual invalid intent value when an error occurs

Tests:
 - Old ValidateICCHeaderData test is update to verify the new output of the checkRenderingIntent
 - New RenderingIntentStressTest test is added to check the next part of the icc_spec:

          * ICC spec: only the least-significant 16 bits encode the rendering
          * intent. The most significant 16 bits must be zero and can be ignored.
          * See https://www.color.org/ICC1v42_2006-05.pdf, section 7.2.15.



@honkar-jdk please take a look.

Note: There is currently an inconsistency in the usage of `getData(icSigHead)` vs `getData(cmmProfile(), icSigHead)` throughout the codebase. I plan to address this separately.

-------------

Commit messages:
 - Create RenderingIntentStressTest.java
 - Update getColorSpaceType and getPCSType
 - Update checkRenderingIntent

Changes: https://git.openjdk.org/jdk/pull/25519/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25519&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358057
  Stats: 141 lines in 3 files changed: 112 ins; 12 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/25519.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25519/head:pull/25519

PR: https://git.openjdk.org/jdk/pull/25519

From honkar at openjdk.org  Fri May 30 00:23:10 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 30 May 2025 00:23:10 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java [v4]
In-Reply-To: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
Message-ID: <MDV4t9orGZ6OfEl8IoynXZ4PbX9qqAOQZps1O0gungs=.4eac9173-6b0e-4d77-afab-8a8396fcd6e0@github.com>

> CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs.
> 
> Test failure is not reproducible when the test is run individually (multiple times) on CI.
> 
> Rewritten the test and added debug logs that will be helpful to figure out the issue. 
> 
> - Added code to capture screenshot (entire screen as well as the frame) in case of failure.
> - Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  added back screencapture code to paint method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25279/files
  - new: https://git.openjdk.org/jdk/pull/25279/files/707ed6df..73861a9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25279&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25279&range=02-03

  Stats: 29 lines in 1 file changed: 11 ins; 10 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25279.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25279/head:pull/25279

PR: https://git.openjdk.org/jdk/pull/25279

From honkar at openjdk.org  Fri May 30 00:34:52 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 30 May 2025 00:34:52 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java [v4]
In-Reply-To: <vHSyErxHa9Qj3AXT--S2xsTeHcz06CmVbLq3IRuCnPs=.10076546-bcde-409a-84be-9e4f403de898@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
 <-lBIVrQXyxII4hEx6bRTJaM9dtFYWTgu7ULBFS-5kOQ=.a653a92e-702d-48d2-b6fa-50d134d4996d@github.com>
 <vHSyErxHa9Qj3AXT--S2xsTeHcz06CmVbLq3IRuCnPs=.10076546-bcde-409a-84be-9e4f403de898@github.com>
Message-ID: <n-QkhTLb4TNA4NeG1XjI0uuk-e8YvF53BWQtFXnoF1o=.716a24e1-6dd5-4f2f-96aa-8f3ab40f8ef8@github.com>

On Thu, 29 May 2025 10:52:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added back screencapture code to paint method
>
> test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 57:
> 
>> 55:         // copy the region such that part of it goes below the bottom of the
>> 56:         // destination surface
>> 57:         g2d.copyArea(0, 10, 50, h-10, 60, 10);
> 
> The new version looks like a different test, previously we copyArea from the paint method for the awt frame, then call sync to flush all rendering, then check the rendering on screen, and all of that on "each render frame".
> 
> Now it will draw everything in paint then sometime later(or even after a few repaints) we check the actual rendering(waitForIdle/delay(100))....

@mrserb 

Added back Toolkit.sync() and canvas capture to paint method. I'm not sure if I understood  _"each render frame"_.  Can you please explain? 


        BufferedImage capture = null;
        try {
            Thread.sleep(500);
            if (robot == null) robot = new Robot();
            Point pt1 = getLocationOnScreen();
            Rectangle rect = new Rectangle(pt1.x, pt1.y, 400, 400);
            capture = robot.createScreenCapture(rect);
        } catch (Exception e) {
            throw new RuntimeException("Problems handling Robot");
        }
        // Test pixels
        testRegion(capture, "green",          0,   0, 400,  10, 0xff00ff00);
        testRegion(capture, "original red",   0,  10,  50, 400, 0xffff0000);
        testRegion(capture, "background",    50,  10,  60, 400, 0xff000000);
        testRegion(capture, "in-between",    60,  10, 110,  20, 0xff000000);
        testRegion(capture, "copied red",    60,  20, 110, 400, 0xffff0000);
        testRegion(capture, "background",   110,  10, 400, 400, 0xff000000);


Isn't capture going to be the same image throughout? I'm not sure why it is passed as an extra argument to testRegion. It can be saved once as static BufferedImage var and the same can be used for testing or am I missing something?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2114942573

From honkar at openjdk.org  Fri May 30 00:40:11 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 30 May 2025 00:40:11 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java [v5]
In-Reply-To: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
Message-ID: <cg6sERqzXIdvtfckwoZ2U64Pi696TE3EFy3Fe0AA2eE=.cd19129d-4f51-4da8-b24e-c0d3fdd3afb9@github.com>

> CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs.
> 
> Test failure is not reproducible when the test is run individually (multiple times) on CI.
> 
> Rewritten the test and added debug logs that will be helpful to figure out the issue. 
> 
> - Added code to capture screenshot (entire screen as well as the frame) in case of failure.
> - Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  added testRegion back to paint()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25279/files
  - new: https://git.openjdk.org/jdk/pull/25279/files/73861a9c..e9c5b3ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25279&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25279&range=03-04

  Stats: 16 lines in 1 file changed: 8 ins; 8 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25279.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25279/head:pull/25279

PR: https://git.openjdk.org/jdk/pull/25279

From dnguyen at openjdk.org  Fri May 30 00:42:50 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 30 May 2025 00:42:50 GMT
Subject: RFR: 8357598: Toolkit.removeAWTEventListener should handle null
 listener in AWTEventListenerProxy [v2]
In-Reply-To: <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
 <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
Message-ID: <GxHA201G-kbm38cbr9ykIDyEpvMpTEkXZGp6F08ip74=.25f6b111-fe0e-46c4-b715-bbfdde9ff38a@github.com>

On Tue, 27 May 2025 17:38:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
>> 
>> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
>> 
>> One of the test is updated just to touch that codepath.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

LGTM. Ran a test job myself and everything looks good.

-------------

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25401#pullrequestreview-2879913986

From dgredler at openjdk.org  Fri May 30 00:47:53 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 30 May 2025 00:47:53 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377 [v4]
In-Reply-To: <Exw_xAvebaFaPnU85goD4Iq-6ayndgcniCIEL9zufZE=.7c3dad4a-d994-4b55-b1e3-047f1ed4b2c1@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
 <DVwbyup3ory0QwNRsyxVu7zjhVMDI-xjK82V9_DRy6k=.502c6320-ae1a-4919-9260-fb879f9f2994@github.com>
 <Exw_xAvebaFaPnU85goD4Iq-6ayndgcniCIEL9zufZE=.7c3dad4a-d994-4b55-b1e3-047f1ed4b2c1@github.com>
Message-ID: <H3MHyWdXoUpdJk7vLWzKQc87g5g8HXmc_i1w9CTkST4=.8353aad6-b0c3-4968-82b3-a5ff6a30170a@github.com>

On Thu, 29 May 2025 21:55:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove one last now-unnecessary whitespace check inside CMap
>
> src/java.desktop/share/classes/sun/print/RasterPrinterJob.java line 2485:
> 
>> 2483:         for (int i = 0; i < len; i++) {
>> 2484:             char c = in_chars[i];
>> 2485:             if (c > '\r' || c < '\t' || c == '\u000b' || c == '\u000c')  {
> 
> hmm. looks like you are fixing a bug here. I think those == were supposed to be !=

Hah, I've had to check it a few times but I do think the code was correct -- just formulated in a confusing way, probably as a micro-optimization.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24412#discussion_r2114953676

From dgredler at openjdk.org  Fri May 30 00:54:54 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 30 May 2025 00:54:54 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377 [v4]
In-Reply-To: <H3MHyWdXoUpdJk7vLWzKQc87g5g8HXmc_i1w9CTkST4=.8353aad6-b0c3-4968-82b3-a5ff6a30170a@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
 <DVwbyup3ory0QwNRsyxVu7zjhVMDI-xjK82V9_DRy6k=.502c6320-ae1a-4919-9260-fb879f9f2994@github.com>
 <Exw_xAvebaFaPnU85goD4Iq-6ayndgcniCIEL9zufZE=.7c3dad4a-d994-4b55-b1e3-047f1ed4b2c1@github.com>
 <H3MHyWdXoUpdJk7vLWzKQc87g5g8HXmc_i1w9CTkST4=.8353aad6-b0c3-4968-82b3-a5ff6a30170a@github.com>
Message-ID: <gdjdh7zWGJpItzQwQQE6Hb3awN5rYR_EIdCP2a8R22A=.1cf6ebd0-3cb4-4555-8be1-b97cfe2b8356@github.com>

On Fri, 30 May 2025 00:45:36 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/print/RasterPrinterJob.java line 2485:
>> 
>>> 2483:         for (int i = 0; i < len; i++) {
>>> 2484:             char c = in_chars[i];
>>> 2485:             if (c > '\r' || c < '\t' || c == '\u000b' || c == '\u000c')  {
>> 
>> hmm. looks like you are fixing a bug here. I think those == were supposed to be !=
>
> Hah, I've had to check it a few times but I do think the code was correct -- just formulated in a confusing way, probably as a micro-optimization.

Although I do think we will end up wanting to add Vertical Tab and Form Feed to the list of ignored whitespace chars later, as part of JDK-8356803.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24412#discussion_r2114958892

From psadhukhan at openjdk.org  Fri May 30 02:10:02 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 30 May 2025 02:10:02 GMT
Subject: RFR: 8357299: Graphics copyArea doesn't copy any pixels when there
 is overflow
In-Reply-To: <2AKd-LMlhNMKnrNUXmxwYyyfDGIvFOESfwSAK-hJRfw=.7de2e85d-8412-4d25-bff8-5d4f6c9d1854@github.com>
References: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
 <rYu0g4fVWaCX7yxGhNgYijkzsYIUjWnnGdwiq3u5ZeU=.09c39483-6204-4490-b952-5c4ed8cfdc6b@github.com>
 <tugH2JMkemfDK7hiEvhXNORN7OxSyLsKGPO0bjNicn8=.27d05a6d-4659-4bc6-96ad-fd31fd8ae56f@github.com>
 <vbcJsxfrOgq8jE5MsCxXKfyYt4E_MTT6Fin2tOLgrEg=.a88f543a-1284-4a15-bdeb-08a3b6e9620e@github.com>
 <2AKd-LMlhNMKnrNUXmxwYyyfDGIvFOESfwSAK-hJRfw=.7de2e85d-8412-4d25-bff8-5d4f6c9d1854@github.com>
Message-ID: <vv3aqxTzqMaU9rT1GIvnXiwiGUTklYb5BWpXZWWgVzU=.ca29af1d-a4a7-41c4-9cd2-83953bfb214b@github.com>

On Thu, 29 May 2025 23:29:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> ok
>
>>That is because down below it anyway calls SurfaceData_IntersectBounds(&dstInfo.bounds, &clipInfo.bounds); 
> so it should clip to clipInfo.bounds there.
> 
> In addition to intersecting dst with clip, you're also intersecting src with clip, which seems incorrect. A better approach might be to compute the drawable width based on the non-overflowing range for both src and dst, and then proceed with the original logic.
> 
> BTW I have not checked MaskBlit_MaskBlit yet it might require a similar update.

We have not found any problem with that part of code so far..We have addressed the issue that was raised.
MaskBlit might require similar update but since it was not proven to be problematic (we waited for your feedback) and since RDP1 is approaching, we will integrate this and you can come back with POC for us to check..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25340#discussion_r2115019947

From psadhukhan at openjdk.org  Fri May 30 02:10:04 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 30 May 2025 02:10:04 GMT
Subject: Integrated: 8357299: Graphics copyArea doesn't copy any pixels when
 there is overflow
In-Reply-To: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
References: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
Message-ID: <yt0Iyo95t_QGdkSgEzop9DmEFNewR0iqWIuJkUL24TI=.f0e187ce-5e07-4a41-93be-72cacaedffe0@github.com>

On Wed, 21 May 2025 03:17:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Graphics copyArea overflow check bails out of copying pixels if there is overflow.
> The spec says ""If a portion of the source rectangle lies outside the bounds of the component, or is obscured by another window or component, {@code copyArea} *will be unable to copy* the associated pixels"
> 
> which suggests that we should always copy the parts inside the bounds and never the parts outside the bounds
> but it seems currently, in the case of overflow it no longer copies any pixels, including the parts that are inside. 
> So, the fix clips the copyarea region to clip bounds so it will only affect pixels within the valid bounds, and any pixels outside will be ignored.

This pull request has now been integrated.

Changeset: 64503c78
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64503c784bbddc638ce0098f5c6ef0cb81cbf938
Stats:     74 lines in 2 files changed: 62 ins; 5 del; 7 mod

8357299: Graphics copyArea doesn't copy any pixels when there is overflow

Reviewed-by: achung, kizune, prr

-------------

PR: https://git.openjdk.org/jdk/pull/25340

From serb at openjdk.org  Fri May 30 02:40:00 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 30 May 2025 02:40:00 GMT
Subject: RFR: 8357299: Graphics copyArea doesn't copy any pixels when there
 is overflow
In-Reply-To: <vv3aqxTzqMaU9rT1GIvnXiwiGUTklYb5BWpXZWWgVzU=.ca29af1d-a4a7-41c4-9cd2-83953bfb214b@github.com>
References: <nELVLO_ejbI2nw8beMOGtc0EMJCsvvZZMPASHrweyWw=.c3b147ad-8b4e-4af1-8949-a2b18ce06c26@github.com>
 <rYu0g4fVWaCX7yxGhNgYijkzsYIUjWnnGdwiq3u5ZeU=.09c39483-6204-4490-b952-5c4ed8cfdc6b@github.com>
 <tugH2JMkemfDK7hiEvhXNORN7OxSyLsKGPO0bjNicn8=.27d05a6d-4659-4bc6-96ad-fd31fd8ae56f@github.com>
 <vbcJsxfrOgq8jE5MsCxXKfyYt4E_MTT6Fin2tOLgrEg=.a88f543a-1284-4a15-bdeb-08a3b6e9620e@github.com>
 <2AKd-LMlhNMKnrNUXmxwYyyfDGIvFOESfwSAK-hJRfw=.7de2e85d-8412-4d25-bff8-5d4f6c9d1854@github.com>
 <vv3aqxTzqMaU9rT1GIvnXiwiGUTklYb5BWpXZWWgVzU=.ca29af1d-a4a7-41c4-9cd2-83953bfb214b@github.com>
Message-ID: <ND8Qn3IFcgEJsdXeDt2eSgQCVvoAHLy0gDSrFk124dY=.4cca5c26-6b1b-4ccf-b1ca-372c7466a7e3@github.com>

On Fri, 30 May 2025 02:06:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>We have not found any problem with that part of code so far..

This is incorrect because the clip bounds are relative to the destination (dst), so you cannot intersect them directly with the source (src) surface. The usage of UNSAFE_TO_SUB below is also wrong, we cannot just exists.

filed https://bugs.openjdk.org/browse/JDK-8358103

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25340#discussion_r2115043873

From serb at openjdk.org  Fri May 30 04:16:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 30 May 2025 04:16:02 GMT
Subject: RFR: 8358107: Rollback JDK-8357299 changeset
Message-ID: <zqrd4zODgKQpF2N3MzWB-R7UZrUq3mfLfhzNJ5WEbeA=.56313fa6-a2b3-4fa7-968b-95fc388d2007@github.com>

The patch for [JDK-8357299](https://bugs.openjdk.org/browse/JDK-8357299) does not completely fix the regression it was intended to address. Instead of bailing out on overflow, it introduces additional logic around src and clip, which might lead to attempts to draw invalid source pixels.

A test case demonstrating the issue is attached to [JDK-8358103](https://bugs.openjdk.org/browse/JDK-8358103)(passed on jdk22 failed on latest openjdk/jdk).

There are some unresolved discussions related to that patch, see [PR](https://github.com/openjdk/jdk/pull/25340). I believe it would be better to bail out early in case of overflow than risk incorrect calculations. 

Therefore, I propose reverting [JDK-8357299](https://bugs.openjdk.org/browse/JDK-8357299) until a proper fix is available. This approach would also simplify backports, since only the patch for [JDK-8358103](https://bugs.openjdk.org/browse/JDK-8358103) would need to be backported

@prsadhuk, @prrace please take a look

-------------

Commit messages:
 - Revert "8357299: Graphics copyArea doesn't copy any pixels when there is overflow"

Changes: https://git.openjdk.org/jdk/pull/25537/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25537&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358107
  Stats: 74 lines in 2 files changed: 5 ins; 62 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25537/head:pull/25537

PR: https://git.openjdk.org/jdk/pull/25537

From psadhukhan at openjdk.org  Fri May 30 04:55:51 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 30 May 2025 04:55:51 GMT
Subject: RFR: 8358107: Rollback JDK-8357299 changeset
In-Reply-To: <zqrd4zODgKQpF2N3MzWB-R7UZrUq3mfLfhzNJ5WEbeA=.56313fa6-a2b3-4fa7-968b-95fc388d2007@github.com>
References: <zqrd4zODgKQpF2N3MzWB-R7UZrUq3mfLfhzNJ5WEbeA=.56313fa6-a2b3-4fa7-968b-95fc388d2007@github.com>
Message-ID: <xMy0b0a7FFapeTbnXSjvCk5Gb9LEdah96WYjedZKUvk=.f473cea0-3fc0-4fc3-a6bb-edf130a76d65@github.com>

On Fri, 30 May 2025 04:11:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The patch for [JDK-8357299](https://bugs.openjdk.org/browse/JDK-8357299) does not completely fix the regression it was intended to address. Instead of bailing out on overflow, it introduces additional logic around src and clip, which might lead to attempts to draw invalid source pixels.
> 
> A test case demonstrating the issue is attached to [JDK-8358103](https://bugs.openjdk.org/browse/JDK-8358103)(passed on jdk22 failed on latest openjdk/jdk).
> 
> There are some unresolved discussions related to that patch, see [PR](https://github.com/openjdk/jdk/pull/25340). I believe it would be better to bail out early in case of overflow than risk incorrect calculations. 
> 
> Therefore, I propose reverting [JDK-8357299](https://bugs.openjdk.org/browse/JDK-8357299) until a proper fix is available. This approach would also simplify backports, since only the patch for [JDK-8358103](https://bugs.openjdk.org/browse/JDK-8358103) would need to be backported
> 
> @prsadhuk, @prrace please take a look

Marked as reviewed by psadhukhan (Reviewer).

> A test case demonstrating the issue is attached to [JDK-8358103](https://bugs.openjdk.org/browse/JDK-8358103)(passed on jdk22 failed on latest openjdk/jdk).

I believe this new testcase is also failing with jdk24.0.1 too where UNSAFE_TO_ADD macro was added for overflow check and caused [JDK-8357299](https://bugs.openjdk.org/browse/JDK-8357299) issue so both testcase is failing with jdk24.0.1
but if you feel the earlier bailout is better than this, then it's ok.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25537#pullrequestreview-2880172293
PR Comment: https://git.openjdk.org/jdk/pull/25537#issuecomment-2921224425

From abhiscxk at openjdk.org  Fri May 30 06:28:00 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 30 May 2025 06:28:00 GMT
Subject: RFR: 8341311: [Accessibility, macOS,
 VoiceOver] VoiceOver announces
 incorrect number of items in submenu of JPopupMenu [v3]
In-Reply-To: <xMzFldszd76f1p5RCDnTP-DZNBOmO1X4jQsWasiMMq8=.a51a8ff4-7ec6-47f2-a66f-5674601405d3@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
 <xMzFldszd76f1p5RCDnTP-DZNBOmO1X4jQsWasiMMq8=.a51a8ff4-7ec6-47f2-a66f-5674601405d3@github.com>
Message-ID: <FLLQc2lCmfieYPwbZh0hACLB-yFjFafqFjIqJjRTWys=.06838e01-0047-4619-b998-8a8ae89f25ef@github.com>

On Thu, 29 May 2025 07:03:58 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver announce incorrect number of child for a submenu of JPopupMenu when it is visible for the first time only. After that VO is able to announce the number of items correctly.
>> 
>> **Issue:** Problem is with the a11y subsystem method call to get the accessible children details.
>> 
>> **Analysis:** When the Submenu of a JPopupMenu is opened, accessible component of PopupMenu is created dynamically in the native side implementation and `PostMenuOpened` notification is sent to the a11y subsystem for the newly created PopupMenu. Once the notification is sent to a11y sub-system, it invokes the `accessibilityChildren` method to get the children details for the menu component. A11y subsystem always retrieve the information of the root level PopupMenu irrespective of the submenu's PopupMenu (PopupMenu is associated with each JMenu) and thus announce the root level PopupMenu child count which is incorrect.
>> 
>> **Proposed Fix:** Proposed fix is to ensure the correct child details are sent back to a11y sub-system for correct announcement. So, whenever the `accessibilityChildren` method is invoked, first try to find out the current accessible PopupMenu which is opened for the Submenu and then return the child details.
>> 
>> **Testing :** Manual test case is attached to verify the fix and there is no failure with fix in CI pipeline.
>> 
>> `Current fix also ensures the correct child counts are announced for the JMenu's Submenu which are present in the JMenubar.`
>> 
>> **Note :** While verifying the fix, a new issue is unearthed for multi-level submenu where VO is failed to announce the Submenu's text. Since the issue exists without the proposed fix too, it shall be treated as a new bug finding and will raise a separate JBS issue.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code optimization

>Note : While verifying the fix, a new issue is unearthed for multi-level submenu where VO is failed to announce the Submenu's text. Since the issue exists without the proposed fix too, it shall be treated as a new bug finding and will raise a separate JBS issue.

@azuev-java @savoptik Created a new JBS bug [JDK-8358121](https://bugs.openjdk.org/browse/JDK-8358121) to track the multi level submenu text announcement issue

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25470#issuecomment-2921351710

From abhiscxk at openjdk.org  Fri May 30 06:28:01 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 30 May 2025 06:28:01 GMT
Subject: Integrated: 8341311: [Accessibility,macOS,VoiceOver] VoiceOver
 announces incorrect number of items in submenu of JPopupMenu
In-Reply-To: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
References: <R00_0DjxMricz6XaVnTMW6v4ABCwzvbvXU8tWFRgBjc=.361358e5-7373-42e8-ae2b-4cd4a1ab9a21@github.com>
Message-ID: <6pWCrhhcjDaluh6TQLW8cNjGvmwPKnECWH00HGZhdSU=.91ad57f0-e53b-4965-8e4d-3f8c3d91ceae@github.com>

On Tue, 27 May 2025 17:01:16 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> VoiceOver announce incorrect number of child for a submenu of JPopupMenu when it is visible for the first time only. After that VO is able to announce the number of items correctly.
> 
> **Issue:** Problem is with the a11y subsystem method call to get the accessible children details.
> 
> **Analysis:** When the Submenu of a JPopupMenu is opened, accessible component of PopupMenu is created dynamically in the native side implementation and `PostMenuOpened` notification is sent to the a11y subsystem for the newly created PopupMenu. Once the notification is sent to a11y sub-system, it invokes the `accessibilityChildren` method to get the children details for the menu component. A11y subsystem always retrieve the information of the root level PopupMenu irrespective of the submenu's PopupMenu (PopupMenu is associated with each JMenu) and thus announce the root level PopupMenu child count which is incorrect.
> 
> **Proposed Fix:** Proposed fix is to ensure the correct child details are sent back to a11y sub-system for correct announcement. So, whenever the `accessibilityChildren` method is invoked, first try to find out the current accessible PopupMenu which is opened for the Submenu and then return the child details.
> 
> **Testing :** Manual test case is attached to verify the fix and there is no failure with fix in CI pipeline.
> 
> `Current fix also ensures the correct child counts are announced for the JMenu's Submenu which are present in the JMenubar.`
> 
> **Note :** While verifying the fix, a new issue is unearthed for multi-level submenu where VO is failed to announce the Submenu's text. Since the issue exists without the proposed fix too, it shall be treated as a new bug finding and will raise a separate JBS issue.

This pull request has now been integrated.

Changeset: e33eeeea
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e33eeeea04fc7899bf66b0a2fdaccc30060854b4
Stats:     172 lines in 3 files changed: 170 ins; 0 del; 2 mod

8341311: [Accessibility,macOS,VoiceOver] VoiceOver announces incorrect number of items in submenu of JPopupMenu

Reviewed-by: asemenov, kizune

-------------

PR: https://git.openjdk.org/jdk/pull/25470

From psadhukhan at openjdk.org  Fri May 30 06:42:51 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 30 May 2025 06:42:51 GMT
Subject: RFR: 8251928: [macos] the printer DPI always be 72,
 cause some content lost when print out
In-Reply-To: <rR0Z3tgI9pY3Bh5XTqUr2Q_wf4kspUitnygW5CgxHE4=.1f2586f7-b715-457f-88ed-247155d6fb90@github.com>
References: <rR0Z3tgI9pY3Bh5XTqUr2Q_wf4kspUitnygW5CgxHE4=.1f2586f7-b715-457f-88ed-247155d6fb90@github.com>
Message-ID: <mMOTGTlZqvwbNZI5QJ9TlIVtDkS-yqBgCTf5PYah3Lw=.163560ac-e088-4d77-b10d-42e6c5464379@github.com>

On Wed, 28 May 2025 10:29:17 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

> The fix for the https://bugs.openjdk.org/browse/JDK-8251928.
> 
> **Description**.
> This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob.
> 
> As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ):
> 1. Convert the user-space point, size, or rectangle value to device space coordinates;
> 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary;
> 3. Convert the normalized value back to user space;
> 4. Draw your content using the adjusted value. 
>     
> The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI.
> The 2-nd step is a drawing process in the java code (without changes).
> The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI.
> The 4-th step is a drawing process in the native code (without changes).
> 
> **Tests**.
> I run all tests from javax.print package and there is no any regression.
> New test covers macOS and Linux only because we know its default DPI - 300.

While running PDFBOX4935PrintDpi  testcase from the JBS, it is showing with your fix
ScaleX: 4.166666
ScaleY: 4.166666
DPI = 300

while printing to pdf. Shouldn't the scale be shown as 2.0 for retina display while doing pdf printing?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25489#issuecomment-2921381067

From tr at openjdk.org  Fri May 30 09:45:52 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 30 May 2025 09:45:52 GMT
Subject: RFR: 8357598: Toolkit.removeAWTEventListener should handle null
 listener in AWTEventListenerProxy [v2]
In-Reply-To: <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
 <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
Message-ID: <qaUTWc7UC985atmIfiHl4nX6uFZBIimKvOfpsjidtnc=.28046a83-2ea1-4942-a860-0b7b39829320@github.com>

On Tue, 27 May 2025 17:38:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
>> 
>> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
>> 
>> One of the test is updated just to touch that codepath.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java line 169:

> 167:         AWTEventListener[] array = tk.getAWTEventListeners();
> 168:         if (array == null || array.length != expected) {
> 169:             System.out.println("[Simple test failed!!]");

I don't think this print statement is required?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25401#discussion_r2115522289

From tr at openjdk.org  Fri May 30 09:55:54 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 30 May 2025 09:55:54 GMT
Subject: RFR: 8357598: Toolkit.removeAWTEventListener should handle null
 listener in AWTEventListenerProxy [v2]
In-Reply-To: <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
 <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
Message-ID: <5esyds_XiOkkKu-Az09lY9sXEBJ-v-2U-7M0xFbYIS8=.b3713dbe-4844-49dc-8c89-2057cb2d447b@github.com>

On Tue, 27 May 2025 17:38:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
>> 
>> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
>> 
>> One of the test is updated just to touch that codepath.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java line 24:

> 22:  */
> 23: 
> 24: /*

Suggestion:

/*
 * @test
 * @bug 4290704 8357598
 * @summary Test use of AWTEventListenerProxyTest class
 */


Most of the test follow this pattern for jtreg tags. It would be good if you use it too for code consistency.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25401#discussion_r2115549915

From tr at openjdk.org  Fri May 30 09:57:53 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 30 May 2025 09:57:53 GMT
Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in
 a password when double clicked at the starting and end of the text
 [v2]
In-Reply-To: <s3OIzucQgCh3B3WRjrTo8igD3OvZa7hQ8vkjTyEPN-4=.ef1de180-7366-4ff4-8838-f216f306d673@github.com>
References: <zz-73SqK7SlO2jnHNxCWunPOE7iHZiZVrN-PkqIMFfg=.18c45065-f8a3-48eb-9ae5-d6dd4a5c02dc@github.com>
 <s3OIzucQgCh3B3WRjrTo8igD3OvZa7hQ8vkjTyEPN-4=.ef1de180-7366-4ff4-8838-f216f306d673@github.com>
Message-ID: <2_AeOX3dM4DrUFwnZ8jdwQMSUm1wmyKu4bH3E_vDYE4=.27c80a84-ca3f-4659-b8b6-4dd66b4600f7@github.com>

On Mon, 26 May 2025 16:51:11 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Make sure AquaTextPasswordFieldUI can't use selectWordAction.
>> 
>> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI, but the AquaTextPasswordFieldUI (and SynthPasswordFieldUI) do NOT extend the BasicPasswordFieldUI, so they weren't inheriting this solution.
>> 
>> So the problem is partially about multiple inheritance.
>> 
>> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields.
>> 
>> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions.
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354646: Update copyright year

Marked as reviewed by tr (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 651:

> 649:                 TransferHandler.getPasteAction());
> 650: 
> 651:         if (getComponent() instanceof JPasswordField) {

Since the fix has been made in Basic, we should not restrict the test to Aqua L&F alone. It should be tested for all L&F. (For fix and for regression)

-------------

PR Review: https://git.openjdk.org/jdk/pull/25443#pullrequestreview-2880804268
PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2115555622

From tr at openjdk.org  Fri May 30 10:08:52 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 30 May 2025 10:08:52 GMT
Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in
 a password when double clicked at the starting and end of the text
 [v2]
In-Reply-To: <s3OIzucQgCh3B3WRjrTo8igD3OvZa7hQ8vkjTyEPN-4=.ef1de180-7366-4ff4-8838-f216f306d673@github.com>
References: <zz-73SqK7SlO2jnHNxCWunPOE7iHZiZVrN-PkqIMFfg=.18c45065-f8a3-48eb-9ae5-d6dd4a5c02dc@github.com>
 <s3OIzucQgCh3B3WRjrTo8igD3OvZa7hQ8vkjTyEPN-4=.ef1de180-7366-4ff4-8838-f216f306d673@github.com>
Message-ID: <NCdkUlHLFGXTZhJLQY7-NMwA7gEkqNoMAeFPZuxJTbU=.65b6b943-719c-4511-a13d-683b02884fd2@github.com>

On Mon, 26 May 2025 16:51:11 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Make sure AquaTextPasswordFieldUI can't use selectWordAction.
>> 
>> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI, but the AquaTextPasswordFieldUI (and SynthPasswordFieldUI) do NOT extend the BasicPasswordFieldUI, so they weren't inheriting this solution.
>> 
>> So the problem is partially about multiple inheritance.
>> 
>> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields.
>> 
>> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions.
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354646: Update copyright year

Since the fix has been made in Basic, we should not restrict the test to Aqua L&F alone. It should be tested for all L&F. (For fix and for regression)

Approved by mistake, mybad.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25443#pullrequestreview-2880829112
Changes requested by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25443#pullrequestreview-2880836177

From aivanov at openjdk.org  Fri May 30 10:52:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 30 May 2025 10:52:55 GMT
Subject: RFR: 8357598: Toolkit.removeAWTEventListener should handle null
 listener in AWTEventListenerProxy [v2]
In-Reply-To: <5esyds_XiOkkKu-Az09lY9sXEBJ-v-2U-7M0xFbYIS8=.b3713dbe-4844-49dc-8c89-2057cb2d447b@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
 <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
 <5esyds_XiOkkKu-Az09lY9sXEBJ-v-2U-7M0xFbYIS8=.b3713dbe-4844-49dc-8c89-2057cb2d447b@github.com>
Message-ID: <HGqaE1hT-w_Tsp-KI3Q-Cd06-94CtnQVToYQzYGe4As=.c5208fc5-9a8a-4016-a181-5853a6da3e4d@github.com>

On Fri, 30 May 2025 09:52:21 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java
>>   
>>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>
> test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: /*
> 
> Suggestion:
> 
> /*
>  * @test
>  * @bug 4290704 8357598
>  * @summary Test use of AWTEventListenerProxyTest class
>  */
> 
> 
> Most of the test follow this pattern for jtreg tags. It would be good if you use it too for code consistency.

Not required, but can be updated?

> test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java line 169:
> 
>> 167:         AWTEventListener[] array = tk.getAWTEventListeners();
>> 168:         if (array == null || array.length != expected) {
>> 169:             System.out.println("[Simple test failed!!]");
> 
> I don't think this print statement is required?

Probably not, but it follows the common pattern in the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25401#discussion_r2115659639
PR Review Comment: https://git.openjdk.org/jdk/pull/25401#discussion_r2115660853

From aivanov at openjdk.org  Fri May 30 10:52:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 30 May 2025 10:52:53 GMT
Subject: RFR: 8357598: Toolkit.removeAWTEventListener should handle null
 listener in AWTEventListenerProxy [v2]
In-Reply-To: <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
 <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
Message-ID: <MH3MYvzzowTGAKd8ppJgG9jFH0-sloz8my7lDVTxbsI=.983dc5b5-031d-4472-bda8-0669789bc230@github.com>

On Tue, 27 May 2025 17:38:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
>> 
>> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
>> 
>> One of the test is updated just to touch that codepath.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25401#pullrequestreview-2880953280

From vyazici at openjdk.org  Fri May 30 11:04:23 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 30 May 2025 11:04:23 GMT
Subject: RFR: 8357994: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [client]
Message-ID: <q_2Vt9xHzTL9_evxoUv1BE2z46fh1M1QgEBlr2xGmHo=.19abd633-a08f-4a51-88c3-d9fa6ac19271@github.com>

Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.

`stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357994 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to client libraries.

-------------

Commit messages:
 - Discard changes unrelated with client libraries
 - Revert superfluous changes
 - Revert changes to 3rd parties in `com/sun/org/apache`
 - Revert `PandocFilter` changes
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations

Changes: https://git.openjdk.org/jdk/pull/25543/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25543&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357994
  Stats: 17 lines in 3 files changed: 12 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25543.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25543/head:pull/25543

PR: https://git.openjdk.org/jdk/pull/25543

From rmarchenko at openjdk.org  Fri May 30 11:15:09 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 30 May 2025 11:15:09 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v15]
In-Reply-To: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
Message-ID: <2G_AAjpoCzSpYwfIFRxq35O0qoBAcUiEbheaeQp_e5E=.37c5209f-cd3a-48ad-aa42-72618796a057@github.com>

> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
> 
> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
> 
> ---------
> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default and static methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses.
> 
> When a subclass "overrides" a static method from a parent class `getMethodDescriptors()` behaves as follows:
> 
> - In case of a clash with a class method, the class version will take precedence rather than interface's one. 
> - If the same method appears in multiple classes/interfaces within the same hierarchy, the version from the most specific sub-interface will be selected.
> - If the method appears in classes/interfaces from different hierarchies, the result is undefined, either version can be returned.
> 
> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
> 
> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
> * Gettters/setters declared and not implemented are not considered.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  Addes test scenario 10

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23443/files
  - new: https://git.openjdk.org/jdk/pull/23443/files/779194f1..82bad7d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=13-14

  Stats: 97 lines in 1 file changed: 97 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23443/head:pull/23443

PR: https://git.openjdk.org/jdk/pull/23443

From rmarchenko at openjdk.org  Fri May 30 11:15:10 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 30 May 2025 11:15:10 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v9]
In-Reply-To: <frXGWTXYtH-H1BhL_FptSkfRX-wMgEWQhv6rbZg5zAo=.aadb952d-ebbd-47ef-ba61-f56ad9e7e2fd@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <MN6Tzr00BUOvCWgqkdiFoK_p-52Rk0heHEl3AOmARRM=.ec6f8e5d-f86d-4471-a277-66eb39d91392@github.com>
 <W-JTwAa8hkC2Y-QuqFNehMbY6pbjzY6whOXhHSH549A=.c1c8ba4b-4651-47d2-9148-6d4613703b72@github.com>
 <frXGWTXYtH-H1BhL_FptSkfRX-wMgEWQhv6rbZg5zAo=.aadb952d-ebbd-47ef-ba61-f56ad9e7e2fd@github.com>
Message-ID: <ORlghHci2CR5zwFSkaZPwS_Fki1iicz-4ckLqrTk4F4=.03db7b70-d153-47fa-9233-6b9c2ee88d56@github.com>

On Mon, 14 Apr 2025 13:28:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I ran this changes through CI testing, and the results are good.
>
>> I do not have any other comments, @aivanov-jdk please take a look.
>> 
>> @aivanov-jdk ?\
>> Could you review the PR, please?
> 
> I'm currently busy, I'll get to look at this PR as soon as I can.
> 
> Does it make sense to expand tests to cover cases that @mrserb brought up? With module system and exported vs non-exported classes and interfaces?

> > Could you review, please? @aivanov-jdk @mrserb @azvegint
> 
> Please update the test to cover the latest change.

 Done

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2922070937

From rmarchenko at openjdk.org  Fri May 30 11:20:39 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 30 May 2025 11:20:39 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v16]
In-Reply-To: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
Message-ID: <fYsv9kLjAhN-xp0JI9mHbXO90QD_unYDKnxNtemwNVc=.5a0201c5-f9e7-4503-896c-d5c399695659@github.com>

> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
> 
> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
> 
> ---------
> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default and static methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses.
> 
> When a subclass "overrides" a static method from a parent class `getMethodDescriptors()` behaves as follows:
> 
> - In case of a clash with a class method, the class version will take precedence rather than interface's one. 
> - If the same method appears in multiple classes/interfaces within the same hierarchy, the version from the most specific sub-interface will be selected.
> - If the method appears in classes/interfaces from different hierarchies, the result is undefined, either version can be returned.
> 
> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
> 
> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
> * Gettters/setters declared and not implemented are not considered.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  minor change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23443/files
  - new: https://git.openjdk.org/jdk/pull/23443/files/82bad7d8..8d46a88d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=14-15

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23443/head:pull/23443

PR: https://git.openjdk.org/jdk/pull/23443

From aivanov at openjdk.org  Fri May 30 13:35:02 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 30 May 2025 13:35:02 GMT
Subject: Integrated: 8357675: Amend headless message
In-Reply-To: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
References: <RlVKX-LXEhNdwgeb_uKhUoq7cp_BRlcabPqxsd3r6yw=.f48ce859-e011-47cd-b75b-8fcc59f28f9b@github.com>
Message-ID: <hkDvcvbll-_mHBZJKhwVl6qd8C9c6drhcad5w627GO4=.c40b3dea-914b-4918-8ef0-d6d7b4009539@github.com>

On Mon, 26 May 2025 16:38:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Currently, the default headless message ends with a comma instead of full stop and has an additional line break.
> 
> 
> Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException:
> No X11 DISPLAY variable was set,
> or no headful library support was found,
> but this program performed an operation which requires it,
> 
>         at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:158)
>         at java.desktop/java.awt.Window.<init>(Window.java:518)
>         at java.desktop/java.awt.Frame.<init>(Frame.java:428)
>         at java.desktop/javax.swing.JFrame.<init>(JFrame.java:224) 
> 
> 
> **Fix:**
> 
> Amend the message so that it ends with a full stop and remove the line break.
> 
> 
> Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException:
> No X11 DISPLAY variable was set,
> or no headful library support was found,
> but this program performed an operation which requires it.
>         at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:158)
>         at java.desktop/java.awt.Window.<init>(Window.java:518)
>         at java.desktop/java.awt.Frame.<init>(Frame.java:428)
>         at java.desktop/javax.swing.JFrame.<init>(JFrame.java:224)
> 
> 
> **Testing:**
> 
> Build a headless-only JDK (pass `--enable-headless-only` to the `configure` script) and create a `JFrame`.
> 
> It's impossible to create an automated test for this change, and I don't think a test is required, it's a cosmetic change.

This pull request has now been integrated.

Changeset: 12ee80ca
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12ee80cac754c1a6dd37191a9f80c01de8b659ad
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8357675: Amend headless message

Reviewed-by: prr, shade

-------------

PR: https://git.openjdk.org/jdk/pull/25453

From azvegint at openjdk.org  Fri May 30 13:53:51 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 30 May 2025 13:53:51 GMT
Subject: RFR: 8357688: Remove unnecessary List.get before remove in
 PopupFactory
In-Reply-To: <3fcUgHLShP5HamE2sRaXGbXg2gJzO9xOu28IQ_eVZyo=.1de88e4f-9519-4160-97b8-41072221fc07@github.com>
References: <3fcUgHLShP5HamE2sRaXGbXg2gJzO9xOu28IQ_eVZyo=.1de88e4f-9519-4160-97b8-41072221fc07@github.com>
Message-ID: <E5RKT_S9h8CWHVHeBePOrBoVfMaZNiI4B6FcFH1BgxI=.6500ecc8-f13d-41ff-9238-67d00142ad15@github.com>

On Sat, 17 May 2025 07:42:59 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate List.get+List.remove calls we can use single `removeFirst`. It's clearer.

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25283#pullrequestreview-2881430115

From duke at openjdk.org  Fri May 30 14:03:52 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Fri, 30 May 2025 14:03:52 GMT
Subject: RFR: 8251928: [macos] the printer DPI always be 72,
 cause some content lost when print out
In-Reply-To: <mMOTGTlZqvwbNZI5QJ9TlIVtDkS-yqBgCTf5PYah3Lw=.163560ac-e088-4d77-b10d-42e6c5464379@github.com>
References: <rR0Z3tgI9pY3Bh5XTqUr2Q_wf4kspUitnygW5CgxHE4=.1f2586f7-b715-457f-88ed-247155d6fb90@github.com>
 <mMOTGTlZqvwbNZI5QJ9TlIVtDkS-yqBgCTf5PYah3Lw=.163560ac-e088-4d77-b10d-42e6c5464379@github.com>
Message-ID: <lmbm5QaJQtciJo4OnoC-sT_msXjw2jtRQXcjOtm-Oks=.0628fd8f-de45-4541-a19b-9bd2f75675ab@github.com>

On Fri, 30 May 2025 06:40:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The fix for the https://bugs.openjdk.org/browse/JDK-8251928.
>> 
>> **Description**.
>> This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob.
>> 
>> As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ):
>> 1. Convert the user-space point, size, or rectangle value to device space coordinates;
>> 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary;
>> 3. Convert the normalized value back to user space;
>> 4. Draw your content using the adjusted value. 
>>     
>> The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI.
>> The 2-nd step is a drawing process in the java code (without changes).
>> The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI.
>> The 4-th step is a drawing process in the native code (without changes).
>> 
>> **Tests**.
>> I run all tests from javax.print package and there is no any regression.
>> New test covers macOS and Linux only because we know its default DPI - 300.
>
> While running PDFBOX4935PrintDpi  testcase from the JBS, it is showing with your fix
> ScaleX: 4.166666
> ScaleY: 4.166666
> DPI = 300
> 
> while printing to pdf. Shouldn't the scale be shown as 2.0 for retina display while doing pdf printing?

@prsadhuk  , no, the scale should be 4.166666.

As described in the drawing guide
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-SW6

> Units in the user space are based on the printer's point, which was used in the publishing industry to measure the size of content on the printed page. A single point is equivalent to 1/72 of an inch. Points were adopted by earlier versions of Mac OS as the standard resolution for content on the screen. OS X continues to use the same effective ?resolution? for user-space drawing.
> 
> Although a single point often corresponded directly to a pixel in the past, in OS X, that may not be the case. Points are not tied to the resolution of any particular device. If you draw a rectangle whose width and height are exactly three points, that does not mean it will be rendered on the screen as a three-pixel by three-pixel rectangle. On a 144 dpi screen, the rectangle might be rendered using six pixels per side, and on a 600-dpi printer, the rectangle would require 25 pixels per side. The actual translation from points to pixels is device dependent and handled for you automatically by OS X. 

So it does not matter what the actual device DPI is, we always use or see 72 on the java side.
I set the default printing DPI for macOS to 300 in this PR, so if you do not provide different value using javax.print.attribute.standard.PrinterResolution then the scaling should be 300/72 = 4.16666.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25489#issuecomment-2922481400

From duke at openjdk.org  Fri May 30 14:53:50 2025
From: duke at openjdk.org (Eirik Bakke)
Date: Fri, 30 May 2025 14:53:50 GMT
Subject: RFR: 8251928: [macos] the printer DPI always be 72,
 cause some content lost when print out
In-Reply-To: <rR0Z3tgI9pY3Bh5XTqUr2Q_wf4kspUitnygW5CgxHE4=.1f2586f7-b715-457f-88ed-247155d6fb90@github.com>
References: <rR0Z3tgI9pY3Bh5XTqUr2Q_wf4kspUitnygW5CgxHE4=.1f2586f7-b715-457f-88ed-247155d6fb90@github.com>
Message-ID: <P8yOwqFJRAKKzeK-7gVepneadXZD-Uzs54J6o8PhVvk=.fb765d7e-af9b-41b3-9d45-150056757d65@github.com>

On Wed, 28 May 2025 10:29:17 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

> The fix for the https://bugs.openjdk.org/browse/JDK-8251928.
> 
> **Description**.
> This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob.
> 
> As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ):
> 1. Convert the user-space point, size, or rectangle value to device space coordinates;
> 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary;
> 3. Convert the normalized value back to user space;
> 4. Draw your content using the adjusted value. 
>     
> The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI.
> The 2-nd step is a drawing process in the java code (without changes).
> The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI.
> The 4-th step is a drawing process in the native code (without changes).
> 
> **Tests**.
> I run all tests from javax.print package and there is no any regression.
> New test covers macOS and Linux only because we know its default DPI - 300.

Increasing the DPI in the Graphics2D transform on the Java side might have the side effect of also fixing this bug:

[JDK-8278222](https://bugs.openjdk.org/browse/JDK-8278222) [macos] Inaccurate letter spacing (kerning) when printing via java.awt.print

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25489#issuecomment-2922610942

From duke at openjdk.org  Fri May 30 16:52:14 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 30 May 2025 16:52:14 GMT
Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in
 a password when double clicked at the starting and end of the text
 [v3]
In-Reply-To: <zz-73SqK7SlO2jnHNxCWunPOE7iHZiZVrN-PkqIMFfg=.18c45065-f8a3-48eb-9ae5-d6dd4a5c02dc@github.com>
References: <zz-73SqK7SlO2jnHNxCWunPOE7iHZiZVrN-PkqIMFfg=.18c45065-f8a3-48eb-9ae5-d6dd4a5c02dc@github.com>
Message-ID: <CWxATbIMdtquQsHrQkk6gSS_qHrGHWf0hSvFV1AeAxI=.9c6e67a3-d6c0-4d27-9510-3fe3df961ca7@github.com>

> Make sure AquaTextPasswordFieldUI can't use selectWordAction.
> 
> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI, but the AquaTextPasswordFieldUI (and SynthPasswordFieldUI) do NOT extend the BasicPasswordFieldUI, so they weren't inheriting this solution.
> 
> So the problem is partially about multiple inheritance.
> 
> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields.
> 
> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions.

Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:

 - 8354646: move to /plaf/basic/ dir
   
   If this is longer focusing on Aqua then probably this should live in a directory focusing on BasicL&F
   
   This is partially in response to:
   https://github.com/openjdk/jdk/pull/25443#pullrequestreview-2880829112
 - 8354646: remove os.family=="mac"
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25443#pullrequestreview-2880829112

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25443/files
  - new: https://git.openjdk.org/jdk/pull/25443/files/bdbd51b0..a7709b7e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=01-02

  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443

PR: https://git.openjdk.org/jdk/pull/25443

From honkar at openjdk.org  Fri May 30 16:52:55 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 30 May 2025 16:52:55 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377
In-Reply-To: <yhi-ey0BSjzpDd9AetSugVTAfS79UEPSsVgByqxSRYY=.3f6bcb5e-0d22-4b32-8b79-cb64b10d6686@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
 <qAXldHcR9uja7Lnj-LCAkQvYUqcxsbc0LXC7pS6gsmo=.41fd8ffb-bee5-4358-a4ff-b86c7fd6bb5e@github.com>
 <7qRLx0aLwArI3Md49dSXjXVR_aqNzSfRWCo-59TcyYo=.e75861cf-bd30-4118-ab4b-53e6fe86b8f8@github.com>
 <o-RfCz8vaxQpRihpmsKQakcsMJTVoxh2tE1sQcM1rYI=.3b80a35f-ed45-4558-a88d-4b6d51ad4ef0@github.com>
 <yhi-ey0BSjzpDd9AetSugVTAfS79UEPSsVgByqxSRYY=.3f6bcb5e-0d22-4b32-8b79-cb64b10d6686@github.com>
Message-ID: <9q66ZT3geFmp0yNxaibi9o-C-wv7J_ON_Q3o-JebRtg=.bbd38ca8-6d8b-4f7b-ae9e-e3ddf236088f@github.com>

On Wed, 28 May 2025 20:25:23 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>>> @prrace Please don't approve yet. I was able to fix the code conflicts caused by PR #23665, but it looks like the logic does not layer nicely as there is now a test failure on macOS after the merge. I'm having a look and will let you know what I find.
>> 
>> And indeed the tests just finished and a test (not the new one, a previous one : IgnoredWhitespaceTest.java) failed on macOS x64 and ARM ..
>> 
>> java.lang.RuntimeException: for text '\t\t\t\t\tXXXXX' with font java.awt.Font[family=Dialog,name=Dialog,style=plain,size=40]: java.awt.Rectangle[x=300,y=271,width=123,height=28] != java.awt.Rectangle[x=365,y=271,width=123,height=28]
>> 	at IgnoredWhitespaceTest.assertEqual(IgnoredWhitespaceTest.java:127)
>> 	at IgnoredWhitespaceTest.test(IgnoredWhitespaceTest.java:103)
>> 	at IgnoredWhitespaceTest.test(IgnoredWhitespaceTest.java:69)
>> 	at IgnoredWhitespaceTest.main(IgnoredWhitespaceTest.java:49)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>> 	at java.base/java.lang.Thread.run(Thread.java:1447)
>> 
>> JavaTest Message: Test threw exception: java.lang.RuntimeException: for text '\t\t\t\t\tXXXXX' with font java.awt.Font[family=Dialog,name=Dialog,style=plain,size=40]: java.awt.Rectangle[x=300,y=271,width=123,height=28] != java.awt.Rectangle[x=365,y=271,width=123,height=28]
>> JavaTest Message: shutting down test
>
> @prrace This is ready for review again. I've updated the code to combine nicely with the recent whitespace fixes. The `test/jdk/java/awt/font`, `test/jdk/java/awt/print` and `test/jdk/java/awt/Graphics2D/DrawString` tests all pass for me locally on Windows, Linux and macOS.
> 
> Once these changes are integrated it should be relatively simple to address JDK-8356803 ("Test TextLayout/TestControls fails on windows & linux: line and paragraph separator show non-zero advance") and JDK-8356812 ("Create an automated version of TextLayout/TestControls").

@gredler In the process of reviewing this PR.

Just a headsup, JDK 25 RDP1 is next week (https://openjdk.org/projects/jdk/25/) in case you are planning to get the following fixes into 25:
[JDK-8356803](https://bugs.openjdk.org/browse/JDK-8356803) - Test TextLayout/TestControls fails on windows & linux: line and paragraph separator show non-zero advance
[JDK-8356812](https://bugs.openjdk.org/browse/JDK-8356812) - Create an automated version of TextLayout/TestControls

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24412#issuecomment-2922880879

From duke at openjdk.org  Fri May 30 17:04:34 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 30 May 2025 17:04:34 GMT
Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in
 a password when double clicked at the starting and end of the text
 [v4]
In-Reply-To: <zz-73SqK7SlO2jnHNxCWunPOE7iHZiZVrN-PkqIMFfg=.18c45065-f8a3-48eb-9ae5-d6dd4a5c02dc@github.com>
References: <zz-73SqK7SlO2jnHNxCWunPOE7iHZiZVrN-PkqIMFfg=.18c45065-f8a3-48eb-9ae5-d6dd4a5c02dc@github.com>
Message-ID: <t0BGawrsEW4vZ1qXmDgZTWkVWwjDeziLrti2bZ4-LcA=.eb9b7827-a279-43aa-b4b3-b72eb8325246@github.com>

> Make sure AquaTextPasswordFieldUI can't use selectWordAction.
> 
> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI, but the AquaTextPasswordFieldUI (and SynthPasswordFieldUI) do NOT extend the BasicPasswordFieldUI, so they weren't inheriting this solution.
> 
> So the problem is partially about multiple inheritance.
> 
> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields.
> 
> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions.

Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:

  8354646: updating bug summary to include 4231444
  
  This is partially in response to:
  https://github.com/openjdk/jdk/pull/25443#pullrequestreview-2880829112

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25443/files
  - new: https://git.openjdk.org/jdk/pull/25443/files/a7709b7e..de054277

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443

PR: https://git.openjdk.org/jdk/pull/25443

From duke at openjdk.org  Fri May 30 17:07:55 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 30 May 2025 17:07:55 GMT
Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in
 a password when double clicked at the starting and end of the text
 [v2]
In-Reply-To: <NCdkUlHLFGXTZhJLQY7-NMwA7gEkqNoMAeFPZuxJTbU=.65b6b943-719c-4511-a13d-683b02884fd2@github.com>
References: <zz-73SqK7SlO2jnHNxCWunPOE7iHZiZVrN-PkqIMFfg=.18c45065-f8a3-48eb-9ae5-d6dd4a5c02dc@github.com>
 <s3OIzucQgCh3B3WRjrTo8igD3OvZa7hQ8vkjTyEPN-4=.ef1de180-7366-4ff4-8838-f216f306d673@github.com>
 <NCdkUlHLFGXTZhJLQY7-NMwA7gEkqNoMAeFPZuxJTbU=.65b6b943-719c-4511-a13d-683b02884fd2@github.com>
Message-ID: <ejZJxJxVTvFwNpg6gSf5o8izBJIxCAkaJgu9CPffhcE=.92cd7f06-fb14-4622-a9ab-8565de65794a@github.com>

On Fri, 30 May 2025 10:03:56 GMT, Tejesh R <tr at openjdk.org> wrote:

> Since the fix has been made in Basic, we should not restrict the test to Aqua L&F alone. It should be tested for all L&F. (For fix and for regression)

OK, this is updated.

Since this is now meant to cover/discuss Basic L&F, I updated the test to reflect that it tests 4231444 too. (The code that this PR moves around is the solution from 4231444). That ticket was resolved in 2003 with no accompanying unit test.

(To be clear: Basic L&F  ux should not change at all with this PR, but Aqua L&F ux should (via class inheritance).)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25443#issuecomment-2922910842

From duke at openjdk.org  Fri May 30 17:13:24 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 30 May 2025 17:13:24 GMT
Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in
 a password when double clicked at the starting and end of the text
 [v5]
In-Reply-To: <zz-73SqK7SlO2jnHNxCWunPOE7iHZiZVrN-PkqIMFfg=.18c45065-f8a3-48eb-9ae5-d6dd4a5c02dc@github.com>
References: <zz-73SqK7SlO2jnHNxCWunPOE7iHZiZVrN-PkqIMFfg=.18c45065-f8a3-48eb-9ae5-d6dd4a5c02dc@github.com>
Message-ID: <9OsgP7Nt-I4n_uqYEzVaNAbp-3rYf4ozSFmiWyDoF5Q=.5dc3cbc6-942d-490b-b086-c9803c92ee14@github.com>

> Make sure AquaTextPasswordFieldUI can't use selectWordAction.
> 
> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI, but the AquaTextPasswordFieldUI (and SynthPasswordFieldUI) do NOT extend the BasicPasswordFieldUI, so they weren't inheriting this solution.
> 
> So the problem is partially about multiple inheritance.
> 
> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields.
> 
> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions.

Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:

  8354646: fixing typo in summary

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25443/files
  - new: https://git.openjdk.org/jdk/pull/25443/files/de054277..fe1b781c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443

PR: https://git.openjdk.org/jdk/pull/25443

From dgredler at openjdk.org  Fri May 30 17:29:54 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 30 May 2025 17:29:54 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377
In-Reply-To: <9q66ZT3geFmp0yNxaibi9o-C-wv7J_ON_Q3o-JebRtg=.bbd38ca8-6d8b-4f7b-ae9e-e3ddf236088f@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
 <qAXldHcR9uja7Lnj-LCAkQvYUqcxsbc0LXC7pS6gsmo=.41fd8ffb-bee5-4358-a4ff-b86c7fd6bb5e@github.com>
 <7qRLx0aLwArI3Md49dSXjXVR_aqNzSfRWCo-59TcyYo=.e75861cf-bd30-4118-ab4b-53e6fe86b8f8@github.com>
 <o-RfCz8vaxQpRihpmsKQakcsMJTVoxh2tE1sQcM1rYI=.3b80a35f-ed45-4558-a88d-4b6d51ad4ef0@github.com>
 <yhi-ey0BSjzpDd9AetSugVTAfS79UEPSsVgByqxSRYY=.3f6bcb5e-0d22-4b32-8b79-cb64b10d6686@github.com>
 <9q66ZT3geFmp0yNxaibi9o-C-wv7J_ON_Q3o-JebRtg=.bbd38ca8-6d8b-4f7b-ae9e-e3ddf236088f@github.com>
Message-ID: <VAzDd27rA92eofc3Gd85z9zBCE2ERIzyOglZtNgbiDA=.1a77b895-7103-494b-b6a5-7ac31c90be18@github.com>

On Fri, 30 May 2025 16:49:46 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> @prrace This is ready for review again. I've updated the code to combine nicely with the recent whitespace fixes. The `test/jdk/java/awt/font`, `test/jdk/java/awt/print` and `test/jdk/java/awt/Graphics2D/DrawString` tests all pass for me locally on Windows, Linux and macOS.
>> 
>> Once these changes are integrated it should be relatively simple to address JDK-8356803 ("Test TextLayout/TestControls fails on windows & linux: line and paragraph separator show non-zero advance") and JDK-8356812 ("Create an automated version of TextLayout/TestControls").
>
> @gredler In the process of reviewing this PR.
> 
> Just a headsup, JDK 25 RDP1 is next week (https://openjdk.org/projects/jdk/25/) in case you are planning to get the following fixes into 25:
> [JDK-8356803](https://bugs.openjdk.org/browse/JDK-8356803) - Test TextLayout/TestControls fails on windows & linux: line and paragraph separator show non-zero advance
> [JDK-8356812](https://bugs.openjdk.org/browse/JDK-8356812) - Create an automated version of TextLayout/TestControls

@honkar-jdk Thanks! It shouldn't take me more than a day to address those two issues once this PR has been integrated, so I think it will just depend on how long the reviews take. I'll keep a close eye out to keep things quick on my end, though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24412#issuecomment-2922956785

From prr at openjdk.org  Fri May 30 18:20:59 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 May 2025 18:20:59 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v14]
In-Reply-To: <-wufduQaG7bNR6MZksflsgCitkejQfKDFxXKNhB-2bQ=.998703db-0369-4d4c-98fc-1036e0479ed8@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <-wufduQaG7bNR6MZksflsgCitkejQfKDFxXKNhB-2bQ=.998703db-0369-4d4c-98fc-1036e0479ed8@github.com>
Message-ID: <lI293Q7bDaXvW8w_X9OT-bbQUIhfSwX9yDfJWlPEmag=.815990e5-f1fd-46ab-8e76-bea57758b443@github.com>

On Tue, 27 May 2025 17:35:17 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Currently on macOS when mouseMove is given an offscreen coordinate to move the mouse to, mouseMove will physically clamp to the edge of the screen, but if you try to grab the mouse location immediately after by using MouseInfo.getPointerInfo().getLocation() you will get the value of the offscreen point.
>> 
>> Windows and linux do this clamping and coordinate handling for us, but new distributions may not necessarily handle clamping the same way, so Robot should be checking for clamping rather than delegating it to native.
>> 
>> This fix updates shared code to cache the screen bounds and adds a check to not exceed the bounds in mouseMove. The caching is done in the Robot constructor, so if the screen bounds changes the constructor must be called again to update to the new bounds.
>
> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add logging to test
>  - test require macos, spacing in crobot

Feedback question with native reproducer sent to Apple on 5/22/25, follow up email sent the same day. No reply to either.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2923087053

From abhiscxk at openjdk.org  Fri May 30 18:49:55 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 30 May 2025 18:49:55 GMT
Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates
 too many frames on Linux [v6]
In-Reply-To: <NmZrzADfGzwZQAlsWdQAh4_ksyqHhZiRAQn95l_WBCc=.2e8e82ef-fb04-4d1c-a32e-98a8f8cec391@github.com>
References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com>
 <NmZrzADfGzwZQAlsWdQAh4_ksyqHhZiRAQn95l_WBCc=.2e8e82ef-fb04-4d1c-a32e-98a8f8cec391@github.com>
Message-ID: <ysl75LXddW1UYRn8Z8av5SoPWUJKP8ozSHCSEv9zNBw=.b0a9de25-4646-4caf-aed8-45afc76ac1bd@github.com>

On Fri, 9 May 2025 13:05:40 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Fixes issue in which the test fails when run on multi-screen machine.
>> 
>> Tested on Ubuntu 24.04, MacOS 15 and Windows 11
>> 
>> JTREG
>> 
>> runner starting test: java/awt/Frame/MultiScreenTest.java
>> runner finished test: java/awt/Frame/MultiScreenTest.java
>> Passed. Execution successful
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adds Override for overriden methods

You may remove setting the `title for instruction` and `row count` for PassFailJFrame.

test/jdk/java/awt/Frame/MultiScreenTest.java line 103:

> 101:             if (gc.length > 0) {
> 102:                 for (int i = 0; i < gc.length && i < 10; i++) {
> 103:                     JFrame f = new JFrame(gc[i]); //test JFrame( gc )

Suggestion:

                    JFrame f = new JFrame(gc[i]); // test JFrame( gc )

test/jdk/java/awt/Frame/MultiScreenTest.java line 104:

> 102:                 for (int i = 0; i < gc.length && i < 10; i++) {
> 103:                     JFrame f = new JFrame(gc[i]); //test JFrame( gc )
> 104:                     GCCanvas c = new GCCanvas(gc[i]);// test canvas( gc )

For consistency
Suggestion:

                    GCCanvas c = new GCCanvas(gc[i]); // test canvas( gc )

test/jdk/java/awt/Frame/MultiScreenTest.java line 112:

> 110:                     f.setTitle("Screen# " + Integer.toString(j) + ", GC#" + Integer.toString(i));
> 111:                     f.setSize(300, 200);
> 112:                     f.setLocation(400 + xoffs, (i * 150) + yoffs);// test

Suggestion:

                    f.setLocation(400 + xoffs, (i * 150) + yoffs); // test

test/jdk/java/awt/Frame/MultiScreenTest.java line 178:

> 176:         g.fillArc(150, 30, 30, 30, 0, 200);
> 177:     }
> 178: @Override

You may add a blank line before `@Override` line to maintain consistency. Also add 4 spaces to move `@Override` similar to other methods
Suggestion:

    @Override

-------------

PR Review: https://git.openjdk.org/jdk/pull/24752#pullrequestreview-2882210805
PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2116449111
PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2116448694
PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2116449951
PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2116450051

From honkar at openjdk.org  Fri May 30 18:50:54 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 30 May 2025 18:50:54 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377 [v4]
In-Reply-To: <DVwbyup3ory0QwNRsyxVu7zjhVMDI-xjK82V9_DRy6k=.502c6320-ae1a-4919-9260-fb879f9f2994@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
 <DVwbyup3ory0QwNRsyxVu7zjhVMDI-xjK82V9_DRy6k=.502c6320-ae1a-4919-9260-fb879f9f2994@github.com>
Message-ID: <xK7WIFldPHe6N9n_9Mhe-GUVuXprmUTE092bY1U02H8=.cd967d92-2866-456a-b587-8792d96898bc@github.com>

On Thu, 29 May 2025 11:10:38 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> It looks like this regression actually fits into a longer series of fixes / regressions in this area:
>> 
>> - [JDK-4517298](https://bugs.openjdk.org/browse/JDK-4517298) fixed metrics for zero-width characters, but broke some ligatures / glyph substitutions
>> - [JDK-7017058](https://bugs.openjdk.org/browse/JDK-7017058) fixed the ligatures / glyph substitutions, but broke some zero-width metrics
>> - [JDK-8208377](https://bugs.openjdk.org/browse/JDK-8208377) fixed some metrics and rendering for zero-width characters, but broke some ligatures / glyph substitutions
>> - Now, with this PR, we aim to fix the ligatures without re-breaking zero-width metrics and display
>> 
>> We have two different types of use cases pulling `CharToGlyphMapper` in two different directions: the users who need raw, untransformed glyph info, and the users who need normalized / transformed glyph info.
>> 
>> It looks to me like, in the current code base, the only `CharToGlyphMapper` user which requires raw font data is HarfBuzz (explicitly confirmed with the HarfBuzz team here: https://github.com/harfbuzz/harfbuzz/discussions/5234).
>> 
>> The regression mechanism at play here is that the HarfBuzz font callbacks are currently providing HarfBuzz with transformed glyph info (e.g. ZWJ -> INVISIBLE_GLYPH_ID), which prevents HarfBuzz from recognizing and applying the correct font GSUB substitutions (which involve ZWJ).
>> 
>> In order to fix this without (yet again) breaking metrics and display behavior elsewhere, I've added two methods to `CharToGlyphMapper` which provide access to raw glyph info, to be used by the HarfBuzz font callbacks: `charToGlyphRaw(int)` and `charToVariationGlyphRaw(int)`.
>> 
>> Note two intricacies related to `CompositeGlyphMapper`:
>> 1. We need to be careful to only cache raw (untransformed) values, to avoid conflicts between requests for a raw version of a glyph and a transformed version of the same glyph. Another option would have been two separate caches, but I don't think that's necessary.
>> 2. Consumers who are using `CompositeGlyphMapper.SLOTMASK` to check glyph slots (e.g. `FontRunIterator` and `CTextPipe`) will "see" invisible glyphs as having come from slot 0. This isn't new, and I think it's OK, but something to be aware of.
>> 
>> The glyph cache handling in `CCharToGlyphMapper` (for macOS) also requires care to avoid mixing value types.
>> 
>> Please also note that I'm not sure if the tweak to `sunFont.c` is being tested, since FFM is being used by default for Harf...
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove one last now-unnecessary whitespace check inside CMap

LGTM

-------------

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24412#pullrequestreview-2882218602

From duke at openjdk.org  Fri May 30 18:54:56 2025
From: duke at openjdk.org (duke)
Date: Fri, 30 May 2025 18:54:56 GMT
Subject: RFR: 8353230: Emoji rendering regression after JDK-8208377 [v4]
In-Reply-To: <DVwbyup3ory0QwNRsyxVu7zjhVMDI-xjK82V9_DRy6k=.502c6320-ae1a-4919-9260-fb879f9f2994@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
 <DVwbyup3ory0QwNRsyxVu7zjhVMDI-xjK82V9_DRy6k=.502c6320-ae1a-4919-9260-fb879f9f2994@github.com>
Message-ID: <VE2ZQYDW5D89GNAraoE8Zt6YK_4vkJRffh_8JjltAxc=.9d575722-0f38-448b-9a45-d84a12684168@github.com>

On Thu, 29 May 2025 11:10:38 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> It looks like this regression actually fits into a longer series of fixes / regressions in this area:
>> 
>> - [JDK-4517298](https://bugs.openjdk.org/browse/JDK-4517298) fixed metrics for zero-width characters, but broke some ligatures / glyph substitutions
>> - [JDK-7017058](https://bugs.openjdk.org/browse/JDK-7017058) fixed the ligatures / glyph substitutions, but broke some zero-width metrics
>> - [JDK-8208377](https://bugs.openjdk.org/browse/JDK-8208377) fixed some metrics and rendering for zero-width characters, but broke some ligatures / glyph substitutions
>> - Now, with this PR, we aim to fix the ligatures without re-breaking zero-width metrics and display
>> 
>> We have two different types of use cases pulling `CharToGlyphMapper` in two different directions: the users who need raw, untransformed glyph info, and the users who need normalized / transformed glyph info.
>> 
>> It looks to me like, in the current code base, the only `CharToGlyphMapper` user which requires raw font data is HarfBuzz (explicitly confirmed with the HarfBuzz team here: https://github.com/harfbuzz/harfbuzz/discussions/5234).
>> 
>> The regression mechanism at play here is that the HarfBuzz font callbacks are currently providing HarfBuzz with transformed glyph info (e.g. ZWJ -> INVISIBLE_GLYPH_ID), which prevents HarfBuzz from recognizing and applying the correct font GSUB substitutions (which involve ZWJ).
>> 
>> In order to fix this without (yet again) breaking metrics and display behavior elsewhere, I've added two methods to `CharToGlyphMapper` which provide access to raw glyph info, to be used by the HarfBuzz font callbacks: `charToGlyphRaw(int)` and `charToVariationGlyphRaw(int)`.
>> 
>> Note two intricacies related to `CompositeGlyphMapper`:
>> 1. We need to be careful to only cache raw (untransformed) values, to avoid conflicts between requests for a raw version of a glyph and a transformed version of the same glyph. Another option would have been two separate caches, but I don't think that's necessary.
>> 2. Consumers who are using `CompositeGlyphMapper.SLOTMASK` to check glyph slots (e.g. `FontRunIterator` and `CTextPipe`) will "see" invisible glyphs as having come from slot 0. This isn't new, and I think it's OK, but something to be aware of.
>> 
>> The glyph cache handling in `CCharToGlyphMapper` (for macOS) also requires care to avoid mixing value types.
>> 
>> Please also note that I'm not sure if the tweak to `sunFont.c` is being tested, since FFM is being used by default for Harf...
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove one last now-unnecessary whitespace check inside CMap

@gredler 
Your change (at version 95652a114b9a9ac6da2dd1c3722c22c130c69a33) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24412#issuecomment-2923189224

From dgredler at openjdk.org  Fri May 30 19:19:02 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 30 May 2025 19:19:02 GMT
Subject: Integrated: 8353230: Emoji rendering regression after JDK-8208377
In-Reply-To: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
References: <-N8_d2SHcl-h9yG8t6-WKGF_nGLJZQTu4ymMD2oPGrg=.651c8251-b235-4681-b82a-4ee680eb6593@github.com>
Message-ID: <g2J5YX0ws_4YqXq_HiqmhIBJbnYR_TIR8Icg5gGPMks=.c777255c-f72b-4701-b065-f199dfcb64e2@github.com>

On Thu, 3 Apr 2025 11:23:42 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> It looks like this regression actually fits into a longer series of fixes / regressions in this area:
> 
> - [JDK-4517298](https://bugs.openjdk.org/browse/JDK-4517298) fixed metrics for zero-width characters, but broke some ligatures / glyph substitutions
> - [JDK-7017058](https://bugs.openjdk.org/browse/JDK-7017058) fixed the ligatures / glyph substitutions, but broke some zero-width metrics
> - [JDK-8208377](https://bugs.openjdk.org/browse/JDK-8208377) fixed some metrics and rendering for zero-width characters, but broke some ligatures / glyph substitutions
> - Now, with this PR, we aim to fix the ligatures without re-breaking zero-width metrics and display
> 
> We have two different types of use cases pulling `CharToGlyphMapper` in two different directions: the users who need raw, untransformed glyph info, and the users who need normalized / transformed glyph info.
> 
> It looks to me like, in the current code base, the only `CharToGlyphMapper` user which requires raw font data is HarfBuzz (explicitly confirmed with the HarfBuzz team here: https://github.com/harfbuzz/harfbuzz/discussions/5234).
> 
> The regression mechanism at play here is that the HarfBuzz font callbacks are currently providing HarfBuzz with transformed glyph info (e.g. ZWJ -> INVISIBLE_GLYPH_ID), which prevents HarfBuzz from recognizing and applying the correct font GSUB substitutions (which involve ZWJ).
> 
> In order to fix this without (yet again) breaking metrics and display behavior elsewhere, I've added two methods to `CharToGlyphMapper` which provide access to raw glyph info, to be used by the HarfBuzz font callbacks: `charToGlyphRaw(int)` and `charToVariationGlyphRaw(int)`.
> 
> Note two intricacies related to `CompositeGlyphMapper`:
> 1. We need to be careful to only cache raw (untransformed) values, to avoid conflicts between requests for a raw version of a glyph and a transformed version of the same glyph. Another option would have been two separate caches, but I don't think that's necessary.
> 2. Consumers who are using `CompositeGlyphMapper.SLOTMASK` to check glyph slots (e.g. `FontRunIterator` and `CTextPipe`) will "see" invisible glyphs as having come from slot 0. This isn't new, and I think it's OK, but something to be aware of.
> 
> The glyph cache handling in `CCharToGlyphMapper` (for macOS) also requires care to avoid mixing value types.
> 
> Please also note that I'm not sure if the tweak to `sunFont.c` is being tested, since FFM is being used by default for HarfBuzz integration. (Is there a plan to remove...

This pull request has now been integrated.

Changeset: 94039e22
Author:    Daniel Gredler <dgredler at openjdk.org>
Committer: Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/94039e22bbe943888e858d8ae278145e2668526a
Stats:     384 lines in 13 files changed: 257 ins; 66 del; 61 mod

8353230: Emoji rendering regression after JDK-8208377

Reviewed-by: prr, honkar

-------------

PR: https://git.openjdk.org/jdk/pull/24412

From honkar at openjdk.org  Fri May 30 20:40:52 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 30 May 2025 20:40:52 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java [v5]
In-Reply-To: <cg6sERqzXIdvtfckwoZ2U64Pi696TE3EFy3Fe0AA2eE=.cd19129d-4f51-4da8-b24e-c0d3fdd3afb9@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
 <cg6sERqzXIdvtfckwoZ2U64Pi696TE3EFy3Fe0AA2eE=.cd19129d-4f51-4da8-b24e-c0d3fdd3afb9@github.com>
Message-ID: <54IGkudg-8nx4Tsb1_kGHteOnylYKpP7B4XNZ5O2BHM=.429d5cbd-6c3a-403f-ba4c-c15b1b9964ca@github.com>

On Fri, 30 May 2025 00:40:11 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs.
>> 
>> Test failure is not reproducible when the test is run individually (multiple times) on CI.
>> 
>> Rewritten the test and added debug logs that will be helpful to figure out the issue. 
>> 
>> - Added code to capture screenshot (entire screen as well as the frame) in case of failure.
>> - Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added testRegion back to paint()

@mrserb @aivanov-jdk  Can you please re-review when you get a chance?
This issue fix is targeted for jdk-25 and I was planning on integrating it on Monday if the updated test looks good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25279#issuecomment-2923434327

From prr at openjdk.org  Fri May 30 21:24:54 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 May 2025 21:24:54 GMT
Subject: RFR: 8357994: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [client]
In-Reply-To: <q_2Vt9xHzTL9_evxoUv1BE2z46fh1M1QgEBlr2xGmHo=.19abd633-a08f-4a51-88c3-d9fa6ac19271@github.com>
References: <q_2Vt9xHzTL9_evxoUv1BE2z46fh1M1QgEBlr2xGmHo=.19abd633-a08f-4a51-88c3-d9fa6ac19271@github.com>
Message-ID: <jmV7QQ1kMPzT2yIK3kKEdsm2qF-om6Xi567ONVTRKzw=.36da858d-2d09-4d37-9693-a15c051308f9@github.com>

On Fri, 30 May 2025 10:59:17 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357994 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to client libraries.

This is the first I've heard of it but it makes absolutely zero sense here.
The data transfer case is things like "drag and drop" between applications. You'll never see it coming from stdin
And the editor kits will read FILES with some content you want to edit. No one will ever type it in.
So in summary, withdraw this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25543#issuecomment-2923526310

From prr at openjdk.org  Fri May 30 21:34:52 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 May 2025 21:34:52 GMT
Subject: RFR: 8355904: Use variadic macros for J2dTrace [v6]
In-Reply-To: <rNnbkM8NpX0HYVUh0rPOnohIycsaLtvTDFBx4Un38G8=.b2e95ecc-8e7e-4f41-85ca-51c7556fd573@github.com>
References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com>
 <rNnbkM8NpX0HYVUh0rPOnohIycsaLtvTDFBx4Un38G8=.b2e95ecc-8e7e-4f41-85ca-51c7556fd573@github.com>
Message-ID: <ud8RXiOUXbevLt9QZhFrBy-WbyZAnKBGFsAv-zjzt74=.252297e5-14d0-4aab-927c-1b073cf7d7da@github.com>

On Thu, 22 May 2025 20:44:30 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> J2dTrace macros have multiple overloads specifying number of arguments, making it less convent to change number of arguments. There were cases when existing macros were not enough and people had to add new variants with even more arguments. We could simply use variadic macros instead.
>> 
>> Also, currently those macros expand to a { code block }, which doesn't require a semicolon at the end, so it can sometimes be missed, leading to an inconsistent code style. We could expand it directly to the function, forcing user to insert a semicolon after that, in a function-like style.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update D3DShaderGen.c

I would like to run this through our build system - which will build the debug builds as well as product
but I find that a recent change means the patch doesn't apply.
So pls merge the change with latest master and I will try after you've done that

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24949#issuecomment-2923541756

From dgredler at openjdk.org  Fri May 30 23:48:26 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 30 May 2025 23:48:26 GMT
Subject: RFR: 8356803: Test TextLayout/TestControls fails on windows & linux:
 line and paragraph separator show non-zero advance
Message-ID: <k1PSi9nmO6Lp98YlJAhpVz9rYfk2fhCgIuLldHRo8pM=.2e4c223e-dd66-4e04-816a-7dc718a73900@github.com>

Per discussion in JBS, adds the following chars to the list of ignorable whitespace chars: U+000B (Vertical Tab), U+000C (Form Feed), U+0085 (Next Line), U+2028 (Line Separator), U+2029 (Paragraph Separator).

Adds the necessary testing in pre-existing automated test class `test/jdk/java/awt/font/TextLayout/FormatCharAdvanceTest.java`.

Removes now-unnecessary manual test `test/jdk/java/awt/font/TextLayout/TestControls.java`.

The `test/jdk/java/awt/font`, `test/jdk/java/awt/print` and `test/jdk/java/awt/Graphics2D/DrawString` tests all pass for me locally on Windows, Linux and macOS.

-------------

Commit messages:
 - Add missing ignorable whitespace chars, add (automated) tests

Changes: https://git.openjdk.org/jdk/pull/25560/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25560&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356803
  Stats: 215 lines in 3 files changed: 40 ins; 161 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25560.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25560/head:pull/25560

PR: https://git.openjdk.org/jdk/pull/25560

From honkar at openjdk.org  Sat May 31 00:00:52 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Sat, 31 May 2025 00:00:52 GMT
Subject: RFR: 8358057: Update validation of ICC_Profile header data
In-Reply-To: <mYmaF_Bcw_3vxMlSpjTi6pxk19ISh4_OWMs7lgQs47w=.cf6eecf8-1faf-4d0f-af41-dcb9ea6d8770@github.com>
References: <mYmaF_Bcw_3vxMlSpjTi6pxk19ISh4_OWMs7lgQs47w=.cf6eecf8-1faf-4d0f-af41-dcb9ea6d8770@github.com>
Message-ID: <MFdvz11kAze5RPm2t6mJwYBt_SWWRqCG3EABIy2ErhA=.5582bde6-56b2-4275-a82d-099191eef7b8@github.com>

On Thu, 29 May 2025 10:22:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The [next PR](https://github.com/openjdk/jdk/pull/23044) introduces several new methods to the ICC_Profile class:
> -  getProfileClass(byte[])
> -  getColorSpaceType(byte[])
> -  getPCSType(byte[])
> -  checkRenderingIntent(byte[])
> 
> These new methods extract data directly from the provided byte array rather than relying on the profile instance. The first three methods essentially duplicate the existing ones (getProfileClass(), getColorSpaceType(), getPCSType()).
> 
> It is possible to update implementation:
> - The existing methods getColorSpaceType() and getPCSType() could delegate to the new getColorSpaceType(byte[]) and getPCSType(byte[]) methods.
> - The checkRenderingIntent(byte[]) method could be updated to report the actual invalid intent value when an error occurs
> 
> Tests:
>  - Old ValidateICCHeaderData test is update to verify the new output of the checkRenderingIntent
>  - New RenderingIntentStressTest test is added to check the next part of the icc_spec:
> 
>           * ICC spec: only the least-significant 16 bits encode the rendering
>           * intent. The most significant 16 bits must be zero and can be ignored.
>           * See https://www.color.org/ICC1v42_2006-05.pdf, section 7.2.15.
> 
> 
> 
> @honkar-jdk please take a look.
> 
> Note: There is currently an inconsistency in the usage of `getData(icSigHead)` vs `getData(cmmProfile(), icSigHead)` throughout the codebase. I plan to address this separately.

Initial testing looks good.
I have added minor inline comments.

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1191:

> 1189:          * ICC spec: only the least-significant 16 bits encode the rendering
> 1190:          * intent. The most significant 16 bits must be zero and can be ignored.
> 1191:          * See https://www.color.org/ICC1v42_2006-05.pdf, section 7.2.15.

ICC Spec link in the comment refers to older one, probably update to the new version ?  https://www.color.org/specification/ICC.1-2022-05.pdf , https://www.color.org/icc_specs2.xalter.

test/jdk/java/awt/color/ICC_Profile/RenderingIntentStressTest.java line 95:

> 93:                 || intent == icMediaRelativeColorimetric
> 94:                 || intent == icSaturation || intent == icAbsoluteColorimetric
> 95:                 || intent == icICCAbsoluteColorimetric;

I hadn't noticed it earlier but `icAbsoluteColorimetric` and `icICCAbsoluteColorimetric` (since 1.5) point to the same intent. Can it be unified or has it be maintained as two separate constants for backward compatibility ?

test/jdk/java/awt/color/ICC_Profile/ValidateICCHeaderData/ValidateICCHeaderData.java line 199:

> 197:             if (!message.contains(": " + invalidRenderIntent)) {
> 198:                 throw new RuntimeException("Test Failed ! Unexpected text");
> 199:             }

The usual recommendation is not to check for specific exception messages but in this case it should be fine since this fix changes the exception msg and as regression test update for the fix.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25519#pullrequestreview-2882873809
PR Review Comment: https://git.openjdk.org/jdk/pull/25519#discussion_r2116863194
PR Review Comment: https://git.openjdk.org/jdk/pull/25519#discussion_r2116878277
PR Review Comment: https://git.openjdk.org/jdk/pull/25519#discussion_r2116872440

From serb at openjdk.org  Sat May 31 00:30:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 31 May 2025 00:30:02 GMT
Subject: Integrated: 8358107: Rollback JDK-8357299 changeset
In-Reply-To: <zqrd4zODgKQpF2N3MzWB-R7UZrUq3mfLfhzNJ5WEbeA=.56313fa6-a2b3-4fa7-968b-95fc388d2007@github.com>
References: <zqrd4zODgKQpF2N3MzWB-R7UZrUq3mfLfhzNJ5WEbeA=.56313fa6-a2b3-4fa7-968b-95fc388d2007@github.com>
Message-ID: <7josMxpLC0ELBOwp5yl5V8yjRJboF1sFXNCQBnxLncc=.39a4eb6a-afcd-4e5e-b152-9ea8b617c054@github.com>

On Fri, 30 May 2025 04:11:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The patch for [JDK-8357299](https://bugs.openjdk.org/browse/JDK-8357299) does not completely fix the regression it was intended to address. Instead of bailing out on overflow, it introduces additional logic around src and clip, which might lead to attempts to draw invalid source pixels.
> 
> A test case demonstrating the issue is attached to [JDK-8358103](https://bugs.openjdk.org/browse/JDK-8358103)(passed on jdk22 failed on latest openjdk/jdk).
> 
> There are some unresolved discussions related to that patch, see [PR](https://github.com/openjdk/jdk/pull/25340). I believe it would be better to bail out early in case of overflow than risk incorrect calculations. 
> 
> Therefore, I propose reverting [JDK-8357299](https://bugs.openjdk.org/browse/JDK-8357299) until a proper fix is available. This approach would also simplify backports, since only the patch for [JDK-8358103](https://bugs.openjdk.org/browse/JDK-8358103) would need to be backported
> 
> @prsadhuk, @prrace please take a look

This pull request has now been integrated.

Changeset: d9d00d33
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d9d00d33a6a0d540a10e0a58f6df27cae46d2753
Stats:     74 lines in 2 files changed: 5 ins; 62 del; 7 mod

8358107: Rollback JDK-8357299 changeset

Reviewed-by: psadhukhan

-------------

PR: https://git.openjdk.org/jdk/pull/25537

From serb at openjdk.org  Sat May 31 00:32:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 31 May 2025 00:32:02 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v16]
In-Reply-To: <fYsv9kLjAhN-xp0JI9mHbXO90QD_unYDKnxNtemwNVc=.5a0201c5-f9e7-4503-896c-d5c399695659@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <fYsv9kLjAhN-xp0JI9mHbXO90QD_unYDKnxNtemwNVc=.5a0201c5-f9e7-4503-896c-d5c399695659@github.com>
Message-ID: <uPejGw5RMW2POlbLtpK6JJVMAinENQUCLiX8b8aA8ew=.71ed77be-6229-4d2e-a659-cd8a5b0cb823@github.com>

On Fri, 30 May 2025 11:20:39 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
>> 
>> ---------
>> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default and static methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses.
>> 
>> When a subclass "overrides" a static method from a parent class `getMethodDescriptors()` behaves as follows:
>> 
>> - In case of a clash with a class method, the class version will take precedence rather than interface's one. 
>> - If the same method appears in multiple classes/interfaces within the same hierarchy, the version from the most specific sub-interface will be selected.
>> - If the method appears in classes/interfaces from different hierarchies, the result is undefined, either version can be returned.
>> 
>> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter:
>> 
>> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence.
>> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen).
>> * Gettters/setters declared and not implemented are not considered.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor change

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23443#pullrequestreview-2882939391

From serb at openjdk.org  Sat May 31 01:03:04 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 31 May 2025 01:03:04 GMT
Subject: RFR: JDK-8357082 : Stabilize and add debug logs to
 CopyAreaOOB.java [v5]
In-Reply-To: <n-QkhTLb4TNA4NeG1XjI0uuk-e8YvF53BWQtFXnoF1o=.716a24e1-6dd5-4f2f-96aa-8f3ab40f8ef8@github.com>
References: <LGYHoWDAP3AZxCtsDjg-Q6hr8eW0m7Xj9Fjo55E4Psw=.0ade9e68-9e30-429a-96c4-df22bf188d47@github.com>
 <-lBIVrQXyxII4hEx6bRTJaM9dtFYWTgu7ULBFS-5kOQ=.a653a92e-702d-48d2-b6fa-50d134d4996d@github.com>
 <vHSyErxHa9Qj3AXT--S2xsTeHcz06CmVbLq3IRuCnPs=.10076546-bcde-409a-84be-9e4f403de898@github.com>
 <n-QkhTLb4TNA4NeG1XjI0uuk-e8YvF53BWQtFXnoF1o=.716a24e1-6dd5-4f2f-96aa-8f3ab40f8ef8@github.com>
Message-ID: <1oCpyW01HIgsdailQXTvgyOi3EwZCpQvqvd6dMcYxzE=.958c3237-4786-4189-86d1-daf317d9e041@github.com>

On Fri, 30 May 2025 00:31:55 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Added back Toolkit.sync() and canvas capture to paint method. Although I'm not sure if I understood _"each render frame"_ correctly. Can you please explain?

The paint method may be invoked multiple times after the frame becomes visible, so the validation logic inside paint will be executed for each rendering data.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2116940976

From serb at openjdk.org  Sat May 31 01:07:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 31 May 2025 01:07:53 GMT
Subject: RFR: 8358057: Update validation of ICC_Profile header data
In-Reply-To: <MFdvz11kAze5RPm2t6mJwYBt_SWWRqCG3EABIy2ErhA=.5582bde6-56b2-4275-a82d-099191eef7b8@github.com>
References: <mYmaF_Bcw_3vxMlSpjTi6pxk19ISh4_OWMs7lgQs47w=.cf6eecf8-1faf-4d0f-af41-dcb9ea6d8770@github.com>
 <MFdvz11kAze5RPm2t6mJwYBt_SWWRqCG3EABIy2ErhA=.5582bde6-56b2-4275-a82d-099191eef7b8@github.com>
Message-ID: <KPo170LV7zerX_CMtq2P3KBlo7vI_e1ud4uAqeK-ryQ=.4f324bfa-b506-484c-87c5-6c9021ca040a@github.com>

On Fri, 30 May 2025 23:56:35 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>I hadn't noticed it earlier but icAbsoluteColorimetric and icICCAbsoluteColorimetric point to the same intent. Is it good to unify them into a single constant in src code during clean up (separate issue)?

At some point, that constants were renamed in the ICC spec, and as a result, the new constants with the different names were added to ICC_Profile. The old one were not removed to avoid breaking compatibility. It wasn't considered critical, since both constants have the same value.

>Since both indicate intent value of 3 only one comparison should be sufficient in the test.

I just included all constants supported by the JDK for completeness.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25519#discussion_r2116951657

From serb at openjdk.org  Sat May 31 01:23:12 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 31 May 2025 01:23:12 GMT
Subject: RFR: 8358057: Update validation of ICC_Profile header data [v2]
In-Reply-To: <mYmaF_Bcw_3vxMlSpjTi6pxk19ISh4_OWMs7lgQs47w=.cf6eecf8-1faf-4d0f-af41-dcb9ea6d8770@github.com>
References: <mYmaF_Bcw_3vxMlSpjTi6pxk19ISh4_OWMs7lgQs47w=.cf6eecf8-1faf-4d0f-af41-dcb9ea6d8770@github.com>
Message-ID: <3Hc0HUBARShfH4xBoo2r6FzrQcpp1QzRNY_SiXJSaRs=.25f51547-f193-4d8a-9058-9cbd3c202d67@github.com>

> The [next PR](https://github.com/openjdk/jdk/pull/23044) introduces several new methods to the ICC_Profile class:
> -  getProfileClass(byte[])
> -  getColorSpaceType(byte[])
> -  getPCSType(byte[])
> -  checkRenderingIntent(byte[])
> 
> These new methods extract data directly from the provided byte array rather than relying on the profile instance. The first three methods essentially duplicate the existing ones (getProfileClass(), getColorSpaceType(), getPCSType()).
> 
> It is possible to update implementation:
> - The existing methods getColorSpaceType() and getPCSType() could delegate to the new getColorSpaceType(byte[]) and getPCSType(byte[]) methods.
> - The checkRenderingIntent(byte[]) method could be updated to report the actual invalid intent value when an error occurs
> 
> Tests:
>  - Old ValidateICCHeaderData test is update to verify the new output of the checkRenderingIntent
>  - New RenderingIntentStressTest test is added to check the next part of the icc_spec:
> 
>           * ICC spec: only the least-significant 16 bits encode the rendering
>           * intent. The most significant 16 bits must be zero and can be ignored.
>           * See https://www.color.org/ICC1v42_2006-05.pdf, section 7.2.15.
> 
> 
> 
> @honkar-jdk please take a look.
> 
> Note: There is currently an inconsistency in the usage of `getData(icSigHead)` vs `getData(cmmProfile(), icSigHead)` throughout the codebase. I plan to address this separately.

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  Update link to specification

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25519/files
  - new: https://git.openjdk.org/jdk/pull/25519/files/fc6360d3..cc41d6d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25519&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25519&range=00-01

  Stats: 9 lines in 2 files changed: 0 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25519.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25519/head:pull/25519

PR: https://git.openjdk.org/jdk/pull/25519

From psadhukhan at openjdk.org  Sat May 31 04:18:01 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sat, 31 May 2025 04:18:01 GMT
Subject: RFR: 8356594: JSplitPane loses divider location when reopened via
 JOptionPane.createDialog() [v4]
In-Reply-To: <61tykjKijk-xkAT398xNxGXuqaSEBw88B4begSzHndo=.2a5c38cf-cef0-473d-bd86-516d7e21c47c@github.com>
References: <LOycuJ99s85KU7sH8Kz-aWy-t-548jKDMMP7MvvxO3A=.ae11bc9b-6f7d-4b23-9f23-219d6611b9dc@github.com>
 <TeBe9DI5AuCjtP4iTp7g1UAhafKnpdz-4DHaRISktd8=.9dbeb508-ac06-4319-91d4-97e6a0108a33@github.com>
 <tAHygDZOrjsNIxY2viFQ3CK5oD0gzaJsJ6CbR1kzc20=.c446c35e-6db9-4628-950c-058d77b5aad2@github.com>
 <DMhK2yhL3IOU9aq6N1J2Im-EhC_L6IH2qw17aMugygE=.4acbdfe3-3350-4986-9f20-9353a7bc4273@github.com>
 <miQMydzf40ruao9E1mTYUK5Ouw5tMoFVLGh0qjFXS0o=.0f2fec72-ca0e-4d45-a642-0bb55c25525c@github.com>
 <61tykjKijk-xkAT398xNxGXuqaSEBw88B4begSzHndo=.2a5c38cf-cef0-473d-bd86-516d7e21c47c@github.com>
Message-ID: <Nfq57fO4F5arEqh4LKa2Mpyk2FJ3QsvNgiEHod4oPkg=.0c231450-664f-476b-9baa-9e95c42aefb4@github.com>

On Wed, 28 May 2025 03:21:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> But we can read/save orientation, then call super, then make a check? 
>> I am not sure how important to always call super.setComponentOrientation(orientation);
>> can we miss some notification fired from that method?
>
> OK. Current orientation is stored and then checked and super.setComponentOrientation is called before check.
> I guess that method fires PropertyChangeEvent for orientation set and now it will be fired always like before..

I guess all concerns are addressed..If there is no proven concern on this, I would integrate this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25294#discussion_r2117210553

From serb at openjdk.org  Sat May 31 04:24:47 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 31 May 2025 04:24:47 GMT
Subject: RFR: 8358057: Update validation of ICC_Profile header data [v3]
In-Reply-To: <mYmaF_Bcw_3vxMlSpjTi6pxk19ISh4_OWMs7lgQs47w=.cf6eecf8-1faf-4d0f-af41-dcb9ea6d8770@github.com>
References: <mYmaF_Bcw_3vxMlSpjTi6pxk19ISh4_OWMs7lgQs47w=.cf6eecf8-1faf-4d0f-af41-dcb9ea6d8770@github.com>
Message-ID: <Fpp91P3VjW_g30LlS42TnhO-HRkgEUNJJq1bCkImO-o=.356ffe38-8cd3-4eb7-b06d-79e8256e7a29@github.com>

> The [next PR](https://github.com/openjdk/jdk/pull/23044) introduces several new methods to the ICC_Profile class:
> -  getProfileClass(byte[])
> -  getColorSpaceType(byte[])
> -  getPCSType(byte[])
> -  checkRenderingIntent(byte[])
> 
> These new methods extract data directly from the provided byte array rather than relying on the profile instance. The first three methods essentially duplicate the existing ones (getProfileClass(), getColorSpaceType(), getPCSType()).
> 
> It is possible to update implementation:
> - The existing methods getColorSpaceType() and getPCSType() could delegate to the new getColorSpaceType(byte[]) and getPCSType(byte[]) methods.
> - The checkRenderingIntent(byte[]) method could be updated to report the actual invalid intent value when an error occurs
> 
> Tests:
>  - Old ValidateICCHeaderData test is update to verify the new output of the checkRenderingIntent
>  - New RenderingIntentStressTest test is added to check the next part of the icc_spec:
> 
>           * ICC spec: only the least-significant 16 bits encode the rendering
>           * intent. The most significant 16 bits must be zero and can be ignored.
>           * See https://www.color.org/ICC1v42_2006-05.pdf, section 7.2.15.
> 
> 
> 
> @honkar-jdk please take a look.
> 
> Note: There is currently an inconsistency in the usage of `getData(icSigHead)` vs `getData(cmmProfile(), icSigHead)` throughout the codebase. I plan to address this separately.

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  Update ValidateICCHeaderData.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25519/files
  - new: https://git.openjdk.org/jdk/pull/25519/files/cc41d6d4..43b88ff3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25519&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25519&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25519.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25519/head:pull/25519

PR: https://git.openjdk.org/jdk/pull/25519

From serb at openjdk.org  Sat May 31 04:24:48 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 31 May 2025 04:24:48 GMT
Subject: RFR: 8358057: Update validation of ICC_Profile header data [v3]
In-Reply-To: <Fpp91P3VjW_g30LlS42TnhO-HRkgEUNJJq1bCkImO-o=.356ffe38-8cd3-4eb7-b06d-79e8256e7a29@github.com>
References: <mYmaF_Bcw_3vxMlSpjTi6pxk19ISh4_OWMs7lgQs47w=.cf6eecf8-1faf-4d0f-af41-dcb9ea6d8770@github.com>
 <Fpp91P3VjW_g30LlS42TnhO-HRkgEUNJJq1bCkImO-o=.356ffe38-8cd3-4eb7-b06d-79e8256e7a29@github.com>
Message-ID: <fkyf0rGGVv6t9SoCUoLX9cM4vKAV07pQamjeDc2Cfss=.7e032634-7888-4359-81c3-6c65939f8ee8@github.com>

On Sat, 31 May 2025 04:21:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The [next PR](https://github.com/openjdk/jdk/pull/23044) introduces several new methods to the ICC_Profile class:
>> -  getProfileClass(byte[])
>> -  getColorSpaceType(byte[])
>> -  getPCSType(byte[])
>> -  checkRenderingIntent(byte[])
>> 
>> These new methods extract data directly from the provided byte array rather than relying on the profile instance. The first three methods essentially duplicate the existing ones (getProfileClass(), getColorSpaceType(), getPCSType()).
>> 
>> It is possible to update implementation:
>> - The existing methods getColorSpaceType() and getPCSType() could delegate to the new getColorSpaceType(byte[]) and getPCSType(byte[]) methods.
>> - The checkRenderingIntent(byte[]) method could be updated to report the actual invalid intent value when an error occurs
>> 
>> Tests:
>>  - Old ValidateICCHeaderData test is update to verify the new output of the checkRenderingIntent
>>  - New RenderingIntentStressTest test is added to check the next part of the icc_spec:
>> 
>>           * ICC spec: only the least-significant 16 bits encode the rendering
>>           * intent. The most significant 16 bits must be zero and can be ignored.
>>           * See https://www.color.org/ICC1v42_2006-05.pdf, section 7.2.15.
>> 
>> 
>> 
>> @honkar-jdk please take a look.
>> 
>> Note: There is currently an inconsistency in the usage of `getData(icSigHead)` vs `getData(cmmProfile(), icSigHead)` throughout the codebase. I plan to address this separately.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update ValidateICCHeaderData.java

test/jdk/java/awt/color/ICC_Profile/ValidateICCHeaderData/ValidateICCHeaderData.java line 27:

> 25:  * @test
> 26:  * @bug 8337703 8347377 8358057
> 27:  * @summary To verify if ICC_Profile's setData() and getInstance() methods

I have added 8347377 where this test was added and 8358057 for the current issue. @honkar-jdk I cannot access the 8337703 is it a "closed bug" or it is a typo and we can drop that id?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25519#discussion_r2117224965

From serb at openjdk.org  Sat May 31 07:09:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 31 May 2025 07:09:03 GMT
Subject: Integrated: 8357598: Toolkit.removeAWTEventListener should handle null
 listener in AWTEventListenerProxy
In-Reply-To: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
Message-ID: <P1T325_3_07C_FmtKH2sRkMoft2zKw7Gho7827hhpsA=.163ad63b-230c-4720-b2bb-d1338a4c3828@github.com>

On Thu, 22 May 2025 21:21:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
> 
> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
> 
> One of the test is updated just to touch that codepath.

This pull request has now been integrated.

Changeset: 3a3ea7e1
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a3ea7e17fff100e368c956350bb9aaa2261b8a9
Stats:     48 lines in 2 files changed: 28 ins; 15 del; 5 mod

8357598: Toolkit.removeAWTEventListener should handle null listener in AWTEventListenerProxy

Reviewed-by: aivanov, dnguyen

-------------

PR: https://git.openjdk.org/jdk/pull/25401