From duke at openjdk.org  Sat Nov  1 05:33:24 2025
From: duke at openjdk.org (samypr100)
Date: Sat, 1 Nov 2025 05:33:24 GMT
Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access
 methods with FFM [v9]
In-Reply-To: <j_Ph-pb5YhtDfEu8YuyXc2bkRlnJHewem_obT_d1nvQ=.235e8fa9-1bf7-43fe-840b-977693526262@github.com>
References: <HH7UwqQkAqErAsML43k19KnXHMDK1iOjtNWOGELGLT8=.3a1c133d-6fdf-4cd3-b579-cf7b4a7707a4@github.com>
 <ErmrFIJhyF7uVqaNHco8znxf0RUACZBXRmyLLMVBfjk=.832f2595-9f29-4f12-869d-5ceb4b68dbf8@github.com>
 <j_Ph-pb5YhtDfEu8YuyXc2bkRlnJHewem_obT_d1nvQ=.235e8fa9-1bf7-43fe-840b-977693526262@github.com>
Message-ID: <PCEEMEKNu2KkHhburSAl3-fdTZZFyFJ0xKIfQdbtIXI=.a6c6683d-42b7-43e2-b8a5-bb8234cf2761@github.com>

On Wed, 11 Jun 2025 20:17:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup for review comments
>
> Thanks for the reviews.

@kevinrushforth More of a follow-up question rather than a bug report yet (apologies if this is not the right avenue). I found usage of [sun.misc.BASE64Encoder](https://github.com/openjdk/jfx/blob/c77c2335856a967907aaacc9546f44943c069add/modules/javafx.web/src/android/java/javafx/scene/web/WebEngine.java#L478) in `javafx.web` module as well as [jdk.unsupported](https://github.com/openjdk/jfx/blob/c77c2335856a967907aaacc9546f44943c069add/modules/javafx.graphics/src/main/java/module-info.java#L45) still referenced in javafx.graphics.

Would those need to be addressed as well (assuming the end goal was to remove all sun.misc references)? I'm also naively assuming the requires on `jdk.unsupported` can be dropped after these changes unless I'm mistaken.

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

PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-3475802120

From duke at openjdk.org  Sat Nov  1 12:13:19 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Sat, 1 Nov 2025 12:13:19 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED [v2]
In-Reply-To: <yaXrRwaSvxpT6h4i6a0O9KDby2d3BMlRY8p-rQxEg7E=.5f6fac82-05b7-44ad-847e-294b42adb035@github.com>
References: <bIMP7awMNGUfYipsINgCBoQ24l8S7-r7BR-ksByEQq4=.2f4e676f-10dc-419c-9b48-f7d2c3a076a9@github.com>
 <lU2DPUg_0azYapE7yXf6IQR1kttgYg-WOsYLHhtoaGc=.0a105028-4ccc-4069-a41e-22b090d5f251@github.com>
 <yaXrRwaSvxpT6h4i6a0O9KDby2d3BMlRY8p-rQxEg7E=.5f6fac82-05b7-44ad-847e-294b42adb035@github.com>
Message-ID: <l6WUGJTKbiRfet598RfpPg90MAanSPsXzFnlL_zGx-E=.07fbe029-dd6d-4896-969a-eaa4fd30cdf6@github.com>

On Fri, 31 Oct 2025 00:48:44 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move HeaderBar to DialogPane
>
> I've moved the new API from `Dialog` (which roughly corresponds to a `Stage`) to `DialogPane`, which contains the scene graph of a dialog. All bugs you've found should also be fixed.

@mstr2: Thanks. I've been using this build a lot yesterday and today, and haven't noticed any issues re: alerts/dialogs + HeaderBar usage. Great to have HeaderBar support for dialogs now.

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

PR Comment: https://git.openjdk.org/jfx/pull/1943#issuecomment-3476326422

From kcr at openjdk.org  Sat Nov  1 15:41:25 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 1 Nov 2025 15:41:25 GMT
Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access
 methods with FFM [v9]
In-Reply-To: <PCEEMEKNu2KkHhburSAl3-fdTZZFyFJ0xKIfQdbtIXI=.a6c6683d-42b7-43e2-b8a5-bb8234cf2761@github.com>
References: <HH7UwqQkAqErAsML43k19KnXHMDK1iOjtNWOGELGLT8=.3a1c133d-6fdf-4cd3-b579-cf7b4a7707a4@github.com>
 <ErmrFIJhyF7uVqaNHco8znxf0RUACZBXRmyLLMVBfjk=.832f2595-9f29-4f12-869d-5ceb4b68dbf8@github.com>
 <j_Ph-pb5YhtDfEu8YuyXc2bkRlnJHewem_obT_d1nvQ=.235e8fa9-1bf7-43fe-840b-977693526262@github.com>
 <PCEEMEKNu2KkHhburSAl3-fdTZZFyFJ0xKIfQdbtIXI=.a6c6683d-42b7-43e2-b8a5-bb8234cf2761@github.com>
Message-ID: <PQNNr24tUkvwAYWeNdm53m99VifddOLRGZgAtBzaMqE=.71886b96-5653-40a1-b519-921a2c6b80c4@github.com>

On Sat, 1 Nov 2025 05:28:06 GMT, samypr100 <duke at openjdk.org> wrote:

> More of a follow-up question rather than a bug report yet (apologies if this is not the right avenue).

I'll give a brief answer here. Any follow-up discussion can happen on the mailing list.

> I found usage of [sun.misc.BASE64Encoder](https://github.com/openjdk/jfx/blob/c77c2335856a967907aaacc9546f44943c069add/modules/javafx.web/src/android/java/javafx/scene/web/WebEngine.java#L478) in `javafx.web` module

The `src/android` directory under the `javafx.web` module is unused by the JavaFX desktop build, and requires additional stuff outside the jfx repo to build it (I've never built it myself). Since `sun.misc.BASE64Encoder` no longer exists in the JDK -- and hasn't since it was removed in JDK 9 -- that copy of `WebEngine.java` cannot possibly compile unmodified, at least not with an unmodified JDK.

> as well as [jdk.unsupported](https://github.com/openjdk/jfx/blob/c77c2335856a967907aaacc9546f44943c069add/modules/javafx.graphics/src/main/java/module-info.java#L45) still referenced in javafx.graphics.
> 
> Would those need to be addressed as well (assuming the end goal was to remove all sun.misc references)? I'm also naively assuming the requires on `jdk.unsupported` can be dropped after these changes unless I'm mistaken.

Thank you for pointing this out. This was an oversight on my part. I should have removed the `requires jdk.unsupported` as part of this PR. I filed [JDK-8371087](https://bugs.openjdk.org/browse/JDK-8371087) as a follow-on to do this.

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

PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-3476468473

From kcr at openjdk.org  Sat Nov  1 15:51:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 1 Nov 2025 15:51:52 GMT
Subject: RFR: 8371087: Remove unused dependency on jdk.unsupported from
 javafx.graphics
Message-ID: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>

This PR removes the unused dependency on `jdk.unsupported` from `javafx.graphics` as a followup to [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137), which replaced the use of `sun.misc.Unsafe` with FFM in PR #1814. `sun.misc.Unsafe` was the only use of `jdk.unsupported`, so it can now be removed.

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

Commit messages:
 - 8371087: Remove unused dependency on jdk.unsupported from javafx.graphics

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

PR: https://git.openjdk.org/jfx/pull/1957

From lbourges at openjdk.org  Sat Nov  1 16:36:15 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sat, 1 Nov 2025 16:36:15 GMT
Subject: RFR: 8371087: Remove unused dependency on jdk.unsupported from
 javafx.graphics
In-Reply-To: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
References: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
Message-ID: <DWcJqyJj845868pbS-13-X9vKwczRong7_DR8gNhyy8=.a3017101-eb4d-413d-af49-b50481ba7ff6@github.com>

On Sat, 1 Nov 2025 15:47:00 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the unused dependency on `jdk.unsupported` from `javafx.graphics` as a followup to [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137), which replaced the use of `sun.misc.Unsafe` with FFM in PR #1814. `sun.misc.Unsafe` was the only use of `jdk.unsupported`, so it can now be removed.

LGTM. 
Good job!

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

PR Comment: https://git.openjdk.org/jfx/pull/1957#issuecomment-3476542405

From mhanl at openjdk.org  Sat Nov  1 16:49:18 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 1 Nov 2025 16:49:18 GMT
Subject: RFR: 8371087: Remove unused dependency on jdk.unsupported from
 javafx.graphics
In-Reply-To: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
References: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
Message-ID: <7_PC2mxzc0P2y0oCJBguoyUOS4ehwEgi8xZaFW97whA=.3a24b6ef-765d-4593-944c-8d98d688a549@github.com>

On Sat, 1 Nov 2025 15:47:00 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the unused dependency on `jdk.unsupported` from `javafx.graphics` as a followup to [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137), which replaced the use of `sun.misc.Unsafe` with FFM in PR #1814. `sun.misc.Unsafe` was the only use of `jdk.unsupported`, so it can now be removed.

Makes sense. Can confirm that the last `sun.misc` usage is `WebEngine.java` in the `android` folder in `javafx.web`, as also noted in the comment in https://github.com/openjdk/jfx/pull/1814#issuecomment-3475802120.

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

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1957#pullrequestreview-3407595674

From jhendrikx at openjdk.org  Sun Nov  2 00:52:19 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 2 Nov 2025 00:52:19 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v2]
In-Reply-To: <SUQ3uoL6zgtSTQzHnzd9pv5DbkeBmZUK8AcMz__By0c=.c2627d35-51c0-42bb-a8bf-f5a5cfbd9450@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <SUQ3uoL6zgtSTQzHnzd9pv5DbkeBmZUK8AcMz__By0c=.c2627d35-51c0-42bb-a8bf-f5a5cfbd9450@github.com>
Message-ID: <-O4F0UKPZVGp6TV18AKefLrXvIdtSHySgYF6tdA5_GY=.090ff031-c390-4718-a3d0-debbeeef05aa@github.com>

On Mon, 20 Oct 2025 05:06:20 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR implements two new default methods on `ObservableList` to be able to replace elements at a given position or within a specified range.
>> 
>> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
>> 
>> The other alternative is to call `set` individually for each item, which results in many change notifications.
>> 
>> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
>> 
>> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.
>
> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix test
>  - Rename setAll to replaceRange and removed superfluous method

Looks like I'll need this change to write a test for replacing a range of elements in ListView.  It seems that currently replacing a range of items will always clear the whole selection.  Filed https://bugs.openjdk.org/browse/JDK-8371090 to track those problems.

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

PR Comment: https://git.openjdk.org/jfx/pull/1937#issuecomment-3477012798

From asarkar at openjdk.org  Sun Nov  2 16:17:20 2025
From: asarkar at openjdk.org (Anirvan Sarkar)
Date: Sun, 2 Nov 2025 16:17:20 GMT
Subject: RFR: 8371087: Remove unused dependency on jdk.unsupported from
 javafx.graphics
In-Reply-To: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
References: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
Message-ID: <hfoycoKEiwObCSMdkv68Vfa9mfg8LG9KHMPewlfyqU4=.6269ce46-bca8-4805-9e47-8f4a14594ffa@github.com>

On Sat, 1 Nov 2025 15:47:00 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the unused dependency on `jdk.unsupported` from `javafx.graphics` as a followup to [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137), which replaced the use of `sun.misc.Unsafe` with FFM in PR #1814. `sun.misc.Unsafe` was the only use of `jdk.unsupported`, so it can now be removed.

As `sun.misc.Unsafe` is not used anymore, maybe then also remove the references to `XDignore.symbol.file` flag in `build.gradle`.

I noticed [JDK-8179462](https://bugs.openjdk.org/browse/JDK-8179462) already exists to remove the flag from javadoc build.

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

PR Comment: https://git.openjdk.org/jfx/pull/1957#issuecomment-3478077301

From mhanl at openjdk.org  Sun Nov  2 17:21:26 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sun, 2 Nov 2025 17:21:26 GMT
Subject: RFR: 8371087: Remove unused dependency on jdk.unsupported from
 javafx.graphics
In-Reply-To: <hfoycoKEiwObCSMdkv68Vfa9mfg8LG9KHMPewlfyqU4=.6269ce46-bca8-4805-9e47-8f4a14594ffa@github.com>
References: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
 <hfoycoKEiwObCSMdkv68Vfa9mfg8LG9KHMPewlfyqU4=.6269ce46-bca8-4805-9e47-8f4a14594ffa@github.com>
Message-ID: <EErboZ2Bm5UNCP8ARa-0y_6xzjbHMfYvWZVzUKo8W1c=.eb8c758e-d09e-449a-a1e4-7dec24fe2ad4@github.com>

On Sun, 2 Nov 2025 16:14:19 GMT, Anirvan Sarkar <asarkar at openjdk.org> wrote:

> As `sun.misc.Unsafe` is not used anymore, maybe then also remove the references to `XDignore.symbol.file` flag in `build.gradle`.
> 
> I noticed [JDK-8179462](https://bugs.openjdk.org/browse/JDK-8179462) already exists to remove the flag from javadoc build.

That sounds indeed reasonable! As mentioned above, there is one `sun.misc` usage left in the `android` folder, so we may need to check that out first.

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

PR Comment: https://git.openjdk.org/jfx/pull/1957#issuecomment-3478121997

From mstrauss at openjdk.org  Sun Nov  2 17:56:18 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 2 Nov 2025 17:56:18 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v2]
In-Reply-To: <SUQ3uoL6zgtSTQzHnzd9pv5DbkeBmZUK8AcMz__By0c=.c2627d35-51c0-42bb-a8bf-f5a5cfbd9450@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <SUQ3uoL6zgtSTQzHnzd9pv5DbkeBmZUK8AcMz__By0c=.c2627d35-51c0-42bb-a8bf-f5a5cfbd9450@github.com>
Message-ID: <-EPHSExUFbTWYUhpor36C9Ru_0uPnbf4EyB4zACAULE=.2fd3d9c3-ce41-4991-abc8-e0b9f322a80a@github.com>

On Mon, 20 Oct 2025 05:06:20 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR implements two new default methods on `ObservableList` to be able to replace elements at a given position or within a specified range.
>> 
>> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
>> 
>> The other alternative is to call `set` individually for each item, which results in many change notifications.
>> 
>> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
>> 
>> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.
>
> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix test
>  - Rename setAll to replaceRange and removed superfluous method

Marked as reviewed by mstrauss (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1937#pullrequestreview-3408892663

From mhanl at openjdk.org  Sun Nov  2 19:45:49 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sun, 2 Nov 2025 19:45:49 GMT
Subject: RFR: 8240844: Remove dependency on java.desktop from javafx.base
Message-ID: <s4sTfLR0m9Ps-C00W_TqTRsM4a0szVpRO7T_FMPOOpo=.56315c2c-9b93-457d-b712-2d9baed984b3@github.com>

This PR makes the `java.desktop` requirement static for `javafx.base` and `javafx.graphics`.
With this changes, a JavaFX app without `Swing` and the `WebView` will be much smaller (results below).

Consequences:
- `java.desktop` need to be loaded (required) when using anything from the `javafx.beans.property.adapter` package (the property classes from `java.beans.XXX` are used here)
- `java.desktop` need to be loaded (required) when using printing, that is e.g. `PrinterJob.createPrinterJob().showPrintDialog(..)`

Results:
- Removing `java.desktop` gives a huge size boost! I benchmarked the following values when using `jlink` with: [`zip-6`, `--no-man-pages`, `--no-header-files`, `--strip-debug`, `--strip-java-debug-attributes`] to build an own runtime

Tried on a real application (here called `myapp`) with JDK-25 on Windows 11 that has dependencies to: [`javafx-base`,  `javafx-graphics`, `javafx-fxml`, `javafx-controls`]

---

`master`

`70.009.288 Bytes`


myapp
java.base at 25
java.datatransfer at 25
java.desktop at 25
java.prefs at 25
java.scripting at 25
java.xml at 25
javafx.base at 26-internal
javafx.controls at 26-internal
javafx.fxml at 26-internal
javafx.graphics at 26-internal
jdk.localedata at 25
jdk.unsupported at 25


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

`This PR`

`57.266.538 Bytes`


myapp
java.base at 25
java.scripting at 25
java.xml at 25
javafx.base at 26-internal
javafx.controls at 26-internal
javafx.fxml at 26-internal
javafx.graphics at 26-internal
jdk.localedata at 25
jdk.unsupported at 25


---

`This PR` + https://github.com/openjdk/jfx/pull/1957

`57.249.459 Bytes`


myapp
java.base at 25
java.scripting at 25
java.xml at 25
javafx.base at 26-internal
javafx.controls at 26-internal
javafx.fxml at 26-internal
javafx.graphics at 26-internal
jdk.localedata at 25


---

So we save around 13MB. If building a native package, e.g. an `.msi` installer, this will be even higher.

This change however probably need some discussion, if we want to go that direction + add a note in the release notes, that if one of the two things mentioned above are needed, an requirement to `java.desktop` is needed (in case of a modular project).

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

Commit messages:
 - 8240844: Remove dependency on java.desktop from javafx.base

Changes: https://git.openjdk.org/jfx/pull/1958/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1958&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8240844
  Stats: 6 lines in 2 files changed: 2 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1958.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1958/head:pull/1958

PR: https://git.openjdk.org/jfx/pull/1958

From mhanl at openjdk.org  Sun Nov  2 20:06:20 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sun, 2 Nov 2025 20:06:20 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: <wPAA9aAnrNklGwk5c8pJLmhxYd8nL4-Z8_GCILQ8whc=.53900459-2846-4d41-aea4-20ab809abf9f@github.com>
References: <LwnBiVMOfsnBlKPaSv_P99MdGLTYFzV282agrWuXZvM=.45a4b546-241f-4754-99b8-6ed5dee81ab6@github.com>
 <wPAA9aAnrNklGwk5c8pJLmhxYd8nL4-Z8_GCILQ8whc=.53900459-2846-4d41-aea4-20ab809abf9f@github.com>
Message-ID: <dXul0jP0wEPTpYaY_wO0mWckPun8673x-EiXnbn_sks=.c351f119-2e96-4799-9165-1bef9864bce3@github.com>

On Mon, 27 Oct 2025 14:44:44 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename test

I did tests on 3 different applications and could not spot any problems!

What I did not test:
- `ToolBar`
- `BubbleChart`
- `AreaChart`
- `Pagination`
- Most of the 3D `Shape` classes

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3478233496

From jurgen at ivoryemr.co.za  Mon Nov  3 06:46:54 2025
From: jurgen at ivoryemr.co.za (Jurgen Doll)
Date: Mon, 3 Nov 2025 08:46:54 +0200
Subject: RichTextArea missing Caspian entries
In-Reply-To: <CY8PR10MB7265A4E7F402C44950AF8781E5F8A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CY8PR10MB7265A4E7F402C44950AF8781E5F8A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <AEFBFF1F-BD13-4986-8FD6-8709F35EC17A@getmailspring.com>

Hi Andy

I just prefer the Caspian L&F to that of Modena :-)
Regards
Jurgen

On Oct 31 2025, at 11:47 pm, Andy Goryachev <andy.goryachev at oracle.com> wrote:
> I am afraid the Caspian CSS is effectively unmaintained since jfx 9 or so. All the changes and fixes go to Modena.
>
> I wonder if we should deprecate Caspian (not for removal).
>
> May I ask why you are using Caspian and not Modena? Is there something missing or got worse in Modena?
>
> In any case, created https://bugs.openjdk.org/browse/JDK-8371080
>
> Thanks!
> -andy
>
>
> From: openjfx-discuss <openjfx-discuss-retn at openjdk.org> on behalf of Jurgen Doll <jurgen at ivoryemr.co.za>
> Date: Friday, October 31, 2025 at 01:40
> To: openjfx-discuss at openjdk.org <openjfx-discuss at openjdk.org>
> Subject: RichTextArea missing Caspian entries
>
> Hi Andy
>
> Just a heads up that Caspian CSS doesn't have the entries for RichTextArea etc.
>
> Thanks, regards
> Jurgen
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251103/5233a21e/attachment-0001.htm>

From jurgen at ivoryemr.co.za  Mon Nov  3 06:46:54 2025
From: jurgen at ivoryemr.co.za (Jurgen Doll)
Date: Mon, 3 Nov 2025 08:46:54 +0200
Subject: RichTextArea missing Caspian entries
In-Reply-To: <CY8PR10MB7265A4E7F402C44950AF8781E5F8A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CY8PR10MB7265A4E7F402C44950AF8781E5F8A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <AEFBFF1F-BD13-4986-8FD6-8709F35EC17A@getmailspring.com>

Hi Andy

I just prefer the Caspian L&F to that of Modena :-)
Regards
Jurgen

On Oct 31 2025, at 11:47 pm, Andy Goryachev <andy.goryachev at oracle.com> wrote:
> I am afraid the Caspian CSS is effectively unmaintained since jfx 9 or so. All the changes and fixes go to Modena.
>
> I wonder if we should deprecate Caspian (not for removal).
>
> May I ask why you are using Caspian and not Modena? Is there something missing or got worse in Modena?
>
> In any case, created https://bugs.openjdk.org/browse/JDK-8371080
>
> Thanks!
> -andy
>
>
> From: openjfx-discuss <openjfx-discuss-retn at openjdk.org> on behalf of Jurgen Doll <jurgen at ivoryemr.co.za>
> Date: Friday, October 31, 2025 at 01:40
> To: openjfx-discuss at openjdk.org <openjfx-discuss at openjdk.org>
> Subject: RichTextArea missing Caspian entries
>
> Hi Andy
>
> Just a heads up that Caspian CSS doesn't have the entries for RichTextArea etc.
>
> Thanks, regards
> Jurgen
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251103/5233a21e/attachment-0002.htm>

From dlemmermann at gmail.com  Mon Nov  3 09:45:00 2025
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Mon, 3 Nov 2025 10:45:00 +0100
Subject: User Agent Stylesheets
Message-ID: <3EEE598B-1018-434B-AAA4-B84B5EC9F4DF@gmail.com>

Hi,

I just ran into this issue again where I wrote a custom control with an inner custom control and both of them have their own user agent stylesheet, so basically an outer custom control and an inner custom control. I tried using the user agent stylesheet of the outer custom control to change rules for the inner custom control, but that seems to be impossible. Am I missing something or is this the intended use of user agent stylesheets?

Dirk

P.S.: both of them are controls with their own skin.




From jurgen at ivoryemr.co.za  Mon Nov  3 09:53:00 2025
From: jurgen at ivoryemr.co.za (Jurgen Doll)
Date: Mon, 3 Nov 2025 11:53:00 +0200
Subject: RichTextArea Feedback
In-Reply-To: <CY8PR10MB72658933F689A807433DDE4CE5F8A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CY8PR10MB72658933F689A807433DDE4CE5F8A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <D59F4F9A-21E8-49DE-BAD8-C593977D5F2F@getmailspring.com>

Hi Andy

Thanks for posting a summary to the dev list.

With regards to this point:

>> As expected though paste and undo/redo don't work due to
> StyledTextModel's final replace method not handling INLINE_NODE's
>  
> This is correct, and I think it might be better to leave up to the
> (custom) model. ?The reason for it is it should be up to the
> application/custom model to decide how to deal with the embedded
> nodes, especially interactive ones.

I understand your rational, however having tried it myself (with two
different models) I can claim with a high degree of confidence that it's
currently impossible. Unless I've missed something, a developer
extending any form of StyledTextModel cannot accomplish this.

The fix if I'm not mistaken is straightforward. What is required is
the addition of something like the following method to StyledTextModel:

protected abstract int insertNodeSegment(int index, int offset,
Supplier<Node> sup, StyleAttributeMap? attrs?);

and that the method:

public final TextPos replace(..., StyledInput input)

then handles INLINE_NODE and appropriately invokes this added
insertNodeSegment method.

All your current sub-classes of StyledTextModel can then just implement
No-Op implementations of insertNodeSegment. Of course it would be
awesome if RichTextModel could handle inline nodes out of the box.

I hope this meets with your approval and if I've missed something please
let me know.

Thanks, regards
Jurgen


From mhanl at openjdk.org  Mon Nov  3 10:44:48 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 3 Nov 2025 10:44:48 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v2]
In-Reply-To: <o3hU2SQe79lZPMQ3ZAeqlTpeJcK60gztEQNOsUhgf5k=.af7cf450-78bf-440a-89a3-18691c03ce28@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <Mgct4rb3dRHE8dJ9uT1iO7yMgosrzhIyAIvzpUsU4PE=.bb38ff0c-ea79-498b-b722-d517ea3557a1@github.com>
 <LzuOnYP0YbVEflxZEkVHbTG5ykSHTSGvjXPp12YP1ik=.d0e4d40a-0d74-4095-979d-84b103a078dc@github.com>
 <YvcNl5_75SiSnfUyh-JrJ9NPeJ2fwIMhBEYuuZU_vuY=.fcee6959-7a57-49c4-880f-57552e8d5fd8@github.com>
 <i2gSLwZLmp2xBDm350sCnpMQXeR0dAfS9a7AZbaY6wQ=.7aa47a02-290d-4c27-ab8a-edc0070015a6@github.com>
 <zalMYqmsa4i6LIxcP79u0guOBmYSQohY7YKvt9sH074=.f43d8041-51b1-4b9f-95e0-768da42932f6@github.com>
 <o3hU2SQe79lZPMQ3ZAeqlTpeJcK60gztEQNOsUhgf5k=.af7cf450-78bf-440a-89a3-18691c03ce28@github.com>
Message-ID: <9Us1duA3t9S97bmzJ_nN03yikb4EnkPomX0yWY2orbQ=.c0f2331a-3531-4e21-b003-176fb3baacf9@github.com>

On Mon, 20 Oct 2025 05:02:12 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> * `setAll(int, Collection)` and disallow it to change size
>> I think this doesn't carry its weight. It's just an explicit name for a narrow special case of a more general operation. However, if we're going to have a method with this signature, I suggest to not go for the narrow special case, but instead at least allow me to overlap the new list across the end of the existing list.
>> 
>> * `replaceAll(int, int, Collection)`
>> We already have `List.replaceAll(UnaryOperator)`, which does something quite different (namely, replacing all elements with different elements). I think your proposed operation really is more like a `replaceRange`.
>
> @mstr2 I was hesitant to introduce another "new" method, and was looking to only overload `setAll`, but thinking it over a bit longer, I think if we want to offer this functionality in a free form way, we may as well just introduce a `replaceRange` method.  I removed the `setAll` overload and renamed the range version to `replaceRange`.

I also like `replaceRange`. When I first checked the PR with the old name, I didn't really understand the intent of the function.
But now I understand it +1 from me. I've definitely needed this sometimes, especially for tables.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1937#discussion_r2486037952

From arapte at openjdk.org  Mon Nov  3 11:21:27 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 3 Nov 2025 11:21:27 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: <QvDVzxnZ2dxi-y2RvwBGY9-CnKeUg7tmXeKKAIvGyF8=.68ae04ff-dc06-4962-8762-4b10035d713e@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <QvDVzxnZ2dxi-y2RvwBGY9-CnKeUg7tmXeKKAIvGyF8=.68ae04ff-dc06-4962-8762-4b10035d713e@github.com>
Message-ID: <4rzaU_8iDK34kOSpHtLK7VE43OrI8xbNKFgFBio8ow0=.5c8ebfef-1d00-43d4-a102-409433dcf7cb@github.com>

On Thu, 30 Oct 2025 14:08:38 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BaseContext: Add maskTex checks to flushMask()

modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DTextureResource.java line 41:

> 39:         if (resource != null) {
> 40:             resource.dispose();
> 41:             resource = null;

We do not set the resource to `null` for any classes like `D3DTextureResource`, `MTLTextureResource` or `ES2TextureResource`. But the actual reference to native resource is set to **0** in the `resource.dispose();` call ( i.e. in classes like, `D3DTextureData`, `MTLTextureData`, `ES2TextureData` ). So the actual dispose of resource is already guarded.

Setting null only for D3D may cause confusion, as to why is it not done for other pipelines.
So, I would recommend to remove, as current code is safe. Or
add the same for other pipelines as well.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1951#discussion_r2486128510

From arapte at openjdk.org  Mon Nov  3 11:21:29 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 3 Nov 2025 11:21:29 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: <2FWS9tiiKQMpTOs88Czu4dXoe-27anWId3ppau-1Dog=.b0e85d3d-fd3c-4658-b64c-376d1a4ed77c@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <QvDVzxnZ2dxi-y2RvwBGY9-CnKeUg7tmXeKKAIvGyF8=.68ae04ff-dc06-4962-8762-4b10035d713e@github.com>
 <lAFGM-gteBGlk9cOsRr4YmT332TcWY2m7RD_5gM-Du4=.1295ec65-c53b-456a-810d-d90a66ce872c@github.com>
 <2FWS9tiiKQMpTOs88Czu4dXoe-27anWId3ppau-1Dog=.b0e85d3d-fd3c-4658-b64c-376d1a4ed77c@github.com>
Message-ID: <HwCbOlYsnZb7oZ5FMPHv29SjboagD4f8KtwYAz6z6B0=.a6494c3e-8595-4fc8-899d-814851e57dd4@github.com>

On Fri, 31 Oct 2025 11:03:39 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/prism/impl/BaseContext.java line 111:
>> 
>>> 109: 
>>> 110:     protected final void flushMask() {
>>> 111:         if (maskTex != null && maskTex.isSurfaceLost()) return;
>> 
>> if maskTex is null the subsequent calls could throw NPE, so maybe this should be:
>> 
>> 
>>         if (maskTex == null || maskTex.isSurfaceLost()) return;
>
> Fair point. I think this code works regardless because originally `maskTex` was supposed to be guarded by `curMaskRow` and `curMaskCol` below being set to zero.
> 
> I will change it to the above.

If this change fixes this particular issue, then can the calls `!resource.isValid()` be removed ?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1951#discussion_r2486128563

From nlisker at openjdk.org  Mon Nov  3 11:24:30 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 3 Nov 2025 11:24:30 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: <4rzaU_8iDK34kOSpHtLK7VE43OrI8xbNKFgFBio8ow0=.5c8ebfef-1d00-43d4-a102-409433dcf7cb@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <QvDVzxnZ2dxi-y2RvwBGY9-CnKeUg7tmXeKKAIvGyF8=.68ae04ff-dc06-4962-8762-4b10035d713e@github.com>
 <4rzaU_8iDK34kOSpHtLK7VE43OrI8xbNKFgFBio8ow0=.5c8ebfef-1d00-43d4-a102-409433dcf7cb@github.com>
Message-ID: <JHBs7PUrjSO8k1CUsdr819Rue1j2UTPfVZ4VnflN7qw=.fe15ba0e-fdc0-444f-8975-60b9b4a4bc7f@github.com>

On Mon, 3 Nov 2025 11:19:03 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   BaseContext: Add maskTex checks to flushMask()
>
> modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DTextureResource.java line 41:
> 
>> 39:         if (resource != null) {
>> 40:             resource.dispose();
>> 41:             resource = null;
> 
> We do not set the resource to `null` for any classes like `D3DTextureResource`, `MTLTextureResource` or `ES2TextureResource`. But the actual reference to native resource is set to **0** in the `resource.dispose();` call ( i.e. in classes like, `D3DTextureData`, `MTLTextureData`, `ES2TextureData` ). So the actual dispose of resource is already guarded.
> 
> Setting null only for D3D may cause confusion, as to why is it not done for other pipelines.
> So, I would recommend to remove, as current code is safe. Or
> add the same for other pipelines as well.

Might be worth adding a comment that the resource is freed natively so there's no need to dereference.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1951#discussion_r2486136658

From mfox at openjdk.org  Mon Nov  3 12:40:04 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 3 Nov 2025 12:40:04 GMT
Subject: RFR: 8359899: Stage.isFocused() returns invalid value when Stage
 fails to receive focus
In-Reply-To: <vrf_graprxnZ2ZafRydh94V8sGcsdvj37zlNqUPPRW4=.e00c5988-251e-46a2-ae8d-0e9335b46547@github.com>
References: <einORxJYJmPpn4dSQuVRu8rIvOvTDNf7FfgIVrTyJhU=.b6b1beb0-ef49-40ab-81fb-3cf6c4e772b7@github.com>
 <rJTP0x--Nsn5Vyou250vumOnCAbCzK1TwGy8BTxC_Po=.7a3ce93e-5ce8-43cf-9a3e-2bb2f0ffef44@github.com>
 <vrf_graprxnZ2ZafRydh94V8sGcsdvj37zlNqUPPRW4=.e00c5988-251e-46a2-ae8d-0e9335b46547@github.com>
Message-ID: <G2SVSS8AzdGahtpnzDAAOk0GlNrzu_t_vNq4R04mJ8A=.01230f37-e817-4cba-85ed-48b163050a8d@github.com>

On Tue, 28 Oct 2025 11:23:53 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> I played around with this for a bit and I cannot reproduce this behavior. When I start the app it gets brought to foreground and stage.isFocused() returns true as it should for me.
> 
> Could it be the difference between Windows versions maybe? I'm running Win 11 24H2 at this point in time.

I'm also running an up-to-date version of Win 11. I can reproduce the ::SetForegroundWindow failure when launching from a MinGW terminal window but not from a Cygwin terminal.

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

PR Comment: https://git.openjdk.org/jfx/pull/1849#issuecomment-3480320468

From mfox at openjdk.org  Mon Nov  3 12:52:27 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 3 Nov 2025 12:52:27 GMT
Subject: RFR: 8359899: Stage.isFocused() returns invalid value when Stage
 fails to receive focus [v2]
In-Reply-To: <5dqRJNL_jk1DrmWFn3XfCtTg9dt7aeb9QacOIigw4qI=.b96d2941-19c4-42f5-9a1b-acadcde5504e@github.com>
References: <einORxJYJmPpn4dSQuVRu8rIvOvTDNf7FfgIVrTyJhU=.b6b1beb0-ef49-40ab-81fb-3cf6c4e772b7@github.com>
 <VIly_0A7T7aO5-kTx7KLcS5mRwaq7hlN7xVTzggfVPs=.43d3d669-80b4-408f-b630-ff6d6330d50e@github.com>
 <Qn8RB4AnshCzhEKNpFT5RzZ0x_VGcaZj99FJlYtxjrc=.aaa7cabf-4f24-48e3-9fda-49998badea37@github.com>
 <5dqRJNL_jk1DrmWFn3XfCtTg9dt7aeb9QacOIigw4qI=.b96d2941-19c4-42f5-9a1b-acadcde5504e@github.com>
Message-ID: <aOtVOxjTf0J1fRefOtawC4Lf2onPW8c7T17xhiAuTD0=.b2dbda8e-d183-4045-801c-a3cb946d1b3e@github.com>

On Thu, 30 Oct 2025 13:43:58 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 1959:
>> 
>>> 1957:         }
>>> 1958: 
>>> 1959:         ::ShowWindow(hWnd, visible ? SW_SHOWNA : SW_HIDE);
>> 
>> Is this change needed? I presume that the idea behind it is that if it is a focusable window, it will be activated anyway?
>
> Yes, this is part of the fix. The values in question are:
> - `SW_SHOW` - shows a window and activates it, sending the `WM_ACTIVATE` message
> - `SW_SHOWNA` - shows a window but doesn't activate it - activation is postponed to us later calling `::SetForegroundWindow()`
> 
> By using `SW_SHOWNA` we can postpone the window activation and have `::SetForegroundWindow()` trigger it. If `::SetForegroundWindow()` succeeds, window gets activated and gains focus, and `WM_ACTIVATE` gets sent, which will then be captured by JavaFX message loop so we can notify Java-side that we gained focus. If `::SetForegroundWindow()` fails, we see that in this function and we can notify Java-side the focus has been lost.
> 
> This is unfortunately a bit hacky, but I couldn't find another way of establishing whether we actually have focus or not, especially combining that with what `::SetForegroundWindow()` returns. With `SW_SHOW` the `WM_ACTIVATE` message would go through despite `::SetForegroundWindow()` failing and us ultimately _not_ having focus.
> 
> My first attempt also considered leaving this part as-is and simply notifying Java-side if we lost focus or not based on `::SetForegroundWindow()` result, but that wasn't consistent. Postponing the window activation seemed to me as the best bet here.

On my system the `SetForegroundWindow` call activates the window and makes it the focus window. We get `WM_ACTIVATE` and `WM_SETFOCUS` and tell the Java side to set the focused property to true. Then `SetForegroundWindow` returns false and we tell the Java side to clear the focused property.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1849#discussion_r2486382236

From zelmidaoui at openjdk.org  Mon Nov  3 12:54:23 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 3 Nov 2025 12:54:23 GMT
Subject: RFR: 8366202: RichTextArea: wrong style used for typed text [v3]
In-Reply-To: <TLf7tNmPvOMnMj9HuMseOTezIxNHhuh53fd_rJYzO9c=.9a4ef33a-34af-42fb-9039-8f9e0c94b912@github.com>
References: <jXJWCEH5_QG54daSS3iS1-iTOC39YN8OTxIQlkOVvJQ=.7599c825-0466-43bf-9c4f-5f225a4a7090@github.com>
 <TLf7tNmPvOMnMj9HuMseOTezIxNHhuh53fd_rJYzO9c=.9a4ef33a-34af-42fb-9039-8f9e0c94b912@github.com>
Message-ID: <fj93lFFO8Cdvz1EmCoLpp0FztM2P8LJ0EuJW-NYtYys=.d8f82a1b-a3b6-42d6-9d06-86b12e082ad9@github.com>

On Fri, 31 Oct 2025 20:38:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> User feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ):
>> 
>> When typing text, in the middle of a sentence, to extend a word that's styled then the typed text is not being inserted using the styles of the preceding text.
>> 
>> Root cause: implementation bug.
>
> Andy Goryachev 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 8366202.wrong
>  - review comments
>  - wrong style

The test works fine, I tried it in the RTA Demo and adding text in middle of sentence keeps the styles of the preceding text.

I noticed one thing is that when clicking at the end of a line of text (or anywhere in the middle) and then changing the color or style it changes the whole line style and color, shouldn't the new color and style be applied on the newly typed text only and not change the existing text color? 
This happens also on master so maybe it's not related to this issue directly
steps to reproduce :

1. Write "testing testing testing"
2. click somewhere on this text without selecting any text
3. change color
4. notice the whole text is changing color (normally it shouldn't change colors of the existing text only the newly typed text)

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

PR Comment: https://git.openjdk.org/jfx/pull/1950#issuecomment-3480373566

From duke at openjdk.org  Mon Nov  3 13:38:23 2025
From: duke at openjdk.org (Alessadro Parisi)
Date: Mon, 3 Nov 2025 13:38:23 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: <QvDVzxnZ2dxi-y2RvwBGY9-CnKeUg7tmXeKKAIvGyF8=.68ae04ff-dc06-4962-8762-4b10035d713e@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <QvDVzxnZ2dxi-y2RvwBGY9-CnKeUg7tmXeKKAIvGyF8=.68ae04ff-dc06-4962-8762-4b10035d713e@github.com>
Message-ID: <UpHuFYCBwOjyA-V-xXIb4D9D6a73l3jH3Jhna1e11BA=.f2c4c3e5-f753-4771-ad0c-b0f4c2569f1f@github.com>

On Thu, 30 Oct 2025 14:08:38 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BaseContext: Add maskTex checks to flushMask()

I have an app that performs a lot of rendering. It creates and needs to store many Canvas objects. I?ve noticed that when the maximum allowed VRAM is exhausted, the app becomes unresponsive and starts throwing multiple NullPointerExceptions.
Does this PR solve the issue?

I also have a couple more questions:
- Is there any way to prevent VRAM saturation? The plan would be to switch to ImageViews once VRAM is full, since they seem to use system RAM instead.
- I read that it?s possible to control the amount of VRAM through the `prism.maxvram` system property. What happens if I set a value much larger than the available VRAM? Does it automatically fall back to system RAM on both iGPUs and dGPUs?

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3480564794

From jhendrikx at openjdk.org  Mon Nov  3 14:04:46 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 3 Nov 2025 14:04:46 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: <UpHuFYCBwOjyA-V-xXIb4D9D6a73l3jH3Jhna1e11BA=.f2c4c3e5-f753-4771-ad0c-b0f4c2569f1f@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <QvDVzxnZ2dxi-y2RvwBGY9-CnKeUg7tmXeKKAIvGyF8=.68ae04ff-dc06-4962-8762-4b10035d713e@github.com>
 <UpHuFYCBwOjyA-V-xXIb4D9D6a73l3jH3Jhna1e11BA=.f2c4c3e5-f753-4771-ad0c-b0f4c2569f1f@github.com>
Message-ID: <WjWOjpdyBVJ87ZP3NCF_JG5wisNfN8jx1iikAyw2oqA=.e105a5b1-7f17-4e7b-bb64-bf806820ddea@github.com>

On Mon, 3 Nov 2025 13:35:26 GMT, Alessadro Parisi <duke at openjdk.org> wrote:

> I have an app that performs a lot of rendering. It creates and needs to store many Canvas objects. I?ve noticed that when the maximum allowed VRAM is exhausted, the app becomes unresponsive and starts throwing multiple NullPointerExceptions. Does this PR solve the issue?

For me it did (I also use large canvas/writableimage and just many images in general).  I included the affected classes, and NPE's went away, and the app keeps functioning (so I'm guessing it is falling back on normal RAM).

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3480703040

From zelmidaoui at openjdk.org  Mon Nov  3 15:49:01 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 3 Nov 2025 15:49:01 GMT
Subject: RFR: 8358023: javafx.scene.control.ColorPicker configure size of
 squares in color pallet
Message-ID: <LT1JTJnZsal4AjwZRMSN6F6PI-GjJmHD-zLu4lNmw4I=.252e6159-f0a1-4fd0-90b4-95409b717583@github.com>

Added new method `setSquareSize(double size)` to be able to customize the size of squares in `ColorPalette` which was previously hardcoded with a value 15

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

Commit messages:
 - Merge branch 'openjdk:master' into 8358023.ColorPickerSquares
 - New setSquareSize method to configure the size of ColorPalette

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

PR: https://git.openjdk.org/jfx/pull/1954

From angorya at openjdk.org  Mon Nov  3 15:49:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 3 Nov 2025 15:49:45 GMT
Subject: RFR: 8366202: RichTextArea: wrong style used for typed text [v3]
In-Reply-To: <fj93lFFO8Cdvz1EmCoLpp0FztM2P8LJ0EuJW-NYtYys=.d8f82a1b-a3b6-42d6-9d06-86b12e082ad9@github.com>
References: <jXJWCEH5_QG54daSS3iS1-iTOC39YN8OTxIQlkOVvJQ=.7599c825-0466-43bf-9c4f-5f225a4a7090@github.com>
 <TLf7tNmPvOMnMj9HuMseOTezIxNHhuh53fd_rJYzO9c=.9a4ef33a-34af-42fb-9039-8f9e0c94b912@github.com>
 <fj93lFFO8Cdvz1EmCoLpp0FztM2P8LJ0EuJW-NYtYys=.d8f82a1b-a3b6-42d6-9d06-86b12e082ad9@github.com>
Message-ID: <t-DvWZS-MXGtWE4SpbUCdOwva3VGmwPv-kbY6KUC_Ms=.a6dd3d25-eaa2-4f51-bcc9-6c69aeb8e2f6@github.com>

On Mon, 3 Nov 2025 12:51:20 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Andy Goryachev 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 8366202.wrong
>>  - review comments
>>  - wrong style
>
> The test works fine, I tried it in the RTA Demo and adding text in middle of sentence keeps the styles of the preceding text.
> 
> I noticed one thing is that when clicking at the end of a line of text (or anywhere in the middle) and then changing the color or style it changes the whole line style and color, shouldn't the new color and style be applied on the newly typed text only and not change the existing text color? 
> This happens also on master so maybe it's not related to this issue directly
> steps to reproduce :
> 
> 1. Write "testing testing testing"
> 2. click somewhere on this text without selecting any text
> 3. change color
> 4. notice the whole text is changing color (normally it shouldn't change colors of the existing text only the newly typed text)

@Ziad-Mid yes, that's the way it's implemented in the demo, for simplicity sake.  Out of scope for this PR, but it should be changed to the way other editors operate.

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

PR Comment: https://git.openjdk.org/jfx/pull/1950#issuecomment-3481204545

From angorya at openjdk.org  Mon Nov  3 16:10:33 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 3 Nov 2025 16:10:33 GMT
Subject: RFR: 8358023: javafx.scene.control.ColorPicker configure size of
 squares in color pallet
In-Reply-To: <LT1JTJnZsal4AjwZRMSN6F6PI-GjJmHD-zLu4lNmw4I=.252e6159-f0a1-4fd0-90b4-95409b717583@github.com>
References: <LT1JTJnZsal4AjwZRMSN6F6PI-GjJmHD-zLu4lNmw4I=.252e6159-f0a1-4fd0-90b4-95409b717583@github.com>
Message-ID: <lHMsl0V5DDJiLm6AanAj4UyVrMlad-OopZsqSV9ietA=.22709550-dea2-47a6-80c6-6cceddd696f6@github.com>

On Wed, 29 Oct 2025 15:10:43 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Added new method `setSquareSize(double size)` to be able to customize the size of squares in `ColorPalette` which was previously hardcoded with a value 15

Question: should we make it a styleable property instead, so the application can configure it with CSS?

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

PR Comment: https://git.openjdk.org/jfx/pull/1954#issuecomment-3481307118

From kcr at openjdk.org  Mon Nov  3 16:17:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Nov 2025 16:17:21 GMT
Subject: RFR: 8371087: Remove unused dependency on jdk.unsupported from
 javafx.graphics
In-Reply-To: <EErboZ2Bm5UNCP8ARa-0y_6xzjbHMfYvWZVzUKo8W1c=.eb8c758e-d09e-449a-a1e4-7dec24fe2ad4@github.com>
References: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
 <hfoycoKEiwObCSMdkv68Vfa9mfg8LG9KHMPewlfyqU4=.6269ce46-bca8-4805-9e47-8f4a14594ffa@github.com>
 <EErboZ2Bm5UNCP8ARa-0y_6xzjbHMfYvWZVzUKo8W1c=.eb8c758e-d09e-449a-a1e4-7dec24fe2ad4@github.com>
Message-ID: <_hKvqhVMg0aeny0-BimmE-lzLW9xxP2kXU5m48sfWSI=.2409a873-49b4-4c12-8dee-5082f600f75e@github.com>

On Sun, 2 Nov 2025 17:18:39 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> > As `sun.misc.Unsafe` is not used anymore, maybe then also remove the references to `XDignore.symbol.file` flag in `build.gradle`.
> > I noticed [JDK-8179462](https://bugs.openjdk.org/browse/JDK-8179462) already exists to remove the flag from javadoc build.
> 
> That sounds indeed reasonable!

Agreed. I'll expand [JDK-8179462](https://bugs.openjdk.org/browse/JDK-8179462) to remove `-XDignore.symbol.file` entirely, both as a javadoc and javac option and then add that issue to this PR.

> As mentioned above, there is one `sun.misc` usage left in the `android` folder, so we may need to check that out first.

Since that file cannot possibly compile without some additional modification to the JDK and/or JavaFX anyway, I don't see any harm removing this option from `build.gradle`. The right fix for the obsolete `sun.misc` usage in the `android` folder would be to replace `sun.misc.BASE64Encoder` with `java.util.Base64` as we did for the rest of JavaFX. I'll file a follow-on bug for that.

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

PR Comment: https://git.openjdk.org/jfx/pull/1957#issuecomment-3481353559

From kcr at openjdk.org  Mon Nov  3 16:31:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Nov 2025 16:31:46 GMT
Subject: RFR: 8371087: Remove unused dependency on jdk.unsupported from
 javafx.graphics [v2]
In-Reply-To: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
References: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
Message-ID: <TgVzu9TFS8Q1dlo-lUDpYMOzAEb-YvNDfOK3nIDqZ40=.d0cb346e-8f1b-4cf4-9441-5ec8c367097b@github.com>

> This PR removes the unused dependency on `jdk.unsupported` from `javafx.graphics` as a followup to [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137), which replaced the use of `sun.misc.Unsafe` with FFM in PR #1814. `sun.misc.Unsafe` was the only use of `jdk.unsupported`, so it can now be removed.

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

  Remove unneeded '-XDignore.symbol.file' option

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1957/files
  - new: https://git.openjdk.org/jfx/pull/1957/files/e390af9a..fe26e6fc

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

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

PR: https://git.openjdk.org/jfx/pull/1957

From kcr at openjdk.org  Mon Nov  3 17:00:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Nov 2025 17:00:50 GMT
Subject: RFR: 8371087: Remove unused dependency on jdk.unsupported from
 javafx.graphics [v2]
In-Reply-To: <TgVzu9TFS8Q1dlo-lUDpYMOzAEb-YvNDfOK3nIDqZ40=.d0cb346e-8f1b-4cf4-9441-5ec8c367097b@github.com>
References: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
 <TgVzu9TFS8Q1dlo-lUDpYMOzAEb-YvNDfOK3nIDqZ40=.d0cb346e-8f1b-4cf4-9441-5ec8c367097b@github.com>
Message-ID: <VBxH-SSHIGPXF23uZqan-uae4i8JXmviJrRPl0QC1mY=.8d7f1d2d-2420-492b-8b09-8103103c2a9a@github.com>

On Mon, 3 Nov 2025 16:31:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the unused dependency on `jdk.unsupported` from `javafx.graphics` as a followup to [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137), which replaced the use of `sun.misc.Unsafe` with FFM in PR #1814. `sun.misc.Unsafe` was the only use of `jdk.unsupported`, so it can now be removed.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded '-XDignore.symbol.file' option

I filed [JDK-8371157](https://bugs.openjdk.org/browse/JDK-8371157) to track replacing the obsolete usage of `sun.misc.BASE64Encoder` in the android dir.

I also filed [JDK-8371158](https://bugs.openjdk.org/browse/JDK-8371158) as a follow-on to investigate removing a workaround for setting javac options that is described as only being needed se we can set `-XDignore.symbol.file`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1957#issuecomment-3481559896

From kcr at openjdk.org  Mon Nov  3 17:05:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Nov 2025 17:05:52 GMT
Subject: RFR: 8371087: Remove unused dependency on jdk.unsupported from
 javafx.graphics [v2]
In-Reply-To: <TgVzu9TFS8Q1dlo-lUDpYMOzAEb-YvNDfOK3nIDqZ40=.d0cb346e-8f1b-4cf4-9441-5ec8c367097b@github.com>
References: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
 <TgVzu9TFS8Q1dlo-lUDpYMOzAEb-YvNDfOK3nIDqZ40=.d0cb346e-8f1b-4cf4-9441-5ec8c367097b@github.com>
Message-ID: <T2oxlxdFKE7DGMFzV4ppEK3Gl_ywJVEdJwmS3HmfELE=.ca96bc1c-81df-4c7f-b1cd-a7f41896cc69@github.com>

On Mon, 3 Nov 2025 16:31:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the unused dependency on `jdk.unsupported` from `javafx.graphics` as a followup to [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137), which replaced the use of `sun.misc.Unsafe` with FFM in PR #1814. `sun.misc.Unsafe` was the only use of `jdk.unsupported`, so it can now be removed.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded '-XDignore.symbol.file' option

@arapte Can you be the primary Reviewer?

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

PR Comment: https://git.openjdk.org/jfx/pull/1957#issuecomment-3481582122

From kcr at openjdk.org  Mon Nov  3 17:21:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Nov 2025 17:21:46 GMT
Subject: RFR: 8240844: Remove dependency on java.desktop from javafx.base
In-Reply-To: <s4sTfLR0m9Ps-C00W_TqTRsM4a0szVpRO7T_FMPOOpo=.56315c2c-9b93-457d-b712-2d9baed984b3@github.com>
References: <s4sTfLR0m9Ps-C00W_TqTRsM4a0szVpRO7T_FMPOOpo=.56315c2c-9b93-457d-b712-2d9baed984b3@github.com>
Message-ID: <dZcUAEXHB1bEgjyQCAp46WeVBbcjdq_nzBxw8ZBqeGc=.f2db045d-89bc-4b89-bad5-492251181a69@github.com>

On Sun, 2 Nov 2025 19:40:04 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR makes the `java.desktop` requirement static for `javafx.base` and `javafx.graphics`.
> With this changes, a JavaFX app without `Swing` and the `WebView` will be much smaller (results below).
> 
> Consequences:
> - `java.desktop` need to be loaded (required) when using anything from the `javafx.beans.property.adapter` package (the property classes from `java.beans.XXX` are used here)
> - `java.desktop` need to be loaded (required) when using printing, that is e.g. `PrinterJob.createPrinterJob().showPrintDialog(..)`
> 
> Results:
> - Removing `java.desktop` gives a huge size boost! I benchmarked the following values when using `jlink` with: [`zip-6`, `--no-man-pages`, `--no-header-files`, `--strip-debug`, `--strip-java-debug-attributes`] to build an own runtime
> 
> Tried on a real application (here called `myapp`) with JDK-25 on Windows 11 that has dependencies to: [`javafx-base`,  `javafx-graphics`, `javafx-fxml`, `javafx-controls`]
> 
> ---
> 
> `master`
> 
> `70.009.288 Bytes`
> 
> 
> myapp
> java.base at 25
> java.datatransfer at 25
> java.desktop at 25
> java.prefs at 25
> java.scripting at 25
> java.xml at 25
> javafx.base at 26-internal
> javafx.controls at 26-internal
> javafx.fxml at 26-internal
> javafx.graphics at 26-internal
> jdk.localedata at 25
> jdk.unsupported at 25
> 
> 
> -------------------------------------
> 
> `This PR`
> 
> `57.266.538 Bytes`
> 
> 
> myapp
> java.base at 25
> java.scripting at 25
> java.xml at 25
> javafx.base at 26-internal
> javafx.controls at 26-internal
> javafx.fxml at 26-internal
> javafx.graphics at 26-internal
> jdk.localedata at 25
> jdk.unsupported at 25
> 
> 
> ---
> 
> `This PR` + https://github.com/openjdk/jfx/pull/1957
> 
> `57.249.459 Bytes`
> 
> 
> myapp
> java.base at 25
> java.scripting at 25
> java.xml at 25
> javafx.base at 26-internal
> javafx.controls at 26-internal
> javafx.fxml at 26-internal
> javafx.graphics at 26-internal
> jdk.localedata at 25
> 
> 
> ---
> 
> So we save around 13MB. If building a native package, e.g. an `.msi` installer, this will be even higher.
> 
> This change however probably need some discussion, if we want to go that direction + add a note in the release notes, that if one of the two things mentioned above are needed, an requirement to `java.desktop` is needed (in case of a modular project).

Three quick comments before I review.

1. This will need a CSR
2. Removing the direct dependency on `java.desktop` from `javafx.base`, making it a `requires static`, seems reasonable, as I wrote in the description of the enhancement request. This will need testing.
3. Removing the direct dependency on `java.desktop` from `javafx.graphics`, making it a `requires static` will almost certainly not be accepted as long as the implementation depends on it. I'll add more details when I review.

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

PR Comment: https://git.openjdk.org/jfx/pull/1958#issuecomment-3481656301

From lbourges at openjdk.org  Mon Nov  3 17:48:50 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 3 Nov 2025 17:48:50 GMT
Subject: RFR: 8371087: Remove unused dependency on jdk.unsupported from
 javafx.graphics [v2]
In-Reply-To: <TgVzu9TFS8Q1dlo-lUDpYMOzAEb-YvNDfOK3nIDqZ40=.d0cb346e-8f1b-4cf4-9441-5ec8c367097b@github.com>
References: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
 <TgVzu9TFS8Q1dlo-lUDpYMOzAEb-YvNDfOK3nIDqZ40=.d0cb346e-8f1b-4cf4-9441-5ec8c367097b@github.com>
Message-ID: <XHF68YmqepZCqnFYkdKXvbLDmFsKmLofWc3A58Ku_X8=.8f4a3c57-6574-46bc-befe-c2a48d784448@github.com>

On Mon, 3 Nov 2025 16:31:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the unused dependency on `jdk.unsupported` from `javafx.graphics` as a followup to [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137), which replaced the use of `sun.misc.Unsafe` with FFM in PR #1814. `sun.misc.Unsafe` was the only use of `jdk.unsupported`, so it can now be removed.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded '-XDignore.symbol.file' option

modules/javafx.graphics/src/main/java/module-info.java line 45:

> 43:     requires java.desktop;
> 44:     requires java.xml;
> 45:     requires jdk.unsupported;

Good job!

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1957#discussion_r2487359926

From kcr at openjdk.org  Mon Nov  3 17:47:40 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Nov 2025 17:47:40 GMT
Subject: RFR: 8358023: javafx.scene.control.ColorPicker configure size of
 squares in color pallet
In-Reply-To: <LT1JTJnZsal4AjwZRMSN6F6PI-GjJmHD-zLu4lNmw4I=.252e6159-f0a1-4fd0-90b4-95409b717583@github.com>
References: <LT1JTJnZsal4AjwZRMSN6F6PI-GjJmHD-zLu4lNmw4I=.252e6159-f0a1-4fd0-90b4-95409b717583@github.com>
Message-ID: <7KxON7yscS4Xyy11e-Rav2NtY9npzTvNQM5aAab1w4g=.5137909c-dbc6-4ea2-aa1b-f47ca4f3db21@github.com>

On Wed, 29 Oct 2025 15:10:43 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Added new method `setSquareSize(double size)` to be able to customize the size of squares in `ColorPalette` which was previously hardcoded with a value 15

Since this PR adds public API, it will need a CSR. And the new public methods will need API docs.

You will also need to automated tests.

> Question: should we make it a styleable property instead, so the application can configure it with CSS?

Yes, I think this would be best.

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

PR Comment: https://git.openjdk.org/jfx/pull/1954#issuecomment-3481760074

From kcr at openjdk.org  Mon Nov  3 17:52:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Nov 2025 17:52:43 GMT
Subject: RFR: 8358023: javafx.scene.control.ColorPicker configure size of
 squares in color pallet
In-Reply-To: <LT1JTJnZsal4AjwZRMSN6F6PI-GjJmHD-zLu4lNmw4I=.252e6159-f0a1-4fd0-90b4-95409b717583@github.com>
References: <LT1JTJnZsal4AjwZRMSN6F6PI-GjJmHD-zLu4lNmw4I=.252e6159-f0a1-4fd0-90b4-95409b717583@github.com>
Message-ID: <q66hlLgdCFThouKxuLpINtpv-Vz9B-VwXCOTasBVibs=.1ee6dd0c-4ef7-4f8a-84af-bf76236b0490@github.com>

On Wed, 29 Oct 2025 15:10:43 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Added new method `setSquareSize(double size)` to be able to customize the size of squares in `ColorPalette` which was previously hardcoded with a value 15

I was about to try and figure out why the lack of javadoc comments didn't fail the build. Then I noticed that the class in question, `ColorPalette.java`, is not a public class.

That means that this PR doesn't actually provide the desired functionality as far as the application is concerned.

This will need more work. I recommend moving it back to Draft until it is ready.

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

PR Comment: https://git.openjdk.org/jfx/pull/1954#issuecomment-3481789850

From mhanl at openjdk.org  Mon Nov  3 17:53:43 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 3 Nov 2025 17:53:43 GMT
Subject: RFR: 8240844: Remove dependency on java.desktop from javafx.base
In-Reply-To: <dZcUAEXHB1bEgjyQCAp46WeVBbcjdq_nzBxw8ZBqeGc=.f2db045d-89bc-4b89-bad5-492251181a69@github.com>
References: <s4sTfLR0m9Ps-C00W_TqTRsM4a0szVpRO7T_FMPOOpo=.56315c2c-9b93-457d-b712-2d9baed984b3@github.com>
 <dZcUAEXHB1bEgjyQCAp46WeVBbcjdq_nzBxw8ZBqeGc=.f2db045d-89bc-4b89-bad5-492251181a69@github.com>
Message-ID: <tjR7OS0gp0OOwR2aJHte3-UxtEg82xpXmjTCOjEfN6Y=.78cf63ca-0c1a-45ae-ab7f-1291511a413b@github.com>

On Mon, 3 Nov 2025 17:19:17 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>     3. Removing the direct dependency on `java.desktop` from `javafx.graphics`, making it a `requires static` will almost certainly not be accepted as long as the implementation depends on it. I'll add more details when I review.

I agree, this change has the biggest 'risk'. Still, I would like to bring this up for discussion, as there is a huge benefit (much higher than I thought).
I have already considered discussing this on the mailing list, but I would like to know first whether this change might be out of question, as we would not need to discuss it in that case.

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

PR Comment: https://git.openjdk.org/jfx/pull/1958#issuecomment-3481791768

From angorya at openjdk.org  Mon Nov  3 18:10:30 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 3 Nov 2025 18:10:30 GMT
Subject: RFR: 8358023: javafx.scene.control.ColorPicker configure size of
 squares in color pallet
In-Reply-To: <q66hlLgdCFThouKxuLpINtpv-Vz9B-VwXCOTasBVibs=.1ee6dd0c-4ef7-4f8a-84af-bf76236b0490@github.com>
References: <LT1JTJnZsal4AjwZRMSN6F6PI-GjJmHD-zLu4lNmw4I=.252e6159-f0a1-4fd0-90b4-95409b717583@github.com>
 <q66hlLgdCFThouKxuLpINtpv-Vz9B-VwXCOTasBVibs=.1ee6dd0c-4ef7-4f8a-84af-bf76236b0490@github.com>
Message-ID: <ZjybTeo7Xp_K05g5FsysIBJHHsPdaq435pOFpLBR6vU=.3e96ea44-30bd-44b4-8019-a2b0ae7156b0@github.com>

On Mon, 3 Nov 2025 17:50:36 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Then I noticed that the class in question, `ColorPalette.java`, is not a public class.

Yes some of its styleable properties are present in modena.css and caspian.css - like `color-picker-grid` selector for instance.  It is not, however, specified in the CSS reference at all (even though the skin itself, `ColorPickerSkin` is a public class).  So if one wants to provide a custom ColorPicker skin, there is no middle ground - either use the stock implementation with a limited range of customization, or create your own.  This is the kind of difficulties one finds working with JavaFX - it's extremely difficult to extend.

So adding (an undocumented) styleable property to `ColorPalette.java` might solve the issue described in the ticket, without requiring a CSR since no public APIs are introduced, right?

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

PR Comment: https://git.openjdk.org/jfx/pull/1954#issuecomment-3481852465

From kcr at openjdk.org  Mon Nov  3 18:29:40 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Nov 2025 18:29:40 GMT
Subject: RFR: 8358023: javafx.scene.control.ColorPicker configure size of
 squares in color pallet
In-Reply-To: <ZjybTeo7Xp_K05g5FsysIBJHHsPdaq435pOFpLBR6vU=.3e96ea44-30bd-44b4-8019-a2b0ae7156b0@github.com>
References: <LT1JTJnZsal4AjwZRMSN6F6PI-GjJmHD-zLu4lNmw4I=.252e6159-f0a1-4fd0-90b4-95409b717583@github.com>
 <q66hlLgdCFThouKxuLpINtpv-Vz9B-VwXCOTasBVibs=.1ee6dd0c-4ef7-4f8a-84af-bf76236b0490@github.com>
 <ZjybTeo7Xp_K05g5FsysIBJHHsPdaq435pOFpLBR6vU=.3e96ea44-30bd-44b4-8019-a2b0ae7156b0@github.com>
Message-ID: <dDXXllLRjR1rpUAQlp_W95qWrZ8ElCX_86QDSEPem9g=.37032949-45db-4d23-92f9-8d80bbf5a730@github.com>

On Mon, 3 Nov 2025 18:08:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Yes some of its styleable properties are present in modena.css and caspian.css - like `color-picker-grid` selector for instance. It is not, however, specified in the CSS reference at all (even though the skin itself, `ColorPickerSkin` is a public class).

Ideally, everything used by `modena.css` would be documented in the CSS guide.

> So if one wants to provide a custom ColorPicker skin, there is no middle ground - either use the stock implementation with a limited range of customization, or create your own. This is the kind of difficulties one finds working with JavaFX - it's extremely difficult to extend.

This highlights the inadequacy of these type of undocumented "back door" properties.

> So adding (an undocumented) styleable property to `ColorPalette.java` might solve the issue described in the ticket, without requiring a CSR since no public APIs are introduced, right?

I'd prefer not to implement this enhancement by adding even more hidden, undocumented, CSS properties. How many such properties are there on ColorPickerSkin? Would it make sense to document them or would that open a larger can of worms?

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

PR Comment: https://git.openjdk.org/jfx/pull/1954#issuecomment-3481919528

From andy.goryachev at oracle.com  Mon Nov  3 18:31:40 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 3 Nov 2025 18:31:40 +0000
Subject: [External] : Re: RichTextArea Feedback
In-Reply-To: <D59F4F9A-21E8-49DE-BAD8-C593977D5F2F@getmailspring.com>
References: <CY8PR10MB72658933F689A807433DDE4CE5F8A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <D59F4F9A-21E8-49DE-BAD8-C593977D5F2F@getmailspring.com>
Message-ID: <CY8PR10MB7265ABB119DC58825687913AE5C7A@CY8PR10MB7265.namprd10.prod.outlook.com>

Dear Jurgen:

It is possible to add a Node to the content, but needs a custom model (see SimpleViewOnlyStyledModel:488).

Also, what does it mean to copy a content with a Node, especially an interactive one, like a TextField?  This question cannot be answered generally, as it depends on the application requirements, thus the custom model.

Having said that, there might still be a need to provide the necessary protected APIs as you suggested.  I've added a note to https://bugs.openjdk.org/browse/JDK-8365948

Thanks!
-andy

From: Jurgen Doll <jurgen at ivoryemr.co.za>
Date: Monday, November 3, 2025 at 01:53
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev <openjfx-dev at openjdk.org>
Subject: [External] : Re: RichTextArea Feedback

Hi Andy

Thanks for posting a summary to the dev list.

With regards to this point:

>> As expected though paste and undo/redo don't work due to
> StyledTextModel's final replace method not handling INLINE_NODE's
>
> This is correct, and I think it might be better to leave up to the
> (custom) model.  The reason for it is it should be up to the
> application/custom model to decide how to deal with the embedded
> nodes, especially interactive ones.

I understand your rational, however having tried it myself (with two
different models) I can claim with a high degree of confidence that it's
currently impossible. Unless I've missed something, a developer
extending any form of StyledTextModel cannot accomplish this.

The fix if I'm not mistaken is straightforward. What is required is
the addition of something like the following method to StyledTextModel:

protected abstract int insertNodeSegment(int index, int offset,
Supplier<Node> sup, StyleAttributeMap? attrs?);

and that the method:

public final TextPos replace(..., StyledInput input)

then handles INLINE_NODE and appropriately invokes this added
insertNodeSegment method.

All your current sub-classes of StyledTextModel can then just implement
No-Op implementations of insertNodeSegment. Of course it would be
awesome if RichTextModel could handle inline nodes out of the box.

I hope this meets with your approval and if I've missed something please
let me know.

Thanks, regards
Jurgen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251103/cf319a58/attachment-0001.htm>

From angorya at openjdk.org  Mon Nov  3 18:46:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 3 Nov 2025 18:46:08 GMT
Subject: RFR: 8358023: javafx.scene.control.ColorPicker configure size of
 squares in color pallet
In-Reply-To: <LT1JTJnZsal4AjwZRMSN6F6PI-GjJmHD-zLu4lNmw4I=.252e6159-f0a1-4fd0-90b4-95409b717583@github.com>
References: <LT1JTJnZsal4AjwZRMSN6F6PI-GjJmHD-zLu4lNmw4I=.252e6159-f0a1-4fd0-90b4-95409b717583@github.com>
Message-ID: <A0TCeb3LgRJQKauA07_1RuIrA3yDd9EOwYwuh0KPDFg=.2ef5b742-44af-4218-ac97-11f1eb1aebbd@github.com>

On Wed, 29 Oct 2025 15:10:43 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Added new method `setSquareSize(double size)` to be able to customize the size of squares in `ColorPalette` which was previously hardcoded with a value 15

This is a good question.  We already have a can of worms on our hands, so we need to figure out what to do with it.

First of all, we should decide (speaking generally) what properties should be in the control, to be applied to all the possible skins, and which properties are specific to a particular Skin implementation.  In this particular case, the size of the grid cell does not seem to belong to the control, it's clearly a property of the skin.

Then, we need to decide whether we allow extending that particular skin, and the degree in which we allow this.  We may want to document the structure (hierarchy and style classes) of the skin - maybe in cssref.html, or in the skin's javadoc or similar place (Example: VFlow:78).
Keep in mind that we do support both modena and caspian themes, to any changes to styles need to be reflected in both.

Or maybe even go further and design the skins explicitly to allow extension - using extendable classes and methods.

Then, of course, there is a question of extending behavior and that's where the discussion stalls.

What do you think?

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

PR Comment: https://git.openjdk.org/jfx/pull/1954#issuecomment-3481991172

From andy.goryachev at oracle.com  Mon Nov  3 18:59:58 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 3 Nov 2025 18:59:58 +0000
Subject: [External] : Re: RichTextArea Feedback
In-Reply-To: <EFD96B2E-F49A-4E2E-9EF2-2D8B0744ABA6@getmailspring.com>
References: <CY8PR10MB72658933F689A807433DDE4CE5F8A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <EFD96B2E-F49A-4E2E-9EF2-2D8B0744ABA6@getmailspring.com>
Message-ID: <CY8PR10MB72656AB5648465E0F6AB2AE1E5C7A@CY8PR10MB7265.namprd10.prod.outlook.com>

Right, sorry, missed that one.

This might get complicated - while that might work for an in-memory model, it will be very complicated in the case of a large virtualized model.

An alternative might be to remove 'final' from replace(StyleResolver resolver, TextPos start, TextPos end, StyledInput input), or to allow a callback before the actual changes are made.

I am not sure about the use case for this though.  If you simply want to do a syntax or spelling check highlighter, you might need to keep a separate data structure that allows one to do, for example, a partial update, or to get the plain text from the model, or something else entirely.

-andy


From: Jurgen Doll <jurgen at ivoryemr.co.za>
Date: Monday, November 3, 2025 at 00:36
To: Andy Goryachev <andy.goryachev at oracle.com>
Subject: [External] : Re: RichTextArea Feedback

Hi Andy

> Did I miss anything?  Please let me know. #2

Also, the RFE regarding ContentChange:

This is a request to enhance ContentChange with an additional method: getPreviousSegments()

Currently ContentChange reports only where something has changed.
Using this one can determine the current state of the document, however
determining what has actually changed is impossible. So having this
extra information available would be helpful.

I think this can easily be done in StyledTextModel where the previous
segments can be obtained by extracting them from the freshly created
UndoableChange object when calling fire?ChangeEvent(...)

Thanks, regards
Jurgen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251103/7bbd9f78/attachment.htm>

From angorya at openjdk.org  Mon Nov  3 19:57:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 3 Nov 2025 19:57:45 GMT
Subject: RFR: 8371080: RichTextArea: missing styles in Caspian
Message-ID: <14Fv8RMnNEHSsBpXqu4G11ITFEt_ETTmBZ8OTJaoptM=.9ecc21e1-6664-425f-b472-03849e3d069f@github.com>

Added missing RichTextArea styles to `caspian.css`.

This is a trivial change.

To test, one can use the latest Monkey Tester Window -> Stylesheet menu.
https://github.com/andy-goryachev-oracle/MonkeyTest

<img width="1021" height="350" alt="Screenshot 2025-11-03 at 11 50 50" src="https://github.com/user-attachments/assets/8559e702-5294-4a98-a251-f3b2283d7a83" />

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

Commit messages:
 - added rich text area styles to caspian.css

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

PR: https://git.openjdk.org/jfx/pull/1959

From kcr at openjdk.org  Mon Nov  3 20:37:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Nov 2025 20:37:50 GMT
Subject: RFR: 8358023: javafx.scene.control.ColorPicker configure size of
 squares in color pallet
In-Reply-To: <A0TCeb3LgRJQKauA07_1RuIrA3yDd9EOwYwuh0KPDFg=.2ef5b742-44af-4218-ac97-11f1eb1aebbd@github.com>
References: <LT1JTJnZsal4AjwZRMSN6F6PI-GjJmHD-zLu4lNmw4I=.252e6159-f0a1-4fd0-90b4-95409b717583@github.com>
 <A0TCeb3LgRJQKauA07_1RuIrA3yDd9EOwYwuh0KPDFg=.2ef5b742-44af-4218-ac97-11f1eb1aebbd@github.com>
Message-ID: <NI72bkeuoM8saRUTvRzrz8lUb4HmZ3wPWhqVe36ZXLE=.8d93b363-e09f-4181-9f9c-5c9bf17c5e4d@github.com>

On Mon, 3 Nov 2025 18:43:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This is a good question. We already have a can of worms on our hands, so we need to figure out what to do with it.

You are right.

In this specific case, we have many color picker skin properties in `modena.css` and none are documented. The only thing about the skin that is documented is this, from the CSS guide:


Substructure

    color display node ? Label
    arrow-button ? StackPane
        arrow ? StackPane


Nothing at all about the popup or the palette.

> First of all, we should decide (speaking generally) what properties should be in the control, to be applied to all the possible skins, and which properties are specific to a particular Skin implementation.

Right. One thing to note is that if a property is in the skin, and we document it and provide public API in our skin implementation, we are effectively "suggesting" that all skins implement that property.

> In this particular case, the size of the grid cell does not seem to belong to the control, it's clearly a property of the skin.

Perhaps, although there are many controls where sizing information is taken from the control. The most obvious example is text font and size for controls that have a label, which propagates from the control (Button, Label, ComboBox, etc) to the skin. That may or may not make a case for adding the size of the grid cell to the control.

> Then, we need to decide whether we allow extending that particular skin, and the degree in which we allow this. We may want to document the structure (hierarchy and style classes) of the skin - maybe in cssref.html, or in the skin's javadoc or similar place (Example: VFlow:78). Keep in mind that we do support both modena and caspian themes, to any changes to styles need to be reflected in both.

Yes, this is the larger issue. Whatever we do would probably be limited to those attributes that are not overly specific to one particular skin implementation.

> Or maybe even go further and design the skins explicitly to allow extension - using extendable classes and methods.

This would be a large effort, and probably not something we want to tackle.

> Then, of course, there is a question of extending behavior and that's where the discussion stalls.

Right. We are unlikely to address this any time soon.


Getting back to this specific enhancement request, we seem to have a few options, presuming we want to provide this capability without having it blocked by a much larger effort:

1. Add a private, undocumented styleable CSS property that app developers have to discover by looking at `modena.css`, reading the source code, or reading the comments in the JBS issue that implemented it. (as you can guess, I don't like this option)
2. Provide a documented styleable CSS property that would apply to the skin, but without way to set it via API on the skin
3. Provide a documented styleable CSS property in ColorPickerSkin so that there is public API as well as it being settable via CSS.
4. Add a styleable property to the ColorPicker control, which the skin would then implement.
5. Something else?

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

PR Comment: https://git.openjdk.org/jfx/pull/1954#issuecomment-3482489442

From angorya at openjdk.org  Mon Nov  3 21:19:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 3 Nov 2025 21:19:00 GMT
Subject: RFR: 8358023: javafx.scene.control.ColorPicker configure size of
 squares in color pallet
In-Reply-To: <LT1JTJnZsal4AjwZRMSN6F6PI-GjJmHD-zLu4lNmw4I=.252e6159-f0a1-4fd0-90b4-95409b717583@github.com>
References: <LT1JTJnZsal4AjwZRMSN6F6PI-GjJmHD-zLu4lNmw4I=.252e6159-f0a1-4fd0-90b4-95409b717583@github.com>
Message-ID: <iVcfiDkwm0jHZstYIAGi4FeHKU5BCBj0uQqMNOCfC-0=.66acae83-3ed0-47f2-b583-e915f13b940b@github.com>

On Wed, 29 Oct 2025 15:10:43 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Added new method `setSquareSize(double size)` to be able to customize the size of squares in `ColorPalette` which was previously hardcoded with a value 15

Good points!

I might suggest option 1 for this PR, with a follow-up created for improving CSS ref regarding the missing structure and styles (and maybe a discussion on the mailing list about what to document and where).  I think we ought to document the default skin structure, but make it clear that the structure and the styles describe the default skin implementation for the purposes of styling.

I don't know whether it makes sense to extract the skins css ref into a separate document or not - it might still be easier from the hosting point of view to keep everything in one place since we don't really have a proper CMS.

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

PR Comment: https://git.openjdk.org/jfx/pull/1954#issuecomment-3482637925

From kcr at openjdk.org  Mon Nov  3 21:43:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Nov 2025 21:43:01 GMT
Subject: RFR: 8240844: Remove dependency on java.desktop from javafx.base
In-Reply-To: <s4sTfLR0m9Ps-C00W_TqTRsM4a0szVpRO7T_FMPOOpo=.56315c2c-9b93-457d-b712-2d9baed984b3@github.com>
References: <s4sTfLR0m9Ps-C00W_TqTRsM4a0szVpRO7T_FMPOOpo=.56315c2c-9b93-457d-b712-2d9baed984b3@github.com>
Message-ID: <qNq8ouvKhSEwQAvmIUGhU3tKkm6XSAnd-r3P85KaMzI=.cfea9ff2-c81a-4268-979a-76795b82c5ac@github.com>

On Sun, 2 Nov 2025 19:40:04 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR makes the `java.desktop` requirement static for `javafx.base` and `javafx.graphics`.
> With this changes, a JavaFX app without `Swing` and the `WebView` will be much smaller (results below).
> 
> Consequences:
> - `java.desktop` need to be loaded (required) when using anything from the `javafx.beans.property.adapter` package (the property classes from `java.beans.XXX` are used here)
> - `java.desktop` need to be loaded (required) when using printing, that is e.g. `PrinterJob.createPrinterJob().showPrintDialog(..)`
> 
> Results:
> - Removing `java.desktop` gives a huge size boost! I benchmarked the following values when using `jlink` with: [`zip-6`, `--no-man-pages`, `--no-header-files`, `--strip-debug`, `--strip-java-debug-attributes`] to build an own runtime
> 
> Tried on a real application (here called `myapp`) with JDK-25 on Windows 11 that has dependencies to: [`javafx-base`,  `javafx-graphics`, `javafx-fxml`, `javafx-controls`]
> 
> ---
> 
> `master`
> 
> `70.009.288 Bytes`
> 
> 
> myapp
> java.base at 25
> java.datatransfer at 25
> java.desktop at 25
> java.prefs at 25
> java.scripting at 25
> java.xml at 25
> javafx.base at 26-internal
> javafx.controls at 26-internal
> javafx.fxml at 26-internal
> javafx.graphics at 26-internal
> jdk.localedata at 25
> jdk.unsupported at 25
> 
> 
> -------------------------------------
> 
> `This PR`
> 
> `57.266.538 Bytes`
> 
> 
> myapp
> java.base at 25
> java.scripting at 25
> java.xml at 25
> javafx.base at 26-internal
> javafx.controls at 26-internal
> javafx.fxml at 26-internal
> javafx.graphics at 26-internal
> jdk.localedata at 25
> jdk.unsupported at 25
> 
> 
> ---
> 
> `This PR` + https://github.com/openjdk/jfx/pull/1957
> 
> `57.249.459 Bytes`
> 
> 
> myapp
> java.base at 25
> java.scripting at 25
> java.xml at 25
> javafx.base at 26-internal
> javafx.controls at 26-internal
> javafx.fxml at 26-internal
> javafx.graphics at 26-internal
> jdk.localedata at 25
> 
> 
> ---
> 
> So we save around 13MB. If building a native package, e.g. an `.msi` installer, this will be even higher.
> 
> This change however probably need some discussion, if we want to go that direction + add a note in the release notes, that if one of the two things mentioned above are needed, an requirement to `java.desktop` is needed (in case of a modular project).

Changes requested by kcr (Lead).

modules/javafx.graphics/src/main/java/module-info.java line 43:

> 41:  */
> 42: module javafx.graphics {
> 43:     requires java.desktop;

As commented on in general comments, this is an incompatible change. A general discussion on the mailing list is needed to determine whether we want to consider this.

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

PR Review: https://git.openjdk.org/jfx/pull/1958#pullrequestreview-3413029573
PR Review Comment: https://git.openjdk.org/jfx/pull/1958#discussion_r2487927810

From kcr at openjdk.org  Mon Nov  3 21:43:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Nov 2025 21:43:02 GMT
Subject: RFR: 8240844: Remove dependency on java.desktop from javafx.base
In-Reply-To: <tjR7OS0gp0OOwR2aJHte3-UxtEg82xpXmjTCOjEfN6Y=.78cf63ca-0c1a-45ae-ab7f-1291511a413b@github.com>
References: <s4sTfLR0m9Ps-C00W_TqTRsM4a0szVpRO7T_FMPOOpo=.56315c2c-9b93-457d-b712-2d9baed984b3@github.com>
 <dZcUAEXHB1bEgjyQCAp46WeVBbcjdq_nzBxw8ZBqeGc=.f2db045d-89bc-4b89-bad5-492251181a69@github.com>
 <tjR7OS0gp0OOwR2aJHte3-UxtEg82xpXmjTCOjEfN6Y=.78cf63ca-0c1a-45ae-ab7f-1291511a413b@github.com>
Message-ID: <UHNs54BwMU24SdYlaA5D5oyptkNGP8OKmB1hDmAAjsU=.1762b089-d12d-47da-ae0d-00a1af356da8@github.com>

On Mon, 3 Nov 2025 17:51:12 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> > 3. Removing the direct dependency on `java.desktop` from `javafx.graphics`, making it a `requires static` will almost certainly not be accepted as long as the implementation depends on it. I'll add more details when I review.
> 
> I agree, this change has the biggest 'risk'. Still, I would like to bring this up for discussion, as there is a huge benefit (much higher than I thought). I have already considered discussing this on the mailing list, but I would like to know first whether this change might be out of question, as we would not need to discuss it in that case.

While I might not quite go as far as to say "out of the question", it is unlikely that such a proposal would be accepted. This would be an incompatible change, which we very rarely do, especially for features that are still useful (and even then, not without notice, such as deprecating API for removal, followed by later removal). Applications that use JavaFX Printing APIs would stop working in some cases, unpredictably so, since it would work as long as any other module required java.desktop, but would fail at runtime if not (with a confusing error message). The recently-added ImageIO support added to images would also behave differently. Whereas today loading a ".tiff" file will just work (by falling back to the ImageIO TIFF loader shipped with java.desktop), it would fail to load (gracefully, but it would fail nonetheless).

The difference between the `javafx.graphics` usage and the `javafx.base` usage, is that the `javafx.graphics` usage of `java.desktop` for printing is incidental, and is an implementation detail as far as the app is concerns: There is nothing in the API docs that suggests the use of the Java2D printing API. So we would effectively have to tell application developers -- via API docs, a CSR, and a release note (at least) -- "if you want to use these APIs, your application now has to add a dependency on `java.desktop` because we no longer do". That will be a hard sell.

So, feel free to raise it on the mailing list. In the mean time, either move this to Draft or revert the change in javafx.graphics.

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

PR Comment: https://git.openjdk.org/jfx/pull/1958#issuecomment-3482703068

From kcr at openjdk.org  Tue Nov  4 00:02:25 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 00:02:25 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: <JHBs7PUrjSO8k1CUsdr819Rue1j2UTPfVZ4VnflN7qw=.fe15ba0e-fdc0-444f-8975-60b9b4a4bc7f@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <QvDVzxnZ2dxi-y2RvwBGY9-CnKeUg7tmXeKKAIvGyF8=.68ae04ff-dc06-4962-8762-4b10035d713e@github.com>
 <4rzaU_8iDK34kOSpHtLK7VE43OrI8xbNKFgFBio8ow0=.5c8ebfef-1d00-43d4-a102-409433dcf7cb@github.com>
 <JHBs7PUrjSO8k1CUsdr819Rue1j2UTPfVZ4VnflN7qw=.fe15ba0e-fdc0-444f-8975-60b9b4a4bc7f@github.com>
Message-ID: <HBRKWrlatQmtX1H6x_sBD3LBfcErkF2Aa3dDWkQCo2Y=.9b0a0fb6-7e31-4b50-97a8-5ca0ac4cc324@github.com>

On Mon, 3 Nov 2025 11:21:53 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DTextureResource.java line 41:
>> 
>>> 39:         if (resource != null) {
>>> 40:             resource.dispose();
>>> 41:             resource = null;
>> 
>> We do not set the resource to `null` for any classes like `D3DTextureResource`, `MTLTextureResource` or `ES2TextureResource`. But the actual reference to native resource is set to **0** in the `resource.dispose();` call ( i.e. in classes like, `D3DTextureData`, `MTLTextureData`, `ES2TextureData` ). So the actual dispose of resource is already guarded.
>> 
>> Setting null only for D3D may cause confusion, as to why is it not done for other pipelines.
>> So, I would recommend to remove, as current code is safe. Or
>> add the same for other pipelines as well.
>
> Might be worth adding a comment that the resource is freed natively so there's no need to dereference.

That might be a good idea (for all pipelines).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1951#discussion_r2488193229

From kcr at openjdk.org  Tue Nov  4 00:02:26 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 00:02:26 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: <HwCbOlYsnZb7oZ5FMPHv29SjboagD4f8KtwYAz6z6B0=.a6494c3e-8595-4fc8-899d-814851e57dd4@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <QvDVzxnZ2dxi-y2RvwBGY9-CnKeUg7tmXeKKAIvGyF8=.68ae04ff-dc06-4962-8762-4b10035d713e@github.com>
 <lAFGM-gteBGlk9cOsRr4YmT332TcWY2m7RD_5gM-Du4=.1295ec65-c53b-456a-810d-d90a66ce872c@github.com>
 <2FWS9tiiKQMpTOs88Czu4dXoe-27anWId3ppau-1Dog=.b0e85d3d-fd3c-4658-b64c-376d1a4ed77c@github.com>
 <HwCbOlYsnZb7oZ5FMPHv29SjboagD4f8KtwYAz6z6B0=.a6494c3e-8595-4fc8-899d-814851e57dd4@github.com>
Message-ID: <_bn4DJQpYGPustVKn-XZyqCfkNmdgHqq4D7F7qJ6Bl4=.f70e6b5e-a33b-4137-a573-c91517d67fe6@github.com>

On Mon, 3 Nov 2025 11:19:05 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Fair point. I think this code works regardless because originally `maskTex` was supposed to be guarded by `curMaskRow` and `curMaskCol` below being set to zero.
>> 
>> I will change it to the above.
>
> If this check fixes this particular issue, then can the calls `!resource.isValid()` be removed ?

I think they should remain unless we are absolutely certain that this is the only possibly place where `update` can be called on a texture that has been released.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1951#discussion_r2488195650

From andy.goryachev at oracle.com  Tue Nov  4 00:25:10 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 4 Nov 2025 00:25:10 +0000
Subject: [External] : Re: RichTextArea Feedback
In-Reply-To: <EA1725F8-A0DE-47A2-86D1-A6880E0C14FF@getmailspring.com>
References: <CY8PR10MB72658933F689A807433DDE4CE5F8A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <EA1725F8-A0DE-47A2-86D1-A6880E0C14FF@getmailspring.com>
Message-ID: <CY8PR10MB7265F7EB7CA778E55A9FDBA9E5C4A@CY8PR10MB7265.namprd10.prod.outlook.com>

Indeed!  Filed https://bugs.openjdk.org/browse/JDK-8371183

Thanks,
-andy


From: Jurgen Doll <jurgen at ivoryemr.co.za>
Date: Sunday, November 2, 2025 at 23:18
To: Andy Goryachev <andy.goryachev at oracle.com>
Subject: [External] : Re: RichTextArea Feedback

Hi Andy

> Did I miss anything?  Please let me know.

The summary covers most points, just need to also add the issue regarding:
Undoing a style only change fires a change event where ContentChange.isEdit is true when it should be false.

Thanks, regards
Jurgen


On Oct 31 2025, at 7:29 pm, Andy Goryachev <andy.goryachev at oracle.com> wrote:

Dear Jurgen:

Thank you for the feedback!  Let's see if I could give a satisfactory response.

> In RichParagraph you have a note to make getSegments() public.

Yes, either this list must be made immutable (by adding some overhead) or we could add getSegmentCount() and getSegmentAt(int).  Created RFE https://bugs.openjdk.org/browse/JDK-8371070

> When an INLINE_NODE in RichTextArea is updated and it triggers
requestLayout then the request doesn't propagate all the way up to VFlow
but stops when it reaches TextCell.

Interesting, I'll need to investigate.  Created https://bugs.openjdk.org/browse/JDK-8371067

> When a paragraph ends with an INLINE_NODE and one tries to go to the end
of the line/paragraph (either via API or K/B end) then the caret moves
to the starting position of the node and not after it.

Support for inline nodes is not yet complete, see https://bugs.openjdk.org/browse/JDK-8365948
Created https://bugs.openjdk.org/browse/JDK-8371067 to address this specific scenario.

> As expected though paste and undo/redo don't work due to
StyledTextModel's final replace method not handling INLINE_NODE's

This is correct, and I think it might be better to leave up to the (custom) model.  The reason for it is it should be up to the application/custom model to decide how to deal with the embedded nodes, especially interactive ones.

There exists a special case of embedding images - images are a binary objects that can be easily duplicated, copied, exported, and pasted.  See https://bugs.openjdk.org/browse/JDK-8365949

Did I miss anything?  Please let me know.

And keep that feedback coming!

Cheers,
-andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251104/80ae8657/attachment-0001.htm>

From arapte at openjdk.org  Tue Nov  4 01:19:54 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 4 Nov 2025 01:19:54 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1 [v2]
In-Reply-To: <AqYPkdmL8rn6F-gdhFHBoa7qB37H_mOsqC1NxxvaGFM=.7d7c0324-599d-4594-b8e4-1df4ceceef73@github.com>
References: <AqYPkdmL8rn6F-gdhFHBoa7qB37H_mOsqC1NxxvaGFM=.7d7c0324-599d-4594-b8e4-1df4ceceef73@github.com>
Message-ID: <nXmVVf0_DJbmJ5-XTc310SxO7WsAouHaeNYnNWRClh8=.023781b2-feab-4e5a-87ce-6a4b0ea56c74@github.com>

> Update boot jdk to 25.0.1, along with gradle update to version 9.1.0.
> The gradle 9 related deprecation are already addressed with [JDK-8360586](https://bugs.openjdk.org/browse/JDK-8360586)

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

  gradle update to 920

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1953/files
  - new: https://git.openjdk.org/jfx/pull/1953/files/209486a1..08bd27f6

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

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1953.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1953/head:pull/1953

PR: https://git.openjdk.org/jfx/pull/1953

From arapte at openjdk.org  Tue Nov  4 01:28:23 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 4 Nov 2025 01:28:23 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1 [v2]
In-Reply-To: <nIIIIbpxx9TRK-mGduMqpn_QoBD2BXdm4X2m1F_ibPo=.12ebb785-163f-44e8-9b8a-f8779694e87b@github.com>
References: <AqYPkdmL8rn6F-gdhFHBoa7qB37H_mOsqC1NxxvaGFM=.7d7c0324-599d-4594-b8e4-1df4ceceef73@github.com>
 <nIIIIbpxx9TRK-mGduMqpn_QoBD2BXdm4X2m1F_ibPo=.12ebb785-163f-44e8-9b8a-f8779694e87b@github.com>
Message-ID: <9nraDSz6JYhfkxxXnbH5JN-DS0bkIFIxKh3DU3w6aBk=.63d065b2-c852-4efe-b058-5506bb069b8f@github.com>

On Fri, 31 Oct 2025 14:31:47 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> Also worked with the newest Gradle version 9.2.0 for me! 

Thanks for checking with gradle 9.2.0. 
Changed the PR and the bug to update to gradle 9.2.0

Please have a relook.

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

PR Comment: https://git.openjdk.org/jfx/pull/1953#issuecomment-3483305210

From lkostyra at openjdk.org  Tue Nov  4 07:33:07 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 4 Nov 2025 07:33:07 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: <UpHuFYCBwOjyA-V-xXIb4D9D6a73l3jH3Jhna1e11BA=.f2c4c3e5-f753-4771-ad0c-b0f4c2569f1f@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <QvDVzxnZ2dxi-y2RvwBGY9-CnKeUg7tmXeKKAIvGyF8=.68ae04ff-dc06-4962-8762-4b10035d713e@github.com>
 <UpHuFYCBwOjyA-V-xXIb4D9D6a73l3jH3Jhna1e11BA=.f2c4c3e5-f753-4771-ad0c-b0f4c2569f1f@github.com>
Message-ID: <BWKxw8tRQXJyPPSU7upQ4FAGFIwo8hD1FtqbZFqOrUk=.cc27044b-08a3-4bc2-a47d-87377c6fa1c9@github.com>

On Mon, 3 Nov 2025 13:35:26 GMT, Alessadro Parisi <duke at openjdk.org> wrote:

> I read that it?s possible to control the amount of VRAM through the prism.maxvram system property. What happens if I set a value much larger than the available VRAM? Does it automatically fall back to system RAM on both iGPUs and dGPUs?

In most cases this is in hands of the runtime and the driver. In D3D and ES2 during allocation we provide those with a hint on how the memory is used and the runtime/driver determine the best spot for it. When VRAM runs out most drivers will delegate such allocation to system RAM making it slower to access (especially on dGPUs; iGPUs often share RAM memory with the system already) but keeping the application alive.

Modern APIs are more explicit about this - both Vulkan and D3D12 need you to specify (at least to some degree) which memory type you want your newly allocated region to exist in - but this is not the problem in case of JavaFX (yet =) ).

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3484142333

From lkostyra at openjdk.org  Tue Nov  4 07:33:25 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 4 Nov 2025 07:33:25 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: <HBRKWrlatQmtX1H6x_sBD3LBfcErkF2Aa3dDWkQCo2Y=.9b0a0fb6-7e31-4b50-97a8-5ca0ac4cc324@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <QvDVzxnZ2dxi-y2RvwBGY9-CnKeUg7tmXeKKAIvGyF8=.68ae04ff-dc06-4962-8762-4b10035d713e@github.com>
 <4rzaU_8iDK34kOSpHtLK7VE43OrI8xbNKFgFBio8ow0=.5c8ebfef-1d00-43d4-a102-409433dcf7cb@github.com>
 <JHBs7PUrjSO8k1CUsdr819Rue1j2UTPfVZ4VnflN7qw=.fe15ba0e-fdc0-444f-8975-60b9b4a4bc7f@github.com>
 <HBRKWrlatQmtX1H6x_sBD3LBfcErkF2Aa3dDWkQCo2Y=.9b0a0fb6-7e31-4b50-97a8-5ca0ac4cc324@github.com>
Message-ID: <uUVX1fYForv7_CC8PFI30Ta4w8CFT7GELzTrmIChG3A=.6cb0dbde-1419-48b5-9816-5b08bbc63d08@github.com>

On Mon, 3 Nov 2025 23:57:50 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Might be worth adding a comment that the resource is freed natively so there's no need to dereference.
>
> That might be a good idea (for all pipelines).

~~It does make more sense, I noticed that we also often check `resource.isValid()` but we don't precede it with `resource == null` which would cause another potential NPE.~~

I'll revert this and add a comment in all backend-specific `*TextureResource` classes

**EDIT:** I got the `resource` instances mixed up - the checks I was thinking of would be for an instance of `D3D/ES2/MTLTextureResource`, not its underlying `D3D/ES2/MTLTextureData` instance that is also referred to as `resource` variable.

Still, the `ManagedResource` class that we extend in the backends will handle the `resource = null` set, so this addition is redundant.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1951#discussion_r2488936531

From lkostyra at openjdk.org  Tue Nov  4 08:04:51 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 4 Nov 2025 08:04:51 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v4]
In-Reply-To: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
Message-ID: <2dRJ3IhppfvY0ZhqCqtM_qjSqQD-lKh-TG3w_ZqtEFw=.3c040e21-0e1c-48d8-8129-f5a70a6eb2d6@github.com>

> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
> 
> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
> 
> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.

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

  Review comments - ES2 check + extra code comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1951/files
  - new: https://git.openjdk.org/jfx/pull/1951/files/1e1832f3..683b6591

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

  Stats: 18 lines in 5 files changed: 16 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1951.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1951/head:pull/1951

PR: https://git.openjdk.org/jfx/pull/1951

From psadhukhan at openjdk.org  Tue Nov  4 09:13:57 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Nov 2025 09:13:57 GMT
Subject: RFR: 8371128: NullPointerException occurs due to double cleanup of
 SwingNode
Message-ID: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>

It is seen that when we close the SwingNode window while we have registered a WINDOW_HIDDEN listener, it will cause a NPE 
This is because WINDOW_HIDDEN listener called `SwingNode.overrideNativeWindowHandle` to provide a native FX window handle to AWT/Swing via JNI code, which gives provision to AWT/Swing code in sun/swing/JLightweightFrame.java#overrideNativeWindowHandle to handle the window closing

https://github.com/openjdk/jdk/blob/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/src/java.desktop/share/classes/sun/swing/JLightweightFrame.java#L527-L534

But if window is closed, then the node is removed from scene and `SwingNode.disposeLwFrame` is called which nulls "lwFrame" which is the handle for JLightweightFrame AWT frame, so when JNI code 
https://github.com/openjdk/jfx/blob/c77c2335856a967907aaacc9546f44943c069add/modules/javafx.graphics/src/main/native-prism/SwingInterop.c#L47

tries to call JLightweightFrame, it crashes.
Fix is made to check for `lwFrame `before `overrideNativeWindowHandle ` is called inside `SwingNodeHelper.runOnEDT`. 
This is common practice employed inside `SwingNodeHelper.runOnEDT` to check for lwFrame to be not null

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

Commit messages:
 - 8371128: NullPointerException occurs due to double cleanup of SwingNode
 - 8371128: NullPointerException occurs due to double cleanup of SwingNode

Changes: https://git.openjdk.org/jfx/pull/1960/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1960&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371128
  Stats: 103 lines in 2 files changed: 100 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1960.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1960/head:pull/1960

PR: https://git.openjdk.org/jfx/pull/1960

From jurgen at ivoryemr.co.za  Tue Nov  4 09:40:22 2025
From: jurgen at ivoryemr.co.za (Jurgen Doll)
Date: Tue, 4 Nov 2025 11:40:22 +0200
Subject: [External] : Re: RichTextArea Feedback
In-Reply-To: <CY8PR10MB72656AB5648465E0F6AB2AE1E5C7A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CY8PR10MB72656AB5648465E0F6AB2AE1E5C7A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <F70DB26E-A625-4EE6-80A7-C7CDE8BE8B94@getmailspring.com>

Hi Andy

> This might get complicated - while that might work for an in-memory
> model, it will be very complicated in the case of a large virtualized model.

I don't see how it's complicated, and I don't think the model matters.
As far as I can see the changes required are quite straightforward.

Here's a brief outline: In StyledTextModel, in both the applyStyle:766
and replace(...,StyledInput):663 methods there's the line:
UndoableChange ch = ...

Then a little further down in both of these methods there's a
fireStyleChangeEvent and fireChangeEvent line respectively which will
now each get an extra parameter, something like:
fire(Style)ChangeEvent(..., ch.getUndoSegments());

This extra parameter is a StyledSegment[] which is then passed on to
ContentChange where it's made available via something like: getPreviousSegments()

That's it :-) If I've missed the complicated part please let me know.

Thanks, regards
Jurgen


On Nov 3 2025, at 8:59 pm, Andy Goryachev <andy.goryachev at oracle.com> wrote:

> Right, sorry, missed that one.
>  
> This might get complicated - while that might work for an in-memory
> model, it will be very complicated in the case of a large virtualized model.
>  
> An alternative might be to remove 'final' from replace(StyleResolver
> resolver, TextPos start, TextPos end, StyledInput input), or to allow
> a callback before the actual changes are made.
>  
> I am not sure about the use case for this though. ?If you simply want
> to do a syntax or spelling check?highlighter, you might need to keep a
> separate data structure that allows one to do, for example, a partial
> update, or to get the plain text from the model, or something else entirely.
>  
> -andy
>  
>  
> From: Jurgen Doll <jurgen at ivoryemr.co.za>
> Date: Monday, November 3, 2025 at 00:36
> To: Andy Goryachev <andy.goryachev at oracle.com>
> Subject: [External] : Re: RichTextArea Feedback
>  
> Hi Andy
>  
>> Did I miss anything?? Please let me know. #2
>  
> Also, the RFE regarding ContentChange:
> This is a request to enhance ContentChange with an additional method: getPreviousSegments()
>  
> Currently ContentChange reports only where something has changed.
> Using this one can determine the current state of the document, however
> determining what has actually changed is impossible. So having this
> extra information available would be helpful.
>  
> I think this can easily be done in StyledTextModel where the previous
> segments can be obtained by extracting them from the freshly created
> UndoableChange object when calling fire?ChangeEvent(...)
>  
> Thanks, regards
> Jurgen

From arapte at openjdk.org  Tue Nov  4 11:02:58 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 4 Nov 2025 11:02:58 GMT
Subject: RFR: 8371087: Remove unused dependency on jdk.unsupported from
 javafx.graphics [v2]
In-Reply-To: <TgVzu9TFS8Q1dlo-lUDpYMOzAEb-YvNDfOK3nIDqZ40=.d0cb346e-8f1b-4cf4-9441-5ec8c367097b@github.com>
References: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
 <TgVzu9TFS8Q1dlo-lUDpYMOzAEb-YvNDfOK3nIDqZ40=.d0cb346e-8f1b-4cf4-9441-5ec8c367097b@github.com>
Message-ID: <q1_VdUygCZdNVp3m4zdjiNhg63NHLWKXNTTbPdKxqbg=.808e6ef1-8d39-4d24-a12c-8875f4c8c2e6@github.com>

On Mon, 3 Nov 2025 16:31:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the unused dependency on `jdk.unsupported` from `javafx.graphics` as a followup to [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137), which replaced the use of `sun.misc.Unsafe` with FFM in PR #1814. `sun.misc.Unsafe` was the only use of `jdk.unsupported`, so it can now be removed.
>> 
>> It also removes the no-longer-needed `-XDignore.symbol.file` flag from `build.gradle`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded '-XDignore.symbol.file' option

lgtm

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1957#pullrequestreview-3415738350

From mhanl at openjdk.org  Tue Nov  4 11:02:59 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 4 Nov 2025 11:02:59 GMT
Subject: RFR: 8371087: Remove unused dependency on jdk.unsupported from
 javafx.graphics [v2]
In-Reply-To: <TgVzu9TFS8Q1dlo-lUDpYMOzAEb-YvNDfOK3nIDqZ40=.d0cb346e-8f1b-4cf4-9441-5ec8c367097b@github.com>
References: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
 <TgVzu9TFS8Q1dlo-lUDpYMOzAEb-YvNDfOK3nIDqZ40=.d0cb346e-8f1b-4cf4-9441-5ec8c367097b@github.com>
Message-ID: <bhuDfrVzOtN6hVp6o62E1eeu10cYuVgdreSsE0y9Km0=.3d42aa93-325c-45ba-9d76-e3c5c11de4bf@github.com>

On Mon, 3 Nov 2025 16:31:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the unused dependency on `jdk.unsupported` from `javafx.graphics` as a followup to [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137), which replaced the use of `sun.misc.Unsafe` with FFM in PR #1814. `sun.misc.Unsafe` was the only use of `jdk.unsupported`, so it can now be removed.
>> 
>> It also removes the no-longer-needed `-XDignore.symbol.file` flag from `build.gradle`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded '-XDignore.symbol.file' option

Marked as reviewed by mhanl (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1957#pullrequestreview-3415743833

From mhanl at openjdk.org  Tue Nov  4 11:03:58 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 4 Nov 2025 11:03:58 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1 [v2]
In-Reply-To: <nXmVVf0_DJbmJ5-XTc310SxO7WsAouHaeNYnNWRClh8=.023781b2-feab-4e5a-87ce-6a4b0ea56c74@github.com>
References: <AqYPkdmL8rn6F-gdhFHBoa7qB37H_mOsqC1NxxvaGFM=.7d7c0324-599d-4594-b8e4-1df4ceceef73@github.com>
 <nXmVVf0_DJbmJ5-XTc310SxO7WsAouHaeNYnNWRClh8=.023781b2-feab-4e5a-87ce-6a4b0ea56c74@github.com>
Message-ID: <lz9HaPQXAqdmZfl_gfNZQAekaPXgdnlabqfQ0traf6o=.d943419f-990f-42b4-836d-42ae3f2adb2d@github.com>

On Tue, 4 Nov 2025 01:19:54 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Update boot jdk to 25.0.1, along with gradle update to version 9.1.0.
>> The gradle 9 related deprecation are already addressed with [JDK-8360586](https://bugs.openjdk.org/browse/JDK-8360586)
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   gradle update to 920

Marked as reviewed by mhanl (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1953#pullrequestreview-3415747505

From jdv at openjdk.org  Tue Nov  4 11:37:18 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 4 Nov 2025 11:37:18 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v6]
In-Reply-To: <HzoV0_nTS4wT9sp6sp0GsdHr1MOPcOh-Jv_yx8y4hWA=.67710d5a-0169-4ce4-9c7b-b2b78573b73d@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <HzoV0_nTS4wT9sp6sp0GsdHr1MOPcOh-Jv_yx8y4hWA=.67710d5a-0169-4ce4-9c7b-b2b78573b73d@github.com>
Message-ID: <fjhNGQ35TeDwuHYamSs6zJrnIB3GRvENlA2_p_q1-iw=.e8026d5e-c8cd-4434-ab2f-e74950bc0ab4@github.com>

On Fri, 31 Oct 2025 18:48:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
>> 
>> The impacted areas are:
>> - saving to plain text
>> - copying to plain text
>> - IME
>> 
>> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), and as a property in the `CodeArea`.
>> 
>> NOTE:
>> - some dependency on #1938 , resolved.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get text

Code change looks good to me. I have minor suggestions.
Also played around with demos everything works fine.

modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/StringBuilderStyledOutput.java line 39:

> 37: 
> 38:     public StringBuilderStyledOutput(LineEnding lineEnding) {
> 39:         sb = new StringBuilder(1024);

Its better to name this constant.

modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/util/RichUtils.java line 176:

> 174:         }
> 175:         return switch(v) {
> 176:         case CR -> "\r";

Missing indentation.

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

Marked as reviewed by jdv (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1944#pullrequestreview-3415733643
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2489992597
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2490000411

From arapte at openjdk.org  Tue Nov  4 12:08:21 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 4 Nov 2025 12:08:21 GMT
Subject: [jfx25u] RFR: 8271024: Implement macOS Metal Rendering Pipeline
Message-ID: <OSmg9v23sHHrjY1K6agwdjVPPPW_naKto_j3zR3Wsk0=.63a89426-c1fa-426f-8bb1-fee4a27bbb38@github.com>

Backport metal implementation to jfx25u.
The backport is nearly clean with only one conflict that: The file `modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessView.java` is not present in jfx25u.
No issues observed with build and test.

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

Commit messages:
 - 8271024: Implement macOS Metal Rendering Pipeline

Changes: https://git.openjdk.org/jfx25u/pull/30/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=30&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8271024
  Stats: 12322 lines in 105 files changed: 11457 ins; 709 del; 156 mod
  Patch: https://git.openjdk.org/jfx25u/pull/30.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/30/head:pull/30

PR: https://git.openjdk.org/jfx25u/pull/30

From jurgen at ivoryemr.co.za  Tue Nov  4 12:21:34 2025
From: jurgen at ivoryemr.co.za (Jurgen Doll)
Date: Tue, 4 Nov 2025 14:21:34 +0200
Subject: [External] : Re: RichTextArea Feedback
In-Reply-To: <CY8PR10MB7265ABB119DC58825687913AE5C7A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CY8PR10MB7265ABB119DC58825687913AE5C7A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <FB023CFC-6C01-4B58-B033-B36EB917EE77@getmailspring.com>

Hi Andy

> It is possible to add a Node to the content, but needs a custom model

Yes Node can be added (I've done that successfully with two different
models), but copy/paste and undo are impossible with current API.

> Also, what does it mean to copy a content with a Node, especially an
> interactive one, like a TextField? ?This question cannot be answered
> generally, as it depends on the application requirements, thus the
> custom model.

Agreed. Actually, if I'm not mistaken, it depends on the available
DataFormatHandlers and not on the model itself. The model must just be
able to process all types of StyledSegment, which it currently doesn't.
The suggested API's are essential to accomplish this.

Then the developer must provide a custom DataFormatHandler to handle the
detail of what it means as per the application requirements.

Thanks, regards
Jurgen


On Nov 3 2025, at 8:31 pm, Andy Goryachev <andy.goryachev at oracle.com> wrote:

> Dear Jurgen:
>  
> It is possible to add a Node to the content, but needs a custom model
> (see SimpleViewOnlyStyledModel:488).
>  
> Also, what does it mean to copy a content with a Node, especially an
> interactive one, like a TextField? ?This question cannot be answered
> generally, as it depends on the application requirements, thus the
> custom model.
>  
> Having said that, there might still be a need to provide the necessary
> protected APIs as you suggested. ?I've added a note to https://bugs.openjdk.org/browse/JDK-8365948
>  
> Thanks!
> -andy
>  
>  
> From: Jurgen Doll <jurgen at ivoryemr.co.za>
> Date: Monday, November 3, 2025 at 01:53
> To: Andy Goryachev <andy.goryachev at oracle.com>
> Cc: openjfx-dev <openjfx-dev at openjdk.org>
> Subject: [External] : Re: RichTextArea Feedback
>  
> Hi Andy
>  
> Thanks for posting a summary to the dev list.
>  
> With regards to this point:
>  
>>> As expected though paste and undo/redo don't work due to
>> StyledTextModel's final replace method not handling INLINE_NODE's
>> ?
>> This is correct, and I think it might be better to leave up to the
>> (custom) model. ?The reason for it is it should be up to the
>> application/custom model to decide how to deal with the embedded
>> nodes, especially interactive ones.
>  
> I understand your rational, however having tried it myself (with two
> different models) I can claim with a high degree of confidence that it's
> currently impossible. Unless I've missed something, a developer
> extending any form of StyledTextModel cannot accomplish this.
>  
> The fix if I'm not mistaken is straightforward. What is required is
> the addition of something like the following method to StyledTextModel:
>  
> protected abstract int insertNodeSegment(int index, int offset,
> Supplier<Node> sup, StyleAttributeMap? attrs?);
>  
> and that the method:
>  
> public final TextPos replace(..., StyledInput input)
>  
> then handles INLINE_NODE and appropriately invokes this added
> insertNodeSegment method.
>  
> All your current sub-classes of StyledTextModel can then just implement
> No-Op implementations of insertNodeSegment. Of course it would be
> awesome if RichTextModel could handle inline nodes out of the box.
>  
> I hope this meets with your approval and if I've missed something please
> let me know.
>  
> Thanks, regards
> Jurgen

From nlisker at openjdk.org  Tue Nov  4 12:33:52 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 4 Nov 2025 12:33:52 GMT
Subject: RFR: 8240844: Remove dependency on java.desktop from javafx.base
In-Reply-To: <s4sTfLR0m9Ps-C00W_TqTRsM4a0szVpRO7T_FMPOOpo=.56315c2c-9b93-457d-b712-2d9baed984b3@github.com>
References: <s4sTfLR0m9Ps-C00W_TqTRsM4a0szVpRO7T_FMPOOpo=.56315c2c-9b93-457d-b712-2d9baed984b3@github.com>
Message-ID: <TrtmM5Hcjxb0_w6UYADDNRXQd2XZMLCxDJcWQTDfdC0=.a98156e0-4385-4d96-b1a8-dd5ff031fffa@github.com>

On Sun, 2 Nov 2025 19:40:04 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR makes the `java.desktop` requirement static for `javafx.base` and `javafx.graphics`.
> With this changes, a JavaFX app without `Swing` and the `WebView` will be much smaller (results below).
> 
> Consequences:
> - `java.desktop` need to be loaded (required) when using anything from the `javafx.beans.property.adapter` package (the property classes from `java.beans.XXX` are used here)
> - `java.desktop` need to be loaded (required) when using printing, that is e.g. `PrinterJob.createPrinterJob().showPrintDialog(..)`
> 
> Results:
> - Removing `java.desktop` gives a huge size boost! I benchmarked the following values when using `jlink` with: [`zip-6`, `--no-man-pages`, `--no-header-files`, `--strip-debug`, `--strip-java-debug-attributes`] to build an own runtime
> 
> Tried on a real application (here called `myapp`) with JDK-25 on Windows 11 that has dependencies to: [`javafx-base`,  `javafx-graphics`, `javafx-fxml`, `javafx-controls`]
> 
> ---
> 
> `master`
> 
> `70.009.288 Bytes`
> 
> 
> myapp
> java.base at 25
> java.datatransfer at 25
> java.desktop at 25
> java.prefs at 25
> java.scripting at 25
> java.xml at 25
> javafx.base at 26-internal
> javafx.controls at 26-internal
> javafx.fxml at 26-internal
> javafx.graphics at 26-internal
> jdk.localedata at 25
> jdk.unsupported at 25
> 
> 
> -------------------------------------
> 
> `This PR`
> 
> `57.266.538 Bytes`
> 
> 
> myapp
> java.base at 25
> java.scripting at 25
> java.xml at 25
> javafx.base at 26-internal
> javafx.controls at 26-internal
> javafx.fxml at 26-internal
> javafx.graphics at 26-internal
> jdk.localedata at 25
> jdk.unsupported at 25
> 
> 
> ---
> 
> `This PR` + https://github.com/openjdk/jfx/pull/1957
> 
> `57.249.459 Bytes`
> 
> 
> myapp
> java.base at 25
> java.scripting at 25
> java.xml at 25
> javafx.base at 26-internal
> javafx.controls at 26-internal
> javafx.fxml at 26-internal
> javafx.graphics at 26-internal
> jdk.localedata at 25
> 
> 
> ---
> 
> So we save around 13MB. If building a native package, e.g. an `.msi` installer, this will be even higher.
> 
> This change however probably need some discussion, if we want to go that direction + add a note in the release notes, that if one of the two things mentioned above are needed, an requirement to `java.desktop` is needed (in case of a modular project).

There was a discussion on this on the mailing list: https://mail.openjdk.org/pipermail/openjfx-dev/2023-November/043731.html.

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

PR Comment: https://git.openjdk.org/jfx/pull/1958#issuecomment-3485752164

From sykora at openjdk.org  Tue Nov  4 13:04:03 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Tue, 4 Nov 2025 13:04:03 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1 [v2]
In-Reply-To: <nXmVVf0_DJbmJ5-XTc310SxO7WsAouHaeNYnNWRClh8=.023781b2-feab-4e5a-87ce-6a4b0ea56c74@github.com>
References: <AqYPkdmL8rn6F-gdhFHBoa7qB37H_mOsqC1NxxvaGFM=.7d7c0324-599d-4594-b8e4-1df4ceceef73@github.com>
 <nXmVVf0_DJbmJ5-XTc310SxO7WsAouHaeNYnNWRClh8=.023781b2-feab-4e5a-87ce-6a4b0ea56c74@github.com>
Message-ID: <SUhx6g86r14zWC4ezprbUFwIRpy9_POBz6q8hY7tA-M=.4be1bf67-290e-4429-960c-2332aeb753b1@github.com>

On Tue, 4 Nov 2025 01:19:54 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Update boot jdk to 25.0.1, along with gradle update to version 9.1.0.
>> The gradle 9 related deprecation are already addressed with [JDK-8360586](https://bugs.openjdk.org/browse/JDK-8360586)
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   gradle update to 920

I've ran the builds again and all worked fine with gradle 9.2.0.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1953#pullrequestreview-3416351458

From kcr at openjdk.org  Tue Nov  4 13:11:10 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 13:11:10 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1 [v2]
In-Reply-To: <nXmVVf0_DJbmJ5-XTc310SxO7WsAouHaeNYnNWRClh8=.023781b2-feab-4e5a-87ce-6a4b0ea56c74@github.com>
References: <AqYPkdmL8rn6F-gdhFHBoa7qB37H_mOsqC1NxxvaGFM=.7d7c0324-599d-4594-b8e4-1df4ceceef73@github.com>
 <nXmVVf0_DJbmJ5-XTc310SxO7WsAouHaeNYnNWRClh8=.023781b2-feab-4e5a-87ce-6a4b0ea56c74@github.com>
Message-ID: <QBsH7nddC8-AuKu4BPuZpDcB_9V2g5TpNVnOdXkWo04=.02fd8823-902d-434a-9623-05c85c5e9e9b@github.com>

On Tue, 4 Nov 2025 01:19:54 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Update boot jdk to 25.0.1, along with gradle update to version 9.1.0.
>> The gradle 9 related deprecation are already addressed with [JDK-8360586](https://bugs.openjdk.org/browse/JDK-8360586)
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   gradle update to 920

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1953#pullrequestreview-3416390129

From kcr at openjdk.org  Tue Nov  4 13:24:14 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 13:24:14 GMT
Subject: [jfx25u] RFR: 8271024: Implement macOS Metal Rendering Pipeline
In-Reply-To: <OSmg9v23sHHrjY1K6agwdjVPPPW_naKto_j3zR3Wsk0=.63a89426-c1fa-426f-8bb1-fee4a27bbb38@github.com>
References: <OSmg9v23sHHrjY1K6agwdjVPPPW_naKto_j3zR3Wsk0=.63a89426-c1fa-426f-8bb1-fee4a27bbb38@github.com>
Message-ID: <FvrQuVaoXP5k6ZBaCInSwiwQFJiO3m902egXhrHtLQI=.67a12c9b-cd04-4935-8b31-ddb568bc0354@github.com>

On Tue, 4 Nov 2025 12:01:26 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Backport metal implementation to jfx25u.
> The backport is nearly clean with only one conflict that: The file `modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessView.java` is not present in jfx25u.
> No issues observed with build and test.

LGTM. I confirm that the patch is clean except for the file that isn't present in jfx25u. I did a quick build / test and all looks good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx25u/pull/30#pullrequestreview-3416445089

From jvos at openjdk.org  Tue Nov  4 13:52:54 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 4 Nov 2025 13:52:54 GMT
Subject: [jfx25u] RFR: 8271024: Implement macOS Metal Rendering Pipeline
In-Reply-To: <OSmg9v23sHHrjY1K6agwdjVPPPW_naKto_j3zR3Wsk0=.63a89426-c1fa-426f-8bb1-fee4a27bbb38@github.com>
References: <OSmg9v23sHHrjY1K6agwdjVPPPW_naKto_j3zR3Wsk0=.63a89426-c1fa-426f-8bb1-fee4a27bbb38@github.com>
Message-ID: <k43tf_OdXsYCwwLo3Dp-VluLDtAlWwVE3Ui-uRVzMJQ=.93785040-75c7-4c72-8c75-f890cc40174c@github.com>

On Tue, 4 Nov 2025 12:01:26 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Backport metal implementation to jfx25u.
> The backport is nearly clean with only one conflict that: The file `modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessView.java` is not present in jfx25u.
> No issues observed with build and test.

I believe this is indeed a good thing to backport. As a consequence, it will need to be maintained by LTS providers during the timeline of 25 LTS, but I assume this is not going to pose problems.

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

PR Comment: https://git.openjdk.org/jfx25u/pull/30#issuecomment-3486100812

From kcr at openjdk.org  Tue Nov  4 14:04:32 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 14:04:32 GMT
Subject: [jfx25u] RFR: 8271024: Implement macOS Metal Rendering Pipeline
In-Reply-To: <OSmg9v23sHHrjY1K6agwdjVPPPW_naKto_j3zR3Wsk0=.63a89426-c1fa-426f-8bb1-fee4a27bbb38@github.com>
References: <OSmg9v23sHHrjY1K6agwdjVPPPW_naKto_j3zR3Wsk0=.63a89426-c1fa-426f-8bb1-fee4a27bbb38@github.com>
Message-ID: <9ERMdiqQUFT-ByLrAutot8OfS1DOFQ6rre8LJl8rXJo=.253000e1-83b8-435d-9815-4f76d23df7a4@github.com>

On Tue, 4 Nov 2025 12:01:26 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Backport metal implementation to jfx25u.
> The backport is nearly clean with only one conflict that: The file `modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessView.java` is not present in jfx25u.
> No issues observed with build and test.

Yes. I expect metal will be off by default for the lifetime of 25u, but will be there if Apple ends up removing OpenGL sooner than expected.

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

PR Comment: https://git.openjdk.org/jfx25u/pull/30#issuecomment-3486159264

From arapte at openjdk.org  Tue Nov  4 14:23:29 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 4 Nov 2025 14:23:29 GMT
Subject: [jfx25u] Integrated: 8271024: Implement macOS Metal Rendering Pipeline
In-Reply-To: <OSmg9v23sHHrjY1K6agwdjVPPPW_naKto_j3zR3Wsk0=.63a89426-c1fa-426f-8bb1-fee4a27bbb38@github.com>
References: <OSmg9v23sHHrjY1K6agwdjVPPPW_naKto_j3zR3Wsk0=.63a89426-c1fa-426f-8bb1-fee4a27bbb38@github.com>
Message-ID: <yGy6pxnwUMTtcLHENZDSS66Ff6iiTisdXx-AoU2r9Is=.185316f7-1dea-402d-aaad-0b408335fa8b@github.com>

On Tue, 4 Nov 2025 12:01:26 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Backport metal implementation to jfx25u.
> The backport is nearly clean with only one conflict that: The file `modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessView.java` is not present in jfx25u.
> No issues observed with build and test.

This pull request has now been integrated.

Changeset: 29c74efe
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/29c74efe2778dfadd95ef79c5f217f834d5e835d
Stats:     12322 lines in 105 files changed: 11457 ins; 709 del; 156 mod

8271024: Implement macOS Metal Rendering Pipeline

Reviewed-by: kcr
Backport-of: f0312b0e3d384d5e1cfe905408983c66a61dd2bf

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

PR: https://git.openjdk.org/jfx25u/pull/30

From arapte at openjdk.org  Tue Nov  4 14:38:39 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 4 Nov 2025 14:38:39 GMT
Subject: [jfx25u] RFR: 8350479: SW pipeline should use default pipeline in
 Glass
Message-ID: <TZ4SlCIVt3aW6sETNbRrmxaIGJ5e3d0QMhlXH25KCqI=.b7714eed-4a8d-4087-8e73-d9c21d6aee93@github.com>

This is an important follow-up metal related change, to use Metal pipeline for bliting the frame buffer with SW pipeline.

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

Commit messages:
 - Backport f8f466f9038b02b1e100cccf25a9ba58e7a06157

Changes: https://git.openjdk.org/jfx25u/pull/31/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=31&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350479
  Stats: 88 lines in 9 files changed: 58 ins; 16 del; 14 mod
  Patch: https://git.openjdk.org/jfx25u/pull/31.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/31/head:pull/31

PR: https://git.openjdk.org/jfx25u/pull/31

From kcr at openjdk.org  Tue Nov  4 14:30:28 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 14:30:28 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v4]
In-Reply-To: <2dRJ3IhppfvY0ZhqCqtM_qjSqQD-lKh-TG3w_ZqtEFw=.3c040e21-0e1c-48d8-8129-f5a70a6eb2d6@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <2dRJ3IhppfvY0ZhqCqtM_qjSqQD-lKh-TG3w_ZqtEFw=.3c040e21-0e1c-48d8-8129-f5a70a6eb2d6@github.com>
Message-ID: <fu2gMRmN16CoshTdv2wYr6lmWwNFkFo5dFx0LRFCyvw=.264158d6-eb1d-46e9-9c91-aa9814442371@github.com>

On Tue, 4 Nov 2025 08:04:51 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments - ES2 check + extra code comments

The updates look good with one question about whether to update `MTLTexture` as well (see inline).

We still need to do one of two things relating to the JBS bug management:

1. If this solves [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629), close [JDK-8352209](https://bugs.openjdk.org/browse/JDK-8352209) as a duplicate and change the title of this PR to `8368629: Texture.update sometimes invoked for a disposed Texture`
2. Otherwise, Change the title of this PR and [JDK-8352209](https://bugs.openjdk.org/browse/JDK-8352209) to describe the more general problem being solved rather than a D3D-specific problem.

@arapte Have you evaluated whether this solves [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629)?

modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java line 784:

> 782:             return;
> 783:         }
> 784: 

I see that you applied this to both D3D and ES2. The corresponding MTLTexture also has an `update(MediaFrame frame, ...)` method which does not have this check. For consistency, it might be worth adding it there, too.

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

PR Review: https://git.openjdk.org/jfx/pull/1951#pullrequestreview-3416733053
PR Review Comment: https://git.openjdk.org/jfx/pull/1951#discussion_r2490708044

From kcr at openjdk.org  Tue Nov  4 14:38:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 14:38:39 GMT
Subject: [jfx25u] RFR: 8350479: SW pipeline should use default pipeline in
 Glass
In-Reply-To: <TZ4SlCIVt3aW6sETNbRrmxaIGJ5e3d0QMhlXH25KCqI=.b7714eed-4a8d-4087-8e73-d9c21d6aee93@github.com>
References: <TZ4SlCIVt3aW6sETNbRrmxaIGJ5e3d0QMhlXH25KCqI=.b7714eed-4a8d-4087-8e73-d9c21d6aee93@github.com>
Message-ID: <SJZsSnD6fG9uj95LEx8XmVJEpoNig606z85-sN4z1BA=.bb34d4ea-3cba-417c-b01b-59ea8dd8f8a4@github.com>

On Tue, 4 Nov 2025 14:25:52 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> This is an important follow-up metal related change, to use Metal pipeline for bliting the frame buffer with SW pipeline.

Slight clarification: this will use the _default_ pipeline for blitting when using the SW pipeline, which is still ES2 for now. It allows for using the MTL pipeline if that is ever set as default. It also cleans up the pipeline selection logic so is an important follow-on fix to take.

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

PR Comment: https://git.openjdk.org/jfx25u/pull/31#issuecomment-3486311813

From kcr at openjdk.org  Tue Nov  4 14:41:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 14:41:43 GMT
Subject: Integrated: 8371087: Remove unused dependency on jdk.unsupported from
 javafx.graphics
In-Reply-To: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
References: <BWoCd4opznjCMyHuA6Llef2nBY47qNyRYlQADTokres=.93b3538f-2f6f-4f06-9737-fe0d3f6cfb2b@github.com>
Message-ID: <A1pZA4wX4x_2qHWuy9elEn-IpLlJlWl3hVaWZPJwMzI=.f9a014f3-74bc-4202-aaad-8bada5e094fd@github.com>

On Sat, 1 Nov 2025 15:47:00 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the unused dependency on `jdk.unsupported` from `javafx.graphics` as a followup to [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137), which replaced the use of `sun.misc.Unsafe` with FFM in PR #1814. `sun.misc.Unsafe` was the only use of `jdk.unsupported`, so it can now be removed.
> 
> It also removes the no-longer-needed `-XDignore.symbol.file` flag from `build.gradle`.

This pull request has now been integrated.

Changeset: a4e54513
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/a4e5451373beed93942e0bf2b6c8b81d3e6ad66d
Stats:     4 lines in 2 files changed: 0 ins; 2 del; 2 mod

8371087: Remove unused dependency on jdk.unsupported from javafx.graphics
8179462: Remove obsolete -XDignore.symbol.file flag from build

Reviewed-by: mhanl, arapte

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

PR: https://git.openjdk.org/jfx/pull/1957

From lkostyra at openjdk.org  Tue Nov  4 14:45:07 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 4 Nov 2025 14:45:07 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v4]
In-Reply-To: <fu2gMRmN16CoshTdv2wYr6lmWwNFkFo5dFx0LRFCyvw=.264158d6-eb1d-46e9-9c91-aa9814442371@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <2dRJ3IhppfvY0ZhqCqtM_qjSqQD-lKh-TG3w_ZqtEFw=.3c040e21-0e1c-48d8-8129-f5a70a6eb2d6@github.com>
 <fu2gMRmN16CoshTdv2wYr6lmWwNFkFo5dFx0LRFCyvw=.264158d6-eb1d-46e9-9c91-aa9814442371@github.com>
Message-ID: <DDGdxMh8pbAWMvaxJ5JGmCsdCHVavEfCEVke2h7Z5CA=.47f1f88e-1fc2-4647-bd4b-634cc3c22007@github.com>

On Tue, 4 Nov 2025 14:27:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> We still need to do one of two things relating to the JBS bug management:
> 
>     1. If this solves [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629), close [JDK-8352209](https://bugs.openjdk.org/browse/JDK-8352209) as a duplicate and change the title of this PR to `8368629: Texture.update sometimes invoked for a disposed Texture`
> 
>     2. Otherwise, Change the title of this PR and [JDK-8352209](https://bugs.openjdk.org/browse/JDK-8352209) to describe the more general problem being solved rather than a D3D-specific problem.

I am personally more leaning towards option 1, I will make those changes now

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3486341053

From lkostyra at openjdk.org  Tue Nov  4 14:49:56 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 4 Nov 2025 14:49:56 GMT
Subject: RFR: 8368629: Texture.update sometimes invoked for a disposed
 Texture [v5]
In-Reply-To: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
Message-ID: <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>

> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
> 
> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
> 
> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.

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

  Review comments - MTLTexture: add isValid() check to update(MediaFrame)

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1951/files
  - new: https://git.openjdk.org/jfx/pull/1951/files/683b6591..10cc7fd7

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

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

PR: https://git.openjdk.org/jfx/pull/1951

From arapte at openjdk.org  Tue Nov  4 15:47:59 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 4 Nov 2025 15:47:59 GMT
Subject: [jfx25u] Integrated: 8350479: SW pipeline should use default pipeline
 in Glass
In-Reply-To: <TZ4SlCIVt3aW6sETNbRrmxaIGJ5e3d0QMhlXH25KCqI=.b7714eed-4a8d-4087-8e73-d9c21d6aee93@github.com>
References: <TZ4SlCIVt3aW6sETNbRrmxaIGJ5e3d0QMhlXH25KCqI=.b7714eed-4a8d-4087-8e73-d9c21d6aee93@github.com>
Message-ID: <fmniSXO_wbKgjYCI_-u26JFnBaIVdduZOqgMjnvQwX8=.b539cb0d-7a23-4237-9ccc-ab82fbae3cda@github.com>

On Tue, 4 Nov 2025 14:25:52 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> This is an important follow-up metal related change, to use Metal pipeline for bliting the frame buffer with SW pipeline.

This pull request has now been integrated.

Changeset: 8b26175b
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/8b26175b7b7dd82cbc5a2dafdbfdae07834dd744
Stats:     88 lines in 9 files changed: 58 ins; 16 del; 14 mod

8350479: SW pipeline should use default pipeline in Glass

Backport-of: f8f466f9038b02b1e100cccf25a9ba58e7a06157

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

PR: https://git.openjdk.org/jfx25u/pull/31

From arapte at openjdk.org  Tue Nov  4 16:17:59 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 4 Nov 2025 16:17:59 GMT
Subject: [jfx25u] RFR: 8368631: Avoid updating disposed MTLTexture
Message-ID: <q07YhuGT3dqnYArePYHyiAi10iWg5EFknbDeDJCq4cY=.31bd754e-40e0-4be6-844a-cd05d7773a69@github.com>

This is a metal specific safe change. This fixes a crash issue that occurs when a Texture is updated after disposal.

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

Commit messages:
 - Backport c480b4622e7a1dc4e1987649eedf972103380b61

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

PR: https://git.openjdk.org/jfx25u/pull/32

From arapte at openjdk.org  Tue Nov  4 16:53:48 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 4 Nov 2025 16:53:48 GMT
Subject: [jfx25u] RFR: 8368879: Intermittent crash on exit when disposing
 MTLRTTextureData
Message-ID: <gd885K9sziUo25716l_r6n5k_4FwhzZBDC-GcizTeNE=.ad144b0e-42bc-4c6f-944c-50b7a412dc93@github.com>

This is metal specific change that fixes Intermittent crash on exit in MTLRTTextureData::dispose() during toolkit shutdown

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

Commit messages:
 - Backport 1b16ebaa8c583ce6094ad5717969967b8c9f2c9e

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

PR: https://git.openjdk.org/jfx25u/pull/33

From kcr at openjdk.org  Tue Nov  4 16:55:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 16:55:39 GMT
Subject: RFR: 8371128: NullPointerException occurs due to double cleanup of
 SwingNode
In-Reply-To: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
References: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
Message-ID: <1JVE6qTzI01I7PdvFjacJI_bWWg-9r9QnqZjcBQshLE=.13377ec7-53a1-45fc-b557-7f1915be0665@github.com>

On Tue, 4 Nov 2025 09:06:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is seen that when we close the SwingNode window while we have registered a WINDOW_HIDDEN listener, it will cause a NPE 
> This is because WINDOW_HIDDEN listener called `SwingNode.overrideNativeWindowHandle` to provide a native FX window handle to AWT/Swing via JNI code, which gives provision to AWT/Swing code in sun/swing/JLightweightFrame.java#overrideNativeWindowHandle to handle the window closing
> 
> https://github.com/openjdk/jdk/blob/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/src/java.desktop/share/classes/sun/swing/JLightweightFrame.java#L527-L534
> 
> But if window is closed, then the node is removed from scene and `SwingNode.disposeLwFrame` is called which nulls "lwFrame" which is the handle for JLightweightFrame AWT frame, so when JNI code 
> https://github.com/openjdk/jfx/blob/c77c2335856a967907aaacc9546f44943c069add/modules/javafx.graphics/src/main/native-prism/SwingInterop.c#L47
> 
> tries to call JLightweightFrame, it crashes.
> Fix is made to check for `lwFrame `before `overrideNativeWindowHandle ` is called inside `SwingNodeHelper.runOnEDT`. 
> This is common practice employed inside `SwingNodeHelper.runOnEDT` to check for lwFrame to be not null

LGTM. The fix is safe and obvious. I left one minor comment on the test and will reapprove if you decide to make any changes.

This fix is simple enough that a single reviewer should suffice. Wait until it has been out for review for at least 24 hours before integrating.

tests/manual/swing/JavaSwingNodeCleanupBug.java line 57:

> 55:         passButton.setOnAction(e -> this.quit());
> 56:         failButton.setOnAction(e -> {
> 57:             this.quit();

Minor: Maybe throw an exception or print an error message here?

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1960#pullrequestreview-3417573997
PR Review Comment: https://git.openjdk.org/jfx/pull/1960#discussion_r2491289190

From arapte at openjdk.org  Tue Nov  4 17:03:46 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 4 Nov 2025 17:03:46 GMT
Subject: [jfx25u] Integrated: 8368631: Avoid updating disposed MTLTexture
In-Reply-To: <q07YhuGT3dqnYArePYHyiAi10iWg5EFknbDeDJCq4cY=.31bd754e-40e0-4be6-844a-cd05d7773a69@github.com>
References: <q07YhuGT3dqnYArePYHyiAi10iWg5EFknbDeDJCq4cY=.31bd754e-40e0-4be6-844a-cd05d7773a69@github.com>
Message-ID: <HTGIAgIKtusfLAeG6jUFsOpLX-zLJsa5lm3OlVFRBgE=.a9ef46de-1a4a-4b41-8b64-a9e0d9b84103@github.com>

On Tue, 4 Nov 2025 16:11:14 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> This is a metal specific safe change. This fixes a crash issue that occurs when a Texture is updated after disposal.

This pull request has now been integrated.

Changeset: b116dc0d
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/b116dc0d3910027d4b4e6f0bd2d43aeca7a9a799
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8368631: Avoid updating disposed MTLTexture

Backport-of: c480b4622e7a1dc4e1987649eedf972103380b61

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

PR: https://git.openjdk.org/jfx25u/pull/32

From arapte at openjdk.org  Tue Nov  4 17:08:07 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 4 Nov 2025 17:08:07 GMT
Subject: [jfx25u] Integrated: 8368879: Intermittent crash on exit when
 disposing MTLRTTextureData
In-Reply-To: <gd885K9sziUo25716l_r6n5k_4FwhzZBDC-GcizTeNE=.ad144b0e-42bc-4c6f-944c-50b7a412dc93@github.com>
References: <gd885K9sziUo25716l_r6n5k_4FwhzZBDC-GcizTeNE=.ad144b0e-42bc-4c6f-944c-50b7a412dc93@github.com>
Message-ID: <zSaTamXs8WoUmc4zg5DoW-Iswo590-G_Bzv_FUIH0c4=.57ca4261-6056-4631-bd74-393b923be2f9@github.com>

On Tue, 4 Nov 2025 16:48:02 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> This is metal specific change that fixes Intermittent crash on exit in MTLRTTextureData::dispose() during toolkit shutdown

This pull request has now been integrated.

Changeset: e7d1fdf3
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/e7d1fdf384cd30aa2e4ec2dad3ce661e5ec2e8f1
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8368879: Intermittent crash on exit when disposing MTLRTTextureData

Backport-of: 1b16ebaa8c583ce6094ad5717969967b8c9f2c9e

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

PR: https://git.openjdk.org/jfx25u/pull/33

From psadhukhan at openjdk.org  Tue Nov  4 17:13:25 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Nov 2025 17:13:25 GMT
Subject: RFR: 8371128: NullPointerException occurs due to double cleanup of
 SwingNode [v2]
In-Reply-To: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
References: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
Message-ID: <h8fUjVkYPIOgvlMYj3H1_F6gMgP_Vsak2g4P1ndb9sE=.631b9529-17f8-4a3a-ac6a-037df3374a60@github.com>

> It is seen that when we close the SwingNode window while we have registered a WINDOW_HIDDEN listener, it will cause a NPE 
> This is because WINDOW_HIDDEN listener called `SwingNode.overrideNativeWindowHandle` to provide a native FX window handle to AWT/Swing via JNI code, which gives provision to AWT/Swing code in sun/swing/JLightweightFrame.java#overrideNativeWindowHandle to handle the window closing
> 
> https://github.com/openjdk/jdk/blob/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/src/java.desktop/share/classes/sun/swing/JLightweightFrame.java#L527-L534
> 
> But if window is closed, then the node is removed from scene and `SwingNode.disposeLwFrame` is called which nulls "lwFrame" which is the handle for JLightweightFrame AWT frame, so when JNI code 
> https://github.com/openjdk/jfx/blob/c77c2335856a967907aaacc9546f44943c069add/modules/javafx.graphics/src/main/native-prism/SwingInterop.c#L47
> 
> tries to call JLightweightFrame, it crashes.
> Fix is made to check for `lwFrame `before `overrideNativeWindowHandle ` is called inside `SwingNodeHelper.runOnEDT`. 
> This is common practice employed inside `SwingNodeHelper.runOnEDT` to check for lwFrame to be not null

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

  Test message

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1960/files
  - new: https://git.openjdk.org/jfx/pull/1960/files/1ff1099f..bc245727

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

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

PR: https://git.openjdk.org/jfx/pull/1960

From kcr at openjdk.org  Tue Nov  4 17:14:08 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 17:14:08 GMT
Subject: RFR: 8368629: Texture.update sometimes invoked for a disposed
 Texture [v5]
In-Reply-To: <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>
Message-ID: <OssevNGhCg4cP5k-Q7BoBPK7JCqrAT88SHl0Pcnqd58=.24e78f8f-bef5-40ec-ac64-280d7ae63c09@github.com>

On Tue, 4 Nov 2025 14:49:56 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments - MTLTexture: add isValid() check to update(MediaFrame)

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1951#pullrequestreview-3417700856

From psadhukhan at openjdk.org  Tue Nov  4 17:13:28 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Nov 2025 17:13:28 GMT
Subject: RFR: 8371128: NullPointerException occurs due to double cleanup of
 SwingNode [v2]
In-Reply-To: <1JVE6qTzI01I7PdvFjacJI_bWWg-9r9QnqZjcBQshLE=.13377ec7-53a1-45fc-b557-7f1915be0665@github.com>
References: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
 <1JVE6qTzI01I7PdvFjacJI_bWWg-9r9QnqZjcBQshLE=.13377ec7-53a1-45fc-b557-7f1915be0665@github.com>
Message-ID: <F_x5XQkDljYf3vDl7-61WZNAJ528JyEeV4TojN5F66s=.377d70b4-f9f0-4325-a807-5a512ae20411@github.com>

On Tue, 4 Nov 2025 16:50:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test message
>
> tests/manual/swing/JavaSwingNodeCleanupBug.java line 57:
> 
>> 55:         passButton.setOnAction(e -> this.quit());
>> 56:         failButton.setOnAction(e -> {
>> 57:             this.quit();
> 
> Minor: Maybe throw an exception or print an error message here?

We already have an NPE so guess it will be better to have a message than another exception...Updated

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1960#discussion_r2491369990

From kcr at openjdk.org  Tue Nov  4 17:21:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 17:21:03 GMT
Subject: RFR: 8371128: NullPointerException occurs due to double cleanup of
 SwingNode [v2]
In-Reply-To: <h8fUjVkYPIOgvlMYj3H1_F6gMgP_Vsak2g4P1ndb9sE=.631b9529-17f8-4a3a-ac6a-037df3374a60@github.com>
References: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
 <h8fUjVkYPIOgvlMYj3H1_F6gMgP_Vsak2g4P1ndb9sE=.631b9529-17f8-4a3a-ac6a-037df3374a60@github.com>
Message-ID: <29S5jGKQGQGJtATwisrTYkx-JooRLsoDVhbphKpNGiI=.c46c9d80-c970-440e-bf17-d2fb528d194c@github.com>

On Tue, 4 Nov 2025 17:13:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It is seen that when we close the SwingNode window while we have registered a WINDOW_HIDDEN listener, it will cause a NPE 
>> This is because WINDOW_HIDDEN listener called `SwingNode.overrideNativeWindowHandle` to provide a native FX window handle to AWT/Swing via JNI code, which gives provision to AWT/Swing code in sun/swing/JLightweightFrame.java#overrideNativeWindowHandle to handle the window closing
>> 
>> https://github.com/openjdk/jdk/blob/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/src/java.desktop/share/classes/sun/swing/JLightweightFrame.java#L527-L534
>> 
>> But if window is closed, then the node is removed from scene and `SwingNode.disposeLwFrame` is called which nulls "lwFrame" which is the handle for JLightweightFrame AWT frame, so when JNI code 
>> https://github.com/openjdk/jfx/blob/c77c2335856a967907aaacc9546f44943c069add/modules/javafx.graphics/src/main/native-prism/SwingInterop.c#L47
>> 
>> tries to call JLightweightFrame, it crashes.
>> Fix is made to check for `lwFrame `before `overrideNativeWindowHandle ` is called inside `SwingNodeHelper.runOnEDT`. 
>> This is common practice employed inside `SwingNodeHelper.runOnEDT` to check for lwFrame to be not null
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test message

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1960#pullrequestreview-3417735725

From angorya at openjdk.org  Tue Nov  4 17:25:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Nov 2025 17:25:59 GMT
Subject: RFR: 8371128: NullPointerException occurs due to double cleanup of
 SwingNode [v2]
In-Reply-To: <h8fUjVkYPIOgvlMYj3H1_F6gMgP_Vsak2g4P1ndb9sE=.631b9529-17f8-4a3a-ac6a-037df3374a60@github.com>
References: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
 <h8fUjVkYPIOgvlMYj3H1_F6gMgP_Vsak2g4P1ndb9sE=.631b9529-17f8-4a3a-ac6a-037df3374a60@github.com>
Message-ID: <tTcG73QheIC7iQ4XsbditA5LIR9C_gZCUWAOaT14y0M=.02f275f8-0a37-457a-9125-5099f5f7a247@github.com>

On Tue, 4 Nov 2025 17:13:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It is seen that when we close the SwingNode window while we have registered a WINDOW_HIDDEN listener, it will cause a NPE 
>> This is because WINDOW_HIDDEN listener called `SwingNode.overrideNativeWindowHandle` to provide a native FX window handle to AWT/Swing via JNI code, which gives provision to AWT/Swing code in sun/swing/JLightweightFrame.java#overrideNativeWindowHandle to handle the window closing
>> 
>> https://github.com/openjdk/jdk/blob/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/src/java.desktop/share/classes/sun/swing/JLightweightFrame.java#L527-L534
>> 
>> But if window is closed, then the node is removed from scene and `SwingNode.disposeLwFrame` is called which nulls "lwFrame" which is the handle for JLightweightFrame AWT frame, so when JNI code 
>> https://github.com/openjdk/jfx/blob/c77c2335856a967907aaacc9546f44943c069add/modules/javafx.graphics/src/main/native-prism/SwingInterop.c#L47
>> 
>> tries to call JLightweightFrame, it crashes.
>> Fix is made to check for `lwFrame `before `overrideNativeWindowHandle ` is called inside `SwingNodeHelper.runOnEDT`. 
>> This is common practice employed inside `SwingNodeHelper.runOnEDT` to check for lwFrame to be not null
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test message

modules/javafx.swing/src/main/java/javafx/embed/swing/SwingNode.java line 283:

> 281:                     SwingNodeHelper.runOnEDT(() -> {
> 282:                         if (lwFrame != null) {
> 283:                             swNodeIOP.overrideNativeWindowHandle(lwFrame, 0L,

question: is it possible to have `lwFrame` set to `null` between L282 and L283?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1960#discussion_r2491426546

From arapte at openjdk.org  Tue Nov  4 17:29:00 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 4 Nov 2025 17:29:00 GMT
Subject: [jfx25u] RFR: 8367306: HeaderButtonOverlayTest fails to compile with
 TEST_SDK_PATH
Message-ID: <prOHtnwtXxSeai3Nt3UUFHjLIe1u2irBwFlsM-FA1kI=.657bfd44-4b56-465b-bcd7-409c45a523f0@github.com>

This is a test only fix. 
When using `-PTEST_SDK_PATH=<path>` and `-PTEST_ONLY=true`, the test `HeaderButtonOverlayTest` fails to compile with error: package com.sun.glass.events is not visible.
It would be good to backport this fix so that test passes with `-PTEST_SDK_PATH=<path>`

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

Commit messages:
 - Backport 3e376e66a3510f8dee7abb52344961caee1d114a

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

PR: https://git.openjdk.org/jfx25u/pull/34

From angorya at openjdk.org  Tue Nov  4 17:33:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Nov 2025 17:33:58 GMT
Subject: RFR: 8371128: NullPointerException occurs due to double cleanup of
 SwingNode [v2]
In-Reply-To: <tTcG73QheIC7iQ4XsbditA5LIR9C_gZCUWAOaT14y0M=.02f275f8-0a37-457a-9125-5099f5f7a247@github.com>
References: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
 <h8fUjVkYPIOgvlMYj3H1_F6gMgP_Vsak2g4P1ndb9sE=.631b9529-17f8-4a3a-ac6a-037df3374a60@github.com>
 <tTcG73QheIC7iQ4XsbditA5LIR9C_gZCUWAOaT14y0M=.02f275f8-0a37-457a-9125-5099f5f7a247@github.com>
Message-ID: <tUMzPRgd89uQADSj_vcU480sCeXmxFShLoFl0wINX2M=.decba1f2-8693-495d-aa30-01aea4f87430@github.com>

On Tue, 4 Nov 2025 17:23:40 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test message
>
> modules/javafx.swing/src/main/java/javafx/embed/swing/SwingNode.java line 283:
> 
>> 281:                     SwingNodeHelper.runOnEDT(() -> {
>> 282:                         if (lwFrame != null) {
>> 283:                             swNodeIOP.overrideNativeWindowHandle(lwFrame, 0L,
> 
> question: is it possible to have `lwFrame` set to `null` between L282 and L283?

seems like being set in the EDT always

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1960#discussion_r2491449372

From angorya at openjdk.org  Tue Nov  4 17:33:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Nov 2025 17:33:59 GMT
Subject: RFR: 8371128: NullPointerException occurs due to double cleanup of
 SwingNode [v2]
In-Reply-To: <tUMzPRgd89uQADSj_vcU480sCeXmxFShLoFl0wINX2M=.decba1f2-8693-495d-aa30-01aea4f87430@github.com>
References: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
 <h8fUjVkYPIOgvlMYj3H1_F6gMgP_Vsak2g4P1ndb9sE=.631b9529-17f8-4a3a-ac6a-037df3374a60@github.com>
 <tTcG73QheIC7iQ4XsbditA5LIR9C_gZCUWAOaT14y0M=.02f275f8-0a37-457a-9125-5099f5f7a247@github.com>
 <tUMzPRgd89uQADSj_vcU480sCeXmxFShLoFl0wINX2M=.decba1f2-8693-495d-aa30-01aea4f87430@github.com>
Message-ID: <8tIzBYY8xC50iujDytfb2utmLHJU9LfFTO7N0Hyjzjw=.497d14bd-c226-4911-a1eb-4b872e079112@github.com>

On Tue, 4 Nov 2025 17:28:44 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.swing/src/main/java/javafx/embed/swing/SwingNode.java line 283:
>> 
>>> 281:                     SwingNodeHelper.runOnEDT(() -> {
>>> 282:                         if (lwFrame != null) {
>>> 283:                             swNodeIOP.overrideNativeWindowHandle(lwFrame, 0L,
>> 
>> question: is it possible to have `lwFrame` set to `null` between L282 and L283?
>
> seems like being set in the EDT always

BUT, in line 555 we are accessing lwFrame from the FX app thread, in a completely unsafe manner - test followed by use.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1960#discussion_r2491457526

From kcr at openjdk.org  Tue Nov  4 17:42:38 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 17:42:38 GMT
Subject: [jfx25u] RFR: 8367306: HeaderButtonOverlayTest fails to compile
 with TEST_SDK_PATH
In-Reply-To: <prOHtnwtXxSeai3Nt3UUFHjLIe1u2irBwFlsM-FA1kI=.657bfd44-4b56-465b-bcd7-409c45a523f0@github.com>
References: <prOHtnwtXxSeai3Nt3UUFHjLIe1u2irBwFlsM-FA1kI=.657bfd44-4b56-465b-bcd7-409c45a523f0@github.com>
Message-ID: <YHBwcoxyBezEUya4ht6Iu9cQrT3y6wfFYo7DB_zJ1-U=.ab11077b-7c2c-40ee-b7c9-0c3459ff9ece@github.com>

On Tue, 4 Nov 2025 17:21:30 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> This is a test only fix. 
> When using `-PTEST_SDK_PATH=<path>` and `-PTEST_ONLY=true`, the test `HeaderButtonOverlayTest` fails to compile with error: package com.sun.glass.events is not visible.
> It would be good to backport this fix so that test passes with `-PTEST_SDK_PATH=<path>`

I realize that the review is optional, but I confirm that this simple test fix works and solved the graphics test build failure.

Btw, the macOS aarch64 GHA build failed with a known intermittent test failure.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx25u/pull/34#pullrequestreview-3417869230
PR Comment: https://git.openjdk.org/jfx25u/pull/34#issuecomment-3487290009

From arapte at openjdk.org  Tue Nov  4 18:00:18 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 4 Nov 2025 18:00:18 GMT
Subject: [jfx25u] Integrated: 8367306: HeaderButtonOverlayTest fails to compile
 with TEST_SDK_PATH
In-Reply-To: <prOHtnwtXxSeai3Nt3UUFHjLIe1u2irBwFlsM-FA1kI=.657bfd44-4b56-465b-bcd7-409c45a523f0@github.com>
References: <prOHtnwtXxSeai3Nt3UUFHjLIe1u2irBwFlsM-FA1kI=.657bfd44-4b56-465b-bcd7-409c45a523f0@github.com>
Message-ID: <-HCrVN631YvgAExFZ-Xx9Z0hPytCwDf_5BzC_aqQVkU=.d15bb034-3f55-43ce-9efd-05ef3b2b5a3b@github.com>

On Tue, 4 Nov 2025 17:21:30 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> This is a test only fix. 
> When using `-PTEST_SDK_PATH=<path>` and `-PTEST_ONLY=true`, the test `HeaderButtonOverlayTest` fails to compile with error: package com.sun.glass.events is not visible.
> It would be good to backport this fix so that test passes with `-PTEST_SDK_PATH=<path>`

This pull request has now been integrated.

Changeset: cc07ab1a
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/cc07ab1a1b73c198397d0df1f7d03204fecf4ff4
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8367306: HeaderButtonOverlayTest fails to compile with TEST_SDK_PATH

Reviewed-by: kcr
Backport-of: 3e376e66a3510f8dee7abb52344961caee1d114a

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

PR: https://git.openjdk.org/jfx25u/pull/34

From kcr at openjdk.org  Tue Nov  4 18:02:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 18:02:39 GMT
Subject: RFR: 8371128: NullPointerException occurs due to double cleanup of
 SwingNode [v2]
In-Reply-To: <8tIzBYY8xC50iujDytfb2utmLHJU9LfFTO7N0Hyjzjw=.497d14bd-c226-4911-a1eb-4b872e079112@github.com>
References: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
 <h8fUjVkYPIOgvlMYj3H1_F6gMgP_Vsak2g4P1ndb9sE=.631b9529-17f8-4a3a-ac6a-037df3374a60@github.com>
 <tTcG73QheIC7iQ4XsbditA5LIR9C_gZCUWAOaT14y0M=.02f275f8-0a37-457a-9125-5099f5f7a247@github.com>
 <tUMzPRgd89uQADSj_vcU480sCeXmxFShLoFl0wINX2M=.decba1f2-8693-495d-aa30-01aea4f87430@github.com>
 <8tIzBYY8xC50iujDytfb2utmLHJU9LfFTO7N0Hyjzjw=.497d14bd-c226-4911-a1eb-4b872e079112@github.com>
Message-ID: <7dJzoMhEzKCafPO065FLCT63aH_qpMHoJ2beIlTbOYY=.0a23a74f-3f2e-40fa-af33-a923f28fc9a0@github.com>

On Tue, 4 Nov 2025 17:30:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> seems like being set in the EDT always
>
> BUT, in line 555 we are accessing lwFrame from the FX app thread, in a completely unsafe manner - test followed by use.

Good catch. Other than being another possible source of an NPE, that one seems unrelated, so might be better handled as a follow-up. This one isn't a threading issue whereas the one you pointed out is.

@prsadhuk Can you at least take a look at it and see whether there is any relation to the bug you are fixing? If not, let's file a follow-up bug. The fix is to also check for null on the EDT before calling createUngrabEvent (as is done in disposeLwFrame -- even if you test lwFrame for null in the FX thread (to short-circuit creating the call on the EDT), you still need to check before use once you actually are on the EDT.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1960#discussion_r2491576342

From kcr at openjdk.org  Tue Nov  4 18:20:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 18:20:57 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v6]
In-Reply-To: <FOibqvmhc2kby5tOnY2lGj5POE8U8F2nFWm0ecD5l34=.7846c8be-6da9-41c3-9985-72c7ea371f20@github.com>
References: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
 <FOibqvmhc2kby5tOnY2lGj5POE8U8F2nFWm0ecD5l34=.7846c8be-6da9-41c3-9985-72c7ea371f20@github.com>
Message-ID: <Yw0GQ6IhXa9ceiIGPlYtau3OXeQdFyBYCCwQJYgxwh8=.2a94db47-e426-4ee5-a1cd-88cedb06231b@github.com>

On Thu, 30 Oct 2025 08:11:34 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> When calling `refresh()` on virtualized Controls (`ListView`, `TreeView`, `TableView`, `TreeTableView`), all cells will be recreated completely, instead of just refreshing them.
>> 
>> This is because `recreateCells()` of the `VirtualFlow` is called when `refresh()` was called. This is not needed, since refreshing the cells can be done much cheaper with `rebuildCells()`.
>> 
>> This will reset all cells (`index = -1`), add them to the pile and fill them back in the viewport with an index again. This ensures `updateItem()` is called.
>> 
>> The contract of `refresh()` is also a big vague, stating:
>> 
>> Calling {@code refresh()} forces the XXX control to recreate and repopulate the cells 
>> necessary to populate the visual bounds of the control.
>> In other words, this forces the XXX to update what it is showing to the user. 
>> This is useful in cases where the underlying data source has changed in a way that is not observed by the XXX itself.
>> 
>> 
>> As written above, recreating is not needed in order to fulfull the contract of updating what is shown to the user in case the underlying data source changed without JavaFX noticing (e.g. calling a normal Setter without any Property and therefore listener involved).
>> 
>> ----
>> 
>> Benchmarks
>> -
>> 
>> Setup:
>> - `TableView`
>> - `100 TableColumns`
>> - `1000 Items`
>> 
>> Code is in `tests/performance`.
>> 
>> Calling `refresh()` with a `Button` press.
>> 
>> | WHAT | BEFORE WITHOUT JDK-8360940 | BEFORE | WITH FIX | WITH FIX WITH JDK-8370498 |
>> | - | - | - | - | - |
>> | Init | 0ms | 0 ms | 0 ms | 0 ms |
>> | Init | 0ms | 0 ms | 0 ms | 0 ms |
>> | Init | 195 ms | 209 ms | 211 ms | 217 ms |
>> | Init | 42 ms | 47 ms | 41 ms | 10 ms |
>> | Init | 2 ms | 6 ms | 6 ms | - |
>> | Refresh Nr. 1 | 204 ms | 227 ms -> 23 ms -> 0 ms | 42 ms -> 0ms | 48 ms -> 0ms |
>> | Refresh Nr. 2 | 201 ms | 145 ms -> 27 ms -> 0 ms | 31 ms -> 0ms | 35 ms -> 0ms |
>> | Refresh Nr. 3 | 207 ms | 153 ms -> 25 ms | 33 ms -> 0ms | 31 ms -> 0ms |
>> | Refresh Nr. 4 | 148 ms | 168 ms -> 20 ms -> 0 ms | 30 ms -> 0ms | 31 ms -> 0ms |
>> | Refresh Nr. 5 | 136 ms | 183 ms -> 31 ms -> 0 ms | 46 ms -> 0ms | 29 ms -> 0ms |
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add copyright

The latest version of the API docs looks good. The CSR needs to be updated with the diffs between master and the latest version.

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

PR Review: https://git.openjdk.org/jfx/pull/1830#pullrequestreview-3418070404

From kcr at openjdk.org  Tue Nov  4 18:37:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 18:37:46 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v6]
In-Reply-To: <FOibqvmhc2kby5tOnY2lGj5POE8U8F2nFWm0ecD5l34=.7846c8be-6da9-41c3-9985-72c7ea371f20@github.com>
References: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
 <FOibqvmhc2kby5tOnY2lGj5POE8U8F2nFWm0ecD5l34=.7846c8be-6da9-41c3-9985-72c7ea371f20@github.com>
Message-ID: <XlZmP7IIX4rznBtv0xofGVrwEUUtRJRLx_rdd-_VsPo=.eba75081-9da6-40b5-ab99-d8cd58f5bced@github.com>

On Thu, 30 Oct 2025 08:11:34 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> When calling `refresh()` on virtualized Controls (`ListView`, `TreeView`, `TableView`, `TreeTableView`), all cells will be recreated completely, instead of just refreshing them.
>> 
>> This is because `recreateCells()` of the `VirtualFlow` is called when `refresh()` was called. This is not needed, since refreshing the cells can be done much cheaper with `rebuildCells()`.
>> 
>> This will reset all cells (`index = -1`), add them to the pile and fill them back in the viewport with an index again. This ensures `updateItem()` is called.
>> 
>> The contract of `refresh()` is also a big vague, stating:
>> 
>> Calling {@code refresh()} forces the XXX control to recreate and repopulate the cells 
>> necessary to populate the visual bounds of the control.
>> In other words, this forces the XXX to update what it is showing to the user. 
>> This is useful in cases where the underlying data source has changed in a way that is not observed by the XXX itself.
>> 
>> 
>> As written above, recreating is not needed in order to fulfull the contract of updating what is shown to the user in case the underlying data source changed without JavaFX noticing (e.g. calling a normal Setter without any Property and therefore listener involved).
>> 
>> ----
>> 
>> Benchmarks
>> -
>> 
>> Setup:
>> - `TableView`
>> - `100 TableColumns`
>> - `1000 Items`
>> 
>> Code is in `tests/performance`.
>> 
>> Calling `refresh()` with a `Button` press.
>> 
>> | WHAT | BEFORE WITHOUT JDK-8360940 | BEFORE | WITH FIX | WITH FIX WITH JDK-8370498 |
>> | - | - | - | - | - |
>> | Init | 0ms | 0 ms | 0 ms | 0 ms |
>> | Init | 0ms | 0 ms | 0 ms | 0 ms |
>> | Init | 195 ms | 209 ms | 211 ms | 217 ms |
>> | Init | 42 ms | 47 ms | 41 ms | 10 ms |
>> | Init | 2 ms | 6 ms | 6 ms | - |
>> | Refresh Nr. 1 | 204 ms | 227 ms -> 23 ms -> 0 ms | 42 ms -> 0ms | 48 ms -> 0ms |
>> | Refresh Nr. 2 | 201 ms | 145 ms -> 27 ms -> 0 ms | 31 ms -> 0ms | 35 ms -> 0ms |
>> | Refresh Nr. 3 | 207 ms | 153 ms -> 25 ms | 33 ms -> 0ms | 31 ms -> 0ms |
>> | Refresh Nr. 4 | 148 ms | 168 ms -> 20 ms -> 0 ms | 30 ms -> 0ms | 31 ms -> 0ms |
>> | Refresh Nr. 5 | 136 ms | 183 ms -> 31 ms -> 0 ms | 46 ms -> 0ms | 29 ms -> 0ms |
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add copyright

Thanks for adding the perf test. I verified that without this fix (current master branch), the performance of "refresh" and "recreate" are the same (unsurprisingly). With this fix, "refresh" is measurably faster.

I did not review most of the code changes and will rely on others to do that. At least one of the other reviewers will need to re-review.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1830#pullrequestreview-3418137577

From kcr at openjdk.org  Tue Nov  4 18:41:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 18:41:07 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v6]
In-Reply-To: <FOibqvmhc2kby5tOnY2lGj5POE8U8F2nFWm0ecD5l34=.7846c8be-6da9-41c3-9985-72c7ea371f20@github.com>
References: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
 <FOibqvmhc2kby5tOnY2lGj5POE8U8F2nFWm0ecD5l34=.7846c8be-6da9-41c3-9985-72c7ea371f20@github.com>
Message-ID: <Ki8YuHdHva7XJG2bjebOhABSyCvfSazf5lBrzevYC7I=.297fab2c-fd16-41ae-958f-46a4cd13cc0d@github.com>

On Thu, 30 Oct 2025 08:11:34 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> When calling `refresh()` on virtualized Controls (`ListView`, `TreeView`, `TableView`, `TreeTableView`), all cells will be recreated completely, instead of just refreshing them.
>> 
>> This is because `recreateCells()` of the `VirtualFlow` is called when `refresh()` was called. This is not needed, since refreshing the cells can be done much cheaper with `rebuildCells()`.
>> 
>> This will reset all cells (`index = -1`), add them to the pile and fill them back in the viewport with an index again. This ensures `updateItem()` is called.
>> 
>> The contract of `refresh()` is also a big vague, stating:
>> 
>> Calling {@code refresh()} forces the XXX control to recreate and repopulate the cells 
>> necessary to populate the visual bounds of the control.
>> In other words, this forces the XXX to update what it is showing to the user. 
>> This is useful in cases where the underlying data source has changed in a way that is not observed by the XXX itself.
>> 
>> 
>> As written above, recreating is not needed in order to fulfull the contract of updating what is shown to the user in case the underlying data source changed without JavaFX noticing (e.g. calling a normal Setter without any Property and therefore listener involved).
>> 
>> ----
>> 
>> Benchmarks
>> -
>> 
>> Setup:
>> - `TableView`
>> - `100 TableColumns`
>> - `1000 Items`
>> 
>> Code is in `tests/performance`.
>> 
>> Calling `refresh()` with a `Button` press.
>> 
>> | WHAT | BEFORE WITHOUT JDK-8360940 | BEFORE | WITH FIX | WITH FIX WITH JDK-8370498 |
>> | - | - | - | - | - |
>> | Init | 0ms | 0 ms | 0 ms | 0 ms |
>> | Init | 0ms | 0 ms | 0 ms | 0 ms |
>> | Init | 195 ms | 209 ms | 211 ms | 217 ms |
>> | Init | 42 ms | 47 ms | 41 ms | 10 ms |
>> | Init | 2 ms | 6 ms | 6 ms | - |
>> | Refresh Nr. 1 | 204 ms | 227 ms -> 23 ms -> 0 ms | 42 ms -> 0ms | 48 ms -> 0ms |
>> | Refresh Nr. 2 | 201 ms | 145 ms -> 27 ms -> 0 ms | 31 ms -> 0ms | 35 ms -> 0ms |
>> | Refresh Nr. 3 | 207 ms | 153 ms -> 25 ms | 33 ms -> 0ms | 31 ms -> 0ms |
>> | Refresh Nr. 4 | 148 ms | 168 ms -> 20 ms -> 0 ms | 30 ms -> 0ms | 31 ms -> 0ms |
>> | Refresh Nr. 5 | 136 ms | 183 ms -> 31 ms -> 0 ms | 46 ms -> 0ms | 29 ms -> 0ms |
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add copyright

tests/performance/control/src/table/TableRefreshTest.java line 77:

> 75:             refreshBtn.setOnAction(_ -> tv.refresh());
> 76:             Button recreateBtn = new Button("Recreate");
> 77:             recreateBtn.setOnAction(_ -> tv.getProperties().put("recreateKey", true));

Question: Can this be done with public API? It's OK as is, since it is a test, but I figured I'd ask.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2491682003

From angorya at openjdk.org  Tue Nov  4 18:40:42 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Nov 2025 18:40:42 GMT
Subject: RFR: 8368629: Texture.update sometimes invoked for a disposed
 Texture [v5]
In-Reply-To: <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>
Message-ID: <8aRtVmY4T7o9AFVk_a2qW46Zg22ZADOgdgoOOeembO0=.1b1c18ac-c214-44f9-bf9e-fc5065ae8fa4@github.com>

On Tue, 4 Nov 2025 14:49:56 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments - MTLTexture: add isValid() check to update(MediaFrame)

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1951#pullrequestreview-3418148377

From angorya at openjdk.org  Tue Nov  4 18:44:33 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Nov 2025 18:44:33 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v6]
In-Reply-To: <FOibqvmhc2kby5tOnY2lGj5POE8U8F2nFWm0ecD5l34=.7846c8be-6da9-41c3-9985-72c7ea371f20@github.com>
References: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
 <FOibqvmhc2kby5tOnY2lGj5POE8U8F2nFWm0ecD5l34=.7846c8be-6da9-41c3-9985-72c7ea371f20@github.com>
Message-ID: <Zat5FKw1pnDQeqIBqtF1WNFc1TK8itjgrz-EJjfYKQQ=.070a7c66-4f66-49a8-b8f2-51ac077f01bc@github.com>

On Thu, 30 Oct 2025 08:11:34 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> When calling `refresh()` on virtualized Controls (`ListView`, `TreeView`, `TableView`, `TreeTableView`), all cells will be recreated completely, instead of just refreshing them.
>> 
>> This is because `recreateCells()` of the `VirtualFlow` is called when `refresh()` was called. This is not needed, since refreshing the cells can be done much cheaper with `rebuildCells()`.
>> 
>> This will reset all cells (`index = -1`), add them to the pile and fill them back in the viewport with an index again. This ensures `updateItem()` is called.
>> 
>> The contract of `refresh()` is also a big vague, stating:
>> 
>> Calling {@code refresh()} forces the XXX control to recreate and repopulate the cells 
>> necessary to populate the visual bounds of the control.
>> In other words, this forces the XXX to update what it is showing to the user. 
>> This is useful in cases where the underlying data source has changed in a way that is not observed by the XXX itself.
>> 
>> 
>> As written above, recreating is not needed in order to fulfull the contract of updating what is shown to the user in case the underlying data source changed without JavaFX noticing (e.g. calling a normal Setter without any Property and therefore listener involved).
>> 
>> ----
>> 
>> Benchmarks
>> -
>> 
>> Setup:
>> - `TableView`
>> - `100 TableColumns`
>> - `1000 Items`
>> 
>> Code is in `tests/performance`.
>> 
>> Calling `refresh()` with a `Button` press.
>> 
>> | WHAT | BEFORE WITHOUT JDK-8360940 | BEFORE | WITH FIX | WITH FIX WITH JDK-8370498 |
>> | - | - | - | - | - |
>> | Init | 0ms | 0 ms | 0 ms | 0 ms |
>> | Init | 0ms | 0 ms | 0 ms | 0 ms |
>> | Init | 195 ms | 209 ms | 211 ms | 217 ms |
>> | Init | 42 ms | 47 ms | 41 ms | 10 ms |
>> | Init | 2 ms | 6 ms | 6 ms | - |
>> | Refresh Nr. 1 | 204 ms | 227 ms -> 23 ms -> 0 ms | 42 ms -> 0ms | 48 ms -> 0ms |
>> | Refresh Nr. 2 | 201 ms | 145 ms -> 27 ms -> 0 ms | 31 ms -> 0ms | 35 ms -> 0ms |
>> | Refresh Nr. 3 | 207 ms | 153 ms -> 25 ms | 33 ms -> 0ms | 31 ms -> 0ms |
>> | Refresh Nr. 4 | 148 ms | 168 ms -> 20 ms -> 0 ms | 30 ms -> 0ms | 31 ms -> 0ms |
>> | Refresh Nr. 5 | 136 ms | 183 ms -> 31 ms -> 0 ms | 46 ms -> 0ms | 29 ms -> 0ms |
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add copyright

looks good, thanks!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1830#pullrequestreview-3418164751

From kcr at openjdk.org  Tue Nov  4 20:50:28 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 20:50:28 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v6]
In-Reply-To: <HzoV0_nTS4wT9sp6sp0GsdHr1MOPcOh-Jv_yx8y4hWA=.67710d5a-0169-4ce4-9c7b-b2b78573b73d@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <HzoV0_nTS4wT9sp6sp0GsdHr1MOPcOh-Jv_yx8y4hWA=.67710d5a-0169-4ce4-9c7b-b2b78573b73d@github.com>
Message-ID: <amqwYWz3r23pO_2bkjFwY33vEQknAGmQDROnM_U1Z7c=.e7c864d0-5b51-4fbf-9441-4e9faae9559b@github.com>

On Fri, 31 Oct 2025 18:48:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
>> 
>> The impacted areas are:
>> - saving to plain text
>> - copying to plain text
>> - IME
>> 
>> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), and as a property in the `CodeArea`.
>> 
>> NOTE:
>> - some dependency on #1938 , resolved.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get text

I looked over the proposed API and left some inline comments. I'll repeat my two main points here:

1. Rather than a Nullable enum, create an explicit enum value for "use the `line.separator` property"
2. Why is the new lineEnding property on the `CodeArea` subclass and not on `RichTextArea`?

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 466:

> 464:      * @return the line ending property
> 465:      * @since 26
> 466:      * @defaultValue null

I can't think of a good reason for this to be a Nullable property. Instead, define a new enum value that means "use the value of the `line.separator` system property". It seems much cleaner (I don't like relying on `null` for out of band enum values, since it will cause an NPE if you switch on it without checking for null first).

Separately, should "use line.separator" should be the default value or should it use "\n" instead. Probably using "line.separator" is a better choice, which is what this PR does. The reason I bring this up is so that we make a conscious decision.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 468:

> 466:      * @defaultValue null
> 467:      */
> 468:     public final ObjectProperty<LineEnding> lineEndingProperty() {

Shouldn't this be a property of RichTextArea?

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/LineEnding.java line 33:

> 31:  * @since 26
> 32:  */
> 33: public enum LineEnding {

Please add an explicit enum value that means "use the value of System.getProperty("line.separator")". Relying on `null` to mean this is not clean for two reasons: 1) it is more difficult to document (case in point, it isn't documented here); and 2) using an enum that might be null in a switch statement without first checking for null will cause an NPE.

Possible names: `NATIVE`? `LINE_SEPARATOR`? something else?

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/LineEnding.java line 35:

> 33: public enum LineEnding {
> 34:     /** Classic Mac OS */
> 35:     CR,

I question the need for this enum value. CR was only used prior to macOS 10.0, which is so old as to be uninteresting without a good reason (for comparison, the very first version of Java for macOS was for macOS 10.5). Do you have a use case in mind?

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/LineEnding.java line 39:

> 37:     CRLF,
> 38:     /** macOS/Unix */
> 39:     LF

Since this shows up in the javadoc-generated API docs, it might be worth expanding this a bit.

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

PR Review: https://git.openjdk.org/jfx/pull/1944#pullrequestreview-3418252114
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2491791031
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2491987923
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2491756972
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2491766155
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2491767288

From angorya at openjdk.org  Tue Nov  4 21:06:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Nov 2025 21:06:59 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v11]
In-Reply-To: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
References: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
Message-ID: <qs8jE5IgmH5OAiM1Gq84NCUtGYKA7rMM4jJ5MI-aW8I=.35573598-02dd-42c8-8be2-bffdf69e431d@github.com>

> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
> 
> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
> 
> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
> 
> WARNING this is an incompatible change, permitted because of the incubator.
> 
> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .

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

  javadoc

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1941/files
  - new: https://git.openjdk.org/jfx/pull/1941/files/878429e3..b8e53ba2

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

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

PR: https://git.openjdk.org/jfx/pull/1941

From kcr at openjdk.org  Tue Nov  4 21:08:30 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 21:08:30 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v6]
In-Reply-To: <amqwYWz3r23pO_2bkjFwY33vEQknAGmQDROnM_U1Z7c=.e7c864d0-5b51-4fbf-9441-4e9faae9559b@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <HzoV0_nTS4wT9sp6sp0GsdHr1MOPcOh-Jv_yx8y4hWA=.67710d5a-0169-4ce4-9c7b-b2b78573b73d@github.com>
 <amqwYWz3r23pO_2bkjFwY33vEQknAGmQDROnM_U1Z7c=.e7c864d0-5b51-4fbf-9441-4e9faae9559b@github.com>
Message-ID: <HDjqjUSBupGIuUbjqLS0lpVudw6kSfuEn0ZC2FJuOSc=.1fdd0c1e-dc02-4cf6-a92e-f3edf3a247f8@github.com>

On Tue, 4 Nov 2025 19:06:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   get text
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/LineEnding.java line 33:
> 
>> 31:  * @since 26
>> 32:  */
>> 33: public enum LineEnding {
> 
> Please add an explicit enum value that means "use the value of System.getProperty("line.separator")". Relying on `null` to mean this is not clean for two reasons: 1) it is more difficult to document (case in point, it isn't documented here); and 2) using an enum that might be null in a switch statement without first checking for null will cause an NPE.
> 
> Possible names: `NATIVE`? `LINE_SEPARATOR`? something else?

Another possible name: `DEFAULT`

I'm not sure which one I like best.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2492047048

From kcr at openjdk.org  Tue Nov  4 21:35:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 21:35:03 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v11]
In-Reply-To: <qs8jE5IgmH5OAiM1Gq84NCUtGYKA7rMM4jJ5MI-aW8I=.35573598-02dd-42c8-8be2-bffdf69e431d@github.com>
References: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
 <qs8jE5IgmH5OAiM1Gq84NCUtGYKA7rMM4jJ5MI-aW8I=.35573598-02dd-42c8-8be2-bffdf69e431d@github.com>
Message-ID: <U5B-VPgnp5jag81YYWkTrN3f0WLfbBtl0iXv_nOw9bc=.04ae72d5-a6cb-4fc1-866a-2c6d556f917f@github.com>

On Tue, 4 Nov 2025 21:06:59 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc

Updated links in the javadocs look good. I would think javadoc should warn about that, but it looks like it doesn't.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1941#pullrequestreview-3418704124

From angorya at openjdk.org  Tue Nov  4 21:38:32 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Nov 2025 21:38:32 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v11]
In-Reply-To: <qs8jE5IgmH5OAiM1Gq84NCUtGYKA7rMM4jJ5MI-aW8I=.35573598-02dd-42c8-8be2-bffdf69e431d@github.com>
References: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
 <qs8jE5IgmH5OAiM1Gq84NCUtGYKA7rMM4jJ5MI-aW8I=.35573598-02dd-42c8-8be2-bffdf69e431d@github.com>
Message-ID: <lYsaWSXVuVhsJ7BSVU9MPK1zxrwpaXLW5LSs4arxGh4=.cd1d6bb2-3838-4bd4-9637-2cd4561919ed@github.com>

On Tue, 4 Nov 2025 21:06:59 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc

Javadoc tool seems to allow a link to a private method from a javadoc comment.  Could be a bug, could be by design.

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

PR Comment: https://git.openjdk.org/jfx/pull/1941#issuecomment-3488095620

From angorya at openjdk.org  Tue Nov  4 21:53:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Nov 2025 21:53:16 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v6]
In-Reply-To: <HDjqjUSBupGIuUbjqLS0lpVudw6kSfuEn0ZC2FJuOSc=.1fdd0c1e-dc02-4cf6-a92e-f3edf3a247f8@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <HzoV0_nTS4wT9sp6sp0GsdHr1MOPcOh-Jv_yx8y4hWA=.67710d5a-0169-4ce4-9c7b-b2b78573b73d@github.com>
 <amqwYWz3r23pO_2bkjFwY33vEQknAGmQDROnM_U1Z7c=.e7c864d0-5b51-4fbf-9441-4e9faae9559b@github.com>
 <HDjqjUSBupGIuUbjqLS0lpVudw6kSfuEn0ZC2FJuOSc=.1fdd0c1e-dc02-4cf6-a92e-f3edf3a247f8@github.com>
Message-ID: <eEsC-wXu14ZA1ChVSepG2FCJouwva2IOL4pNL4_G0-M=.33064092-96c2-4f5f-9a07-a05233b872ae@github.com>

On Tue, 4 Nov 2025 21:06:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/LineEnding.java line 33:
>> 
>>> 31:  * @since 26
>>> 32:  */
>>> 33: public enum LineEnding {
>> 
>> Please add an explicit enum value that means "use the value of System.getProperty("line.separator")". Relying on `null` to mean this is not clean for two reasons: 1) it is more difficult to document (case in point, it isn't documented here); and 2) using an enum that might be null in a switch statement without first checking for null will cause an NPE.
>> 
>> Possible names: `NATIVE`? `LINE_SEPARATOR`? something else?
>
> Another possible name: `DEFAULT`
> 
> I'm not sure which one I like best.

`PLATFORM_DEFAULT` maybe?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2492141176

From mhanl at openjdk.org  Tue Nov  4 21:53:37 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 4 Nov 2025 21:53:37 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v6]
In-Reply-To: <Ki8YuHdHva7XJG2bjebOhABSyCvfSazf5lBrzevYC7I=.297fab2c-fd16-41ae-958f-46a4cd13cc0d@github.com>
References: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
 <FOibqvmhc2kby5tOnY2lGj5POE8U8F2nFWm0ecD5l34=.7846c8be-6da9-41c3-9985-72c7ea371f20@github.com>
 <Ki8YuHdHva7XJG2bjebOhABSyCvfSazf5lBrzevYC7I=.297fab2c-fd16-41ae-958f-46a4cd13cc0d@github.com>
Message-ID: <wxdqtmWy28rxfblDiX3aSwShuqF3k8FLx3bQL_d6_yQ=.ae07521c-a7ad-4de3-a3d4-9d3ac93fd3c0@github.com>

On Tue, 4 Nov 2025 18:38:12 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add copyright
>
> tests/performance/control/src/table/TableRefreshTest.java line 77:
> 
>> 75:             refreshBtn.setOnAction(_ -> tv.refresh());
>> 76:             Button recreateBtn = new Button("Recreate");
>> 77:             recreateBtn.setOnAction(_ -> tv.getProperties().put("recreateKey", true));
> 
> Question: Can this be done with public API? It's OK as is, since it is a test, but I figured I'd ask.

Note like this, but setting a new `TableRow` factory will essentially trigger and do the same:
https://github.com/openjdk/jfx/blob/a4e5451373beed93942e0bf2b6c8b81d3e6ad66d/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableViewSkinBase.java#L331-L337

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2492141465

From kcr at openjdk.org  Tue Nov  4 22:03:12 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 22:03:12 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v2]
In-Reply-To: <SUQ3uoL6zgtSTQzHnzd9pv5DbkeBmZUK8AcMz__By0c=.c2627d35-51c0-42bb-a8bf-f5a5cfbd9450@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <SUQ3uoL6zgtSTQzHnzd9pv5DbkeBmZUK8AcMz__By0c=.c2627d35-51c0-42bb-a8bf-f5a5cfbd9450@github.com>
Message-ID: <Q2BwedcY8YwXxEl12B8EVrAacrS4uFA_9q1kv7fb-rc=.64884b51-1bd2-4c8e-a1b4-4de1f140c44d@github.com>

On Mon, 20 Oct 2025 05:06:20 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR implements a new default method on `ObservableList` to be able to replace elements within a specified range.
>> 
>> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
>> 
>> The other alternative is to call `set` individually for each item, which results in many change notifications.
>> 
>> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
>> 
>> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.
>
> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix test
>  - Rename setAll to replaceRange and removed superfluous method

Looks good. I left a question as to whether a couple additional tests might be useful.

modules/javafx.base/src/test/java/test/javafx/collections/ModifiableObservableListBaseTest.java line 94:

> 92:         @Test
> 93:         void shouldReplaceElementsAtGivenRange() {
> 94:             assertTrue(list.replaceRange(1, 3, List.of("B", "C", "D")));

Would additional tests be useful?

* Replace a sub-range in the middle (so both beginning and end are kept)
* Replace a sub-range with fewer elements than are removed (the existing test checks the case of more elements added than removed)

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1937#pullrequestreview-3418762471
PR Review Comment: https://git.openjdk.org/jfx/pull/1937#discussion_r2492152669

From kcr at openjdk.org  Tue Nov  4 22:03:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 22:03:13 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v2]
In-Reply-To: <-O4F0UKPZVGp6TV18AKefLrXvIdtSHySgYF6tdA5_GY=.090ff031-c390-4718-a3d0-debbeeef05aa@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <SUQ3uoL6zgtSTQzHnzd9pv5DbkeBmZUK8AcMz__By0c=.c2627d35-51c0-42bb-a8bf-f5a5cfbd9450@github.com>
 <-O4F0UKPZVGp6TV18AKefLrXvIdtSHySgYF6tdA5_GY=.090ff031-c390-4718-a3d0-debbeeef05aa@github.com>
Message-ID: <lXt-yQXJQ1JZnFtymhvjGCzuyt_5vNZKMAhvb9VGbpw=.44e22d55-87c7-4cd1-93cd-a5ac297749cb@github.com>

On Sun, 2 Nov 2025 00:49:29 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix test
>>  - Rename setAll to replaceRange and removed superfluous method
>
> Looks like I'll need this change to write a test for replacing a range of elements in ListView.  It seems that currently replacing a range of items will always clear the whole selection.  Filed https://bugs.openjdk.org/browse/JDK-8371090 to track those problems.

@hjohn You can create the CSR when you are ready. I'll review it once you do.

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

PR Comment: https://git.openjdk.org/jfx/pull/1937#issuecomment-3488160916

From duke at openjdk.org  Tue Nov  4 23:01:28 2025
From: duke at openjdk.org (iso53)
Date: Tue, 4 Nov 2025 23:01:28 GMT
Subject: RFR: 8370912: Formatting error on JavaDoc because of missing quotation
 mark.
Message-ID: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>

Corrected a missing closing quote in the HBox JavaDoc example, ensuring it's properly formatted.

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

Commit messages:
 - 8370912: Formatting error on JavaDoc because of missing quotation mark.

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

PR: https://git.openjdk.org/jfx/pull/1956

From kcr at openjdk.org  Tue Nov  4 23:01:29 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 23:01:29 GMT
Subject: RFR: 8370912: Formatting error on JavaDoc because of missing
 quotation mark.
In-Reply-To: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
References: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
Message-ID: <JRnK4wFDFD4Pd_i3lyULFRttvIpHzLbL8A_FLx13SIs=.23016d95-4f73-4cee-90c9-0182942b02be@github.com>

On Thu, 30 Oct 2025 07:39:11 GMT, iso53 <duke at openjdk.org> wrote:

> Corrected a missing closing quote in the HBox JavaDoc example, ensuring it's properly formatted.

@ISO53 If you would like to proceed with this PR, please sign the [Oracle Contributor Agreement](https://oca.opensource.oracle.com/) (OCA) as indicated in the [Contributing Guidelines](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#before-submitting-a-pull-request) and then enter `/signed` in a comment in this PR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1956#issuecomment-3476429339

From duke at openjdk.org  Tue Nov  4 23:01:29 2025
From: duke at openjdk.org (iso53)
Date: Tue, 4 Nov 2025 23:01:29 GMT
Subject: RFR: 8370912: Formatting error on JavaDoc because of missing
 quotation mark.
In-Reply-To: <JRnK4wFDFD4Pd_i3lyULFRttvIpHzLbL8A_FLx13SIs=.23016d95-4f73-4cee-90c9-0182942b02be@github.com>
References: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
 <JRnK4wFDFD4Pd_i3lyULFRttvIpHzLbL8A_FLx13SIs=.23016d95-4f73-4cee-90c9-0182942b02be@github.com>
Message-ID: <hcYUciUpUYAbGXmxJRrJlvQqQRHWog0PuIcAgyR4cQo=.1ae02a7a-9451-4b53-b4a6-4359c70c6e30@github.com>

On Sat, 1 Nov 2025 14:43:15 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Corrected a missing closing quote in the HBox JavaDoc example, ensuring it's properly formatted.
>
> @ISO53 If you would like to proceed with this PR, please sign the [Oracle Contributor Agreement](https://oca.opensource.oracle.com/) (OCA) as indicated in the [Contributing Guidelines](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#before-submitting-a-pull-request) and then enter `/signed` in a comment in this PR.

@kevinrushforth I've signed it. It's still under review. Patiently waiting :)

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

PR Comment: https://git.openjdk.org/jfx/pull/1956#issuecomment-3476431189

From kcr at openjdk.org  Tue Nov  4 23:01:30 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 23:01:30 GMT
Subject: RFR: 8370912: Formatting error on JavaDoc because of missing
 quotation mark.
In-Reply-To: <hcYUciUpUYAbGXmxJRrJlvQqQRHWog0PuIcAgyR4cQo=.1ae02a7a-9451-4b53-b4a6-4359c70c6e30@github.com>
References: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
 <JRnK4wFDFD4Pd_i3lyULFRttvIpHzLbL8A_FLx13SIs=.23016d95-4f73-4cee-90c9-0182942b02be@github.com>
 <hcYUciUpUYAbGXmxJRrJlvQqQRHWog0PuIcAgyR4cQo=.1ae02a7a-9451-4b53-b4a6-4359c70c6e30@github.com>
Message-ID: <8N1KWVTTzmssRyWA3NhL1fwVZk07liuYuJnF3DXkPOQ=.b459b3c1-a382-4f05-9b26-3f26af5e46d0@github.com>

On Sat, 1 Nov 2025 14:46:25 GMT, iso53 <duke at openjdk.org> wrote:

> I've signed it. It's still under review. Patiently waiting :)

OK. You can enter a `/signed` comment while waiting if you like.

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

PR Comment: https://git.openjdk.org/jfx/pull/1956#issuecomment-3476480537

From kcr at openjdk.org  Tue Nov  4 23:05:30 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 23:05:30 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v6]
In-Reply-To: <eEsC-wXu14ZA1ChVSepG2FCJouwva2IOL4pNL4_G0-M=.33064092-96c2-4f5f-9a07-a05233b872ae@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <HzoV0_nTS4wT9sp6sp0GsdHr1MOPcOh-Jv_yx8y4hWA=.67710d5a-0169-4ce4-9c7b-b2b78573b73d@github.com>
 <amqwYWz3r23pO_2bkjFwY33vEQknAGmQDROnM_U1Z7c=.e7c864d0-5b51-4fbf-9441-4e9faae9559b@github.com>
 <HDjqjUSBupGIuUbjqLS0lpVudw6kSfuEn0ZC2FJuOSc=.1fdd0c1e-dc02-4cf6-a92e-f3edf3a247f8@github.com>
 <eEsC-wXu14ZA1ChVSepG2FCJouwva2IOL4pNL4_G0-M=.33064092-96c2-4f5f-9a07-a05233b872ae@github.com>
Message-ID: <3EZq1E5DULZW7Y24jeJ6tllzF0GrZLjKE1xY0UpdyHA=.6357ec1b-42c1-4020-8e06-6d61acc05143@github.com>

On Tue, 4 Nov 2025 21:50:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Another possible name: `DEFAULT`
>> 
>> I'm not sure which one I like best.
>
> `PLATFORM_DEFAULT` maybe?

Maybe. Or maybe `SYSTEM_DEFAULT` (since it comes from Java's system properties)?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2492268263

From angorya at openjdk.org  Tue Nov  4 23:09:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Nov 2025 23:09:53 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v6]
In-Reply-To: <amqwYWz3r23pO_2bkjFwY33vEQknAGmQDROnM_U1Z7c=.e7c864d0-5b51-4fbf-9441-4e9faae9559b@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <HzoV0_nTS4wT9sp6sp0GsdHr1MOPcOh-Jv_yx8y4hWA=.67710d5a-0169-4ce4-9c7b-b2b78573b73d@github.com>
 <amqwYWz3r23pO_2bkjFwY33vEQknAGmQDROnM_U1Z7c=.e7c864d0-5b51-4fbf-9441-4e9faae9559b@github.com>
Message-ID: <pyRdlYykU3rnJyWiPpO-p1r_HT_rwTjRH_Fjp6Rq3WY=.7dfcccf3-d499-482f-880d-dec48154f8cf@github.com>

On Tue, 4 Nov 2025 19:09:54 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   get text
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/LineEnding.java line 35:
> 
>> 33: public enum LineEnding {
>> 34:     /** Classic Mac OS */
>> 35:     CR,
> 
> I question the need for this enum value. CR was only used prior to macOS 10.0, which is so old as to be uninteresting without a good reason (for comparison, the very first version of Java for macOS was for macOS 10.5). Do you have a use case in mind?

Yes, the use case is for application developers to have full control of the line endings.  This might be useful for programming editors that deal with legacy formats.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2492276685

From kcr at openjdk.org  Tue Nov  4 23:13:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Nov 2025 23:13:19 GMT
Subject: RFR: 8370912: Formatting error on JavaDoc because of missing
 quotation mark.
In-Reply-To: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
References: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
Message-ID: <SyaiPRpH9M5gNQPdLgi07nZ5_UUxaLArTqBOaZK4ucM=.390915b8-3fb7-4670-b652-3f5e72cbcd01@github.com>

On Thu, 30 Oct 2025 07:39:11 GMT, iso53 <duke at openjdk.org> wrote:

> Corrected a missing closing quote in the HBox JavaDoc example, ensuring it's properly formatted.

The doc change looks good. Can you do two more things?

1. I removed the trailing `.` from the JBS issue title (at Skara's suggestion). Can you update your PR title to match (no change needed to the code, since the commit message in your branch isn't used).
2. Please enable running GitHub actions in your repo to allow a GHA run for sanity testing.

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

PR Comment: https://git.openjdk.org/jfx/pull/1956#issuecomment-3488330044

From angorya at openjdk.org  Wed Nov  5 00:09:32 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Nov 2025 00:09:32 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v6]
In-Reply-To: <amqwYWz3r23pO_2bkjFwY33vEQknAGmQDROnM_U1Z7c=.e7c864d0-5b51-4fbf-9441-4e9faae9559b@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <HzoV0_nTS4wT9sp6sp0GsdHr1MOPcOh-Jv_yx8y4hWA=.67710d5a-0169-4ce4-9c7b-b2b78573b73d@github.com>
 <amqwYWz3r23pO_2bkjFwY33vEQknAGmQDROnM_U1Z7c=.e7c864d0-5b51-4fbf-9441-4e9faae9559b@github.com>
Message-ID: <A8WW5po_t1eRA0z_YAFL7PMHXXwxOWtfaLttAefc1po=.e54c6724-3d9c-4e93-a6f4-db07df1fd23a@github.com>

On Tue, 4 Nov 2025 20:40:36 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   get text
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 468:
> 
>> 466:      * @defaultValue null
>> 467:      */
>> 468:     public final ObjectProperty<LineEnding> lineEndingProperty() {
> 
> Shouldn't this be a property of RichTextArea?

No, `RichTextArea` might have a model that has no concept of line ending, or has its own idea of line ending - that's why it's an attribute of the model rather than the property in the control.

`CodeArea`, on the other hand, deals with plain text as an underlying data, so line ending is a property of the control, just like `font` and `tabSize`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2492375075

From angorya at openjdk.org  Wed Nov  5 00:15:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Nov 2025 00:15:19 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v7]
In-Reply-To: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
Message-ID: <tsgRdhX9fKNgf5_IY67XBSt9pEtTvol6vw6RESYkS6c=.2bc0679f-027d-444d-a051-e790c4347c72@github.com>

> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
> 
> The impacted areas are:
> - saving to plain text
> - copying to plain text
> - IME
> 
> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), and as a property in the `CodeArea`.
> 
> NOTE:
> - some dependency on #1938 , resolved.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - non-nullable
 - Merge branch 'master' into 8370140.line.separator
 - get text
 - Merge branch 'master' into 8370140.line.separator
 - since
 - Merge branch 'master' into 8370140.line.separator
 - Merge remote-tracking branch 'origin/master' into 8370140.line.separator
 - tests
 - line endings

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

Changes: https://git.openjdk.org/jfx/pull/1944/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=06
  Stats: 270 lines in 13 files changed: 239 ins; 11 del; 20 mod
  Patch: https://git.openjdk.org/jfx/pull/1944.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1944/head:pull/1944

PR: https://git.openjdk.org/jfx/pull/1944

From almatvee at openjdk.org  Wed Nov  5 02:22:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 5 Nov 2025 02:22:57 GMT
Subject: RFR: 8371052: Update libFFI to 3.5.2
Message-ID: <EihmQlWsI1W2GLW_YDC8pOUhxQnzSfn4W5q1NvH2euM=.d769fa13-8113-43d1-8c37-1fcd849f653d@github.com>

- Updated libFFI to 3.5.2.
- Tested on all platforms.
- No additional changes are done.

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

Commit messages:
 - 8371052: Update libFFI to 3.5.2 [v2]
 - 8371052: Update libFFI to 3.5.2

Changes: https://git.openjdk.org/jfx/pull/1962/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1962&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371052
  Stats: 253 lines in 24 files changed: 183 ins; 12 del; 58 mod
  Patch: https://git.openjdk.org/jfx/pull/1962.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1962/head:pull/1962

PR: https://git.openjdk.org/jfx/pull/1962

From psadhukhan at openjdk.org  Wed Nov  5 03:04:18 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 5 Nov 2025 03:04:18 GMT
Subject: RFR: 8371128: NullPointerException occurs due to double cleanup of
 SwingNode [v2]
In-Reply-To: <7dJzoMhEzKCafPO065FLCT63aH_qpMHoJ2beIlTbOYY=.0a23a74f-3f2e-40fa-af33-a923f28fc9a0@github.com>
References: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
 <h8fUjVkYPIOgvlMYj3H1_F6gMgP_Vsak2g4P1ndb9sE=.631b9529-17f8-4a3a-ac6a-037df3374a60@github.com>
 <tTcG73QheIC7iQ4XsbditA5LIR9C_gZCUWAOaT14y0M=.02f275f8-0a37-457a-9125-5099f5f7a247@github.com>
 <tUMzPRgd89uQADSj_vcU480sCeXmxFShLoFl0wINX2M=.decba1f2-8693-495d-aa30-01aea4f87430@github.com>
 <8tIzBYY8xC50iujDytfb2utmLHJU9LfFTO7N0Hyjzjw=.497d14bd-c226-4911-a1eb-4b872e079112@github.com>
 <7dJzoMhEzKCafPO065FLCT63aH_qpMHoJ2beIlTbOYY=.0a23a74f-3f2e-40fa-af33-a923f28fc9a0@github.com>
Message-ID: <llOy87_TBSeyU4P1pPP6jy5OBbzqu7mSf4fPYH-QOJk=.819b08dc-4035-4f06-ad14-8e342903231f@github.com>

On Tue, 4 Nov 2025 17:58:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> BUT, in line 555 we are accessing lwFrame from the FX app thread, in a completely unsafe manner - test followed by use.
>
> Good catch. Other than being another possible source of an NPE, that one seems unrelated, so might be better handled as a follow-up. This one isn't a threading issue whereas the one you pointed out is.
> 
> @prsadhuk Can you at least take a look at it and see whether there is any relation to the bug you are fixing? If not, let's file a follow-up bug. The fix is to also check for null on the EDT before calling createUngrabEvent (as is done in disposeLwFrame -- even if you test lwFrame for null in the FX thread (to short-circuit creating the call on the EDT), you still need to check before use once you actually are on the EDT.

I don't quite understand..In 


private final EventHandler<FocusUngrabEvent> ungrabHandler = event -> {
    556         if (!skipBackwardUnrgabNotification) {
    557             if (lwFrame != null) {
    558                 postAWTEvent(
    559                     swNodeIOP.createUngrabEvent(lwFrame));
    560             }
    561         }
    562     };

we are checking for null lwFrame in FX thread and there's no thread switching so how can we have again null lwFrame?
In disposeLwFrame, we are checking for null lwFrame inside `SwingNodeHelper.runOnEDT` due to context switch but here no such thing is happening and is running in same thread, so I am not sure why and where to `check for null on the EDT before calling createUngrabEvent`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1960#discussion_r2492695377

From arapte at openjdk.org  Wed Nov  5 08:09:25 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 5 Nov 2025 08:09:25 GMT
Subject: Integrated: 8370883: Update boot JDK to 25.0.1
In-Reply-To: <AqYPkdmL8rn6F-gdhFHBoa7qB37H_mOsqC1NxxvaGFM=.7d7c0324-599d-4594-b8e4-1df4ceceef73@github.com>
References: <AqYPkdmL8rn6F-gdhFHBoa7qB37H_mOsqC1NxxvaGFM=.7d7c0324-599d-4594-b8e4-1df4ceceef73@github.com>
Message-ID: <3H-3pVhWvOSOsTGUyLdMX4C-lohiV2mE9Oi0DfrjtW0=.f69abbfa-6e4c-4965-a9fd-48fee82b7332@github.com>

On Wed, 29 Oct 2025 13:57:39 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Update boot jdk to 25.0.1, along with gradle update to version 9.1.0.
> The gradle 9 related deprecation are already addressed with [JDK-8360586](https://bugs.openjdk.org/browse/JDK-8360586)

This pull request has now been integrated.

Changeset: 3a1cf698
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/3a1cf698cd7e8ad62219076398d282428f4120af
Stats:     27 lines in 7 files changed: 0 ins; 4 del; 23 mod

8370883: Update boot JDK to 25.0.1
8370881: Update Gradle to 9.2.0

Reviewed-by: kcr, sykora, mhanl, kizune

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

PR: https://git.openjdk.org/jfx/pull/1953

From duke at openjdk.org  Wed Nov  5 08:20:29 2025
From: duke at openjdk.org (duke)
Date: Wed, 5 Nov 2025 08:20:29 GMT
Subject: Withdrawn: 8354539: [macOS] ComboBox and Spinner disable system menu
 bar shortcuts
In-Reply-To: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
References: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
Message-ID: <WVW5GXN8OG9YMGJ_DwSzcYnUAc3wQG4FWpY_hPQCAUw=.848ef4cd-70e5-4e8a-90a6-963cb92ffafa@github.com>

On Mon, 14 Jul 2025 17:39:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The Mac platform code sends a KeyEvent into the scene graph and if the event is not consumed it gets sent on to the system menu. But ComboBox and Spinner always consume the original event and fire a copy which the system menu ignores.
> 
> In the past the platform code sent key events to the system menu even if the scene graph consumed them. This caused various bugs and was fixed in PR #1528 leading to this issue.
> 
> One could argue that a ComboBox or Spinner shouldn?t consume all key events but one could also argue that the system menu shouldn?t behave so differently from a standard MenuBar which will respond to any KeyEvent that reaches the top-level Scene no matter where it came from.
> 
> This PR installs an event dispatcher which forwards KEY_PRESSED events on to the platform so any event bubbling through the dispatch chain can trigger the system menu. The dispatcher is placed by the top-level (non-popup) Window such that it?s the last dispatcher encountered while bubbling.
> 
> In this PR once the key event reaches the GlassSystemMenu it passes the JavaFX key code and modifiers into the Mac platform code. This isn?t enough information to construct an NSEvent to pass to the main menu. Instead the code uses the code and modifiers to verify that the originating key down NSEvent (which it retained) should be sent on to NSApp.mainMenu.
> 
> (There are other ways this could work. GlassSystemMenu could take the KeyEvent and perform its own accelerator matching entirely inside Java. This would match the way the standard MenuBar finds accelerators instead of using Apple?s matching algorithm. This PR is the more conservative approach, basically just shifting the timing of system menu matching without changing how it?s done.)

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jfx/pull/1848

From duke at openjdk.org  Wed Nov  5 08:50:25 2025
From: duke at openjdk.org (Alessadro Parisi)
Date: Wed, 5 Nov 2025 08:50:25 GMT
Subject: RFR: 8368629: Texture.update sometimes invoked for a disposed
 Texture [v5]
In-Reply-To: <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>
Message-ID: <b6V3zXUmO4RZ2F0vnt_spUBBY8m_-YBsUrYFnke0xOM=.b6cab202-da18-479c-8fa4-86364cba4ccf@github.com>

On Tue, 4 Nov 2025 14:49:56 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments - MTLTexture: add isValid() check to update(MediaFrame)

I was finally able to compile JavaFX with this PR and integrate it into my maven project. This does not seem to fix my issue entirely.
While I don't see expections like these anymore:
`NullPointerException: Cannot invoke "com.sun.prism.RTTexture.createGraphics()" because <local9> is null`
I now see this:
`java.lang.NullPointerException: Cannot invoke "com.sun.prism.RTTexture.createGraphics()" because "newtex" is null` or this `java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.assertLocked()" because "this.maskTex" is null`
and the app still freezes

Is this related or an entirely different issue?

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3489978984

From duke at openjdk.org  Wed Nov  5 09:17:45 2025
From: duke at openjdk.org (iso53)
Date: Wed, 5 Nov 2025 09:17:45 GMT
Subject: RFR: 8370912: Formatting error on JavaDoc because of missing
 quotation mark
In-Reply-To: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
References: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
Message-ID: <MQ5AnuGP-p1SM5q8yQzo9kQfXBbImrbTHqapltVbmvU=.1558ef5f-d1c1-498a-8aff-b2501977e24f@github.com>

On Thu, 30 Oct 2025 07:39:11 GMT, iso53 <duke at openjdk.org> wrote:

> Corrected a missing closing quote in the HBox JavaDoc example, ensuring it's properly formatted.

Changed the PR title. Actions is already enabled.

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

PR Comment: https://git.openjdk.org/jfx/pull/1956#issuecomment-3490082649

From mhanl at openjdk.org  Wed Nov  5 09:31:12 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 5 Nov 2025 09:31:12 GMT
Subject: RFR: 8240844: Remove dependency on java.desktop from javafx.base
In-Reply-To: <TrtmM5Hcjxb0_w6UYADDNRXQd2XZMLCxDJcWQTDfdC0=.a98156e0-4385-4d96-b1a8-dd5ff031fffa@github.com>
References: <s4sTfLR0m9Ps-C00W_TqTRsM4a0szVpRO7T_FMPOOpo=.56315c2c-9b93-457d-b712-2d9baed984b3@github.com>
 <TrtmM5Hcjxb0_w6UYADDNRXQd2XZMLCxDJcWQTDfdC0=.a98156e0-4385-4d96-b1a8-dd5ff031fffa@github.com>
Message-ID: <vnEkBAmnYunizaL6yynMTLQ1b-H_bb_jVnulbfrZrqU=.93349043-03c1-4cd6-937b-ea06faf36db2@github.com>

On Tue, 4 Nov 2025 12:31:10 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> There was a discussion on this on the mailing list: https://mail.openjdk.org/pipermail/openjfx-dev/2023-November/043731.html.

Thanks. Is there a way to answer to it, even if I don't have the original email anymore?

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

PR Comment: https://git.openjdk.org/jfx/pull/1958#issuecomment-3490133528

From nlisker at gmail.com  Wed Nov  5 09:56:40 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 5 Nov 2025 11:56:40 +0200
Subject: javafx.base and java.desktop
In-Reply-To: <CA+0ynh_cSSv-zUyBB=5Uwt74ZpOXon+xnmvWPZ+vFHsWD_N1+Q@mail.gmail.com>
References: <CA+0ynh8YbgqDipHoLj2pnC9Uq4inKjKSduB_wuifAvtRO0EcAw@mail.gmail.com>
 <d44d2588-65db-4b07-9123-6c0e518a8070@oracle.com>
 <5c8fc9fa-cf5d-455a-8335-022f80ce64d7@oracle.com>
 <CA+0ynh_cSSv-zUyBB=5Uwt74ZpOXon+xnmvWPZ+vFHsWD_N1+Q@mail.gmail.com>
Message-ID: <CA+0ynh-5AwkEvw9XR2q49R_TGj5Yte_YUTFSruGWTAxD-4eiXQ@mail.gmail.com>

This is being implemented in https://github.com/openjdk/jfx/pull/1958.

On Sun, Nov 19, 2023 at 4:42?AM Nir Lisker <nlisker at gmail.com> wrote:

> Perhaps this is the right time to move this forward?
>
>
> I don't see why not. Except for changing the `requires` declaration in the
> module-info and mentioning it in the docs, is there anything else that
> needs to be changed?
>
> On Sat, Nov 18, 2023 at 7:48?PM Kevin Rushforth <
> kevin.rushforth at oracle.com> wrote:
>
>> We would need to validate the assertion that an app can't doing anything
>> useful without the app itself importing and using java.beans from the
>> java.desktop module.
>>
>> At a minimum this would need a CSR specifying this additional requirement
>> that the app must depend on java.desktop in order to use the JavaFX beans
>> property adapter classes.
>>
>> If others think this is useful, we could consider this for JavaFX 23.
>>
>> -- Kevin
>>
>> On 11/18/2023 6:16 AM, Kevin Rushforth wrote:
>>
>> Perhaps the module can be declared 'requires static'.
>>
>>
>> That was my thinking as well, which is captured in
>> https://bugs.openjdk.org/browse/JDK-8240844
>>
>> Perhaps this is the right time to move this forward?
>>
>> -- Kevin
>>
>>
>> On 11/17/2023 4:06 PM, Nir Lisker wrote:
>>
>> Hi,
>>
>> A previous discussion mentioned the removal of AWT dependencies. One of
>> the points that Kevin brought up was
>>
>>  Refactor Java Beans implementation in javafx.base such that java.desktop
>>> is optional
>>
>>
>> John and I looked at this some time ago when we discussed the usage of
>> the javafx base module outside of JavaFX, as its observables/binding
>> capabilities are suitable for non-GUI applications, which currently have to
>> pull in GUI modules as dependencies.
>>
>> The dependency is used in the property.adapter packages that bridge
>> javafx.base properties with Java Beans. I think that these classes are
>> seldom used.
>>
>> What could be a way to deal with that dependency? Perhaps the module can
>> be declared 'requires static'. Or extract the adapter packages into a
>> different "interop" module (javafx.javabeans) like javafx.swing?
>>
>> - Nir
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251105/e96581d7/attachment-0001.htm>

From nlisker at openjdk.org  Wed Nov  5 10:00:19 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 5 Nov 2025 10:00:19 GMT
Subject: RFR: 8240844: Remove dependency on java.desktop from javafx.base
In-Reply-To: <vnEkBAmnYunizaL6yynMTLQ1b-H_bb_jVnulbfrZrqU=.93349043-03c1-4cd6-937b-ea06faf36db2@github.com>
References: <s4sTfLR0m9Ps-C00W_TqTRsM4a0szVpRO7T_FMPOOpo=.56315c2c-9b93-457d-b712-2d9baed984b3@github.com>
 <TrtmM5Hcjxb0_w6UYADDNRXQd2XZMLCxDJcWQTDfdC0=.a98156e0-4385-4d96-b1a8-dd5ff031fffa@github.com>
 <vnEkBAmnYunizaL6yynMTLQ1b-H_bb_jVnulbfrZrqU=.93349043-03c1-4cd6-937b-ea06faf36db2@github.com>
Message-ID: <9kJMzK4X4DJVDBf8B8IAgJUFITcqTTUT0oZfMo7Ga8g=.093d90ef-eb68-4da3-b61a-a5e1e3a09819@github.com>

On Wed, 5 Nov 2025 09:28:27 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> > There was a discussion on this on the mailing list: https://mail.openjdk.org/pipermail/openjfx-dev/2023-November/043731.html.
> 
> Thanks. Is there a way to answer to it, even if I don't have the original email anymore?

Not sure. I sent an email from that thread now so you can latch onto it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1958#issuecomment-3490275127

From mariushanl at web.de  Wed Nov  5 10:46:48 2025
From: mariushanl at web.de (Marius Hanl)
Date: Wed, 5 Nov 2025 10:46:48 +0000
Subject: javafx.base and java.desktop
In-Reply-To: <CA+0ynh-5AwkEvw9XR2q49R_TGj5Yte_YUTFSruGWTAxD-4eiXQ@mail.gmail.com>
References: <CA+0ynh8YbgqDipHoLj2pnC9Uq4inKjKSduB_wuifAvtRO0EcAw@mail.gmail.com>
 <d44d2588-65db-4b07-9123-6c0e518a8070@oracle.com>
 <5c8fc9fa-cf5d-455a-8335-022f80ce64d7@oracle.com>
 <CA+0ynh_cSSv-zUyBB=5Uwt74ZpOXon+xnmvWPZ+vFHsWD_N1+Q@mail.gmail.com>
 <CA+0ynh-5AwkEvw9XR2q49R_TGj5Yte_YUTFSruGWTAxD-4eiXQ@mail.gmail.com>
Message-ID: <trinity-5f3ac2af-ef6f-490f-8cc3-2337125b1b80-1762339607934@trinity-msg-rest-webde-webde-live-58c6f6855b-gl8cl>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251105/4b5a28cf/attachment.htm>

From nlisker at gmail.com  Wed Nov  5 10:59:51 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 5 Nov 2025 12:59:51 +0200
Subject: javafx.base and java.desktop
In-Reply-To: <trinity-5f3ac2af-ef6f-490f-8cc3-2337125b1b80-1762339607934@trinity-msg-rest-webde-webde-live-58c6f6855b-gl8cl>
References: <CA+0ynh8YbgqDipHoLj2pnC9Uq4inKjKSduB_wuifAvtRO0EcAw@mail.gmail.com>
 <d44d2588-65db-4b07-9123-6c0e518a8070@oracle.com>
 <5c8fc9fa-cf5d-455a-8335-022f80ce64d7@oracle.com>
 <CA+0ynh_cSSv-zUyBB=5Uwt74ZpOXon+xnmvWPZ+vFHsWD_N1+Q@mail.gmail.com>
 <CA+0ynh-5AwkEvw9XR2q49R_TGj5Yte_YUTFSruGWTAxD-4eiXQ@mail.gmail.com>
 <trinity-5f3ac2af-ef6f-490f-8cc3-2337125b1b80-1762339607934@trinity-msg-rest-webde-webde-live-58c6f6855b-gl8cl>
Message-ID: <CA+0ynh9vt+2zYcKG0S9Qc53+3jGf9MgQDEHrRq3wa5Cnwx5UzA@mail.gmail.com>

The removal from the base module is straightforward and should continue in
my opinion. The one from graphics is more troublesome because it will
remove functionality that might otherwise be assumed and requires planning.

I suggest using the current PR for decoupling the base module and if a
similar decoupling is done for the graphics module then it should be done
in a different PR.

On Wed, Nov 5, 2025 at 12:46?PM Marius Hanl <mariushanl at web.de> wrote:

> Thanks Nir for referencing the PR.
>
> There are more information and detailed numbers on the PR, but to add some
> context:
>
> I did some tests by making the java.desktop requirement static.
> That is, java.desktop is not automatically pulled into your application.
> If you need it, it need to be put in your module.info, otherwise an
> exception is thrown as soon as a class from java.desktop is used.
>
> When is java.desktop needed?
>
>    - javafx.base: When using any of the Bean Property classes from
>    javafx.beans.property.adapter
>    - javafx.graphics: When using the printing classes, e.g.
>    PrinterJob.createPrinterJob().showPrintDialog(..), or if you want to use
>    ImageIO to load e.g. TIFF or SVG files
>
> Benefit:
> I created a modular Java runtime with JLink and measured the modules and
> disk size. Without java.desktop, the runtime got 13 MB smaller!
> That is a nice decrease, especially if nothing what I mentioned above is
> needed. Creating a native installer like a .MSI will decrease the size
> further.
>
> In my opinion, this is a great benefit. Unfortunately, as Kevin mentioned
> this is a somewhat incompatible change. So I'm interested in your opinion.
> From my perspective, this is nice and if we don't want to go this route,
> I'm thinking for the first time ever about having a custom fork with this
> changes, which I would use for JLink (or can I easily patch those out when
> JLinking?).
> I really don't like that, since now every other developer in the Team
> needs to build JFX, or take my custom JFX build.
> But shipping a at least 13MB smaller .exe / even smaller .msi to the
> customer is very neat, also 'GreenIT' wise.
>
> -- Marius
>
> *Gesendet: *Mittwoch, 5. November 2025 um 10:56
> *Von: *"Nir Lisker" <nlisker at gmail.com>
> *An: *"Kevin Rushforth" <kevin.rushforth at oracle.com>
> *CC: *openjfx-dev at openjdk.org
> *Betreff: *Re: javafx.base and java.desktop
> This is being implemented in https://github.com/openjdk/jfx/pull/1958.
>
> On Sun, Nov 19, 2023 at 4:42?AM Nir Lisker <nlisker at gmail.com> wrote:
>
>> Perhaps this is the right time to move this forward?
>>
>>
>> I don't see why not. Except for changing the `requires` declaration in
>> the module-info and mentioning it in the docs, is there anything else that
>> needs to be changed?
>>
>> On Sat, Nov 18, 2023 at 7:48?PM Kevin Rushforth <
>> kevin.rushforth at oracle.com> wrote:
>>
>>> We would need to validate the assertion that an app can't doing anything
>>> useful without the app itself importing and using java.beans from the
>>> java.desktop module.
>>>
>>> At a minimum this would need a CSR specifying this additional
>>> requirement that the app must depend on java.desktop in order to use the
>>> JavaFX beans property adapter classes.
>>>
>>> If others think this is useful, we could consider this for JavaFX 23.
>>>
>>> -- Kevin
>>>
>>> On 11/18/2023 6:16 AM, Kevin Rushforth wrote:
>>>
>>> Perhaps the module can be declared 'requires static'.
>>>
>>>
>>> That was my thinking as well, which is captured in
>>> https://bugs.openjdk.org/browse/JDK-8240844
>>>
>>> Perhaps this is the right time to move this forward?
>>>
>>> -- Kevin
>>>
>>>
>>> On 11/17/2023 4:06 PM, Nir Lisker wrote:
>>>
>>> Hi,
>>>
>>> A previous discussion mentioned the removal of AWT dependencies. One of
>>> the points that Kevin brought up was
>>>
>>>
>>>>  Refactor Java Beans implementation in javafx.base such that
>>>> java.desktop is optional
>>>
>>>
>>> John and I looked at this some time ago when we discussed the usage of
>>> the javafx base module outside of JavaFX, as its observables/binding
>>> capabilities are suitable for non-GUI applications, which currently have to
>>> pull in GUI modules as dependencies.
>>>
>>> The dependency is used in the property.adapter packages that bridge
>>> javafx.base properties with Java Beans. I think that these classes are
>>> seldom used.
>>>
>>> What could be a way to deal with that dependency? Perhaps the module can
>>> be declared 'requires static'. Or extract the adapter packages into a
>>> different "interop" module (javafx.javabeans) like javafx.swing?
>>>
>>> - Nir
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251105/36aba083/attachment-0001.htm>

From lkostyra at openjdk.org  Wed Nov  5 11:19:22 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 5 Nov 2025 11:19:22 GMT
Subject: RFR: 8368629: Texture.update sometimes invoked for a disposed
 Texture [v5]
In-Reply-To: <b6V3zXUmO4RZ2F0vnt_spUBBY8m_-YBsUrYFnke0xOM=.b6cab202-da18-479c-8fa4-86364cba4ccf@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>
 <b6V3zXUmO4RZ2F0vnt_spUBBY8m_-YBsUrYFnke0xOM=.b6cab202-da18-479c-8fa4-86364cba4ccf@github.com>
Message-ID: <0l75Ntsh97_SK7jLWg-Y1N0ajkvlh-SAbwSPww-ugWA=.cba522ac-51b3-4bfc-88bb-4ef8a162fc65@github.com>

On Wed, 5 Nov 2025 08:47:47 GMT, Alessadro Parisi <duke at openjdk.org> wrote:

> I was finally able to compile JavaFX with this PR and integrate it into my maven project. This does not seem to fix my issue entirely. While I don't see expections like these anymore: `NullPointerException: Cannot invoke "com.sun.prism.RTTexture.createGraphics()" because <local9> is null` I now see this: `java.lang.NullPointerException: Cannot invoke "com.sun.prism.RTTexture.createGraphics()" because "newtex" is null` or this `java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.assertLocked()" because "this.maskTex" is null` and the app still freezes
> 
> Is this related or an entirely different issue?

Hard to judge just from those messages, but it is possible the root cause is similar. The check I added is only in one place and it might not cover all cases. Can you provide a full stacktrace for each of those NPEs?

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3490623326

From duke at openjdk.org  Wed Nov  5 11:28:21 2025
From: duke at openjdk.org (Alessadro Parisi)
Date: Wed, 5 Nov 2025 11:28:21 GMT
Subject: RFR: 8368629: Texture.update sometimes invoked for a disposed
 Texture [v5]
In-Reply-To: <0l75Ntsh97_SK7jLWg-Y1N0ajkvlh-SAbwSPww-ugWA=.cba522ac-51b3-4bfc-88bb-4ef8a162fc65@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>
 <b6V3zXUmO4RZ2F0vnt_spUBBY8m_-YBsUrYFnke0xOM=.b6cab202-da18-479c-8fa4-86364cba4ccf@github.com>
 <0l75Ntsh97_SK7jLWg-Y1N0ajkvlh-SAbwSPww-ugWA=.cba522ac-51b3-4bfc-88bb-4ef8a162fc65@github.com>
Message-ID: <7qwmtaXylAWHTzLvKlwbhjS0j8RU7k9QYjVLz7gFlMQ=.c8b5523a-d194-4e52-b737-15db53d8ce62@github.com>

On Wed, 5 Nov 2025 11:16:28 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> Hard to judge just from those messages, but it is possible the root cause is similar. The check I added is only in one place and it might not cover all cases. Can you provide a full stacktrace for each of those NPEs?

Sure thing, here are the full stack traces:
<details>
<summary><code>createGraphics()</code> exception</summary>
<pre>
java.lang.NullPointerException: Cannot invoke "com.sun.prism.RTTexture.createGraphics()" because "newtex" is null
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGCanvas$RenderBuf.validate(NGCanvas.java:216)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGCanvas.initCanvas(NGCanvas.java:646)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGCanvas.renderContent(NGCanvas.java:609)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2057)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NodeEffectInput.getImageDataForBoundedNode(NodeEffectInput.java:237)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NodeEffectInput.filter(NodeEffectInput.java:131)
	at javafx.graphics at 26-internal/com.sun.scenario.effect.FilterEffect.filter(FilterEffect.java:185)
	at javafx.graphics at 26-internal/com.sun.scenario.effect.Offset.filter(Offset.java:160)
	at javafx.graphics at 26-internal/com.sun.scenario.effect.Merge.filter(Merge.java:148)
	at javafx.graphics at 26-internal/com.sun.scenario.effect.DelegateEffect.filter(DelegateEffect.java:70)
	at javafx.graphics at 26-internal/com.sun.scenario.effect.impl.prism.PrEffectHelper.render(PrEffectHelper.java:166)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.EffectFilter.render(EffectFilter.java:61)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderEffect(NGNode.java:2350)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2060)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2057)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:481)
	at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:321)
	at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
	at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:369)
	at javafx.graphics at 26-internal/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
	at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:122)
	at java.base/java.lang.Thread.run(Thread.java:1474)
</pre>
</details>

<details>
<summary><code>assertLocked()</code> exception</summary>
<pre>
java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.assertLocked()" because "this.maskTex" is null
	at javafx.graphics at 26-internal/com.sun.prism.impl.BaseContext.updateMaskTexture(BaseContext.java:271)
	at javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.renderShape(BaseShaderGraphics.java:506)
	at javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.fill(BaseGraphics.java:424)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderBackgroundShape(NGRegion.java:710)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderAsShape(NGRegion.java:662)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:573)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderOpacity(NGNode.java:2323)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2051)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NodeEffectInput.getImageDataForBoundedNode(NodeEffectInput.java:237)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NodeEffectInput.filter(NodeEffectInput.java:131)
	at javafx.graphics at 26-internal/com.sun.scenario.effect.FilterEffect.filter(FilterEffect.java:185)
	at javafx.graphics at 26-internal/com.sun.scenario.effect.Offset.filter(Offset.java:160)
	at javafx.graphics at 26-internal/com.sun.scenario.effect.Merge.filter(Merge.java:148)
	at javafx.graphics at 26-internal/com.sun.scenario.effect.DelegateEffect.filter(DelegateEffect.java:70)
	at javafx.graphics at 26-internal/com.sun.scenario.effect.impl.prism.PrEffectHelper.render(PrEffectHelper.java:166)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.EffectFilter.render(EffectFilter.java:61)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderEffect(NGNode.java:2350)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2060)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2057)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:481)
	at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:321)
	at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
	at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:369)
	at javafx.graphics at 26-internal/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
	at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:122)
	at java.base/java.lang.Thread.run(Thread.java:1474)
</pre>
</details>

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3490661072

From kcr at openjdk.org  Wed Nov  5 11:41:37 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 11:41:37 GMT
Subject: RFR: 8370912: Formatting error on JavaDoc because of missing
 quotation mark
In-Reply-To: <MQ5AnuGP-p1SM5q8yQzo9kQfXBbImrbTHqapltVbmvU=.1558ef5f-d1c1-498a-8aff-b2501977e24f@github.com>
References: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
 <MQ5AnuGP-p1SM5q8yQzo9kQfXBbImrbTHqapltVbmvU=.1558ef5f-d1c1-498a-8aff-b2501977e24f@github.com>
Message-ID: <AfqHTuyqiWFCgjIuZkdVV9it18ibj6CZu_9RoF0XswU=.87d31c8a-ad6e-47fa-aad0-9dff74f8404b@github.com>

On Wed, 5 Nov 2025 09:15:22 GMT, iso53 <duke at openjdk.org> wrote:

> Actions is already enabled.

You must have enabled them after you pushed to your branch. Double-check that they are enabled, and then either manually trigger a GHA run or else push an empty commit (`git commit --allow-empty -m empty; git push`) to your branch.

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

PR Comment: https://git.openjdk.org/jfx/pull/1956#issuecomment-3490716549

From kcr at openjdk.org  Wed Nov  5 11:47:33 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 11:47:33 GMT
Subject: RFR: 8371052: Update libFFI to 3.5.2
In-Reply-To: <EihmQlWsI1W2GLW_YDC8pOUhxQnzSfn4W5q1NvH2euM=.d769fa13-8113-43d1-8c37-1fcd849f653d@github.com>
References: <EihmQlWsI1W2GLW_YDC8pOUhxQnzSfn4W5q1NvH2euM=.d769fa13-8113-43d1-8c37-1fcd849f653d@github.com>
Message-ID: <T-BKrPPWEO37zeo5R_yA6lUx5mTk3kR46OViNtLXd5o=.1bb17a7a-5f46-4074-b0d7-5eb105ad975a@github.com>

On Wed, 5 Nov 2025 02:17:39 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Updated libFFI to 3.5.2.
> - Tested on all platforms.
> - No additional changes are done.

Reviewers: @arapte @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1962#issuecomment-3490750159

From jpereda at openjdk.org  Wed Nov  5 11:50:44 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Wed, 5 Nov 2025 11:50:44 GMT
Subject: RFR: 8371302: [Windows] Stage coordinates in secondary display are not
 properly updated after changing settings of first display
Message-ID: <CR0CQX9O56oytMISf8D6Bdsnt9U0uPBr0NMsQPIv5Ls=.1be06b8c-8f09-44d9-ba74-39a7feee7db9@github.com>

This PR handles two windows events, `WM_DISPLAYCHANGE` and `WM_SETTINGCHANGE`, that can be received by a JavaFX Window on a given display when other display changed its settings (resolution), or both displays were rearranged, and therefore its location has changed. 

When this happens, `com.sun.glass.ui.Window` has the new updated location, but the `javafx.stage.Window` does not, and triggering a `Window.MOVE` event notifies the stage to update its location accordingly.

There are no tests added to this PR (those would require two monitors, and external changes of Windows Settings), but the [test](https://bugs.openjdk.org/secure/attachment/116917/RenderScaleTest.java) attached to the JBS issue passes after this PR running some manual tests: for the stage at secondary display, check that the location is updated properly and the context menu shows up at the expected position, when the primary display resolution changes via Settings->System->Display->Scale, or when both displays are rearranged via Settings->System->Display->Drag to rearrange.

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

Commit messages:
 - Notify stage to update its location after display or settings changed

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

PR: https://git.openjdk.org/jfx/pull/1963

From duke at openjdk.org  Wed Nov  5 12:17:07 2025
From: duke at openjdk.org (iso53)
Date: Wed, 5 Nov 2025 12:17:07 GMT
Subject: RFR: 8370912: Formatting error on JavaDoc because of missing
 quotation mark [v2]
In-Reply-To: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
References: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
Message-ID: <kReW9CXZ90A9L4CJmvb1Bik88nNISVs6gXfp87ZOoWA=.388dd655-ba40-4cd1-b956-619da9f4561b@github.com>

> Corrected a missing closing quote in the HBox JavaDoc example, ensuring it's properly formatted.

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

  empty commit to trigger GHA

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1956/files
  - new: https://git.openjdk.org/jfx/pull/1956/files/418d4767..f69e5e58

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

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

PR: https://git.openjdk.org/jfx/pull/1956

From jpereda at openjdk.org  Wed Nov  5 12:37:41 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Wed, 5 Nov 2025 12:37:41 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI changes
Message-ID: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>

This PR adds the missing native implementation for Windows, `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running, in a similar way as Java Desktop [handles](https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L1418) this DPI event.

When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well.

The change in `Screen:: notifySettingsChanged` is needed in order to prevent disposing screens that are not referenced by windows, and only do it when the screen instance of a given window does change.

There are no tests added to this PR, since these would require manual intervention to change the resolution of the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. It has also been tested that it doesn't have any side effect on macOS.

For the case when the app runs on a different display that the one that was changed, see https://bugs.openjdk.org/browse/JDK-8371302 and a possible fix with https://github.com/openjdk/jfx/pull/1963.

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

Commit messages:
 - Notify window and screen when dpi changes, dispose screens only when windows replace them

Changes: https://git.openjdk.org/jfx/pull/1964/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1964&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346281
  Stats: 28 lines in 2 files changed: 21 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1964.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1964/head:pull/1964

PR: https://git.openjdk.org/jfx/pull/1964

From kcr at openjdk.org  Wed Nov  5 12:42:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 12:42:43 GMT
Subject: RFR: 8370912: Formatting error on JavaDoc because of missing
 quotation mark
In-Reply-To: <MQ5AnuGP-p1SM5q8yQzo9kQfXBbImrbTHqapltVbmvU=.1558ef5f-d1c1-498a-8aff-b2501977e24f@github.com>
References: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
 <MQ5AnuGP-p1SM5q8yQzo9kQfXBbImrbTHqapltVbmvU=.1558ef5f-d1c1-498a-8aff-b2501977e24f@github.com>
Message-ID: <qzwuMCn-q60TTJ7K7KtU9f0YCSUuRbAazhX-hNKLT0Y=.a6ef83bb-74bc-4a3a-8904-0b86b42f6f71@github.com>

On Wed, 5 Nov 2025 09:15:22 GMT, iso53 <duke at openjdk.org> wrote:

>> Corrected a missing closing quote in the HBox JavaDoc example, ensuring it's properly formatted.
>
> Changed the PR title. Actions is already enabled.

@ISO53 Are you sure you have enabled GHA for your repo? To check, go to https://github.com/ISO53/jfx/actions in your browser. If you see a green button to enable workflows with a message similar to "I understand, enable workflows", press the green button. Then you will need to either manually rerun or push another empty commit.

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

PR Comment: https://git.openjdk.org/jfx/pull/1956#issuecomment-3491003492

From kcr at openjdk.org  Wed Nov  5 12:49:28 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 12:49:28 GMT
Subject: RFR: 8371128: NullPointerException occurs due to double cleanup of
 SwingNode [v2]
In-Reply-To: <llOy87_TBSeyU4P1pPP6jy5OBbzqu7mSf4fPYH-QOJk=.819b08dc-4035-4f06-ad14-8e342903231f@github.com>
References: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
 <h8fUjVkYPIOgvlMYj3H1_F6gMgP_Vsak2g4P1ndb9sE=.631b9529-17f8-4a3a-ac6a-037df3374a60@github.com>
 <tTcG73QheIC7iQ4XsbditA5LIR9C_gZCUWAOaT14y0M=.02f275f8-0a37-457a-9125-5099f5f7a247@github.com>
 <tUMzPRgd89uQADSj_vcU480sCeXmxFShLoFl0wINX2M=.decba1f2-8693-495d-aa30-01aea4f87430@github.com>
 <8tIzBYY8xC50iujDytfb2utmLHJU9LfFTO7N0Hyjzjw=.497d14bd-c226-4911-a1eb-4b872e079112@github.com>
 <7dJzoMhEzKCafPO065FLCT63aH_qpMHoJ2beIlTbOYY=.0a23a74f-3f2e-40fa-af33-a923f28fc9a0@github.com>
 <llOy87_TBSeyU4P1pPP6jy5OBbzqu7mSf4fPYH-QOJk=.819b08dc-4035-4f06-ad14-8e342903231f@github.com>
Message-ID: <4WfTwEoQWC5Nc6Bs6w-ghx_si8OoiuPyNzwptrbm6GM=.4833f3ed-eb79-427a-8024-63b302d6980f@github.com>

On Wed, 5 Nov 2025 03:01:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Good catch. Other than being another possible source of an NPE, that one seems unrelated, so might be better handled as a follow-up. This one isn't a threading issue whereas the one you pointed out is.
>> 
>> @prsadhuk Can you at least take a look at it and see whether there is any relation to the bug you are fixing? If not, let's file a follow-up bug. The fix is to also check for null on the EDT before calling createUngrabEvent (as is done in disposeLwFrame -- even if you test lwFrame for null in the FX thread (to short-circuit creating the call on the EDT), you still need to check before use once you actually are on the EDT.
>
> I don't quite understand..In 
> 
> 
> private final EventHandler<FocusUngrabEvent> ungrabHandler = event -> {
>     556         if (!skipBackwardUnrgabNotification) {
>     557             if (lwFrame != null) {
>     558                 postAWTEvent(
>     559                     swNodeIOP.createUngrabEvent(lwFrame));
>     560             }
>     561         }
>     562     };
> 
> we are checking for null lwFrame in FX thread and there's no thread switching so how can we have again null lwFrame?
> In disposeLwFrame, we are checking for null lwFrame inside `SwingNodeHelper.runOnEDT` due to context switch but here no such thing is happening and is running in same thread, so I am not sure why and where to `check for null on the EDT before calling createUngrabEvent`

@prsadhuk You are correct. There is no thread switching in that block (it's all on the FX app thread, which creates an event and then sends that created event to the EDT).

Go ahead and integrate this PR.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1960#discussion_r2494323128

From psadhukhan at openjdk.org  Wed Nov  5 12:54:43 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 5 Nov 2025 12:54:43 GMT
Subject: Integrated: 8371128: NullPointerException occurs due to double cleanup
 of SwingNode
In-Reply-To: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
References: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
Message-ID: <9bQSY0pn8mHzft7Qic_dFhOdjLjuhUWVoz7NhiZzmK8=.93c69282-3eae-4554-81d2-e73c466e2718@github.com>

On Tue, 4 Nov 2025 09:06:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is seen that when we close the SwingNode window while we have registered a WINDOW_HIDDEN listener, it will cause a NPE 
> This is because WINDOW_HIDDEN listener called `SwingNode.overrideNativeWindowHandle` to provide a native FX window handle to AWT/Swing via JNI code, which gives provision to AWT/Swing code in sun/swing/JLightweightFrame.java#overrideNativeWindowHandle to handle the window closing
> 
> https://github.com/openjdk/jdk/blob/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/src/java.desktop/share/classes/sun/swing/JLightweightFrame.java#L527-L534
> 
> But if window is closed, then the node is removed from scene and `SwingNode.disposeLwFrame` is called which nulls "lwFrame" which is the handle for JLightweightFrame AWT frame, so when JNI code 
> https://github.com/openjdk/jfx/blob/c77c2335856a967907aaacc9546f44943c069add/modules/javafx.graphics/src/main/native-prism/SwingInterop.c#L47
> 
> tries to call JLightweightFrame, it crashes.
> Fix is made to check for `lwFrame `before `overrideNativeWindowHandle ` is called inside `SwingNodeHelper.runOnEDT`. 
> This is common practice employed inside `SwingNodeHelper.runOnEDT` to check for lwFrame to be not null

This pull request has now been integrated.

Changeset: c9b74a80
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/c9b74a80e76c03b0a3df698e6ba5c1ea239b32ad
Stats:     104 lines in 2 files changed: 101 ins; 0 del; 3 mod

8371128: NullPointerException occurs due to double cleanup of SwingNode

Reviewed-by: kcr

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

PR: https://git.openjdk.org/jfx/pull/1960

From duke at openjdk.org  Wed Nov  5 12:55:34 2025
From: duke at openjdk.org (iso53)
Date: Wed, 5 Nov 2025 12:55:34 GMT
Subject: RFR: 8370912: Formatting error on JavaDoc because of missing
 quotation mark [v2]
In-Reply-To: <kReW9CXZ90A9L4CJmvb1Bik88nNISVs6gXfp87ZOoWA=.388dd655-ba40-4cd1-b956-619da9f4561b@github.com>
References: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
 <kReW9CXZ90A9L4CJmvb1Bik88nNISVs6gXfp87ZOoWA=.388dd655-ba40-4cd1-b956-619da9f4561b@github.com>
Message-ID: <DVHUy0obCNqZcDOhJ5VewSvqp9JdD3JirRjZsATqdpY=.5b76d345-bfdf-4fe7-bee2-e3fc50f0db4a@github.com>

On Wed, 5 Nov 2025 12:17:07 GMT, iso53 <duke at openjdk.org> wrote:

>> Corrected a missing closing quote in the HBox JavaDoc example, ensuring it's properly formatted.
>
> iso53 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit to trigger GHA

Ok, my bad. Now it runs the tests.

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

PR Comment: https://git.openjdk.org/jfx/pull/1956#issuecomment-3491050935

From mhanl at openjdk.org  Wed Nov  5 13:54:38 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 5 Nov 2025 13:54:38 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes
In-Reply-To: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
Message-ID: <MorKUsTSgxPY4sO2mu7nfVYYSn_60u03QdaTZ_YAhFo=.4d8e9009-034b-4585-90ae-c977cea5a035@github.com>

On Wed, 5 Nov 2025 12:32:09 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds the missing native implementation for Windows, `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running, in a similar way as Java Desktop [handles](https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L1418) this DPI event.
> 
> When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well.
> 
> The change in `Screen:: notifySettingsChanged` is needed in order to prevent disposing screens that are not referenced by windows, and only do it when the screen instance of a given window does change.
> 
> There are no tests added to this PR, since these would require manual intervention to change the resolution of the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. It has also been tested that it doesn't have any side effect on macOS.
> 
> For the case when the app runs on a different display that the one that was changed, see https://bugs.openjdk.org/browse/JDK-8371302 and a possible fix with https://github.com/openjdk/jfx/pull/1963.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/Screen.java line 374:

> 372:     public static void notifySettingsChanged() {
> 373:         // Save the old screens in order to dispose them later
> 374:         List<Screen> oldScreens = new ArrayList<>();

This could also be a `Set`, which then handles duplicates without the need for `contains`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2494605717

From kcr at openjdk.org  Wed Nov  5 14:06:12 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 14:06:12 GMT
Subject: RFR: 8370912: Formatting error on JavaDoc because of missing
 quotation mark [v2]
In-Reply-To: <kReW9CXZ90A9L4CJmvb1Bik88nNISVs6gXfp87ZOoWA=.388dd655-ba40-4cd1-b956-619da9f4561b@github.com>
References: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
 <kReW9CXZ90A9L4CJmvb1Bik88nNISVs6gXfp87ZOoWA=.388dd655-ba40-4cd1-b956-619da9f4561b@github.com>
Message-ID: <kskZ2uZZHhIwNUZzDFs_LFiHs95_Vc38m8VuBcOaYZs=.ac201eb6-dbe1-4fe5-bfd0-062324ae1c82@github.com>

On Wed, 5 Nov 2025 12:17:07 GMT, iso53 <duke at openjdk.org> wrote:

>> Corrected a missing closing quote in the HBox JavaDoc example, ensuring it's properly formatted.
>
> iso53 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit to trigger GHA

Looks good. Thanks for fixing it.

Since this is a trivial doc-only fix, a single review is sufficient. You may integrate this PR when ready.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1956#pullrequestreview-3422265527

From kcr at openjdk.org  Wed Nov  5 14:15:22 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 14:15:22 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes
In-Reply-To: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
Message-ID: <dwe23q-pl8ocW3YiQ4h2ddBNunv0DEUHYQ3kgP9S0YQ=.cea75688-2345-43ae-9547-875ec91b6c0f@github.com>

On Wed, 5 Nov 2025 12:32:09 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds the missing native implementation for Windows, `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running, in a similar way as Java Desktop [handles](https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L1418) this DPI event.
> 
> When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well.
> 
> The change in `Screen:: notifySettingsChanged` is needed in order to prevent disposing screens that are not referenced by windows, and only do it when the screen instance of a given window does change.
> 
> There are no tests added to this PR, since these would require manual intervention to change the resolution of the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. It has also been tested that it doesn't have any side effect on macOS.
> 
> For the case when the app runs on a different display that the one that was changed, see https://bugs.openjdk.org/browse/JDK-8371302 and a possible fix with https://github.com/openjdk/jfx/pull/1963.

I'd like to review and test this, both in isolation and in connection with #1963

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

PR Comment: https://git.openjdk.org/jfx/pull/1964#issuecomment-3491445090

From kcr at openjdk.org  Wed Nov  5 14:16:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 14:16:27 GMT
Subject: RFR: 8371302: [Windows] Stage coordinates in secondary display are
 not properly updated after changing settings of first display
In-Reply-To: <CR0CQX9O56oytMISf8D6Bdsnt9U0uPBr0NMsQPIv5Ls=.1be06b8c-8f09-44d9-ba74-39a7feee7db9@github.com>
References: <CR0CQX9O56oytMISf8D6Bdsnt9U0uPBr0NMsQPIv5Ls=.1be06b8c-8f09-44d9-ba74-39a7feee7db9@github.com>
Message-ID: <bIkbLfvuHXNRvzPrtTjTHKWPNfaYInAtw9CROWJu5_8=.8cc59990-c69e-4828-aa39-7ccba53fda17@github.com>

On Wed, 5 Nov 2025 11:44:40 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR handles two windows events, `WM_DISPLAYCHANGE` and `WM_SETTINGCHANGE`, that can be received by a JavaFX Window on a given display when other display changed its settings (resolution), or both displays were rearranged, and therefore its location has changed. 
> 
> When this happens, `com.sun.glass.ui.Window` has the new updated location, but the `javafx.stage.Window` does not, and triggering a `Window.MOVE` event notifies the stage to update its location accordingly.
> 
> There are no tests added to this PR (those would require two monitors, and external changes of Windows Settings), but the [test](https://bugs.openjdk.org/secure/attachment/116917/RenderScaleTest.java) attached to the JBS issue passes after this PR running some manual tests: for the stage at secondary display, check that the location is updated properly and the context menu shows up at the expected position, when the primary display resolution changes via Settings->System->Display->Scale, or when both displays are rearranged via Settings->System->Display->Drag to rearrange.

I'd like to review and test this, both in isolation and in connection with #1964

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

PR Comment: https://git.openjdk.org/jfx/pull/1963#issuecomment-3491446809

From duke at openjdk.org  Wed Nov  5 14:24:53 2025
From: duke at openjdk.org (duke)
Date: Wed, 5 Nov 2025 14:24:53 GMT
Subject: RFR: 8370912: Formatting error on JavaDoc because of missing
 quotation mark [v2]
In-Reply-To: <kReW9CXZ90A9L4CJmvb1Bik88nNISVs6gXfp87ZOoWA=.388dd655-ba40-4cd1-b956-619da9f4561b@github.com>
References: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
 <kReW9CXZ90A9L4CJmvb1Bik88nNISVs6gXfp87ZOoWA=.388dd655-ba40-4cd1-b956-619da9f4561b@github.com>
Message-ID: <ao7Zm1N70m_Kzdpy1PXa9iK7QMHGbwZStpCI00sPfxY=.59a040c0-bda2-45c5-bb04-211d3d4b4a32@github.com>

On Wed, 5 Nov 2025 12:17:07 GMT, iso53 <duke at openjdk.org> wrote:

>> Corrected a missing closing quote in the HBox JavaDoc example, ensuring it's properly formatted.
>
> iso53 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit to trigger GHA

@ISO53 
Your change (at version f69e5e58cca75c8545e4478103b70a9f600a9d0a) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1956#issuecomment-3491492248

From duke at openjdk.org  Wed Nov  5 15:15:15 2025
From: duke at openjdk.org (iso53)
Date: Wed, 5 Nov 2025 15:15:15 GMT
Subject: Integrated: 8370912: Formatting error on JavaDoc because of missing
 quotation mark
In-Reply-To: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
References: <G38bU9kDJqPoSNXtWzgbRR9JpawI0flchSErFzK4jts=.36953d47-3d06-4d8e-875e-b272c3a4cf1c@github.com>
Message-ID: <DdhbvcnxxduOv9wkxjrwkHRC7-zWMZSS4hmqkh1EDmM=.349caa1b-e07a-4645-9c62-61ad0cc45bcc@github.com>

On Thu, 30 Oct 2025 07:39:11 GMT, iso53 <duke at openjdk.org> wrote:

> Corrected a missing closing quote in the HBox JavaDoc example, ensuring it's properly formatted.

This pull request has now been integrated.

Changeset: 11cff5d6
Author:    iso53 <102249575+ISO53 at users.noreply.github.com>
Committer: Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/11cff5d686f2e9d55737b3a0ed89efa2a0cabe2a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8370912: Formatting error on JavaDoc because of missing quotation mark

Reviewed-by: kcr

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

PR: https://git.openjdk.org/jfx/pull/1956

From angorya at openjdk.org  Wed Nov  5 15:28:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Nov 2025 15:28:15 GMT
Subject: RFR: 8371128: NullPointerException occurs due to double cleanup of
 SwingNode [v2]
In-Reply-To: <4WfTwEoQWC5Nc6Bs6w-ghx_si8OoiuPyNzwptrbm6GM=.4833f3ed-eb79-427a-8024-63b302d6980f@github.com>
References: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
 <h8fUjVkYPIOgvlMYj3H1_F6gMgP_Vsak2g4P1ndb9sE=.631b9529-17f8-4a3a-ac6a-037df3374a60@github.com>
 <tTcG73QheIC7iQ4XsbditA5LIR9C_gZCUWAOaT14y0M=.02f275f8-0a37-457a-9125-5099f5f7a247@github.com>
 <tUMzPRgd89uQADSj_vcU480sCeXmxFShLoFl0wINX2M=.decba1f2-8693-495d-aa30-01aea4f87430@github.com>
 <8tIzBYY8xC50iujDytfb2utmLHJU9LfFTO7N0Hyjzjw=.497d14bd-c226-4911-a1eb-4b872e079112@github.com>
 <7dJzoMhEzKCafPO065FLCT63aH_qpMHoJ2beIlTbOYY=.0a23a74f-3f2e-40fa-af33-a923f28fc9a0@github.com>
 <llOy87_TBSeyU4P1pPP6jy5OBbzqu7mSf4fPYH-QOJk=.819b08dc-4035-4f06-ad14-8e342903231f@github.com>
 <4WfTwEoQWC5Nc6Bs6w-ghx_si8OoiuPyNzwptrbm6GM=.4833f3ed-eb79-427a-8024-63b302d6980f@github.com>
Message-ID: <OS4ZsZdWmG5UqAYBLkBOv4_AToJr4F5vRB7r4dE1vWs=.b9906583-5dc3-4486-a3ba-0fcf6f411c97@github.com>

On Wed, 5 Nov 2025 12:46:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I don't quite understand..In 
>> 
>> 
>> private final EventHandler<FocusUngrabEvent> ungrabHandler = event -> {
>>     556         if (!skipBackwardUnrgabNotification) {
>>     557             if (lwFrame != null) {
>>     558                 postAWTEvent(
>>     559                     swNodeIOP.createUngrabEvent(lwFrame));
>>     560             }
>>     561         }
>>     562     };
>> 
>> we are checking for null lwFrame in FX thread and there's no thread switching so how can we have again null lwFrame?
>> In disposeLwFrame, we are checking for null lwFrame inside `SwingNodeHelper.runOnEDT` due to context switch but here no such thing is happening and is running in same thread, so I am not sure why and where to `check for null on the EDT before calling createUngrabEvent`
>
> @prsadhuk You are correct. There is no thread switching in that block (it's all on the FX app thread, which creates an event and then sends that created event to the EDT).
> 
> Go ahead and integrate this PR.

yes, the block is on the fx thread, but the value of lwFrame is modified on the EDT.
Instead of this code where check and use happens with the volatile lwFrame, it should instead get the value into a temp variable and use that.


var lw = lwFrame;
if(lw != null) {
  use(lw)
}


here is the scenario, the way I see it:

swing       fx
not null
            L557, not null
            (context switch)
sets to null
(context switch)
            L559, null


unlikely, but possible, I think.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1960#discussion_r2495058308

From jhendrikx at openjdk.org  Wed Nov  5 15:29:21 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 5 Nov 2025 15:29:21 GMT
Subject: RFR: 8368629: Texture.update sometimes invoked for a disposed
 Texture [v5]
In-Reply-To: <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>
Message-ID: <iqVOPTQ86Bg0_rvXixkvWEJXEALwql4B1zNErVQr6CQ=.f92c7ad4-b64c-4d49-8e65-ce26c5fe24a5@github.com>

On Tue, 4 Nov 2025 14:49:56 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments - MTLTexture: add isValid() check to update(MediaFrame)

For me it was much better, but when I now go to further extremes (more windows open with images) eventually it does throw NPE's again.  I didn't manage to get a stack trace yet (they got reduced to a single line by the VM and my logs ran out), but will add here once I do.

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3491888754

From kcr at openjdk.org  Wed Nov  5 15:51:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 15:51:19 GMT
Subject: RFR: 8371128: NullPointerException occurs due to double cleanup of
 SwingNode [v2]
In-Reply-To: <OS4ZsZdWmG5UqAYBLkBOv4_AToJr4F5vRB7r4dE1vWs=.b9906583-5dc3-4486-a3ba-0fcf6f411c97@github.com>
References: <KeiZmszl4F1G2tPfk533rrHtNhPVFhDpT0htbg8tfJk=.00148503-3aab-4d35-869e-df88882fbca8@github.com>
 <h8fUjVkYPIOgvlMYj3H1_F6gMgP_Vsak2g4P1ndb9sE=.631b9529-17f8-4a3a-ac6a-037df3374a60@github.com>
 <tTcG73QheIC7iQ4XsbditA5LIR9C_gZCUWAOaT14y0M=.02f275f8-0a37-457a-9125-5099f5f7a247@github.com>
 <tUMzPRgd89uQADSj_vcU480sCeXmxFShLoFl0wINX2M=.decba1f2-8693-495d-aa30-01aea4f87430@github.com>
 <8tIzBYY8xC50iujDytfb2utmLHJU9LfFTO7N0Hyjzjw=.497d14bd-c226-4911-a1eb-4b872e079112@github.com>
 <7dJzoMhEzKCafPO065FLCT63aH_qpMHoJ2beIlTbOYY=.0a23a74f-3f2e-40fa-af33-a923f28fc9a0@github.com>
 <llOy87_TBSeyU4P1pPP6jy5OBbzqu7mSf4fPYH-QOJk=.819b08dc-4035-4f06-ad14-8e342903231f@github.com>
 <4WfTwEoQWC5Nc6Bs6w-ghx_si8OoiuPyNzwptrbm6GM=.4833f3ed-eb79-427a-8024-63b302d6980f@github.com>
 <OS4ZsZdWmG5UqAYBLkBOv4_AToJr4F5vRB7r4dE1vWs=.b9906583-5dc3-4486-a3ba-0fcf6f411c97@github.com>
Message-ID: <ayR1n13SOo9c3DXKbQp5nref3ACsQ1_9cStIOp9bHtE=.0f14aff4-0e60-4af7-bf8b-70f298be1da5@github.com>

On Wed, 5 Nov 2025 15:25:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> @prsadhuk You are correct. There is no thread switching in that block (it's all on the FX app thread, which creates an event and then sends that created event to the EDT).
>> 
>> Go ahead and integrate this PR.
>
> yes, the block is on the fx thread, but the value of lwFrame is modified on the EDT.
> Instead of this code where check and use happens with the volatile lwFrame, it should instead get the value into a temp variable and use that.
> 
> 
> var lw = lwFrame;
> if(lw != null) {
>   use(lw)
> }
> 
> 
> here is the scenario, the way I see it:
> 
> swing       fx
> not null
>             L557, not null
>             (context switch)
> sets to null
> (context switch)
>             L559, null
> 
> 
> unlikely, but possible, I think.

Yes, the scenario you pointed out is possible -- it's different from the (more serious) issue that I was thinking it was. And the solution is exactly as you point out: store it in a temp variable rather than reading it twice since the value can change between successive reads.

@prsadhuk Please file a follow-up bug.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1960#discussion_r2495140272

From jhendrikx at openjdk.org  Wed Nov  5 16:19:36 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 5 Nov 2025 16:19:36 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v3]
In-Reply-To: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
Message-ID: <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com>

> This PR implements a new default method on `ObservableList` to be able to replace elements within a specified range.
> 
> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
> 
> The other alternative is to call `set` individually for each item, which results in many change notifications.
> 
> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
> 
> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.

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

  Add additional tests

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1937/files
  - new: https://git.openjdk.org/jfx/pull/1937/files/0b42426b..730ea77f

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

  Stats: 29 lines in 1 file changed: 28 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1937.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1937/head:pull/1937

PR: https://git.openjdk.org/jfx/pull/1937

From jhendrikx at openjdk.org  Wed Nov  5 16:19:39 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 5 Nov 2025 16:19:39 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v2]
In-Reply-To: <Q2BwedcY8YwXxEl12B8EVrAacrS4uFA_9q1kv7fb-rc=.64884b51-1bd2-4c8e-a1b4-4de1f140c44d@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <SUQ3uoL6zgtSTQzHnzd9pv5DbkeBmZUK8AcMz__By0c=.c2627d35-51c0-42bb-a8bf-f5a5cfbd9450@github.com>
 <Q2BwedcY8YwXxEl12B8EVrAacrS4uFA_9q1kv7fb-rc=.64884b51-1bd2-4c8e-a1b4-4de1f140c44d@github.com>
Message-ID: <nVPHSgaMQkksNVxEej52uMazhN-Y6Zhyf9nYRUhQVec=.542d3ef9-a752-4bb0-8d32-a47af3093e7a@github.com>

On Tue, 4 Nov 2025 21:56:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix test
>>  - Rename setAll to replaceRange and removed superfluous method
>
> modules/javafx.base/src/test/java/test/javafx/collections/ModifiableObservableListBaseTest.java line 94:
> 
>> 92:         @Test
>> 93:         void shouldReplaceElementsAtGivenRange() {
>> 94:             assertTrue(list.replaceRange(1, 3, List.of("B", "C", "D")));
> 
> Would additional tests be useful?
> 
> * Replace a sub-range in the middle (so both beginning and end are kept)
> * Replace a sub-range with fewer elements than are removed (the existing test checks the case of more elements added than removed)

Always hard to say where to end, I had full coverage I think, but I added the suggested extra tests anyway as coverage isn't everything.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1937#discussion_r2495228889

From kcr at openjdk.org  Wed Nov  5 17:37:15 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 17:37:15 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v3]
In-Reply-To: <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com>
Message-ID: <uDwDa03VR9PBeSpPcxhrip_76MPAZbBKTao104fEfz8=.1c876327-9a06-4e38-aac2-cf8ea91330ab@github.com>

On Wed, 5 Nov 2025 16:19:36 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR implements a new default method on `ObservableList` to be able to replace elements within a specified range.
>> 
>> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
>> 
>> The other alternative is to call `set` individually for each item, which results in many change notifications.
>> 
>> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
>> 
>> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add additional tests

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1937#pullrequestreview-3423503647

From kcr at openjdk.org  Wed Nov  5 17:37:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 17:37:18 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v2]
In-Reply-To: <nVPHSgaMQkksNVxEej52uMazhN-Y6Zhyf9nYRUhQVec=.542d3ef9-a752-4bb0-8d32-a47af3093e7a@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <SUQ3uoL6zgtSTQzHnzd9pv5DbkeBmZUK8AcMz__By0c=.c2627d35-51c0-42bb-a8bf-f5a5cfbd9450@github.com>
 <Q2BwedcY8YwXxEl12B8EVrAacrS4uFA_9q1kv7fb-rc=.64884b51-1bd2-4c8e-a1b4-4de1f140c44d@github.com>
 <nVPHSgaMQkksNVxEej52uMazhN-Y6Zhyf9nYRUhQVec=.542d3ef9-a752-4bb0-8d32-a47af3093e7a@github.com>
Message-ID: <1wzQvnwLqqt-UH_JJTJS6g-HlLFq9fglqClj_ILLFSY=.d7484f79-d455-4309-a100-1f79237cd7f8@github.com>

On Wed, 5 Nov 2025 16:16:43 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.base/src/test/java/test/javafx/collections/ModifiableObservableListBaseTest.java line 94:
>> 
>>> 92:         @Test
>>> 93:         void shouldReplaceElementsAtGivenRange() {
>>> 94:             assertTrue(list.replaceRange(1, 3, List.of("B", "C", "D")));
>> 
>> Would additional tests be useful?
>> 
>> * Replace a sub-range in the middle (so both beginning and end are kept)
>> * Replace a sub-range with fewer elements than are removed (the existing test checks the case of more elements added than removed)
>
> Always hard to say where to end, I had full coverage I think, but I added the suggested extra tests anyway as coverage isn't everything.

Yes, it is a judgment call in many cases. The new tests look good.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1937#discussion_r2495513464

From angorya at openjdk.org  Wed Nov  5 17:57:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Nov 2025 17:57:46 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v8]
In-Reply-To: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
Message-ID: <uHWyNA8qz-0StxVyOxj7sH2AzL856P-XSdsWoAU0u30=.9e9686b2-5139-49ed-a280-0517d476945c@github.com>

> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
> 
> The impacted areas are:
> - saving to plain text
> - copying to plain text
> - IME
> 
> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), and as a property in the `CodeArea`.
> 
> ### NOTES
> 
> - some dependency on #1938 , resolved.
> - reviewers may use the Monkey Tester with the `CodeArea.lineEnding` property enabled from this branch: https://github.com/andy-goryachev-oracle/MonkeyTest/tree/line.ending

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' into 8370140.line.separator
 - fixed tests
 - non-nullable
 - Merge branch 'master' into 8370140.line.separator
 - get text
 - Merge branch 'master' into 8370140.line.separator
 - since
 - Merge branch 'master' into 8370140.line.separator
 - Merge remote-tracking branch 'origin/master' into 8370140.line.separator
 - tests
 - ... and 1 more: https://git.openjdk.org/jfx/compare/11cff5d6...0cf0ed66

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

Changes: https://git.openjdk.org/jfx/pull/1944/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=07
  Stats: 296 lines in 13 files changed: 265 ins; 11 del; 20 mod
  Patch: https://git.openjdk.org/jfx/pull/1944.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1944/head:pull/1944

PR: https://git.openjdk.org/jfx/pull/1944

From angorya at openjdk.org  Wed Nov  5 18:14:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Nov 2025 18:14:51 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v9]
In-Reply-To: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
Message-ID: <_j3maM1FbJ0lif6lbh14jEH5Zmd2jxHFdhPufhvhFYY=.acb4af78-5554-4a5f-90f6-877d11b3672c@github.com>

> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
> 
> The impacted areas are:
> - saving to plain text
> - copying to plain text
> - IME
> 
> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), and as a property in the `CodeArea`.
> 
> ### NOTES
> 
> - some dependency on #1938 , resolved.
> - reviewers may use the Monkey Tester with the `CodeArea.lineEnding` property enabled from this branch: https://github.com/andy-goryachev-oracle/MonkeyTest/tree/line.ending

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

  code area test

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1944/files
  - new: https://git.openjdk.org/jfx/pull/1944/files/0cf0ed66..a27a4410

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

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

PR: https://git.openjdk.org/jfx/pull/1944

From kcr at openjdk.org  Wed Nov  5 18:34:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 18:34:44 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v3]
In-Reply-To: <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com>
Message-ID: <cFtwEDeZi_Mi8_SxCtfnbKzJRDiV-PRJwUgYIv6rB5Q=.5d3be645-6418-43f6-8cbc-bcbd8b19a47d@github.com>

On Wed, 5 Nov 2025 16:19:36 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR implements a new default method on `ObservableList` to be able to replace elements within a specified range.
>> 
>> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
>> 
>> The other alternative is to call `set` individually for each item, which results in many change notifications.
>> 
>> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
>> 
>> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add additional tests

A single re-review of the new tests should be sufficient.

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

PR Comment: https://git.openjdk.org/jfx/pull/1937#issuecomment-3492737124

From kcr at openjdk.org  Wed Nov  5 19:06:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 19:06:20 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v9]
In-Reply-To: <_j3maM1FbJ0lif6lbh14jEH5Zmd2jxHFdhPufhvhFYY=.acb4af78-5554-4a5f-90f6-877d11b3672c@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <_j3maM1FbJ0lif6lbh14jEH5Zmd2jxHFdhPufhvhFYY=.acb4af78-5554-4a5f-90f6-877d11b3672c@github.com>
Message-ID: <MNhjX8A-A6Qswh0jS5DcQGQMkJfBm-9C3YP6czV3PBw=.3f37f48f-82ac-49f4-a99f-afb37846b0e6@github.com>

On Wed, 5 Nov 2025 18:14:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
>> 
>> The impacted areas are:
>> - saving to plain text
>> - copying to plain text
>> - IME
>> 
>> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), and as a property in the `CodeArea`.
>> 
>> ### NOTES
>> 
>> - some dependency on #1938 , resolved.
>> - reviewers may use the Monkey Tester with the `CodeArea.lineEnding` property enabled from this branch: https://github.com/andy-goryachev-oracle/MonkeyTest/tree/line.ending
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code area test

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 472:

> 470:                 protected void invalidated() {
> 471:                     LineEnding v = get();
> 472:                     if(v == null) {

Minor: space after `if`

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 473:

> 471:                     LineEnding v = get();
> 472:                     if(v == null) {
> 473:                         set(old);

You also need to unbind if bound.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/LineEnding.java line 34:

> 32:  */
> 33: public enum LineEnding {
> 34:     /** Classic Mac OS line ending, ASCII CR (0x0d) */

I would say "Legacy" rather than "Classic", and maybe add a sentence that this was used on Mac systems prior to macOS 10.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/LineEnding.java line 37:

> 35:     CR,
> 36:     /** Windows line ending, ASCII LF (0x0a) */
> 37:     CRLF,

Can you add a `.` at the end of the sentence (here and for all the enums)?

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/LineEnding.java line 41:

> 39:     LF,
> 40:     /** Platform default line ending, using the value of {@code System.getProperty("line.separator")} */
> 41:     SYSTEM_DEFAULT;

or maybe just `SYSTEM`? Now that I look at it, I'm not sure we need the "DEFAULT" suffix (nor the word "default" in the description).

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledOutput.java line 59:

> 57:      */
> 58:     public static StyledOutput forPlainText() {
> 59:         return new StringBuilderStyledOutput(null);

Null is not allowed. Pass `LineEnding.SYSTEM_DEFAULT`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2495753140
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2495755365
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2495712433
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2495714570
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2495698978
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2495749183

From kcr at openjdk.org  Wed Nov  5 19:06:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 19:06:13 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v6]
In-Reply-To: <A8WW5po_t1eRA0z_YAFL7PMHXXwxOWtfaLttAefc1po=.e54c6724-3d9c-4e93-a6f4-db07df1fd23a@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <HzoV0_nTS4wT9sp6sp0GsdHr1MOPcOh-Jv_yx8y4hWA=.67710d5a-0169-4ce4-9c7b-b2b78573b73d@github.com>
 <amqwYWz3r23pO_2bkjFwY33vEQknAGmQDROnM_U1Z7c=.e7c864d0-5b51-4fbf-9441-4e9faae9559b@github.com>
 <A8WW5po_t1eRA0z_YAFL7PMHXXwxOWtfaLttAefc1po=.e54c6724-3d9c-4e93-a6f4-db07df1fd23a@github.com>
Message-ID: <Vt42mhzaA4KuMWQ4A9IoKyo4FAnOZQCxvjnMzKecekg=.a1445936-9f90-408c-b316-8895f32a902d@github.com>

On Wed, 5 Nov 2025 00:07:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 468:
>> 
>>> 466:      * @defaultValue null
>>> 467:      */
>>> 468:     public final ObjectProperty<LineEnding> lineEndingProperty() {
>> 
>> Shouldn't this be a property of RichTextArea?
>
> No, `RichTextArea` might have a model that has no concept of line ending, or has its own idea of line ending - that's why it's an attribute of the model rather than the property in the control.
> 
> `CodeArea`, on the other hand, deals with plain text as an underlying data, so line ending is a property of the control, just like `font` and `tabSize`.

Unlike `font` and `tabSize`, the `lineEnding` property is used when exporting to an external format where you want line endings, which also applies to RichTextArea. This is done implicitly by various operations (copy/paste/export) or explicitly when calling `getText`. I realize that `getText` is not currently a public method in `RichTextArea`, but I understand is likely to be proposed in the future. Once you add that method to the public API it will seem odd that users of CodeArea set the property in the control, but users of RichTextArea itself would need to set it in the model.

Do you still think it belongs in the `CodeArea` subclass? I suppose it can be moved to the superclass later, if needed (without breaking anything), but I at least want you to think through all the issues.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2495693335

From kcr at openjdk.org  Wed Nov  5 19:13:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 19:13:59 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v6]
In-Reply-To: <wxdqtmWy28rxfblDiX3aSwShuqF3k8FLx3bQL_d6_yQ=.ae07521c-a7ad-4de3-a3d4-9d3ac93fd3c0@github.com>
References: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
 <FOibqvmhc2kby5tOnY2lGj5POE8U8F2nFWm0ecD5l34=.7846c8be-6da9-41c3-9985-72c7ea371f20@github.com>
 <Ki8YuHdHva7XJG2bjebOhABSyCvfSazf5lBrzevYC7I=.297fab2c-fd16-41ae-958f-46a4cd13cc0d@github.com>
 <wxdqtmWy28rxfblDiX3aSwShuqF3k8FLx3bQL_d6_yQ=.ae07521c-a7ad-4de3-a3d4-9d3ac93fd3c0@github.com>
Message-ID: <x98r11J87rq7kuXWHhkFJ8vcBPr4KRVkoG7jY8OzcPk=.de749e8c-8acb-4b0e-b0d6-31c4cd3b89c6@github.com>

On Tue, 4 Nov 2025 21:50:38 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> tests/performance/control/src/table/TableRefreshTest.java line 77:
>> 
>>> 75:             refreshBtn.setOnAction(_ -> tv.refresh());
>>> 76:             Button recreateBtn = new Button("Recreate");
>>> 77:             recreateBtn.setOnAction(_ -> tv.getProperties().put("recreateKey", true));
>> 
>> Question: Can this be done with public API? It's OK as is, since it is a test, but I figured I'd ask.
>
> Note like this, but setting a new `TableRow` factory will essentially trigger and do the same:
> https://github.com/openjdk/jfx/blob/a4e5451373beed93942e0bf2b6c8b81d3e6ad66d/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableViewSkinBase.java#L331-L337

OK, thanks. I would leave the test as you have it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2495787816

From kcr at openjdk.org  Wed Nov  5 20:10:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 20:10:21 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v6]
In-Reply-To: <Vt42mhzaA4KuMWQ4A9IoKyo4FAnOZQCxvjnMzKecekg=.a1445936-9f90-408c-b316-8895f32a902d@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <HzoV0_nTS4wT9sp6sp0GsdHr1MOPcOh-Jv_yx8y4hWA=.67710d5a-0169-4ce4-9c7b-b2b78573b73d@github.com>
 <amqwYWz3r23pO_2bkjFwY33vEQknAGmQDROnM_U1Z7c=.e7c864d0-5b51-4fbf-9441-4e9faae9559b@github.com>
 <A8WW5po_t1eRA0z_YAFL7PMHXXwxOWtfaLttAefc1po=.e54c6724-3d9c-4e93-a6f4-db07df1fd23a@github.com>
 <Vt42mhzaA4KuMWQ4A9IoKyo4FAnOZQCxvjnMzKecekg=.a1445936-9f90-408c-b316-8895f32a902d@github.com>
Message-ID: <UhqX3UkMdLsXroqFfzGLoueAGLvRdOoZ_p5FfsH6ChM=.905b273f-e12b-4e87-91fc-f7ff1dc4eb41@github.com>

On Wed, 5 Nov 2025 18:38:01 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> No, `RichTextArea` might have a model that has no concept of line ending, or has its own idea of line ending - that's why it's an attribute of the model rather than the property in the control.
>> 
>> `CodeArea`, on the other hand, deals with plain text as an underlying data, so line ending is a property of the control, just like `font` and `tabSize`.
>
> Unlike `font` and `tabSize`, the `lineEnding` property is used when exporting to an external format where you want line endings, which also applies to RichTextArea. This is done implicitly by various operations (copy/paste/export) or explicitly when calling `getText`. I realize that `getText` is not currently a public method in `RichTextArea`, but I understand is likely to be proposed in the future. Once you add that method to the public API it will seem odd that users of CodeArea set the property in the control, but users of RichTextArea itself would need to set it in the model.
> 
> Do you still think it belongs in the `CodeArea` subclass? I suppose it can be moved to the superclass later, if needed (without breaking anything), but I at least want you to think through all the issues.

Actually, I thought of a bigger concern. Having a writable attribute in both the control and the model is not going to give coherent results in the case where you have more than one view on the same model. So you might need to rethink the idea of having a writable property on the view (the control) while also having state (via a writable attribute) on the model.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2495967579

From angorya at openjdk.org  Wed Nov  5 20:23:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Nov 2025 20:23:19 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v6]
In-Reply-To: <UhqX3UkMdLsXroqFfzGLoueAGLvRdOoZ_p5FfsH6ChM=.905b273f-e12b-4e87-91fc-f7ff1dc4eb41@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <HzoV0_nTS4wT9sp6sp0GsdHr1MOPcOh-Jv_yx8y4hWA=.67710d5a-0169-4ce4-9c7b-b2b78573b73d@github.com>
 <amqwYWz3r23pO_2bkjFwY33vEQknAGmQDROnM_U1Z7c=.e7c864d0-5b51-4fbf-9441-4e9faae9559b@github.com>
 <A8WW5po_t1eRA0z_YAFL7PMHXXwxOWtfaLttAefc1po=.e54c6724-3d9c-4e93-a6f4-db07df1fd23a@github.com>
 <Vt42mhzaA4KuMWQ4A9IoKyo4FAnOZQCxvjnMzKecekg=.a1445936-9f90-408c-b316-8895f32a902d@github.com>
 <UhqX3UkMdLsXroqFfzGLoueAGLvRdOoZ_p5FfsH6ChM=.905b273f-e12b-4e87-91fc-f7ff1dc4eb41@github.com>
Message-ID: <6EC_fe28eiJ4GZWWtnMyGukuitJdUi2ylm7lW6w8P2c=.076451e8-16c3-425d-b3dc-c60e6b985eff@github.com>

On Wed, 5 Nov 2025 20:08:01 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Unlike `font` and `tabSize`, the `lineEnding` property is used when exporting to an external format where you want line endings, which also applies to RichTextArea. This is done implicitly by various operations (copy/paste/export) or explicitly when calling `getText`. I realize that `getText` is not currently a public method in `RichTextArea`, but I understand is likely to be proposed in the future. Once you add that method to the public API it will seem odd that users of CodeArea set the property in the control, but users of RichTextArea itself would need to set it in the model.
>> 
>> Do you still think it belongs in the `CodeArea` subclass? I suppose it can be moved to the superclass later, if needed (without breaking anything), but I at least want you to think through all the issues.
>
> Actually, I thought of a bigger concern. Having a writable attribute in both the control and the model is not going to give coherent results in the case where you have more than one view on the same model. So you might need to rethink the idea of having a writable property on the view (the control) while also having state (via a writable attribute) on the model.

Good point!
What do you think we should do then?

I should probably move the setter and getter to the RichTextArea class then, and remove the property altogether.

Any custom UI can always create its own property for line ending and deal with the model directly.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2496008024

From angorya at openjdk.org  Wed Nov  5 20:33:48 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Nov 2025 20:33:48 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v10]
In-Reply-To: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
Message-ID: <zYJdFLkf-dRuQ0OhW2MoauoI90Vc1gHMDg7s4vakcqE=.b5578b3b-d091-48c8-85d4-f0531b1bf88a@github.com>

> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
> 
> The impacted areas are:
> - saving to plain text
> - copying to plain text
> - IME
> 
> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), and as a property in the `CodeArea`.
> 
> ### NOTES
> 
> - some dependency on #1938 , resolved.
> - reviewers may use the Monkey Tester with the `CodeArea.lineEnding` property enabled from this branch: https://github.com/andy-goryachev-oracle/MonkeyTest/tree/line.ending

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

  review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1944/files
  - new: https://git.openjdk.org/jfx/pull/1944/files/a27a4410..cfbc542d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=09
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=08-09

  Stats: 24 lines in 7 files changed: 4 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jfx/pull/1944.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1944/head:pull/1944

PR: https://git.openjdk.org/jfx/pull/1944

From angorya at openjdk.org  Wed Nov  5 21:00:37 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Nov 2025 21:00:37 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v11]
In-Reply-To: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
Message-ID: <mBHaheyq-KrBlvXhtIpMUx77mKqNxku7gdGkUMAcuzo=.63776f3f-23ae-4388-8f6a-27bf4170cd64@github.com>

> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
> 
> The impacted areas are:
> - saving to plain text
> - copying to plain text
> - IME
> 
> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), with convenience setter and getter in the `RichTextArea`.
> 
> ### NOTES
> 
> - some dependency on #1938 , resolved.

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

  removed property

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1944/files
  - new: https://git.openjdk.org/jfx/pull/1944/files/cfbc542d..35a75ccd

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

  Stats: 89 lines in 4 files changed: 40 ins; 48 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1944.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1944/head:pull/1944

PR: https://git.openjdk.org/jfx/pull/1944

From kcr at openjdk.org  Wed Nov  5 21:51:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Nov 2025 21:51:17 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v6]
In-Reply-To: <6EC_fe28eiJ4GZWWtnMyGukuitJdUi2ylm7lW6w8P2c=.076451e8-16c3-425d-b3dc-c60e6b985eff@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <HzoV0_nTS4wT9sp6sp0GsdHr1MOPcOh-Jv_yx8y4hWA=.67710d5a-0169-4ce4-9c7b-b2b78573b73d@github.com>
 <amqwYWz3r23pO_2bkjFwY33vEQknAGmQDROnM_U1Z7c=.e7c864d0-5b51-4fbf-9441-4e9faae9559b@github.com>
 <A8WW5po_t1eRA0z_YAFL7PMHXXwxOWtfaLttAefc1po=.e54c6724-3d9c-4e93-a6f4-db07df1fd23a@github.com>
 <Vt42mhzaA4KuMWQ4A9IoKyo4FAnOZQCxvjnMzKecekg=.a1445936-9f90-408c-b316-8895f32a902d@github.com>
 <UhqX3UkMdLsXroqFfzGLoueAGLvRdOoZ_p5FfsH6ChM=.905b273f-e12b-4e87-91fc-f7ff1dc4eb41@github.com>
 <6EC_fe28eiJ4GZWWtnMyGukuitJdUi2ylm7lW6w8P2c=.076451e8-16c3-425d-b3dc-c60e6b985eff@github.com>
Message-ID: <zWeaN4g2xHoKPUyk8Slrw7qsY-ObgM6c5P_1tGEkXdA=.090921e8-fb40-4b3f-b4e9-ee2db9896b70@github.com>

On Wed, 5 Nov 2025 20:20:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Actually, I thought of a bigger concern. Having a writable attribute in both the control and the model is not going to give coherent results in the case where you have more than one view on the same model. So you might need to rethink the idea of having a writable property on the view (the control) while also having state (via a writable attribute) on the model.
>
> Good point!
> What do you think we should do then?
> 
> I should probably move the setter and getter to the RichTextArea class then, and remove the property altogether.
> 
> Any custom UI can always create its own property for line ending and deal with the model directly.

Making the property in the model be the primary and having the RTA setter/getter forward to the model makes it a lot like setUndoRedoEnable, which seems like a good choice. The state is only in one place (the model) with convenience methods in the control.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2496294565

From mhanl at openjdk.org  Wed Nov  5 22:40:44 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 5 Nov 2025 22:40:44 GMT
Subject: Integrated: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells
In-Reply-To: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
References: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
Message-ID: <O7dgoF9sGjFgMEgP2vggBnpdaSPckM4QfcJq68aTIp4=.d729128b-5482-40a2-885c-17cd3c135b38@github.com>

On Sun, 15 Jun 2025 14:23:27 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> When calling `refresh()` on virtualized Controls (`ListView`, `TreeView`, `TableView`, `TreeTableView`), all cells will be recreated completely, instead of just refreshing them.
> 
> This is because `recreateCells()` of the `VirtualFlow` is called when `refresh()` was called. This is not needed, since refreshing the cells can be done much cheaper with `rebuildCells()`.
> 
> This will reset all cells (`index = -1`), add them to the pile and fill them back in the viewport with an index again. This ensures `updateItem()` is called.
> 
> The contract of `refresh()` is also a big vague, stating:
> 
> Calling {@code refresh()} forces the XXX control to recreate and repopulate the cells 
> necessary to populate the visual bounds of the control.
> In other words, this forces the XXX to update what it is showing to the user. 
> This is useful in cases where the underlying data source has changed in a way that is not observed by the XXX itself.
> 
> 
> As written above, recreating is not needed in order to fulfull the contract of updating what is shown to the user in case the underlying data source changed without JavaFX noticing (e.g. calling a normal Setter without any Property and therefore listener involved).
> 
> ----
> 
> Benchmarks
> -
> 
> Setup:
> - `TableView`
> - `100 TableColumns`
> - `1000 Items`
> 
> Code is in `tests/performance`.
> 
> Calling `refresh()` with a `Button` press.
> 
> | WHAT | BEFORE WITHOUT JDK-8360940 | BEFORE | WITH FIX | WITH FIX WITH JDK-8370498 |
> | - | - | - | - | - |
> | Init | 0ms | 0 ms | 0 ms | 0 ms |
> | Init | 0ms | 0 ms | 0 ms | 0 ms |
> | Init | 195 ms | 209 ms | 211 ms | 217 ms |
> | Init | 42 ms | 47 ms | 41 ms | 10 ms |
> | Init | 2 ms | 6 ms | 6 ms | - |
> | Refresh Nr. 1 | 204 ms | 227 ms -> 23 ms -> 0 ms | 42 ms -> 0ms | 48 ms -> 0ms |
> | Refresh Nr. 2 | 201 ms | 145 ms -> 27 ms -> 0 ms | 31 ms -> 0ms | 35 ms -> 0ms |
> | Refresh Nr. 3 | 207 ms | 153 ms -> 25 ms | 33 ms -> 0ms | 31 ms -> 0ms |
> | Refresh Nr. 4 | 148 ms | 168 ms -> 20 ms -> 0 ms | 30 ms -> 0ms | 31 ms -> 0ms |
> | Refresh Nr. 5 | 136 ms | 183 ms -> 31 ms -> 0 ms | 46 ms -> 0ms | 29 ms -> 0ms |

This pull request has now been integrated.

Changeset: 02756a81
Author:    Marius Hanl <mhanl at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/02756a810c54c4068505eca6d43c1ba2a136e04e
Stats:     429 lines in 15 files changed: 364 ins; 37 del; 28 mod

8359599: Calling refresh() for all virtualized controls recreates all cells instead of refreshing the cells

Reviewed-by: angorya, kcr, jhendrikx, jvos

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

PR: https://git.openjdk.org/jfx/pull/1830

From mstrauss at openjdk.org  Wed Nov  5 23:43:17 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 5 Nov 2025 23:43:17 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v3]
In-Reply-To: <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com>
Message-ID: <aavSnAKjNX3fhEz4ld5DSWBN28vv41JvJW5xtHgjyWY=.42ddb62e-ba1a-472a-94e0-61b26a26c696@github.com>

On Wed, 5 Nov 2025 16:19:36 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR implements a new default method on `ObservableList` to be able to replace elements within a specified range.
>> 
>> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
>> 
>> The other alternative is to call `set` individually for each item, which results in many change notifications.
>> 
>> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
>> 
>> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add additional tests

modules/javafx.base/src/main/java/javafx/collections/ObservableList.java line 105:

> 103:      *         or {@code from > to}
> 104:      */
> 105:     public default boolean replaceRange(int from, int to, Collection<? extends E> col) {

This method needs an `@since 26` tag.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1937#discussion_r2496532720

From kcr at openjdk.org  Thu Nov  6 00:08:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 6 Nov 2025 00:08:20 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v3]
In-Reply-To: <aavSnAKjNX3fhEz4ld5DSWBN28vv41JvJW5xtHgjyWY=.42ddb62e-ba1a-472a-94e0-61b26a26c696@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com>
 <aavSnAKjNX3fhEz4ld5DSWBN28vv41JvJW5xtHgjyWY=.42ddb62e-ba1a-472a-94e0-61b26a26c696@github.com>
Message-ID: <ONkTtrfikmH2cGl99qtGs5GHtuJwFhqIEI6tHXwTckU=.b2f5b733-1ffd-4782-8784-6f72f8bede9c@github.com>

On Wed, 5 Nov 2025 23:40:26 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add additional tests
>
> modules/javafx.base/src/main/java/javafx/collections/ObservableList.java line 105:
> 
>> 103:      *         or {@code from > to}
>> 104:      */
>> 105:     public default boolean replaceRange(int from, int to, Collection<? extends E> col) {
> 
> This method needs an `@since 26` tag.

Thanks for catching this! I don't know how I missed it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1937#discussion_r2496576508

From kcr at openjdk.org  Thu Nov  6 00:08:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 6 Nov 2025 00:08:18 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v3]
In-Reply-To: <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com>
Message-ID: <AI4COU5Ft--8ui_RBQ61DhTbVa93GmqNhf7_QNkNQuE=.1ff193d4-c007-4cdd-8841-7abeceabf0a2@github.com>

On Wed, 5 Nov 2025 16:19:36 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR implements a new default method on `ObservableList` to be able to replace elements within a specified range.
>> 
>> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
>> 
>> The other alternative is to call `set` individually for each item, which results in many change notifications.
>> 
>> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
>> 
>> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add additional tests

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

Changes requested by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1937#pullrequestreview-3425035523

From jhendrikx at openjdk.org  Thu Nov  6 03:24:40 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 6 Nov 2025 03:24:40 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v4]
In-Reply-To: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
Message-ID: <jSVQbyU6nbs_v6qdLeX-_PUXbBt0h65R_ozwhKEx2lQ=.da7c4005-ef06-4031-b17f-736ef981cfbe@github.com>

> This PR implements a new default method on `ObservableList` to be able to replace elements within a specified range.
> 
> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
> 
> The other alternative is to call `set` individually for each item, which results in many change notifications.
> 
> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
> 
> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.

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

  Add since tag

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1937/files
  - new: https://git.openjdk.org/jfx/pull/1937/files/730ea77f..3e3bb966

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

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

PR: https://git.openjdk.org/jfx/pull/1937

From mstrauss at openjdk.org  Thu Nov  6 03:28:19 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 6 Nov 2025 03:28:19 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v4]
In-Reply-To: <jSVQbyU6nbs_v6qdLeX-_PUXbBt0h65R_ozwhKEx2lQ=.da7c4005-ef06-4031-b17f-736ef981cfbe@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <jSVQbyU6nbs_v6qdLeX-_PUXbBt0h65R_ozwhKEx2lQ=.da7c4005-ef06-4031-b17f-736ef981cfbe@github.com>
Message-ID: <tqI7x-J-dx28Trblvz3suQVsE7aXDjxueIoJbNj3N0U=.4c99cea2-82cd-4eb2-aa89-36e5922e08c0@github.com>

On Thu, 6 Nov 2025 03:24:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR implements a new default method on `ObservableList` to be able to replace elements within a specified range.
>> 
>> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
>> 
>> The other alternative is to call `set` individually for each item, which results in many change notifications.
>> 
>> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
>> 
>> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add since tag

Marked as reviewed by mstrauss (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1937#pullrequestreview-3425676123

From psadhukhan at openjdk.org  Thu Nov  6 04:02:57 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 6 Nov 2025 04:02:57 GMT
Subject: RFR: 8371386: Fix potential NPE in SwingNode
Message-ID: <l4a-jc7xeqRWm_plz2vkjX3yvJZxcqhQgxHTKGEZFhI=.842f452b-4b5e-4b8f-995f-fd205232c296@github.com>

There can be potential NPEs in SwingNode which is fixed

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

Commit messages:
 - 8371386: Fix potential NPE in SwingNode

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

PR: https://git.openjdk.org/jfx/pull/1965

From jvos at openjdk.org  Thu Nov  6 08:32:57 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 6 Nov 2025 08:32:57 GMT
Subject: [jfx17u] RFR: 8371015: Change JavaFX release version to 17.0.18 in
 jfx17u
Message-ID: <jNufGrkdDTMuc2DfCb-MW90azny-6tUnTVOIKauDfsQ=.1d202b59-f2bd-477a-b016-f0f58d1d8bf8@github.com>

Bump release version to 17.0.18

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

Commit messages:
 - Bump release version to 17.0.18

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

PR: https://git.openjdk.org/jfx17u/pull/240

From jpereda at openjdk.org  Thu Nov  6 08:32:58 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 6 Nov 2025 08:32:58 GMT
Subject: [jfx17u] RFR: 8371015: Change JavaFX release version to 17.0.18 in
 jfx17u
In-Reply-To: <jNufGrkdDTMuc2DfCb-MW90azny-6tUnTVOIKauDfsQ=.1d202b59-f2bd-477a-b016-f0f58d1d8bf8@github.com>
References: <jNufGrkdDTMuc2DfCb-MW90azny-6tUnTVOIKauDfsQ=.1d202b59-f2bd-477a-b016-f0f58d1d8bf8@github.com>
Message-ID: <oSvUGLEBViR7hPNdXBGkUFzdcTBesFtsJUiZ6ZMf3IM=.bb5a4659-6907-4d85-9404-cd62c60525fc@github.com>

On Thu, 6 Nov 2025 08:24:48 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Bump release version to 17.0.18

Marked as reviewed by jpereda (Reviewer).

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

PR Review: https://git.openjdk.org/jfx17u/pull/240#pullrequestreview-3426870675

From jvos at openjdk.org  Thu Nov  6 08:32:59 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 6 Nov 2025 08:32:59 GMT
Subject: [jfx17u] RFR: 8371015: Change JavaFX release version to 17.0.18 in
 jfx17u
In-Reply-To: <jNufGrkdDTMuc2DfCb-MW90azny-6tUnTVOIKauDfsQ=.1d202b59-f2bd-477a-b016-f0f58d1d8bf8@github.com>
References: <jNufGrkdDTMuc2DfCb-MW90azny-6tUnTVOIKauDfsQ=.1d202b59-f2bd-477a-b016-f0f58d1d8bf8@github.com>
Message-ID: <o7blEWqaJPYBvAcA2aT0IN7TtSnXQsFgf9b59ftHhN8=.23611fa7-25ca-4fc4-936a-788c0e797ecc@github.com>

On Thu, 6 Nov 2025 08:24:48 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Bump release version to 17.0.18

@jperedadnr can you review?

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

PR Comment: https://git.openjdk.org/jfx17u/pull/240#issuecomment-3495821368

From jvos at openjdk.org  Thu Nov  6 08:43:17 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 6 Nov 2025 08:43:17 GMT
Subject: [jfx21u] RFR: 8371016: Change JavaFX release version to 21.0.10 in
 jfx21u
Message-ID: <fty6K1NwKLpctXkzTwOKfeWZ9Nq7yZM6TMJPFKEqwNs=.bd4198d1-ffc2-4a34-804c-7c3d48969381@github.com>

Bump version to 21.0.10

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

Commit messages:
 - Bump version to 21.0.10

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

PR: https://git.openjdk.org/jfx21u/pull/103

From jvos at openjdk.org  Thu Nov  6 08:43:18 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 6 Nov 2025 08:43:18 GMT
Subject: [jfx21u] RFR: 8371016: Change JavaFX release version to 21.0.10 in
 jfx21u
In-Reply-To: <fty6K1NwKLpctXkzTwOKfeWZ9Nq7yZM6TMJPFKEqwNs=.bd4198d1-ffc2-4a34-804c-7c3d48969381@github.com>
References: <fty6K1NwKLpctXkzTwOKfeWZ9Nq7yZM6TMJPFKEqwNs=.bd4198d1-ffc2-4a34-804c-7c3d48969381@github.com>
Message-ID: <00cNN50xAFN9VRX1s_anecwbSrPZsN881Zg3P5WJlYo=.d7b82a3d-47e3-4b49-88d3-88f078053b35@github.com>

On Thu, 6 Nov 2025 08:33:45 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Bump version to 21.0.10

@jperedadnr can you review?

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

PR Comment: https://git.openjdk.org/jfx21u/pull/103#issuecomment-3495879799

From jvos at openjdk.org  Thu Nov  6 08:43:21 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 6 Nov 2025 08:43:21 GMT
Subject: [jfx17u] Integrated: 8371015: Change JavaFX release version to 17.0.18
 in jfx17u
In-Reply-To: <jNufGrkdDTMuc2DfCb-MW90azny-6tUnTVOIKauDfsQ=.1d202b59-f2bd-477a-b016-f0f58d1d8bf8@github.com>
References: <jNufGrkdDTMuc2DfCb-MW90azny-6tUnTVOIKauDfsQ=.1d202b59-f2bd-477a-b016-f0f58d1d8bf8@github.com>
Message-ID: <dj5QvZbAyVCQpTAFYl8B_FktBm8IyAiAgqlmn48Uf1s=.73c190b7-c068-44d2-8f63-92ea67e72f70@github.com>

On Thu, 6 Nov 2025 08:24:48 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Bump release version to 17.0.18

This pull request has now been integrated.

Changeset: 4cc49e64
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/4cc49e645e52ce3797da01f184efb921c2db6674
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8371015: Change JavaFX release version to 17.0.18 in jfx17u

Reviewed-by: jpereda

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

PR: https://git.openjdk.org/jfx17u/pull/240

From jpereda at openjdk.org  Thu Nov  6 08:50:27 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 6 Nov 2025 08:50:27 GMT
Subject: [jfx21u] RFR: 8371016: Change JavaFX release version to 21.0.10 in
 jfx21u
In-Reply-To: <fty6K1NwKLpctXkzTwOKfeWZ9Nq7yZM6TMJPFKEqwNs=.bd4198d1-ffc2-4a34-804c-7c3d48969381@github.com>
References: <fty6K1NwKLpctXkzTwOKfeWZ9Nq7yZM6TMJPFKEqwNs=.bd4198d1-ffc2-4a34-804c-7c3d48969381@github.com>
Message-ID: <iUDCX_iwKH76ZyrkkOaJY7HuB1wl7EQzQoGmG0hSxmM=.d67fe556-aa77-4ee8-b871-af5ce6bf0288@github.com>

On Thu, 6 Nov 2025 08:33:45 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Bump version to 21.0.10

Marked as reviewed by jpereda (Reviewer).

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

PR Review: https://git.openjdk.org/jfx21u/pull/103#pullrequestreview-3426947313

From jvos at openjdk.org  Thu Nov  6 08:56:26 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 6 Nov 2025 08:56:26 GMT
Subject: [jfx21u] Integrated: 8371016: Change JavaFX release version to 21.0.10
 in jfx21u
In-Reply-To: <fty6K1NwKLpctXkzTwOKfeWZ9Nq7yZM6TMJPFKEqwNs=.bd4198d1-ffc2-4a34-804c-7c3d48969381@github.com>
References: <fty6K1NwKLpctXkzTwOKfeWZ9Nq7yZM6TMJPFKEqwNs=.bd4198d1-ffc2-4a34-804c-7c3d48969381@github.com>
Message-ID: <1Lp5PqlwDrgt6gudVkM7PQGOzTYuxicP1zsmLjN4hLk=.de1ed024-3dbd-4cb9-9ad6-6be93cb1f345@github.com>

On Thu, 6 Nov 2025 08:33:45 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Bump version to 21.0.10

This pull request has now been integrated.

Changeset: 30c1e547
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/30c1e547190e552c047cb10a3a3888558dea5219
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8371016: Change JavaFX release version to 21.0.10 in jfx21u

Reviewed-by: jpereda

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

PR: https://git.openjdk.org/jfx21u/pull/103

From lkostyra at openjdk.org  Thu Nov  6 09:57:26 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 6 Nov 2025 09:57:26 GMT
Subject: RFR: 8210547: [Linux] Uncontrolled framerate [v2]
In-Reply-To: <iwmsPHVjzXWB-bAxJmHn-91NT_mTG_bTuo9-wdmoXDs=.f86ac5cc-4c7a-4d49-ba12-bcb8b700b570@github.com>
References: <O6h0vab-ONVxD-3eOinC6if5xX_Ae9Aa2xFErxWsmgU=.c0f9330b-77aa-48c8-b083-700ba6124251@github.com>
 <iwmsPHVjzXWB-bAxJmHn-91NT_mTG_bTuo9-wdmoXDs=.f86ac5cc-4c7a-4d49-ba12-bcb8b700b570@github.com>
Message-ID: <EyPWV8b1lR5NXXvULxwARGx2hqetw7fevXf7loTePto=.c4207bb4-f8f4-4d8d-ba31-d229360e49bc@github.com>

On Sat, 4 Oct 2025 15:19:32 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> As Michael Zucchi pointed out on the mailing list, the high framerate occurs because `glXSwapBuffers() `operates asynchronously. To ensure proper synchronization, you can call `glFinish() `afterward, which blocks until the buffer swap is fully completed. However, when using `glXSwapIntervalSGI`, the swap interval setting applies globally rather than per drawable. In contrast, `glXSwapIntervalEXT` provides per-drawable control, allowing finer-grained vsync behavior.
>> 
>> I don't know if there are scenarios when the unlimited frame rate is needed - if so we should provide a option.
>> 
>> See [https://wikis.khronos.org/opengl/Swap_Interval](https://wikis.khronos.org/opengl/Swap_Interval)
>> 
>> It also selects the correct visual for transparency which needs to be depth = 32 for X11.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Call glXSwapIntervalEXT or glXSwapIntervalSGI if not null

I only have one code review remark, I still have to do my testing for this change.

modules/javafx.graphics/src/main/native-prism-es2/x11/X11GLFactory.c line 237:

> 235: 
> 236:     if (visualInfo == NULL) {
> 237:         fbConfig = fbConfigList[0];

If I understand this correctly, we're just fetching the first available option from the list which might not always have windows transparency. If that's the case - would it make sense to print some sort of warning on the terminal that window transparency might not work correctly? I think it could be a valuable information to the user, or at least when debugging in the future.

@kevinrushforth it's also a question to you, cause I'm not 100% sure what the JFX strategy would be in this case - if we would want this to be printed always as a warning, or only when we ex. activate `-Dprism.verbose=true`

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

PR Review: https://git.openjdk.org/jfx/pull/1929#pullrequestreview-3427243988
PR Review Comment: https://git.openjdk.org/jfx/pull/1929#discussion_r2498274259

From tsayao at openjdk.org  Thu Nov  6 10:50:03 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 6 Nov 2025 10:50:03 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v68]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <ZEL2vM5QCujkDxA_xn_BLQdq0-cwenqje3XEEKTTHcI=.e4375bb2-b409-4af7-bfeb-8812aede3da5@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.

Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 82 commits:

 - Merge branch 'master' into 8354943
 - Merge branch 'master' into 8354943
   
   # Conflicts:
   #	modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp
 - Merge branch 'master' into 8354943
 - Fix copyright header
 - Revert "8367898: Skip StageFocusTest on Linux"
   
   This reverts commit c95cdcdc9cd8b3070e8076ea91234772d6a21331.
 - Merge branch 'master' into 8354943
 - Remove unused imports
 - - Fix StageOwnershipTest label + minor adjustments
 - Merge branch 'master' into 8354943
 - Merge branch 'master' into 8354943
 - ... and 72 more: https://git.openjdk.org/jfx/compare/02756a81...fee7ca32

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=67
  Stats: 4117 lines in 28 files changed: 2712 ins; 776 del; 629 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

PR: https://git.openjdk.org/jfx/pull/1789

From tsayao at openjdk.org  Thu Nov  6 10:54:59 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 6 Nov 2025 10:54:59 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v69]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <0tfbWwXhyQyvEIf71zpbHsQHTe6QKleb_QhlIo8k2rM=.b9ec1b58-1aed-47b6-97df-babc0dad3d9f@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Remote assumeTrue for JDK-8364547

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/fee7ca32..4aed85b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=68
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=67-68

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

PR: https://git.openjdk.org/jfx/pull/1789

From tsayao at openjdk.org  Thu Nov  6 10:57:31 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 6 Nov 2025 10:57:31 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v67]
In-Reply-To: <Q6sspI1qpai--Hg7ck4NJj5acQzT-Mz485BMQdcasbA=.ade73a49-ca94-4af2-8252-0b7779d81b71@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <E2i6jXFgof7wwX8XaVBIkUOxA1s2MnwrJHmvDzkKHn4=.f2501476-3d87-4cdf-b7ab-fab5a4629d71@github.com>
 <Q6sspI1qpai--Hg7ck4NJj5acQzT-Mz485BMQdcasbA=.ade73a49-ca94-4af2-8252-0b7779d81b71@github.com>
Message-ID: <EyNDnWG4_kJxP0z7myx7a3IBz3N6HnTbkbeJetQ9niM=.30306dd4-33f0-4380-b35e-bd943616e7d7@github.com>

On Wed, 15 Oct 2025 20:42:36 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 81 commits:
>> 
>>  - Merge branch 'master' into 8354943
>>    
>>    # Conflicts:
>>    #	modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp
>>  - Merge branch 'master' into 8354943
>>  - Fix copyright header
>>  - Revert "8367898: Skip StageFocusTest on Linux"
>>    
>>    This reverts commit c95cdcdc9cd8b3070e8076ea91234772d6a21331.
>>  - Merge branch 'master' into 8354943
>>  - Remove unused imports
>>  - - Fix StageOwnershipTest label + minor adjustments
>>  - Merge branch 'master' into 8354943
>>  - Merge branch 'master' into 8354943
>>  - - Fix scene resize when window is unresizable
>>  - ... and 71 more: https://git.openjdk.org/jfx/compare/38300ca6...07d1cd31
>
> tests/system/src/test/java/test/javafx/stage/SizingTest.java line 159:
> 
>> 157:     void minSize(StageStyle stageStyle) {
>> 158:         // JDK-8364547
>> 159:         assumeTrue(!PlatformUtil.isWindows());
> 
> I can confirm that PR #1870 fixes the underlying bug, JDK-8364547. Once that PR is integrated, merge master and then remove this `assumeTrue`.

Done

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2498492282

From arapte at openjdk.org  Thu Nov  6 11:33:22 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 6 Nov 2025 11:33:22 GMT
Subject: RFR: 8371052: Update libFFI to 3.5.2
In-Reply-To: <EihmQlWsI1W2GLW_YDC8pOUhxQnzSfn4W5q1NvH2euM=.d769fa13-8113-43d1-8c37-1fcd849f653d@github.com>
References: <EihmQlWsI1W2GLW_YDC8pOUhxQnzSfn4W5q1NvH2euM=.d769fa13-8113-43d1-8c37-1fcd849f653d@github.com>
Message-ID: <Cqt5whiDWoEQV8W3CXlq2PEkuEsv7k05hbLOXO547M4=.934ea1e3-bc87-447a-8ae6-20377363e836@github.com>

On Wed, 5 Nov 2025 02:17:39 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Updated libFFI to 3.5.2.
> - Tested on all platforms.
> - No additional changes are done.

Spot checked files.
I have provided a query and a minor suggestion. Please check. rest LGTM.

modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/include/ffi_cfi.h line 74:

> 72: # define cfi_lsda(enc, exp)
> 73: # define cfi_escape(...)
> 74: # define cfi_window_save

The libffi 3.5.2 source contains a definition of `cfi_window_save` under `#ifdef HAVE_AS_CFI_PSEUDO_OP` as well. Could you please check.

modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/src/aarch64/internal.h line 93:

> 91:   #define SIGN_LR_LINUX_ONLY
> 92: #define BRANCH_TO_REG braaz
> 93:   #define PAC_CFI_WINDOW_SAVE

Minor: 
Looks like the upstream libffi file has some specific space additions in this file to showcase nesting. So, to match it, Line 86 to 90, line 92, should also be modified to have prefixing space.
Similar applies to line 135 to 142.

It may help reducing conflicts during next update.

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

Changes requested by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1962#pullrequestreview-3427532447
PR Review Comment: https://git.openjdk.org/jfx/pull/1962#discussion_r2498482768
PR Review Comment: https://git.openjdk.org/jfx/pull/1962#discussion_r2498582602

From lkostyra at openjdk.org  Thu Nov  6 11:41:20 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 6 Nov 2025 11:41:20 GMT
Subject: RFR: 8366202: RichTextArea: wrong style used for typed text [v3]
In-Reply-To: <TLf7tNmPvOMnMj9HuMseOTezIxNHhuh53fd_rJYzO9c=.9a4ef33a-34af-42fb-9039-8f9e0c94b912@github.com>
References: <jXJWCEH5_QG54daSS3iS1-iTOC39YN8OTxIQlkOVvJQ=.7599c825-0466-43bf-9c4f-5f225a4a7090@github.com>
 <TLf7tNmPvOMnMj9HuMseOTezIxNHhuh53fd_rJYzO9c=.9a4ef33a-34af-42fb-9039-8f9e0c94b912@github.com>
Message-ID: <bwJBvhv8GV5crl7tO79kEJOx3gl8d-yeliac1IJZWL8=.e85fd743-1614-4a4f-b06b-a460b85e3b4f@github.com>

On Fri, 31 Oct 2025 20:38:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> User feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ):
>> 
>> When typing text, in the middle of a sentence, to extend a word that's styled then the typed text is not being inserted using the styles of the preceding text.
>> 
>> Root cause: implementation bug.
>
> Andy Goryachev 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 8366202.wrong
>  - review comments
>  - wrong style

LGTM, after the fixes RichEditorDemo works properly and tests pass as expected.

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1950#pullrequestreview-3427732581

From lkostyra at openjdk.org  Thu Nov  6 12:32:32 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 6 Nov 2025 12:32:32 GMT
Subject: RFR: 8368629: Texture.update sometimes invoked for a disposed
 Texture [v5]
In-Reply-To: <7qwmtaXylAWHTzLvKlwbhjS0j8RU7k9QYjVLz7gFlMQ=.c8b5523a-d194-4e52-b737-15db53d8ce62@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>
 <b6V3zXUmO4RZ2F0vnt_spUBBY8m_-YBsUrYFnke0xOM=.b6cab202-da18-479c-8fa4-86364cba4ccf@github.com>
 <0l75Ntsh97_SK7jLWg-Y1N0ajkvlh-SAbwSPww-ugWA=.cba522ac-51b3-4bfc-88bb-4ef8a162fc65@github.com>
 <7qwmtaXylAWHTzLvKlwbhjS0j8RU7k9QYjVLz7gFlMQ=.c8b5523a-d194-4e52-b737-15db53d8ce62@github.com>
Message-ID: <_ITzBRboQ9NxbijetuLXmjjfjm9ofWBzNMmosLua2VE=.50aaa687-e997-4803-b5ce-96c969d660c5@github.com>

On Wed, 5 Nov 2025 11:25:31 GMT, Alessadro Parisi <duke at openjdk.org> wrote:

>>> I was finally able to compile JavaFX with this PR and integrate it into my maven project. This does not seem to fix my issue entirely. While I don't see expections like these anymore: `NullPointerException: Cannot invoke "com.sun.prism.RTTexture.createGraphics()" because <local9> is null` I now see this: `java.lang.NullPointerException: Cannot invoke "com.sun.prism.RTTexture.createGraphics()" because "newtex" is null` or this `java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.assertLocked()" because "this.maskTex" is null` and the app still freezes
>>> 
>>> Is this related or an entirely different issue?
>> 
>> Hard to judge just from those messages, but it is possible the root cause is similar. The check I added is only in one place and it might not cover all cases. Can you provide a full stacktrace for each of those NPEs?
>
>> Hard to judge just from those messages, but it is possible the root cause is similar. The check I added is only in one place and it might not cover all cases. Can you provide a full stacktrace for each of those NPEs?
> 
> Sure thing, here are the full stack traces:
> <details>
> <summary><code>createGraphics()</code> exception</summary>
> <pre>
> java.lang.NullPointerException: Cannot invoke "com.sun.prism.RTTexture.createGraphics()" because "newtex" is null
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGCanvas$RenderBuf.validate(NGCanvas.java:216)
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGCanvas.initCanvas(NGCanvas.java:646)
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGCanvas.renderContent(NGCanvas.java:609)
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279)
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186)
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213)
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2057)
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NodeEffectInput.getImageDataForBoundedNode(NodeEffectInput.java:237)
> 	at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NodeEffectInput.filter(NodeEffectInput.java:131)
> 	at javafx.graphics at 26-internal/com.sun.scenario.effect.FilterEffect.filter(FilterEffect.java:185)
> 	at javafx.graphics at 26-internal/com.sun.scenario.effect.Offset.filter(Offset.java:160)
> 	at javafx.graphics at 26-internal/com.sun.scenario.effect.Merge.filter(Merge.java:148)
> 	at javafx.graphics at 26-internal/com.sun.scenario.effect.DelegateEffect.filter(DelegateEffect.java:70)
> 	at javafx.graphics at 26-internal/com.sun.scenario.effect.impl.prism.PrEffectHelper.render(PrEffectHelper.java:166)
> 	at jav...

@palexdev these seem to come from a similar root cause (Pool pruning some Textures that are not locked when they should be) however these seem to be different spots than this one; in other words, to me this seems unrelated to this fix.

Independently @arapte notified me of one more situation that causes an NPE when the mask texture is updated, this happens only on ES2 backend on macOS despite these changes. NPE stack trace comes from the same place (`BaseContext.flushMask()`) but for some reason current fix does not handle those. I'm pretty sure I know why so I'll fix that as part of this change.

To summarize, I think this is how we're going to tackle this:
- I will fix the ES2 problem on macOS as part of this PR, since this one is way more related than other NPEs attached here
- The "proper" solution (managing Textures lifetime better) - including the new more "extreme" cases of NPEs attached here - I think should be solved as part of [JDK-8371192](https://bugs.openjdk.org/browse/JDK-8371192). I'll file a separate PR for this and we'll give it proper, more exhaustive testing.

@kevinrushforth what do you think of this?

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3497041222

From mhanl at openjdk.org  Thu Nov  6 12:32:49 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 6 Nov 2025 12:32:49 GMT
Subject: RFR: 8369049: [TestBug] Update JUnit to Version 6.0.1 [v2]
In-Reply-To: <fh2lOQgiepinztNz4eY5JI2XJnrp6dh8pURAvAiPzuA=.c954e1c0-0788-4b4a-9b71-90e73de29bf5@github.com>
References: <fh2lOQgiepinztNz4eY5JI2XJnrp6dh8pURAvAiPzuA=.c954e1c0-0788-4b4a-9b71-90e73de29bf5@github.com>
Message-ID: <mPos3U76pnLvx2LYEFUWpJBK3NBP6nS3aGBxAkhhbjU=.48e9a00d-dac8-417d-beeb-09f2ed6b1bcb@github.com>

> JUnit 6.0.1 is out and we can consider updating to it.
> 
> Release Notes: https://docs.junit.org/current/release-notes/index.html#release-notes-6.0.0
> https://docs.junit.org/current/release-notes/index.html#release-notes-6.0.1
> 
> Notes:
> - Java 17 is the baseline (so not a problem for us, since we have a higher baseline)
> - Deprecation were removed (not a problem, as we don't rely on any)
> - JUnit Vintage Engine is deprecated (not a problem, as we dropped support for it some months ago)
> 
> JUnit 6 now uses a single version number for all dependencies, that is platform, jupiter and vintage (which we do not use anymore). That makes updating it easier.
> 
> It also uses `JSpecify`, which is an annotation library for `@NonNull` and `@Nullable`. All version numbers for JUnit now use a single variable.

Marius Hanl 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:

 - 6.0.1
 - Merge branch 'master' of https://github.com/openjdk/jfx into junit6-upgrade
 - Update to JUnit Version 6.0.0

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1925/files
  - new: https://git.openjdk.org/jfx/pull/1925/files/a41489c9..e28215be

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

  Stats: 3244 lines in 154 files changed: 2348 ins; 299 del; 597 mod
  Patch: https://git.openjdk.org/jfx/pull/1925.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1925/head:pull/1925

PR: https://git.openjdk.org/jfx/pull/1925

From kcr at openjdk.org  Thu Nov  6 12:33:31 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 6 Nov 2025 12:33:31 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v4]
In-Reply-To: <jSVQbyU6nbs_v6qdLeX-_PUXbBt0h65R_ozwhKEx2lQ=.da7c4005-ef06-4031-b17f-736ef981cfbe@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <jSVQbyU6nbs_v6qdLeX-_PUXbBt0h65R_ozwhKEx2lQ=.da7c4005-ef06-4031-b17f-736ef981cfbe@github.com>
Message-ID: <iUdtvANBofIqiBcUiBHzA0p_DspehpN_hjw8vR5R8hU=.90b02208-690e-4cbc-ae52-4db47b9b4b31@github.com>

On Thu, 6 Nov 2025 03:24:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR implements a new default method on `ObservableList` to be able to replace elements within a specified range.
>> 
>> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
>> 
>> The other alternative is to call `set` individually for each item, which results in many change notifications.
>> 
>> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
>> 
>> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add since tag

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1937#pullrequestreview-3427954225

From jdv at openjdk.org  Thu Nov  6 13:35:32 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 6 Nov 2025 13:35:32 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v11]
In-Reply-To: <qs8jE5IgmH5OAiM1Gq84NCUtGYKA7rMM4jJ5MI-aW8I=.35573598-02dd-42c8-8be2-bffdf69e431d@github.com>
References: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
 <qs8jE5IgmH5OAiM1Gq84NCUtGYKA7rMM4jJ5MI-aW8I=.35573598-02dd-42c8-8be2-bffdf69e431d@github.com>
Message-ID: <AoXRKeG6DewcdJH0OswKJlSdH6mzXilManxoOXyagoU=.cb8049ca-841d-4c95-886e-678e848d4a23@github.com>

On Tue, 4 Nov 2025 21:06:59 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc

I think we need to update comments related to appendText() method. Please correct me if i am wrong.

Also if we are updating the identified comments, we also need to update the CSR.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 103:

> 101:  *   // build the content
> 102:  *   textArea.setUndoRedoEnabled(false);
> 103:  *   textArea.appendText("RichTextArea\n", heading, false);

We don't pass any per method undo/redo flag as argument in appendText.
This needs to be updated.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1105:

> 1103:      * <p>
> 1104:      * This convenience method is equivalent to calling
> 1105:      * {@code appendText(text, StyleAttributeMap.EMPTY, true);}

I dont see any appendText() method with third argument.
And we have already specified in StyledTextModel that default value for undoRedoEnabled is `true`. So this comment needs to be updated.

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

PR Review: https://git.openjdk.org/jfx/pull/1941#pullrequestreview-3428171390
PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2498951695
PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2498963504

From jhendrikx at openjdk.org  Thu Nov  6 13:54:32 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 6 Nov 2025 13:54:32 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: <dXul0jP0wEPTpYaY_wO0mWckPun8673x-EiXnbn_sks=.c351f119-2e96-4799-9165-1bef9864bce3@github.com>
References: <LwnBiVMOfsnBlKPaSv_P99MdGLTYFzV282agrWuXZvM=.45a4b546-241f-4754-99b8-6ed5dee81ab6@github.com>
 <wPAA9aAnrNklGwk5c8pJLmhxYd8nL4-Z8_GCILQ8whc=.53900459-2846-4d41-aea4-20ab809abf9f@github.com>
 <dXul0jP0wEPTpYaY_wO0mWckPun8673x-EiXnbn_sks=.c351f119-2e96-4799-9165-1bef9864bce3@github.com>
Message-ID: <3bcATw2N08fxaco0X8hbTAsjt0nHwIJkpeyMGHnPYXs=.e613550b-0eaa-48f6-8ed9-86ae631a4275@github.com>

On Sun, 2 Nov 2025 20:03:48 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> I did tests on 3 different applications and could not spot any problems!
> 
> What I did not test:
> 
> * `ToolBar`
> * `BubbleChart`
> * `AreaChart`
> * `Pagination`
> * Most of the 3D `Shape` classes

Thanks very much :)  

I'm hoping I will get around to looking at the menu bar issue this weekend, and seeing what causes the problems there.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3497365679

From angorya at openjdk.org  Thu Nov  6 15:41:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 15:41:09 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v12]
In-Reply-To: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
References: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
Message-ID: <-5RQhssjbuZbj2zWEB4TYXgNOUVModpvsFaJVVfVl1I=.2356192e-77d3-4949-beeb-9b643a05a0f7@github.com>

> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
> 
> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
> 
> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
> 
> WARNING this is an incompatible change, permitted because of the incubator.
> 
> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - review comments
 - Merge branch 'master' into 8366201.allow.undo
 - javadoc
 - suggestion
   
   Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
 - set text
 - Merge branch 'master' into 8366201.allow.undo
 - undo/redo javadoc in model only
 - javadoc
 - the
 - review comments
 - ... and 11 more: https://git.openjdk.org/jfx/compare/11cff5d6...96453dba

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

Changes: https://git.openjdk.org/jfx/pull/1941/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1941&range=11
  Stats: 313 lines in 17 files changed: 239 ins; 6 del; 68 mod
  Patch: https://git.openjdk.org/jfx/pull/1941.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1941/head:pull/1941

PR: https://git.openjdk.org/jfx/pull/1941

From angorya at openjdk.org  Thu Nov  6 15:41:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 15:41:12 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v11]
In-Reply-To: <AoXRKeG6DewcdJH0OswKJlSdH6mzXilManxoOXyagoU=.cb8049ca-841d-4c95-886e-678e848d4a23@github.com>
References: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
 <qs8jE5IgmH5OAiM1Gq84NCUtGYKA7rMM4jJ5MI-aW8I=.35573598-02dd-42c8-8be2-bffdf69e431d@github.com>
 <AoXRKeG6DewcdJH0OswKJlSdH6mzXilManxoOXyagoU=.cb8049ca-841d-4c95-886e-678e848d4a23@github.com>
Message-ID: <anugmdcpo9ssWffFAWNWwi9lAhcf7pDjWl9Y5Mf9frw=.db316f73-1bb2-4cb5-aa06-2009d00867d8@github.com>

On Thu, 6 Nov 2025 13:23:01 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 103:
> 
>> 101:  *   // build the content
>> 102:  *   textArea.setUndoRedoEnabled(false);
>> 103:  *   textArea.appendText("RichTextArea\n", heading, false);
> 
> We don't pass any per method undo/redo flag as argument in appendText.
> This needs to be updated.

good catch!  these code blocks are not checked by the `javadoc` tool.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2499499082

From angorya at openjdk.org  Thu Nov  6 16:10:42 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 16:10:42 GMT
Subject: RFR: 8366202: RichTextArea: wrong style used for typed text [v3]
In-Reply-To: <fj93lFFO8Cdvz1EmCoLpp0FztM2P8LJ0EuJW-NYtYys=.d8f82a1b-a3b6-42d6-9d06-86b12e082ad9@github.com>
References: <jXJWCEH5_QG54daSS3iS1-iTOC39YN8OTxIQlkOVvJQ=.7599c825-0466-43bf-9c4f-5f225a4a7090@github.com>
 <TLf7tNmPvOMnMj9HuMseOTezIxNHhuh53fd_rJYzO9c=.9a4ef33a-34af-42fb-9039-8f9e0c94b912@github.com>
 <fj93lFFO8Cdvz1EmCoLpp0FztM2P8LJ0EuJW-NYtYys=.d8f82a1b-a3b6-42d6-9d06-86b12e082ad9@github.com>
Message-ID: <dPaEkMD0exlfIGAZPqEDyie434kKbarDs3AVm0Hj6v8=.fa251b42-d11c-4104-b3cf-c13384058b7e@github.com>

On Mon, 3 Nov 2025 12:51:20 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Andy Goryachev 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 8366202.wrong
>>  - review comments
>>  - wrong style
>
> The test works fine, I tried it in the RTA Demo and adding text in middle of sentence keeps the styles of the preceding text.
> 
> I noticed one thing is that when clicking at the end of a line of text (or anywhere in the middle) and then changing the color or style it changes the whole line style and color, shouldn't the new color and style be applied on the newly typed text only and not change the existing text color? 
> This happens also on master so maybe it's not related to this issue directly
> steps to reproduce :
> 
> 1. Write "testing testing testing"
> 2. click somewhere on this text without selecting any text
> 3. change color
> 4. notice the whole text is changing color (normally it shouldn't change colors of the existing text only the newly typed text)

@Ziad-Mid please re-review.  thanks!

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

PR Comment: https://git.openjdk.org/jfx/pull/1950#issuecomment-3498082816

From jhendrikx at openjdk.org  Thu Nov  6 16:04:40 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 6 Nov 2025 16:04:40 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: <z--N5xCX44yUlDPW-VE5vACztUNRtwXYxXbUgHE1tkc=.c6a19cfc-1844-4260-bce4-a616af09444c@github.com>
References: <LwnBiVMOfsnBlKPaSv_P99MdGLTYFzV282agrWuXZvM=.45a4b546-241f-4754-99b8-6ed5dee81ab6@github.com>
 <wPAA9aAnrNklGwk5c8pJLmhxYd8nL4-Z8_GCILQ8whc=.53900459-2846-4d41-aea4-20ab809abf9f@github.com>
 <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>
 <ZQ71ynBU_Wx2dy03O-mv7shOHgybV7R4li7t1OIWEyU=.b2c4b23e-e7bb-4429-878d-3e685bfc541f@github.com>
 <z--N5xCX44yUlDPW-VE5vACztUNRtwXYxXbUgHE1tkc=.c6a19cfc-1844-4260-bce4-a616af09444c@github.com>
Message-ID: <FRUKzA5osqFqoZDhVx-9QgEPqT6-7DUkcANJ8ulleTM=.9f679f4f-1c0f-4a61-9a56-988e84c6c003@github.com>

On Tue, 28 Oct 2025 15:40:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > I'll see if I can reproduce the menu issue and what is the culprit there.
> 
> Thanks! For what it's worth, the issue also appears when I move the window from the main retina screen (scale=2) to an external monitor (scale=1). I would imagine it should be easy to reproduce on Windows, especially with a fractional scale.

@andy-goryachev-oracle I ran the Monkey Tester with the changes, and also created a menu in my own test program, but I'm not seeing any issues on Windows.  I have a 3 monitor setup, 2x 150%, 1x 100%

I'll take a look at the `MenuBar` code directly and see if I can spot problems, and perhaps add some debug logs in this branch.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3498044702

From aghaisas at openjdk.org  Thu Nov  6 16:22:58 2025
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 6 Nov 2025 16:22:58 GMT
Subject: RFR: 8371080: RichTextArea: missing styles in Caspian
In-Reply-To: <14Fv8RMnNEHSsBpXqu4G11ITFEt_ETTmBZ8OTJaoptM=.9ecc21e1-6664-425f-b472-03849e3d069f@github.com>
References: <14Fv8RMnNEHSsBpXqu4G11ITFEt_ETTmBZ8OTJaoptM=.9ecc21e1-6664-425f-b472-03849e3d069f@github.com>
Message-ID: <05zE6860YTuPOgSIECEfvQkvH2vh8aSeuHvStWkRQuM=.224109ad-4508-457c-9232-461306556bcf@github.com>

On Mon, 3 Nov 2025 19:49:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Added missing RichTextArea styles to `caspian.css`.
> 
> This is a trivial change.
> 
> To test, one can use the latest Monkey Tester Window -> Stylesheet menu.
> https://github.com/andy-goryachev-oracle/MonkeyTest
> 
> <img width="1021" height="350" alt="Screenshot 2025-11-03 at 11 50 50" src="https://github.com/user-attachments/assets/8559e702-5294-4a98-a251-f3b2283d7a83" />

I tested with the provided MonkeyTester application and can confirm that the RichTextArea control honors the Caspian styles with this change.

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

Marked as reviewed by aghaisas (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1959#pullrequestreview-3429170025

From angorya at openjdk.org  Thu Nov  6 16:31:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 16:31:56 GMT
Subject: RFR: 8371080: RichTextArea: missing styles in Caspian
In-Reply-To: <14Fv8RMnNEHSsBpXqu4G11ITFEt_ETTmBZ8OTJaoptM=.9ecc21e1-6664-425f-b472-03849e3d069f@github.com>
References: <14Fv8RMnNEHSsBpXqu4G11ITFEt_ETTmBZ8OTJaoptM=.9ecc21e1-6664-425f-b472-03849e3d069f@github.com>
Message-ID: <ZKeiXWC27JM05n8sZewlNLciuPiP4XE3WkaiHsN1T8s=.7cb486fe-5b15-4ef6-b4a7-0607445d8b86@github.com>

On Mon, 3 Nov 2025 19:49:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Added missing RichTextArea styles to `caspian.css`.
> 
> This is a trivial change.
> 
> To test, one can use the latest Monkey Tester Window -> Stylesheet menu.
> https://github.com/andy-goryachev-oracle/MonkeyTest
> 
> <img width="1021" height="350" alt="Screenshot 2025-11-03 at 11 50 50" src="https://github.com/user-attachments/assets/8559e702-5294-4a98-a251-f3b2283d7a83" />

Thank you Ajit!

This is a trivial change, one reviewer should be ok.

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

PR Comment: https://git.openjdk.org/jfx/pull/1959#issuecomment-3498200802

From angorya at openjdk.org  Thu Nov  6 16:31:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 16:31:57 GMT
Subject: Integrated: 8371080: RichTextArea: missing styles in Caspian
In-Reply-To: <14Fv8RMnNEHSsBpXqu4G11ITFEt_ETTmBZ8OTJaoptM=.9ecc21e1-6664-425f-b472-03849e3d069f@github.com>
References: <14Fv8RMnNEHSsBpXqu4G11ITFEt_ETTmBZ8OTJaoptM=.9ecc21e1-6664-425f-b472-03849e3d069f@github.com>
Message-ID: <IxRnE35FnLmMWzOZrbe4-ATlZxIZcQ3sFpHaEkSr8yk=.7a51c310-dd58-4914-9fc2-57df1b00238b@github.com>

On Mon, 3 Nov 2025 19:49:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Added missing RichTextArea styles to `caspian.css`.
> 
> This is a trivial change.
> 
> To test, one can use the latest Monkey Tester Window -> Stylesheet menu.
> https://github.com/andy-goryachev-oracle/MonkeyTest
> 
> <img width="1021" height="350" alt="Screenshot 2025-11-03 at 11 50 50" src="https://github.com/user-attachments/assets/8559e702-5294-4a98-a251-f3b2283d7a83" />

This pull request has now been integrated.

Changeset: 5684edf7
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/5684edf79b84bb62cde988e3f53b40cdbb6b22b6
Stats:     80 lines in 1 file changed: 79 ins; 0 del; 1 mod

8371080: RichTextArea: missing styles in Caspian

Reviewed-by: aghaisas

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

PR: https://git.openjdk.org/jfx/pull/1959

From angorya at openjdk.org  Thu Nov  6 17:19:43 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 17:19:43 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes
In-Reply-To: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
Message-ID: <g6O-rdxJBHKCiH5WgTOwa2pVqlRU5prFazlpsPv72y8=.81fbdfe4-7549-48ca-922b-d1e19c8969fd@github.com>

On Wed, 5 Nov 2025 12:32:09 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds the missing native implementation for Windows, `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running, in a similar way as Java Desktop [handles](https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L1418) this DPI event.
> 
> When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well.
> 
> The change in `Screen:: notifySettingsChanged` is needed in order to prevent disposing screens that are not referenced by windows, and only do it when the screen instance of a given window does change.
> 
> There are no tests added to this PR, since these would require manual intervention to change the resolution of the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. It has also been tested that it doesn't have any side effect on macOS.
> 
> For the case when the app runs on a different display that the one that was changed, see https://bugs.openjdk.org/browse/JDK-8371302 and a possible fix with https://github.com/openjdk/jfx/pull/1963.

no ill effects on macOS 15.7.1, will test on windows shortly

modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 824:

> 822: {
> 823:     JNIEnv* env = GetEnv();
> 824:     float scale = (float) LOWORD(wParam) / (float) USER_DEFAULT_SCREEN_DPI;

could we simply declare `USER_DEFAULT_SCREEN_DPI` to be a `float`?

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

PR Review: https://git.openjdk.org/jfx/pull/1964#pullrequestreview-3429420777
PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2499938939

From angorya at openjdk.org  Thu Nov  6 18:37:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 18:37:21 GMT
Subject: RFR: 8371302: [Windows] Stage coordinates in secondary display are
 not properly updated after changing settings of first display
In-Reply-To: <CR0CQX9O56oytMISf8D6Bdsnt9U0uPBr0NMsQPIv5Ls=.1be06b8c-8f09-44d9-ba74-39a7feee7db9@github.com>
References: <CR0CQX9O56oytMISf8D6Bdsnt9U0uPBr0NMsQPIv5Ls=.1be06b8c-8f09-44d9-ba74-39a7feee7db9@github.com>
Message-ID: <B9rrxaC7oJxPuBzqtothaR0Zsgh3IyQgr4K6OZ8-Nt4=.d6654118-59d8-48ef-b7ab-441cf38d3f7a@github.com>

On Wed, 5 Nov 2025 11:44:40 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR handles two windows events, `WM_DISPLAYCHANGE` and `WM_SETTINGCHANGE`, that can be received by a JavaFX Window on a given display when other display changed its settings (resolution), or both displays were rearranged, and therefore its location has changed. 
> 
> When this happens, `com.sun.glass.ui.Window` has the new updated location, but the `javafx.stage.Window` does not, and triggering a `Window.MOVE` event notifies the stage to update its location accordingly.
> 
> There are no tests added to this PR (those would require two monitors, and external changes of Windows Settings), but the [test](https://bugs.openjdk.org/secure/attachment/116917/RenderScaleTest.java) attached to the JBS issue passes after this PR running some manual tests: for the stage at secondary display, check that the location is updated properly and the context menu shows up at the expected position, when the primary display resolution changes via Settings->System->Display->Scale, or when both displays are rearranged via Settings->System->Display->Drag to rearrange.

For testing, I've added the scale/size/position info to the main window status bar in the monkey tester:
https://github.com/andy-goryachev-oracle/MonkeyTest

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

PR Comment: https://git.openjdk.org/jfx/pull/1963#issuecomment-3498830263

From jpereda at openjdk.org  Thu Nov  6 19:01:30 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 6 Nov 2025 19:01:30 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes
In-Reply-To: <g6O-rdxJBHKCiH5WgTOwa2pVqlRU5prFazlpsPv72y8=.81fbdfe4-7549-48ca-922b-d1e19c8969fd@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <g6O-rdxJBHKCiH5WgTOwa2pVqlRU5prFazlpsPv72y8=.81fbdfe4-7549-48ca-922b-d1e19c8969fd@github.com>
Message-ID: <fwEbqNrPJqeCg-BQPF3s08ICLWQFmBmA71idswDQLNM=.56ba60d8-d781-44f8-a61e-ba5aa9491a47@github.com>

On Thu, 6 Nov 2025 17:04:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR adds the missing native implementation for Windows, `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running, in a similar way as Java Desktop [handles](https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L1418) this DPI event.
>> 
>> When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well.
>> 
>> The change in `Screen:: notifySettingsChanged` is needed in order to prevent disposing screens that are not referenced by windows, and only do it when the screen instance of a given window does change.
>> 
>> There are no tests added to this PR, since these would require manual intervention to change the resolution of the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. It has also been tested that it doesn't have any side effect on macOS.
>> 
>> For the case when the app runs on a different display that the one that was changed, see https://bugs.openjdk.org/browse/JDK-8371302 and a possible fix with https://github.com/openjdk/jfx/pull/1963.
>
> modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 824:
> 
>> 822: {
>> 823:     JNIEnv* env = GetEnv();
>> 824:     float scale = (float) LOWORD(wParam) / (float) USER_DEFAULT_SCREEN_DPI;
> 
> could we simply declare `USER_DEFAULT_SCREEN_DPI` to be a `float`?

No need, I've removed the casting, it wasn't needed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2500423818

From jpereda at openjdk.org  Thu Nov  6 19:01:28 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 6 Nov 2025 19:01:28 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes
In-Reply-To: <MorKUsTSgxPY4sO2mu7nfVYYSn_60u03QdaTZ_YAhFo=.4d8e9009-034b-4585-90ae-c977cea5a035@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <MorKUsTSgxPY4sO2mu7nfVYYSn_60u03QdaTZ_YAhFo=.4d8e9009-034b-4585-90ae-c977cea5a035@github.com>
Message-ID: <Jd_8pze_k_gbCiHiGOoGattWMcWXWJgWJl4DCHnpghk=.35cc42d4-fbc7-4a50-a25c-a1a197751684@github.com>

On Wed, 5 Nov 2025 13:52:00 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR adds the missing native implementation for Windows, `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running, in a similar way as Java Desktop [handles](https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L1418) this DPI event.
>> 
>> When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well.
>> 
>> The change in `Screen:: notifySettingsChanged` is needed in order to prevent disposing screens that are not referenced by windows, and only do it when the screen instance of a given window does change.
>> 
>> There are no tests added to this PR, since these would require manual intervention to change the resolution of the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. It has also been tested that it doesn't have any side effect on macOS.
>> 
>> For the case when the app runs on a different display that the one that was changed, see https://bugs.openjdk.org/browse/JDK-8371302 and a possible fix with https://github.com/openjdk/jfx/pull/1963.
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Screen.java line 374:
> 
>> 372:     public static void notifySettingsChanged() {
>> 373:         // Save the old screens in order to dispose them later
>> 374:         List<Screen> oldScreens = new ArrayList<>();
> 
> This could also be a `Set`, which then handles duplicates without the need for `contains`

Done

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2500422693

From angorya at openjdk.org  Thu Nov  6 19:11:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 19:11:21 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes
In-Reply-To: <fwEbqNrPJqeCg-BQPF3s08ICLWQFmBmA71idswDQLNM=.56ba60d8-d781-44f8-a61e-ba5aa9491a47@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <g6O-rdxJBHKCiH5WgTOwa2pVqlRU5prFazlpsPv72y8=.81fbdfe4-7549-48ca-922b-d1e19c8969fd@github.com>
 <fwEbqNrPJqeCg-BQPF3s08ICLWQFmBmA71idswDQLNM=.56ba60d8-d781-44f8-a61e-ba5aa9491a47@github.com>
Message-ID: <12LNXOnh47WzhGRzoKkADBMR2SPfA1L1Ij26XVYee2A=.0579c029-b187-4046-9459-b96b657a979d@github.com>

On Thu, 6 Nov 2025 18:58:15 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 824:
>> 
>>> 822: {
>>> 823:     JNIEnv* env = GetEnv();
>>> 824:     float scale = (float) LOWORD(wParam) / (float) USER_DEFAULT_SCREEN_DPI;
>> 
>> could we simply declare `USER_DEFAULT_SCREEN_DPI` to be a `float`?
>
> No need, I've removed the casting, it wasn't needed.

if you declare this constant as float, you won't have to cast and it won't be converted each time it's used.  saves 0.3 nanoseconds!  :-)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2500455779

From kcr at openjdk.org  Thu Nov  6 19:18:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 6 Nov 2025 19:18:19 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes
In-Reply-To: <12LNXOnh47WzhGRzoKkADBMR2SPfA1L1Ij26XVYee2A=.0579c029-b187-4046-9459-b96b657a979d@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <g6O-rdxJBHKCiH5WgTOwa2pVqlRU5prFazlpsPv72y8=.81fbdfe4-7549-48ca-922b-d1e19c8969fd@github.com>
 <fwEbqNrPJqeCg-BQPF3s08ICLWQFmBmA71idswDQLNM=.56ba60d8-d781-44f8-a61e-ba5aa9491a47@github.com>
 <12LNXOnh47WzhGRzoKkADBMR2SPfA1L1Ij26XVYee2A=.0579c029-b187-4046-9459-b96b657a979d@github.com>
Message-ID: <EdO9OA9L6NrfR6-pdj_CGMBzFa944EbQNskBE5SmeAc=.50772594-61cb-4970-954e-0c3fea88df76@github.com>

On Thu, 6 Nov 2025 19:08:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> No need, I've removed the casting, it wasn't needed.
>
> if you declare this constant as float, you won't have to cast and it won't be converted each time it's used.  saves 0.3 nanoseconds!  :-)

The cast will almost certainly be done at compile time, so it is fine as is.

More importantly, I see that the constant is in an `ifndef`. Presuming that if the constant exists in the header file, it would be defined as an int, it would be wrong to define it as a float in the ifndef case.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2500482084

From angorya at openjdk.org  Thu Nov  6 19:39:18 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 19:39:18 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes
In-Reply-To: <Jd_8pze_k_gbCiHiGOoGattWMcWXWJgWJl4DCHnpghk=.35cc42d4-fbc7-4a50-a25c-a1a197751684@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <MorKUsTSgxPY4sO2mu7nfVYYSn_60u03QdaTZ_YAhFo=.4d8e9009-034b-4585-90ae-c977cea5a035@github.com>
 <Jd_8pze_k_gbCiHiGOoGattWMcWXWJgWJl4DCHnpghk=.35cc42d4-fbc7-4a50-a25c-a1a197751684@github.com>
Message-ID: <b3P-aje9e5y62k6cYapcASV4eAE-coCRWkz4tAf2N7c=.485ed844-aa90-4202-b5a9-b74fe4eadb2d@github.com>

On Thu, 6 Nov 2025 18:57:52 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Screen.java line 374:
>> 
>>> 372:     public static void notifySettingsChanged() {
>>> 373:         // Save the old screens in order to dispose them later
>>> 374:         List<Screen> oldScreens = new ArrayList<>();
>> 
>> This could also be a `Set`, which then handles duplicates without the need for `contains`
>
> Done

Can you push the changes to the repo please?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2500551954

From angorya at openjdk.org  Thu Nov  6 19:46:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 19:46:19 GMT
Subject: RFR: 8371302: [Windows] Stage coordinates in secondary display are
 not properly updated after changing settings of first display
In-Reply-To: <CR0CQX9O56oytMISf8D6Bdsnt9U0uPBr0NMsQPIv5Ls=.1be06b8c-8f09-44d9-ba74-39a7feee7db9@github.com>
References: <CR0CQX9O56oytMISf8D6Bdsnt9U0uPBr0NMsQPIv5Ls=.1be06b8c-8f09-44d9-ba74-39a7feee7db9@github.com>
Message-ID: <I7CcfUpHrYv1rKwziAeZPcoR5Ct9DLDuTKBK9PklOa4=.82985a8d-701a-40df-b94d-e48995e164a4@github.com>

On Wed, 5 Nov 2025 11:44:40 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR handles two windows events, `WM_DISPLAYCHANGE` and `WM_SETTINGCHANGE`, that can be received by a JavaFX Window on a given display when other display changed its settings (resolution), or both displays were rearranged, and therefore its location has changed. 
> 
> When this happens, `com.sun.glass.ui.Window` has the new updated location, but the `javafx.stage.Window` does not, and triggering a `Window.MOVE` event notifies the stage to update its location accordingly.
> 
> There are no tests added to this PR (those would require two monitors, and external changes of Windows Settings), but the [test](https://bugs.openjdk.org/secure/attachment/116917/RenderScaleTest.java) attached to the JBS issue passes after this PR running some manual tests: for the stage at secondary display, check that the location is updated properly and the context menu shows up at the expected position, when the primary display resolution changes via Settings->System->Display->Scale, or when both displays are rearranged via Settings->System->Display->Drag to rearrange.

Tested on windows, using the latest master + this PR + #1964 

The windows, their child windows, their popup menus all work as expected when changing scale and adjusting relative position of the monitors.  

Excellent work chasing all these issues!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1963#pullrequestreview-3430209530

From kcr at openjdk.org  Thu Nov  6 19:47:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 6 Nov 2025 19:47:27 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v12]
In-Reply-To: <-5RQhssjbuZbj2zWEB4TYXgNOUVModpvsFaJVVfVl1I=.2356192e-77d3-4949-beeb-9b643a05a0f7@github.com>
References: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
 <-5RQhssjbuZbj2zWEB4TYXgNOUVModpvsFaJVVfVl1I=.2356192e-77d3-4949-beeb-9b643a05a0f7@github.com>
Message-ID: <BPJynCONdfEBASrFWXq0jtzp7HypVm4Amwjz6ihUE7I=.102940ec-76f5-4929-990d-ee3529416a32@github.com>

On Thu, 6 Nov 2025 15:41:09 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - review comments
>  - Merge branch 'master' into 8366201.allow.undo
>  - javadoc
>  - suggestion
>    
>    Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
>  - set text
>  - Merge branch 'master' into 8366201.allow.undo
>  - undo/redo javadoc in model only
>  - javadoc
>  - the
>  - review comments
>  - ... and 11 more: https://git.openjdk.org/jfx/compare/11cff5d6...96453dba

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1941#pullrequestreview-3430213655

From angorya at openjdk.org  Thu Nov  6 19:49:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 19:49:16 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes
In-Reply-To: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
Message-ID: <djxjejgLvm4wvTycPV_PPUjVHvozTCp2MSzZLwtVqS4=.53cc8c05-ca8a-4b95-84fa-1afd65110500@github.com>

On Wed, 5 Nov 2025 12:32:09 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds the missing native implementation for Windows, `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running, in a similar way as Java Desktop [handles](https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L1418) this DPI event.
> 
> When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well.
> 
> The change in `Screen:: notifySettingsChanged` is needed in order to prevent disposing screens that are not referenced by windows, and only do it when the screen instance of a given window does change.
> 
> There are no tests added to this PR, since these would require manual intervention to change the resolution of the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. It has also been tested that it doesn't have any side effect on macOS.
> 
> For the case when the app runs on a different display that the one that was changed, see https://bugs.openjdk.org/browse/JDK-8371302 and a possible fix with https://github.com/openjdk/jfx/pull/1963.

Tested on windows in combination with #1963 , good job!

(I'll reapprove if/when you push the `Set` changes)

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1964#pullrequestreview-3430220201

From kcr at openjdk.org  Thu Nov  6 19:59:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 6 Nov 2025 19:59:21 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v11]
In-Reply-To: <mBHaheyq-KrBlvXhtIpMUx77mKqNxku7gdGkUMAcuzo=.63776f3f-23ae-4388-8f6a-27bf4170cd64@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <mBHaheyq-KrBlvXhtIpMUx77mKqNxku7gdGkUMAcuzo=.63776f3f-23ae-4388-8f6a-27bf4170cd64@github.com>
Message-ID: <3ZJY-Ajf-YDXZiECDqbIP-o-dS4la2NMxGn2yBTSMHk=.c7974ad1-b184-4212-91fd-7c4f161d5b83@github.com>

On Wed, 5 Nov 2025 21:00:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
>> 
>> The impacted areas are:
>> - saving to plain text
>> - copying to plain text
>> - IME
>> 
>> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), with convenience setter and getter in the `RichTextArea`.
>> 
>> ### NOTES
>> 
>> - some dependency on #1938 , resolved.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed property

Looks good with a couple fairly minor comments inline.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/LineEnding.java line 36:

> 34:     /** Legacy Mac OS line ending, ASCII CR (0x0d). */
> 35:     CR,
> 36:     /** Windows line ending, ASCII LF (0x0a). */

The "ASCII LF (0x0a)" bit belongs to the `LF` enum value, not here.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/LineEnding.java line 38:

> 36:     /** Windows line ending, ASCII LF (0x0a). */
> 37:     CRLF,
> 38:     /** macOS/Unix line ending, sequence of CR/LF (0x0d 0x0a). */

The The "CR/LF (0x0d 0x0a)" bit belongs to the `CRLF` enum value, not here. While you are at it, maybe add "ASCII" before "CR/LF" for consistency?

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 1023:

> 1021:         if (lineEnding == null) {
> 1022:             lineEnding = LineEnding.SYSTEM;
> 1023:         }

This isn't needed, right? `lineEnding` can never be null as long as you initialize it to `LineEnding.SYSTEM `, since you check and throw on an attempt to set it to null.

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

PR Review: https://git.openjdk.org/jfx/pull/1944#pullrequestreview-3430225520
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2500587452
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2500590389
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2500604816

From angorya at openjdk.org  Thu Nov  6 20:06:42 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 20:06:42 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v12]
In-Reply-To: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
Message-ID: <Xg8XU7o7oDgJlI2xAE6zfQYUlmT1tBJgUSh8TaEipf4=.5522f313-6e5d-43ca-a70b-3886fcf9278f@github.com>

> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
> 
> The impacted areas are:
> - saving to plain text
> - copying to plain text
> - IME
> 
> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), with convenience setter and getter in the `RichTextArea`.
> 
> ### NOTES
> 
> - some dependency on #1938 , resolved.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge remote-tracking branch 'origin/master' into 8370140.line.separator
 - review comments
 - removed property
 - review comments
 - code area test
 - Merge branch 'master' into 8370140.line.separator
 - fixed tests
 - non-nullable
 - Merge branch 'master' into 8370140.line.separator
 - get text
 - ... and 6 more: https://git.openjdk.org/jfx/compare/5684edf7...285cf40e

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

Changes: https://git.openjdk.org/jfx/pull/1944/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=11
  Stats: 297 lines in 13 files changed: 265 ins; 11 del; 21 mod
  Patch: https://git.openjdk.org/jfx/pull/1944.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1944/head:pull/1944

PR: https://git.openjdk.org/jfx/pull/1944

From angorya at openjdk.org  Thu Nov  6 20:06:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 20:06:44 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v11]
In-Reply-To: <3ZJY-Ajf-YDXZiECDqbIP-o-dS4la2NMxGn2yBTSMHk=.c7974ad1-b184-4212-91fd-7c4f161d5b83@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <mBHaheyq-KrBlvXhtIpMUx77mKqNxku7gdGkUMAcuzo=.63776f3f-23ae-4388-8f6a-27bf4170cd64@github.com>
 <3ZJY-Ajf-YDXZiECDqbIP-o-dS4la2NMxGn2yBTSMHk=.c7974ad1-b184-4212-91fd-7c4f161d5b83@github.com>
Message-ID: <YNWvdI7OCdlMSd795TUDLRbrGBNxad-M4dji2Mx1pdc=.7681236e-e612-4bd3-81e6-1ec03cd05f91@github.com>

On Thu, 6 Nov 2025 19:53:28 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed property
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 1023:
> 
>> 1021:         if (lineEnding == null) {
>> 1022:             lineEnding = LineEnding.SYSTEM;
>> 1023:         }
> 
> This isn't needed, right? `lineEnding` can never be null as long as you initialize it to `LineEnding.SYSTEM `, since you check and throw on an attempt to set it to null.

tried to do a lazy init, but it's not that essential.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2500639682

From angorya at openjdk.org  Thu Nov  6 20:44:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 20:44:25 GMT
Subject: RFR: 8371386: Fix potential NPE in SwingNode
In-Reply-To: <l4a-jc7xeqRWm_plz2vkjX3yvJZxcqhQgxHTKGEZFhI=.842f452b-4b5e-4b8f-995f-fd205232c296@github.com>
References: <l4a-jc7xeqRWm_plz2vkjX3yvJZxcqhQgxHTKGEZFhI=.842f452b-4b5e-4b8f-995f-fd205232c296@github.com>
Message-ID: <qG9mhuUwjMvAlMmhKnaDrXbMw0oDGDSG9j7k0vM-O-k=.8efe31aa-fa80-4388-a22b-1d59df5dabd4@github.com>

On Thu, 6 Nov 2025 03:57:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> There can be potential NPEs in SwingNode which is fixed

modules/javafx.swing/src/main/java/javafx/embed/swing/SwingNode.java line 557:

> 555: 
> 556:     private final EventHandler<FocusUngrabEvent> ungrabHandler = event -> {
> 557:         var hFrame = lwFrame;

this can be pushed down to L559 - no need to create/assign if not needed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1965#discussion_r2500791603

From kcr at openjdk.org  Thu Nov  6 21:18:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 6 Nov 2025 21:18:18 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v12]
In-Reply-To: <Xg8XU7o7oDgJlI2xAE6zfQYUlmT1tBJgUSh8TaEipf4=.5522f313-6e5d-43ca-a70b-3886fcf9278f@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <Xg8XU7o7oDgJlI2xAE6zfQYUlmT1tBJgUSh8TaEipf4=.5522f313-6e5d-43ca-a70b-3886fcf9278f@github.com>
Message-ID: <4sjrnoyMWa59gFn1RXC5WvOJVbtY1yxT-t5XxkNLbZs=.fa5991f5-c0e2-4400-a5bf-a144d17e88a7@github.com>

On Thu, 6 Nov 2025 20:06:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
>> 
>> The impacted areas are:
>> - saving to plain text
>> - copying to plain text
>> - IME
>> 
>> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), with convenience setter and getter in the `RichTextArea`.
>> 
>> ### NOTES
>> 
>> - some dependency on #1938 , resolved.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8370140.line.separator
>  - review comments
>  - removed property
>  - review comments
>  - code area test
>  - Merge branch 'master' into 8370140.line.separator
>  - fixed tests
>  - non-nullable
>  - Merge branch 'master' into 8370140.line.separator
>  - get text
>  - ... and 6 more: https://git.openjdk.org/jfx/compare/5684edf7...285cf40e

Looks good. I left one minor comment, but will approve as is. Will reapprove if you decide to make changes.

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/support/RTUtil.java line 88:

> 86:         ByteArrayOutputStream out = new ByteArrayOutputStream();
> 87:         try {
> 88:             try {

Minor: you don't need two levels of try here. Even better, you can use try with resources instead of adding finally clause.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1944#pullrequestreview-3430574192
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2500877917

From angorya at openjdk.org  Thu Nov  6 21:23:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 21:23:53 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v13]
In-Reply-To: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
Message-ID: <gK-xkPBmlT_QvJobvvh8eymF_bjCrcqGwaFcn0XlJjE=.d4bac700-21fe-4c35-bf69-adbe96a40e28@github.com>

> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
> 
> The impacted areas are:
> - saving to plain text
> - copying to plain text
> - IME
> 
> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), with convenience setter and getter in the `RichTextArea`.
> 
> ### NOTES
> 
> - some dependency on #1938 , resolved.

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

  try

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1944/files
  - new: https://git.openjdk.org/jfx/pull/1944/files/285cf40e..90c11101

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

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

PR: https://git.openjdk.org/jfx/pull/1944

From angorya at openjdk.org  Thu Nov  6 21:29:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 21:29:54 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v14]
In-Reply-To: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
Message-ID: <IvzVPMvsmj5Q35-3Cw6yT9051Cv4qPKJmpsSv7poIcA=.19c33ec4-cba8-4861-a030-0febc2983b71@github.com>

> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
> 
> The impacted areas are:
> - saving to plain text
> - copying to plain text
> - IME
> 
> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), with convenience setter and getter in the `RichTextArea`.
> 
> ### NOTES
> 
> - some dependency on #1938 , resolved.

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

  rm property

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1944/files
  - new: https://git.openjdk.org/jfx/pull/1944/files/90c11101..4a3e1e32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=13
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=12-13

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

PR: https://git.openjdk.org/jfx/pull/1944

From jpereda at openjdk.org  Thu Nov  6 21:43:32 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 6 Nov 2025 21:43:32 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes [v2]
In-Reply-To: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
Message-ID: <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>

> This PR adds the missing native implementation for Windows, `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running, in a similar way as Java Desktop [handles](https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L1418) this DPI event.
> 
> When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well.
> 
> The change in `Screen:: notifySettingsChanged` is needed in order to prevent disposing screens that are not referenced by windows, and only do it when the screen instance of a given window does change.
> 
> There are no tests added to this PR, since these would require manual intervention to change the resolution of the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. It has also been tested that it doesn't have any side effect on macOS.
> 
> For the case when the app runs on a different display that the one that was changed, see https://bugs.openjdk.org/browse/JDK-8371302 and a possible fix with https://github.com/openjdk/jfx/pull/1963.

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

  Use set and remove unnecessary casting

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1964/files
  - new: https://git.openjdk.org/jfx/pull/1964/files/9ec63bb5..fbf6c6a3

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

  Stats: 8 lines in 2 files changed: 2 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1964.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1964/head:pull/1964

PR: https://git.openjdk.org/jfx/pull/1964

From angorya at openjdk.org  Thu Nov  6 21:43:32 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 21:43:32 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes [v2]
In-Reply-To: <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
Message-ID: <SwLeTKnmlRTuPdff6r4YUCyaykq8y9D5dQb-MHW9jMM=.5d67e6ad-9484-44d4-a547-45b2ed16f98c@github.com>

On Thu, 6 Nov 2025 21:40:51 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> This PR adds the missing native implementation for Windows, `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running, in a similar way as Java Desktop [handles](https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L1418) this DPI event.
>> 
>> When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well.
>> 
>> The change in `Screen:: notifySettingsChanged` is needed in order to prevent disposing screens that are not referenced by windows, and only do it when the screen instance of a given window does change.
>> 
>> There are no tests added to this PR, since these would require manual intervention to change the resolution of the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. It has also been tested that it doesn't have any side effect on macOS.
>> 
>> For the case when the app runs on a different display that the one that was changed, see https://bugs.openjdk.org/browse/JDK-8371302 and a possible fix with https://github.com/openjdk/jfx/pull/1963.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use set and remove unnecessary casting

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1964#pullrequestreview-3430672391

From jpereda at openjdk.org  Thu Nov  6 21:43:34 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 6 Nov 2025 21:43:34 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes
In-Reply-To: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
Message-ID: <5sXPGu6bxhNungOz4JWdbTs6eBYkbatbjmwhhrGTMD8=.eadee223-6f64-49e0-865e-27b39d2687fa@github.com>

On Wed, 5 Nov 2025 12:32:09 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds the missing native implementation for Windows, `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running, in a similar way as Java Desktop [handles](https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L1418) this DPI event.
> 
> When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well.
> 
> The change in `Screen:: notifySettingsChanged` is needed in order to prevent disposing screens that are not referenced by windows, and only do it when the screen instance of a given window does change.
> 
> There are no tests added to this PR, since these would require manual intervention to change the resolution of the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. It has also been tested that it doesn't have any side effect on macOS.
> 
> For the case when the app runs on a different display that the one that was changed, see https://bugs.openjdk.org/browse/JDK-8371302 and a possible fix with https://github.com/openjdk/jfx/pull/1963.

(Sorry, pushed now)

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

PR Comment: https://git.openjdk.org/jfx/pull/1964#issuecomment-3499493908

From angorya at openjdk.org  Thu Nov  6 22:00:18 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 22:00:18 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes [v2]
In-Reply-To: <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
Message-ID: <lwJtSQYQgheD50FxiEv9SFxhV6SH3sjuKGwqgwzwk0w=.6ff763c7-2186-4136-a661-f595ff744ac4@github.com>

On Thu, 6 Nov 2025 21:43:32 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> This PR adds the missing native implementation for Windows, `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running, in a similar way as Java Desktop [handles](https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L1418) this DPI event.
>> 
>> When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well.
>> 
>> The change in `Screen:: notifySettingsChanged` is needed in order to prevent disposing screens that are not referenced by windows, and only do it when the screen instance of a given window does change.
>> 
>> There are no tests added to this PR, since these would require manual intervention to change the resolution of the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. It has also been tested that it doesn't have any side effect on macOS.
>> 
>> For the case when the app runs on a different display that the one that was changed, see https://bugs.openjdk.org/browse/JDK-8371302 and a possible fix with https://github.com/openjdk/jfx/pull/1963.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use set and remove unnecessary casting

GHA failure in linux is intermittent https://bugs.openjdk.org/browse/JDK-8365551 , please ignore.

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

PR Comment: https://git.openjdk.org/jfx/pull/1964#issuecomment-3499541638

From kcr at openjdk.org  Thu Nov  6 22:11:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 6 Nov 2025 22:11:19 GMT
Subject: RFR: 8371386: Fix potential NPE in SwingNode
In-Reply-To: <l4a-jc7xeqRWm_plz2vkjX3yvJZxcqhQgxHTKGEZFhI=.842f452b-4b5e-4b8f-995f-fd205232c296@github.com>
References: <l4a-jc7xeqRWm_plz2vkjX3yvJZxcqhQgxHTKGEZFhI=.842f452b-4b5e-4b8f-995f-fd205232c296@github.com>
Message-ID: <wnpa4GkT4bjXtHn7UdFKgqPrKZYJXE-Uzs9uBSAsW9E=.202c3b2b-ee7f-47ac-a589-8616590cf3b6@github.com>

On Thu, 6 Nov 2025 03:57:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> There can be potential NPEs in SwingNode which is fixed

The changes look reasonable, for a start. I decided to look more closely at the threads the methods are being called on, and I found two related threading problems and one more place where you should locally capture `lwFrame`.

### Methods called on wrong thread

#### notifyNativeHandle

The `notifyNativeHandle` method is meant to be called on the FX thread. Two of the three call sites are correct, but one of them incorrectly calls it from the EDT:


    /*
     * Called on EDT
     */
    private void setContentImpl(JComponent content) {
            ...

            if (getScene() != null) {
                notifyNativeHandle(getScene().getWindow());
            }


Since, the very next line of code in this method executes a block on the FX app thread, it should be as simple as moving the above block into the body of the `runOnFxThread` immediately below it.

#### locateLwFrame

The `locateLwFrame` method is meant to be called on the FX thread. Three of the four call sites are correct, but one of them incorrectly calls it from the EDT:


            SwingNodeHelper.runOnEDT(() -> {
                if (lwFrame != null) {
                    locateLwFrame();
                }
            });


For some reason this code goes out of its way to jump on the EDT to call a method that is called from the FX thread in all other cases. Removing the runOnEDT call should be the right fix. Also, the check for `lwFrame != null` is unnecessary here. `locateLwFrame` already checks for null (and none of the other 3 callers of that method check prior to calling).


### Local capture of `lwFrame` needed

The `windowHiddenHandler` lambda is called on the FX thread. As such, the following is one more place where you should capture `lwFrame` into a local variable so you can test it for non-null and then be sure you are using that still non-null value:


                if (isThreadMerged) {
                    swNodeIOP.overrideNativeWindowHandle(lwFrame, 0L, null);


Suggestion:


                if (isThreadMerged) {
                    var hFrame = lwFrame;
                    If (hFrame != null) {
                        swNodeIOP.overrideNativeWindowHandle(hFrame, 0L, null);
                    }

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

PR Review: https://git.openjdk.org/jfx/pull/1965#pullrequestreview-3430748790

From kcr at openjdk.org  Thu Nov  6 22:37:23 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 6 Nov 2025 22:37:23 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v14]
In-Reply-To: <IvzVPMvsmj5Q35-3Cw6yT9051Cv4qPKJmpsSv7poIcA=.19c33ec4-cba8-4861-a030-0febc2983b71@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <IvzVPMvsmj5Q35-3Cw6yT9051Cv4qPKJmpsSv7poIcA=.19c33ec4-cba8-4861-a030-0febc2983b71@github.com>
Message-ID: <5xkNK1cg0z0VXHC-TBP2bnnmNuijQ1a41S5EHtubHN4=.624d4617-3616-4c38-9b78-18eff1099200@github.com>

On Thu, 6 Nov 2025 21:29:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
>> 
>> The impacted areas are:
>> - saving to plain text
>> - copying to plain text
>> - IME
>> 
>> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), with convenience setter and getter in the `RichTextArea`.
>> 
>> ### NOTES
>> 
>> - some dependency on #1938 , resolved.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rm property

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1944#pullrequestreview-3430812450

From almatvee at openjdk.org  Thu Nov  6 23:35:18 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 6 Nov 2025 23:35:18 GMT
Subject: RFR: 8371052: Update libFFI to 3.5.2
In-Reply-To: <Cqt5whiDWoEQV8W3CXlq2PEkuEsv7k05hbLOXO547M4=.934ea1e3-bc87-447a-8ae6-20377363e836@github.com>
References: <EihmQlWsI1W2GLW_YDC8pOUhxQnzSfn4W5q1NvH2euM=.d769fa13-8113-43d1-8c37-1fcd849f653d@github.com>
 <Cqt5whiDWoEQV8W3CXlq2PEkuEsv7k05hbLOXO547M4=.934ea1e3-bc87-447a-8ae6-20377363e836@github.com>
Message-ID: <bGbkuq1X3oqjLhZqSiFUwpTs4EtKTAm9J0y0qm-e0Ck=.cfd4459b-3cc7-46d5-a205-1806cee9b61b@github.com>

On Thu, 6 Nov 2025 10:52:40 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> - Updated libFFI to 3.5.2.
>> - Tested on all platforms.
>> - No additional changes are done.
>
> modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/include/ffi_cfi.h line 74:
> 
>> 72: # define cfi_lsda(enc, exp)
>> 73: # define cfi_escape(...)
>> 74: # define cfi_window_save
> 
> The libffi 3.5.2 source contains a definition of `cfi_window_save` under `#ifdef HAVE_AS_CFI_PSEUDO_OP` as well. Could you please check.

This is how it is done in the original code. Two repeated definitions:
`# define cfi_window_save		.cfi_window_save` under `#ifdef HAVE_AS_CFI_PSEUDO_OP` and `# define cfi_window_save` otherwise. I was missing repeated `# define cfi_window_save		.cfi_window_save`. I will add it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1962#discussion_r2501210704

From angorya at openjdk.org  Thu Nov  6 23:37:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 23:37:22 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED [v2]
In-Reply-To: <lU2DPUg_0azYapE7yXf6IQR1kttgYg-WOsYLHhtoaGc=.0a105028-4ccc-4069-a41e-22b090d5f251@github.com>
References: <bIMP7awMNGUfYipsINgCBoQ24l8S7-r7BR-ksByEQq4=.2f4e676f-10dc-419c-9b48-f7d2c3a076a9@github.com>
 <lU2DPUg_0azYapE7yXf6IQR1kttgYg-WOsYLHhtoaGc=.0a105028-4ccc-4069-a41e-22b090d5f251@github.com>
Message-ID: <2S4V0uJ3wUvLsBgQ_mjwftAhIRjU1pXmS5SipiAAHRA=.040230cf-fc2b-465a-8154-041c00fc9894@github.com>

On Fri, 31 Oct 2025 00:07:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Adds the `DialogPane.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move HeaderBar to DialogPane

This might be a silly question: is there a need for split `HeaderBar`s?

modules/javafx.controls/src/main/java/javafx/scene/control/Dialog.java line 467:

> 465:      * Specifies the style for this dialog. This must be done prior to making the dialog visible.
> 466:      * <p>
> 467:      * Note that a dialog with the {@link StageStyle#EXTENDED} style must also specify a {@link HeaderBar} with

must or should?  meaning, is it a requirement, or just a warning?
if the latter, it might be better to say something like "the dialog will not be draggable if the header bar is not set"

modules/javafx.controls/src/main/java/javafx/scene/control/DialogPane.java line 1020:

> 1018:     /** {@inheritDoc} */
> 1019:     @Override protected double computeMinWidth(double height) {
> 1020:         double headerBarMinWidth = getHeaderBar() instanceof HeaderBar hb ? hb.minWidth(height) : 0;

clever!  :-)

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

PR Comment: https://git.openjdk.org/jfx/pull/1943#issuecomment-3499836327
PR Review Comment: https://git.openjdk.org/jfx/pull/1943#discussion_r2500831479
PR Review Comment: https://git.openjdk.org/jfx/pull/1943#discussion_r2500981553

From almatvee at openjdk.org  Thu Nov  6 23:44:17 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 6 Nov 2025 23:44:17 GMT
Subject: RFR: 8371052: Update libFFI to 3.5.2
In-Reply-To: <Cqt5whiDWoEQV8W3CXlq2PEkuEsv7k05hbLOXO547M4=.934ea1e3-bc87-447a-8ae6-20377363e836@github.com>
References: <EihmQlWsI1W2GLW_YDC8pOUhxQnzSfn4W5q1NvH2euM=.d769fa13-8113-43d1-8c37-1fcd849f653d@github.com>
 <Cqt5whiDWoEQV8W3CXlq2PEkuEsv7k05hbLOXO547M4=.934ea1e3-bc87-447a-8ae6-20377363e836@github.com>
Message-ID: <0m3o8lMpleyeH9nyCa2RaS01SB-TiNfrNg_nNMfB0DY=.6732b36d-912e-439d-9fe9-48a94ef7aa38@github.com>

On Thu, 6 Nov 2025 11:23:13 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> - Updated libFFI to 3.5.2.
>> - Tested on all platforms.
>> - No additional changes are done.
>
> modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/src/aarch64/internal.h line 93:
> 
>> 91:   #define SIGN_LR_LINUX_ONLY
>> 92: #define BRANCH_TO_REG braaz
>> 93:   #define PAC_CFI_WINDOW_SAVE
> 
> Minor: 
> Looks like the upstream libffi file has some specific space additions in this file to showcase nesting. So, to match it, Line 86 to 90, line 92, should also be modified to have prefixing space.
> Similar applies to line 135 to 142.
> 
> It may help reducing conflicts during next update.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1962#discussion_r2501225852

From angorya at openjdk.org  Thu Nov  6 23:59:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Nov 2025 23:59:22 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED [v2]
In-Reply-To: <lU2DPUg_0azYapE7yXf6IQR1kttgYg-WOsYLHhtoaGc=.0a105028-4ccc-4069-a41e-22b090d5f251@github.com>
References: <bIMP7awMNGUfYipsINgCBoQ24l8S7-r7BR-ksByEQq4=.2f4e676f-10dc-419c-9b48-f7d2c3a076a9@github.com>
 <lU2DPUg_0azYapE7yXf6IQR1kttgYg-WOsYLHhtoaGc=.0a105028-4ccc-4069-a41e-22b090d5f251@github.com>
Message-ID: <BujyNnWMpJPMRolxIMMoB2KGd94_1opk07y4EuqOXgo=.51a89fed-f658-4da4-b544-f710f80e4808@github.com>

On Fri, 31 Oct 2025 00:07:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Adds the `DialogPane.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move HeaderBar to DialogPane

For testing: added the header bar options to the Stage and Dialog pages:
https://github.com/andy-goryachev-oracle/MonkeyTest/tree/dialog.header.bar

Looks nice!

<img width="975" height="543" alt="Screenshot 2025-11-06 at 15 56 35" src="https://github.com/user-attachments/assets/0356b3bb-7c34-4dd2-a318-e61310495ff4" />

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

PR Comment: https://git.openjdk.org/jfx/pull/1943#issuecomment-3499882246
PR Comment: https://git.openjdk.org/jfx/pull/1943#issuecomment-3499887605

From kcr at openjdk.org  Fri Nov  7 00:05:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Nov 2025 00:05:20 GMT
Subject: RFR: 8371302: [Windows] Stage coordinates in secondary display are
 not properly updated after changing settings of first display
In-Reply-To: <CR0CQX9O56oytMISf8D6Bdsnt9U0uPBr0NMsQPIv5Ls=.1be06b8c-8f09-44d9-ba74-39a7feee7db9@github.com>
References: <CR0CQX9O56oytMISf8D6Bdsnt9U0uPBr0NMsQPIv5Ls=.1be06b8c-8f09-44d9-ba74-39a7feee7db9@github.com>
Message-ID: <HCITBX-9MVDPdlukzUDtWJJknQybvVtTbXfUNZ8sScw=.dc6bdbb0-e004-4e28-8b40-1746e335ee86@github.com>

On Wed, 5 Nov 2025 11:44:40 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR handles two windows events, `WM_DISPLAYCHANGE` and `WM_SETTINGCHANGE`, that can be received by a JavaFX Window on a given display when other display changed its settings (resolution), or both displays were rearranged, and therefore its location has changed. 
> 
> When this happens, `com.sun.glass.ui.Window` has the new updated location, but the `javafx.stage.Window` does not, and triggering a `Window.MOVE` event notifies the stage to update its location accordingly.
> 
> There are no tests added to this PR (those would require two monitors, and external changes of Windows Settings), but the [test](https://bugs.openjdk.org/secure/attachment/116917/RenderScaleTest.java) attached to the JBS issue passes after this PR running some manual tests: for the stage at secondary display, check that the location is updated properly and the context menu shows up at the expected position, when the primary display resolution changes via Settings->System->Display->Scale, or when both displays are rearranged via Settings->System->Display->Drag to rearrange.

The code changes look good. My initial testing looks good. I'll do some final testing tomorrow.

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

PR Review: https://git.openjdk.org/jfx/pull/1963#pullrequestreview-3431037495

From angorya at openjdk.org  Fri Nov  7 00:05:27 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Nov 2025 00:05:27 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED [v2]
In-Reply-To: <lU2DPUg_0azYapE7yXf6IQR1kttgYg-WOsYLHhtoaGc=.0a105028-4ccc-4069-a41e-22b090d5f251@github.com>
References: <bIMP7awMNGUfYipsINgCBoQ24l8S7-r7BR-ksByEQq4=.2f4e676f-10dc-419c-9b48-f7d2c3a076a9@github.com>
 <lU2DPUg_0azYapE7yXf6IQR1kttgYg-WOsYLHhtoaGc=.0a105028-4ccc-4069-a41e-22b090d5f251@github.com>
Message-ID: <0pP__xBvacVZkSXUgeuxXv_Sk-1mr1V2LO1R2AFoimc=.2c53d237-3c03-4ac5-b443-c4ebe5ce67c7@github.com>

On Fri, 31 Oct 2025 00:07:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Adds the `DialogPane.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move HeaderBar to DialogPane

I just wanted to mention a bit of asymmetry between the way header bars are added to the `Stage` vs. `Dialog`.  Probably nothing we could do here, and `DialogPane` property is the right approach.

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

PR Comment: https://git.openjdk.org/jfx/pull/1943#issuecomment-3499899614

From almatvee at openjdk.org  Fri Nov  7 00:05:59 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 7 Nov 2025 00:05:59 GMT
Subject: RFR: 8371052: Update libFFI to 3.5.2 [v2]
In-Reply-To: <EihmQlWsI1W2GLW_YDC8pOUhxQnzSfn4W5q1NvH2euM=.d769fa13-8113-43d1-8c37-1fcd849f653d@github.com>
References: <EihmQlWsI1W2GLW_YDC8pOUhxQnzSfn4W5q1NvH2euM=.d769fa13-8113-43d1-8c37-1fcd849f653d@github.com>
Message-ID: <6qUPKNTM1YxB1M4ArEvbgN45e_HqRzcDaqQ6NpUdlRg=.6d67057e-08c2-4f0b-be82-c8e7326cde26@github.com>

> - Updated libFFI to 3.5.2.
> - Tested on all platforms.
> - No additional changes are done.

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

  8371052: Update libFFI to 3.5.2 [v3]

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1962/files
  - new: https://git.openjdk.org/jfx/pull/1962/files/3d114a18..389dde1d

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

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

PR: https://git.openjdk.org/jfx/pull/1962

From almatvee at openjdk.org  Fri Nov  7 00:06:00 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 7 Nov 2025 00:06:00 GMT
Subject: RFR: 8371052: Update libFFI to 3.5.2
In-Reply-To: <EihmQlWsI1W2GLW_YDC8pOUhxQnzSfn4W5q1NvH2euM=.d769fa13-8113-43d1-8c37-1fcd849f653d@github.com>
References: <EihmQlWsI1W2GLW_YDC8pOUhxQnzSfn4W5q1NvH2euM=.d769fa13-8113-43d1-8c37-1fcd849f653d@github.com>
Message-ID: <yvw2kTFFuiszMdg41bYM1-xKCnESJv5Y12Cl1gv4STU=.ca1ce87a-887c-4fc7-9488-9186d4e7a1e7@github.com>

On Wed, 5 Nov 2025 02:17:39 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Updated libFFI to 3.5.2.
> - Tested on all platforms.
> - No additional changes are done.

8371052: Update libFFI to 3.5.2 [v3]
- Fixed latest comments.

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

PR Comment: https://git.openjdk.org/jfx/pull/1962#issuecomment-3499899347

From kcr at openjdk.org  Fri Nov  7 00:07:22 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Nov 2025 00:07:22 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes [v2]
In-Reply-To: <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
Message-ID: <v7OCI24Z_Tp1zQM5gvv-TKUGESIzt5Tp1ukgVAg9mRc=.51d6b3e5-8e98-4044-a9b7-d48a391f014f@github.com>

On Thu, 6 Nov 2025 21:43:32 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> This PR adds the missing native implementation for Windows, `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running, in a similar way as Java Desktop [handles](https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L1418) this DPI event.
>> 
>> When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well.
>> 
>> The change in `Screen:: notifySettingsChanged` is needed in order to prevent disposing screens that are not referenced by windows, and only do it when the screen instance of a given window does change.
>> 
>> There are no tests added to this PR, since these would require manual intervention to change the resolution of the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. It has also been tested that it doesn't have any side effect on macOS.
>> 
>> For the case when the app runs on a different display that the one that was changed, see https://bugs.openjdk.org/browse/JDK-8371302 and a possible fix with https://github.com/openjdk/jfx/pull/1963.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use set and remove unnecessary casting

The code changes look good. My initial testing looks good. I'll do some final testing tomorrow.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/Screen.java line 375:

> 373:     public static void notifySettingsChanged() {
> 374:         // Save the old screens in order to dispose them later
> 375:         Set<Screen> oldScreens = new HashSet<>();

Does the order matter? I don't think so, but if it does, `LinkedHashSet` would preserve the order.

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

PR Review: https://git.openjdk.org/jfx/pull/1964#pullrequestreview-3431020254
PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2501243856

From jpereda at openjdk.org  Fri Nov  7 00:35:19 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Fri, 7 Nov 2025 00:35:19 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes [v2]
In-Reply-To: <v7OCI24Z_Tp1zQM5gvv-TKUGESIzt5Tp1ukgVAg9mRc=.51d6b3e5-8e98-4044-a9b7-d48a391f014f@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
 <v7OCI24Z_Tp1zQM5gvv-TKUGESIzt5Tp1ukgVAg9mRc=.51d6b3e5-8e98-4044-a9b7-d48a391f014f@github.com>
Message-ID: <v8pmPkNdHf0ZWbWTD5OwAm_qrpc6_SdSZOKYiGBx5kY=.c0153534-0faf-43a7-b546-0af898f9fdff@github.com>

On Thu, 6 Nov 2025 23:53:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use set and remove unnecessary casting
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Screen.java line 375:
> 
>> 373:     public static void notifySettingsChanged() {
>> 374:         // Save the old screens in order to dispose them later
>> 375:         Set<Screen> oldScreens = new HashSet<>();
> 
> Does the order matter? I don't think so, but if it does, `LinkedHashSet` would preserve the order.

No, it doesn't matter. 

The old screens are "disposed" just by setting their native pointer to 0L, so they can't be reused, while the new screens instances are passed to the windows, to keep an updated instance. 

Note that even if old screen and new screen have the very same information (nothing changed for this particular screen), since `WinWindow::notifyMoving` uses the equality operator (`screen 1 == screen 2`), we need to keep a valid instance in `Window::screen`, and therefore `Screen::dispose` is just a way of invalidating old instances. Then, since they are no longer referenced by any window, they can be gc'ed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2501301032

From mstrauss at openjdk.org  Fri Nov  7 01:50:19 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 7 Nov 2025 01:50:19 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED [v2]
In-Reply-To: <2S4V0uJ3wUvLsBgQ_mjwftAhIRjU1pXmS5SipiAAHRA=.040230cf-fc2b-465a-8154-041c00fc9894@github.com>
References: <bIMP7awMNGUfYipsINgCBoQ24l8S7-r7BR-ksByEQq4=.2f4e676f-10dc-419c-9b48-f7d2c3a076a9@github.com>
 <lU2DPUg_0azYapE7yXf6IQR1kttgYg-WOsYLHhtoaGc=.0a105028-4ccc-4069-a41e-22b090d5f251@github.com>
 <2S4V0uJ3wUvLsBgQ_mjwftAhIRjU1pXmS5SipiAAHRA=.040230cf-fc2b-465a-8154-041c00fc9894@github.com>
Message-ID: <mn43qrwFqGpg4GWUMDixBcbawyzG7QdO7rpooR9FoBc=.73b0d85a-866b-4b36-a854-78a055221824@github.com>

On Thu, 6 Nov 2025 23:34:13 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This might be a silly question: is there a need for split `HeaderBar`s?

I don't think that this is very useful for `DialogPane`. A dialog is a pretty opinionated control; if users want this level of customization, it's probably better to use use a normal `Stage`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1943#issuecomment-3500121183

From mstrauss at openjdk.org  Fri Nov  7 01:54:56 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 7 Nov 2025 01:54:56 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED [v3]
In-Reply-To: <bIMP7awMNGUfYipsINgCBoQ24l8S7-r7BR-ksByEQq4=.2f4e676f-10dc-419c-9b48-f7d2c3a076a9@github.com>
References: <bIMP7awMNGUfYipsINgCBoQ24l8S7-r7BR-ksByEQq4=.2f4e676f-10dc-419c-9b48-f7d2c3a076a9@github.com>
Message-ID: <LhdiZKZ326XUR3iZp4Lwu75SkC1zc7gNiuY3BCeuEmA=.0251b616-54e6-413b-ab7c-7b1c9aa81495@github.com>

> Adds the `DialogPane.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style.

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

 - documentation
 - Merge branch 'master' into feature/extended-dialog
 - move HeaderBar to DialogPane
 - document/verify preview feature
 - Ensure that DialogPane is always attached to Scene
 - Lazily initialize Dialog.headerBar
 - Support dialogs with StageStyle.EXTENDED

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1943/files
  - new: https://git.openjdk.org/jfx/pull/1943/files/c85e8bb6..1cc864de

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

  Stats: 1592 lines in 50 files changed: 1245 ins; 133 del; 214 mod
  Patch: https://git.openjdk.org/jfx/pull/1943.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1943/head:pull/1943

PR: https://git.openjdk.org/jfx/pull/1943

From mstrauss at openjdk.org  Fri Nov  7 01:54:59 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 7 Nov 2025 01:54:59 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED [v2]
In-Reply-To: <2S4V0uJ3wUvLsBgQ_mjwftAhIRjU1pXmS5SipiAAHRA=.040230cf-fc2b-465a-8154-041c00fc9894@github.com>
References: <bIMP7awMNGUfYipsINgCBoQ24l8S7-r7BR-ksByEQq4=.2f4e676f-10dc-419c-9b48-f7d2c3a076a9@github.com>
 <lU2DPUg_0azYapE7yXf6IQR1kttgYg-WOsYLHhtoaGc=.0a105028-4ccc-4069-a41e-22b090d5f251@github.com>
 <2S4V0uJ3wUvLsBgQ_mjwftAhIRjU1pXmS5SipiAAHRA=.040230cf-fc2b-465a-8154-041c00fc9894@github.com>
Message-ID: <U1cbyMQIBxaaTyvSg7dTczoyT2K2_3QNSAuL3CyKhYM=.8665f6ab-597f-48f2-9c12-fbbc0ce5e7f6@github.com>

On Thu, 6 Nov 2025 20:54:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move HeaderBar to DialogPane
>
> modules/javafx.controls/src/main/java/javafx/scene/control/Dialog.java line 467:
> 
>> 465:      * Specifies the style for this dialog. This must be done prior to making the dialog visible.
>> 466:      * <p>
>> 467:      * Note that a dialog with the {@link StageStyle#EXTENDED} style must also specify a {@link HeaderBar} with
> 
> must or should?  meaning, is it a requirement, or just a warning?
> if the latter, it might be better to say something like "the dialog will not be draggable if the header bar is not set"

You're right, it's more like a warning. I've changed it to "should".

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1943#discussion_r2501422702

From psadhukhan at openjdk.org  Fri Nov  7 03:11:39 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Nov 2025 03:11:39 GMT
Subject: RFR: 8371386: Fix potential NPE in SwingNode [v2]
In-Reply-To: <l4a-jc7xeqRWm_plz2vkjX3yvJZxcqhQgxHTKGEZFhI=.842f452b-4b5e-4b8f-995f-fd205232c296@github.com>
References: <l4a-jc7xeqRWm_plz2vkjX3yvJZxcqhQgxHTKGEZFhI=.842f452b-4b5e-4b8f-995f-fd205232c296@github.com>
Message-ID: <TcbYQNxV6NF_-wW7jKWqrz_P_1_Y-pOg_N-Wlpm8TA0=.dd1e6cae-e14a-4d8a-9f93-d0f1f5726026@github.com>

> There can be potential NPEs in SwingNode which is fixed

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

  Review comment

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1965/files
  - new: https://git.openjdk.org/jfx/pull/1965/files/a493c346..00196134

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

  Stats: 18 lines in 1 file changed: 7 ins; 9 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1965.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1965/head:pull/1965

PR: https://git.openjdk.org/jfx/pull/1965

From psadhukhan at openjdk.org  Fri Nov  7 03:11:40 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Nov 2025 03:11:40 GMT
Subject: RFR: 8371386: Fix potential NPE in SwingNode
In-Reply-To: <l4a-jc7xeqRWm_plz2vkjX3yvJZxcqhQgxHTKGEZFhI=.842f452b-4b5e-4b8f-995f-fd205232c296@github.com>
References: <l4a-jc7xeqRWm_plz2vkjX3yvJZxcqhQgxHTKGEZFhI=.842f452b-4b5e-4b8f-995f-fd205232c296@github.com>
Message-ID: <_a1B_qKtod-ATL3WNRSY71iHeuM_pJ5hBovFjRrPfic=.97c9454e-9489-42eb-89cd-242a32f2361c@github.com>

On Thu, 6 Nov 2025 03:57:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> There can be potential NPEs in SwingNode which is fixed

Updated PR

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

PR Comment: https://git.openjdk.org/jfx/pull/1965#issuecomment-3500385402

From psadhukhan at openjdk.org  Fri Nov  7 03:11:41 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Nov 2025 03:11:41 GMT
Subject: RFR: 8371386: Fix potential NPE in SwingNode [v2]
In-Reply-To: <qG9mhuUwjMvAlMmhKnaDrXbMw0oDGDSG9j7k0vM-O-k=.8efe31aa-fa80-4388-a22b-1d59df5dabd4@github.com>
References: <l4a-jc7xeqRWm_plz2vkjX3yvJZxcqhQgxHTKGEZFhI=.842f452b-4b5e-4b8f-995f-fd205232c296@github.com>
 <qG9mhuUwjMvAlMmhKnaDrXbMw0oDGDSG9j7k0vM-O-k=.8efe31aa-fa80-4388-a22b-1d59df5dabd4@github.com>
Message-ID: <BcLKaiOCdjQ5cw4_BZw1KL3ve67C0AVY456lt6wxazk=.8fca91af-4277-418a-af66-ba0cf9c28e6e@github.com>

On Thu, 6 Nov 2025 20:41:49 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment
>
> modules/javafx.swing/src/main/java/javafx/embed/swing/SwingNode.java line 557:
> 
>> 555: 
>> 556:     private final EventHandler<FocusUngrabEvent> ungrabHandler = event -> {
>> 557:         var hFrame = lwFrame;
> 
> this can be pushed down to L559 - no need to create/assign if not needed.

ok

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1965#discussion_r2501528034

From jdv at openjdk.org  Fri Nov  7 06:29:24 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 7 Nov 2025 06:29:24 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v12]
In-Reply-To: <-5RQhssjbuZbj2zWEB4TYXgNOUVModpvsFaJVVfVl1I=.2356192e-77d3-4949-beeb-9b643a05a0f7@github.com>
References: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
 <-5RQhssjbuZbj2zWEB4TYXgNOUVModpvsFaJVVfVl1I=.2356192e-77d3-4949-beeb-9b643a05a0f7@github.com>
Message-ID: <JCCKerYF-jyFBCcwmzk1EeBTBFWrtbz8OzdbyGY8jd4=.55662beb-4010-4271-88b2-fe420a29e7e7@github.com>

On Thu, 6 Nov 2025 15:41:09 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - review comments
>  - Merge branch 'master' into 8366201.allow.undo
>  - javadoc
>  - suggestion
>    
>    Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
>  - set text
>  - Merge branch 'master' into 8366201.allow.undo
>  - undo/redo javadoc in model only
>  - javadoc
>  - the
>  - review comments
>  - ... and 11 more: https://git.openjdk.org/jfx/compare/11cff5d6...96453dba

We need to update the CSR.

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

Marked as reviewed by jdv (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1941#pullrequestreview-3431862317

From jhendrikx at openjdk.org  Fri Nov  7 06:36:56 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 7 Nov 2025 06:36:56 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v5]
In-Reply-To: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
Message-ID: <xFj5tbFYjL0_B1_XSon-D6rszuf-DD1SG5oWRCGhSao=.6b0a5776-b24d-4bb3-bd8a-2e10b2c48b81@github.com>

> This PR implements a new default method on `ObservableList` to be able to replace elements within a specified range.
> 
> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
> 
> The other alternative is to call `set` individually for each item, which results in many change notifications.
> 
> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
> 
> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.

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

  Explicitly document an empty range is allowed

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1937/files
  - new: https://git.openjdk.org/jfx/pull/1937/files/3e3bb966..980b3c54

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

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

PR: https://git.openjdk.org/jfx/pull/1937

From jdv at openjdk.org  Fri Nov  7 06:43:25 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 7 Nov 2025 06:43:25 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v14]
In-Reply-To: <IvzVPMvsmj5Q35-3Cw6yT9051Cv4qPKJmpsSv7poIcA=.19c33ec4-cba8-4861-a030-0febc2983b71@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <IvzVPMvsmj5Q35-3Cw6yT9051Cv4qPKJmpsSv7poIcA=.19c33ec4-cba8-4861-a030-0febc2983b71@github.com>
Message-ID: <82lauh3d7JrcVL9fXEJp3DMIGOKYTCt2cZkAz5iYVtw=.dfc63f4e-4cfc-482e-a616-7b66bb9adfe4@github.com>

On Thu, 6 Nov 2025 21:29:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
>> 
>> The impacted areas are:
>> - saving to plain text
>> - copying to plain text
>> - IME
>> 
>> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), with convenience setter and getter in the `RichTextArea`.
>> 
>> ### NOTES
>> 
>> - some dependency on #1938 , resolved.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rm property

Marked as reviewed by jdv (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1944#pullrequestreview-3431897182

From mstrauss at openjdk.org  Fri Nov  7 06:45:18 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 7 Nov 2025 06:45:18 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v5]
In-Reply-To: <xFj5tbFYjL0_B1_XSon-D6rszuf-DD1SG5oWRCGhSao=.6b0a5776-b24d-4bb3-bd8a-2e10b2c48b81@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <xFj5tbFYjL0_B1_XSon-D6rszuf-DD1SG5oWRCGhSao=.6b0a5776-b24d-4bb3-bd8a-2e10b2c48b81@github.com>
Message-ID: <KxRIwEsoxOrJciI_qOYW17zCL3aXL_YEc7tn71gdbEg=.97e8b569-2dc7-4e8e-a448-41e10c024680@github.com>

On Fri, 7 Nov 2025 06:36:56 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR implements a new default method on `ObservableList` to be able to replace elements within a specified range.
>> 
>> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
>> 
>> The other alternative is to call `set` individually for each item, which results in many change notifications.
>> 
>> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
>> 
>> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly document an empty range is allowed

Marked as reviewed by mstrauss (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1937#pullrequestreview-3431903506

From jhendrikx at openjdk.org  Fri Nov  7 09:07:20 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 7 Nov 2025 09:07:20 GMT
Subject: RFR: 8368629: Texture.update sometimes invoked for a disposed
 Texture [v5]
In-Reply-To: <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>
Message-ID: <c9ky-c54OL8vz2-QqT0Fpvh6frx-icUeCqglW3zQL7o=.642a405b-10a8-47d8-ae57-a9dc9352ac24@github.com>

On Tue, 4 Nov 2025 14:49:56 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments - MTLTexture: add isValid() check to update(MediaFrame)

I see this NPE (with this fix applied) when I go to more extremes with the amount of images shown:


java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.getPixelFormat()" because "<parameter1>" is null
	at com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:464)
	at com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture(BaseShaderGraphics.java:159)
	at com.sun.javafx.sg.prism.NGImageView.renderContent(NGImageView.java:123)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at com.sun.javafx.sg.prism.NGImageView.doRender(NGImageView.java:103)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279)
	at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186)
	at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2057)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279)
	at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186)
	at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213)
	at com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682)
	at com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586)
	at com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
	at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:481)
	at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329)
	at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
	at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358)
	at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:122)
	at java.base/java.lang.Thread.run(Thread.java:1575)


It seems that:

            Texture texture = factory.getCachedTexture(image, Texture.WrapMode.CLAMP_TO_EDGE);
            
In `NGImageView` can return `null`, but this isn't checked, and just passed along to `g.drawTexture`.

Also seeing this one:


java.lang.NullPointerException: Cannot invoke "com.sun.prism.d3d.D3DRTTexture.contentsUseful()" because "<local6>" is null
	at com.sun.prism.d3d.D3DResourceFactory.createPresentable(D3DResourceFactory.java:381)
	at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:81)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
	at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358)
	at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:122)
	at java.base/java.lang.Thread.run(Thread.java:1575)


Here in `D3DResourceFactory` the `createRTTTexture` returns `null`, but before that is checked (lower) it already derefences the pointer...


            D3DRTTexture rtt = createRTTexture(width, height, WrapMode.CLAMP_NOT_NEEDED, pState.isMSAA());
            if (PrismSettings.dirtyOptsEnabled) {
                rtt.contentsUseful();
            }

            if (rtt != null) {
                return new D3DSwapChain(context, pResource, rtt, pState.getRenderScaleX(), pState.getRenderScaleY());
            }

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3501392644

From jhendrikx at openjdk.org  Fri Nov  7 09:14:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 7 Nov 2025 09:14:23 GMT
Subject: RFR: 8368629: Texture.update sometimes invoked for a disposed
 Texture [v5]
In-Reply-To: <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>
References: <gAAvvczdbcDCnWeKNv3LmHwkMerisTNorUP5yqo4kOs=.e8b6e36a-9c7c-427d-8894-2b64d7622248@github.com>
 <r8fC19aZAhu46r4iZorDaEvkDpRF1tX3FJPJipxEbaY=.34f72834-f487-464e-9aa0-08b630e7e24e@github.com>
Message-ID: <kYEILVe3fCroOTNwZEq5uaj_0n63AhGxagvZUG1y84s=.bda2d7f6-0945-407f-8826-f636b947d2c8@github.com>

On Tue, 4 Nov 2025 14:49:56 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments - MTLTexture: add isValid() check to update(MediaFrame)

I also made this hack (using internals) to display some vram usage information (in a title bar for example).  This helps me at least to see how "bad" the situation is currently:


import com.sun.glass.ui.Screen;
import com.sun.prism.GraphicsPipeline;
import com.sun.prism.ResourceFactory;
import com.sun.prism.impl.TextureResourcePool;

import java.util.HashSet;
import java.util.List;
import java.util.Set;

public class VramStats {

  public static String getVramStats() {
    GraphicsPipeline pipeline = GraphicsPipeline.getPipeline();

    if(pipeline == null) {
      return "Unavailable";
    }

    List<Screen> screens = Screen.getScreens();
    Set<TextureResourcePool<?>> uniquePools = new HashSet<>();

    for(Screen screen : screens) {
      ResourceFactory resourceFactory = pipeline.getResourceFactory(screen);

      uniquePools.add(resourceFactory.getTextureResourcePool());
    }

    long totalUsed = 0;

    for(TextureResourcePool<?> pool : uniquePools) {
      totalUsed += pool.used();
    }

    return "VRAM: " + (totalUsed / 1024 / 1024) + " MB";
  }
}

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3501416090

From zelmidaoui at openjdk.org  Fri Nov  7 11:21:22 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Fri, 7 Nov 2025 11:21:22 GMT
Subject: RFR: 8366202: RichTextArea: wrong style used for typed text [v3]
In-Reply-To: <TLf7tNmPvOMnMj9HuMseOTezIxNHhuh53fd_rJYzO9c=.9a4ef33a-34af-42fb-9039-8f9e0c94b912@github.com>
References: <jXJWCEH5_QG54daSS3iS1-iTOC39YN8OTxIQlkOVvJQ=.7599c825-0466-43bf-9c4f-5f225a4a7090@github.com>
 <TLf7tNmPvOMnMj9HuMseOTezIxNHhuh53fd_rJYzO9c=.9a4ef33a-34af-42fb-9039-8f9e0c94b912@github.com>
Message-ID: <Yz847rC2is-UTSTZV-_mF8FnVT0HgB9HaoMFGsJFfZc=.91d62e3c-aa0e-4c7e-b375-fd8a143396eb@github.com>

On Fri, 31 Oct 2025 20:38:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> User feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ):
>> 
>> When typing text, in the middle of a sentence, to extend a word that's styled then the typed text is not being inserted using the styles of the preceding text.
>> 
>> Root cause: implementation bug.
>
> Andy Goryachev 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 8366202.wrong
>  - review comments
>  - wrong style

LGTM , works fine with the fix

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

Marked as reviewed by zelmidaoui (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1950#pullrequestreview-3433170822

From kcr at openjdk.org  Fri Nov  7 12:57:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Nov 2025 12:57:24 GMT
Subject: RFR: 8091429: ObservableList<E>#replaceRange(int from, int to,
 Collection<? extends E> col) [v5]
In-Reply-To: <xFj5tbFYjL0_B1_XSon-D6rszuf-DD1SG5oWRCGhSao=.6b0a5776-b24d-4bb3-bd8a-2e10b2c48b81@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
 <xFj5tbFYjL0_B1_XSon-D6rszuf-DD1SG5oWRCGhSao=.6b0a5776-b24d-4bb3-bd8a-2e10b2c48b81@github.com>
Message-ID: <Hil4lNB_2zZNdeNHuTWPgjxql_BXzg9ggWyrXRVfBMo=.444d0c19-51c9-46ed-ae41-62a46c0ab139@github.com>

On Fri, 7 Nov 2025 06:36:56 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR implements a new default method on `ObservableList` to be able to replace elements within a specified range.
>> 
>> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
>> 
>> The other alternative is to call `set` individually for each item, which results in many change notifications.
>> 
>> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
>> 
>> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly document an empty range is allowed

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1937#pullrequestreview-3433745750

From angorya at openjdk.org  Fri Nov  7 15:24:27 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Nov 2025 15:24:27 GMT
Subject: RFR: 8371386: Fix potential NPE in SwingNode [v2]
In-Reply-To: <TcbYQNxV6NF_-wW7jKWqrz_P_1_Y-pOg_N-Wlpm8TA0=.dd1e6cae-e14a-4d8a-9f93-d0f1f5726026@github.com>
References: <l4a-jc7xeqRWm_plz2vkjX3yvJZxcqhQgxHTKGEZFhI=.842f452b-4b5e-4b8f-995f-fd205232c296@github.com>
 <TcbYQNxV6NF_-wW7jKWqrz_P_1_Y-pOg_N-Wlpm8TA0=.dd1e6cae-e14a-4d8a-9f93-d0f1f5726026@github.com>
Message-ID: <BW8N8x6jgNk2CSCVmoBt9fy9mLJD1mNrdOPQn9gAtg0=.0dccd86a-28c6-4a83-bf3d-ebf7bbc95aa7@github.com>

On Fri, 7 Nov 2025 03:11:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> There can be potential NPEs in SwingNode which is fixed
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

thanks for making the changes!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1965#pullrequestreview-3434632369

From angorya at openjdk.org  Fri Nov  7 15:27:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Nov 2025 15:27:56 GMT
Subject: Integrated: 8366202: RichTextArea: wrong style used for typed text
In-Reply-To: <jXJWCEH5_QG54daSS3iS1-iTOC39YN8OTxIQlkOVvJQ=.7599c825-0466-43bf-9c4f-5f225a4a7090@github.com>
References: <jXJWCEH5_QG54daSS3iS1-iTOC39YN8OTxIQlkOVvJQ=.7599c825-0466-43bf-9c4f-5f225a4a7090@github.com>
Message-ID: <eNOVpcnCQRyZcACyupg95e6JfesXGn6bfTnhpp7lgCE=.5b8b6fe2-495e-47ff-a98f-96ffcf742548@github.com>

On Mon, 27 Oct 2025 19:04:16 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> User feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ):
> 
> When typing text, in the middle of a sentence, to extend a word that's styled then the typed text is not being inserted using the styles of the preceding text.
> 
> Root cause: implementation bug.

This pull request has now been integrated.

Changeset: bb660211
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/bb660211438c21cf54c97153589e6651fd420049
Stats:     31 lines in 2 files changed: 27 ins; 1 del; 3 mod

8366202: RichTextArea: wrong style used for typed text

Reviewed-by: lkostyra, zelmidaoui

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

PR: https://git.openjdk.org/jfx/pull/1950

From angorya at openjdk.org  Fri Nov  7 15:27:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Nov 2025 15:27:55 GMT
Subject: RFR: 8366202: RichTextArea: wrong style used for typed text [v3]
In-Reply-To: <TLf7tNmPvOMnMj9HuMseOTezIxNHhuh53fd_rJYzO9c=.9a4ef33a-34af-42fb-9039-8f9e0c94b912@github.com>
References: <jXJWCEH5_QG54daSS3iS1-iTOC39YN8OTxIQlkOVvJQ=.7599c825-0466-43bf-9c4f-5f225a4a7090@github.com>
 <TLf7tNmPvOMnMj9HuMseOTezIxNHhuh53fd_rJYzO9c=.9a4ef33a-34af-42fb-9039-8f9e0c94b912@github.com>
Message-ID: <M26xBNHYOSfViCNWcisFUhh1jbtH1_9o8yy1HLVgk9M=.25d52164-c289-41ee-9988-01bd9ed7a8a0@github.com>

On Fri, 31 Oct 2025 20:38:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> User feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ):
>> 
>> When typing text, in the middle of a sentence, to extend a word that's styled then the typed text is not being inserted using the styles of the preceding text.
>> 
>> Root cause: implementation bug.
>
> Andy Goryachev 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 8366202.wrong
>  - review comments
>  - wrong style

Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/jfx/pull/1950#issuecomment-3503171614

From angorya at openjdk.org  Fri Nov  7 15:36:39 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Nov 2025 15:36:39 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes [v2]
In-Reply-To: <v8pmPkNdHf0ZWbWTD5OwAm_qrpc6_SdSZOKYiGBx5kY=.c0153534-0faf-43a7-b546-0af898f9fdff@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
 <v7OCI24Z_Tp1zQM5gvv-TKUGESIzt5Tp1ukgVAg9mRc=.51d6b3e5-8e98-4044-a9b7-d48a391f014f@github.com>
 <v8pmPkNdHf0ZWbWTD5OwAm_qrpc6_SdSZOKYiGBx5kY=.c0153534-0faf-43a7-b546-0af898f9fdff@github.com>
Message-ID: <BBfW7W5Sw8KfuAxnCFSDA8w2OH9KXXmi9lN3I3wzrk0=.89986313-f5ec-4938-adf7-9c9304f5a4b2@github.com>

On Fri, 7 Nov 2025 00:32:31 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Screen.java line 375:
>> 
>>> 373:     public static void notifySettingsChanged() {
>>> 374:         // Save the old screens in order to dispose them later
>>> 375:         Set<Screen> oldScreens = new HashSet<>();
>> 
>> Does the order matter? I don't think so, but if it does, `LinkedHashSet` would preserve the order.
>
> No, it doesn't matter. 
> 
> The old screens are "disposed" just by setting their native pointer to 0L, so they can't be reused, while the new screens instances are passed to the windows, to keep an updated instance. 
> 
> Note that even if old screen and new screen have the very same information (nothing changed for this particular screen), since `WinWindow::notifyMoving` uses the equality operator (`screen 1 == screen 2`), we need to keep a valid instance in `Window::screen`, and therefore `Screen::dispose` is just a way of invalidating old instances. Then, since they are no longer referenced by any window, they can be gc'ed.

I had exactly the same question, and looked into the implementation.
Is it likely the implementation would change and the order be important in the future?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2504169270

From mhanl at openjdk.org  Fri Nov  7 15:45:17 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 7 Nov 2025 15:45:17 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes [v2]
In-Reply-To: <BBfW7W5Sw8KfuAxnCFSDA8w2OH9KXXmi9lN3I3wzrk0=.89986313-f5ec-4938-adf7-9c9304f5a4b2@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
 <v7OCI24Z_Tp1zQM5gvv-TKUGESIzt5Tp1ukgVAg9mRc=.51d6b3e5-8e98-4044-a9b7-d48a391f014f@github.com>
 <v8pmPkNdHf0ZWbWTD5OwAm_qrpc6_SdSZOKYiGBx5kY=.c0153534-0faf-43a7-b546-0af898f9fdff@github.com>
 <BBfW7W5Sw8KfuAxnCFSDA8w2OH9KXXmi9lN3I3wzrk0=.89986313-f5ec-4938-adf7-9c9304f5a4b2@github.com>
Message-ID: <CFOEo8FM5uB75Qyt5q7E9Xf6zKfsLZT9-bt07kDdNSU=.51f451d8-b844-4450-8d56-0ee487aa54e8@github.com>

On Fri, 7 Nov 2025 15:33:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> No, it doesn't matter. 
>> 
>> The old screens are "disposed" just by setting their native pointer to 0L, so they can't be reused, while the new screens instances are passed to the windows, to keep an updated instance. 
>> 
>> Note that even if old screen and new screen have the very same information (nothing changed for this particular screen), since `WinWindow::notifyMoving` uses the equality operator (`screen 1 == screen 2`), we need to keep a valid instance in `Window::screen`, and therefore `Screen::dispose` is just a way of invalidating old instances. Then, since they are no longer referenced by any window, they can be gc'ed.
>
> I had exactly the same question, and looked into the implementation.
> Is it likely the implementation would change and the order be important in the future?

I don't think so. And I would also argue that it would be weird, if not even bad if the order of disposing a `Screen` would matter

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2504214440

From kcr at openjdk.org  Fri Nov  7 15:47:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Nov 2025 15:47:21 GMT
Subject: RFR: 8371386: Fix potential NPE in SwingNode [v2]
In-Reply-To: <TcbYQNxV6NF_-wW7jKWqrz_P_1_Y-pOg_N-Wlpm8TA0=.dd1e6cae-e14a-4d8a-9f93-d0f1f5726026@github.com>
References: <l4a-jc7xeqRWm_plz2vkjX3yvJZxcqhQgxHTKGEZFhI=.842f452b-4b5e-4b8f-995f-fd205232c296@github.com>
 <TcbYQNxV6NF_-wW7jKWqrz_P_1_Y-pOg_N-Wlpm8TA0=.dd1e6cae-e14a-4d8a-9f93-d0f1f5726026@github.com>
Message-ID: <23Hlf_1RJl65Gs0MLI6flCYJFWugKjYy407Xv6JHHMY=.3ef56af4-72cd-4742-82fd-e6a6392046eb@github.com>

On Fri, 7 Nov 2025 03:11:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> There can be potential NPEs in SwingNode which is fixed
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1965#pullrequestreview-3434766498

From kcr at openjdk.org  Fri Nov  7 16:04:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Nov 2025 16:04:20 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes [v2]
In-Reply-To: <CFOEo8FM5uB75Qyt5q7E9Xf6zKfsLZT9-bt07kDdNSU=.51f451d8-b844-4450-8d56-0ee487aa54e8@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
 <v7OCI24Z_Tp1zQM5gvv-TKUGESIzt5Tp1ukgVAg9mRc=.51d6b3e5-8e98-4044-a9b7-d48a391f014f@github.com>
 <v8pmPkNdHf0ZWbWTD5OwAm_qrpc6_SdSZOKYiGBx5kY=.c0153534-0faf-43a7-b546-0af898f9fdff@github.com>
 <BBfW7W5Sw8KfuAxnCFSDA8w2OH9KXXmi9lN3I3wzrk0=.89986313-f5ec-4938-adf7-9c9304f5a4b2@github.com>
 <CFOEo8FM5uB75Qyt5q7E9Xf6zKfsLZT9-bt07kDdNSU=.51f451d8-b844-4450-8d56-0ee487aa54e8@github.com>
Message-ID: <QCS1Fwvoo-IFZphrEYXDkexiPYr4kIN2cBTNO5syDyA=.3f675f81-7f7d-4ad9-9fbd-9ac8ed33c586@github.com>

On Fri, 7 Nov 2025 15:42:27 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> I had exactly the same question, and looked into the implementation.
>> Is it likely the implementation would change and the order be important in the future?
>
> I don't think so. And I would also argue that it would be weird, if not even bad if the order of disposing a `Screen` would matter

Agreed. In this case I don't see how it could ever matter.

I only raised the question because whenever I see an ordinary HashSet being iterated, I always ask myself whether the iteration order matters.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2504318897

From angorya at openjdk.org  Fri Nov  7 16:47:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Nov 2025 16:47:47 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v13]
In-Reply-To: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
References: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
Message-ID: <LMPFI2YIdsctg7KCsj39455YwQndiYFgdJUOo0s9AzI=.5b6d2483-7a22-4324-8f91-21d4815a6a0c@github.com>

> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
> 
> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
> 
> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
> 
> WARNING this is an incompatible change, permitted because of the incubator.
> 
> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .

Andy Goryachev 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 branch 'master' into 8366201.allow.undo
 - review comments
 - Merge branch 'master' into 8366201.allow.undo
 - javadoc
 - suggestion
   
   Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
 - set text
 - Merge branch 'master' into 8366201.allow.undo
 - undo/redo javadoc in model only
 - javadoc
 - the
 - ... and 12 more: https://git.openjdk.org/jfx/compare/bb660211...4f3cf21f

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

Changes: https://git.openjdk.org/jfx/pull/1941/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1941&range=12
  Stats: 314 lines in 17 files changed: 238 ins; 7 del; 69 mod
  Patch: https://git.openjdk.org/jfx/pull/1941.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1941/head:pull/1941

PR: https://git.openjdk.org/jfx/pull/1941

From angorya at openjdk.org  Fri Nov  7 16:47:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Nov 2025 16:47:47 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v12]
In-Reply-To: <-5RQhssjbuZbj2zWEB4TYXgNOUVModpvsFaJVVfVl1I=.2356192e-77d3-4949-beeb-9b643a05a0f7@github.com>
References: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
 <-5RQhssjbuZbj2zWEB4TYXgNOUVModpvsFaJVVfVl1I=.2356192e-77d3-4949-beeb-9b643a05a0f7@github.com>
Message-ID: <lvF6ceoue-lF9UiK3K0Z5lZuhmDBxJsxHV9vbE8F7ME=.909469a0-cd25-4dbf-9803-1fcd1e523704@github.com>

On Thu, 6 Nov 2025 15:41:09 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - review comments
>  - Merge branch 'master' into 8366201.allow.undo
>  - javadoc
>  - suggestion
>    
>    Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
>  - set text
>  - Merge branch 'master' into 8366201.allow.undo
>  - undo/redo javadoc in model only
>  - javadoc
>  - the
>  - review comments
>  - ... and 11 more: https://git.openjdk.org/jfx/compare/11cff5d6...96453dba

Attached updated diff to the CSR: https://bugs.openjdk.org/secure/attachment/117056/JDK-8370909-v2.diff

... and we have a merge conflict.

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

PR Comment: https://git.openjdk.org/jfx/pull/1941#issuecomment-3503577259

From angorya at openjdk.org  Fri Nov  7 16:50:18 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Nov 2025 16:50:18 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED [v3]
In-Reply-To: <LhdiZKZ326XUR3iZp4Lwu75SkC1zc7gNiuY3BCeuEmA=.0251b616-54e6-413b-ab7c-7b1c9aa81495@github.com>
References: <bIMP7awMNGUfYipsINgCBoQ24l8S7-r7BR-ksByEQq4=.2f4e676f-10dc-419c-9b48-f7d2c3a076a9@github.com>
 <LhdiZKZ326XUR3iZp4Lwu75SkC1zc7gNiuY3BCeuEmA=.0251b616-54e6-413b-ab7c-7b1c9aa81495@github.com>
Message-ID: <Fy7G8UBr84tNXjzQxSYnNS77k6udkLzJnUXdPsx-aOQ=.ac75f0ab-0638-4152-aa34-06f09c6c2c52@github.com>

On Fri, 7 Nov 2025 01:54:56 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Adds the `DialogPane.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - documentation
>  - Merge branch 'master' into feature/extended-dialog
>  - move HeaderBar to DialogPane
>  - document/verify preview feature
>  - Ensure that DialogPane is always attached to Scene
>  - Lazily initialize Dialog.headerBar
>  - Support dialogs with StageStyle.EXTENDED

looks good, thanks!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1943#pullrequestreview-3435151004

From angorya at openjdk.org  Fri Nov  7 16:57:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Nov 2025 16:57:55 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v15]
In-Reply-To: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
Message-ID: <VJwun5rVStCRmY4epAw1jWeCMyKrzc7X4HNyP88HUCM=.5d2d5b05-b51e-440f-95a6-31c938225c05@github.com>

> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
> 
> The impacted areas are:
> - saving to plain text
> - copying to plain text
> - IME
> 
> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), with convenience setter and getter in the `RichTextArea`.
> 
> ### NOTES
> 
> - some dependency on #1938 , resolved.

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

 - Merge branch 'master' into 8370140.line.separator
 - rm property
 - try
 - Merge remote-tracking branch 'origin/master' into 8370140.line.separator
 - review comments
 - removed property
 - review comments
 - code area test
 - Merge branch 'master' into 8370140.line.separator
 - fixed tests
 - ... and 9 more: https://git.openjdk.org/jfx/compare/bb660211...4eb15464

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

Changes: https://git.openjdk.org/jfx/pull/1944/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=14
  Stats: 291 lines in 13 files changed: 258 ins; 11 del; 22 mod
  Patch: https://git.openjdk.org/jfx/pull/1944.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1944/head:pull/1944

PR: https://git.openjdk.org/jfx/pull/1944

From angorya at openjdk.org  Fri Nov  7 17:48:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Nov 2025 17:48:06 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property [v9]
In-Reply-To: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
References: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
Message-ID: <Ulu0RwnlmTqYhEJzlkeIhSrCz2Jz_cgkJeqd3xsmEQU=.5f4b4b17-ce9f-4e53-805a-9c23ddfbb40f@github.com>

> Tries to address the mystery of missing graphic in the TabPane overflow menu.
> 
> ### Summary of Changes
> 
> - minor `TabPaneSkin` constructor javadoc clarification
> - added the property
> - changed popup menu to be created on demand
> - removing adding the popup reference to the `TabHeaderSkin` properties (I think it was done for testing purposes, I could not find any references to it in the code)
>  
> For a quick tester, use https://bugs.openjdk.org/secure/attachment/114240/TabPaneGraphicFactoryExample.java
> 
> # Overflow Menu Graphic Property in the TabPaneSkin
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `menuGraphicFactory` property in the `TabPaneSkin` class eliminates the current limitation of this skin
> in supporting menu item graphics other than an `ImageView` or `Label` with an `ImageView` graphic.
> 
> 
> 
> ## Goals
> 
> The goals of this proposal are:
> 
> - to allow the application developers to customize the overflow menu items' graphic
> - retain the backward compatibility with the existing application code
> - clarify the behavior of the skin when the property is null (i.e. the current behavior)
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - disable the overflow menu
> - configure overflow menu graphic property via CSS
> - add this property to the `TabPane` control itself
> 
> 
> 
> ## Motivation
> 
> The existing `TabPaneSkin` does not allow the overflow menu to show graphic other than
> an `ImageView` or `Label` with an `ImageView`.
> 
> This limitation makes it impossible for the application developer to use other graphic Nodes,
> such as `Path` or `Canvas`, or in fact any other types.  The situation becomes even more egregious
> when the tabs in the `TabPane` have no text.
> 
> Example:
> 
> 
> public class TabPaneGraphicFactoryExample {
>     public void example() {
>         Tab tab1 = new Tab("Tab1");
>         tab1.setGraphic(createGraphic(tab1));
> 
>         Tab tab2 = new Tab("Tab2");
>         tab2.setGraphic(createGraphic(tab2));
> 
>         TabPane tabPane = new TabPane();
>         tabPane.getTabs().addAll(tab1, tab2);
> 
>         TabPaneSkin skin = new TabPaneSkin(tabPane);
>         // set overflow menu factory with the same method as was used to create the tabs
>         skin.setMenuGraphicFactory(this::createGraphic);
>         tabPane.setSkin(skin);
>     }
> 
>     // creates graphic Nodes for tabs as well as the overflow menu
>     private Node createGraphic(Tab tab) {
>         switch (tab.getText()) {
>         case "Tab1":
>             return new Circle(10);
>         case "Tab2"...

Andy Goryachev 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 13 additional commits since the last revision:

 - Merge branch 'master' into 8353599.menu.factory
 - Merge branch 'master' into 8353599.menu.factory
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - Merge branch 'master' into 8353599.menu.factory
 - Merge branch 'master' into 8353599.menu.factory
 - Merge branch 'master' into 8353599.menu.factory
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - popup menu on demand
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - ... and 3 more: https://git.openjdk.org/jfx/compare/f222a283...ca4c1739

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1773/files
  - new: https://git.openjdk.org/jfx/pull/1773/files/638681d4..ca4c1739

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

  Stats: 1860 lines in 56 files changed: 1479 ins; 143 del; 238 mod
  Patch: https://git.openjdk.org/jfx/pull/1773.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1773/head:pull/1773

PR: https://git.openjdk.org/jfx/pull/1773

From mhanl at openjdk.org  Fri Nov  7 20:27:17 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 7 Nov 2025 20:27:17 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes [v2]
In-Reply-To: <QCS1Fwvoo-IFZphrEYXDkexiPYr4kIN2cBTNO5syDyA=.3f675f81-7f7d-4ad9-9fbd-9ac8ed33c586@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
 <v7OCI24Z_Tp1zQM5gvv-TKUGESIzt5Tp1ukgVAg9mRc=.51d6b3e5-8e98-4044-a9b7-d48a391f014f@github.com>
 <v8pmPkNdHf0ZWbWTD5OwAm_qrpc6_SdSZOKYiGBx5kY=.c0153534-0faf-43a7-b546-0af898f9fdff@github.com>
 <BBfW7W5Sw8KfuAxnCFSDA8w2OH9KXXmi9lN3I3wzrk0=.89986313-f5ec-4938-adf7-9c9304f5a4b2@github.com>
 <CFOEo8FM5uB75Qyt5q7E9Xf6zKfsLZT9-bt07kDdNSU=.51f451d8-b844-4450-8d56-0ee487aa54e8@github.com>
 <QCS1Fwvoo-IFZphrEYXDkexiPYr4kIN2cBTNO5syDyA=.3f675f81-7f7d-4ad9-9fbd-9ac8ed33c586@github.com>
Message-ID: <HRqIoK1djrKlYVtY5xJtJXIeoZsYZZRCTQoM9oacGL4=.0eaad302-8b72-4ec0-af8d-0e747257ceb5@github.com>

On Fri, 7 Nov 2025 16:01:45 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I only raised the question because whenever I see an ordinary HashSet being iterated, I always ask myself whether the iteration order matters.

I agree 100%, especially since bugs in that case are really hard to find and debug.

I remember from my personal experience tests that sometimes failed, because the test did call `iterator().next()` on a Collection, which was a HashSet.? 

I just saw that I forgot to quote Andy on my previous answer. Just to emphasize this: I don't see how the implementation could be changed in such a way that the order would matter in the future.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2505367222

From angorya at openjdk.org  Fri Nov  7 21:06:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Nov 2025 21:06:53 GMT
Subject: RFR: 8371070: RichParagraph enhancements
Message-ID: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>

Addressing the user feedback:

In RichParagraph you have a note to make getSegments() public.  It would be helpful if it was.


Adding two methods to the `RichParagraph` class:

- getSegmentCount()
- getSegment(int index)

Decided against exposing a List since it would require additional allocation.  Some of the callers seems to implement special logic when the number of segments is 0 anyway.

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

Commit messages:
 - test
 - expose segments

Changes: https://git.openjdk.org/jfx/pull/1966/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1966&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371070
  Stats: 213 lines in 7 files changed: 141 ins; 42 del; 30 mod
  Patch: https://git.openjdk.org/jfx/pull/1966.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1966/head:pull/1966

PR: https://git.openjdk.org/jfx/pull/1966

From kcr at openjdk.org  Fri Nov  7 21:52:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Nov 2025 21:52:19 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes [v2]
In-Reply-To: <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
Message-ID: <XmT4aBenwGQoI4A2EXbNqVQd0zFG7T3M_u_BxhrBVPc=.e8c25c35-ae41-4342-9242-2c6832a7735a@github.com>

On Thu, 6 Nov 2025 21:43:32 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> This PR adds the missing native implementation for Windows, `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running, in a similar way as Java Desktop [handles](https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L1418) this DPI event.
>> 
>> When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well.
>> 
>> The change in `Screen:: notifySettingsChanged` is needed in order to prevent disposing screens that are not referenced by windows, and only do it when the screen instance of a given window does change.
>> 
>> There are no tests added to this PR, since these would require manual intervention to change the resolution of the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. It has also been tested that it doesn't have any side effect on macOS.
>> 
>> For the case when the app runs on a different display that the one that was changed, see https://bugs.openjdk.org/browse/JDK-8371302 and a possible fix with https://github.com/openjdk/jfx/pull/1963.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use set and remove unnecessary casting

All my testing is good. It fixes the bug and as far as I can tell, doesn't introduce new regressions.

My only question is that I'm still not sure why the changes in the shared code in Screen.java are needed.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/Screen.java line 403:

> 401:         for (Screen screen : oldScreens) {
> 402:             screen.dispose();
> 403:         }

I'm still a little puzzled as to why a change was needed in the class at all. Even with the change you made to the native Windows glass code, it seems that calling dispose for all of the old Java screen objects is what we want. Am I missing something?

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

PR Review: https://git.openjdk.org/jfx/pull/1964#pullrequestreview-3436557419
PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2505645025

From kcr at openjdk.org  Fri Nov  7 21:53:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Nov 2025 21:53:16 GMT
Subject: RFR: 8371302: [Windows] Stage coordinates in secondary display are
 not properly updated after changing settings of first display
In-Reply-To: <CR0CQX9O56oytMISf8D6Bdsnt9U0uPBr0NMsQPIv5Ls=.1be06b8c-8f09-44d9-ba74-39a7feee7db9@github.com>
References: <CR0CQX9O56oytMISf8D6Bdsnt9U0uPBr0NMsQPIv5Ls=.1be06b8c-8f09-44d9-ba74-39a7feee7db9@github.com>
Message-ID: <bnJTwH0_WZR98_zyVgY7bA3Xgtl4T4S1itlz6v-ogl8=.d09ef4f0-0a2b-4d29-bdd6-da7f8eedd9d5@github.com>

On Wed, 5 Nov 2025 11:44:40 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR handles two windows events, `WM_DISPLAYCHANGE` and `WM_SETTINGCHANGE`, that can be received by a JavaFX Window on a given display when other display changed its settings (resolution), or both displays were rearranged, and therefore its location has changed. 
> 
> When this happens, `com.sun.glass.ui.Window` has the new updated location, but the `javafx.stage.Window` does not, and triggering a `Window.MOVE` event notifies the stage to update its location accordingly.
> 
> There are no tests added to this PR (those would require two monitors, and external changes of Windows Settings), but the [test](https://bugs.openjdk.org/secure/attachment/116917/RenderScaleTest.java) attached to the JBS issue passes after this PR running some manual tests: for the stage at secondary display, check that the location is updated properly and the context menu shows up at the expected position, when the primary display resolution changes via Settings->System->Display->Scale, or when both displays are rearranged via Settings->System->Display->Drag to rearrange.

All testing looks good. This is a safe and simple change.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1963#pullrequestreview-3436563023

From kcr at openjdk.org  Fri Nov  7 22:02:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Nov 2025 22:02:19 GMT
Subject: RFR: 8371070: RichParagraph enhancements
In-Reply-To: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>
References: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>
Message-ID: <t1qvaYIvBq9I-NH5hU3vpxLMpGEEy7t4JpyFT8LX-Vo=.63fbff47-5a09-42a2-9d77-f1fee31ecfe7@github.com>

On Fri, 7 Nov 2025 20:08:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Addressing the user feedback:
> 
> In RichParagraph you have a note to make getSegments() public.  It would be helpful if it was.
> 
> 
> Adding two methods to the `RichParagraph` class:
> 
> - getSegmentCount()
> - getSegment(int index)
> 
> Decided against exposing a List since it would require additional allocation.  Some of the callers seems to implement special logic when the number of segments is 0 anyway.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichParagraph.java line 133:

> 131:      * @since 26
> 132:      */
> 133:     public abstract StyledSegment getSegment(int index);

A `List<StyledSegment> getSegments()` method would be more convenient to use. You could either return an unmodifiable view of the list or make a shallow copy.

What is the reason for separate `getSegmentCount` and `getSegment(index)` methods?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1966#discussion_r2505672434

From angorya at openjdk.org  Fri Nov  7 22:28:17 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Nov 2025 22:28:17 GMT
Subject: RFR: 8371070: RichParagraph enhancements
In-Reply-To: <t1qvaYIvBq9I-NH5hU3vpxLMpGEEy7t4JpyFT8LX-Vo=.63fbff47-5a09-42a2-9d77-f1fee31ecfe7@github.com>
References: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>
 <t1qvaYIvBq9I-NH5hU3vpxLMpGEEy7t4JpyFT8LX-Vo=.63fbff47-5a09-42a2-9d77-f1fee31ecfe7@github.com>
Message-ID: <UD0LAz5xZQmiWTK_-4uvRWHZ9hMzuWNWnLtv8wBy18I=.14e93558-f5f9-4e60-b172-901443a0fe4a@github.com>

On Fri, 7 Nov 2025 21:59:37 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Addressing the user feedback:
>> 
>> In RichParagraph you have a note to make getSegments() public.  It would be helpful if it was.
>> 
>> 
>> Adding two methods to the `RichParagraph` class:
>> 
>> - getSegmentCount()
>> - getSegment(int index)
>> 
>> Decided against exposing a List since it would require additional allocation.  Some of the callers seems to implement special logic when the number of segments is 0 anyway.
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichParagraph.java line 133:
> 
>> 131:      * @since 26
>> 132:      */
>> 133:     public abstract StyledSegment getSegment(int index);
> 
> A `List<StyledSegment> getSegments()` method would be more convenient to use. You could either return an unmodifiable view of the list or make a shallow copy.
> 
> What is the reason for separate `getSegmentCount` and `getSegment(index)` methods?

Did explain it in the description.  Avoid extra allocation + most of the clients have special logic for paragraphs that contain 0 segments.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1966#discussion_r2505744934

From kcr at openjdk.org  Fri Nov  7 22:59:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Nov 2025 22:59:27 GMT
Subject: [jfx25u] RFR: 8252373: [macOS] Stage with owner disappears when moved
 to another screen
Message-ID: <KFOIB59SYWOFHQDB4MrGgxNmynly9BJx7-NZDxs4wQE=.1c4f244f-039b-45ad-89d5-b54af57cc318@github.com>

Clean backport of fix for bug where owned stage disappears when moved to another screen. This has baked in mainline for about 3 weeks and no problems have been observed. I verified that the fix works equally well on jfx25u.

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

Commit messages:
 - 8252373: [macOS] Stage with owner disappears when moved to another screen

Changes: https://git.openjdk.org/jfx25u/pull/35/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=35&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8252373
  Stats: 235 lines in 5 files changed: 207 ins; 9 del; 19 mod
  Patch: https://git.openjdk.org/jfx25u/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/35/head:pull/35

PR: https://git.openjdk.org/jfx25u/pull/35

From michaelstrau2 at gmail.com  Sat Nov  8 01:50:19 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 8 Nov 2025 02:50:19 +0100
Subject: Enhance the property metadata model
Message-ID: <CAJEpuXSYTSGH8eOQcEh1oDRdy=-TOGGaO_LW7CvLD4EmNqYXpA@mail.gmail.com>

PR 1936 [0] proposes to introduce observable attached properties that
are distinguishable from instance properties with a naming convention
(this is also relevant for PR 1714 [1]). However, before doing this,
we should take a step back and see if we can't do better than that and
make attached properties more accessible in the property API.

I've prepared a document that explores a few options for doing so, and
a proposal for what I think might be a natural enhancement of the
existing property metadata model [2].

Comments are welcome.

[0] https://github.com/openjdk/jfx/pull/1936
[1] https://github.com/openjdk/jfx/pull/1714
[2] https://gist.github.com/mstr2/2fec0303fc440b8eaeb126befc76eb5c

From jpereda at openjdk.org  Sat Nov  8 14:20:18 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Sat, 8 Nov 2025 14:20:18 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes [v2]
In-Reply-To: <XmT4aBenwGQoI4A2EXbNqVQd0zFG7T3M_u_BxhrBVPc=.e8c25c35-ae41-4342-9242-2c6832a7735a@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
 <XmT4aBenwGQoI4A2EXbNqVQd0zFG7T3M_u_BxhrBVPc=.e8c25c35-ae41-4342-9242-2c6832a7735a@github.com>
Message-ID: <z1JAr7WIsbGjF_Mx5l8WRkTfWK4EMLRAgEBPOC5ANeo=.1dcdc726-e16e-42de-ba7b-580025b88133@github.com>

On Fri, 7 Nov 2025 21:48:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use set and remove unnecessary casting
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Screen.java line 403:
> 
>> 401:         for (Screen screen : oldScreens) {
>> 402:             screen.dispose();
>> 403:         }
> 
> I'm still a little puzzled as to why a change was needed in the class at all. Even with the change you made to the native Windows glass code, it seems that calling dispose for all of the old Java screen objects is what we want. Am I missing something?

There is a reason for it, otherwise I wouldn't have modified `Screen`.

If you run the [test](https://bugs.openjdk.org/secure/attachment/112708/Menu_RenderScale_8346281.java) in the JBS issue, on Windows with two monitors (primary with scale > 100%), with the changes from `GlassWindow.cpp` only, without changing `Screen`, when you open the File menu of the window in the secondary display, the context menu is misplaced:

<img width="404" height="341" alt="Screenshot 2025-11-08 143811" src="https://github.com/user-attachments/assets/5844155e-c6cb-4b9a-9edb-c81b1140b8bb" />

Adding some debugging info, it can be seen that, when the application starts (without doing any external change in Windows settings), there is a DPI event, that calls `notifySettingsChanged`, at a point where there is only a `Window` instance (the one in the primary screen), instead of two. The two screens get disposed (that is, `Screen.ptr = 0`), and later on, when the secondary window is created, it gets assigned the disposed secondary screen, with this `ptr = 0`. 

When opening the `File` menu of the secondary window, another DPI event is triggered, `notifySettingsChanged` is called, but since there was no real change in the screens, the new screens are the same as the old ones (the valid  `ptr` didn't change after the event). However, the valid secondary screen is not assigned to the secondary Window, because the if test, (ptr from old screen was 0, and new screen ptr >0 doesn't match), so it keeps the old screen instance with `ptr = 0`.

This causes some unexpected issues for instance in `WinWindow::notifyMoving`, as there is a mixture of valid screens (from `Screen.getScreens()`) and invalid one in `Window::getScreen`, and the equality checks (`screen1 == screen2`) fails, ultimately providing wrong screen information for the popup.

So the change in `Screen` that I propose in this PR removes the disposal of screens if these are not assigned to a window yet.

Does that make sense?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2506946177

From credmond at certak.com  Sat Nov  8 20:30:21 2025
From: credmond at certak.com (Cormac Redmond)
Date: Sat, 8 Nov 2025 20:30:21 +0000
Subject: ComboBox item height bug
Message-ID: <CAG_-AaBUk78-=EiNwN9v7g3yr=FKiA7JW0S5PDYFDmzsgm8ENQ@mail.gmail.com>

Hi,

I have found a height bug when I am trying to reduce the height of one
ComboBox item (a Separator) in a simple ComboBox.

One would expect that to achieve this, you'd set the maximum height for
that particular ListCell; but this has no effect.

Instead what I need to do is set the *minimum* height (but to the value I
wish to be the maximum height), and I must *also *set the *maximum *height
to any value (if I do not, my minimum height (i.e., my desired maximum)
gets ignored)...

For example, if I want the maximum height of this Separator to be 6, I must
set the minimum height to 6 and I must set the maximum height to anything,
even 1.

Obviously this is counter-intuitive and doesn't make any logical sense.

Example to reproduce (running from JFX master branch):

public class ComboBoxHeightBug extends Application {
    public static void main(String[] args) {
        launch(args);
    }

    public void start(Stage stage) {
        ComboBox<Object> cb = new ComboBox<>();
        cb.getItems().addAll("Apple", "Banana",  new Separator() ,
"Carrot", "Lettuce");
        cb.setCellFactory(_ -> new ListCell<>() {
            protected void updateItem(Object item, boolean empty) {
                super.updateItem(item, empty);
                if (empty || item == null) {
                    setText(null);
                    setGraphic(null);
                    setStyle("");
                    // Set back to default
                    setMinHeight(USE_PREF_SIZE);
                    setMaxHeight(Double.MAX_VALUE);
                } else if (item instanceof Separator) {
                    setText(null);
                    setGraphic((Separator) item);
                    setDisable(true);
                    setMinHeight(6); // This is required for any "max
height" to apply, and appears to be the value that is used to determine
height
                    setMaxHeight(1); // Setting this (to 6) should work on
its own, it doesn't, the value appears irrelevant -- but it MUST be set to
get the separator height to be 6
                } else {
                    setText(item.toString());
                    setGraphic(null);
                    setStyle("");
                    // Set back to default
                    setMinHeight(USE_PREF_SIZE);
                    setMaxHeight(Double.MAX_VALUE);
                }
            }
        });

        cb.getSelectionModel().selectFirst();
        stage.setScene(new Scene(cb, 200, 100));
        stage.show();
    }
}

Note: I have noticed a few issues like this in general, whereby it requires
trial and error to get *some* desired height to apply; without any apparent
logic as to how these values are being arrived at or how they're triggered
to be used (I have logged bugs before on this)...


Kind Regards,
Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251108/293e54c0/attachment.htm>

From credmond at certak.com  Sat Nov  8 21:26:44 2025
From: credmond at certak.com (Cormac Redmond)
Date: Sat, 8 Nov 2025 21:26:44 +0000
Subject: ComboBox item disappearing when selected
In-Reply-To: <CAG_-AaCciHuZ1feJ3NTQycJVqXEnHw-k2V8PVop19XP0CLtYGg@mail.gmail.com>
References: <CAG_-AaCciHuZ1feJ3NTQycJVqXEnHw-k2V8PVop19XP0CLtYGg@mail.gmail.com>
Message-ID: <CAG_-AaBfCFLynAxwONLJOFniWEiUNjOBdnsuHQutiX2VqW=Ecw@mail.gmail.com>

Hi,

There is a bug whereby if you select a ComboBox item the item disappears /
becomes invisible.

This ComboBox consists of strings and a Label node and the Label node will
disappear from the dropdown if it's selected (though, continue to take
up space).

I'm just picking a Label for example, it appears to happen with any Node
that I've tried.

[image: bug_cb.gif]


Steps to reproduce (JFX 26, master branch). Note: I've kept the sample small
intentionally, but if you use a CellFactory (to call setText() or setGraphic
() accordingly, as normal), the *same* thing happens. In other words, the
bug doesn't seem to be because of "mis-use" of the ComboBox by mixing types
-- I think.

public class ComboBoxDisappearingItemBug extends Application {
    public static void main(String[] args) {
        launch(args);
    }

    public void start(Stage stage) {
        ComboBox<Object> cb = new ComboBox<>();
        cb.getItems().addAll("Apple", "Banana", new Label("I will
disappear"), "Carrot", "Lettuce");
        cb.getSelectionModel().selectFirst();
        stage.setScene(new Scene(cb, 200, 100));
        stage.show();
    }
}



Kind Regards,
Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251108/4844af23/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug_cb.gif
Type: image/gif
Size: 85745 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251108/4844af23/bug_cb-0001.gif>

From john.hendrikx at gmail.com  Sat Nov  8 22:12:11 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sat, 8 Nov 2025 23:12:11 +0100
Subject: ComboBox item disappearing when selected
In-Reply-To: <CAG_-AaBfCFLynAxwONLJOFniWEiUNjOBdnsuHQutiX2VqW=Ecw@mail.gmail.com>
References: <CAG_-AaCciHuZ1feJ3NTQycJVqXEnHw-k2V8PVop19XP0CLtYGg@mail.gmail.com>
 <CAG_-AaBfCFLynAxwONLJOFniWEiUNjOBdnsuHQutiX2VqW=Ecw@mail.gmail.com>
Message-ID: <552b3cb9-7316-490a-8bd3-86c037f536de@gmail.com>

Hi,

I'm guessing you're setting the disappearing item as "Graphic", because
it is a Label and not a string.? However, you can only set a Node
(anywhere, including as graphic) in one part of the scene graph.?
Setting it somewhere else will cause it to be removed?in the old
location (without warning unfortunately).

In this case, the Label is likely used as graphic in two places: once in
the list (as a cell), and once in the edit area (as another cell) of the
ComboBox when it was the last one selected.? This is causing the odd
disappearing artifact.

Best practice is to not use Nodes as items for a ComboBox.? Instead, use
a Record or some other type that the ListCell::updateItem will convert
to be shown in the way you want.

--John

On 08/11/2025 22:26, Cormac Redmond wrote:
> Hi,
>
> There is a bug whereby if you select a ComboBox item the item
> disappears / becomes invisible.
>
> This ComboBox consists of strings and a Label node and the Label node
> will disappear from the dropdown if it's selected (though, continue to
> take up?space).
>
> I'm just picking a Label for example, it appears to happen with any
> Node that I've tried.
>
> bug_cb.gif
>
>
> Steps to reproduce (JFX 26, master branch). Note:?I've kept the sample
> smallintentionally, but if you use a CellFactory (to call setText() or
> setGraphic() accordingly, as normal),?the /same/ thing happens. In
> other words, the bug doesn't?seem to be because of "mis-use" of the
> ComboBox by mixing types -- I think.
>
> public class ComboBoxDisappearingItemBug extends Application {
> ? ? public static void main(String[] args) {
> ? ? ? ? launch(args);
> ? ? }
>
> ? ? public void start(Stage stage) {
> ? ? ? ? ComboBox<Object> cb = new ComboBox<>();
> ? ? ? ? cb.getItems().addAll("Apple", "Banana", new Label("I will
> disappear"), "Carrot", "Lettuce");
> ? ? ? ? cb.getSelectionModel().selectFirst();
> ? ? ? ? stage.setScene(new Scene(cb, 200, 100));
> ? ? ? ? stage.show();
> ? ? }
> }
>
>
>
> Kind Regards,
> Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251108/8330fd64/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug_cb.gif
Type: image/gif
Size: 85745 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251108/8330fd64/bug_cb-0001.gif>

From john.hendrikx at gmail.com  Sat Nov  8 22:16:04 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sat, 8 Nov 2025 23:16:04 +0100
Subject: ComboBox item height bug
In-Reply-To: <CAG_-AaBUk78-=EiNwN9v7g3yr=FKiA7JW0S5PDYFDmzsgm8ENQ@mail.gmail.com>
References: <CAG_-AaBUk78-=EiNwN9v7g3yr=FKiA7JW0S5PDYFDmzsgm8ENQ@mail.gmail.com>
Message-ID: <41357b68-7658-430a-b464-dc73599db978@gmail.com>

What you are likely seeing is that the minimum always wins over the
other values.

The minimum height is set to the constant USE_PREF_SIZE, which means
that it will take the preferred size for the minimum height.

When it comes to size priorities (min, pref and max), minimum always
wins, then comes maximum, then comes preferred.

So in this case, the preferred size is say 20.? The minimum follows the
preferred, also 20.? You set maximum to 1.? Minimum > Maximum, so
Maximum is ignored.

What you could try is set preferred size smaller instead; there should
be no need to change minimum or maximum then.

--John

On 08/11/2025 21:30, Cormac Redmond wrote:
> Hi,
>
> I have found a height bug when I am trying to reduce?the height of one
> ComboBox item (a Separator) in a simple ComboBox.
>
> One would expect that to achieve this, you'd set the maximum height
> for that particular ListCell; but this has no?effect.
>
> Instead what I need to do is set the /minimum/ height (but to the
> value I wish to be the maximum height), and I must *also *set the
> /maximum /height to any value (if I do not, my minimum height (i.e.,
> my desired maximum) gets ignored)...
>
> For example, if I want the?maximum height of this Separator to be 6, I
> must set the minimum height to 6 and I must set the maximum height to
> anything, even 1.
>
> Obviously this is counter-intuitive and doesn't make?any?logical sense.
>
> Example to reproduce (running from JFX master branch):
>
> public class ComboBoxHeightBug extends Application {
> ? ? public static void main(String[] args) {
> ? ? ? ? launch(args);
> ? ? }
>
> ? ? public void start(Stage stage) {
> ? ? ? ? ComboBox<Object> cb = new ComboBox<>();
> ? ? ? ? cb.getItems().addAll("Apple", "Banana",? new Separator()?,
> "Carrot", "Lettuce");
> ? ? ? ? cb.setCellFactory(_ -> new ListCell<>() {
> ? ? ? ? ? ? protected void updateItem(Object item, boolean empty) {
> ? ? ? ? ? ? ? ? super.updateItem(item, empty);
> ? ? ? ? ? ? ? ? if (empty || item == null) {
> ? ? ? ? ? ? ? ? ? ? setText(null);
> ? ? ? ? ? ? ? ? ? ? setGraphic(null);
> ? ? ? ? ? ? ? ? ? ? setStyle("");
> ? ? ? ? ? ? ? ? ? ? // Set back to default
> ? ? ? ? ? ? ? ? ? ? setMinHeight(USE_PREF_SIZE);
> ? ? ? ? ? ? ? ? ? ? setMaxHeight(Double.MAX_VALUE);
> ? ? ? ? ? ? ? ? } else if (item instanceof Separator) {
> ? ? ? ? ? ? ? ? ? ? setText(null);
> ? ? ? ? ? ? ? ? ? ? setGraphic((Separator) item);
> ? ? ? ? ? ? ? ? ? ? setDisable(true);
> ? ? ? ? ? ? ? ? ? ? setMinHeight(6); // This is required for any "max
> height" to apply, and appears to be the value that is used to
> determine height
> ? ? ? ? ? ? ? ? ? ? setMaxHeight(1); // Setting this (to 6) should
> work on its own, it doesn't, the value appears irrelevant -- but it
> MUST be set to get the separator height to be 6
> ? ? ? ? ? ? ? ? } else {
> ? ? ? ? ? ? ? ? ? ? setText(item.toString());
> ? ? ? ? ? ? ? ? ? ? setGraphic(null);
> ? ? ? ? ? ? ? ? ? ? setStyle("");
> ? ? ? ? ? ? ? ? ? ? // Set back to default
> ? ? ? ? ? ? ? ? ? ? setMinHeight(USE_PREF_SIZE);
> ? ? ? ? ? ? ? ? ? ? setMaxHeight(Double.MAX_VALUE);
> ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? }
> ? ? ? ? });
>
> ? ? ? ? cb.getSelectionModel().selectFirst();
> ? ? ? ? stage.setScene(new Scene(cb, 200, 100));
> ? ? ? ? stage.show();
> ? ? }
> }
>
> Note: I have noticed a few issues like this in general, whereby it
> requires trial and error to get?/some/?desired height to apply;
> without any apparent logic as to how these values are being arrived at
> or how they're triggered to be used (I have logged bugs before on this)...
>
>
> Kind Regards,
> Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251108/80c74623/attachment.htm>

From jhendrikx at openjdk.org  Sat Nov  8 22:19:18 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 8 Nov 2025 22:19:18 GMT
Subject: Integrated: 8091429: ObservableList<E>#replaceRange(int from, int to, 
 Collection<? extends E> col)
In-Reply-To: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
References: <mKAH_lVQoPjwoZZkBTPmx5kR1R8Cou3yvpkWyzZZJuM=.dbeb22c6-cb48-48fb-9388-a37140a700c1@github.com>
Message-ID: <Ef3wk3ywUiL3ARCsa9ZYGafSMLcxxNtiiT2ilwYCcnU=.195ae5d7-788f-43b2-b259-bcb9e902de33@github.com>

On Wed, 15 Oct 2025 03:40:24 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR implements a new default method on `ObservableList` to be able to replace elements within a specified range.
> 
> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
> 
> The other alternative is to call `set` individually for each item, which results in many change notifications.
> 
> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
> 
> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.

This pull request has now been integrated.

Changeset: b76090df
Author:    John Hendrikx <jhendrikx at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/b76090dfe6821efcbd86230e1b24ad7f455c7a41
Stats:     135 lines in 3 files changed: 134 ins; 1 del; 0 mod

8091429: ObservableList<E>#replaceRange(int from, int to, Collection<? extends E> col)

Reviewed-by: mstrauss, kcr

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

PR: https://git.openjdk.org/jfx/pull/1937

From credmond at certak.com  Sun Nov  9 00:26:20 2025
From: credmond at certak.com (Cormac Redmond)
Date: Sun, 9 Nov 2025 00:26:20 +0000
Subject: ComboBox item disappearing when selected
In-Reply-To: <552b3cb9-7316-490a-8bd3-86c037f536de@gmail.com>
References: <CAG_-AaCciHuZ1feJ3NTQycJVqXEnHw-k2V8PVop19XP0CLtYGg@mail.gmail.com>
 <CAG_-AaBfCFLynAxwONLJOFniWEiUNjOBdnsuHQutiX2VqW=Ecw@mail.gmail.com>
 <552b3cb9-7316-490a-8bd3-86c037f536de@gmail.com>
Message-ID: <CAG_-AaAo6wKoeV7=qLGAvDgEq71gp1MyEeNRM-xRg4qDKzMbvg@mail.gmail.com>

Hi,

Ah, of course, I should have realized that myself.

It would be nice if there was a warning or a property developers can set to
prevent that, for example, to check and throw an error if a node is used
twice.

Thanks for pointing it out, and apologies for reporting a non-issue.

(P.S. I sent another email just before this that I don't think falls into
the same user-error category!)



Kind regards,
Cormac

On Sat, 8 Nov 2025 at 23:08, John Hendrikx <john.hendrikx at gmail.com> wrote:

> Hi,
>
> I'm guessing you're setting the disappearing item as "Graphic", because it
> is a Label and not a string.  However, you can only set a Node (anywhere,
> including as graphic) in one part of the scene graph.  Setting it somewhere
> else will cause it to be removed in the old location (without warning
> unfortunately).
>
> In this case, the Label is likely used as graphic in two places: once in
> the list (as a cell), and once in the edit area (as another cell) of the
> ComboBox when it was the last one selected.  This is causing the odd
> disappearing artifact.
>
> Best practice is to not use Nodes as items for a ComboBox.  Instead, use a
> Record or some other type that the ListCell::updateItem will convert to be
> shown in the way you want.
>
> --John
> On 08/11/2025 22:26, Cormac Redmond wrote:
>
> Hi,
>
> There is a bug whereby if you select a ComboBox item the item disappears /
> becomes invisible.
>
> This ComboBox consists of strings and a Label node and the Label node will
> disappear from the dropdown if it's selected (though, continue to take
> up space).
>
> I'm just picking a Label for example, it appears to happen with any Node
> that I've tried.
>
> [image: bug_cb.gif]
>
>
> Steps to reproduce (JFX 26, master branch). Note: I've kept the sample
> small intentionally, but if you use a CellFactory (to call setText() or
> setGraphic() accordingly, as normal), the *same* thing happens. In other
> words, the bug doesn't seem to be because of "mis-use" of the ComboBox by
> mixing types -- I think.
>
> public class ComboBoxDisappearingItemBug extends Application {
>     public static void main(String[] args) {
>         launch(args);
>     }
>
>     public void start(Stage stage) {
>         ComboBox<Object> cb = new ComboBox<>();
>         cb.getItems().addAll("Apple", "Banana", new Label("I will
> disappear"), "Carrot", "Lettuce");
>         cb.getSelectionModel().selectFirst();
>         stage.setScene(new Scene(cb, 200, 100));
>         stage.show();
>     }
> }
>
>
>
> Kind Regards,
> Cormac
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251109/f81badf5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug_cb.gif
Type: image/gif
Size: 85745 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251109/f81badf5/bug_cb-0001.gif>

From credmond at certak.com  Sun Nov  9 02:44:41 2025
From: credmond at certak.com (Cormac Redmond)
Date: Sun, 9 Nov 2025 02:44:41 +0000
Subject: ComboBox item height bug
In-Reply-To: <41357b68-7658-430a-b464-dc73599db978@gmail.com>
References: <CAG_-AaBUk78-=EiNwN9v7g3yr=FKiA7JW0S5PDYFDmzsgm8ENQ@mail.gmail.com>
 <41357b68-7658-430a-b464-dc73599db978@gmail.com>
Message-ID: <CAG_-AaAnqe9gjkrh29NACBBbB7PRrTx+C+UgR007rrOtpKVhpg@mail.gmail.com>

Hi John,

Thanks for the reply & details. One remaining question in my previous mail
however, was why a max *needs* to be set for min to "win"...this still
didn't make sense.

Similarly, I had already tried prefHeight on its own, but it has no effect
(unless it's set to number higher than the computed size of the cell, in
which case it would increase the size). Setting prefHeight and minHeight
together though, can achieve setting a "max height" though, just like
setting a maxHeight and minHeight as per my previous mail.

But I've noticed that values prefHeight, minHeight, maxHeight are all
defaulted to USE_COMPUTED_SIZE (-1)..., *not USE_PREF_SIZE* as you
mentioned, and I assumed.

So this explains the above behaviour and why several need to be set:
otherwise computed size wins one way or another.

Although confusing initially, I assume there's no bug here and that the
developer needs to always check the underlying nature of how pref/min/max
default values are set for any node, in order to know what and how to
override their settings...?


If you want some validation, you can see these -1 defaults, via a simpler
example:

public class ComboBoxHeightBug2 extends Application {
    public static void main(String[] args) {
        launch(args);
    }

    public void start(Stage stage) {
        ComboBox<Object> cb = new ComboBox<>();
        cb.getItems().addAll("Apple", "Banana", "Carrot", "Lettuce");
        cb.setCellFactory(_ -> new ListCell<>() {
            protected void updateItem(Object item, boolean empty) {
                super.updateItem(item, empty);
                if (empty || item == null) {
                    setText(null);
                    setGraphic(null);
                } else if (item instanceof Separator) {
                    setText(null);
                    setGraphic((Separator) item);
                    setDisable(true);
                } else {
                    System.out.println("minHeight: " + getMinHeight()); //
-1
                    System.out.println("maxHeight: " + getMaxHeight()); //
-1
                    System.out.println("prefHeight: " + getPrefHeight());
// -1
                    setText(item.toString());
                    setGraphic(null);
                    setStyle("");
                }
            }
        });

        cb.getSelectionModel().selectFirst();
        stage.setScene(new Scene(cb, 200, 100));
        stage.show();
    }
}




Kind Regards,
Cormac



On Sun, 9 Nov 2025 at 00:06, John Hendrikx <john.hendrikx at gmail.com> wrote:

> What you are likely seeing is that the minimum always wins over the other
> values.
>
> The minimum height is set to the constant USE_PREF_SIZE, which means that
> it will take the preferred size for the minimum height.
>
> When it comes to size priorities (min, pref and max), minimum always wins,
> then comes maximum, then comes preferred.
>
> So in this case, the preferred size is say 20.  The minimum follows the
> preferred, also 20.  You set maximum to 1.  Minimum > Maximum, so Maximum
> is ignored.
>
> What you could try is set preferred size smaller instead; there should be
> no need to change minimum or maximum then.
>
> --John
> On 08/11/2025 21:30, Cormac Redmond wrote:
>
> Hi,
>
> I have found a height bug when I am trying to reduce the height of one
> ComboBox item (a Separator) in a simple ComboBox.
>
> One would expect that to achieve this, you'd set the maximum height for
> that particular ListCell; but this has no effect.
>
> Instead what I need to do is set the *minimum* height (but to the value I
> wish to be the maximum height), and I must *also *set the *maximum *height
> to any value (if I do not, my minimum height (i.e., my desired maximum)
> gets ignored)...
>
> For example, if I want the maximum height of this Separator to be 6, I
> must set the minimum height to 6 and I must set the maximum height to
> anything, even 1.
>
> Obviously this is counter-intuitive and doesn't make any logical sense.
>
> Example to reproduce (running from JFX master branch):
>
> public class ComboBoxHeightBug extends Application {
>     public static void main(String[] args) {
>         launch(args);
>     }
>
>     public void start(Stage stage) {
>         ComboBox<Object> cb = new ComboBox<>();
>         cb.getItems().addAll("Apple", "Banana",  new Separator() ,
> "Carrot", "Lettuce");
>         cb.setCellFactory(_ -> new ListCell<>() {
>             protected void updateItem(Object item, boolean empty) {
>                 super.updateItem(item, empty);
>                 if (empty || item == null) {
>                     setText(null);
>                     setGraphic(null);
>                     setStyle("");
>                     // Set back to default
>                     setMinHeight(USE_PREF_SIZE);
>                     setMaxHeight(Double.MAX_VALUE);
>                 } else if (item instanceof Separator) {
>                     setText(null);
>                     setGraphic((Separator) item);
>                     setDisable(true);
>                     setMinHeight(6); // This is required for any "max
> height" to apply, and appears to be the value that is used to determine
> height
>                     setMaxHeight(1); // Setting this (to 6) should work on
> its own, it doesn't, the value appears irrelevant -- but it MUST be set to
> get the separator height to be 6
>                 } else {
>                     setText(item.toString());
>                     setGraphic(null);
>                     setStyle("");
>                     // Set back to default
>                     setMinHeight(USE_PREF_SIZE);
>                     setMaxHeight(Double.MAX_VALUE);
>                 }
>             }
>         });
>
>         cb.getSelectionModel().selectFirst();
>         stage.setScene(new Scene(cb, 200, 100));
>         stage.show();
>     }
> }
>
> Note: I have noticed a few issues like this in general, whereby it
> requires trial and error to get *some* desired height to apply; without
> any apparent logic as to how these values are being arrived at or how
> they're triggered to be used (I have logged bugs before on this)...
>
>
> Kind Regards,
> Cormac
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251109/3db1eeca/attachment.htm>

From psadhukhan at openjdk.org  Sun Nov  9 07:23:26 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 9 Nov 2025 07:23:26 GMT
Subject: Integrated: 8371386: Fix potential NPE in SwingNode
In-Reply-To: <l4a-jc7xeqRWm_plz2vkjX3yvJZxcqhQgxHTKGEZFhI=.842f452b-4b5e-4b8f-995f-fd205232c296@github.com>
References: <l4a-jc7xeqRWm_plz2vkjX3yvJZxcqhQgxHTKGEZFhI=.842f452b-4b5e-4b8f-995f-fd205232c296@github.com>
Message-ID: <kbDeIiDflXO4RSGyCV1vEoZUaZBFpCGt8p3vFuyxp6Q=.2dff54af-2546-49de-9652-2fbe6c8b2c0a@github.com>

On Thu, 6 Nov 2025 03:57:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> There can be potential NPEs in SwingNode which is fixed

This pull request has now been integrated.

Changeset: 5e3a5e1a
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/5e3a5e1aa9914b68c7a94c530201356f5e3e583e
Stats:     22 lines in 1 file changed: 8 ins; 8 del; 6 mod

8371386: Fix potential NPE in SwingNode

Reviewed-by: kcr, angorya

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

PR: https://git.openjdk.org/jfx/pull/1965

From john.hendrikx at gmail.com  Sun Nov  9 18:50:24 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sun, 9 Nov 2025 19:50:24 +0100
Subject: ComboBox item height bug
In-Reply-To: <CAG_-AaAnqe9gjkrh29NACBBbB7PRrTx+C+UgR007rrOtpKVhpg@mail.gmail.com>
References: <CAG_-AaBUk78-=EiNwN9v7g3yr=FKiA7JW0S5PDYFDmzsgm8ENQ@mail.gmail.com>
 <41357b68-7658-430a-b464-dc73599db978@gmail.com>
 <CAG_-AaAnqe9gjkrh29NACBBbB7PRrTx+C+UgR007rrOtpKVhpg@mail.gmail.com>
Message-ID: <fc5e24d9-35aa-4df7-a04b-1cdb98291d25@gmail.com>

Hi,

Normally a cell will have computed values for each of the min/pref/max.?
In your example, you were resetting the cells to USE_PREF_SIZE, but it
makes little difference in the reasoning.? All the size of a cell
control (which is a label) will be the label's size to display its
text.? Its preferred height will be say 20.? Its minimum will also be 20
to avoid cuts off.? Its maximum will be 20 because there is no reason
for it to take up more space. Those are the computes sizes.? If you
change all to USE_PREF_SIZE, nothing changes (since pref is 20, min and
max will copy that).? So:

- min/pref/max height are 20/20/20
- you set minimum to 6
- end result: pref height wins with 20 as it is within the range [min, max]
- you also set maximum to 1
- end result: pref height is now outside the min/max range, so it is
ignored; max is smaller than min, so it is ignored; min wins with 6

If you however set minimum to USE_PREF_SIZE (as was done in your
original code) or set it to 1, then you can use the pref size to change
it.? Either because 1 is smaller than the pref size, and so changing
pref size to a smaller value won't make it go out of range; or in the
USE_PREF_SIZE case, because min will simply track the pref size value
and always change with it.

--John

On 09/11/2025 03:44, Cormac Redmond wrote:
> Hi John,
>
> Thanks for the reply & details. One remaining question in my previous
> mail however, was why a max?*needs*?to be set for min to "win"...this
> still didn't make sense.
>
> Similarly, I had already tried prefHeight on its own, but it has no
> effect (unless it's set to number higher than the computed size of the
> cell, in which case it would increase the size). Setting prefHeight
> and minHeight together though, can achieve setting a "max height"
> though, just like setting a maxHeight and minHeight as per my previous
> mail.
>
> But I've noticed that values prefHeight, minHeight, maxHeight are all
> defaulted to USE_COMPUTED_SIZE (-1)..., *not USE_PREF_SIZE*?as you
> mentioned, and I assumed.
>
> So this explains the above behaviour and why several need to be set:
> otherwise computed size wins one way or another.
>
> Although confusing initially, I assume there's no bug here and that
> the developer needs to always check the underlying nature of how
> pref/min/max default values are set for any node, in order to know
> what and how to override their settings...?
>
>
> If you want some validation, you can see these -1 defaults, via a
> simpler example:
>
> public class ComboBoxHeightBug2 extends Application {
> ? ? public static void main(String[] args) {
> ? ? ? ? launch(args);
> ? ? }
>
> ? ? public void start(Stage stage) {
> ? ? ? ? ComboBox<Object> cb = new ComboBox<>();
> ? ? ? ? cb.getItems().addAll("Apple", "Banana", "Carrot", "Lettuce");
> ? ? ? ? cb.setCellFactory(_ -> new ListCell<>() {
> ? ? ? ? ? ? protected void updateItem(Object item, boolean empty) {
> ? ? ? ? ? ? ? ? super.updateItem(item, empty);
> ? ? ? ? ? ? ? ? if (empty || item == null) {
> ? ? ? ? ? ? ? ? ? ? setText(null);
> ? ? ? ? ? ? ? ? ? ? setGraphic(null);
> ? ? ? ? ? ? ? ? } else if (item instanceof Separator) {
> ? ? ? ? ? ? ? ? ? ? setText(null);
> ? ? ? ? ? ? ? ? ? ? setGraphic((Separator) item);
> ? ? ? ? ? ? ? ? ? ? setDisable(true);
> ? ? ? ? ? ? ? ? } else {
> ? ? ? ? ? ? ? ? ? ? System.out.println("minHeight: " +
> getMinHeight()); // -1
> ? ? ? ? ? ? ? ? ? ? System.out.println("maxHeight: " +
> getMaxHeight()); // -1
> ? ? ? ? ? ? ? ? ? ? System.out.println("prefHeight: " +
> getPrefHeight()); // -1
> ? ? ? ? ? ? ? ? ? ? setText(item.toString());
> ? ? ? ? ? ? ? ? ? ? setGraphic(null);
> ? ? ? ? ? ? ? ? ? ? setStyle("");
> ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? }
> ? ? ? ? });
>
> ? ? ? ? cb.getSelectionModel().selectFirst();
> ? ? ? ? stage.setScene(new Scene(cb, 200, 100));
> ? ? ? ? stage.show();
> ? ? }
> }
>
>
>
>
> Kind Regards,
> Cormac
>
>
>
> On Sun, 9 Nov 2025 at 00:06, John Hendrikx <john.hendrikx at gmail.com>
> wrote:
>
>     What you are likely seeing is that the minimum always wins over
>     the other values.
>
>     The minimum height is set to the constant USE_PREF_SIZE, which
>     means that it will take the preferred size for the minimum height.
>
>     When it comes to size priorities (min, pref and max), minimum
>     always wins, then comes maximum, then comes preferred.
>
>     So in this case, the preferred size is say 20.? The minimum
>     follows the preferred, also 20.? You set maximum to 1.? Minimum >
>     Maximum, so Maximum is ignored.
>
>     What you could try is set preferred size smaller instead; there
>     should be no need to change minimum or maximum then.
>
>     --John
>
>     On 08/11/2025 21:30, Cormac Redmond wrote:
>>     Hi,
>>
>>     I have found a height bug when I am trying to reduce?the height
>>     of one ComboBox item (a Separator) in a simple ComboBox.
>>
>>     One would expect that to achieve this, you'd set the maximum
>>     height for that particular ListCell; but this has no?effect.
>>
>>     Instead what I need to do is set the /minimum/ height (but to the
>>     value I wish to be the maximum height), and I must *also *set the
>>     /maximum /height to any value (if I do not, my minimum height
>>     (i.e., my desired maximum) gets ignored)...
>>
>>     For example, if I want the?maximum height of this Separator to be
>>     6, I must set the minimum height to 6 and I must set the maximum
>>     height to anything, even 1.
>>
>>     Obviously this is counter-intuitive and doesn't make?any?logical
>>     sense.
>>
>>     Example to reproduce (running from JFX master branch):
>>
>>     public class ComboBoxHeightBug extends Application {
>>     ? ? public static void main(String[] args) {
>>     ? ? ? ? launch(args);
>>     ? ? }
>>
>>     ? ? public void start(Stage stage) {
>>     ? ? ? ? ComboBox<Object> cb = new ComboBox<>();
>>     ? ? ? ? cb.getItems().addAll("Apple", "Banana",? new
>>     Separator()?, "Carrot", "Lettuce");
>>     ? ? ? ? cb.setCellFactory(_ -> new ListCell<>() {
>>     ? ? ? ? ? ? protected void updateItem(Object item, boolean empty) {
>>     ? ? ? ? ? ? ? ? super.updateItem(item, empty);
>>     ? ? ? ? ? ? ? ? if (empty || item == null) {
>>     ? ? ? ? ? ? ? ? ? ? setText(null);
>>     ? ? ? ? ? ? ? ? ? ? setGraphic(null);
>>     ? ? ? ? ? ? ? ? ? ? setStyle("");
>>     ? ? ? ? ? ? ? ? ? ? // Set back to default
>>     ? ? ? ? ? ? ? ? ? ? setMinHeight(USE_PREF_SIZE);
>>     ? ? ? ? ? ? ? ? ? ? setMaxHeight(Double.MAX_VALUE);
>>     ? ? ? ? ? ? ? ? } else if (item instanceof Separator) {
>>     ? ? ? ? ? ? ? ? ? ? setText(null);
>>     ? ? ? ? ? ? ? ? ? ? setGraphic((Separator) item);
>>     ? ? ? ? ? ? ? ? ? ? setDisable(true);
>>     ? ? ? ? ? ? ? ? ? ? setMinHeight(6); // This is required for any
>>     "max height" to apply, and appears to be the value that is used
>>     to determine height
>>     ? ? ? ? ? ? ? ? ? ? setMaxHeight(1); // Setting this (to 6)
>>     should work on its own, it doesn't, the value appears irrelevant
>>     -- but it MUST be set to get the separator height to be 6
>>     ? ? ? ? ? ? ? ? } else {
>>     ? ? ? ? ? ? ? ? ? ? setText(item.toString());
>>     ? ? ? ? ? ? ? ? ? ? setGraphic(null);
>>     ? ? ? ? ? ? ? ? ? ? setStyle("");
>>     ? ? ? ? ? ? ? ? ? ? // Set back to default
>>     ? ? ? ? ? ? ? ? ? ? setMinHeight(USE_PREF_SIZE);
>>     ? ? ? ? ? ? ? ? ? ? setMaxHeight(Double.MAX_VALUE);
>>     ? ? ? ? ? ? ? ? }
>>     ? ? ? ? ? ? }
>>     ? ? ? ? });
>>
>>     ? ? ? ? cb.getSelectionModel().selectFirst();
>>     ? ? ? ? stage.setScene(new Scene(cb, 200, 100));
>>     ? ? ? ? stage.show();
>>     ? ? }
>>     }
>>
>>     Note: I have noticed a few issues like this in general, whereby
>>     it requires trial and error to get?/some/?desired height to
>>     apply; without any apparent logic as to how these values are
>>     being arrived at or how they're triggered to be used (I have
>>     logged bugs before on this)...
>>
>>
>>     Kind Regards,
>>     Cormac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251109/6a2c2cc1/attachment-0001.htm>

From nlisker at gmail.com  Sun Nov  9 23:34:15 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 10 Nov 2025 01:34:15 +0200
Subject: ComboBox item height bug
In-Reply-To: <fc5e24d9-35aa-4df7-a04b-1cdb98291d25@gmail.com>
References: <CAG_-AaBUk78-=EiNwN9v7g3yr=FKiA7JW0S5PDYFDmzsgm8ENQ@mail.gmail.com>
 <41357b68-7658-430a-b464-dc73599db978@gmail.com>
 <CAG_-AaAnqe9gjkrh29NACBBbB7PRrTx+C+UgR007rrOtpKVhpg@mail.gmail.com>
 <fc5e24d9-35aa-4df7-a04b-1cdb98291d25@gmail.com>
Message-ID: <CA+0ynh-SE7wWiewcY_GJ1T64NZr78XV6hw68GVuguSFhAuqXsQ@mail.gmail.com>

>
> When it comes to size priorities (min, pref and max), minimum always wins,
> then comes maximum, then comes preferred.
> - min/pref/max height are 20/20/20
> - you set minimum to 6
> - end result: pref height wins with 20 as it is within the range [min, max]
> - you also set maximum to 1
> - end result: pref height is now outside the min/max range, so it is
> ignored; max is smaller than min, so it is ignored; min wins with 6


Is this documented somewhere? I'd think it would answer a lot of confusing
questions.

On Sun, Nov 9, 2025 at 8:50?PM John Hendrikx <john.hendrikx at gmail.com>
wrote:

> Hi,
>
> Normally a cell will have computed values for each of the min/pref/max.
> In your example, you were resetting the cells to USE_PREF_SIZE, but it
> makes little difference in the reasoning.  All the size of a cell control
> (which is a label) will be the label's size to display its text.  Its
> preferred height will be say 20.  Its minimum will also be 20 to avoid cuts
> off.  Its maximum will be 20 because there is no reason for it to take up
> more space. Those are the computes sizes.  If you change all to
> USE_PREF_SIZE, nothing changes (since pref is 20, min and max will copy
> that).  So:
>
> - min/pref/max height are 20/20/20
> - you set minimum to 6
> - end result: pref height wins with 20 as it is within the range [min, max]
> - you also set maximum to 1
> - end result: pref height is now outside the min/max range, so it is
> ignored; max is smaller than min, so it is ignored; min wins with 6
>
> If you however set minimum to USE_PREF_SIZE (as was done in your original
> code) or set it to 1, then you can use the pref size to change it.  Either
> because 1 is smaller than the pref size, and so changing pref size to a
> smaller value won't make it go out of range; or in the USE_PREF_SIZE case,
> because min will simply track the pref size value and always change with it.
>
> --John
> On 09/11/2025 03:44, Cormac Redmond wrote:
>
> Hi John,
>
> Thanks for the reply & details. One remaining question in my previous mail
> however, was why a max *needs* to be set for min to "win"...this still
> didn't make sense.
>
> Similarly, I had already tried prefHeight on its own, but it has no effect
> (unless it's set to number higher than the computed size of the cell, in
> which case it would increase the size). Setting prefHeight and minHeight
> together though, can achieve setting a "max height" though, just like
> setting a maxHeight and minHeight as per my previous mail.
>
> But I've noticed that values prefHeight, minHeight, maxHeight are all
> defaulted to USE_COMPUTED_SIZE (-1)..., *not USE_PREF_SIZE* as you
> mentioned, and I assumed.
>
> So this explains the above behaviour and why several need to be set:
> otherwise computed size wins one way or another.
>
> Although confusing initially, I assume there's no bug here and that the
> developer needs to always check the underlying nature of how pref/min/max
> default values are set for any node, in order to know what and how to
> override their settings...?
>
>
> If you want some validation, you can see these -1 defaults, via a simpler
> example:
>
> public class ComboBoxHeightBug2 extends Application {
>     public static void main(String[] args) {
>         launch(args);
>     }
>
>     public void start(Stage stage) {
>         ComboBox<Object> cb = new ComboBox<>();
>         cb.getItems().addAll("Apple", "Banana", "Carrot", "Lettuce");
>         cb.setCellFactory(_ -> new ListCell<>() {
>             protected void updateItem(Object item, boolean empty) {
>                 super.updateItem(item, empty);
>                 if (empty || item == null) {
>                     setText(null);
>                     setGraphic(null);
>                 } else if (item instanceof Separator) {
>                     setText(null);
>                     setGraphic((Separator) item);
>                     setDisable(true);
>                 } else {
>                     System.out.println("minHeight: " + getMinHeight()); //
> -1
>                     System.out.println("maxHeight: " + getMaxHeight()); //
> -1
>                     System.out.println("prefHeight: " + getPrefHeight());
> // -1
>                     setText(item.toString());
>                     setGraphic(null);
>                     setStyle("");
>                 }
>             }
>         });
>
>         cb.getSelectionModel().selectFirst();
>         stage.setScene(new Scene(cb, 200, 100));
>         stage.show();
>     }
> }
>
>
>
>
> Kind Regards,
> Cormac
>
>
>
> On Sun, 9 Nov 2025 at 00:06, John Hendrikx <john.hendrikx at gmail.com>
> wrote:
>
>> What you are likely seeing is that the minimum always wins over the other
>> values.
>>
>> The minimum height is set to the constant USE_PREF_SIZE, which means
>> that it will take the preferred size for the minimum height.
>>
>> When it comes to size priorities (min, pref and max), minimum always
>> wins, then comes maximum, then comes preferred.
>>
>> So in this case, the preferred size is say 20.  The minimum follows the
>> preferred, also 20.  You set maximum to 1.  Minimum > Maximum, so Maximum
>> is ignored.
>>
>> What you could try is set preferred size smaller instead; there should be
>> no need to change minimum or maximum then.
>>
>> --John
>> On 08/11/2025 21:30, Cormac Redmond wrote:
>>
>> Hi,
>>
>> I have found a height bug when I am trying to reduce the height of one
>> ComboBox item (a Separator) in a simple ComboBox.
>>
>> One would expect that to achieve this, you'd set the maximum height for
>> that particular ListCell; but this has no effect.
>>
>> Instead what I need to do is set the *minimum* height (but to the value
>> I wish to be the maximum height), and I must *also *set the *maximum *height
>> to any value (if I do not, my minimum height (i.e., my desired maximum)
>> gets ignored)...
>>
>> For example, if I want the maximum height of this Separator to be 6, I
>> must set the minimum height to 6 and I must set the maximum height to
>> anything, even 1.
>>
>> Obviously this is counter-intuitive and doesn't make any logical sense.
>>
>> Example to reproduce (running from JFX master branch):
>>
>> public class ComboBoxHeightBug extends Application {
>>     public static void main(String[] args) {
>>         launch(args);
>>     }
>>
>>     public void start(Stage stage) {
>>         ComboBox<Object> cb = new ComboBox<>();
>>         cb.getItems().addAll("Apple", "Banana",  new Separator() ,
>> "Carrot", "Lettuce");
>>         cb.setCellFactory(_ -> new ListCell<>() {
>>             protected void updateItem(Object item, boolean empty) {
>>                 super.updateItem(item, empty);
>>                 if (empty || item == null) {
>>                     setText(null);
>>                     setGraphic(null);
>>                     setStyle("");
>>                     // Set back to default
>>                     setMinHeight(USE_PREF_SIZE);
>>                     setMaxHeight(Double.MAX_VALUE);
>>                 } else if (item instanceof Separator) {
>>                     setText(null);
>>                     setGraphic((Separator) item);
>>                     setDisable(true);
>>                     setMinHeight(6); // This is required for any "max
>> height" to apply, and appears to be the value that is used to determine
>> height
>>                     setMaxHeight(1); // Setting this (to 6) should work
>> on its own, it doesn't, the value appears irrelevant -- but it MUST be set
>> to get the separator height to be 6
>>                 } else {
>>                     setText(item.toString());
>>                     setGraphic(null);
>>                     setStyle("");
>>                     // Set back to default
>>                     setMinHeight(USE_PREF_SIZE);
>>                     setMaxHeight(Double.MAX_VALUE);
>>                 }
>>             }
>>         });
>>
>>         cb.getSelectionModel().selectFirst();
>>         stage.setScene(new Scene(cb, 200, 100));
>>         stage.show();
>>     }
>> }
>>
>> Note: I have noticed a few issues like this in general, whereby it
>> requires trial and error to get *some* desired height to apply; without
>> any apparent logic as to how these values are being arrived at or how
>> they're triggered to be used (I have logged bugs before on this)...
>>
>>
>> Kind Regards,
>> Cormac
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251110/d88172d0/attachment-0001.htm>

From john.hendrikx at gmail.com  Mon Nov 10 01:10:37 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 10 Nov 2025 02:10:37 +0100
Subject: ComboBox item height bug
In-Reply-To: <CA+0ynh-SE7wWiewcY_GJ1T64NZr78XV6hw68GVuguSFhAuqXsQ@mail.gmail.com>
References: <CAG_-AaBUk78-=EiNwN9v7g3yr=FKiA7JW0S5PDYFDmzsgm8ENQ@mail.gmail.com>
 <41357b68-7658-430a-b464-dc73599db978@gmail.com>
 <CAG_-AaAnqe9gjkrh29NACBBbB7PRrTx+C+UgR007rrOtpKVhpg@mail.gmail.com>
 <fc5e24d9-35aa-4df7-a04b-1cdb98291d25@gmail.com>
 <CA+0ynh-SE7wWiewcY_GJ1T64NZr78XV6hw68GVuguSFhAuqXsQ@mail.gmail.com>
Message-ID: <2159dff4-a4b4-4c1c-b650-b0dd9bce0b25@gmail.com>

Hi Nir,

I got this mainly from non-public API Region#boundedSize

Node#minWidth and Node#maxWidth do document their respective behaviors,
but Node#prefWidth doesn't very explicitly state that it is clamped to
min/max.

--John

On 10/11/2025 00:34, Nir Lisker wrote:
>
>     When it comes to size priorities (min, pref and max), minimum
>     always wins, then comes maximum, then comes preferred.
>
>     - min/pref/max height are 20/20/20
>     - you set minimum to 6
>     - end result: pref height wins with 20 as it is within the range
>     [min, max]
>     - you also set maximum to 1
>     - end result: pref height is now outside the min/max range, so it
>     is ignored; max is smaller than min, so it is ignored; min wins with 6
>
>
> Is this documented somewhere? I'd think it would answer a lot of
> confusing questions.?
>
> On Sun, Nov 9, 2025 at 8:50?PM John Hendrikx <john.hendrikx at gmail.com>
> wrote:
>
>     Hi,
>
>     Normally a cell will have computed values for each of the
>     min/pref/max.? In your example, you were resetting the cells to
>     USE_PREF_SIZE, but it makes little difference in the reasoning.?
>     All the size of a cell control (which is a label) will be the
>     label's size to display its text.? Its preferred height will be
>     say 20.? Its minimum will also be 20 to avoid cuts off.? Its
>     maximum will be 20 because there is no reason for it to take up
>     more space. Those are the computes sizes.? If you change all to
>     USE_PREF_SIZE, nothing changes (since pref is 20, min and max will
>     copy that).? So:
>
>     - min/pref/max height are 20/20/20
>     - you set minimum to 6
>     - end result: pref height wins with 20 as it is within the range
>     [min, max]
>     - you also set maximum to 1
>     - end result: pref height is now outside the min/max range, so it
>     is ignored; max is smaller than min, so it is ignored; min wins with 6
>
>     If you however set minimum to USE_PREF_SIZE (as was done in your
>     original code) or set it to 1, then you can use the pref size to
>     change it.? Either because 1 is smaller than the pref size, and so
>     changing pref size to a smaller value won't make it go out of
>     range; or in the USE_PREF_SIZE case, because min will simply track
>     the pref size value and always change with it.
>
>     --John
>
>     On 09/11/2025 03:44, Cormac Redmond wrote:
>>     Hi John,
>>
>>     Thanks for the reply & details. One remaining question in my
>>     previous mail however, was why a max?*needs*?to be set for min to
>>     "win"...this still didn't make sense.
>>
>>     Similarly, I had already tried prefHeight on its own, but it has
>>     no effect (unless it's set to number higher than the computed
>>     size of the cell, in which case it would increase the size).
>>     Setting prefHeight and minHeight together though, can achieve
>>     setting a "max height" though, just like setting a maxHeight and
>>     minHeight as per my previous mail.
>>
>>     But I've noticed that values prefHeight, minHeight, maxHeight are
>>     all defaulted to USE_COMPUTED_SIZE (-1)..., *not
>>     USE_PREF_SIZE*?as you mentioned, and I assumed.
>>
>>     So this explains the above behaviour and why several need to be
>>     set: otherwise computed size wins one way or another.
>>
>>     Although confusing initially, I assume there's no bug here and
>>     that the developer needs to always check the underlying nature of
>>     how pref/min/max default values are set for any node, in order to
>>     know what and how to override their settings...?
>>
>>
>>     If you want some validation, you can see these -1 defaults, via a
>>     simpler example:
>>
>>     public class ComboBoxHeightBug2 extends Application {
>>     ? ? public static void main(String[] args) {
>>     ? ? ? ? launch(args);
>>     ? ? }
>>
>>     ? ? public void start(Stage stage) {
>>     ? ? ? ? ComboBox<Object> cb = new ComboBox<>();
>>     ? ? ? ? cb.getItems().addAll("Apple", "Banana", "Carrot", "Lettuce");
>>     ? ? ? ? cb.setCellFactory(_ -> new ListCell<>() {
>>     ? ? ? ? ? ? protected void updateItem(Object item, boolean empty) {
>>     ? ? ? ? ? ? ? ? super.updateItem(item, empty);
>>     ? ? ? ? ? ? ? ? if (empty || item == null) {
>>     ? ? ? ? ? ? ? ? ? ? setText(null);
>>     ? ? ? ? ? ? ? ? ? ? setGraphic(null);
>>     ? ? ? ? ? ? ? ? } else if (item instanceof Separator) {
>>     ? ? ? ? ? ? ? ? ? ? setText(null);
>>     ? ? ? ? ? ? ? ? ? ? setGraphic((Separator) item);
>>     ? ? ? ? ? ? ? ? ? ? setDisable(true);
>>     ? ? ? ? ? ? ? ? } else {
>>     ? ? ? ? ? ? ? ? ? ? System.out.println("minHeight: " +
>>     getMinHeight()); // -1
>>     ? ? ? ? ? ? ? ? ? ? System.out.println("maxHeight: " +
>>     getMaxHeight()); // -1
>>     ? ? ? ? ? ? ? ? ? ? System.out.println("prefHeight: " +
>>     getPrefHeight()); // -1
>>     ? ? ? ? ? ? ? ? ? ? setText(item.toString());
>>     ? ? ? ? ? ? ? ? ? ? setGraphic(null);
>>     ? ? ? ? ? ? ? ? ? ? setStyle("");
>>     ? ? ? ? ? ? ? ? }
>>     ? ? ? ? ? ? }
>>     ? ? ? ? });
>>
>>     ? ? ? ? cb.getSelectionModel().selectFirst();
>>     ? ? ? ? stage.setScene(new Scene(cb, 200, 100));
>>     ? ? ? ? stage.show();
>>     ? ? }
>>     }
>>
>>
>>
>>
>>     Kind Regards,
>>     Cormac
>>
>>
>>
>>     On Sun, 9 Nov 2025 at 00:06, John Hendrikx
>>     <john.hendrikx at gmail.com> wrote:
>>
>>         What you are likely seeing is that the minimum always wins
>>         over the other values.
>>
>>         The minimum height is set to the constant USE_PREF_SIZE,
>>         which means that it will take the preferred size for the
>>         minimum height.
>>
>>         When it comes to size priorities (min, pref and max), minimum
>>         always wins, then comes maximum, then comes preferred.
>>
>>         So in this case, the preferred size is say 20.? The minimum
>>         follows the preferred, also 20.? You set maximum to 1.?
>>         Minimum > Maximum, so Maximum is ignored.
>>
>>         What you could try is set preferred size smaller instead;
>>         there should be no need to change minimum or maximum then.
>>
>>         --John
>>
>>         On 08/11/2025 21:30, Cormac Redmond wrote:
>>>         Hi,
>>>
>>>         I have found a height bug when I am trying to reduce?the
>>>         height of one ComboBox item (a Separator) in a simple ComboBox.
>>>
>>>         One would expect that to achieve this, you'd set the maximum
>>>         height for that particular ListCell; but this has no?effect.
>>>
>>>         Instead what I need to do is set the /minimum/ height (but
>>>         to the value I wish to be the maximum height), and I must
>>>         *also *set the /maximum /height to any value (if I do not,
>>>         my minimum height (i.e., my desired maximum) gets ignored)...
>>>
>>>         For example, if I want the?maximum height of this Separator
>>>         to be 6, I must set the minimum height to 6 and I must set
>>>         the maximum height to anything, even 1.
>>>
>>>         Obviously this is counter-intuitive and doesn't
>>>         make?any?logical sense.
>>>
>>>         Example to reproduce (running from JFX master branch):
>>>
>>>         public class ComboBoxHeightBug extends Application {
>>>         ? ? public static void main(String[] args) {
>>>         ? ? ? ? launch(args);
>>>         ? ? }
>>>
>>>         ? ? public void start(Stage stage) {
>>>         ? ? ? ? ComboBox<Object> cb = new ComboBox<>();
>>>         ? ? ? ? cb.getItems().addAll("Apple", "Banana",? new
>>>         Separator()?, "Carrot", "Lettuce");
>>>         ? ? ? ? cb.setCellFactory(_ -> new ListCell<>() {
>>>         ? ? ? ? ? ? protected void updateItem(Object item, boolean
>>>         empty) {
>>>         ? ? ? ? ? ? ? ? super.updateItem(item, empty);
>>>         ? ? ? ? ? ? ? ? if (empty || item == null) {
>>>         ? ? ? ? ? ? ? ? ? ? setText(null);
>>>         ? ? ? ? ? ? ? ? ? ? setGraphic(null);
>>>         ? ? ? ? ? ? ? ? ? ? setStyle("");
>>>         ? ? ? ? ? ? ? ? ? ? // Set back to default
>>>         ? ? ? ? ? ? ? ? ? ? setMinHeight(USE_PREF_SIZE);
>>>         ? ? ? ? ? ? ? ? ? ? setMaxHeight(Double.MAX_VALUE);
>>>         ? ? ? ? ? ? ? ? } else if (item instanceof Separator) {
>>>         ? ? ? ? ? ? ? ? ? ? setText(null);
>>>         ? ? ? ? ? ? ? ? ? ? setGraphic((Separator) item);
>>>         ? ? ? ? ? ? ? ? ? ? setDisable(true);
>>>         ? ? ? ? ? ? ? ? ? ? setMinHeight(6); // This is required for
>>>         any "max height" to apply, and appears to be the value that
>>>         is used to determine height
>>>         ? ? ? ? ? ? ? ? ? ? setMaxHeight(1); // Setting this (to 6)
>>>         should work on its own, it doesn't, the value appears
>>>         irrelevant -- but it MUST be set to get the separator height
>>>         to be 6
>>>         ? ? ? ? ? ? ? ? } else {
>>>         ? ? ? ? ? ? ? ? ? ? setText(item.toString());
>>>         ? ? ? ? ? ? ? ? ? ? setGraphic(null);
>>>         ? ? ? ? ? ? ? ? ? ? setStyle("");
>>>         ? ? ? ? ? ? ? ? ? ? // Set back to default
>>>         ? ? ? ? ? ? ? ? ? ? setMinHeight(USE_PREF_SIZE);
>>>         ? ? ? ? ? ? ? ? ? ? setMaxHeight(Double.MAX_VALUE);
>>>         ? ? ? ? ? ? ? ? }
>>>         ? ? ? ? ? ? }
>>>         ? ? ? ? });
>>>
>>>         ? ? ? ? cb.getSelectionModel().selectFirst();
>>>         ? ? ? ? stage.setScene(new Scene(cb, 200, 100));
>>>         ? ? ? ? stage.show();
>>>         ? ? }
>>>         }
>>>
>>>         Note: I have noticed a few issues like this in general,
>>>         whereby it requires trial and error to get?/some/?desired
>>>         height to apply; without any apparent logic as to how these
>>>         values are being arrived at or how they're triggered to be
>>>         used (I have logged bugs before on this)...
>>>
>>>
>>>         Kind Regards,
>>>         Cormac
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251110/cb046cc3/attachment-0001.htm>

From arapte at openjdk.org  Mon Nov 10 05:52:19 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 10 Nov 2025 05:52:19 GMT
Subject: RFR: 8371052: Update libFFI to 3.5.2 [v2]
In-Reply-To: <6qUPKNTM1YxB1M4ArEvbgN45e_HqRzcDaqQ6NpUdlRg=.6d67057e-08c2-4f0b-be82-c8e7326cde26@github.com>
References: <EihmQlWsI1W2GLW_YDC8pOUhxQnzSfn4W5q1NvH2euM=.d769fa13-8113-43d1-8c37-1fcd849f653d@github.com>
 <6qUPKNTM1YxB1M4ArEvbgN45e_HqRzcDaqQ6NpUdlRg=.6d67057e-08c2-4f0b-be82-c8e7326cde26@github.com>
Message-ID: <maHAuKekyt7q-P4yBRxbshFPHHrqLyUCcW9tIecLofM=.b92d4aba-05f3-42bd-aec5-751253384b76@github.com>

On Fri, 7 Nov 2025 00:05:59 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Updated libFFI to 3.5.2.
>> - Tested on all platforms.
>> - No additional changes are done.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8371052: Update libFFI to 3.5.2 [v3]

LGTM.
May be as follow up or with next upgrade, please consider adding a UPDATING.txt file to document the steps to upgrade.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1962#pullrequestreview-3440975122

From jdv at openjdk.org  Mon Nov 10 05:58:28 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 10 Nov 2025 05:58:28 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v13]
In-Reply-To: <LMPFI2YIdsctg7KCsj39455YwQndiYFgdJUOo0s9AzI=.5b6d2483-7a22-4324-8f91-21d4815a6a0c@github.com>
References: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
 <LMPFI2YIdsctg7KCsj39455YwQndiYFgdJUOo0s9AzI=.5b6d2483-7a22-4324-8f91-21d4815a6a0c@github.com>
Message-ID: <xJT1xQk136h-8rGQiPl7VIRh8IvmoXsUXUoZCl1JUzY=.ac8eed85-3de4-409f-b900-3c7eb4a80a47@github.com>

On Fri, 7 Nov 2025 16:47:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev 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 branch 'master' into 8366201.allow.undo
>  - review comments
>  - Merge branch 'master' into 8366201.allow.undo
>  - javadoc
>  - suggestion
>    
>    Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
>  - set text
>  - Merge branch 'master' into 8366201.allow.undo
>  - undo/redo javadoc in model only
>  - javadoc
>  - the
>  - ... and 12 more: https://git.openjdk.org/jfx/compare/bb660211...4f3cf21f

Marked as reviewed by jdv (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1941#pullrequestreview-3440992883

From jdv at openjdk.org  Mon Nov 10 06:18:21 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 10 Nov 2025 06:18:21 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v15]
In-Reply-To: <VJwun5rVStCRmY4epAw1jWeCMyKrzc7X4HNyP88HUCM=.5d2d5b05-b51e-440f-95a6-31c938225c05@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <VJwun5rVStCRmY4epAw1jWeCMyKrzc7X4HNyP88HUCM=.5d2d5b05-b51e-440f-95a6-31c938225c05@github.com>
Message-ID: <5HU851arTKEDkTgufOlAENFU0uwptEVwiQ_4krW04sI=.b753c882-bf9c-4934-8687-42638d136237@github.com>

On Fri, 7 Nov 2025 16:57:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
>> 
>> The impacted areas are:
>> - saving to plain text
>> - copying to plain text
>> - IME
>> 
>> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), with convenience setter and getter in the `RichTextArea`.
>> 
>> ### NOTES
>> 
>> - some dependency on #1938 , resolved.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Merge branch 'master' into 8370140.line.separator
>  - rm property
>  - try
>  - Merge remote-tracking branch 'origin/master' into 8370140.line.separator
>  - review comments
>  - removed property
>  - review comments
>  - code area test
>  - Merge branch 'master' into 8370140.line.separator
>  - fixed tests
>  - ... and 9 more: https://git.openjdk.org/jfx/compare/bb660211...4eb15464

Marked as reviewed by jdv (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1944#pullrequestreview-3441042627

From mstrauss at openjdk.org  Mon Nov 10 08:04:00 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 10 Nov 2025 08:04:00 GMT
Subject: RFR: 8371106: [macOS] Min/max window height is incorrect for EXTENDED
 StageStyle
Message-ID: <dHgtZS6DyLrZYcHzmdln1cfe-iWvqEEAQjmuHx5oWgs=.ccb516e5-ffa7-4132-aa19-ef3b2183c9e5@github.com>

This patch fixes window size contraints for an `EXTENDED` stage. In contrast to the suggested workaround in the JBS ticket of querying the value of [`NSWindow.minSize`](https://developer.apple.com/documentation/appkit/nswindow/minsize?language=objc) to find out the added size for the toolbar, I've found it easier to set the [`NSWindow.contentMinSize`](https://developer.apple.com/documentation/appkit/nswindow/contentminsize?language=objc) property instead.

This is only done for `EXTENDED` stages, preserving the existing behavior for all other stage styles, and it works because extended stages use a full-size content view that covers the entire window. It also makes it unnecessary to take the toolbar height into consideration, which would be necessary if we used the `minSize` property instead.

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/jfx/pull/1967/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1967&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371106
  Stats: 18 lines in 2 files changed: 15 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1967.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1967/head:pull/1967

PR: https://git.openjdk.org/jfx/pull/1967

From jpereda at openjdk.org  Mon Nov 10 09:11:21 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 10 Nov 2025 09:11:21 GMT
Subject: Integrated: 8371302: [Windows] Stage coordinates in secondary display
 are not properly updated after changing settings of first display
In-Reply-To: <CR0CQX9O56oytMISf8D6Bdsnt9U0uPBr0NMsQPIv5Ls=.1be06b8c-8f09-44d9-ba74-39a7feee7db9@github.com>
References: <CR0CQX9O56oytMISf8D6Bdsnt9U0uPBr0NMsQPIv5Ls=.1be06b8c-8f09-44d9-ba74-39a7feee7db9@github.com>
Message-ID: <e5G2_AfuHFRb_WTlKi5hUkJhfpwesURXaW46DUkCL2A=.51f5a996-78f6-413e-90d7-719c2e15f1fd@github.com>

On Wed, 5 Nov 2025 11:44:40 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR handles two windows events, `WM_DISPLAYCHANGE` and `WM_SETTINGCHANGE`, that can be received by a JavaFX Window on a given display when other display changed its settings (resolution), or both displays were rearranged, and therefore its location has changed. 
> 
> When this happens, `com.sun.glass.ui.Window` has the new updated location, but the `javafx.stage.Window` does not, and triggering a `Window.MOVE` event notifies the stage to update its location accordingly.
> 
> There are no tests added to this PR (those would require two monitors, and external changes of Windows Settings), but the [test](https://bugs.openjdk.org/secure/attachment/116917/RenderScaleTest.java) attached to the JBS issue passes after this PR running some manual tests: for the stage at secondary display, check that the location is updated properly and the context menu shows up at the expected position, when the primary display resolution changes via Settings->System->Display->Scale, or when both displays are rearranged via Settings->System->Display->Drag to rearrange.

This pull request has now been integrated.

Changeset: d1660230
Author:    Jose Pereda <jpereda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/d1660230d21ce8a27db8dae9b0f1088b8e29faeb
Stats:     7 lines in 1 file changed: 7 ins; 0 del; 0 mod

8371302: [Windows] Stage coordinates in secondary display are not properly updated after changing settings of first display

Reviewed-by: angorya, kcr

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

PR: https://git.openjdk.org/jfx/pull/1963

From psadhukhan at openjdk.org  Mon Nov 10 10:41:53 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 10 Nov 2025 10:41:53 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition
 in HostContainer
Message-ID: <Ka7Fvj0XWnkMlHr_pVtRROpnj7Gd0rNrF0AEDq3CFiM=.8ab9d933-f26a-427b-90e7-f0d2d4e7a197@github.com>

NPE is seen while accessing transient "scenePeer" variable between reads..
Fix is made to store it in a temp variable rather than reading it twice since the value can change between successive reads in many places it is accessed.
Also some debug logs added to be enabled via `jfxpanel.debug` property

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

Commit messages:
 - 8255248: NullPointerException in JFXPanel due to race condition in HostContainer

Changes: https://git.openjdk.org/jfx/pull/1968/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1968&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8255248
  Stats: 208 lines in 3 files changed: 182 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/jfx/pull/1968.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1968/head:pull/1968

PR: https://git.openjdk.org/jfx/pull/1968

From sykora at openjdk.org  Mon Nov 10 10:54:18 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Mon, 10 Nov 2025 10:54:18 GMT
Subject: RFR: 8371052: Update libFFI to 3.5.2 [v2]
In-Reply-To: <6qUPKNTM1YxB1M4ArEvbgN45e_HqRzcDaqQ6NpUdlRg=.6d67057e-08c2-4f0b-be82-c8e7326cde26@github.com>
References: <EihmQlWsI1W2GLW_YDC8pOUhxQnzSfn4W5q1NvH2euM=.d769fa13-8113-43d1-8c37-1fcd849f653d@github.com>
 <6qUPKNTM1YxB1M4ArEvbgN45e_HqRzcDaqQ6NpUdlRg=.6d67057e-08c2-4f0b-be82-c8e7326cde26@github.com>
Message-ID: <S-VKXn9GApuzH0jftqNtf4A39Xc3ZBjhGPLi_6bY9-U=.88c85a58-c9c4-477e-9a75-a71b33773f6d@github.com>

On Fri, 7 Nov 2025 00:05:59 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Updated libFFI to 3.5.2.
>> - Tested on all platforms.
>> - No additional changes are done.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8371052: Update libFFI to 3.5.2 [v3]

All builds went fine here.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1962#pullrequestreview-3442436566

From john.hendrikx at gmail.com  Mon Nov 10 14:29:01 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 10 Nov 2025 15:29:01 +0100
Subject: Feedback requested: Proof of concept PR for extending WritableImage
 with its own "graphics context" to draw higher level primitives directly :)
Message-ID: <b78ffa97-ced8-4aff-94ec-8ede6ba8cb5c@gmail.com>

I've extended WritableImage with a new method `getDrawingContext`.

This method gives you a similar interface as Canvas's
`getGraphicsContext`, minus some methods that I didn't implement yet
(save/restore, font rendering, path rendering, line dashes).

The method signatures are compatible, and we could have Canvas's
GraphicsContext extend the DrawingContext interface.

Using it is trivial:

??? WritableImage img = new WritableImage(400, 400);
??? DrawingContext ctx = img.getDrawingContext();
??? ctx.setFill(Color.RED);
??? ctx.fillRect(50, 50, 100, 100);

Internally, this leverages the software renderer Pisces which is part of
JavaFX.? This means that FX can still be fully GPU accelerated, while
for drawing into a heap based WritableImage can be done with the CPU.? A
big advantage here is that this makes it possible to draw complex images
without having to snapshot them later if you need them to be images or
having to resort to drawing all primitives yourself with just a PixelWriter.

See this PR https://github.com/openjdk/jfx/pull/1969

A screenshot and demo program is included.

Feedback on the implementation is much appreciated.

--John


From kcr at openjdk.org  Mon Nov 10 16:22:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 10 Nov 2025 16:22:50 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v13]
In-Reply-To: <LMPFI2YIdsctg7KCsj39455YwQndiYFgdJUOo0s9AzI=.5b6d2483-7a22-4324-8f91-21d4815a6a0c@github.com>
References: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
 <LMPFI2YIdsctg7KCsj39455YwQndiYFgdJUOo0s9AzI=.5b6d2483-7a22-4324-8f91-21d4815a6a0c@github.com>
Message-ID: <RYaC7nqDBXa4SrffvMNkG8WtuyzwYV5DIPCRzXt1pYg=.05ac92cd-5450-478f-85ae-ea3d89e246a8@github.com>

On Fri, 7 Nov 2025 16:47:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev 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 branch 'master' into 8366201.allow.undo
>  - review comments
>  - Merge branch 'master' into 8366201.allow.undo
>  - javadoc
>  - suggestion
>    
>    Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
>  - set text
>  - Merge branch 'master' into 8366201.allow.undo
>  - undo/redo javadoc in model only
>  - javadoc
>  - the
>  - ... and 12 more: https://git.openjdk.org/jfx/compare/bb660211...4f3cf21f

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1941#pullrequestreview-3444086821

From kcr at openjdk.org  Mon Nov 10 16:30:12 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 10 Nov 2025 16:30:12 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v15]
In-Reply-To: <VJwun5rVStCRmY4epAw1jWeCMyKrzc7X4HNyP88HUCM=.5d2d5b05-b51e-440f-95a6-31c938225c05@github.com>
References: <JdWnTNmV5B76au1fqDNqINM5SjVC_vetKkIDMRSHKQ4=.cf021748-c902-4ed8-8c5c-f9e729238886@github.com>
 <VJwun5rVStCRmY4epAw1jWeCMyKrzc7X4HNyP88HUCM=.5d2d5b05-b51e-440f-95a6-31c938225c05@github.com>
Message-ID: <lbMPHKtMnpPwuUdeO-ubkvQlR57vsBC9Vs1pl0Df5XU=.15ccd65d-8408-4b0e-b450-813205053f31@github.com>

On Fri, 7 Nov 2025 16:57:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
>> 
>> The impacted areas are:
>> - saving to plain text
>> - copying to plain text
>> - IME
>> 
>> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), with convenience setter and getter in the `RichTextArea`.
>> 
>> ### NOTES
>> 
>> - some dependency on #1938 , resolved.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Merge branch 'master' into 8370140.line.separator
>  - rm property
>  - try
>  - Merge remote-tracking branch 'origin/master' into 8370140.line.separator
>  - review comments
>  - removed property
>  - review comments
>  - code area test
>  - Merge branch 'master' into 8370140.line.separator
>  - fixed tests
>  - ... and 9 more: https://git.openjdk.org/jfx/compare/bb660211...4eb15464

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1944#pullrequestreview-3444117723

From angorya at openjdk.org  Mon Nov 10 16:45:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Nov 2025 16:45:16 GMT
Subject: Integrated: 8366201: RichTextArea: remove allowUndo parameter
In-Reply-To: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
References: <EsMkgERccvVq6ySXtZ6ws-mrAt9dTXUb86uMN3s5eKk=.42cc138d-4e10-4a5e-9a71-f0905b719eaa@github.com>
Message-ID: <p429RS-gbs6VxadKGoXTxVGt8SGxZUXbuZ1oyfRv84c=.99da4799-5a54-47f3-930b-e623eea4983e@github.com>

On Mon, 20 Oct 2025 23:04:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
> 
> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
> 
> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
> 
> WARNING this is an incompatible change, permitted because of the incubator.
> 
> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .

This pull request has now been integrated.

Changeset: f8bef157
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/f8bef1575781ae8b38fba9dddd5aaa34e11e597d
Stats:     314 lines in 17 files changed: 238 ins; 7 del; 69 mod

8366201: RichTextArea: remove allowUndo parameter

Reviewed-by: kcr, jdv

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

PR: https://git.openjdk.org/jfx/pull/1941