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: References: Message-ID: On Wed, 11 Jun 2025 20:17:39 GMT, Kevin Rushforth 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: References: Message-ID: On Fri, 31 Oct 2025 00:48:44 GMT, Michael Strau? 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: References: Message-ID: On Sat, 1 Nov 2025 05:28:06 GMT, samypr100 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: 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: References: Message-ID: On Sat, 1 Nov 2025 15:47:00 GMT, Kevin Rushforth 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: References: Message-ID: <7_PC2mxzc0P2y0oCJBguoyUOS4ehwEgi8xZaFW97whA=.3a24b6ef-765d-4593-944c-8d98d688a549@github.com> On Sat, 1 Nov 2025 15:47:00 GMT, Kevin Rushforth 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#replaceRange(int from, int to, Collection col) [v2] In-Reply-To: References: Message-ID: <-O4F0UKPZVGp6TV18AKefLrXvIdtSHySgYF6tdA5_GY=.090ff031-c390-4718-a3d0-debbeeef05aa@github.com> On Mon, 20 Oct 2025 05:06:20 GMT, John Hendrikx 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: References: Message-ID: On Sat, 1 Nov 2025 15:47:00 GMT, Kevin Rushforth 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: References: Message-ID: On Sun, 2 Nov 2025 16:14:19 GMT, Anirvan Sarkar 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#replaceRange(int from, int to, Collection col) [v2] In-Reply-To: References: Message-ID: <-EPHSExUFbTWYUhpor36C9Ru_0uPnbf4EyB4zACAULE=.2fd3d9c3-ce41-4991-abc8-e0b9f322a80a@github.com> On Mon, 20 Oct 2025 05:06:20 GMT, John Hendrikx 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: 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: References: Message-ID: On Mon, 27 Oct 2025 14:44:44 GMT, John Hendrikx 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: References: Message-ID: 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 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 on behalf of Jurgen Doll > Date: Friday, October 31, 2025 at 01:40 > To: 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: 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: References: Message-ID: 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 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 on behalf of Jurgen Doll > Date: Friday, October 31, 2025 at 01:40 > To: 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: 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: References: Message-ID: 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 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#replaceRange(int from, int to, Collection col) [v2] In-Reply-To: References: Message-ID: <9Us1duA3t9S97bmzJ_nN03yikb4EnkPomX0yWY2orbQ=.c0f2331a-3531-4e21-b003-176fb3baacf9@github.com> On Mon, 20 Oct 2025 05:02:12 GMT, John Hendrikx 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: References: Message-ID: <4rzaU_8iDK34kOSpHtLK7VE43OrI8xbNKFgFBio8ow0=.5c8ebfef-1d00-43d4-a102-409433dcf7cb@github.com> On Thu, 30 Oct 2025 14:08:38 GMT, Lukasz Kostyra 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: <2FWS9tiiKQMpTOs88Czu4dXoe-27anWId3ppau-1Dog=.b0e85d3d-fd3c-4658-b64c-376d1a4ed77c@github.com> Message-ID: On Fri, 31 Oct 2025 11:03:39 GMT, Lukasz Kostyra 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: <4rzaU_8iDK34kOSpHtLK7VE43OrI8xbNKFgFBio8ow0=.5c8ebfef-1d00-43d4-a102-409433dcf7cb@github.com> Message-ID: On Mon, 3 Nov 2025 11:19:03 GMT, Ambarish Rapte 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: References: Message-ID: On Tue, 28 Oct 2025 11:23:53 GMT, Lukasz Kostyra 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: <5dqRJNL_jk1DrmWFn3XfCtTg9dt7aeb9QacOIigw4qI=.b96d2941-19c4-42f5-9a1b-acadcde5504e@github.com> Message-ID: On Thu, 30 Oct 2025 13:43:58 GMT, Lukasz Kostyra 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: References: Message-ID: On Fri, 31 Oct 2025 20:38:46 GMT, Andy Goryachev 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: References: Message-ID: On Thu, 30 Oct 2025 14:08:38 GMT, Lukasz Kostyra 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: References: Message-ID: On Mon, 3 Nov 2025 13:35:26 GMT, Alessadro Parisi 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: 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: References: Message-ID: On Mon, 3 Nov 2025 12:51:20 GMT, Ziad El Midaoui 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: References: Message-ID: On Wed, 29 Oct 2025 15:10:43 GMT, Ziad El Midaoui 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: References: Message-ID: <_hKvqhVMg0aeny0-BimmE-lzLW9xxP2kXU5m48sfWSI=.2409a873-49b4-4c12-8dee-5082f600f75e@github.com> On Sun, 2 Nov 2025 17:18:39 GMT, Marius Hanl 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: References: Message-ID: > 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: References: Message-ID: On Mon, 3 Nov 2025 16:31:46 GMT, Kevin Rushforth 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: References: Message-ID: On Mon, 3 Nov 2025 16:31:46 GMT, Kevin Rushforth 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: References: Message-ID: On Sun, 2 Nov 2025 19:40:04 GMT, Marius Hanl 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: References: Message-ID: On Mon, 3 Nov 2025 16:31:46 GMT, Kevin Rushforth 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: References: Message-ID: <7KxON7yscS4Xyy11e-Rav2NtY9npzTvNQM5aAab1w4g=.5137909c-dbc6-4ea2-aa1b-f47ca4f3db21@github.com> On Wed, 29 Oct 2025 15:10:43 GMT, Ziad El Midaoui 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: References: Message-ID: On Wed, 29 Oct 2025 15:10:43 GMT, Ziad El Midaoui 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: References: Message-ID: On Mon, 3 Nov 2025 17:19:17 GMT, Kevin Rushforth 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: References: Message-ID: On Mon, 3 Nov 2025 17:50:36 GMT, Kevin Rushforth 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: References: Message-ID: On Mon, 3 Nov 2025 18:08:21 GMT, Andy Goryachev 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: References: Message-ID: 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 Date: Monday, November 3, 2025 at 01:53 To: Andy Goryachev Cc: openjfx-dev 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 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: 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: References: Message-ID: On Wed, 29 Oct 2025 15:10:43 GMT, Ziad El Midaoui 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: References: Message-ID: 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 Date: Monday, November 3, 2025 at 00:36 To: Andy Goryachev 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: 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 Screenshot 2025-11-03 at 11 50 50 ------------- 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: References: Message-ID: On Mon, 3 Nov 2025 18:43:14 GMT, Andy Goryachev 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: References: Message-ID: On Wed, 29 Oct 2025 15:10:43 GMT, Ziad El Midaoui 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: References: Message-ID: On Sun, 2 Nov 2025 19:40:04 GMT, Marius Hanl 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: References: Message-ID: On Mon, 3 Nov 2025 17:51:12 GMT, Marius Hanl 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: References: <4rzaU_8iDK34kOSpHtLK7VE43OrI8xbNKFgFBio8ow0=.5c8ebfef-1d00-43d4-a102-409433dcf7cb@github.com> Message-ID: On Mon, 3 Nov 2025 11:21:53 GMT, Nir Lisker 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: References: <2FWS9tiiKQMpTOs88Czu4dXoe-27anWId3ppau-1Dog=.b0e85d3d-fd3c-4658-b64c-376d1a4ed77c@github.com> Message-ID: <_bn4DJQpYGPustVKn-XZyqCfkNmdgHqq4D7F7qJ6Bl4=.f70e6b5e-a33b-4137-a573-c91517d67fe6@github.com> On Mon, 3 Nov 2025 11:19:05 GMT, Ambarish Rapte 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: References: Message-ID: Indeed! Filed https://bugs.openjdk.org/browse/JDK-8371183 Thanks, -andy From: Jurgen Doll Date: Sunday, November 2, 2025 at 23:18 To: Andy Goryachev 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 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: 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: References: Message-ID: > 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: References: Message-ID: <9nraDSz6JYhfkxxXnbH5JN-DS0bkIFIxKh3DU3w6aBk=.63d065b2-c852-4efe-b058-5506bb069b8f@github.com> On Fri, 31 Oct 2025 14:31:47 GMT, Marius Hanl 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: References: Message-ID: On Mon, 3 Nov 2025 13:35:26 GMT, Alessadro Parisi 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: References: <4rzaU_8iDK34kOSpHtLK7VE43OrI8xbNKFgFBio8ow0=.5c8ebfef-1d00-43d4-a102-409433dcf7cb@github.com> Message-ID: On Mon, 3 Nov 2025 23:57:50 GMT, Kevin Rushforth 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: References: 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: 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: References: Message-ID: 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 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 > Date: Monday, November 3, 2025 at 00:36 > To: Andy Goryachev > 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: References: Message-ID: On Mon, 3 Nov 2025 16:31:46 GMT, Kevin Rushforth 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: References: Message-ID: On Mon, 3 Nov 2025 16:31:46 GMT, Kevin Rushforth 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: References: Message-ID: On Tue, 4 Nov 2025 01:19:54 GMT, Ambarish Rapte 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: References: Message-ID: On Fri, 31 Oct 2025 18:48:57 GMT, Andy Goryachev 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: 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: References: Message-ID: 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 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 > Date: Monday, November 3, 2025 at 01:53 > To: Andy Goryachev > Cc: openjfx-dev > 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 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: References: Message-ID: On Sun, 2 Nov 2025 19:40:04 GMT, Marius Hanl 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: References: Message-ID: On Tue, 4 Nov 2025 01:19:54 GMT, Ambarish Rapte 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: References: Message-ID: On Tue, 4 Nov 2025 01:19:54 GMT, Ambarish Rapte 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: References: Message-ID: On Tue, 4 Nov 2025 12:01:26 GMT, Ambarish Rapte 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: References: Message-ID: On Tue, 4 Nov 2025 12:01:26 GMT, Ambarish Rapte 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: References: Message-ID: <9ERMdiqQUFT-ByLrAutot8OfS1DOFQ6rre8LJl8rXJo=.253000e1-83b8-435d-9815-4f76d23df7a4@github.com> On Tue, 4 Nov 2025 12:01:26 GMT, Ambarish Rapte 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: References: Message-ID: On Tue, 4 Nov 2025 12:01:26 GMT, Ambarish Rapte 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 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: 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: <2dRJ3IhppfvY0ZhqCqtM_qjSqQD-lKh-TG3w_ZqtEFw=.3c040e21-0e1c-48d8-8129-f5a70a6eb2d6@github.com> Message-ID: On Tue, 4 Nov 2025 08:04:51 GMT, Lukasz Kostyra 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: References: Message-ID: On Tue, 4 Nov 2025 14:25:52 GMT, Ambarish Rapte 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: References: Message-ID: On Sat, 1 Nov 2025 15:47:00 GMT, Kevin Rushforth 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 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: References: <2dRJ3IhppfvY0ZhqCqtM_qjSqQD-lKh-TG3w_ZqtEFw=.3c040e21-0e1c-48d8-8129-f5a70a6eb2d6@github.com> Message-ID: On Tue, 4 Nov 2025 14:27:30 GMT, Kevin Rushforth 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: References: Message-ID: > 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: References: Message-ID: On Tue, 4 Nov 2025 14:25:52 GMT, Ambarish Rapte 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 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: 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: 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: References: Message-ID: <1JVE6qTzI01I7PdvFjacJI_bWWg-9r9QnqZjcBQshLE=.13377ec7-53a1-45fc-b557-7f1915be0665@github.com> On Tue, 4 Nov 2025 09:06:41 GMT, Prasanta Sadhukhan 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: References: Message-ID: On Tue, 4 Nov 2025 16:11:14 GMT, Ambarish Rapte 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 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: References: Message-ID: On Tue, 4 Nov 2025 16:48:02 GMT, Ambarish Rapte 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 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: References: Message-ID: > 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: References: Message-ID: On Tue, 4 Nov 2025 14:49:56 GMT, Lukasz Kostyra 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: <1JVE6qTzI01I7PdvFjacJI_bWWg-9r9QnqZjcBQshLE=.13377ec7-53a1-45fc-b557-7f1915be0665@github.com> Message-ID: On Tue, 4 Nov 2025 16:50:10 GMT, Kevin Rushforth 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: References: Message-ID: <29S5jGKQGQGJtATwisrTYkx-JooRLsoDVhbphKpNGiI=.c46c9d80-c970-440e-bf17-d2fb528d194c@github.com> On Tue, 4 Nov 2025 17:13:25 GMT, Prasanta Sadhukhan 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: References: Message-ID: On Tue, 4 Nov 2025 17:13:25 GMT, Prasanta Sadhukhan 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: This is a test only fix. When using `-PTEST_SDK_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=` ------------- 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: References: Message-ID: On Tue, 4 Nov 2025 17:23:40 GMT, Andy Goryachev 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: References: Message-ID: <8tIzBYY8xC50iujDytfb2utmLHJU9LfFTO7N0Hyjzjw=.497d14bd-c226-4911-a1eb-4b872e079112@github.com> On Tue, 4 Nov 2025 17:28:44 GMT, Andy Goryachev 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: References: Message-ID: On Tue, 4 Nov 2025 17:21:30 GMT, Ambarish Rapte wrote: > This is a test only fix. > When using `-PTEST_SDK_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=` 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: References: Message-ID: <-HCrVN631YvgAExFZ-Xx9Z0hPytCwDf_5BzC_aqQVkU=.d15bb034-3f55-43ce-9efd-05ef3b2b5a3b@github.com> On Tue, 4 Nov 2025 17:21:30 GMT, Ambarish Rapte wrote: > This is a test only fix. > When using `-PTEST_SDK_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=` This pull request has now been integrated. Changeset: cc07ab1a Author: Ambarish Rapte 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: <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 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: References: Message-ID: On Thu, 30 Oct 2025 08:11:34 GMT, Marius Hanl 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: References: Message-ID: On Thu, 30 Oct 2025 08:11:34 GMT, Marius Hanl 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: References: Message-ID: On Thu, 30 Oct 2025 08:11:34 GMT, Marius Hanl 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: References: Message-ID: <8aRtVmY4T7o9AFVk_a2qW46Zg22ZADOgdgoOOeembO0=.1b1c18ac-c214-44f9-bf9e-fc5065ae8fa4@github.com> On Tue, 4 Nov 2025 14:49:56 GMT, Lukasz Kostyra 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: References: Message-ID: On Thu, 30 Oct 2025 08:11:34 GMT, Marius Hanl 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: References: Message-ID: On Fri, 31 Oct 2025 18:48:57 GMT, Andy Goryachev 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 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: References: Message-ID: > 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: References: Message-ID: On Tue, 4 Nov 2025 19:06:21 GMT, Kevin Rushforth 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: References: Message-ID: On Tue, 4 Nov 2025 21:06:59 GMT, Andy Goryachev 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: References: Message-ID: On Tue, 4 Nov 2025 21:06:59 GMT, Andy Goryachev 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: References: Message-ID: On Tue, 4 Nov 2025 21:06:13 GMT, Kevin Rushforth 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: References: Message-ID: On Tue, 4 Nov 2025 18:38:12 GMT, Kevin Rushforth 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#replaceRange(int from, int to, Collection col) [v2] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 05:06:20 GMT, John Hendrikx 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#replaceRange(int from, int to, Collection col) [v2] In-Reply-To: <-O4F0UKPZVGp6TV18AKefLrXvIdtSHySgYF6tdA5_GY=.090ff031-c390-4718-a3d0-debbeeef05aa@github.com> References: <-O4F0UKPZVGp6TV18AKefLrXvIdtSHySgYF6tdA5_GY=.090ff031-c390-4718-a3d0-debbeeef05aa@github.com> Message-ID: On Sun, 2 Nov 2025 00:49:29 GMT, John Hendrikx 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: 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: References: Message-ID: On Thu, 30 Oct 2025 07:39:11 GMT, iso53 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: References: Message-ID: On Sat, 1 Nov 2025 14:43:15 GMT, Kevin Rushforth 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: References: Message-ID: <8N1KWVTTzmssRyWA3NhL1fwVZk07liuYuJnF3DXkPOQ=.b459b3c1-a382-4f05-9b26-3f26af5e46d0@github.com> On Sat, 1 Nov 2025 14:46:25 GMT, iso53 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: References: Message-ID: <3EZq1E5DULZW7Y24jeJ6tllzF0GrZLjKE1xY0UpdyHA=.6357ec1b-42c1-4020-8e06-6d61acc05143@github.com> On Tue, 4 Nov 2025 21:50:29 GMT, Andy Goryachev 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: References: Message-ID: On Tue, 4 Nov 2025 19:09:54 GMT, Kevin Rushforth 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: References: Message-ID: On Thu, 30 Oct 2025 07:39:11 GMT, iso53 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: References: Message-ID: On Tue, 4 Nov 2025 20:40:36 GMT, Kevin Rushforth 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 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: References: Message-ID: > 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: - 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: <8tIzBYY8xC50iujDytfb2utmLHJU9LfFTO7N0Hyjzjw=.497d14bd-c226-4911-a1eb-4b872e079112@github.com> <7dJzoMhEzKCafPO065FLCT63aH_qpMHoJ2beIlTbOYY=.0a23a74f-3f2e-40fa-af33-a923f28fc9a0@github.com> Message-ID: On Tue, 4 Nov 2025 17:58:09 GMT, Kevin Rushforth 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 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: References: Message-ID: <3H-3pVhWvOSOsTGUyLdMX4C-lohiV2mE9Oi0DfrjtW0=.f69abbfa-6e4c-4965-a9fd-48fee82b7332@github.com> On Wed, 29 Oct 2025 13:57:39 GMT, Ambarish Rapte 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 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: References: Message-ID: On Mon, 14 Jul 2025 17:39:50 GMT, Martin Fox 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: References: Message-ID: On Tue, 4 Nov 2025 14:49:56 GMT, Lukasz Kostyra 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 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: References: Message-ID: On Thu, 30 Oct 2025 07:39:11 GMT, iso53 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: References: Message-ID: On Tue, 4 Nov 2025 12:31:10 GMT, Nir Lisker 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: References: <5c8fc9fa-cf5d-455a-8335-022f80ce64d7@oracle.com> Message-ID: This is being implemented in https://github.com/openjdk/jfx/pull/1958. On Sun, Nov 19, 2023 at 4:42?AM Nir Lisker 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: 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: References: Message-ID: <9kJMzK4X4DJVDBf8B8IAgJUFITcqTTUT0oZfMo7Ga8g=.093d90ef-eb68-4da3-b61a-a5e1e3a09819@github.com> On Wed, 5 Nov 2025 09:28:27 GMT, Marius Hanl 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: References: <5c8fc9fa-cf5d-455a-8335-022f80ce64d7@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: 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: References: <5c8fc9fa-cf5d-455a-8335-022f80ce64d7@oracle.com> Message-ID: 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 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" > *An: *"Kevin Rushforth" > *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 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: 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: References: 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 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 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: <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 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:
createGraphics() exception 
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)
assertLocked() exception 
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)
------------- 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: References: Message-ID: On Wed, 5 Nov 2025 09:15:22 GMT, iso53 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: References: Message-ID: On Wed, 5 Nov 2025 02:17:39 GMT, Alexander Matveev 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: 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: References: Message-ID: > 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: 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: References: Message-ID: On Wed, 5 Nov 2025 09:15:22 GMT, iso53 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: References: <8tIzBYY8xC50iujDytfb2utmLHJU9LfFTO7N0Hyjzjw=.497d14bd-c226-4911-a1eb-4b872e079112@github.com> <7dJzoMhEzKCafPO065FLCT63aH_qpMHoJ2beIlTbOYY=.0a23a74f-3f2e-40fa-af33-a923f28fc9a0@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 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 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: References: Message-ID: <9bQSY0pn8mHzft7Qic_dFhOdjLjuhUWVoz7NhiZzmK8=.93c69282-3eae-4554-81d2-e73c466e2718@github.com> On Tue, 4 Nov 2025 09:06:41 GMT, Prasanta Sadhukhan 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 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: References: Message-ID: On Wed, 5 Nov 2025 12:17:07 GMT, iso53 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: References: Message-ID: On Wed, 5 Nov 2025 12:32:09 GMT, Jose Pereda 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 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: References: Message-ID: On Wed, 5 Nov 2025 12:17:07 GMT, iso53 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: References: Message-ID: On Wed, 5 Nov 2025 12:32:09 GMT, Jose Pereda 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: References: Message-ID: On Wed, 5 Nov 2025 11:44:40 GMT, Jose Pereda 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: References: Message-ID: On Wed, 5 Nov 2025 12:17:07 GMT, iso53 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: References: Message-ID: On Thu, 30 Oct 2025 07:39:11 GMT, iso53 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 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: <8tIzBYY8xC50iujDytfb2utmLHJU9LfFTO7N0Hyjzjw=.497d14bd-c226-4911-a1eb-4b872e079112@github.com> <7dJzoMhEzKCafPO065FLCT63aH_qpMHoJ2beIlTbOYY=.0a23a74f-3f2e-40fa-af33-a923f28fc9a0@github.com> <4WfTwEoQWC5Nc6Bs6w-ghx_si8OoiuPyNzwptrbm6GM=.4833f3ed-eb79-427a-8024-63b302d6980f@github.com> Message-ID: On Wed, 5 Nov 2025 12:46:23 GMT, Kevin Rushforth wrote: >> I don't quite understand..In >> >> >> private final EventHandler 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: References: Message-ID: On Tue, 4 Nov 2025 14:49:56 GMT, Lukasz Kostyra 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: References: <8tIzBYY8xC50iujDytfb2utmLHJU9LfFTO7N0Hyjzjw=.497d14bd-c226-4911-a1eb-4b872e079112@github.com> <7dJzoMhEzKCafPO065FLCT63aH_qpMHoJ2beIlTbOYY=.0a23a74f-3f2e-40fa-af33-a923f28fc9a0@github.com> <4WfTwEoQWC5Nc6Bs6w-ghx_si8OoiuPyNzwptrbm6GM=.4833f3ed-eb79-427a-8024-63b302d6980f@github.com> Message-ID: On Wed, 5 Nov 2025 15:25:23 GMT, Andy Goryachev 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#replaceRange(int from, int to, Collection col) [v3] In-Reply-To: References: 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#replaceRange(int from, int to, Collection col) [v2] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 21:56:19 GMT, Kevin Rushforth 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#replaceRange(int from, int to, Collection col) [v3] In-Reply-To: <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com> References: <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com> Message-ID: On Wed, 5 Nov 2025 16:19:36 GMT, John Hendrikx 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#replaceRange(int from, int to, Collection col) [v2] In-Reply-To: References: 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 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: References: Message-ID: > 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: References: 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#replaceRange(int from, int to, Collection col) [v3] In-Reply-To: <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com> References: <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com> Message-ID: On Wed, 5 Nov 2025 16:19:36 GMT, John Hendrikx 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: <_j3maM1FbJ0lif6lbh14jEH5Zmd2jxHFdhPufhvhFYY=.acb4af78-5554-4a5f-90f6-877d11b3672c@github.com> Message-ID: On Wed, 5 Nov 2025 18:14:51 GMT, Andy Goryachev 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: References: Message-ID: On Wed, 5 Nov 2025 00:07:14 GMT, Andy Goryachev 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 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: References: Message-ID: On Tue, 4 Nov 2025 21:50:38 GMT, Marius Hanl 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: References: Message-ID: On Wed, 5 Nov 2025 18:38:01 GMT, Kevin Rushforth 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: References: Message-ID: <6EC_fe28eiJ4GZWWtnMyGukuitJdUi2ylm7lW6w8P2c=.076451e8-16c3-425d-b3dc-c60e6b985eff@github.com> On Wed, 5 Nov 2025 20:08:01 GMT, Kevin Rushforth 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: References: Message-ID: > 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: References: Message-ID: > 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: <6EC_fe28eiJ4GZWWtnMyGukuitJdUi2ylm7lW6w8P2c=.076451e8-16c3-425d-b3dc-c60e6b985eff@github.com> Message-ID: On Wed, 5 Nov 2025 20:20:27 GMT, Andy Goryachev 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: References: Message-ID: On Sun, 15 Jun 2025 14:23:27 GMT, Marius Hanl 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 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#replaceRange(int from, int to, Collection col) [v3] In-Reply-To: <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com> References: <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com> Message-ID: On Wed, 5 Nov 2025 16:19:36 GMT, John Hendrikx 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 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#replaceRange(int from, int to, Collection col) [v3] In-Reply-To: References: <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com> Message-ID: On Wed, 5 Nov 2025 23:40:26 GMT, Michael Strau? 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 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#replaceRange(int from, int to, Collection col) [v3] In-Reply-To: <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com> References: <09Cz6FexZIKXJh6lt1EadyBYtc97KLbJVVr-I9jrHGs=.eb7687d1-65ce-4919-9106-009682252f4a@github.com> Message-ID: On Wed, 5 Nov 2025 16:19:36 GMT, John Hendrikx 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#replaceRange(int from, int to, Collection col) [v4] In-Reply-To: References: Message-ID: > 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#replaceRange(int from, int to, Collection col) [v4] In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 03:24:40 GMT, John Hendrikx 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: 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: 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: References: Message-ID: On Thu, 6 Nov 2025 08:24:48 GMT, Johan Vos 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: References: Message-ID: On Thu, 6 Nov 2025 08:24:48 GMT, Johan Vos 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: 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: References: Message-ID: <00cNN50xAFN9VRX1s_anecwbSrPZsN881Zg3P5WJlYo=.d7b82a3d-47e3-4b49-88d3-88f078053b35@github.com> On Thu, 6 Nov 2025 08:33:45 GMT, Johan Vos 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: References: Message-ID: On Thu, 6 Nov 2025 08:24:48 GMT, Johan Vos wrote: > Bump release version to 17.0.18 This pull request has now been integrated. Changeset: 4cc49e64 Author: Johan Vos 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: References: Message-ID: On Thu, 6 Nov 2025 08:33:45 GMT, Johan Vos 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: References: Message-ID: <1Lp5PqlwDrgt6gudVkM7PQGOzTYuxicP1zsmLjN4hLk=.de1ed024-3dbd-4cb9-9ad6-6be93cb1f345@github.com> On Thu, 6 Nov 2025 08:33:45 GMT, Johan Vos wrote: > Bump version to 21.0.10 This pull request has now been integrated. Changeset: 30c1e547 Author: Johan Vos 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: References: Message-ID: On Sat, 4 Oct 2025 15:19:32 GMT, Thiago Milczarek Sayao 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: References: Message-ID: > 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: References: 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: References: Message-ID: On Wed, 15 Oct 2025 20:42:36 GMT, Kevin Rushforth 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: References: Message-ID: On Wed, 5 Nov 2025 02:17:39 GMT, Alexander Matveev 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: References: Message-ID: On Fri, 31 Oct 2025 20:38:46 GMT, Andy Goryachev 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: <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 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 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: >
> createGraphics() exception > 
> 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: 
References: 
Message-ID: 

> 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#replaceRange(int from, int to,
 Collection col) [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 6 Nov 2025 03:24:40 GMT, John Hendrikx  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: 
References: 
 
Message-ID: 

On Tue, 4 Nov 2025 21:06:59 GMT, Andy Goryachev  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:      * 

> 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: 
References: 
 
 
Message-ID: <3bcATw2N08fxaco0X8hbTAsjt0nHwIJkpeyMGHnPYXs=.e613550b-0eaa-48f6-8ed9-86ae631a4275@github.com>

On Sun, 2 Nov 2025 20:03:48 GMT, Marius Hanl  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: 
References: 
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 
 - 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: 
References: 
 
 
Message-ID: 

On Thu, 6 Nov 2025 13:23:01 GMT, Jayathirth D V  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: 
References: 
 
 
Message-ID: 

On Mon, 3 Nov 2025 12:51:20 GMT, Ziad El Midaoui  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: 
References: 
 
 <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>
 
 
Message-ID: 

On Tue, 28 Oct 2025 15:40:33 GMT, Andy Goryachev  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  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
> 
> Screenshot 2025-11-03 at 11 50 50

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: 

On Mon, 3 Nov 2025 19:49:37 GMT, Andy Goryachev  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
> 
> Screenshot 2025-11-03 at 11 50 50

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: 

On Mon, 3 Nov 2025 19:49:37 GMT, Andy Goryachev  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
> 
> Screenshot 2025-11-03 at 11 50 50

This pull request has now been integrated.

Changeset: 5684edf7
Author:    Andy Goryachev 
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: 
References: 
Message-ID: 

On Wed, 5 Nov 2025 12:32:09 GMT, Jose Pereda  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: 
References: 
Message-ID: 

On Wed, 5 Nov 2025 11:44:40 GMT, Jose Pereda  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: 
References: 
 
Message-ID: 

On Thu, 6 Nov 2025 17:04:52 GMT, Andy Goryachev  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: 
References: 
 
Message-ID: 

On Wed, 5 Nov 2025 13:52:00 GMT, Marius Hanl  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 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: 
References: 
 
 
Message-ID: <12LNXOnh47WzhGRzoKkADBMR2SPfA1L1Ij26XVYee2A=.0579c029-b187-4046-9459-b96b657a979d@github.com>

On Thu, 6 Nov 2025 18:58:15 GMT, Jose Pereda  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: 
 
 
 <12LNXOnh47WzhGRzoKkADBMR2SPfA1L1Ij26XVYee2A=.0579c029-b187-4046-9459-b96b657a979d@github.com>
Message-ID: 

On Thu, 6 Nov 2025 19:08:24 GMT, Andy Goryachev  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: 
References: 
 
 
Message-ID: 

On Thu, 6 Nov 2025 18:57:52 GMT, Jose Pereda  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 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: 
References: 
Message-ID: 

On Wed, 5 Nov 2025 11:44:40 GMT, Jose Pereda  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: 
 <-5RQhssjbuZbj2zWEB4TYXgNOUVModpvsFaJVVfVl1I=.2356192e-77d3-4949-beeb-9b643a05a0f7@github.com>
Message-ID: 

On Thu, 6 Nov 2025 15:41:09 GMT, Andy Goryachev  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 
>  - 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: 
References: 
Message-ID: 

On Wed, 5 Nov 2025 12:32:09 GMT, Jose Pereda  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: 
References: 
 
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  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: 
References: 
Message-ID: 

> 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: 
 
 <3ZJY-Ajf-YDXZiECDqbIP-o-dS4la2NMxGn2yBTSMHk=.c7974ad1-b184-4212-91fd-7c4f161d5b83@github.com>
Message-ID: 

On Thu, 6 Nov 2025 19:53:28 GMT, Kevin Rushforth  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: 
References: 
Message-ID: 

On Thu, 6 Nov 2025 03:57:51 GMT, Prasanta Sadhukhan  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 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: 
References: 
 
Message-ID: <4sjrnoyMWa59gFn1RXC5WvOJVbtY1yxT-t5XxkNLbZs=.fa5991f5-c0e2-4400-a5bf-a144d17e88a7@github.com>

On Thu, 6 Nov 2025 20:06:42 GMT, Andy Goryachev  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: 
References: 
Message-ID: 

> 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: 
References: 
Message-ID: 

> 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: 
References: 
Message-ID: 

> 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: 
References: 
 
Message-ID: 

On Thu, 6 Nov 2025 21:40:51 GMT, Jose Pereda  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: 
References: 
Message-ID: <5sXPGu6bxhNungOz4JWdbTs6eBYkbatbjmwhhrGTMD8=.eadee223-6f64-49e0-865e-27b39d2687fa@github.com>

On Wed, 5 Nov 2025 12:32:09 GMT, Jose Pereda  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: 
References: 
 
Message-ID: 

On Thu, 6 Nov 2025 21:43:32 GMT, Jose Pereda  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: 
References: 
Message-ID: 

On Thu, 6 Nov 2025 03:57:51 GMT, Prasanta Sadhukhan  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: 
References: 
 
Message-ID: <5xkNK1cg0z0VXHC-TBP2bnnmNuijQ1a41S5EHtubHN4=.624d4617-3616-4c38-9b78-18eff1099200@github.com>

On Thu, 6 Nov 2025 21:29:54 GMT, Andy Goryachev  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: 
References: 
 
Message-ID: 

On Thu, 6 Nov 2025 10:52:40 GMT, Ambarish Rapte  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: 
References: 
 
Message-ID: <2S4V0uJ3wUvLsBgQ_mjwftAhIRjU1pXmS5SipiAAHRA=.040230cf-fc2b-465a-8154-041c00fc9894@github.com>

On Fri, 31 Oct 2025 00:07:46 GMT, Michael Strau?  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:      * 

> 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: 
References: 
 
Message-ID: <0m3o8lMpleyeH9nyCa2RaS01SB-TiNfrNg_nNMfB0DY=.6732b36d-912e-439d-9fe9-48a94ef7aa38@github.com>

On Thu, 6 Nov 2025 11:23:13 GMT, Ambarish Rapte  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: 
References: 
 
Message-ID: 

On Fri, 31 Oct 2025 00:07:46 GMT, Michael Strau?  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!

Screenshot 2025-11-06 at 15 56 35

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

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: 
References: 
Message-ID: 

On Wed, 5 Nov 2025 11:44:40 GMT, Jose Pereda  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: 
References: 
 
Message-ID: <0pP__xBvacVZkSXUgeuxXv_Sk-1mr1V2LO1R2AFoimc=.2c53d237-3c03-4ac5-b443-c4ebe5ce67c7@github.com>

On Fri, 31 Oct 2025 00:07:46 GMT, Michael Strau?  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: 
References: 
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: 
References: 
Message-ID: 

On Wed, 5 Nov 2025 02:17:39 GMT, Alexander Matveev  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: 
References: 
 
Message-ID: 

On Thu, 6 Nov 2025 21:43:32 GMT, Jose Pereda  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 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: 
References: 
 
 
Message-ID: 

On Thu, 6 Nov 2025 23:53:10 GMT, Kevin Rushforth  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 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: 
 
 <2S4V0uJ3wUvLsBgQ_mjwftAhIRjU1pXmS5SipiAAHRA=.040230cf-fc2b-465a-8154-041c00fc9894@github.com>
Message-ID: 

On Thu, 6 Nov 2025 23:34:13 GMT, Andy Goryachev  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: 
References: 
Message-ID: 

> 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: 
 
 <2S4V0uJ3wUvLsBgQ_mjwftAhIRjU1pXmS5SipiAAHRA=.040230cf-fc2b-465a-8154-041c00fc9894@github.com>
Message-ID: 

On Thu, 6 Nov 2025 20:54:00 GMT, Andy Goryachev  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:      * 

>> 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: 
References: 
Message-ID: 

> 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: 
References: 
Message-ID: <_a1B_qKtod-ATL3WNRSY71iHeuM_pJ5hBovFjRrPfic=.97c9454e-9489-42eb-89cd-242a32f2361c@github.com>

On Thu, 6 Nov 2025 03:57:51 GMT, Prasanta Sadhukhan  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: 
References: 
 
Message-ID: 

On Thu, 6 Nov 2025 20:41:49 GMT, Andy Goryachev  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 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: 
 <-5RQhssjbuZbj2zWEB4TYXgNOUVModpvsFaJVVfVl1I=.2356192e-77d3-4949-beeb-9b643a05a0f7@github.com>
Message-ID: 

On Thu, 6 Nov 2025 15:41:09 GMT, Andy Goryachev  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 
>  - 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#replaceRange(int from, int to,
 Collection col) [v5]
In-Reply-To: 
References: 
Message-ID: 

> 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: 
References: 
 
Message-ID: <82lauh3d7JrcVL9fXEJp3DMIGOKYTCt2cZkAz5iYVtw=.dfc63f4e-4cfc-482e-a616-7b66bb9adfe4@github.com>

On Thu, 6 Nov 2025 21:29:54 GMT, Andy Goryachev  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#replaceRange(int from, int to,
 Collection col) [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 Nov 2025 06:36:56 GMT, John Hendrikx  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: 
References: 
 
Message-ID: 

On Tue, 4 Nov 2025 14:49:56 GMT, Lukasz Kostyra  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 "" 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 "" 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: 
References: 
 
Message-ID: 

On Tue, 4 Nov 2025 14:49:56 GMT, Lukasz Kostyra  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 screens = Screen.getScreens();
    Set> 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: 
References: 
 
Message-ID: 

On Fri, 31 Oct 2025 20:38:46 GMT, Andy Goryachev  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#replaceRange(int from, int to,
 Collection col) [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 Nov 2025 06:36:56 GMT, John Hendrikx  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: 
References: 
 
Message-ID: 

On Fri, 7 Nov 2025 03:11:39 GMT, Prasanta Sadhukhan  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: 
References: 
Message-ID: 

On Mon, 27 Oct 2025 19:04:16 GMT, Andy Goryachev  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 
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: 
References: 
 
Message-ID: 

On Fri, 31 Oct 2025 20:38:46 GMT, Andy Goryachev  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: 
References: 
 
 
 
Message-ID: 

On Fri, 7 Nov 2025 00:32:31 GMT, Jose Pereda  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 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: 
References: 
 
 
 
 
Message-ID: 

On Fri, 7 Nov 2025 15:33:42 GMT, Andy Goryachev  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: 
References: 
 
Message-ID: <23Hlf_1RJl65Gs0MLI6flCYJFWugKjYy407Xv6JHHMY=.3ef56af4-72cd-4742-82fd-e6a6392046eb@github.com>

On Fri, 7 Nov 2025 03:11:39 GMT, Prasanta Sadhukhan  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: 
References: 
 
 
 
 
 
Message-ID: 

On Fri, 7 Nov 2025 15:42:27 GMT, Marius Hanl  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: 
References: 
Message-ID: 

> 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 
 - 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: 
 <-5RQhssjbuZbj2zWEB4TYXgNOUVModpvsFaJVVfVl1I=.2356192e-77d3-4949-beeb-9b643a05a0f7@github.com>
Message-ID: 

On Thu, 6 Nov 2025 15:41:09 GMT, Andy Goryachev  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 
>  - 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: 
References: 
 
Message-ID: 

On Fri, 7 Nov 2025 01:54:56 GMT, Michael Strau?  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: 
References: 
Message-ID: 

> 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: 
References: 
Message-ID: 

> 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
> 
> 
> 
> 
> ## 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: 
References: 
 
 
 
 
 
 
Message-ID: 

On Fri, 7 Nov 2025 16:01:45 GMT, Kevin Rushforth  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: 

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: 
References: 
 
Message-ID: 

On Thu, 6 Nov 2025 21:43:32 GMT, Jose Pereda  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: 
References: 
Message-ID: 

On Wed, 5 Nov 2025 11:44:40 GMT, Jose Pereda  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: 
References: 
Message-ID: 

On Fri, 7 Nov 2025 20:08:15 GMT, Andy Goryachev  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 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: 
References: 
 
Message-ID: 

On Fri, 7 Nov 2025 21:59:37 GMT, Kevin Rushforth  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 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: 

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: 

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: 
References: 
 
 
Message-ID: 

On Fri, 7 Nov 2025 21:48:27 GMT, Kevin Rushforth  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:

Screenshot 2025-11-08 143811

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: 

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

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: 
References: 
Message-ID: 

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 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: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug_cb.gif
Type: image/gif
Size: 85745 bytes
Desc: not available
URL: 

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: 
References: 
 
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 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: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug_cb.gif
Type: image/gif
Size: 85745 bytes
Desc: not available
URL: 

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: 
References: 
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 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: 

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#replaceRange(int from, int to, 
 Collection col)
In-Reply-To: 
References: 
Message-ID: 

On Wed, 15 Oct 2025 03:40:24 GMT, John Hendrikx  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 
URL:       https://git.openjdk.org/jfx/commit/b76090dfe6821efcbd86230e1b24ad7f455c7a41
Stats:     135 lines in 3 files changed: 134 ins; 1 del; 0 mod

8091429: ObservableList#replaceRange(int from, int to, Collection 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: 
 
 <552b3cb9-7316-490a-8bd3-86c037f536de@gmail.com>
Message-ID: 

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  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 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: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug_cb.gif
Type: image/gif
Size: 85745 bytes
Desc: not available
URL: 

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: 
 <41357b68-7658-430a-b464-dc73599db978@gmail.com>
Message-ID: 

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

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: 
References: 
Message-ID: 

On Thu, 6 Nov 2025 03:57:51 GMT, Prasanta Sadhukhan  wrote:

> There can be potential NPEs in SwingNode which is fixed

This pull request has now been integrated.

Changeset: 5e3a5e1a
Author:    Prasanta Sadhukhan 
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: 
References: 
 <41357b68-7658-430a-b464-dc73599db978@gmail.com>
 
Message-ID: 

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

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: 
References: 
 <41357b68-7658-430a-b464-dc73599db978@gmail.com>
 
 
Message-ID: 

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

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: 
References: 
 <41357b68-7658-430a-b464-dc73599db978@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 
> 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 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
>>      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 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: 

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: 
 <6qUPKNTM1YxB1M4ArEvbgN45e_HqRzcDaqQ6NpUdlRg=.6d67057e-08c2-4f0b-be82-c8e7326cde26@github.com>
Message-ID: 

On Fri, 7 Nov 2025 00:05:59 GMT, Alexander Matveev  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: 
References: 
 
Message-ID: 

On Fri, 7 Nov 2025 16:47:47 GMT, Andy Goryachev  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 
>  - 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: 
References: 
 
Message-ID: <5HU851arTKEDkTgufOlAENFU0uwptEVwiQ_4krW04sI=.b753c882-bf9c-4934-8687-42638d136237@github.com>

On Fri, 7 Nov 2025 16:57:55 GMT, Andy Goryachev  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: 

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: 
References: 
Message-ID: 

On Wed, 5 Nov 2025 11:44:40 GMT, Jose Pereda  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 
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: 

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: 
 <6qUPKNTM1YxB1M4ArEvbgN45e_HqRzcDaqQ6NpUdlRg=.6d67057e-08c2-4f0b-be82-c8e7326cde26@github.com>
Message-ID: 

On Fri, 7 Nov 2025 00:05:59 GMT, Alexander Matveev  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: 

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: 
References: 
 
Message-ID: 

On Fri, 7 Nov 2025 16:47:47 GMT, Andy Goryachev  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 
>  - 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: 
References: 
 
Message-ID: 

On Fri, 7 Nov 2025 16:57:55 GMT, Andy Goryachev  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: 
References: 
Message-ID: 

On Mon, 20 Oct 2025 23:04:17 GMT, Andy Goryachev  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 
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

From andy.goryachev at oracle.com  Mon Nov 10 17:32:21 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 10 Nov 2025 17:32:21 +0000
Subject: Feedback requested: Proof of concept PR for extending
 WritableImage with its own "graphics context" to draw higher level primitives
 directly :)
In-Reply-To: 
References: 
Message-ID: 

This is interesting, similar to BufferedImage.createGraphics() in AWT.

Questions:

  *   so this will aways be slower than Canvas?
  *
are the results going to be exactly the same, or there will be platform-specific differences in anti-aliasing etc?

Thanks!
-andy


From: openjfx-dev  on behalf of John Hendrikx 
Date: Monday, November 10, 2025 at 06:29
To: openjfx-dev at openjdk.org 
Subject: Feedback requested: Proof of concept PR for extending WritableImage with its own "graphics context" to draw higher level primitives directly :)

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Mon Nov 10 17:36:17 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Nov 2025 17:36:17 GMT
Subject: RFR: 8371183: RichTextModel: ContentChange.isEdit incorrect undoing
 style modification
Message-ID: 

Fixes an issue found by an external user:

Undoing a style only change fires a change event where `ContentChange.isEdit` is true when it should be false.

NOTE

- this PR depends on #1941 (resolved)

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

Commit messages:
 - Merge branch 'master' into 8371183.is.edit
 - Merge branch 'master' into 8371183.is.edit
 - javadoc
 - Merge remote-tracking branch 'origin/8366201.allow.undo' into 8371183.is.edit
 - javadoc
 - is edit
 - Merge remote-tracking branch 'origin/8366201.allow.undo' into 8371183.is.edit
 - suggestion
 - set text
 - Merge branch 'master' into 8366201.allow.undo
 - ... and 16 more: https://git.openjdk.org/jfx/compare/f8bef157...49c78747

Changes: https://git.openjdk.org/jfx/pull/1961/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1961&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371183
  Stats: 63 lines in 5 files changed: 46 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jfx/pull/1961.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1961/head:pull/1961

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

From angorya at openjdk.org  Mon Nov 10 17:47:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Nov 2025 17:47:58 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v16]
In-Reply-To: 
References: 
Message-ID: 

> 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 20 commits:

 - Merge branch 'master' into 8370140.line.separator
 - 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
 - ... and 10 more: https://git.openjdk.org/jfx/compare/f8bef157...8915ffa4

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

Changes: https://git.openjdk.org/jfx/pull/1944/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=15
  Stats: 287 lines in 13 files changed: 258 ins; 11 del; 18 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  Mon Nov 10 17:54:14 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Nov 2025 17:54:14 GMT
Subject: RFR: 8371070: RichParagraph enhancements [v2]
In-Reply-To: 
References: 
Message-ID: 

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

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 8371070.enhance
 - test
 - expose segments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1966/files
  - new: https://git.openjdk.org/jfx/pull/1966/files/27662d6b..62dd46a8

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

  Stats: 478 lines in 22 files changed: 387 ins; 16 del; 75 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  Mon Nov 10 18:19:40 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 10 Nov 2025 18:19:40 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v16]
In-Reply-To: 
References: 
 
Message-ID: <4sNqCsyyKjxmdK_dTsl9tVHN2_Lzi37pebmLqb0AQvQ=.b8a121c0-6f3c-4676-bf02-db5d1bd6ef16@github.com>

On Mon, 10 Nov 2025 17:47:58 GMT, Andy Goryachev  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 20 commits:
> 
>  - Merge branch 'master' into 8370140.line.separator
>  - 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
>  - ... and 10 more: https://git.openjdk.org/jfx/compare/f8bef157...8915ffa4

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1944#pullrequestreview-3444561279

From angorya at openjdk.org  Mon Nov 10 18:44:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Nov 2025 18:44:25 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Nov 2025 10:37:25 GMT, Prasanta Sadhukhan  wrote:

> 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

modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 215:

> 213: 
> 214:         debugPrint = "true".equalsIgnoreCase(debugStr);
> 215:     }

suggestion:

private static final boolean DEBUG = Boolean.getBoolean("jfxpanel.debug");

modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 217:

> 215:     }
> 216: 
> 217:     protected static void debug_println(String str) {

javadoc complains about this new public API.  Or is it a temporary debugging thing?  Can it be declared `private`?

If it is a permanent thing, it incurs a string concatenation overhead even when disabled.  Use lambdas instead?  Alternatively (and faster), one needs to check if debug printout is enabled on each use inline:


if(DEBUG) {
  debug_println("JFXPanel Thread " + Thread.currentThread().getName() + " isFXUserThread " + Toolkit.getToolkit().isFxUserThread());
}

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2511593814
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2511576430

From kcr at openjdk.org  Mon Nov 10 19:22:10 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 10 Nov 2025 19:22:10 GMT
Subject: RFR: 8371183: RichTextModel: ContentChange.isEdit incorrect
 undoing style modification
In-Reply-To: 
References: 
Message-ID: 

On Tue, 4 Nov 2025 20:32:43 GMT, Andy Goryachev  wrote:

> Fixes an issue found by an external user:
> 
> Undoing a style only change fires a change event where `ContentChange.isEdit` is true when it should be false.
> 
> NOTE
> 
> - this PR depends on #1941 (resolved)

I left a comment on the docs of a public API method that I think should be reverted.

I'll let someone else review and test the fix itself.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1105:

> 1103:      * 

> 1104:      * This convenience method is equivalent to calling
> 1105:      * {@code appendText(text, StyleAttributeMap.EMPTY, true);}

There is no such method, so this should be reverted. I don't see why this bug fix would even need a change to the public API docs.

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

PR Review: https://git.openjdk.org/jfx/pull/1961#pullrequestreview-3444741662
PR Review Comment: https://git.openjdk.org/jfx/pull/1961#discussion_r2511663845

From kcr at openjdk.org  Mon Nov 10 19:25:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 10 Nov 2025 19:25:57 GMT
Subject: RFR: 8371183: RichTextModel: ContentChange.isEdit incorrect
 undoing style modification
In-Reply-To: 
References: 
Message-ID: 

On Tue, 4 Nov 2025 20:32:43 GMT, Andy Goryachev  wrote:

> Fixes an issue found by an external user:
> 
> Undoing a style only change fires a change event where `ContentChange.isEdit` is true when it should be false.
> 
> NOTE
> 
> - this PR depends on #1941 (resolved)

@lukostyra Can you be the reviewer for this (and decide whether you think it needs a second reviewer)?

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

PR Comment: https://git.openjdk.org/jfx/pull/1961#issuecomment-3513525092

From john.hendrikx at gmail.com  Mon Nov 10 19:27:19 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 10 Nov 2025 20:27:19 +0100
Subject: Feedback requested: Proof of concept PR for extending
 WritableImage with its own "graphics context" to draw higher level primitives
 directly :)
In-Reply-To: 
References: 
 
Message-ID: <02b96a3b-3824-48d1-a122-911eddfdde73@gmail.com>


On 10/11/2025 18:32, Andy Goryachev wrote:
>
> This is interesting, similar to |BufferedImage.createGraphics()|?in AWT.
>
Yeah, I proposed this a few months ago as I noticed that FX basically
has everything needed; it just needs something to tie the pieces
together.? This is why the PR is really not that complicated, but just
translating from user API's to Prism API's for the most part.
>
> Questions:
>
>   * so this will aways?be slower than Canvas?
>
Not necessarily.

- If you frequently need to read pixels (with PixelReader) then
WritableImage can be faster, as you avoid the CPU->GPU->CPU memory copy
cycle that you'd get with snapshotting a Canvas. For example, image
scaling may be faster if you need the final resulting pixels again, as
scaling is a relatively simple operation but involves lots of data that
would otherwise need copying multiple times.

- If you primarily do operations on small sizes (say icons, or small
images), or only need infrequent changes

- WritableImage can also be used without any kind of Scene (it is not a
Node)

Where it will definitely be slower:

- Using a large working area (>= 500x500), and drawing over large areas;
at what point the GPU wins depends on what you're doing exactly

- Using gradients/effects over large areas heavily favors GPU's

- Simulating unsupported blend modes (some blend modes are really heavy,
requiring a division per color channel)

- Font rendering heavily favors GPU's I think as GPU's can cache glyphs
in vector form and render them directly at any size

>  *
>     are the results going to be exactly the same, or there will be
>     platform-specific differences in anti-aliasing etc?
>
There will be differences, but for supported features you'd have to know
what to look for to spot the differences.? The limitations are very
similar to the differences between FX's software and?accelerated
pipelines, as the same back-end renderer is used.?

For example, the offered blend modes are limited (only SRC_OVER and
ADD).? Even for supported features (like Image scaling) there can be
slight differences (but the same can be said of different GPU pipelines,
and even different GPU's).

--John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Mon Nov 10 19:49:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Nov 2025 19:49:19 GMT
Subject: RFR: 8371183: RichTextModel: ContentChange.isEdit incorrect
 undoing style modification [v2]
In-Reply-To: 
References: 
Message-ID: 

> Fixes an issue found by an external user:
> 
> Undoing a style only change fires a change event where `ContentChange.isEdit` is true when it should be false.
> 
> NOTE
> 
> - this PR depends on #1941 (resolved)

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

  bad merge

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1961/files
  - new: https://git.openjdk.org/jfx/pull/1961/files/49c78747..9162e0af

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

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

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

From angorya at openjdk.org  Mon Nov 10 19:49:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Nov 2025 19:49:21 GMT
Subject: RFR: 8371183: RichTextModel: ContentChange.isEdit incorrect
 undoing style modification [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 Nov 2025 19:09:32 GMT, Kevin Rushforth  wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   bad merge
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1105:
> 
>> 1103:      * 

>> 1104:      * This convenience method is equivalent to calling
>> 1105:      * {@code appendText(text, StyleAttributeMap.EMPTY, true);}
> 
> There is no such method, so this should be reverted. I don't see why this bug fix would even need a change to the public API docs.

good catch!  result of a bad merge.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1961#discussion_r2511759663

From angorya at openjdk.org  Mon Nov 10 20:10:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Nov 2025 20:10:55 GMT
Subject: RFR: 8371106: [macOS] Min/max window height is incorrect for
 EXTENDED StageStyle
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Nov 2025 07:58:17 GMT, Michael Strau?  wrote:

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

Testing looks good.

modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 1237:

> 1235:     {
> 1236:         GlassWindow *window = getGlassWindow(env, jPtr);
> 1237:         NSSize minSize = NSMakeSize(jW, jH);

Does this structure need to be freed at some point?

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

PR Review: https://git.openjdk.org/jfx/pull/1967#pullrequestreview-3444951852
PR Review Comment: https://git.openjdk.org/jfx/pull/1967#discussion_r2511819479

From mstrauss at openjdk.org  Mon Nov 10 20:21:02 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 10 Nov 2025 20:21:02 GMT
Subject: RFR: 8371106: [macOS] Min/max window height is incorrect for
 EXTENDED StageStyle
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 Nov 2025 20:04:14 GMT, Andy Goryachev  wrote:

>> 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.
>
> modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 1237:
> 
>> 1235:     {
>> 1236:         GlassWindow *window = getGlassWindow(env, jPtr);
>> 1237:         NSSize minSize = NSMakeSize(jW, jH);
> 
> Does this structure need to be freed at some point?

It's a value struct, no heap allocation going on. So it doesn't need to be freed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1967#discussion_r2511853962

From angorya at openjdk.org  Mon Nov 10 20:24:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Nov 2025 20:24:49 GMT
Subject: RFR: 8371106: [macOS] Min/max window height is incorrect for
 EXTENDED StageStyle
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Nov 2025 07:58:17 GMT, Michael Strau?  wrote:

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

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1967#pullrequestreview-3445006742

From kcr at openjdk.org  Mon Nov 10 20:45:34 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 10 Nov 2025 20:45:34 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Nov 2025 10:37:25 GMT, Prasanta Sadhukhan  wrote:

> 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

@prsadhuk Can you provide your evaluation as to why this is the right fix in light of the comments on the earlier PR #1178 and the discussion in JBS issue [JDK-8255248](https://bugs.openjdk.org/browse/JDK-8255248)?

Reviewers: @kevinrushforth @andy-goryachev-oracle 

Also, @mstr2 and @hjohn might want to weigh in since they had comments on #1178

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

PR Comment: https://git.openjdk.org/jfx/pull/1968#issuecomment-3513820947

From angorya at openjdk.org  Mon Nov 10 20:55:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Nov 2025 20:55:52 GMT
Subject: RFR: 8371070: RichParagraph enhancements [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 7 Nov 2025 22:25:26 GMT, Andy Goryachev  wrote:

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

In theory, `List getSegments()` can be added as a convenience method which returns an unmodifiable copy.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1966#discussion_r2511938569

From kcr at openjdk.org  Mon Nov 10 21:13:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 10 Nov 2025 21:13:18 GMT
Subject: RFR: 8371106: [macOS] Min/max window height is incorrect for
 EXTENDED StageStyle
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Nov 2025 07:58:17 GMT, Michael Strau?  wrote:

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

The fix looks good.

I confirm that it fixes the standalone test case attached to the bug and fixes the test failures I was seeing in the new `SizingTest` test added as part of PR #1789.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1967#pullrequestreview-3445165423

From kcr at openjdk.org  Mon Nov 10 21:29:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 10 Nov 2025 21:29:19 GMT
Subject: [jfx25u] Integrated: 8252373: [macOS] Stage with owner disappears when
 moved to another screen
In-Reply-To: 
References: 
Message-ID: 

On Fri, 7 Nov 2025 22:51:09 GMT, Kevin Rushforth  wrote:

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

This pull request has now been integrated.

Changeset: fef01eea
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx25u/commit/fef01eea5025d96dc986e053fa9c551ea467ac5a
Stats:     235 lines in 5 files changed: 207 ins; 9 del; 19 mod

8252373: [macOS] Stage with owner disappears when moved to another screen

Backport-of: 866f68d368594fc44241fdb61adbe522031de05e

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

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

From kcr at openjdk.org  Mon Nov 10 22:15:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 10 Nov 2025 22:15:27 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Sat, 8 Nov 2025 14:17:30 GMT, Jose Pereda  wrote:

>> 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:
> 
> Screenshot 2025-11-08 143811
> 
> 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?

Hmm. I see what you are saying, and can confirm the behavior. With your proposed fix, though, it seems like we will still have a situation where an in-use screen object is no longer in the list of screens. When this happens it will point to the same native screen object as one of the newly-created screens. This seems fragile.

Maybe we could still dispose all old screens, but do it in a way that allows it to later be mapped to a new screen? Or, thinking out loud, maybe "put back" the screens that didn't actually change as the result of the DPI change notification?

I'll want to think about this and take a closer look, but it will be a couple days before I can get to it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2512140208

From almatvee at openjdk.org  Mon Nov 10 22:58:20 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 10 Nov 2025 22:58:20 GMT
Subject: Integrated: 8371052: Update libFFI to 3.5.2
In-Reply-To: 
References: 
Message-ID: 

On Wed, 5 Nov 2025 02:17:39 GMT, Alexander Matveev  wrote:

> - Updated libFFI to 3.5.2.
> - Tested on all platforms.
> - No additional changes are done.

This pull request has now been integrated.

Changeset: 637cb63d
Author:    Alexander Matveev 
URL:       https://git.openjdk.org/jfx/commit/637cb63d9f3834699b99c408c6cee66a0ad4431f
Stats:     267 lines in 24 files changed: 184 ins; 12 del; 71 mod

8371052: Update libFFI to 3.5.2

Reviewed-by: arapte, sykora

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

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

From almatvee at openjdk.org  Mon Nov 10 23:20:33 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 10 Nov 2025 23:20:33 GMT
Subject: [jfx25u] RFR: 8371052: Update libFFI to 3.5.2
Message-ID: 

Clean backport of JDK-8371052.

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

Commit messages:
 - Backport 637cb63d9f3834699b99c408c6cee66a0ad4431f

Changes: https://git.openjdk.org/jfx25u/pull/36/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=36&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371052
  Stats: 267 lines in 24 files changed: 184 ins; 12 del; 71 mod
  Patch: https://git.openjdk.org/jfx25u/pull/36.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/36/head:pull/36

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

From almatvee at openjdk.org  Mon Nov 10 23:48:20 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 10 Nov 2025 23:48:20 GMT
Subject: [jfx25u] Integrated: 8371052: Update libFFI to 3.5.2
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Nov 2025 23:14:53 GMT, Alexander Matveev  wrote:

> Clean backport of JDK-8371052.

This pull request has now been integrated.

Changeset: 8d5232d8
Author:    Alexander Matveev 
URL:       https://git.openjdk.org/jfx25u/commit/8d5232d8373302cade6e4deb9182322883a08893
Stats:     267 lines in 24 files changed: 184 ins; 12 del; 71 mod

8371052: Update libFFI to 3.5.2

Backport-of: 637cb63d9f3834699b99c408c6cee66a0ad4431f

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

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

From psadhukhan at openjdk.org  Tue Nov 11 03:02:01 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Nov 2025 03:02:01 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v2]
In-Reply-To: 
References: 
Message-ID: <9ePaZacAc0aIGeKPS1FQEJU8U0BrxSYXmuLNY23TGLI=.40a67a67-e20e-4aa6-8441-236a0e222c77@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

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

  debug fix

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1968/files
  - new: https://git.openjdk.org/jfx/pull/1968/files/01403e03..4cae0411

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

  Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 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 psadhukhan at openjdk.org  Tue Nov 11 03:02:03 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Nov 2025 03:02:03 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 Nov 2025 18:41:43 GMT, Andy Goryachev  wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   debug fix
>
> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 215:
> 
>> 213: 
>> 214:         debugPrint = "true".equalsIgnoreCase(debugStr);
>> 215:     }
> 
> suggestion:
> 
> private static final boolean DEBUG = Boolean.getBoolean("jfxpanel.debug");

ok

> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 217:
> 
>> 215:     }
>> 216: 
>> 217:     protected static void debug_println(String str) {
> 
> javadoc complains about this new public API.  Or is it a temporary debugging thing?  Can it be declared `private`?
> 
> If it is a permanent thing, it incurs a string concatenation overhead even when disabled.  Use lambdas instead?  Alternatively (and faster), one needs to check if debug printout is enabled on each use inline:
> 
> 
> if(DEBUG) {
>   debug_println("JFXPanel Thread " + Thread.currentThread().getName() + " isFXUserThread " + Toolkit.getToolkit().isFxUserThread());
> }

I intend to keep it as permanent to enable logging of flow and thread context viewing.
Updated to keep the method private

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2512659364
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2512658847

From psadhukhan at openjdk.org  Tue Nov 11 03:07:18 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Nov 2025 03:07:18 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v2]
In-Reply-To: <9ePaZacAc0aIGeKPS1FQEJU8U0BrxSYXmuLNY23TGLI=.40a67a67-e20e-4aa6-8441-236a0e222c77@github.com>
References: 
 <9ePaZacAc0aIGeKPS1FQEJU8U0BrxSYXmuLNY23TGLI=.40a67a67-e20e-4aa6-8441-236a0e222c77@github.com>
Message-ID: 

On Tue, 11 Nov 2025 03:02:01 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   debug fix

I couldn't find anything adverse w.r.t thread usage using the added debug logs and I think it's standard and proven practice to store global (and in this case transient) variable into temp variable and use it to prevent 
inadvertent modification of the global variable and also avoid variable state change causing issue during context switching
especially in multi-threaded environments  
and it is consistent with the approach taken for other swing-interop class like SwingNode

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

PR Comment: https://git.openjdk.org/jfx/pull/1968#issuecomment-3514803313

From mstrauss at openjdk.org  Tue Nov 11 05:12:18 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 11 Nov 2025 05:12:18 GMT
Subject: Integrated: 8371106: [macOS] Min/max window height is incorrect for
 EXTENDED StageStyle
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Nov 2025 07:58:17 GMT, Michael Strau?  wrote:

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

This pull request has now been integrated.

Changeset: 013e55b1
Author:    Michael Strau? 
URL:       https://git.openjdk.org/jfx/commit/013e55b1ba687d212185d00167f375b816faf8c5
Stats:     18 lines in 2 files changed: 15 ins; 0 del; 3 mod

8371106: [macOS] Min/max window height is incorrect for EXTENDED StageStyle

Reviewed-by: angorya, kcr

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

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

From mhanl at openjdk.org  Tue Nov 11 08:13:55 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 11 Nov 2025 08:13:55 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle
Message-ID: 

This PR splits the maven publishing logic into an own file, `maven-publish.gradle`, that is next to the root `build.gradle`.

The `build.gradle` will apply the `maven-publish.gradle`. The `maven-publish.gradle` will then configure the Maven related properties and provides `addMavenPublication` as `Closure`.

This way, the logic and code can be completely the same. All modules still call `addMavenPublication`, as before. 
https://github.com/openjdk/jfx/blob/013e55b1ba687d212185d00167f375b816faf8c5/build.gradle#L2894-L2898
But the publishing code and properties itself are out of the main `build.gradle`.

Tested with:
- `./gradlew -PMAVEN_PUBLISH=true -PMAVEN_VERSION=custom publishToMavenLocal`
- `./gradlew -PMAVEN_PUBLISH=true publishToMavenLocal`
- `./gradlew -PMAVEN_PUBLISH=true -PMILESTONE_FCS=true publishToMavenLocal`

Everything still works:
-> javafx.base from the local .m2 repository
image

I think this is a good step and an easy way to split out functionality without blowing things up. We might want to do that for other parts as well.

Note: I also fixed the deprecated `buildDir` and 2 warnings where it seems like he might not be able to infer the type (changing `def` to the actual type). 
-> The file is completely green, no warnings or deprecations.

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

Commit messages:
 - 8333146: Move maven publication logic from build.gradle

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

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

From tsayao at openjdk.org  Tue Nov 11 11:49:21 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 11 Nov 2025 11:49:21 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v70]
In-Reply-To: 
References: 
Message-ID: 

> 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 84 commits:

 - Merge branch 'master' into 8354943
 - Remote assumeTrue for JDK-8364547
 - 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
 - ... and 74 more: https://git.openjdk.org/jfx/compare/013e55b1...7871e08b

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=69
  Stats: 4113 lines in 28 files changed: 2708 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 lkostyra at openjdk.org  Tue Nov 11 13:18:22 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 11 Nov 2025 13:18:22 GMT
Subject: RFR: 8371183: RichTextModel: ContentChange.isEdit incorrect
 undoing style modification [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 Nov 2025 19:49:19 GMT, Andy Goryachev  wrote:

>> Fixes an issue found by an external user:
>> 
>> Undoing a style only change fires a change event where `ContentChange.isEdit` is true when it should be false.
>> 
>> NOTE
>> 
>> - this PR depends on #1941 (resolved)
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bad merge

LGTM. I verified the test on Windows and playing around a short bit with Rich Editor, everything works fine.

Despite ~60 lines changed, this change is trivial (adding an extra flag and acting upon it in one place) and IMHO does not need a second reveiwer.

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1961#pullrequestreview-3448023601

From jdv at openjdk.org  Tue Nov 11 13:25:24 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 11 Nov 2025 13:25:24 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v16]
In-Reply-To: 
References: 
 
Message-ID: <07FR9yIqNDD3MpxC74kL2TYkXLD0tc8CNJ9IoPJICVg=.48ed1966-fbfe-46c9-bfdc-1e397743548e@github.com>

On Mon, 10 Nov 2025 17:47:58 GMT, Andy Goryachev  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 20 commits:
> 
>  - Merge branch 'master' into 8370140.line.separator
>  - 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
>  - ... and 10 more: https://git.openjdk.org/jfx/compare/f8bef157...8915ffa4

Current change looks good to me. But there is pending query in CSR.
Once it is approved, will re-review this PR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1944#issuecomment-3516916245

From kcr at openjdk.org  Tue Nov 11 14:23:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 11 Nov 2025 14:23:07 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 Nov 2025 08:07:32 GMT, Marius Hanl  wrote:

> This PR splits the maven publishing logic into an own file, `maven-publish.gradle`, that is next to the root `build.gradle`.
> 
> The `build.gradle` will apply the `maven-publish.gradle`. The `maven-publish.gradle` will then configure the Maven related properties and provides `addMavenPublication` as `Closure`.
> 
> This way, the logic and code can be completely the same. All modules still call `addMavenPublication`, as before. 
> https://github.com/openjdk/jfx/blob/013e55b1ba687d212185d00167f375b816faf8c5/build.gradle#L2894-L2898
> But the publishing code and properties itself are out of the main `build.gradle`.
> 
> Tested with:
> - `./gradlew -PMAVEN_PUBLISH=true -PMAVEN_VERSION=custom publishToMavenLocal`
> - `./gradlew -PMAVEN_PUBLISH=true publishToMavenLocal`
> - `./gradlew -PMAVEN_PUBLISH=true -PMILESTONE_FCS=true publishToMavenLocal`
> 
> Everything still works:
> -> javafx.base from the local .m2 repository
> image
> 
> I think this is a good step and an easy way to split out functionality without blowing things up. We might want to do that for other parts as well.
> 
> Note: I also fixed the deprecated `buildDir` and 2 warnings where it seems like he might not be able to infer the type (changing `def` to the actual type). 
> -> The file is completely green, no warnings or deprecations.

Reviewers: @johanvos @tiainen and one of @kevinrushforth or @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1970#issuecomment-3517143495

From nlisker at openjdk.org  Tue Nov 11 22:16:21 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 11 Nov 2025 22:16:21 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 Nov 2025 08:07:32 GMT, Marius Hanl  wrote:

> This PR splits the maven publishing logic into an own file, `maven-publish.gradle`, that is next to the root `build.gradle`.
> 
> The `build.gradle` will apply the `maven-publish.gradle`. The `maven-publish.gradle` will then configure the Maven related properties and provides `addMavenPublication` as `Closure`.
> 
> This way, the logic and code can be completely the same. All modules still call `addMavenPublication`, as before. 
> https://github.com/openjdk/jfx/blob/013e55b1ba687d212185d00167f375b816faf8c5/build.gradle#L2894-L2898
> But the publishing code and properties itself are out of the main `build.gradle`.
> 
> Tested with:
> - `./gradlew -PMAVEN_PUBLISH=true -PMAVEN_VERSION=custom publishToMavenLocal`
> - `./gradlew -PMAVEN_PUBLISH=true publishToMavenLocal`
> - `./gradlew -PMAVEN_PUBLISH=true -PMILESTONE_FCS=true publishToMavenLocal`
> 
> Everything still works:
> -> javafx.base from the local .m2 repository
> image
> 
> I think this is a good step and an easy way to split out functionality without blowing things up. We might want to do that for other parts as well.
> 
> Note: I also fixed the deprecated `buildDir` and 2 warnings where it seems like he might not be able to infer the type (changing `def` to the actual type). 
> -> The file is completely green, no warnings or deprecations.

Note that there's a relevant stale PR in https://github.com/openjdk/jfx/pull/1232 by @jjohannes. Maybe he'd like to take a look.

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

PR Comment: https://git.openjdk.org/jfx/pull/1970#issuecomment-3518916981

From zelmidaoui at openjdk.org  Wed Nov 12 15:52:53 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 12 Nov 2025 15:52:53 GMT
Subject: RFR: 8356770: TreeTableView not updated after removing a TreeItem with
 children and adding it to another parent
Message-ID: 

When a subtree is moved in a `TreeTableView` , the visuals don?t update until a resize or expand/collapse. The `TreeTableViewSkin` only rebuilds cells when the expanded row count changes.
This PR makes the skin to detect structural changes on `childrenModificationEvent` using new variable `treeStructureDirty`, and in `updateItemCount()` call `requestRebuildCells()` to refresh the visuals.

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

Commit messages:
 - Added new treeStructureDirty

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

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

From mhanl at openjdk.org  Wed Nov 12 15:55:34 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 12 Nov 2025 15:55:34 GMT
Subject: RFR: 8356770: TreeTableView not updated after removing a TreeItem
 with children and adding it to another parent
In-Reply-To: 
References: 
Message-ID: 

On Wed, 12 Nov 2025 14:21:22 GMT, Ziad El Midaoui  wrote:

> When a subtree is moved in a `TreeTableView` , the visuals don?t update until a resize or expand/collapse. The `TreeTableViewSkin` only rebuilds cells when the expanded row count changes.
> This PR makes the skin to detect structural changes on `childrenModificationEvent` using new variable `treeStructureDirty`, and in `updateItemCount()` call `requestRebuildCells()` to refresh the visuals.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableViewSkin.java line 151:

> 149:                     }
> 150:                     else if (eventType.equals(TreeItem.childrenModificationEvent())) {
> 151:                         markItemCountDirty();

Question: Couldn't you just call `requestRebuildCells` directly here?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1971#discussion_r2518861737

From zelmidaoui at openjdk.org  Wed Nov 12 16:14:04 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 12 Nov 2025 16:14:04 GMT
Subject: RFR: 8356770: TreeTableView not updated after removing a TreeItem
 with children and adding it to another parent
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 12 Nov 2025 15:52:40 GMT, Marius Hanl  wrote:

>> When a subtree is moved in a `TreeTableView` , the visuals don?t update until a resize or expand/collapse. The `TreeTableViewSkin` only rebuilds cells when the expanded row count changes.
>> This PR makes the skin to detect structural changes on `childrenModificationEvent` using new variable `treeStructureDirty`, and in `updateItemCount()` call `requestRebuildCells()` to refresh the visuals.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableViewSkin.java line 151:
> 
>> 149:                     }
>> 150:                     else if (eventType.equals(TreeItem.childrenModificationEvent())) {
>> 151:                         markItemCountDirty();
> 
> Question: Couldn't you just call `requestRebuildCells` directly here?

It works too , but makes the issue in JDK-8147483 reappear again which makes the test `test_jdk_8147483()` fail since it triggers extra full cell rebuilds. Here it only mark it and ask for layout in `updateItemCount()`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1971#discussion_r2518929402

From angorya at openjdk.org  Wed Nov 12 16:20:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 12 Nov 2025 16:20:05 GMT
Subject: RFR: 8371183: RichTextModel: ContentChange.isEdit incorrect
 undoing style modification [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 11 Nov 2025 13:15:46 GMT, Lukasz Kostyra  wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   bad merge
>
> LGTM. I verified the test on Windows and playing around a short bit with Rich Editor, everything works fine.
> 
> Despite ~60 lines changed, this change is trivial (adding an extra flag and acting upon it in one place) and IMHO does not need a second reveiwer.

Thank you, @lukostyra

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

PR Comment: https://git.openjdk.org/jfx/pull/1961#issuecomment-3522741082

From angorya at openjdk.org  Wed Nov 12 16:20:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 12 Nov 2025 16:20:06 GMT
Subject: Integrated: 8371183: RichTextModel: ContentChange.isEdit incorrect
 undoing style modification
In-Reply-To: 
References: 
Message-ID: 

On Tue, 4 Nov 2025 20:32:43 GMT, Andy Goryachev  wrote:

> Fixes an issue found by an external user:
> 
> Undoing a style only change fires a change event where `ContentChange.isEdit` is true when it should be false.
> 
> NOTE
> 
> - this PR depends on #1941 (resolved)

This pull request has now been integrated.

Changeset: 829d2be4
Author:    Andy Goryachev 
URL:       https://git.openjdk.org/jfx/commit/829d2be46edeedd08f8413d02fd349047ed9f21b
Stats:     62 lines in 4 files changed: 46 ins; 0 del; 16 mod

8371183: RichTextModel: ContentChange.isEdit incorrect undoing style modification

Reviewed-by: lkostyra

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

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

From angorya at openjdk.org  Wed Nov 12 17:03:18 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 12 Nov 2025 17:03:18 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v2]
In-Reply-To: <9ePaZacAc0aIGeKPS1FQEJU8U0BrxSYXmuLNY23TGLI=.40a67a67-e20e-4aa6-8441-236a0e222c77@github.com>
References: 
 <9ePaZacAc0aIGeKPS1FQEJU8U0BrxSYXmuLNY23TGLI=.40a67a67-e20e-4aa6-8441-236a0e222c77@github.com>
Message-ID: 

On Tue, 11 Nov 2025 03:02:01 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   debug fix

Changes requested by angorya (Reviewer).

modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 212:

> 210: 
> 211:     private static void debug_println(String str) {
> 212:         if (DEBUG) {

I am sorry, I was not sufficiently clear.
This method does not need the conditional.  The conditionals are needed in **every** place that calls here.
In other words, we don't want to incur the string concatenation overhead if **DEBUG** is false.

modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 286:

> 284:         super();
> 285: 
> 286:         debug_println("JFXPanel Thread " + Thread.currentThread().getName() + " isFXUserThread " + Toolkit.getToolkit().isFxUserThread());

Basically, here (and elsewhere debug_println() is called) we should have

if(DEBUG) {
          debug_println("JFXPanel Thread " + Thread.currentThread().getName() + " isFXUserThread " + Toolkit.getToolkit().isFxUserThread());
}


As a separate note, you may want to consider removing some noise from debugging output and only print when "unexpected" condition occurs, such as (thread != fx), right?

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

PR Review: https://git.openjdk.org/jfx/pull/1968#pullrequestreview-3454498726
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2519095341
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2519105890

From kcr at openjdk.org  Wed Nov 12 19:10:32 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 12 Nov 2025 19:10:32 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 Nov 2025 01:54:56 GMT, Michael Strau?  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

API changes look good. The code change look good, although I left an inline question about one of the changes (since it would impact all stage styles, not just EXTENDED).

You can create the CSR now.

modules/javafx.controls/src/main/java/javafx/scene/control/DialogPane.java line 221:

> 219:         headerTextPanel = new GridPane();
> 220:         headerTextPanel.setVisible(false);
> 221:         headerTextPanel.setManaged(false);

Why was this change needed? At first glance it seems unrelated to supporting an (optional) header bar.

modules/javafx.controls/src/main/java/javafx/scene/control/DialogPane.java line 228:

> 226:         contentLabel = createContentLabel("");
> 227:         contentLabel.setVisible(false);
> 228:         contentLabel.setManaged(false);

Same question here.

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

PR Review: https://git.openjdk.org/jfx/pull/1943#pullrequestreview-3455010645
PR Review Comment: https://git.openjdk.org/jfx/pull/1943#discussion_r2519469531
PR Review Comment: https://git.openjdk.org/jfx/pull/1943#discussion_r2519470170

From angorya at openjdk.org  Wed Nov 12 19:28:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 12 Nov 2025 19:28:58 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v17]
In-Reply-To: 
References: 
Message-ID: <4nLxCaKa3kVgc3RA0ohbAIx7sZsIt1D1PEdK93HMkZ4=.d560d0d9-f1d8-4a61-acd1-d4abebd64e3b@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 22 commits:

 - system
 - Merge branch 'master' into 8370140.line.separator
 - Merge branch 'master' into 8370140.line.separator
 - 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
 - ... and 12 more: https://git.openjdk.org/jfx/compare/829d2be4...576a8575

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

Changes: https://git.openjdk.org/jfx/pull/1944/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=16
  Stats: 301 lines in 13 files changed: 272 ins; 11 del; 18 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 martinfox656 at gmail.com  Wed Nov 12 19:36:04 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Wed, 12 Nov 2025 11:36:04 -0800
Subject: StageStyle.EXTENDED with transparent background
In-Reply-To: <4A04FCF2-573D-43CD-B1E6-056460435E6F@gmail.com>
References: <3239F687-9FEB-4701-8075-79C38F84B7AE@gmail.com>
 <4A04FCF2-573D-43CD-B1E6-056460435E6F@gmail.com>
Message-ID: <87D428E5-1A5D-472C-9308-D0EF52DEB7A6@gmail.com>

Glavo,

I finally got around to looking into this. I see two requests here, one to add per-pixel window transparency to EXTENDED stages and another to support backdrop materials like Windows? Mica and Acrylic.

On the Mac adding per-pixel transparency to all stage styles is easy. On Windows it would take a lot more work and as far as I know can?t be done with the existing DX9 back end (the necessary DirectComposition API?s are tied to DX11). We would also need to reconcile platform differences related to hit testing and drop shadows. So it?s a big ask.

(I know there?s a DX12 version of JavaFX in the works but it?s hard for me to get enthused. I run Windows in a VM and it?s likely to be stuck on DX11 for a long time.)

Supporting translucent backdrop materials is simpler since we can ask the OS to draw the effect and then composite the JavaFX content over it all within an opaque window. This is how the UNIFIED stage style works so we can leverage that logic. On Mac this is easy to set up. On Windows 11 22H2 and beyond we can easily access a couple of materials. For earlier Windows versions or for a more extensive list of materials we would need to roll our own using DirectComposition.

I know nothing about DirectComposition but I?m pretty sure someone on this list has used it to prototype an Acrylic effect for JavaFX. I?ll see if I can find that e-mail. I?m particularly interested in whether this can easily be turned on and off on-the-fly and how dark mode would be handled (the platform-provided materials respond to dark mode).

I?m probably not the right person to lead the charge on this. On the Mac side the platform code is straightforward. On the Windows side most of the platform work will involve Windows 10 which I can?t run. In any case I suspect the bulk of the work will be in defining the API and sorting out the CSS issues and on that I will defer to folks who have more experience (which is just about everyone).

I did not investigate any of this on Linux.

Martin

P.S. The UNIFIED stage style on Windows is broken. It?s easy to fix but the Aero sheet-of-glass effect it was added for is defunct so there?s been no motivation to get it working again. On macOS it was a brushed metal look that?s also long gone.

> On Oct 25, 2025, at 8:08?AM, Martin Fox  wrote:
> 
> With StageStyle.EXTENDED some of the window elements are drawn by the OS. On all platforms that would include the drop shadows. For Mac it would include the default close/iconify/fullscreen controls (which are difficult to replace seamlessly) and on Windows I?m pretty sure the OS draws a thin outline or two around each stage. If the goal is to allow control over the opacity of the window keep in mind that you won?t be able to control the opacity of these elements.
> 
> EXTENDED assumes an opaque background just like DECORATED does so this would require an API addition in JavaFX. Which platforms are you most interested in? My guess is that this is not much work on Mac, probably very tricky or impossible on Windows and for Linux I would not even venture a guess.
> 
> Martin
> 
>> On Oct 21, 2025, at 10:09?AM, Dirk Lemmermann  wrote:
>> 
>> ?I am very much interested in this, too. I currently do not need it but I had projects in the past where I wished this feature had been available. I am confident this wish will resurface again at some point in time. It?s one more of those features that will make it possible for JavaFX developers to build apps that can compete with more native UI frameworks.
>> 
>> Dirk
>> 
>>> Am 21.10.2025 um 05:00 schrieb Glavo :
>>> 
>>> Is anyone interested in this question?
>>> 
>>> On Wed, Oct 15, 2025 at 10:21?PM Glavo > wrote:
>>>> Hi,
>>>> 
>>>> Our application has traditionally used StageStyle.TRANSPARENT to enable a fully customizable stage. 
>>>> This allows users to set custom backgrounds and adjust the window's opacity freely, leveraging our powerful personalization features.
>>>> 
>>>> After the release of JavaFX 25, we want to migrate to StageStyle.EXTENDED so that 
>>>> we can use native window decorations and no longer need to draw window shadows ourselves.
>>>> But using StageStyle.EXTENDED creates a stage with a white background, which prevents us 
>>>> from setting the window's opacity.
>>>> So is there any way we can make the stage background transparent while using StageStyle.EXTENDED?
>>>> 
>>>> Glavo
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Wed Nov 12 20:25:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 12 Nov 2025 20:25:46 GMT
Subject: RFR: 8356770: TreeTableView not updated after removing a TreeItem
 with children and adding it to another parent
In-Reply-To: 
References: 
Message-ID: 

On Wed, 12 Nov 2025 14:21:22 GMT, Ziad El Midaoui  wrote:

> When a subtree is moved in a `TreeTableView` , the visuals don?t update until a resize or expand/collapse. The `TreeTableViewSkin` only rebuilds cells when the expanded row count changes.
> This PR makes the skin to detect structural changes on `childrenModificationEvent` using new variable `treeStructureDirty`, and in `updateItemCount()` call `requestRebuildCells()` to refresh the visuals.

@Ziad-Mid can we add a unit test which fails in master and passes with the fix?

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

PR Comment: https://git.openjdk.org/jfx/pull/1971#issuecomment-3523759739

From michaelstrau2 at gmail.com  Wed Nov 12 23:33:23 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Thu, 13 Nov 2025 00:33:23 +0100
Subject: StageStyle.EXTENDED with transparent background
In-Reply-To: <87D428E5-1A5D-472C-9308-D0EF52DEB7A6@gmail.com>
References: <3239F687-9FEB-4701-8075-79C38F84B7AE@gmail.com>
 <4A04FCF2-573D-43CD-B1E6-056460435E6F@gmail.com>
 <87D428E5-1A5D-472C-9308-D0EF52DEB7A6@gmail.com>
Message-ID: 

> I finally got around to looking into this. I see two requests here, one to add per-pixel window transparency to EXTENDED stages and another to support backdrop materials like Windows? Mica and Acrylic.
>
> On the Mac adding per-pixel transparency to all stage styles is easy. On Windows it would take a lot more work and as far as I know can?t be done with the existing DX9 back end (the necessary DirectComposition API?s are tied to DX11). We would also need to reconcile platform differences related to hit testing and drop shadows. So it?s a big ask.

I think we can probably get there by using a WS_EX_LAYERED window like
we do for StageStyle.TRANSPARENT, if we accept the significant
performance impact. With DirectComposition, we can directly interface
with the DWM composition engine and skip the GDI window surface
completely. This requires a fair bit of integration with JavaFX that
goes beyond changes in the Glass toolkit. However, it doesn't require
a D3D11 rendering pipeline. It works with the existing D3D9 pipeline
by having D3D9 render into a shared off-screen surface, which is then
accessed by DirectComposition with ID3D11Device::OpenSharedResource.



> (I know there?s a DX12 version of JavaFX in the works but it?s hard for me to get enthused. I run Windows in a VM and it?s likely to be stuck on DX11 for a long time.)
>
> Supporting translucent backdrop materials is simpler since we can ask the OS to draw the effect and then composite the JavaFX content over it all within an opaque window. This is how the UNIFIED stage style works so we can leverage that logic. On Mac this is easy to set up. On Windows 11 22H2 and beyond we can easily access a couple of materials. For earlier Windows versions or for a more extensive list of materials we would need to roll our own using DirectComposition.

That's correct, it's reasonably simple to support platform-provided
backdrop materials. Anything custom is a lot more difficult.
I have a prototype of JavaFX with DirectComposition, along with a
custom acrylic implementation. It's very old, and looks like this
(running on Windows 10):
https://github.com/user-attachments/assets/cd702a74-603a-4d7e-9078-52f915a4448a

In the end, there doesn't seem to be much common ground between the
various OS platforms for any reasonably powerful cross-platform API.
Maybe we could have the supporting infrastructure in JavaFX, but only
exposing API in a platform-specific module (either as part of OpenJFX
or 3rd party)? This certainly requires quite a bit of work.



> I know nothing about DirectComposition but I?m pretty sure someone on this list has used it to prototype an Acrylic effect for JavaFX. I?ll see if I can find that e-mail. I?m particularly interested in whether this can easily be turned on and off on-the-fly and how dark mode would be handled (the platform-provided materials respond to dark mode).

I've never heard of any previous effort, and it couldn't have been me
beacuse I haven't talked about this up util now. I'd be interested to
learn about other attempts at solving this.

From angorya at openjdk.org  Wed Nov 12 23:47:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 12 Nov 2025 23:47:24 GMT
Subject: RFR: 8356770: TreeTableView not updated after removing a TreeItem
 with children and adding it to another parent
In-Reply-To: 
References: 
Message-ID: 

On Wed, 12 Nov 2025 14:21:22 GMT, Ziad El Midaoui  wrote:

> When a subtree is moved in a `TreeTableView` , the visuals don?t update until a resize or expand/collapse. The `TreeTableViewSkin` only rebuilds cells when the expanded row count changes.
> This PR makes the skin to detect structural changes on `childrenModificationEvent` using new variable `treeStructureDirty`, and in `updateItemCount()` call `requestRebuildCells()` to refresh the visuals.

I see no ill effects with the reproducer and the monkey tester (which was updated to add data manipulation context menus, see https://github.com/andy-goryachev-oracle/MonkeyTest ).

I suppose adding a flag in the skin (as opposed to similar flag in `VirtualContainerBase`) is ok since it deals with tree-table-specific functionality.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1971#pullrequestreview-3456069283

From psadhukhan at openjdk.org  Thu Nov 13 03:12:19 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 13 Nov 2025 03:12:19 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v2]
In-Reply-To: 
References: 
 <9ePaZacAc0aIGeKPS1FQEJU8U0BrxSYXmuLNY23TGLI=.40a67a67-e20e-4aa6-8441-236a0e222c77@github.com>
 
Message-ID: 

On Wed, 12 Nov 2025 16:57:16 GMT, Andy Goryachev  wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   debug fix
>
> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 212:
> 
>> 210: 
>> 211:     private static void debug_println(String str) {
>> 212:         if (DEBUG) {
> 
> I am sorry, I was not sufficiently clear.
> This method does not need the conditional.  The conditionals are needed in **every** place that calls here.
> In other words, we don't want to incur the string concatenation overhead if **DEBUG** is false.

will that be too much overhead? We had used the same in jdk having DEBUG check in one place...but I will modify it for FX..

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2521089549

From psadhukhan at openjdk.org  Thu Nov 13 03:28:51 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 13 Nov 2025 03:28:51 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v3]
In-Reply-To: 
References: 
Message-ID: 

> 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

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - debug log fix
 - debug log fix

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1968/files
  - new: https://git.openjdk.org/jfx/pull/1968/files/4cae0411..115001f6

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

  Stats: 124 lines in 1 file changed: 90 ins; 3 del; 31 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 psadhukhan at openjdk.org  Thu Nov 13 03:36:17 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 13 Nov 2025 03:36:17 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v2]
In-Reply-To: 
References: 
 <9ePaZacAc0aIGeKPS1FQEJU8U0BrxSYXmuLNY23TGLI=.40a67a67-e20e-4aa6-8441-236a0e222c77@github.com>
 
Message-ID: 

On Wed, 12 Nov 2025 17:00:38 GMT, Andy Goryachev  wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   debug fix
>
> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 286:
> 
>> 284:         super();
>> 285: 
>> 286:         debug_println("JFXPanel Thread " + Thread.currentThread().getName() + " isFXUserThread " + Toolkit.getToolkit().isFxUserThread());
> 
> Basically, here (and elsewhere debug_println() is called) we should have
> 
> if(DEBUG) {
>           debug_println("JFXPanel Thread " + Thread.currentThread().getName() + " isFXUserThread " + Toolkit.getToolkit().isFxUserThread());
> }
> 
> 
> As a separate note, you may want to consider removing some noise from debugging output and only print when "unexpected" condition occurs, such as (thread != fx), right?

I guess different method will have different unexpected condition so I kept it generic to crosscheck if calling thread are indeed what it should be..

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2521176030

From jhendrikx at openjdk.org  Thu Nov 13 05:32:17 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 13 Nov 2025 05:32:17 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Nov 2025 03:28:51 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - debug log fix
>  - debug log fix

Sorry, what exactly are we trying to do here?  Is the problem that intractable that we must add a million debug lines that will be shipped to everyone in the hope someone will debug the problem on their machine?  This stuff belongs on some local branch, not be considered for inclusion in FX IMHO.

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

PR Comment: https://git.openjdk.org/jfx/pull/1968#issuecomment-3525487234

From sykora at openjdk.org  Thu Nov 13 09:42:36 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Thu, 13 Nov 2025 09:42:36 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 Nov 2025 08:07:32 GMT, Marius Hanl  wrote:

> This PR splits the maven publishing logic into an own file, `maven-publish.gradle`, that is next to the root `build.gradle`.
> 
> The `build.gradle` will apply the `maven-publish.gradle`. The `maven-publish.gradle` will then configure the Maven related properties and provides `addMavenPublication` as `Closure`.
> 
> This way, the logic and code can be completely the same. All modules still call `addMavenPublication`, as before. 
> https://github.com/openjdk/jfx/blob/013e55b1ba687d212185d00167f375b816faf8c5/build.gradle#L2894-L2898
> But the publishing code and properties itself are out of the main `build.gradle`.
> 
> Tested with:
> - `./gradlew -PMAVEN_PUBLISH=true -PMAVEN_VERSION=custom publishToMavenLocal`
> - `./gradlew -PMAVEN_PUBLISH=true publishToMavenLocal`
> - `./gradlew -PMAVEN_PUBLISH=true -PMILESTONE_FCS=true publishToMavenLocal`
> 
> Everything still works:
> -> javafx.base from the local .m2 repository
> image
> 
> I think this is a good step and an easy way to split out functionality without blowing things up. We might want to do that for other parts as well.
> 
> Note: I also fixed the deprecated `buildDir` and 2 warnings where it seems like he might not be able to infer the type (changing `def` to the actual type). 
> -> The file is completely green, no warnings or deprecations.

Marked as reviewed by sykora (Author).

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

PR Review: https://git.openjdk.org/jfx/pull/1970#pullrequestreview-3458723873

From mstrauss at openjdk.org  Thu Nov 13 09:58:29 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 13 Nov 2025 09:58:29 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED [v4]
In-Reply-To: 
References: 
Message-ID: <9vM4xSY16gNYW0PXxmlZYLPliRA8jama3HIyXvedYz4=.cf26f791-f30f-42f9-8e4b-f604ea78ed50@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 incrementally with one additional commit since the last revision:

  fix incorrect button metrics

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1943/files
  - new: https://git.openjdk.org/jfx/pull/1943/files/1cc864de..cddb1402

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

  Stats: 259 lines in 3 files changed: 222 ins; 17 del; 20 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 mhanl at openjdk.org  Thu Nov 13 10:09:16 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 13 Nov 2025 10:09:16 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 Nov 2025 08:07:32 GMT, Marius Hanl  wrote:

> This PR splits the maven publishing logic into an own file, `maven-publish.gradle`, that is next to the root `build.gradle`.
> 
> The `build.gradle` will apply the `maven-publish.gradle`. The `maven-publish.gradle` will then configure the Maven related properties and provides `addMavenPublication` as `Closure`.
> 
> This way, the logic and code can be completely the same. All modules still call `addMavenPublication`, as before. 
> https://github.com/openjdk/jfx/blob/013e55b1ba687d212185d00167f375b816faf8c5/build.gradle#L2894-L2898
> But the publishing code and properties itself are out of the main `build.gradle`.
> 
> Tested with:
> - `./gradlew -PMAVEN_PUBLISH=true -PMAVEN_VERSION=custom publishToMavenLocal`
> - `./gradlew -PMAVEN_PUBLISH=true publishToMavenLocal`
> - `./gradlew -PMAVEN_PUBLISH=true -PMILESTONE_FCS=true publishToMavenLocal`
> 
> Everything still works:
> -> javafx.base from the local .m2 repository
> image
> 
> I think this is a good step and an easy way to split out functionality without blowing things up. We might want to do that for other parts as well.
> 
> Note: I also fixed the deprecated `buildDir` and 2 warnings where it seems like he might not be able to infer the type (changing `def` to the actual type). 
> -> The file is completely green, no warnings or deprecations.

> Note that there's a relevant stale PR in #1232 by @jjohannes. Maybe he'd like to take a look.

Thanks. It looks like my work will not block/interfere the implementation of that PR, which is good. 
It should be easy to pick the changes from there over in the new `maven-publish.gradle`. 
Should also help for reviewing, since it is more isolated. :-)

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

PR Comment: https://git.openjdk.org/jfx/pull/1970#issuecomment-3526934812

From mstrauss at openjdk.org  Thu Nov 13 10:12:33 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 13 Nov 2025 10:12:33 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED [v4]
In-Reply-To: <9vM4xSY16gNYW0PXxmlZYLPliRA8jama3HIyXvedYz4=.cf26f791-f30f-42f9-8e4b-f604ea78ed50@github.com>
References: 
 <9vM4xSY16gNYW0PXxmlZYLPliRA8jama3HIyXvedYz4=.cf26f791-f30f-42f9-8e4b-f604ea78ed50@github.com>
Message-ID: <740zMOqxRgo_Zx2CTkiU8GxJVkIod2Fsc-v8aNrVjac=.0fc66301-8d41-45ac-af6b-a92697810c42@github.com>

On Thu, 13 Nov 2025 09:58:29 GMT, Michael Strau?  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:
> 
>   fix incorrect button metrics

I discovered a bug where `HeaderBar` would sometimes not report its correct height in situations when a `DialogPane` is re-used (similar to [this](https://github.com/openjdk/jfx/pull/1943#issuecomment-3440326580)). The root cause for this bug was that `HeaderButtonOverlay.metricsProperty()` was updated in `HeaderButtonOverlay.layoutChildren()`, i.e. during the layout phase. However, the metrics property itself is used as an input for the layout of `HeaderBar`, so its value should be known in advance of layout, and not be determined during the layout phase. The solution here is to disentangle the computation of header button metrics from the layout computation of `HeaderButtonOverlay`. I've refactored the code a bit, and now the `metrics` property is always updated after CSS processing (which is when we have enough information to know the size and placement of the header buttons), and therefore _before_ a layout pass.

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

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

From mstrauss at openjdk.org  Thu Nov 13 10:20:49 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 13 Nov 2025 10:20:49 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 12 Nov 2025 19:05:30 GMT, Kevin Rushforth  wrote:

>> 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
>
> modules/javafx.controls/src/main/java/javafx/scene/control/DialogPane.java line 221:
> 
>> 219:         headerTextPanel = new GridPane();
>> 220:         headerTextPanel.setVisible(false);
>> 221:         headerTextPanel.setManaged(false);
> 
> Why was this change needed? At first glance it seems unrelated to supporting an (optional) header bar.

This was left over from a previous bug-fixing attempt. I've removed the added code.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1943#discussion_r2522779075

From lukasz.kostyra at oracle.com  Thu Nov 13 13:40:30 2025
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Thu, 13 Nov 2025 13:40:30 +0000
Subject: JavaFX Direct3D 12 - Second EA release
Message-ID: 

Hello openjfx-dev,

The second Early Access(EA) build of JavaFX with the Windows Direct3D 12 rendering pipeline is now available at: https://jdk.java.net/javafxdirect3d12/

Please test this bundle and share your feedback by:
- emailing openjfx-dev at openjdk.java.net or
- reporting issues via JBS[https://bugs.openjdk.org/] or at https://bugreport.java.com

This is the second EA release. The backend is feature-complete and went through a first optimization pass, but it still requires some more testing on more hardware variants before we can consider it complete. As such, with this release we also would like to call for help with performance testing the backend (more details on that will be sent in a separate email thread).

Known issues and pending tasks are captured on JBS and can be accessed using the filter provided on the Direct3D 12 EA page [https://jdk.java.net/javafxdirect3d12/]. Before reporting a new bug, please review the existing issues to avoid duplicates.

Important Notes:
1. This is a Windows-specific feature, so only a Windows-specific bundle is provided.
2. The default rendering pipeline is set to d3d12. Use "-Dprism.order=d3d" or "-Dprism.order=sw" to select one of the other pipelines for comparison testing.
3. It is recommended to use JDK 25 or later.
4. At this stage D3D12 backend is feature-complete and went through the first phase of optimization. It is worth noting that, while generally we noticed performance improvements, it might not be on par with D3D backend on every machine combo  - we already noted performance being worse on recent NVidia discrete GPUs [https://bugs.openjdk.org/browse/JDK-8370486] and are looking for solutions.
5. Issue behavior may vary across different hardware, so please provide detailed information, such as the output of "java -Dprism.verbose=true" or used hardware, when reporting or discussing issues.
6. Refer: Run HelloWorld using JavaFX SDK [https://openjfx.io/openjfx-docs/#install-javafx]

We look forward to your feedback.

Regards,
Lukasz


Confidential- Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From crschnick at xpipe.io  Thu Nov 13 14:21:03 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Thu, 13 Nov 2025 15:21:03 +0100
Subject: StageStyle.EXTENDED with transparent background
In-Reply-To: 
References: <3239F687-9FEB-4701-8075-79C38F84B7AE@gmail.com>
 <4A04FCF2-573D-43CD-B1E6-056460435E6F@gmail.com>
 <87D428E5-1A5D-472C-9308-D0EF52DEB7A6@gmail.com>
 
Message-ID: <4cedea2f-fdb5-4a07-ab91-bd397c10aa82@xpipe.io>

We run our applications with native materials for some time now without 
any issues.

On Windows 11, it uses the Mica material for the Stage. It automatically 
adjusts based on the system theme, so you will always have a good look 
and contrast for all theme configurations. The mica material can also be 
swtiched to the acrylic one, however the acrylic theme was primarily 
intended for Windows 10 and is being replaced by Mica for Windows 11.

On macOS, it uses the new Liquid Glass material in macOS 26 and the 
Vibrant material for older versions. With Liquid Glass you can also 
configure the tint if needed.

This can all be achieved via a few native calls with the existing 
Stages, at least with the older stage styles like Unified.

Isn't the original issue just about the extended stage style using a 
white background? I'm no expert on the implementation, but the other 
types of Stages like Unified show their background if you set the Scene 
and root node background to be transparent. Normally that window fill 
was always white anyway as JavaFX did not support window theming before, 
but if the window theme is set to something different, then that sticks 
out. Is there something fundamentally limiting so that the Extended 
stage is forced to draw a white background?

Unified:

Extended, even with DWMWA_USE_IMMERSIVE_DARK_MODE set to true:

On 13/11/2025 00:33, Michael Strau? wrote:
>> I finally got around to looking into this. I see two requests here, one to add per-pixel window transparency to EXTENDED stages and another to support backdrop materials like Windows? Mica and Acrylic.
>>
>> On the Mac adding per-pixel transparency to all stage styles is easy. On Windows it would take a lot more work and as far as I know can?t be done with the existing DX9 back end (the necessary DirectComposition API?s are tied to DX11). We would also need to reconcile platform differences related to hit testing and drop shadows. So it?s a big ask.
> I think we can probably get there by using a WS_EX_LAYERED window like
> we do for StageStyle.TRANSPARENT, if we accept the significant
> performance impact. With DirectComposition, we can directly interface
> with the DWM composition engine and skip the GDI window surface
> completely. This requires a fair bit of integration with JavaFX that
> goes beyond changes in the Glass toolkit. However, it doesn't require
> a D3D11 rendering pipeline. It works with the existing D3D9 pipeline
> by having D3D9 render into a shared off-screen surface, which is then
> accessed by DirectComposition with ID3D11Device::OpenSharedResource.
>
>
>
>> (I know there?s a DX12 version of JavaFX in the works but it?s hard for me to get enthused. I run Windows in a VM and it?s likely to be stuck on DX11 for a long time.)
>>
>> Supporting translucent backdrop materials is simpler since we can ask the OS to draw the effect and then composite the JavaFX content over it all within an opaque window. This is how the UNIFIED stage style works so we can leverage that logic. On Mac this is easy to set up. On Windows 11 22H2 and beyond we can easily access a couple of materials. For earlier Windows versions or for a more extensive list of materials we would need to roll our own using DirectComposition.
> That's correct, it's reasonably simple to support platform-provided
> backdrop materials. Anything custom is a lot more difficult.
> I have a prototype of JavaFX with DirectComposition, along with a
> custom acrylic implementation. It's very old, and looks like this
> (running on Windows 10):
> https://github.com/user-attachments/assets/cd702a74-603a-4d7e-9078-52f915a4448a
>
> In the end, there doesn't seem to be much common ground between the
> various OS platforms for any reasonably powerful cross-platform API.
> Maybe we could have the supporting infrastructure in JavaFX, but only
> exposing API in a platform-specific module (either as part of OpenJFX
> or 3rd party)? This certainly requires quite a bit of work.
>
>
>
>> I know nothing about DirectComposition but I?m pretty sure someone on this list has used it to prototype an Acrylic effect for JavaFX. I?ll see if I can find that e-mail. I?m particularly interested in whether this can easily be turned on and off on-the-fly and how dark mode would be handled (the platform-provided materials respond to dark mode).
> I've never heard of any previous effort, and it couldn't have been me
> beacuse I haven't talked about this up util now. I'd be interested to
> learn about other attempts at solving this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aBRzaHD5w0KvUgrJ.png
Type: image/png
Size: 282963 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HRrOi0IB1NCsFlHW.png
Type: image/png
Size: 208285 bytes
Desc: not available
URL: 

From lukasz.kostyra at oracle.com  Thu Nov 13 14:50:16 2025
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Thu, 13 Nov 2025 14:50:16 +0000
Subject: JavaFX Direct3D 12 - Call for performance testing help
Message-ID: 

Hello openjfx-dev,

Because Windows is very open hardware-wise, it is difficult to prepare the backend for all possible hardware combinations available, especially from performance perspective. To make sure JavaFX performance does not degrade compared to old D3D backend we would like to call for volunteers to help performance-test the backend. These tests will let us get a general idea on how the backend behaves on different hardware and which areas of the backend to focus on while moving forward with optimization effort for Direct3D 12.

At this point we tested the backend quite extensively on Intel-based integrated GPUs and did some testing on a machine running a recent discrete Nvidia GPU. We are primarily looking for testing Direct3D 12 backend on a system running an AMD discrete GPU, but any hardware combinations are welcome - the more the merrier :). Also note that these tests require a Windows machine, as D3D12 backend is Windows-only.

We run performance testing using RenderPerfTest JavaFX app located in the JavaFX repository under "tests/performance/animation/RenderPerfTest". I wrote a bash script to use with this app for performance-testing the backend. The script will run all available demos on RenderPerfTest with a set amount of objects per test, average the FPS results from each run and output the results into a CSV file.


How to run perf tests:

  1.  Download the test script - https://gist.github.com/lukostyra/bc354a5fd845b82805ffb3380caebe9a
  2.  Get JavaFX Direct3D 12 build - either download the EA2 SDK from [ https://jdk.java.net/javafxdirect3d12/ ] or build it from scratch from direct3d12 [ https://github.com/openjdk/jfx-sandbox/tree/direct3d12 ] branch (make sure to build with -PCONF=Release; at the time of writing this email there is no functional difference between the sandbox repo and the EA2 build).
  3.  Put the script in the same directory as renderperf/RenderPerfTest.java - I usually copy the contents of tests/performance/animation/RenderPerfTest/src into a separate directory where the script is located. The script will look in the current directory specifically for "renderperf" directory containing a "RenderPerfTest.java" source file.
  4.  Ensure nothing else is running on your system.
  5.  Perform a baseline test run with D3D backend:
   ./run_renderperf_all.sh -j  -b d3d -r 3
When the script is done, this should result in "RenderPerf_results_d3d--

> 69:  * {@code HeaderBar} is a layout container that allows applications to place scene graph nodes in three areas:
> 70:  * {@link #leftProperty() left}, {@link #centerProperty() center}, and {@link #rightProperty() right}.

perhaps there should be a separate section explaining that the left/right nodes get switched visually in the RTL mode?  And/or mention that "left" really means "leading", and "right" really means "trailing"?

modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 465:

> 463: 
> 464:     /**
> 465:      * The right area of the {@code HeaderBar}.

please explain RTL behavior, also for "right".

modules/javafx.graphics/src/test/java/test/javafx/scene/layout/HeaderBarTest.java line 187:

> 185:             "BOTTOM_RIGHT, 890, 40, 100, 50"
> 186:         })
> 187:         void alignmentOfRightChildOnly_notResizable(Pos pos, double x, double y, double width, double height) {

FYI, `@CsvSource` also accepts a `textBlock` attribute:


        @ParameterizedTest
        @CsvSource(textBlock = """
            TOP_LEFT, 890, 10, 100, 50
            TOP_CENTER, 890, 10, 100, 50
            TOP_RIGHT, 890, 10, 100, 50
            CENTER_LEFT, 890, 25, 100, 50
            CENTER, 890, 25, 100, 50
            CENTER_RIGHT, 890, 25, 100, 50
            BOTTOM_LEFT, 890, 40, 100, 50
            BOTTOM_CENTER, 890, 40, 100, 50
            BOTTOM_RIGHT, 890, 40, 100, 50
            """
        )

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2528493574
PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2528533628
PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2528561154

From angorya at openjdk.org  Fri Nov 14 18:49:34 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 14 Nov 2025 18:49:34 GMT
Subject: RFR: 8369836: Update HeaderBar API [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 23 Oct 2025 17:58:24 GMT, Kevin Rushforth  wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make leftSystemInset/rightSystemInset/minSystemHeight attached properties
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 287:
> 
>> 285:      *
>> 286:      * @param stage the {@code Stage}
>> 287:      * @return the {@code leftSystemInset} property
> 
> Needs `@since 26` javadoc tag (for all new methods).

please explain RTL behavior (here and elsewhere)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2528494548

From mhanl at openjdk.org  Fri Nov 14 19:23:37 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 14 Nov 2025 19:23:37 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR splits the maven publishing logic into an own file, `maven-publish.gradle`, that is next to the root `build.gradle`.
> 
> The `build.gradle` will apply the `maven-publish.gradle`. The `maven-publish.gradle` will then configure the Maven related properties and provides `addMavenPublication` as `Closure`.
> 
> This way, the logic and code can be completely the same. All modules still call `addMavenPublication`, as before. 
> https://github.com/openjdk/jfx/blob/013e55b1ba687d212185d00167f375b816faf8c5/build.gradle#L2894-L2898
> But the publishing code and properties itself are out of the main `build.gradle`.
> 
> Tested with:
> - `./gradlew -PMAVEN_PUBLISH=true -PMAVEN_VERSION=custom publishToMavenLocal`
> - `./gradlew -PMAVEN_PUBLISH=true publishToMavenLocal`
> - `./gradlew -PMAVEN_PUBLISH=true -PMILESTONE_FCS=true publishToMavenLocal`
> 
> Everything still works:
> -> javafx.base from the local .m2 repository
> image
> 
> I think this is a good step and an easy way to split out functionality without blowing things up. We might want to do that for other parts as well.
> 
> Note: I also fixed the deprecated `buildDir` and 2 warnings where it seems like he might not be able to infer the type (changing `def` to the actual type). 
> -> The file is completely green, no warnings or deprecations.

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

  Copyright header

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1970/files
  - new: https://git.openjdk.org/jfx/pull/1970/files/1af96337..2b45aa63

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

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

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

From kcr at openjdk.org  Fri Nov 14 19:25:33 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 14 Nov 2025 19:25:33 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v17]
In-Reply-To: <4nLxCaKa3kVgc3RA0ohbAIx7sZsIt1D1PEdK93HMkZ4=.d560d0d9-f1d8-4a61-acd1-d4abebd64e3b@github.com>
References: 
 <4nLxCaKa3kVgc3RA0ohbAIx7sZsIt1D1PEdK93HMkZ4=.d560d0d9-f1d8-4a61-acd1-d4abebd64e3b@github.com>
Message-ID: 

On Wed, 12 Nov 2025 19:28:58 GMT, Andy Goryachev  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 22 commits:
> 
>  - system
>  - Merge branch 'master' into 8370140.line.separator
>  - Merge branch 'master' into 8370140.line.separator
>  - 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
>  - ... and 12 more: https://git.openjdk.org/jfx/compare/829d2be4...576a8575

The updated API and implementation look good. I left one minor comment about the new `system()` method and will reapprove if you make changes.

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

> 55:     /**
> 56:      * Returns the system default {@code LineEnding} based on the value of system property
> 57:      * {@code System.getProperty("line.separator")}.

Minor: `System.lineSeparator()` is preferred over `System.getProperty("line.separator")`.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1944#pullrequestreview-3466365762
PR Review Comment: https://git.openjdk.org/jfx/pull/1944#discussion_r2528596488

From mhanl at openjdk.org  Fri Nov 14 19:34:37 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 14 Nov 2025 19:34:37 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 14 Nov 2025 18:44:07 GMT, Kevin Rushforth  wrote:

>> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright header
>
> maven-publish.gradle line 1:
> 
>> 1: /**
> 
> This file should nave a copyright notice, copied from `build.gradle`.

Completely forgot about it. Added!

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1970#discussion_r2528705119

From tsayao at openjdk.org  Fri Nov 14 19:41:04 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Fri, 14 Nov 2025 19:41:04 GMT
Subject: RFR: 8210547: [Linux] Uncontrolled framerate [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <5onp7l_lGYkZuzBSAUtqhdJRvbq-oZoEe3DvWS6Sv14=.6c8682cf-71bd-4518-baa8-144acc8658bd@github.com>

On Thu, 9 Oct 2025 07:40:44 GMT, notzed  wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Call glXSwapIntervalEXT or glXSwapIntervalSGI if not null
>
> Sorry I was wrong and should've tested with more than 1 window.  The change to glXSwapIntervalEXT() doesn't work properly and behaves as if glFinish() is called for each window after glXSwapBuffer(), each causing a new wait for vblank.

>From what I understood, @notzed concluded that the change didn?t work as expected. Please let me know if I misunderstood.

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

PR Comment: https://git.openjdk.org/jfx/pull/1929#issuecomment-3534286860

From angorya at openjdk.org  Fri Nov 14 19:45:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 14 Nov 2025 19:45:22 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v18]
In-Reply-To: 
References: 
Message-ID: 

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

  system

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1944/files
  - new: https://git.openjdk.org/jfx/pull/1944/files/576a8575..e6a2c842

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=17
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=16-17

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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 14 19:53:34 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 14 Nov 2025 19:53:34 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 29 Oct 2025 16:58:05 GMT, Kevin Rushforth  wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8370140.line.separator
>>  - tests
>>  - line endings
>
> Reviewers: @kevinrushforth @jayathirthrao

will update the CSR once you approve the latest change, @kevinrushforth

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

PR Comment: https://git.openjdk.org/jfx/pull/1944#issuecomment-3534334440

From mstrauss at openjdk.org  Fri Nov 14 20:33:38 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 14 Nov 2025 20:33:38 GMT
Subject: Integrated: 8371859: Dialog unnecessarily invokes
 DialogPane.requestLayout()
In-Reply-To: 
References: 
Message-ID: 

On Thu, 13 Nov 2025 21:24:25 GMT, Michael Strau?  wrote:

> The implementation of `Dialog.dialogPane` adds a `ListChangeListener` to `DialogPane.getButtonTypes()`, and calls `DialogPane.requestLayout()` from the listener.
> 
> This is not needed, because the `DialogPane.createButtonBar()` method already specifies that implementers are required to observe changes of `DialogPane.getButtonTypes()`, and relayout the button bar as needed.
> 
> I've added a test to verify that changing the button types indeed requests a layout on the `DialogPane`.

This pull request has now been integrated.

Changeset: 310a260c
Author:    Michael Strau? 
URL:       https://git.openjdk.org/jfx/commit/310a260cbca5c79763caafc30da07af99bd44399
Stats:     18 lines in 2 files changed: 10 ins; 6 del; 2 mod

8371859: Dialog unnecessarily invokes DialogPane.requestLayout()

Reviewed-by: jhendrikx, angorya, mhanl

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

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

From kcr at openjdk.org  Fri Nov 14 20:50:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 14 Nov 2025 20:50:24 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v18]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 14 Nov 2025 19:45:22 GMT, Andy Goryachev  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:
> 
>   system

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1944#pullrequestreview-3466758484

From kcr at openjdk.org  Fri Nov 14 22:08:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 14 Nov 2025 22:08:03 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Nov 2025 03:28:51 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - debug log fix
>  - debug log fix

The debug print logging is OK for debugging purposes to help validate your analysis, as long as you realize that it isn't a substitute for analysis. I do agree with John and Michael that keeping the debug statements isn't needed (or wanted) as part of the product, so I'd like to see it removed once this has proceeded to the point that we are otherwise ready to approve it.

On that note, there are still unanswered questions about the thread safety of the `JFXPanel` class. We do know that, with the exception of setScene (and by extension, getScene()), all _public_ methods are specified to be called on the EDT (the AWT thread). `setScene` checks the thread and always calls `setSceneImpl` on the FX thread to do the "heavy lifting". The question then is around the rest of the implementation methods, some of which are called on the FX thread and some on the EDT.

The NPE being hit by the test program is coming because `setScene(null)`, which is called on the FX app thread, will lead to calling `HostContainer::setEmbeddedStage(null)` and `HostContainer::setEmbeddedScene(null)`. Those methods will set the `stagePeer` and `scenePeer` fields to null. Meanwhile, a repaint operation or a mouse move or ... on the EDT could be trying to access the scene peer.

Locally capturing the `stagePeer` and `scenePeer` fields in methods that are called on the EDT so that it doesn't change out from under us will prevent the NPE, but doesn't guarantee thread safety. In the case where it prevents the NPE, we go one to call a method on a scene peer that is no longer being used. This might be OK or it might not be.

As long as this doesn't make things worse (and I don't see how it would), we could consider taking some variant of your proposed fix as a "workaround" to solve the NPE, but I'd like to understand the problem better. If we do take this fix, we would need to file a follow-on bug to fix the root cause (which could involve some design work to ensure thread safety without introducing deadlocks).

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

PR Review: https://git.openjdk.org/jfx/pull/1968#pullrequestreview-3467010262

From duke at openjdk.org  Fri Nov 14 23:04:01 2025
From: duke at openjdk.org (notzed)
Date: Fri, 14 Nov 2025 23:04:01 GMT
Subject: RFR: 8210547: [Linux] Uncontrolled framerate [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 4 Oct 2025 15:19:32 GMT, Thiago Milczarek Sayao  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

Yeah it doesn't work.  FWIW I've now got an OCP done - it took a couple of weeks so I moved onto other things and haven't revisited it.  I didn't get much traction discussing it on the list either.

I do have a couple of patches which fix the problem but I wanted to do some latency testing to confirm it's further utility - but should I just submit a pull request anyway?

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

PR Comment: https://git.openjdk.org/jfx/pull/1929#issuecomment-3534982943

From mstrauss at openjdk.org  Sat Nov 15 02:00:41 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 15 Nov 2025 02:00:41 GMT
Subject: RFR: 8369836: Update HeaderBar API [v3]
In-Reply-To: 
References: 
Message-ID: <2mMSZ8foAVT6XF9ub642ldTRTuMhbiqT_M-tDuWbUxg=.5dec58d9-0dd0-4f90-a992-07a94fb9621d@github.com>

> The `HeaderBar` control currently has three areas: `leading`, `center`, and `trailing`. Additionally, there's `leftSystemInset` and `rightSystemInset`, which are not RTL adjusted. I've come to the understanding that there is no particularly good reason for this, because every time you would want to use this information for layout purposes, it should also be adjusted for RTL.
> 
> With this in mind, there are three changes for the `HeaderBar` control:
> 1. Rename `leading` to `left`, and `trailing` to `right`, which aligns the terminology with `BorderPane`.
> 2. Adjust `leftSystemInset` and `rightSystemInset` for RTL.
> 3. Make `leftSystemInset`, `rightSystemInset`, and `minSystemHeight` attached properties for `Stage`.
> 
> With this change, the `HeaderBar` control is more semantically consistent and easier to use, and the renamed `left` and `right` areas now show its close relationship with `BorderPane`.

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 four additional commits since the last revision:

 - documentation
 - Merge branch 'master' into headerbar-update
 - Make leftSystemInset/rightSystemInset/minSystemHeight attached properties
 - Update HeaderBar API

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1936/files
  - new: https://git.openjdk.org/jfx/pull/1936/files/da4d219a..026a0d27

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

  Stats: 2901 lines in 104 files changed: 2328 ins; 177 del; 396 mod
  Patch: https://git.openjdk.org/jfx/pull/1936.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1936/head:pull/1936

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

From mstrauss at openjdk.org  Sat Nov 15 02:00:42 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 15 Nov 2025 02:00:42 GMT
Subject: RFR: 8369836: Update HeaderBar API [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 14 Nov 2025 18:23:54 GMT, Andy Goryachev  wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make leftSystemInset/rightSystemInset/minSystemHeight attached properties
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 70:
> 
>> 68:  * 

>> 69:  * {@code HeaderBar} is a layout container that allows applications to place scene graph nodes in three areas:
>> 70:  * {@link #leftProperty() left}, {@link #centerProperty() center}, and {@link #rightProperty() right}.
> 
> perhaps there should be a separate section explaining that the left/right nodes get switched visually in the RTL mode?  And/or mention that "left" really means "leading", and "right" really means "trailing"?

I've added a section to the package documentation, because it is applicable for all layout containers with named regions, not just `HeaderBar`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2529424642

From mstrauss at openjdk.org  Sat Nov 15 02:18:49 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 15 Nov 2025 02:18:49 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED (Preview)
 [v5]
In-Reply-To: 
References: 
Message-ID: 

> 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 pull request now contains nine commits:

 - Merge branch 'master' into feature/extended-dialog
   
   # Conflicts:
   #	modules/javafx.controls/src/test/java/test/javafx/scene/control/DialogPaneTest.java
 - fix incorrect button metrics
 - 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: https://git.openjdk.org/jfx/pull/1943/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1943&range=04
  Stats: 397 lines in 6 files changed: 350 ins; 15 del; 32 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 zelmidaoui at openjdk.org  Sat Nov 15 02:38:09 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Sat, 15 Nov 2025 02:38:09 GMT
Subject: RFR: 8356770: TreeTableView not updated after removing a TreeItem
 with children and adding it to another parent [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 14 Nov 2025 15:56:07 GMT, Ziad El Midaoui  wrote:

>> When a subtree is moved in a `TreeTableView` , the visuals don?t update until a resize or expand/collapse. The `TreeTableViewSkin` only rebuilds cells when the expanded row count changes.
>> This PR makes the skin to detect structural changes on `childrenModificationEvent` using new variable `treeStructureDirty`, and in `updateItemCount()` call `requestRebuildCells()` to refresh the visuals.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor test changes

Changes added thank you for review, I will integrate by tomorrow if no more suggestions.

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

PR Comment: https://git.openjdk.org/jfx/pull/1971#issuecomment-3535435960

From zelmidaoui at openjdk.org  Sat Nov 15 02:38:08 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Sat, 15 Nov 2025 02:38:08 GMT
Subject: RFR: 8356770: TreeTableView not updated after removing a TreeItem
 with children and adding it to another parent [v4]
In-Reply-To: 
References: 
Message-ID: 

> When a subtree is moved in a `TreeTableView` , the visuals don?t update until a resize or expand/collapse. The `TreeTableViewSkin` only rebuilds cells when the expanded row count changes.
> This PR makes the skin to detect structural changes on `childrenModificationEvent` using new variable `treeStructureDirty`, and in `updateItemCount()` call `requestRebuildCells()` to refresh the visuals.

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  minor change

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1971/files
  - new: https://git.openjdk.org/jfx/pull/1971/files/58f9f4e7..e160a15a

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

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

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

From mhanl at openjdk.org  Sat Nov 15 08:54:35 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 15 Nov 2025 08:54:35 GMT
Subject: RFR: 8356770: TreeTableView not updated after removing a TreeItem
 with children and adding it to another parent [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 15 Nov 2025 02:38:08 GMT, Ziad El Midaoui  wrote:

>> When a subtree is moved in a `TreeTableView` , the visuals don?t update until a resize or expand/collapse. The `TreeTableViewSkin` only rebuilds cells when the expanded row count changes.
>> This PR makes the skin to detect structural changes on `childrenModificationEvent` using new variable `treeStructureDirty`, and in `updateItemCount()` call `requestRebuildCells()` to refresh the visuals.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor change

Marked as reviewed by mhanl (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1971#pullrequestreview-3467867231

From nlisker at gmail.com  Sat Nov 15 15:35:00 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Sat, 15 Nov 2025 17:35:00 +0200
Subject: JavaFX Direct3D 12 - Call for performance testing help
In-Reply-To: 
References: 
 
Message-ID: 

I'm getting an error that "Microsoft Visual
Studio/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64/cl.exe"
can't be found. Indeed, I have a newer version. Do I need to downgrade to
that specific one?

On Fri, Nov 14, 2025 at 4:10?PM Lukasz Kostyra 
wrote:

> Hello all,
>
>
>
> I got feedback on the previous call for performance testing email that,
> instead of using the Bash test script on Windows (and hoping you have
> Cygwin/MINGW installed) it would be easier to integrate testing and CSV
> output functionality into RenderPerfTest. I made those changes and they are
> now available on jfx-sandbox direct3d12 branch (you WON?T find those on
> main repo yet):
> https://github.com/openjdk/jfx-sandbox/tree/direct3d12/tests/performance/animation/RenderPerfTest/src/renderperf
>
> Any feedback regarding RenderPerfTest will be updated on that branch
> automatically, so it?s indeed a better solution if there?s more feedback to
> it :)
>
>
> *New steps for running tests:*
>
>    1. Download RenderPerfTest from above link (has to be jfx-sandbox
>    repo, direct3d12 branch) - best to download the entire ?renderperf? folder
>    as ZIP as it contains extra resources needed for the test app
>    2. Get JavaFX Direct3D 12 build - either download the EA2 SDK from [
>    https://jdk.java.net/javafxdirect3d12/ ] or build it from scratch from
>    direct3d12 [ https://github.com/openjdk/jfx-sandbox/tree/direct3d12 ]
>    branch (make sure to *build with -PCONF=Release*; at the time of
>    writing this email there is no functional difference between the sandbox
>    repo and the EA2 build).
>    3. RenderPerf can be run with (underlined parts you need to fill in
>    yourself):
>
> *java --upgrade-module-path="/lib"
>    --add-modules=javafx.base,javafx.controls,javafx.graphics,jdk.jsobject,javafx.media
>    --enable-native-access=javafx.graphics -Dprism.order=
>    renderperf/RenderPerfTest.java --output-csv -r  *Where:
>    *    * -  path to directory where JavaFX SDK is
>    located (has to be where JavaFX bin and lib folders reside)
>    *     *-  short-hand for which Prism backend to use
>        **  - how many times each test case should run; RenderPerf will
>    average FPS results from these runs
>
>
>
>    4. Running RenderPerf like above will produce
>    *RenderPerf_results---

> 207:  * For layout containers, the layout orientation determines the visual order of their children. If a layout container
> 208:  * has named areas, the names always retain their default meaning. For example, the {@code left} and {@code right}

It might be just me, but I still find this explanation very confusing (what is the default meaning of left?).

Could we just say that for historical reasons, "left" and "right" in reality mean "leading" and "trailing", or maybe that in the RTL mode the left/right are swapped, with the "left" nodes appearing on the leading (visually right) side, and the "right" ones are on the trailing (visually left) side?

Also, do you think we should explicitly mention entities where this logic applies  (`BorderPane`, `HeaderBar`)?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2535367949

From kcr at openjdk.org  Mon Nov 17 21:22:34 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 17 Nov 2025 21:22:34 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 17 Nov 2025 16:35:50 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug, store transient var in temp var in EDT methods

> Ideally, this component should be redesigned to ensure proper communication between threads.

That would be the best long-term solution, but that would be a large effort.

> I wonder if we are going to continue chasing the issues until we do it right.

Possibly. This gets back to the question I asked earlier: is the approach proposed in this PR a reasonable workaround that we might employ until such time as we "do it right"? If so, then we might continue down this path, addressing all outstanding comments, and making sure that we locally capture the scene/stage peer in all places where they are accessed from the EDT.

> What do you think of the following idea:
> 
> 1. rename all the variables to have `fx` and `edt` (or `sw` ?) prefix to clearly indicate which thread controls the variable (sets, mutates, etc.)
> 2. similarly rename the methods that can be renamed, and add comments to methods that cannot be renamed

I think adding comments as to which methods are called on which threads would be very useful (I wouldn't bother renaming any of the methods, since many/most of the interesting ones can't be). Similarly, adding comments to the fields as to which are modified on which thread, would be useful; I guess there might be some value in renaming the fields, but let's at least document this clearly.

> 3. whenever the fields are read in a wrong thread, make a local copy (and declare the field as `volatile`)

This is basically what this PR attempts to do. It is a workaround for the lack of a proper MT solution, but it might very well be "good enough" until we can get a proper MT solution.

> and maybe even go a bit further, instead of suggestion in 3), we explicitly disallow accessing of fields from a wrong thread, and use the message passing via Platform.runLater() and EventQueue.invokeLater() ?

I don't think this is practical, or even desired. There are other ways to ensure that we consistently communicate values between the threads, possibly synchronizing operations at the right level of granularity (not just when you read or write the value).

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

PR Comment: https://git.openjdk.org/jfx/pull/1968#issuecomment-3543886235

From mstrauss at openjdk.org  Mon Nov 17 21:42:36 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 17 Nov 2025 21:42:36 GMT
Subject: RFR: 8369836: Update HeaderBar API [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <7mnZxgTpgOMy3jL3WFdZNBQ7CZMX13Spge5qeHh_HFI=.1634e2c8-282c-4a7f-9e33-5acea6471526@github.com>

On Thu, 23 Oct 2025 18:04:28 GMT, Kevin Rushforth  wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make leftSystemInset/rightSystemInset/minSystemHeight attached properties
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 888:
> 
>> 886:             this.leftSystemInset = new ReadOnlyObjectWrapper<>(stage, "HeaderBar.leftSystemInset", EMPTY);
>> 887:             this.rightSystemInset = new ReadOnlyObjectWrapper<>(stage, "HeaderBar.rightSystemInset", EMPTY);
>> 888:             this.minSystemHeight = new ReadOnlyDoubleWrapper(stage, "HeaderBar.minSystemHeight");
> 
> Should the classname prefix in the property `name` be fully qualified? If it were, then a utility could find the corresponding method(s) from the bean using the convention that if a name contains a `.`, it is an attached property with the bean being an argument to the named (static) method.

This is pending a discussion on the [mailing list](https://mail.openjdk.org/pipermail/openjfx-dev/2025-November/057431.html).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2535591882

From angorya at openjdk.org  Mon Nov 17 23:48:29 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 17 Nov 2025 23:48:29 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v2]
In-Reply-To: <6xWWnVedU5-eehKPlHbORXT3dxtIoP7WFyvqQSmyWbk=.048ed0ae-384f-4ffc-9b78-5872fe7b91db@github.com>
References: 
 <6xWWnVedU5-eehKPlHbORXT3dxtIoP7WFyvqQSmyWbk=.048ed0ae-384f-4ffc-9b78-5872fe7b91db@github.com>
Message-ID: 

On Sat, 30 Aug 2025 20:11:36 GMT, Nir Lisker  wrote:

>> Refactoring of all `StringConverter`s and their tests. General notes:
>> * The documentation language has been unified and `null` parameter rules have been documented.
>> *  Tests have been cleaned up in the vein of https://github.com/openjdk/jfx/pull/1759 and unneeded `@BeforeAll`s were removed.
>> * Internal fields were made `private final` to guarantee immutability.
>> 
>>  Incremental commits are provided for easier reviewing:
>> 
>> ### Parent classes
>> * `StringConverter`: updated documentation
>> * `BaseStringConverter`: a new internal class that implements repeated code from converter implementations and serves as an intermediate superclass. It does empty and `null` string checks that are handled uniformly, except for `DefaultStringConverter`, which has a different formatting mechanism.
>> 
>> ### Primitive-related converters
>> * All primitive (wrapper) converters also document their formatting and parsing mechanism since these are "well-established".
>> 
>> ### Format converter
>> * Checked for `null` during constriction time to avoid runtime NPEs.
>> * There is no test class for this converter. A followup might be desirable.
>> * A followup should deprecate for removal `protected Format getFormat()` (as in [JDK-8314597](https://bugs.openjdk.org/browse/JDK-8314597) and [JDK-8260475](https://bugs.openjdk.org/browse/JDK-8260475)).
>> 
>> ### Number and subclasses converters
>> * The intermediate `locale` and `pattern` fields were removed (along with their tests). The class generated a new formatter from these on each call. This only makes sense for mutable fields where the resulting formatter can change, but here the formatter can be computed once on construction and stored.
>> * The only difference between these classes is a single method for creating a format from a `null` pattern, which was encapsulated in the `getSpecializedNumberFormat` method.
>> * The terminally deprecated `protected NumberFormat getNumberFormat()` was removed. Can be split to its own issue if preferred. In my opinion, it shouldn't exist even internally since testing the internal formatter doesn't help. The only tests here should be for to/from strings, and these are lacking. A followup can be filed for adding more conversion tests.
>> 
>> ### Date/Time converters
>> * Added a documentation note advising users to use the `java.time` classes instead of the old `Date` class.
>> * As with Number converters, only the `dateFormat` field was kept, which is created once on construction instead of on each...
>
> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review comments 2
>  - review comments 1

I think the change makes sense, despite a somewhat large footprint.

Requesting the following changes:
- sync up with the latest master
- revert javadoc markdown

modules/javafx.base/src/main/java/javafx/util/StringConverter.java line 38:

> 36: /// - Except for `DefaultStringConverter`, formatting `null` returns an empty string, otherwise the type's `toString` is
> 37: /// used if it is suitable; parsing `null` or an empty string returns `null`.
> 38: /// - Immutable (the same converter can be reused).

Is this true? 
I recall some formatters having a state, but I don't remember which...

modules/javafx.base/src/main/java/javafx/util/converter/BaseStringConverter.java line 30:

> 28: import javafx.util.StringConverter;
> 29: 
> 30: /// A base class containing common implementations for `StringConverter`s as noted in the @implNote of `StringConverter`.

In light of possible backporting, it's been decided earlier not to use markdown comments.

modules/javafx.base/src/main/java/javafx/util/converter/DateStringConverter.java line 99:

> 97: 
> 98:     @Override
> 99:     DateFormat getSpecialziedDateFormat(int dateStyle, int timeStyle, Locale locale) {

spelling

modules/javafx.base/src/main/java/javafx/util/converter/DateTimeStringConverter.java line 115:

> 113:                 getSpecialziedDateFormat(dateStyle, timeStyle, locale) :
> 114:                 new SimpleDateFormat(pattern, locale);
> 115:         dateFormat.setLenient(false);

Would setting `lenient=false` constitute a change in functionality?

modules/javafx.base/src/main/java/javafx/util/converter/TimeStringConverter.java line 101:

> 99: 
> 100:     @Override
> 101:     DateFormat getSpecialziedDateFormat(int dateStyle, int timeStyle, Locale locale) {

spelling

modules/javafx.base/src/test/java/test/javafx/util/converter/CurrencyStringConverterTest.java line 58:

> 56:     void testConstructor_locale() {
> 57:         NumberFormat numberFormat = NumberFormat.getCurrencyInstance(Locale.CANADA);
> 58: 

very minor: extra newlines?

modules/javafx.base/src/test/java/test/javafx/util/converter/NumberStringConverterTest.java line 58:

> 56:     void testConstructor_locale() {
> 57:         NumberFormat numberFormat = NumberFormat.getNumberInstance(Locale.CANADA);
> 58: 

minor: weird extra newlines

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

Changes requested by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1880#pullrequestreview-3474802047
PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2535762634
PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2535714830
PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2535737237
PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2535744617
PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2535760564
PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2535779020
PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2535796857

From angorya at openjdk.org  Mon Nov 17 23:48:31 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 17 Nov 2025 23:48:31 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 25 Aug 2025 11:29:09 GMT, Nir Lisker  wrote:

>> modules/javafx.base/src/main/java/javafx/util/converter/BaseTemporalStringConverter.java line 50:
>> 
>>> 48:     protected BaseTemporalStringConverter(FormatStyle dateStyle, FormatStyle timeStyle, Locale locale, Chronology chrono) {
>>> 49:         locale = Objects.requireNonNullElse(locale, DEFAULT_LOCALE);
>>> 50:         chrono = Objects.requireNonNullElse(chrono, DEFAULT_CHRONO);
>> 
>> Parameter reassignment here.  It all looks like fields, but only the last two are.  Fields could be prefixed with `this.` to make this clearer, but IMHO parameter assignment is always bad.
>
> IDEs can show fields and variables differently so it's very easy to discern. Perhaps it depends on your text editor settings. Adding "this" tends to be more noise than it's worth in my opinion. Can change if there's an agreement.

I second John's suggestion with `this.`.  It matters when refactoring, even with an IDE.

>> modules/javafx.base/src/main/java/javafx/util/converter/CurrencyStringConverter.java line 39:
>> 
>>> 37:     public CurrencyStringConverter() {
>>> 38:         super();
>>> 39:     }
>> 
>> `super()` here is just noise
>
> I opted to explicitly use `super` in these places for uniformity with the other constructors as it can help understand which constructor is called from where. The "constructor jungle" in these classes made me do things I don't normally do. In `LocalDateStringConverter`, for example, the constructor goes through a `this` constructor instead of `super`, so it can be confusing. Can remove anyway.

Second John's suggestion about `super()` - there is no need.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2535715860
PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2535733547

From angorya at openjdk.org  Mon Nov 17 23:48:33 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 17 Nov 2025 23:48:33 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 24 Aug 2025 20:39:46 GMT, John Hendrikx  wrote:

>> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review comments 2
>>  - review comments 1
>
> modules/javafx.base/src/main/java/javafx/util/converter/BaseTemporalStringConverter.java line 86:
> 
>> 84:                             .withChronology(chrono)
>> 85:                             .withDecimalStyle(DecimalStyle.of(locale));
>> 86:     }
> 
> Weird level of indent, perhaps use 4 or 8?

why 8?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2535721058

From kcr at openjdk.org  Tue Nov 18 00:04:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 18 Nov 2025 00:04:03 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v2]
In-Reply-To: 
References: 
 <6xWWnVedU5-eehKPlHbORXT3dxtIoP7WFyvqQSmyWbk=.048ed0ae-384f-4ffc-9b78-5872fe7b91db@github.com>
 
Message-ID: <2w9h-vPFy-b-hkJDsK4m4pHPH4jJg00nIwtCpTtc1aE=.45c75cd5-9b9e-4f1c-b089-a4f41c79083b@github.com>

On Mon, 17 Nov 2025 22:34:03 GMT, Andy Goryachev  wrote:

>> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review comments 2
>>  - review comments 1
>
> modules/javafx.base/src/main/java/javafx/util/converter/BaseStringConverter.java line 30:
> 
>> 28: import javafx.util.StringConverter;
>> 29: 
>> 30: /// A base class containing common implementations for `StringConverter`s as noted in the @implNote of `StringConverter`.
> 
> In light of possible backporting, it's been decided earlier not to use markdown comments.

In general, yes, but I note that this is a pretty major refactoring where most of the javadocs were redone, and all of them now use markdown. This is a case where we could consider allowing them. I don't have a strong opinion either way, and likely won't have time to review this one for a while...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2535870408

From kcr at openjdk.org  Tue Nov 18 00:07:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 18 Nov 2025 00:07:44 GMT
Subject: RFR: 8369836: Update HeaderBar API [v3]
In-Reply-To: 
References: 
 <2mMSZ8foAVT6XF9ub642ldTRTuMhbiqT_M-tDuWbUxg=.5dec58d9-0dd0-4f90-a992-07a94fb9621d@github.com>
 
Message-ID: 

On Mon, 17 Nov 2025 20:05:00 GMT, Andy Goryachev  wrote:

>> 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 four additional commits since the last revision:
>> 
>>  - documentation
>>  - Merge branch 'master' into headerbar-update
>>  - Make leftSystemInset/rightSystemInset/minSystemHeight attached properties
>>  - Update HeaderBar API
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/package-info.java line 208:
> 
>> 206:  * 

>> 207:  * For layout containers, the layout orientation determines the visual order of their children. If a layout container
>> 208:  * has named areas, the names always retain their default meaning. For example, the {@code left} and {@code right}
> 
> It might be just me, but I still find this explanation very confusing (what is the default meaning of left?).
> 
> Could we just say that for historical reasons, "left" and "right" in reality mean "leading" and "trailing", or maybe that in the RTL mode the left/right are swapped, with the "left" nodes appearing on the leading (visually right) side, and the "right" ones are on the trailing (visually left) side?
> 
> Also, do you think we should explicitly mention entities where this logic applies  (`BorderPane`, `HeaderBar`)?

I'll take a look at this as well.

One thing I do note is that it might be helpful if this doc clarification had a separate doc issue to track it -- even if it goes in as part of this PR -- since it is independent from what is otherwise a preview feature.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2535876092

From kcr at openjdk.org  Tue Nov 18 00:07:42 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 18 Nov 2025 00:07:42 GMT
Subject: RFR: 8369836: Update HeaderBar API [v2]
In-Reply-To: <7mnZxgTpgOMy3jL3WFdZNBQ7CZMX13Spge5qeHh_HFI=.1634e2c8-282c-4a7f-9e33-5acea6471526@github.com>
References: 
 
 
 <7mnZxgTpgOMy3jL3WFdZNBQ7CZMX13Spge5qeHh_HFI=.1634e2c8-282c-4a7f-9e33-5acea6471526@github.com>
Message-ID: 

On Mon, 17 Nov 2025 21:39:44 GMT, Michael Strau?  wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 888:
>> 
>>> 886:             this.leftSystemInset = new ReadOnlyObjectWrapper<>(stage, "HeaderBar.leftSystemInset", EMPTY);
>>> 887:             this.rightSystemInset = new ReadOnlyObjectWrapper<>(stage, "HeaderBar.rightSystemInset", EMPTY);
>>> 888:             this.minSystemHeight = new ReadOnlyDoubleWrapper(stage, "HeaderBar.minSystemHeight");
>> 
>> Should the classname prefix in the property `name` be fully qualified? If it were, then a utility could find the corresponding method(s) from the bean using the convention that if a name contains a `.`, it is an attached property with the bean being an argument to the named (static) method.
>
> This is pending a discussion on the [mailing list](https://mail.openjdk.org/pipermail/openjfx-dev/2025-November/057431.html).

Thanks. I saw that, but hadn't had time to respond. I'll do that in the next day or two.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2535872208

From jdv at openjdk.org  Tue Nov 18 04:18:36 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 18 Nov 2025 04:18:36 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v18]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 14 Nov 2025 19:45:22 GMT, Andy Goryachev  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:
> 
>   system

Marked as reviewed by jdv (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1944#pullrequestreview-3475393069

From arapte at openjdk.org  Tue Nov 18 09:20:10 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 18 Nov 2025 09:20:10 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 16 Nov 2025 11:14:10 GMT, Marius Hanl  wrote:

>> This PR splits the maven publishing logic into an own file, `maven-publish.gradle`, that is next to the root `build.gradle`.
>> 
>> The `build.gradle` will apply the `maven-publish.gradle`. The `maven-publish.gradle` will then configure the Maven related properties and register all modules for publication.
>> 
>> This way, we decoupled the logic that much, the only things we need to do:
>> - apply from `maven-publish.gradle`
>> - Call `configureMavenPublication` later in the build chain.
>> 
>> To better understand the context, this is the commit where the whole Maven Publishing logic was introduced. I moved all of that logic out of the main `build.gradle`: 5a18677f
>> 
>> This will reduce the size by ~170 lines for the `build.gradle`.
>> 
>> Tested with:
>> - `./gradlew -PMAVEN_PUBLISH=true -PMAVEN_VERSION=custom publishToMavenLocal`
>> - `./gradlew -PMAVEN_PUBLISH=true publishToMavenLocal`
>> - `./gradlew -PMAVEN_PUBLISH=true -PMILESTONE_FCS=true publishToMavenLocal`
>> 
>> Everything still works:
>> -> Example: javafx.base from the local .m2 repository
>> image
>> 
>> I think this is a good step and an easy way to split out functionality without blowing things up. We might want to do that for other parts as well.
>> 
>> Note: I also fixed the deprecated `buildDir`, the deprecated `project.task` method and 2 warnings where it seems like he might not be able to infer the type (changing `def` to the actual type). 
>> -> The file is completely green, no warnings or deprecations.
>> Note2: I did a small improvement to the `addMavenPublication` method. It is now more 'typesafe', e.g. projects must be passed in directly, not as String. If a project does not exist, the build will fail with an exception.
>
> 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jfx into 833146-mvn-publish
>  - remove print
>  - Use projects directly
>  - Further reduce coupling between main build.gradle and maven-publish.gradle
>  - Move MAVEN_GROUP_ID and fail() over to maven-publish.gradle
>  - Copyright header
>  - 8333146: Move maven publication logic from build.gradle

Could you please verify this observations: 
1. With this change the jar files are generated without class files i.e. sdk is not built. Use command :
`gradle -PMAVEN_PUBLISH=true publishToMavenLocal`. 
Note that default task `sdk` is not specified in the command.
The command completes in just a few seconds (~20 seconds), whereas the `sdk` task can take a few minutes
Attaching the screenshot, please observe that size of jar files are just a few 100 bytes. They should be in KBs.

Screenshot 2025-11-18 at 14 34 01




2. If `sdk` task is added to the above command as : `gradle -PMAVEN_PUBLISH=true publishToMavenLocal sdk`
then the build fails with below error:


> Task :base:buildModuleMac FAILED

[Incubating] Problems report is available at: build/reports/problems/problems-report.html

FAILURE: Build failed with an exception.

* What went wrong:
A problem was found with the configuration of task ':base:buildModuleMac' (type 'Copy').
  - Gradle detected a problem with the following location: 'modules/javafx.base/build/module-classes'.
    
    Reason: Task ':base:modularPublicationJarMac' uses this output of task ':base:buildModuleMac' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
    
    Possible solutions:
      1. Declare task ':base:buildModuleMac' as an input of ':base:modularPublicationJarMac'.
      2. Declare an explicit dependency on ':base:buildModuleMac' from ':base:modularPublicationJarMac' using Task#dependsOn.
      3. Declare an explicit dependency on ':base:buildModuleMac' from ':base:modularPublicationJarMac' using Task#mustRunAfter.
    
    For more information, please refer to https://docs.gradle.org/9.2.0/userguide/validation_problems.html#implicit_dependency in the Gradle documentation.

* Try:
> Declare task ':base:buildModuleMac' as an input of ':base:modularPublicationJarMac'
> Declare an explicit dependency on ':base:buildModuleMac' from ':base:modularPublicationJarMac' using Task#dependsOn
> Declare an explicit dependency on ':base:buildModuleMac' from ':base:modularPublicationJarMac' using Task#mustRunAfter
> Run with --scan to generate a Build Scan (powered by Develocity).

Deprecated Gradle features were used in this build, making it incompatible with Gradle 10.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/9.2.0/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD FAILED in 1m 15s

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

PR Comment: https://git.openjdk.org/jfx/pull/1970#issuecomment-3546385133

From fkirmaier at openjdk.org  Tue Nov 18 09:52:04 2025
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Tue, 18 Nov 2025 09:52:04 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Oct 2025 07:44:36 GMT, Pabulaner IV  wrote:

>> This pull request fixes the system menu bar on MacOS when combining windows of Swing and JavaFX.
>> 
>> # Behavior before
>> 
>> If for some reason You needed to initialize AWT before JavaFX and You wanted to install the system menu bar from the JavaFX side, this wasn't possible. This issue is persistent even when You didn't open a Swing window. 
>> 
>> One scenario where this kind of issue happens is when You use install4j (see https://www.ej-technologies.com/install4j). In this case AWT is initialized by install4j and therefore You can't use the JavaFX system menu bar anymore.
>> 
>> 
>> # Behavior after
>> 
>> The fix allows JavaFX to install a system menu bar even if it is initialized after AWT. This is achieved by only changing code inside JavaFX. Each JavaFX window stores the previously installed menu bar when gaining focus and will restore this menu bar if the focus was lost. This only happens if the system menu bar installed by the JavaFX window is still unchanged.
>> 
>> 
>> # Tests
>> 
>> This PR introduces tests for the system menu bar in addition to verifying its own behavior / changes. The tests include single- and multi-window tests while interacting with Swing. The tests ensure that the menu bar stays the same for each window, no matter how You switch focus between them.
>> 
>> 
>> # Additional benifits 
>> 
>> This fix is not specifically for AWT, but allows JavaFX to interact much more compatibly with other frameworks that make use of the system menu bar.
>> 
>> 
>> # Review from AWT
>> 
>> In the previous PR related to this one, the comment was made that the folks from AWT should take a look at this fix. It would be great and much appreciated if someone could initiate it.
>> 
>> 
>> # Add disable flag?
>> 
>> We could also add a flag to prevent JavaFX from installing a system menu bar for users who have found other fixes for their projects / setups. This could be used to restore the previous behavior when AWT is initialized first.
>> 
>> 
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX

If we can't run the Tests on the CI, i think we should at least keep them - because they are really valuable for every person working on this topic in the future.

Anything left for us to do?

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3546538487

From mhanl at openjdk.org  Tue Nov 18 10:13:34 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 18 Nov 2025 10:13:34 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v4]
In-Reply-To: 
References: 
 
 
Message-ID: <6IBmyrou6emv-ILaXDfghhcOh0PwpoRnLf02gzdedGU=.7e071b83-38b0-4afc-a697-02187632af27@github.com>

On Tue, 18 Nov 2025 09:17:21 GMT, Ambarish Rapte  wrote:

> Could you please verify this observations:
> 
> 1. With this change the jar files are generated without class files i.e. sdk is not built. Use command :
>    `gradle -PMAVEN_PUBLISH=true publishToMavenLocal`.
>    Note that default task `sdk` is not specified in the command.
>    The command completes in just a few seconds (~20 seconds), whereas the `sdk` task can take a few minutes
>    Attaching the screenshot, please observe that size of jar files are just a few 100 bytes. They should be in KBs.

Thanks. I can reproduce this! I always built the sdk first and then run the publishing. But you are right, this should work together as well. My guess is that the maven task need to depend on the build task, that should fix both problems. Will do some testing and report back.

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

PR Comment: https://git.openjdk.org/jfx/pull/1970#issuecomment-3546657279

From mhanl at openjdk.org  Tue Nov 18 11:15:25 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 18 Nov 2025 11:15:25 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v5]
In-Reply-To: 
References: 
Message-ID: 

> This PR splits the maven publishing logic into an own file, `maven-publish.gradle`, that is next to the root `build.gradle`.
> 
> The `build.gradle` will apply the `maven-publish.gradle`. The `maven-publish.gradle` will then configure the Maven related properties and register all modules for publication.
> 
> This way, we decoupled the logic that much, the only things we need to do:
> - apply from `maven-publish.gradle`
> - Call `configureMavenPublication` later in the build chain.
> 
> To better understand the context, this is the commit where the whole Maven Publishing logic was introduced. I moved all of that logic out of the main `build.gradle`: 5a18677f
> 
> This will reduce the size by ~170 lines for the `build.gradle`.
> 
> Tested with:
> - `./gradlew -PMAVEN_PUBLISH=true -PMAVEN_VERSION=custom publishToMavenLocal`
> - `./gradlew -PMAVEN_PUBLISH=true publishToMavenLocal`
> - `./gradlew -PMAVEN_PUBLISH=true -PMILESTONE_FCS=true publishToMavenLocal`
> 
> Everything still works:
> -> Example: javafx.base from the local .m2 repository
> image
> 
> I think this is a good step and an easy way to split out functionality without blowing things up. We might want to do that for other parts as well.
> 
> Note: I also fixed the deprecated `buildDir`, the deprecated `project.task` method and 2 warnings where it seems like he might not be able to infer the type (changing `def` to the actual type). 
> -> The file is completely green, no warnings or deprecations.
> Note2: I did a small improvement to the `addMavenPublication` method. It is now more 'typesafe', e.g. projects must be passed in directly, not as String. If a project does not exist, the build will fail with an exception.

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

  Depend maven publishing on the build modules task

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1970/files
  - new: https://git.openjdk.org/jfx/pull/1970/files/ea0b427c..6d8e7282

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

  Stats: 18 lines in 2 files changed: 7 ins; 8 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1970.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1970/head:pull/1970

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

From arapte at openjdk.org  Tue Nov 18 11:26:38 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 18 Nov 2025 11:26:38 GMT
Subject: RFR: 8371069: RichTextArea: caret with inline node
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Nov 2025 00:20:45 GMT, Andy Goryachev  wrote:

> Original bug referred to RichTextArea, however the root cause of the issue is the incorrect computation of the caret shape around an embedded `Node` in the `TextFlow`.

lgtm...

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1974#pullrequestreview-3477193170

From mhanl at openjdk.org  Tue Nov 18 11:30:54 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 18 Nov 2025 11:30:54 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v6]
In-Reply-To: 
References: 
Message-ID: 

> This PR splits the maven publishing logic into an own file, `maven-publish.gradle`, that is next to the root `build.gradle`.
> 
> The `build.gradle` will apply the `maven-publish.gradle`. The `maven-publish.gradle` will then configure the Maven related properties and register all modules for publication.
> 
> This way, we decoupled the logic that much, the only things we need to do:
> - apply from `maven-publish.gradle`
> - Call `configureMavenPublication` later in the build chain.
> 
> To better understand the context, this is the commit where the whole Maven Publishing logic was introduced. I moved all of that logic out of the main `build.gradle`: 5a18677f
> 
> This will reduce the size by ~170 lines for the `build.gradle`.
> 
> Tested with:
> - `./gradlew -PMAVEN_PUBLISH=true -PMAVEN_VERSION=custom publishToMavenLocal`
> - `./gradlew -PMAVEN_PUBLISH=true publishToMavenLocal`
> - `./gradlew -PMAVEN_PUBLISH=true -PMILESTONE_FCS=true publishToMavenLocal`
> 
> Everything still works:
> -> Example: javafx.base from the local .m2 repository
> image
> 
> I think this is a good step and an easy way to split out functionality without blowing things up. We might want to do that for other parts as well.
> 
> Note: I also fixed the deprecated `buildDir`, the deprecated `project.task` method and 2 warnings where it seems like he might not be able to infer the type (changing `def` to the actual type). 
> -> The file is completely green, no warnings or deprecations.
> Note2: I did a small improvement to the `addMavenPublication` method. It is now more 'typesafe', e.g. projects must be passed in directly, not as String. If a project does not exist, the build will fail with an exception.

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

  Use defineProperty and fail method from default build.gradle

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1970/files
  - new: https://git.openjdk.org/jfx/pull/1970/files/6d8e7282..74a9d1f6

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

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

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

From mhanl at openjdk.org  Tue Nov 18 11:43:18 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 18 Nov 2025 11:43:18 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 18 Nov 2025 11:30:54 GMT, Marius Hanl  wrote:

>> This PR splits the maven publishing logic into an own file, `maven-publish.gradle`, that is next to the root `build.gradle`.
>> 
>> The `build.gradle` will apply the `maven-publish.gradle`. The `maven-publish.gradle` will then configure the Maven related properties and register all modules for publication.
>> 
>> This way, we decoupled the logic that much, the only things we need to do:
>> - apply from `maven-publish.gradle`
>> - Call `configureMavenPublication` later in the build chain.
>> 
>> To better understand the context, this is the commit where the whole Maven Publishing logic was introduced. I moved all of that logic out of the main `build.gradle`: 5a18677f
>> 
>> This will reduce the size by ~170 lines for the `build.gradle`.
>> 
>> Tested with:
>> - `./gradlew -PMAVEN_PUBLISH=true -PMAVEN_VERSION=custom publishToMavenLocal`
>> - `./gradlew -PMAVEN_PUBLISH=true publishToMavenLocal`
>> - `./gradlew -PMAVEN_PUBLISH=true -PMILESTONE_FCS=true publishToMavenLocal`
>> 
>> Everything still works:
>> -> Example: javafx.base from the local .m2 repository
>> image
>> 
>> I think this is a good step and an easy way to split out functionality without blowing things up. We might want to do that for other parts as well.
>> 
>> Note: I also fixed the deprecated `buildDir`, the deprecated `project.task` method and 2 warnings where it seems like he might not be able to infer the type (changing `def` to the actual type). 
>> -> The file is completely green, no warnings or deprecations.
>> Note2: I did a small improvement to the `addMavenPublication` method. It is now more 'typesafe', e.g. projects must be passed in directly, not as String. If a project does not exist, the build will fail with an exception.
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use defineProperty and fail method from default build.gradle

Both issues should be fixed now. It really was just a matter of depending the maven publication task on the `buildModulesTask`, which makes the most sense to me.

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

PR Comment: https://git.openjdk.org/jfx/pull/1970#issuecomment-3547179237

From psadhukhan at openjdk.org  Tue Nov 18 13:24:31 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 18 Nov 2025 13:24:31 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v5]
In-Reply-To: 
References: 
Message-ID: <6Qlc-NKNx94Dp9zVd5KXpAqJNryB4QKt9y21PSrc4UE=.924386db-11d1-4201-8153-060e07fbbbc6@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

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

  temp-var handling in few other methods

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1968/files
  - new: https://git.openjdk.org/jfx/pull/1968/files/7bf8a91e..fc830a7e

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

  Stats: 70 lines in 1 file changed: 58 ins; 0 del; 12 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 psadhukhan at openjdk.org  Tue Nov 18 13:24:33 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 18 Nov 2025 13:24:33 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v4]
In-Reply-To: 
References: 
 
Message-ID: <1TOk6f7MlfNkId1bD9jKJZVW_ItLzjCcaZhX0K3BBSA=.45a4dd65-cc2c-42cd-8049-97f24e67eca2@github.com>

On Mon, 17 Nov 2025 16:35:50 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug, store transient var in temp var in EDT methods

Modified PR to add comments to specify which methods and fields are called on which threads

> > Ideally, this component should be redesigned to ensure proper communication between threads.
> 
> That would be the best long-term solution, but that would be a large effort.

Synchronizing at atomic granularity needs to be done but many methods internally context switch to other thread which can be problematic for this so I have followed the present approach..

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

PR Comment: https://git.openjdk.org/jfx/pull/1968#issuecomment-3547632132

From kevin.rushforth at oracle.com  Tue Nov 18 14:39:00 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 18 Nov 2025 06:39:00 -0800
Subject: Proposed schedule for JavaFX 26
Message-ID: 

Here is the proposed schedule for JavaFX 26:

RDP1: Jan 15, 2026 (aka ?feature freeze?)
RDP2: Feb 5, 2026
RC: Feb 26, 2026 (aka ?code freeze?)
GA: Mar 17, 2026

We will fork a jfx26 stabilization branch at RDP1.

The start of RDP1, the start of RDP2, and the code freeze will be 16:00 
UTC on the respective dates.

Please let Johan or me know if you have any questions.

-- Kevin


From angorya at openjdk.org  Tue Nov 18 15:04:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 18 Nov 2025 15:04:25 GMT
Subject: Integrated: 8370140: RichTextArea: line endings
In-Reply-To: 
References: 
Message-ID: 

On Wed, 22 Oct 2025 20:35:36 GMT, Andy Goryachev  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.

This pull request has now been integrated.

Changeset: 7862ab82
Author:    Andy Goryachev 
URL:       https://git.openjdk.org/jfx/commit/7862ab8281d846d5490d04b7fb2d07d1151bd015
Stats:     301 lines in 13 files changed: 272 ins; 11 del; 18 mod

8370140: RichTextArea: line endings

Reviewed-by: jdv, kcr

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

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

From angorya at openjdk.org  Tue Nov 18 15:21:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 18 Nov 2025 15:21:24 GMT
Subject: RFR: 8371069: RichTextArea: caret with inline node
In-Reply-To: 
References: 
Message-ID: <9kU3e9n69aLK_XlT8DfxfalJYTR81WTv8i1Slvv-SQM=.ef8079f0-ee82-4dc5-8132-be68fca7d4da@github.com>

On Fri, 14 Nov 2025 00:20:45 GMT, Andy Goryachev  wrote:

> Original bug referred to RichTextArea, however the root cause of the issue is the incorrect computation of the caret shape around an embedded `Node` in the `TextFlow`.

thank you!

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

PR Comment: https://git.openjdk.org/jfx/pull/1974#issuecomment-3548121162

From angorya at openjdk.org  Tue Nov 18 15:21:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 18 Nov 2025 15:21:25 GMT
Subject: Integrated: 8371069: RichTextArea: caret with inline node
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Nov 2025 00:20:45 GMT, Andy Goryachev  wrote:

> Original bug referred to RichTextArea, however the root cause of the issue is the incorrect computation of the caret shape around an embedded `Node` in the `TextFlow`.

This pull request has now been integrated.

Changeset: 8341264d
Author:    Andy Goryachev 
URL:       https://git.openjdk.org/jfx/commit/8341264d07040ec03d5f21d4aadb31489ac41026
Stats:     17 lines in 2 files changed: 16 ins; 0 del; 1 mod

8371069: RichTextArea: caret with inline node

Reviewed-by: arapte

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

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

From pavelturk2000 at gmail.com  Tue Nov 18 16:06:19 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Tue, 18 Nov 2025 18:06:19 +0200
Subject: About two my issues
Message-ID: 

Hello everyone,

On November 10, I opened an issue (using the new redesigned form), and the system showed me the ID 23c3711c-36b1-4b94-a0d3-25bbdcf1b95f. The issue was about the fact that PopupWindow is not always shown on Linux systems, and I described how to reproduce the bug using a Tooltip. However, I still haven?t received any information about my issue.

On November 16, I opened another issue (using the old form) about a memory leak in Tab that is related to GRAPHIC. Today I received a message that the issue is JDK-8372108. However, my issue was immediately closed with a note saying that it is a duplicate of JDK-8283449. But it is NOT a duplicate. JDK-8283449 is related to a problem in ContextMenu. I know this issue and I use the following workaround:

contextMenu.getProperties().put(KEY, new WeakReference(tab));

MenuItem close = new MenuItem(..);
close.setOnAction((e) -> {
 ????? var t = getTab(contextMenu); // from properties
});

The issue I reported is related to |graphic|. So I believe that there are TWO separate problems with tabs that lead to memory leaks.

Best regards, Pavel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kcr at openjdk.org  Tue Nov 18 16:12:34 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 18 Nov 2025 16:12:34 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED (Preview)
 [v5]
In-Reply-To: 
References: 
 
Message-ID: <5TFtyjKDYjulyHRV76_NpzPcj9yKR-jLgDuzETw4DpM=.55a04861-5ca0-4ca7-92ff-a3a148b523fb@github.com>

On Sat, 15 Nov 2025 02:18:49 GMT, Michael Strau?  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 pull request now contains nine commits:
> 
>  - Merge branch 'master' into feature/extended-dialog
>    
>    # Conflicts:
>    #	modules/javafx.controls/src/test/java/test/javafx/scene/control/DialogPaneTest.java
>  - fix incorrect button metrics
>  - 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

Running a simple Dialog test that doesn't try to use `HeaderBar` or `StageStyle.EXTENDED` gets a RuntimeException _without_ enabling preview features.

To reproduce, run HelloAlert from apps/toys/Hello or use the MonkeyTester without setting `javafx.enablePreview` and bring up an alert dialog:


Exception in thread "JavaFX Application Thread" java.lang.RuntimeException: HeaderBar is a preview feature of JavaFX 26-internal.
Preview features may be removed in a future release, or upgraded to permanent features of JavaFX.
Programs can only use preview features when the following system property is set: -Djavafx.enablePreview=true

	at javafx.base at 26-internal/com.sun.javafx.PreviewFeature.checkEnabled(PreviewFeature.java:71)
	at javafx.controls at 26-internal/javafx.scene.control.DialogPane.getHeaderBar(DialogPane.java:487)
	at javafx.controls at 26-internal/javafx.scene.control.DialogPane.computePrefWidth(DialogPane.java:1077)
	...

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

Changes requested by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1943#pullrequestreview-3478607121

From kevin.rushforth at oracle.com  Tue Nov 18 16:21:55 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 18 Nov 2025 08:21:55 -0800
Subject: About two my issues
In-Reply-To: 
References: 
Message-ID: 

Regarding the second issue, JDK-8372108, I will add your additional 
information as a comment and reopen the bug.

Regarding the first issue, I see the following, which I presume is the 
one you filed?

JDK-8371781: Popup for ComboBox, Menu, and Tooltip is not shown 
sometimes in JavaFX

I don't know why you didn't receive notification when it was processed 
and transferred to the JDK project in JBS. I see that it was closed as 
not reproducible. Do you have additional information that would help 
reproduce it?

-- Kevin


On 11/18/2025 8:06 AM, PavelTurk wrote:
> Hello everyone,
>
> On November 10, I opened an issue (using the new redesigned form), and 
> the system showed me the ID 23c3711c-36b1-4b94-a0d3-25bbdcf1b95f. The 
> issue was about the fact that PopupWindow is not always shown on Linux 
> systems, and I described how to reproduce the bug using a Tooltip. 
> However, I still haven?t received any information about my issue.
>
> On November 16, I opened another issue (using the old form) about a 
> memory leak in Tab that is related to GRAPHIC. Today I received a 
> message that the issue is JDK-8372108. However, my issue was 
> immediately closed with a note saying that it is a duplicate of 
> JDK-8283449. But it is NOT a duplicate. JDK-8283449 is related to a 
> problem in ContextMenu. I know this issue and I use the following 
> workaround:
>
> contextMenu.getProperties().put(KEY, new WeakReference(tab));
>
> MenuItem close = new MenuItem(..);
> close.setOnAction((e) -> {
> ????? var t = getTab(contextMenu); // from properties
> });
>
> The issue I reported is related to |graphic|. So I believe that there 
> are TWO separate problems with tabs that lead to memory leaks.
>
> Best regards, Pavel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Tue Nov 18 16:23:20 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 18 Nov 2025 16:23:20 GMT
Subject: RFR: 8371070: RichParagraph enhancements [v3]
In-Reply-To: 
References: 
Message-ID: 

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

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into 8371070.enhance
 - Merge branch 'master' into 8371070.enhance
 - test
 - expose segments

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

Changes: https://git.openjdk.org/jfx/pull/1966/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1966&range=02
  Stats: 214 lines in 7 files changed: 141 ins; 43 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 angorya at openjdk.org  Tue Nov 18 16:25:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 18 Nov 2025 16:25:51 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't reach
 VFlow
Message-ID: 

Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`.


### NOTES

- this PR depends on https://github.com/openjdk/jfx/pull/1974
- the fix can be verified visually using the latest Monkey Tester

Screenshot 2025-11-17 at 13 43 12

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

Commit messages:
 - Merge branch 'master' into 8371067.request.layout
 - test
 - request layout
 - test
 - fix

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

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

From pavelturk2000 at gmail.com  Tue Nov 18 16:40:39 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Tue, 18 Nov 2025 18:40:39 +0200
Subject: About two my issues
In-Reply-To: 
References: 
 
Message-ID: <7a48aae0-3cc3-43a0-a6f9-74e6ae0e68da@gmail.com>

Yes, JDK-8371781 is my issue. I understand why it was marked as non-reproducible. And that?s the main problem!
This issue is clearly described both in the title ? SOMETIMES ? and in the FREQUENCY: OCCASIONALLY field.
I specifically recorded a video to prove this issue ? https://streamable.com/6n72cn? (expires in 2 days) ?
and I was able to reproduce it only on the second or third attempt.

However, this issue is one of the most insidious problems in JavaFX on Linux. I talked to users on Reddit ?
many people have heard about it. The reason is that SOMETIMES the menu simply doesn?t appear: a user clicks,
but the menu window doesn?t show up. Because of this, SOMETIMES the ComboBox doesn?t work ? you click,
click, click, but the dropdown doesn?t appear. Maybe, the the window is shown, but it is UNDER the current window.

Best regards, Pavel

On 11/18/25 18:21, Kevin Rushforth wrote:
> Regarding the second issue, JDK-8372108, I will add your additional information as a comment and reopen the bug.
>
> Regarding the first issue, I see the following, which I presume is the one you filed?
>
> JDK-8371781: Popup for ComboBox, Menu, and Tooltip is not shown sometimes in JavaFX
>
> I don't know why you didn't receive notification when it was processed and transferred to the JDK project in JBS. I see that it was closed as not reproducible. Do you have additional information that would help reproduce it?
>
> -- Kevin
>
>
> On 11/18/2025 8:06 AM, PavelTurk wrote:
>> Hello everyone,
>>
>> On November 10, I opened an issue (using the new redesigned form), and the system showed me the ID 23c3711c-36b1-4b94-a0d3-25bbdcf1b95f. The issue was about the fact that PopupWindow is not always shown on Linux systems, and I described how to reproduce the bug using a Tooltip. However, I still haven?t received any information about my issue.
>>
>> On November 16, I opened another issue (using the old form) about a memory leak in Tab that is related to GRAPHIC. Today I received a message that the issue is JDK-8372108. However, my issue was immediately closed with a note saying that it is a duplicate of JDK-8283449. But it is NOT a duplicate. JDK-8283449 is related to a problem in ContextMenu. I know this issue and I use the following workaround:
>>
>> contextMenu.getProperties().put(KEY, new WeakReference(tab));
>>
>> MenuItem close = new MenuItem(..);
>> close.setOnAction((e) -> {
>> ????? var t = getTab(contextMenu); // from properties
>> });
>>
>> The issue I reported is related to |graphic|. So I believe that there are TWO separate problems with tabs that lead to memory leaks.
>>
>> Best regards, Pavel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mstrauss at openjdk.org  Tue Nov 18 16:49:07 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 18 Nov 2025 16:49:07 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED (Preview)
 [v6]
In-Reply-To: 
References: 
Message-ID: 

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

  skip preview feature check for internal use

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1943/files
  - new: https://git.openjdk.org/jfx/pull/1943/files/ccdf88f7..b22712f7

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

  Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 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 kcr at openjdk.org  Tue Nov 18 16:50:37 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 18 Nov 2025 16:50:37 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Oct 2025 07:44:36 GMT, Pabulaner IV  wrote:

>> This pull request fixes the system menu bar on MacOS when combining windows of Swing and JavaFX.
>> 
>> # Behavior before
>> 
>> If for some reason You needed to initialize AWT before JavaFX and You wanted to install the system menu bar from the JavaFX side, this wasn't possible. This issue is persistent even when You didn't open a Swing window. 
>> 
>> One scenario where this kind of issue happens is when You use install4j (see https://www.ej-technologies.com/install4j). In this case AWT is initialized by install4j and therefore You can't use the JavaFX system menu bar anymore.
>> 
>> 
>> # Behavior after
>> 
>> The fix allows JavaFX to install a system menu bar even if it is initialized after AWT. This is achieved by only changing code inside JavaFX. Each JavaFX window stores the previously installed menu bar when gaining focus and will restore this menu bar if the focus was lost. This only happens if the system menu bar installed by the JavaFX window is still unchanged.
>> 
>> 
>> # Tests
>> 
>> This PR introduces tests for the system menu bar in addition to verifying its own behavior / changes. The tests include single- and multi-window tests while interacting with Swing. The tests ensure that the menu bar stays the same for each window, no matter how You switch focus between them.
>> 
>> 
>> # Additional benifits 
>> 
>> This fix is not specifically for AWT, but allows JavaFX to interact much more compatibly with other frameworks that make use of the system menu bar.
>> 
>> 
>> # Review from AWT
>> 
>> In the previous PR related to this one, the comment was made that the folks from AWT should take a look at this fix. It would be great and much appreciated if someone could initiate it.
>> 
>> 
>> # Add disable flag?
>> 
>> We could also add a flag to prevent JavaFX from installing a system menu bar for users who have found other fixes for their projects / setups. This could be used to restore the previous behavior when AWT is initialized first.
>> 
>> 
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX

This is on my list to review this week. Sorry for the delay.

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3548569629

From mstrauss at openjdk.org  Tue Nov 18 16:54:39 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 18 Nov 2025 16:54:39 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED (Preview)
 [v5]
In-Reply-To: <5TFtyjKDYjulyHRV76_NpzPcj9yKR-jLgDuzETw4DpM=.55a04861-5ca0-4ca7-92ff-a3a148b523fb@github.com>
References: 
 
 <5TFtyjKDYjulyHRV76_NpzPcj9yKR-jLgDuzETw4DpM=.55a04861-5ca0-4ca7-92ff-a3a148b523fb@github.com>
Message-ID: <0kyVmC8nvnfOYVvijOqmQ3XUXTgcuTFe_ugooLebIx8=.7e21f4ed-c9c4-4659-b713-cdf954e216e7@github.com>

On Tue, 18 Nov 2025 16:10:09 GMT, Kevin Rushforth  wrote:

> Running a simple Dialog test that doesn't try to use `HeaderBar` or `StageStyle.EXTENDED` gets a RuntimeException _without_ enabling preview features.

I've updated the code to skip the preview feature check internally. It's still active for the public API.

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

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

From kcr at openjdk.org  Tue Nov 18 17:28:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 18 Nov 2025 17:28:02 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v5]
In-Reply-To: <6Qlc-NKNx94Dp9zVd5KXpAqJNryB4QKt9y21PSrc4UE=.924386db-11d1-4201-8153-060e07fbbbc6@github.com>
References: 
 <6Qlc-NKNx94Dp9zVd5KXpAqJNryB4QKt9y21PSrc4UE=.924386db-11d1-4201-8153-060e07fbbbc6@github.com>
Message-ID: 

On Tue, 18 Nov 2025 13:24:31 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   temp-var handling in few other methods

I left a few comments inline. I still want to look more closely at the `sendXxxxxEventToFX()` methods to see if there are any problems using a stale value of scenePeer() or stagePeer(). I do think this PR improves the situation by avoiding spurious NPEs, so if further analysis doesn't show any additional problems, it it probably reasonable to proceed with this PR and file a follow-on bug to do a proper MT design for JFXPanel.


I also want do some additional testing.

modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 156:

> 154:     private transient volatile EmbeddedWindow stage;
> 155: 
> 156:     private transient volatile Scene scene;

Minor: I would remove the blank line between these two declarations to make it clear that the comment applies to both.

modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 974:

> 972:                         getScene().getFocusOwner() != null &&
> 973:                         getScene().getFocusOwner().isFocused()) {
> 974:                     hStagePeer.focusUngrab();

This can be reverted. `stagePeer` is only accessed on the FX thread.

modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 996:

> 994:                             // some reason they didn't install the grab when
> 995:                             // they were shown.
> 996:                             hStagePeer.focusUngrab();

This can be reverted. `stagePeer` is only accessed on the FX thread.

modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 1023:

> 1021:             }
> 1022:         });
> 1023:         sendMoveEventToFX();

This is not an equivalent change, since `sendMoveEventToFX()` can now happen before `stage.show()` and will also happen unconditionally even if the stage is null or already showing. Rather than moving it out of the runOnFxThread block, leave it where it is and call `runOnEDT` like this:


        SwingNodeHelper.runOnFxThread(() -> {
            if ((stage != null) && !stage.isShowing()) {
                stage.show();
                SwingNodeHelper.runOnEDT(() -> sendMoveEventToFX());
            }
        });

modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 1078:

> 1076:             stagePeer = embeddedStage;
> 1077:             var hStagePeer = stagePeer;
> 1078:             if (hStagePeer == null) {

If this is always invoked from the FX thread, you don't need to locally capture the peers.

tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 105:

> 103:             Thread.sleep(100);
> 104:         }
> 105:         System.out.println("failure = " + failure.get());

This print can be removed.

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

PR Review: https://git.openjdk.org/jfx/pull/1968#pullrequestreview-3478854934
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2539008637
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2539028674
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2539029530
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2539054147
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2539059009
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2539066037

From kcr at openjdk.org  Tue Nov 18 18:07:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 18 Nov 2025 18:07:16 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED (Preview)
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 18 Nov 2025 16:49:07 GMT, Michael Strau?  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:
> 
>   skip preview feature check for internal use

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1943#pullrequestreview-3479087460

From angorya at openjdk.org  Tue Nov 18 18:07:17 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 18 Nov 2025 18:07:17 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED (Preview)
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 18 Nov 2025 16:49:07 GMT, Michael Strau?  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:
> 
>   skip preview feature check for internal use

Marked as reviewed by angorya (Reviewer).

modules/javafx.controls/src/main/java/javafx/scene/control/DialogPane.java line 506:

> 504:     }
> 505: 
> 506:     // This method skips the preview feature check for internal use and can be removed when HeaderBar is finalized.

I wonder if a comment should be added to the JBS ticket listing the things that need to be undone, lest we forget.

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

PR Review: https://git.openjdk.org/jfx/pull/1943#pullrequestreview-3479103169
PR Review Comment: https://git.openjdk.org/jfx/pull/1943#discussion_r2539193935

From mstrauss at openjdk.org  Tue Nov 18 18:36:40 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 18 Nov 2025 18:36:40 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED (Preview)
 [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 18 Nov 2025 18:03:19 GMT, Andy Goryachev  wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   skip preview feature check for internal use
>
> modules/javafx.controls/src/main/java/javafx/scene/control/DialogPane.java line 506:
> 
>> 504:     }
>> 505: 
>> 506:     // This method skips the preview feature check for internal use and can be removed when HeaderBar is finalized.
> 
> I wonder if a comment should be added to the JBS ticket listing the things that need to be undone, lest we forget.

In this specific case it's quite hard to miss, since it's right next to the preview API. But go ahead if you want to add the comment.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1943#discussion_r2539273108

From mstrauss at openjdk.org  Tue Nov 18 18:36:41 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 18 Nov 2025 18:36:41 GMT
Subject: Integrated: 8370446: Support dialogs with StageStyle.EXTENDED
 (Preview)
In-Reply-To: 
References: 
Message-ID: <02Rol54ybpUm9Tl_9mW2epFE4WVdOP_650NkWNHJ4fk=.3ba4083e-4fc0-4de7-875b-d229d9a0fd7f@github.com>

On Tue, 21 Oct 2025 23:54:55 GMT, Michael Strau?  wrote:

> Adds the `DialogPane.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style.

This pull request has now been integrated.

Changeset: f87448ec
Author:    Michael Strau? 
URL:       https://git.openjdk.org/jfx/commit/f87448ec156608527d77a4204e98e08052ffecd1
Stats:     402 lines in 6 files changed: 355 ins; 15 del; 32 mod

8370446: Support dialogs with StageStyle.EXTENDED (Preview)

Reviewed-by: angorya, kcr

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

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

From mstrauss at openjdk.org  Tue Nov 18 18:39:43 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 18 Nov 2025 18:39:43 GMT
Subject: RFR: 8369836: Update HeaderBar API [v4]
In-Reply-To: 
References: 
Message-ID: 

> The `HeaderBar` control currently has three areas: `leading`, `center`, and `trailing`. Additionally, there's `leftSystemInset` and `rightSystemInset`, which are not RTL adjusted. I've come to the understanding that there is no particularly good reason for this, because every time you would want to use this information for layout purposes, it should also be adjusted for RTL.
> 
> With this in mind, there are three changes for the `HeaderBar` control:
> 1. Rename `leading` to `left`, and `trailing` to `right`, which aligns the terminology with `BorderPane`.
> 2. Adjust `leftSystemInset` and `rightSystemInset` for RTL.
> 3. Make `leftSystemInset`, `rightSystemInset`, and `minSystemHeight` attached properties for `Stage`.
> 
> With this change, the `HeaderBar` control is more semantically consistent and easier to use, and the renamed `left` and `right` areas now show its close relationship with `BorderPane`.

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 five additional commits since the last revision:

 - Merge branch 'master' into headerbar-update
 - documentation
 - Merge branch 'master' into headerbar-update
 - Make leftSystemInset/rightSystemInset/minSystemHeight attached properties
 - Update HeaderBar API

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1936/files
  - new: https://git.openjdk.org/jfx/pull/1936/files/026a0d27..f6a93537

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

  Stats: 781 lines in 23 files changed: 703 ins; 26 del; 52 mod
  Patch: https://git.openjdk.org/jfx/pull/1936.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1936/head:pull/1936

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

From angorya at openjdk.org  Tue Nov 18 21:56:07 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 18 Nov 2025 21:56:07 GMT
Subject: RFR: 8371981: Wrong spit caret positioning with mixed text
Message-ID: 

Fixing a silly mistake - mixed up `lineX2` and `lineY` parameters in `PrismTextLayout`.

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

Commit messages:
 - tests
 - fix

Changes: https://git.openjdk.org/jfx/pull/1976/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1976&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371981
  Stats: 157 lines in 4 files changed: 152 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1976.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1976/head:pull/1976

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

From angorya at openjdk.org  Tue Nov 18 21:56:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 18 Nov 2025 21:56:08 GMT
Subject: RFR: 8371981: Wrong spit caret positioning with mixed text
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 Nov 2025 20:04:42 GMT, Andy Goryachev  wrote:

> Fixing a silly mistake - mixed up `lineX2` and `lineY` parameters in `PrismTextLayout`.

the headful CI run ok.

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

PR Comment: https://git.openjdk.org/jfx/pull/1976#issuecomment-3549540339

From kcr at openjdk.org  Tue Nov 18 23:59:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 18 Nov 2025 23:59:48 GMT
Subject: RFR: 8371981: Wrong spit caret positioning with mixed text
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 18 Nov 2025 21:26:11 GMT, Andy Goryachev  wrote:

>> Fixing a silly mistake - mixed up `lineX2` and `lineY` parameters in `PrismTextLayout`.
>
> the headful CI run ok.

@andy-goryachev-oracle I fixed a typo in the JBS bug title that you will need to propagate to the PR title.

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

PR Comment: https://git.openjdk.org/jfx/pull/1976#issuecomment-3549940577

From nlisker at openjdk.org  Wed Nov 19 00:08:46 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 19 Nov 2025 00:08:46 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v2]
In-Reply-To: <2w9h-vPFy-b-hkJDsK4m4pHPH4jJg00nIwtCpTtc1aE=.45c75cd5-9b9e-4f1c-b089-a4f41c79083b@github.com>
References: 
 <6xWWnVedU5-eehKPlHbORXT3dxtIoP7WFyvqQSmyWbk=.048ed0ae-384f-4ffc-9b78-5872fe7b91db@github.com>
 
 <2w9h-vPFy-b-hkJDsK4m4pHPH4jJg00nIwtCpTtc1aE=.45c75cd5-9b9e-4f1c-b089-a4f41c79083b@github.com>
Message-ID: <4xcXc6g7x37i055JG0Hjiv3XX9bmqyySc5LCHTdMSsY=.d419ddae-49ae-4883-b461-99b3e8a01ee3@github.com>

On Tue, 18 Nov 2025 00:00:14 GMT, Kevin Rushforth  wrote:

>> modules/javafx.base/src/main/java/javafx/util/converter/BaseStringConverter.java line 30:
>> 
>>> 28: import javafx.util.StringConverter;
>>> 29: 
>>> 30: /// A base class containing common implementations for `StringConverter`s as noted in the @implNote of `StringConverter`.
>> 
>> In light of possible backporting, it's been decided earlier not to use markdown comments.
>
> In general, yes, but I note that this is a pretty major refactoring where most of the javadocs were redone, and all of them now use markdown. This is a case where we could consider allowing them. I don't have a strong opinion either way, and likely won't have time to review this one for a while...

> In light of possible backporting, it's been decided earlier not to use markdown comments.

On the mailing list it was suggested to allow them in this PR (and revert them in the PR for adding the MOUSE_DRAG_DONE event).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2540003224

From kcr at openjdk.org  Wed Nov 19 00:18:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 19 Nov 2025 00:18:55 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v2]
In-Reply-To: <4xcXc6g7x37i055JG0Hjiv3XX9bmqyySc5LCHTdMSsY=.d419ddae-49ae-4883-b461-99b3e8a01ee3@github.com>
References: 
 <6xWWnVedU5-eehKPlHbORXT3dxtIoP7WFyvqQSmyWbk=.048ed0ae-384f-4ffc-9b78-5872fe7b91db@github.com>
 
 <2w9h-vPFy-b-hkJDsK4m4pHPH4jJg00nIwtCpTtc1aE=.45c75cd5-9b9e-4f1c-b089-a4f41c79083b@github.com>
 <4xcXc6g7x37i055JG0Hjiv3XX9bmqyySc5LCHTdMSsY=.d419ddae-49ae-4883-b461-99b3e8a01ee3@github.com>
Message-ID: 

On Wed, 19 Nov 2025 00:06:37 GMT, Nir Lisker  wrote:

>> In general, yes, but I note that this is a pretty major refactoring where most of the javadocs were redone, and all of them now use markdown. This is a case where we could consider allowing them. I don't have a strong opinion either way, and likely won't have time to review this one for a while...
>
>> In light of possible backporting, it's been decided earlier not to use markdown comments.
> 
> On the mailing list it was suggested to allow them in this PR (and revert them in the PR for adding the MOUSE_DRAG_DONE event).

Yes, that was what I had suggested earlier. As I mentioned above I think this is one case where using markdown comments seems reasonable.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2540019286

From nlisker at openjdk.org  Wed Nov 19 00:36:02 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 19 Nov 2025 00:36:02 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 17 Nov 2025 22:34:37 GMT, Andy Goryachev  wrote:

> I second John's suggestion with `this.`. It matters when refactoring, even with an IDE.

I'm not sure what you want me to change here exactly. Is it about renaming parameters (see [this discussion](https://github.com/openjdk/jfx/pull/1880#discussion_r2297668458)), or not using `this`, which you didn't seem to mind [here](https://github.com/openjdk/jfx/pull/1880#discussion_r2297721228)?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2540042087

From nlisker at openjdk.org  Wed Nov 19 00:41:14 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 19 Nov 2025 00:41:14 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v2]
In-Reply-To: 
References: 
 <6xWWnVedU5-eehKPlHbORXT3dxtIoP7WFyvqQSmyWbk=.048ed0ae-384f-4ffc-9b78-5872fe7b91db@github.com>
 
Message-ID: 

On Mon, 17 Nov 2025 22:49:26 GMT, Andy Goryachev  wrote:

>> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review comments 2
>>  - review comments 1
>
> modules/javafx.base/src/main/java/javafx/util/converter/DateTimeStringConverter.java line 115:
> 
>> 113:                 getSpecialziedDateFormat(dateStyle, timeStyle, locale) :
>> 114:                 new SimpleDateFormat(pattern, locale);
>> 115:         dateFormat.setLenient(false);
> 
> Would setting `lenient=false` constitute a change in functionality?

Why would it? It was the same before this change?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2540055853

From nlisker at openjdk.org  Wed Nov 19 00:45:14 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 19 Nov 2025 00:45:14 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v2]
In-Reply-To: 
References: 
 <6xWWnVedU5-eehKPlHbORXT3dxtIoP7WFyvqQSmyWbk=.048ed0ae-384f-4ffc-9b78-5872fe7b91db@github.com>
 
Message-ID: 

On Mon, 17 Nov 2025 22:59:57 GMT, Andy Goryachev  wrote:

>> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review comments 2
>>  - review comments 1
>
> modules/javafx.base/src/main/java/javafx/util/StringConverter.java line 38:
> 
>> 36: /// - Except for `DefaultStringConverter`, formatting `null` returns an empty string, otherwise the type's `toString` is
>> 37: /// used if it is suitable; parsing `null` or an empty string returns `null`.
>> 38: /// - Immutable (the same converter can be reused).
> 
> Is this true? 
> I recall some formatters having a state, but I don't remember which...

Some do, but that state is immutable. Converters build a formatter/parser on construction (if at all needed) and use it for the duration of their existence. There are some deprecations that we need to do regarding inspecting the internal state.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2540061733

From nlisker at openjdk.org  Wed Nov 19 00:49:45 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 19 Nov 2025 00:49:45 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v2]
In-Reply-To: 
References: 
 <6xWWnVedU5-eehKPlHbORXT3dxtIoP7WFyvqQSmyWbk=.048ed0ae-384f-4ffc-9b78-5872fe7b91db@github.com>
 
Message-ID: <-gmnLsq36zliWkkw0V0py5CBEFH-GxF6nOgHYvx5iHw=.1c617127-c390-4d82-b8a0-d6c419f7a213@github.com>

On Mon, 17 Nov 2025 23:09:43 GMT, Andy Goryachev  wrote:

>> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review comments 2
>>  - review comments 1
>
> modules/javafx.base/src/test/java/test/javafx/util/converter/CurrencyStringConverterTest.java line 58:
> 
>> 56:     void testConstructor_locale() {
>> 57:         NumberFormat numberFormat = NumberFormat.getCurrencyInstance(Locale.CANADA);
>> 58: 
> 
> very minor: extra newlines?

To separated the part that created the expected result and the actual result.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2540071517

From nlisker at openjdk.org  Wed Nov 19 00:53:15 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 19 Nov 2025 00:53:15 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v3]
In-Reply-To: 
References: 
Message-ID: 

> Refactoring of all `StringConverter`s and their tests. General notes:
> * The documentation language has been unified and `null` parameter rules have been documented.
> *  Tests have been cleaned up in the vein of https://github.com/openjdk/jfx/pull/1759 and unneeded `@BeforeAll`s were removed.
> * Internal fields were made `private final` to guarantee immutability.
> 
>  Incremental commits are provided for easier reviewing:
> 
> ### Parent classes
> * `StringConverter`: updated documentation
> * `BaseStringConverter`: a new internal class that implements repeated code from converter implementations and serves as an intermediate superclass. It does empty and `null` string checks that are handled uniformly, except for `DefaultStringConverter`, which has a different formatting mechanism.
> 
> ### Primitive-related converters
> * All primitive (wrapper) converters also document their formatting and parsing mechanism since these are "well-established".
> 
> ### Format converter
> * Checked for `null` during constriction time to avoid runtime NPEs.
> * There is no test class for this converter. A followup might be desirable.
> * A followup should deprecate for removal `protected Format getFormat()` (as in [JDK-8314597](https://bugs.openjdk.org/browse/JDK-8314597) and [JDK-8260475](https://bugs.openjdk.org/browse/JDK-8260475)).
> 
> ### Number and subclasses converters
> * The intermediate `locale` and `pattern` fields were removed (along with their tests). The class generated a new formatter from these on each call. This only makes sense for mutable fields where the resulting formatter can change, but here the formatter can be computed once on construction and stored.
> * The only difference between these classes is a single method for creating a format from a `null` pattern, which was encapsulated in the `getSpecializedNumberFormat` method.
> * The terminally deprecated `protected NumberFormat getNumberFormat()` was removed. Can be split to its own issue if preferred. In my opinion, it shouldn't exist even internally since testing the internal formatter doesn't help. The only tests here should be for to/from strings, and these are lacking. A followup can be filed for adding more conversion tests.
> 
> ### Date/Time converters
> * Added a documentation note advising users to use the `java.time` classes instead of the old `Date` class.
> * As with Number converters, only the `dateFormat` field was kept, which is created once on construction instead of on each call.
> * As with Number converters, the `getSpecialzie...

Nir Lisker has updated the pull request incrementally with two additional commits since the last revision:

 - Fix typo
 - Removed super() invocations

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1880/files
  - new: https://git.openjdk.org/jfx/pull/1880/files/3448438b..ffad73e5

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

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

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

From nlisker at openjdk.org  Wed Nov 19 00:59:19 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 19 Nov 2025 00:59:19 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v4]
In-Reply-To: 
References: 
Message-ID: 

> Refactoring of all `StringConverter`s and their tests. General notes:
> * The documentation language has been unified and `null` parameter rules have been documented.
> *  Tests have been cleaned up in the vein of https://github.com/openjdk/jfx/pull/1759 and unneeded `@BeforeAll`s were removed.
> * Internal fields were made `private final` to guarantee immutability.
> 
>  Incremental commits are provided for easier reviewing:
> 
> ### Parent classes
> * `StringConverter`: updated documentation
> * `BaseStringConverter`: a new internal class that implements repeated code from converter implementations and serves as an intermediate superclass. It does empty and `null` string checks that are handled uniformly, except for `DefaultStringConverter`, which has a different formatting mechanism.
> 
> ### Primitive-related converters
> * All primitive (wrapper) converters also document their formatting and parsing mechanism since these are "well-established".
> 
> ### Format converter
> * Checked for `null` during constriction time to avoid runtime NPEs.
> * There is no test class for this converter. A followup might be desirable.
> * A followup should deprecate for removal `protected Format getFormat()` (as in [JDK-8314597](https://bugs.openjdk.org/browse/JDK-8314597) and [JDK-8260475](https://bugs.openjdk.org/browse/JDK-8260475)).
> 
> ### Number and subclasses converters
> * The intermediate `locale` and `pattern` fields were removed (along with their tests). The class generated a new formatter from these on each call. This only makes sense for mutable fields where the resulting formatter can change, but here the formatter can be computed once on construction and stored.
> * The only difference between these classes is a single method for creating a format from a `null` pattern, which was encapsulated in the `getSpecializedNumberFormat` method.
> * The terminally deprecated `protected NumberFormat getNumberFormat()` was removed. Can be split to its own issue if preferred. In my opinion, it shouldn't exist even internally since testing the internal formatter doesn't help. The only tests here should be for to/from strings, and these are lacking. A followup can be filed for adding more conversion tests.
> 
> ### Date/Time converters
> * Added a documentation note advising users to use the `java.time` classes instead of the old `Date` class.
> * As with Number converters, only the `dateFormat` field was kept, which is created once on construction instead of on each call.
> * As with Number converters, the `getSpecialzie...

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

 - Merge master
 - Fix typo
 - Removed super() invocations
 - review comments 2
 - review comments 1
 - LocalDate/Time converters
 - Date/Time converters
 - Number and subclasses converters
 - Format converter
 - Primitive-related converters
 - ... and 1 more: https://git.openjdk.org/jfx/compare/2e6d2313...a030ce58

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1880/files
  - new: https://git.openjdk.org/jfx/pull/1880/files/ffad73e5..a030ce58

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

  Stats: 154009 lines in 1240 files changed: 84543 ins; 27129 del; 42337 mod
  Patch: https://git.openjdk.org/jfx/pull/1880.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1880/head:pull/1880

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

From engineer.fouad.a at gmail.com  Wed Nov 19 01:17:37 2025
From: engineer.fouad.a at gmail.com (Fouad Almalki)
Date: Wed, 19 Nov 2025 04:17:37 +0300
Subject: JDK-8372053: RichTextArea keyboard navigation for RTL paragraph
 should be the opposite
Message-ID: 

Hi,

I am the original reporter of the bug JDK-8372053. The issue I was
referring to was with the incubator RichTextArea not the regular TextArea.
The issue happens when the RichTextArea's node orientation is default (LTR)
but the paragraph is right-aligned (TextAlignment.RIGHT and
ParagraphDirection.RIGHT_TO_LEFT) with RTL text.

Current behavior is: RIGHT moves caret forward, and LEFT moves caret
backward.
Expected behavior is: LEFT moves caret forward, and RIGHT moves caret
backward.



Also, currently the text selection of 2 lines of RTL text (does not matter
aligned to left or right) is a little buggy. When positioning the caret at
the start of second line, then pressing Shift+LEFT:

Current behavior is: both lines will be highlighted and the caret will be
at the end of the first line (wrong highlight but correct caret position).
If pressing Shift+LEFT again, both lines will still be highlighted and the
caret will be at the end of the first line - 1 (again, wrong highlight but
correct caret position).
Expected behavior is: The text highlight should be synced with the caret
position.



I also reported 2 more issues last week but did not appear yet on
bugs.openjdk.org.

Best Regards~
Fouad almalki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From arapte at openjdk.org  Wed Nov 19 05:34:41 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 19 Nov 2025 05:34:41 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 18 Nov 2025 11:30:54 GMT, Marius Hanl  wrote:

>> This PR splits the maven publishing logic into an own file, `maven-publish.gradle`, that is next to the root `build.gradle`.
>> 
>> The `build.gradle` will apply the `maven-publish.gradle`. The `maven-publish.gradle` will then configure the Maven related properties and register all modules for publication.
>> 
>> This way, we decoupled the logic that much, the only things we need to do:
>> - apply from `maven-publish.gradle`
>> - Call `configureMavenPublication` later in the build chain.
>> 
>> To better understand the context, this is the commit where the whole Maven Publishing logic was introduced. I moved all of that logic out of the main `build.gradle`: 5a18677f
>> 
>> This will reduce the size by ~170 lines for the `build.gradle`.
>> 
>> Tested with:
>> - `./gradlew -PMAVEN_PUBLISH=true -PMAVEN_VERSION=custom publishToMavenLocal`
>> - `./gradlew -PMAVEN_PUBLISH=true publishToMavenLocal`
>> - `./gradlew -PMAVEN_PUBLISH=true -PMILESTONE_FCS=true publishToMavenLocal`
>> 
>> Everything still works:
>> -> Example: javafx.base from the local .m2 repository
>> image
>> 
>> I think this is a good step and an easy way to split out functionality without blowing things up. We might want to do that for other parts as well.
>> 
>> Note: I also fixed the deprecated `buildDir`, the deprecated `project.task` method and 2 warnings where it seems like he might not be able to infer the type (changing `def` to the actual type). 
>> -> The file is completely green, no warnings or deprecations.
>> Note2: I did a small improvement to the `addMavenPublication` method. It is now more 'typesafe', e.g. projects must be passed in directly, not as String. If a project does not exist, the build will fail with an exception.
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use defineProperty and fail method from default build.gradle

I ran the same command `gradle -PMAVEN_PUBLISH=true publishToMavenLocal` with the latest changes in the PR and without.

With this PR, for a module a few additional tasks get executed compared to without PR.
For example for graphics module, following additional tasks are executed.

> Task :graphics:modularJarStandaloneMac
> Task :graphics:copyNativeFilesStandaloneMac NO-SOURCE
> Task :graphics:copyLibFilesStandaloneMac
> Task :graphics:copyLegalStandaloneMac
> Task :graphics:cleanOpenLegalStandaloneMac
> Task :graphics:copyClassFilesMac
> Task :graphics:copyBinFilesMac NO-SOURCE
> Task :graphics:copyLibFilesMac
> Task :graphics:copySourceFilesMac
> Task :graphics:copyDocFilesMac
> Task :graphics:copyBuildPropertiesMac
> Task :graphics:copyClosedLegalStandaloneMac
> Task :graphics:copyLegalMac


So, the content of build directories differ. With this change there are 2 additional directories created under build dir: `modular-sdk` and `sdk`

Screenshot 2025-11-19 at 10 37 10


I am not sure which is more correct behavior or if it can cause any issue.
Though seems safe, as ideal way would be to do a full build and then publish.
I would like to request @kevinrushforth and @johanvos to please weigh in.

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

PR Comment: https://git.openjdk.org/jfx/pull/1970#issuecomment-3550883126

From mhanl at openjdk.org  Wed Nov 19 08:50:45 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 19 Nov 2025 08:50:45 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 18 Nov 2025 11:30:54 GMT, Marius Hanl  wrote:

>> This PR splits the maven publishing logic into an own file, `maven-publish.gradle`, that is next to the root `build.gradle`.
>> 
>> The `build.gradle` will apply the `maven-publish.gradle`. The `maven-publish.gradle` will then configure the Maven related properties and register all modules for publication.
>> 
>> This way, we decoupled the logic that much, the only things we need to do:
>> - apply from `maven-publish.gradle`
>> - Call `configureMavenPublication` later in the build chain.
>> 
>> To better understand the context, this is the commit where the whole Maven Publishing logic was introduced. I moved all of that logic out of the main `build.gradle`: 5a18677f
>> 
>> This will reduce the size by ~170 lines for the `build.gradle`.
>> 
>> Tested with:
>> - `./gradlew -PMAVEN_PUBLISH=true -PMAVEN_VERSION=custom publishToMavenLocal`
>> - `./gradlew -PMAVEN_PUBLISH=true publishToMavenLocal`
>> - `./gradlew -PMAVEN_PUBLISH=true -PMILESTONE_FCS=true publishToMavenLocal`
>> 
>> Everything still works:
>> -> Example: javafx.base from the local .m2 repository
>> image
>> 
>> I think this is a good step and an easy way to split out functionality without blowing things up. We might want to do that for other parts as well.
>> 
>> Note: I also fixed the deprecated `buildDir`, the deprecated `project.task` method and 2 warnings where it seems like he might not be able to infer the type (changing `def` to the actual type). 
>> -> The file is completely green, no warnings or deprecations.
>> Note2: I did a small improvement to the `addMavenPublication` method. It is now more 'typesafe', e.g. projects must be passed in directly, not as String. If a project does not exist, the build will fail with an exception.
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use defineProperty and fail method from default build.gradle

> So, the content of build directories differ. With this change there are 2 additional directories created under build dir: `modular-sdk` and `sdk`
> I am not sure which is more correct behavior or if it can cause any issue. Though seems safe, as ideal way would be to do a full build and then publish. I would like to request @kevinrushforth and @johanvos to please weigh in.

Thanks a lot for testing as well!
I saw that too and thought the same, it should be more safe and makes more sense. Before, it was depending on each individual module build task like so:
https://github.com/openjdk/jfx/blob/f87448ec156608527d77a4204e98e08052ffecd1/build.gradle#L5850
Which I think is much more error prone and also risks that we forget something or it is executed too early in the future.

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

PR Comment: https://git.openjdk.org/jfx/pull/1970#issuecomment-3551521154

From mhanl at openjdk.org  Wed Nov 19 08:57:28 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 19 Nov 2025 08:57:28 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow
In-Reply-To: 
References: 
Message-ID: 

On Mon, 17 Nov 2025 21:46:06 GMT, Andy Goryachev  wrote:

> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`.
> 
> 
> ### NOTES
> 
> - this PR depends on https://github.com/openjdk/jfx/pull/1974
> - the fix can be verified visually using the latest Monkey Tester
> 
> Screenshot 2025-11-17 at 13 43 12

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

> 749:     // with the author's permission
> 750:     /** returns a parent of the specified type, or null.  if node is an instance of the specified class, returns node */
> 751:     public static  T getAncestorOfClass(Class c, Node node) {

I would really recommend to not do anything like that. Normally, the layouting system, especially when requesting a layout should work and bubble up correctly. I wonder why this is needed. And if we found a special case, if we can solve it better.

Background: In the past projects, I often saw code like that and it turned out that this was never needed. It is often less readable and hurts the performance a bit. 
We also improve coupling between components, which I would not recommend as well. Especially since subclasses can change a lot and it would be nice if everything still work out of the box.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2541102625

From psadhukhan at openjdk.org  Wed Nov 19 12:38:19 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Nov 2025 12:38:19 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v6]
In-Reply-To: 
References: 
Message-ID: <98_uoVa0itSqGd1_OL00_X9f998Kt-xnZ_gDEeoFPgw=.6b537c67-0650-45fd-ac85-052e2ed9c8df@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

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/1968/files
  - new: https://git.openjdk.org/jfx/pull/1968/files/fc830a7e..290ed2de

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

  Stats: 9 lines in 2 files changed: 2 ins; 3 del; 4 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 psadhukhan at openjdk.org  Wed Nov 19 12:38:27 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Nov 2025 12:38:27 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v5]
In-Reply-To: 
References: 
 <6Qlc-NKNx94Dp9zVd5KXpAqJNryB4QKt9y21PSrc4UE=.924386db-11d1-4201-8153-060e07fbbbc6@github.com>
 
Message-ID: 

On Tue, 18 Nov 2025 17:03:49 GMT, Kevin Rushforth  wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   temp-var handling in few other methods
>
> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 156:
> 
>> 154:     private transient volatile EmbeddedWindow stage;
>> 155: 
>> 156:     private transient volatile Scene scene;
> 
> Minor: I would remove the blank line between these two declarations to make it clear that the comment applies to both.

I intentionally added the blank line to separate it out as `stage` is set in `setSceneImpl `in FX thread and accessed in `paintComponent `in EDT thread whereas `scene` is set in `setSceneImpl ` in FX thread and never accessed in EDT thread

> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 974:
> 
>> 972:                         getScene().getFocusOwner() != null &&
>> 973:                         getScene().getFocusOwner().isFocused()) {
>> 974:                     hStagePeer.focusUngrab();
> 
> This can be reverted. `stagePeer` is only accessed on the FX thread.

`stagePeer` is accessed in `processMouseEvent`, `sendResizeEventToFX`, `sendMoveEventToFX`, `sendFocusEventToFX `in EDT so I did that.
But it seems in this particular method, it is only accessed in FX thread as is mentioned so reverted..

> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 1023:
> 
>> 1021:             }
>> 1022:         });
>> 1023:         sendMoveEventToFX();
> 
> This is not an equivalent change, since `sendMoveEventToFX()` can now happen before `stage.show()` and will also happen unconditionally even if the stage is null or already showing. Rather than moving it out of the runOnFxThread block, leave it where it is and call `runOnEDT` like this:
> 
> 
>         SwingNodeHelper.runOnFxThread(() -> {
>             if ((stage != null) && !stage.isShowing()) {
>                 stage.show();
>                 SwingNodeHelper.runOnEDT(() -> sendMoveEventToFX());
>             }
>         });

ok

> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 1078:
> 
>> 1076:             stagePeer = embeddedStage;
>> 1077:             var hStagePeer = stagePeer;
>> 1078:             if (hStagePeer == null) {
> 
> If this is always invoked from the FX thread, you don't need to locally capture the peers.

but down below it is accessed in EDT so I did the local capture

> tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 105:
> 
>> 103:             Thread.sleep(100);
>> 104:         }
>> 105:         System.out.println("failure = " + failure.get());
> 
> This print can be removed.

ok

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2541819249
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2541821731
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2541822284
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2541822543
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2541822916

From psadhukhan at openjdk.org  Wed Nov 19 12:52:51 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Nov 2025 12:52:51 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v7]
In-Reply-To: 
References: 
Message-ID: 

> 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

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/1968/files
  - new: https://git.openjdk.org/jfx/pull/1968/files/290ed2de..4049ad67

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

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 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 kcr at openjdk.org  Wed Nov 19 14:39:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 19 Nov 2025 14:39:48 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v7]
In-Reply-To: 
References: 
 
Message-ID: <2UT7Kzei56qYAPki0lpEQV5Ezf0GRMNgxmWKe4PHvpI=.49c9d727-a551-41eb-99d9-dc62265c7856@github.com>

On Wed, 19 Nov 2025 12:52:51 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

The fix now looks good with one question about the change in `EmbeddedScene`. I also looked at the implementation of the `EmbeddedStage` and `EmbeddedScene` methods, and they all do the right thing in that they forward the requests to the FX thread.

I do want to see a follow-up issue filed to consider redesigning the threading model, but I think this PR is a good workaround for the NPEs.

As for the newly added test, it passes with the fix and with no exception messages (good). However, at least one of the times I ran the test without the fix (using the existing 100 msec sleep), it printed a couple exceptions and passed anyway. It seems that some of the exceptions that can occur will cause the test to fail but others will not. You might consider using the `test.javafx.util.OutputRedirect` utility instead of relying on the `UncaughtExceptionHandler`. This might not be a problem in practice if you reduce the sleep time, but will make the test more likely to catch any problems.

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedScene.java line 160:

> 158:                 if (getSceneState() != null) {
> 159:                     updateSceneState();
> 160:                 }

None of the other calls to `updateSceneState()` check for a null `sceneState`. Why is this is the only one that needs to? If it is needed, it might be safer to move the null check into `updateSceneState` itself.

tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 103:

> 101:             Thread.sleep(100);
> 102:             Platform.runLater(() -> contentPane.setScene(webView.getScene()));
> 103:             Thread.sleep(100);

With a `sleep(100)` this only occasionally gets an exception when I run it without your fix. I recommend `sleep(1)` which is what the manual test does. The test will take less time and also be a better stress test.

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

PR Review: https://git.openjdk.org/jfx/pull/1968#pullrequestreview-3482862662
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2542150648
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2542248037

From kcr at openjdk.org  Wed Nov 19 14:39:51 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 19 Nov 2025 14:39:51 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v5]
In-Reply-To: 
References: 
 <6Qlc-NKNx94Dp9zVd5KXpAqJNryB4QKt9y21PSrc4UE=.924386db-11d1-4201-8153-060e07fbbbc6@github.com>
 
 
Message-ID: 

On Wed, 19 Nov 2025 12:34:01 GMT, Prasanta Sadhukhan  wrote:

>> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 974:
>> 
>>> 972:                         getScene().getFocusOwner() != null &&
>>> 973:                         getScene().getFocusOwner().isFocused()) {
>>> 974:                     hStagePeer.focusUngrab();
>> 
>> This can be reverted. `stagePeer` is only accessed on the FX thread.
>
> `stagePeer` is accessed in `processMouseEvent`, `sendResizeEventToFX`, `sendMoveEventToFX`, `sendFocusEventToFX `in EDT so I did that.
> But it seems in this particular method, it is only accessed in FX thread as is mentioned so reverted..

Right, I only meant this specific instance (and the usage later on in this same lambda). It looks good now.

>> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 1078:
>> 
>>> 1076:             stagePeer = embeddedStage;
>>> 1077:             var hStagePeer = stagePeer;
>>> 1078:             if (hStagePeer == null) {
>> 
>> If this is always invoked from the FX thread, you don't need to locally capture the peers.
>
> but down below it is accessed in EDT so I did the local capture

Yes, you are right.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2542119249
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2542126656

From angorya at openjdk.org  Wed Nov 19 15:36:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 19 Nov 2025 15:36:03 GMT
Subject: RFR: 8371981: Wrong split caret positioning with mixed text
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 Nov 2025 20:04:42 GMT, Andy Goryachev  wrote:

> Fixing a silly mistake - mixed up `lineX2` and `lineY` parameters in `PrismTextLayout`.

interesting: github/SKARA does not send notification about mismatch in the title.

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

PR Comment: https://git.openjdk.org/jfx/pull/1976#issuecomment-3553365749

From angorya at openjdk.org  Wed Nov 19 15:41:13 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 19 Nov 2025 15:41:13 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v2]
In-Reply-To: 
References: 
 <6xWWnVedU5-eehKPlHbORXT3dxtIoP7WFyvqQSmyWbk=.048ed0ae-384f-4ffc-9b78-5872fe7b91db@github.com>
 
 
Message-ID: 

On Wed, 19 Nov 2025 00:38:43 GMT, Nir Lisker  wrote:

>> modules/javafx.base/src/main/java/javafx/util/converter/DateTimeStringConverter.java line 115:
>> 
>>> 113:                 getSpecialziedDateFormat(dateStyle, timeStyle, locale) :
>>> 114:                 new SimpleDateFormat(pattern, locale);
>>> 115:         dateFormat.setLenient(false);
>> 
>> Would setting `lenient=false` constitute a change in functionality?
>
> Why would it? It was the same before this change?

Not exactly, if I read it right.
The lenient flag is not set if the format is specified in the constructor - see L204 in the original class.  The new code clears this flag regardless.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2542558215

From angorya at openjdk.org  Wed Nov 19 16:00:42 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 19 Nov 2025 16:00:42 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 19 Nov 2025 08:54:27 GMT, Marius Hanl  wrote:

>> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`.
>> 
>> 
>> ### NOTES
>> 
>> - this PR depends on https://github.com/openjdk/jfx/pull/1974
>> - the fix can be verified visually using the latest Monkey Tester
>> 
>> Screenshot 2025-11-17 at 13 43 12
>
> modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/util/RichUtils.java line 751:
> 
>> 749:     // with the author's permission
>> 750:     /** returns a parent of the specified type, or null.  if node is an instance of the specified class, returns node */
>> 751:     public static  T getAncestorOfClass(Class c, Node node) {
> 
> I would really recommend to not do anything like that. Normally, the layouting system, especially when requesting a layout should work and bubble up correctly. I wonder why this is needed. And if we found a special case, if we can solve it better.
> 
> Background: In the past projects, I often saw code like that and it turned out that this was never needed. It is often less readable and hurts the performance a bit. 
> We also improve coupling between components, which I would not recommend as well. Especially since subclasses can change a lot and it would be nice if everything still work out of the box.

Thank you @Maran23 for looking into this PR!

My experience is exactly opposite - I do use it often.  The `Node` (or `JComponent`) hierarchy is a hierarchy, explicitly retaining the pointers to the each member's parent.

A specific member can be a child of a certain Parent, direct or otherwise, by design, and this method allows to get to that parent easily.

Let me ask you this - what is the alternative?  Maintain a duplicate pointer?

Also, keep in mind this is not public API, it's a utility.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2542629583

From jvos at openjdk.org  Wed Nov 19 16:05:42 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 19 Nov 2025 16:05:42 GMT
Subject: [jfx21u] RFR: 8361893: Update libxml2 to 2.14.5
Message-ID: <-exLxA8dLRUWLdSVsFxfdJjkrYIlJu4pfwwqdkJyAXA=.27e9179c-5776-440a-8ece-96c3ca9bb304@github.com>

Hi all,

This pull request contains a backport of commit [15c50c20](https://github.com/openjdk/jfx/commit/15c50c20b80a9287d5b136a197454eabac604a34) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Hima Bindu Meda on 15 Sep 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport 15c50c20b80a9287d5b136a197454eabac604a34

Changes: https://git.openjdk.org/jfx21u/pull/104/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361893
  Stats: 50107 lines in 105 files changed: 12675 ins; 16590 del; 20842 mod
  Patch: https://git.openjdk.org/jfx21u/pull/104.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/104/head:pull/104

PR: https://git.openjdk.org/jfx21u/pull/104

From angorya at openjdk.org  Wed Nov 19 16:16:41 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 19 Nov 2025 16:16:41 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v2]
In-Reply-To: 
References: 
 <6xWWnVedU5-eehKPlHbORXT3dxtIoP7WFyvqQSmyWbk=.048ed0ae-384f-4ffc-9b78-5872fe7b91db@github.com>
 
 
Message-ID: 

On Wed, 19 Nov 2025 00:42:03 GMT, Nir Lisker  wrote:

>> modules/javafx.base/src/main/java/javafx/util/StringConverter.java line 38:
>> 
>>> 36: /// - Except for `DefaultStringConverter`, formatting `null` returns an empty string, otherwise the type's `toString` is
>>> 37: /// used if it is suitable; parsing `null` or an empty string returns `null`.
>>> 38: /// - Immutable (the same converter can be reused).
>> 
>> Is this true? 
>> I recall some formatters having a state, but I don't remember which...
>
> Some do, but that state is immutable. Converters build a formatter/parser on construction (if at all needed) and use it for the duration of their existence. There are some deprecations that we need to do regarding inspecting the internal state.

This is what `DateFormat` javadoc says:


Synchronization
Date formats are not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally.


As long as the `DateTimeStringConverter` is used only in the context of the FX application thread, we should be fine.  But can we guarantee that the application code does not try to call it from other threads?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2542594368

From angorya at openjdk.org  Wed Nov 19 16:16:42 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 19 Nov 2025 16:16:42 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v4]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 19 Nov 2025 00:30:53 GMT, Nir Lisker  wrote:

>> I second John's suggestion with `this.`.  It matters when refactoring, even with an IDE.
>
>> I second John's suggestion with `this.`. It matters when refactoring, even with an IDE.
> 
> I'm not sure what you want me to change here exactly. Is it about renaming parameters (see [this discussion](https://github.com/openjdk/jfx/pull/1880#discussion_r2297668458)), or not using `this`, which you didn't seem to mind [here](https://github.com/openjdk/jfx/pull/1880#discussion_r2297721228)?

I meant to suggest using `this` when parameter name is the same as the field name.  Even though the compiler and IDE know which is which, the IDE might stumble during refactoring.

L50

chrono = Objects.requireNonNullElse(chrono, DEFAULT_CHRONO);

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2542576776

From psadhukhan at openjdk.org  Wed Nov 19 16:30:01 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Nov 2025 16:30:01 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v8]
In-Reply-To: 
References: 
Message-ID: 

> 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

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/1968/files
  - new: https://git.openjdk.org/jfx/pull/1968/files/4049ad67..f08b7417

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

  Stats: 8 lines in 3 files changed: 2 ins; 2 del; 4 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 psadhukhan at openjdk.org  Wed Nov 19 16:30:05 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Nov 2025 16:30:05 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v7]
In-Reply-To: <2UT7Kzei56qYAPki0lpEQV5Ezf0GRMNgxmWKe4PHvpI=.49c9d727-a551-41eb-99d9-dc62265c7856@github.com>
References: 
 
 <2UT7Kzei56qYAPki0lpEQV5Ezf0GRMNgxmWKe4PHvpI=.49c9d727-a551-41eb-99d9-dc62265c7856@github.com>
Message-ID: 

On Wed, 19 Nov 2025 14:04:11 GMT, Kevin Rushforth  wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedScene.java line 160:
> 
>> 158:                 if (getSceneState() != null) {
>> 159:                     updateSceneState();
>> 160:                 }
> 
> None of the other calls to `updateSceneState()` check for a null `sceneState`. Why is this is the only one that needs to? If it is needed, it might be safer to move the null check into `updateSceneState` itself.

We were getting this so it is needed

java.lang.NullPointerException: Cannot invoke "com.sun.javafx.tk.quantum.SceneState.update()" because "this.sceneState" is null
        at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.GlassScene.updateSceneState(GlassScene.java:253)
        at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.EmbeddedScene.lambda$setPixelScaleFactors$1(EmbeddedScene.java:158)
        at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:447)
        at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.EmbeddedScene.lambda$setPixelScaleFactors$0(EmbeddedScene.java:157)
        at javafx.graphics at 26-internal/com.sun.javafx.application.PlatformImpl.lambda$runLater$0(PlatformImpl.java:424)
        at javafx.graphics at 26-internal/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
        at javafx.graphics at 26-internal/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)

> tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 103:
> 
>> 101:             Thread.sleep(100);
>> 102:             Platform.runLater(() -> contentPane.setScene(webView.getScene()));
>> 103:             Thread.sleep(100);
> 
> With a `sleep(100)` this only occasionally gets an exception when I run it without your fix. I recommend `sleep(1)` which is what the manual test does. The test will take less time and also be a better stress test.

ok modified

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2542740240
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2542740799

From jvos at openjdk.org  Wed Nov 19 16:30:08 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 19 Nov 2025 16:30:08 GMT
Subject: [jfx21u] RFR: 8368691: Update libxml2 to 2.14.6
Message-ID: <1Txr0NdDtTLW6Ig5yXp40PaMPMPXE8PO269tHVKLhGw=.77a6b3f5-3ad1-4106-8cd3-32ff843c87cd@github.com>

Hi all,

This pull request contains a backport of commit 6ab42f99 from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 6 Oct 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport 6ab42f99914c1d1e504432957aba992e2b98e377

Changes: https://git.openjdk.org/jfx21u/pull/105/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=105&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368691
  Stats: 123 lines in 16 files changed: 74 ins; 11 del; 38 mod
  Patch: https://git.openjdk.org/jfx21u/pull/105.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/105/head:pull/105

PR: https://git.openjdk.org/jfx21u/pull/105

From jvos at openjdk.org  Wed Nov 19 16:31:14 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 19 Nov 2025 16:31:14 GMT
Subject: [jfx17u] Integrated: 8361893: Update libxml2 to 2.14.5
In-Reply-To: 
References: 
Message-ID: 

On Wed, 19 Nov 2025 16:07:21 GMT, Johan Vos  wrote:

> Hi all,
> 
> This pull request contains a backport of commit 15c50c20 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 15 Sep 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 49a2b953
Author:    Johan Vos 
URL:       https://git.openjdk.org/jfx17u/commit/49a2b9531ce90ab4b2686cca8e03d2bb7dd4e31f
Stats:     50107 lines in 105 files changed: 12675 ins; 16590 del; 20842 mod

8361893: Update libxml2 to 2.14.5

Backport-of: 15c50c20b80a9287d5b136a197454eabac604a34

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

PR: https://git.openjdk.org/jfx17u/pull/241

From jvos at openjdk.org  Wed Nov 19 16:31:13 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 19 Nov 2025 16:31:13 GMT
Subject: [jfx17u] Integrated: 8361893: Update libxml2 to 2.14.5
Message-ID: 

Hi all,

This pull request contains a backport of commit 15c50c20 from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 15 Sep 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport 15c50c20b80a9287d5b136a197454eabac604a34

Changes: https://git.openjdk.org/jfx17u/pull/241/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=241&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361893
  Stats: 50107 lines in 105 files changed: 12675 ins; 16590 del; 20842 mod
  Patch: https://git.openjdk.org/jfx17u/pull/241.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/241/head:pull/241

PR: https://git.openjdk.org/jfx17u/pull/241

From jvos at openjdk.org  Wed Nov 19 16:43:00 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 19 Nov 2025 16:43:00 GMT
Subject: [jfx21u] Integrated: 8368691: Update libxml2 to 2.14.6
In-Reply-To: <1Txr0NdDtTLW6Ig5yXp40PaMPMPXE8PO269tHVKLhGw=.77a6b3f5-3ad1-4106-8cd3-32ff843c87cd@github.com>
References: <1Txr0NdDtTLW6Ig5yXp40PaMPMPXE8PO269tHVKLhGw=.77a6b3f5-3ad1-4106-8cd3-32ff843c87cd@github.com>
Message-ID: 

On Wed, 19 Nov 2025 16:23:18 GMT, Johan Vos  wrote:

> Hi all,
> 
> This pull request contains a backport of commit 6ab42f99 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 6 Oct 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 3b6db621
Author:    Johan Vos 
URL:       https://git.openjdk.org/jfx21u/commit/3b6db621c5706608582d9ba3c0ce5cc08d99e5e8
Stats:     123 lines in 16 files changed: 74 ins; 11 del; 38 mod

8368691: Update libxml2 to 2.14.6

Backport-of: 6ab42f99914c1d1e504432957aba992e2b98e377

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

PR: https://git.openjdk.org/jfx21u/pull/105

From jvos at openjdk.org  Wed Nov 19 16:43:33 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 19 Nov 2025 16:43:33 GMT
Subject: [jfx21u] RFR: 8370632: Additional libxslt 1.1.43 fixes
Message-ID: 

Hi all,

This pull request contains a backport of commit 478e1ad4 from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 28 Oct 2025 and was reviewed by Kevin Rushforth and Jay Bhaskar.

Thanks!

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

Commit messages:
 - Backport 478e1ad43b2feaa4fa1d5be656b78cadf2316ba3

Changes: https://git.openjdk.org/jfx21u/pull/106/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=106&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370632
  Stats: 215 lines in 3 files changed: 83 ins; 14 del; 118 mod
  Patch: https://git.openjdk.org/jfx21u/pull/106.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/106/head:pull/106

PR: https://git.openjdk.org/jfx21u/pull/106

From jvos at openjdk.org  Wed Nov 19 16:43:38 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 19 Nov 2025 16:43:38 GMT
Subject: [jfx17u] Integrated: 8368691: Update libxml2 to 2.14.6
Message-ID: 

Hi all,

This pull request contains a backport of commit 6ab42f99 from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 6 Oct 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport 6ab42f99914c1d1e504432957aba992e2b98e377

Changes: https://git.openjdk.org/jfx17u/pull/242/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=242&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368691
  Stats: 123 lines in 16 files changed: 74 ins; 11 del; 38 mod
  Patch: https://git.openjdk.org/jfx17u/pull/242.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/242/head:pull/242

PR: https://git.openjdk.org/jfx17u/pull/242

From jvos at openjdk.org  Wed Nov 19 16:43:39 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 19 Nov 2025 16:43:39 GMT
Subject: [jfx17u] Integrated: 8368691: Update libxml2 to 2.14.6
In-Reply-To: 
References: 
Message-ID: 

On Wed, 19 Nov 2025 16:22:50 GMT, Johan Vos  wrote:

> Hi all,
> 
> This pull request contains a backport of commit 6ab42f99 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 6 Oct 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 8f39f0c2
Author:    Johan Vos 
URL:       https://git.openjdk.org/jfx17u/commit/8f39f0c27f048a67ac59c23c508b534738d299bc
Stats:     123 lines in 16 files changed: 74 ins; 11 del; 38 mod

8368691: Update libxml2 to 2.14.6

Backport-of: 6ab42f99914c1d1e504432957aba992e2b98e377

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

PR: https://git.openjdk.org/jfx17u/pull/242

From jvos at openjdk.org  Wed Nov 19 16:55:45 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 19 Nov 2025 16:55:45 GMT
Subject: [jfx21u] Integrated: 8370632: Additional libxslt 1.1.43 fixes
In-Reply-To: 
References: 
Message-ID: 

On Wed, 19 Nov 2025 16:35:10 GMT, Johan Vos  wrote:

> Hi all,
> 
> This pull request contains a backport of commit 478e1ad4 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 28 Oct 2025 and was reviewed by Kevin Rushforth and Jay Bhaskar.
> 
> Thanks!

This pull request has now been integrated.

Changeset: dafbd744
Author:    Johan Vos 
URL:       https://git.openjdk.org/jfx21u/commit/dafbd744214c7b61a04b178a6aad729dd326adbb
Stats:     215 lines in 3 files changed: 83 ins; 14 del; 118 mod

8370632: Additional libxslt 1.1.43 fixes

Backport-of: 478e1ad43b2feaa4fa1d5be656b78cadf2316ba3

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

PR: https://git.openjdk.org/jfx21u/pull/106

From jvos at openjdk.org  Wed Nov 19 16:56:58 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 19 Nov 2025 16:56:58 GMT
Subject: [jfx21u] Integrated: 8361893: Update libxml2 to 2.14.5
In-Reply-To: <-exLxA8dLRUWLdSVsFxfdJjkrYIlJu4pfwwqdkJyAXA=.27e9179c-5776-440a-8ece-96c3ca9bb304@github.com>
References: <-exLxA8dLRUWLdSVsFxfdJjkrYIlJu4pfwwqdkJyAXA=.27e9179c-5776-440a-8ece-96c3ca9bb304@github.com>
Message-ID: 

On Wed, 19 Nov 2025 15:55:45 GMT, Johan Vos  wrote:

> Hi all,
> 
> This pull request contains a backport of commit [15c50c20](https://github.com/openjdk/jfx/commit/15c50c20b80a9287d5b136a197454eabac604a34) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 15 Sep 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: dae8e752
Author:    Johan Vos 
URL:       https://git.openjdk.org/jfx21u/commit/dae8e752cf963f09ca29347983bc52fbbcbbd521
Stats:     50107 lines in 105 files changed: 12675 ins; 16590 del; 20842 mod

8361893: Update libxml2 to 2.14.5

Backport-of: 15c50c20b80a9287d5b136a197454eabac604a34

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

PR: https://git.openjdk.org/jfx21u/pull/104

From jvos at openjdk.org  Wed Nov 19 16:58:58 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 19 Nov 2025 16:58:58 GMT
Subject: [jfx17u] Integrated: 8370632: Additional libxslt 1.1.43 fixes
In-Reply-To: 
References: 
Message-ID: 

On Wed, 19 Nov 2025 16:35:24 GMT, Johan Vos  wrote:

> Hi all,
> 
> This pull request contains a backport of commit 478e1ad4 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 28 Oct 2025 and was reviewed by Kevin Rushforth and Jay Bhaskar.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 4d32dec1
Author:    Johan Vos 
URL:       https://git.openjdk.org/jfx17u/commit/4d32dec1f053d265aff195fe083f1bd049bc6a98
Stats:     215 lines in 3 files changed: 83 ins; 14 del; 118 mod

8370632: Additional libxslt 1.1.43 fixes

Backport-of: 478e1ad43b2feaa4fa1d5be656b78cadf2316ba3

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

PR: https://git.openjdk.org/jfx17u/pull/243

From jvos at openjdk.org  Wed Nov 19 16:58:57 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 19 Nov 2025 16:58:57 GMT
Subject: [jfx17u] Integrated: 8370632: Additional libxslt 1.1.43 fixes
Message-ID: 

Hi all,

This pull request contains a backport of commit 478e1ad4 from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 28 Oct 2025 and was reviewed by Kevin Rushforth and Jay Bhaskar.

Thanks!

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

Commit messages:
 - Backport 478e1ad43b2feaa4fa1d5be656b78cadf2316ba3

Changes: https://git.openjdk.org/jfx17u/pull/243/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=243&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370632
  Stats: 215 lines in 3 files changed: 83 ins; 14 del; 118 mod
  Patch: https://git.openjdk.org/jfx17u/pull/243.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/243/head:pull/243

PR: https://git.openjdk.org/jfx17u/pull/243

From kcr at openjdk.org  Wed Nov 19 16:56:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 19 Nov 2025 16:56:57 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 19 Nov 2025 16:30:01 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

Looks good with one more minor suggestion. As mentioned offline, we'll do a CI headful test run.

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassScene.java line 254:

> 252:         // should only be called on the event thread
> 253:         if (getSceneState() != null) {
> 254:             sceneState.update();

Suggestion:

        if (sceneState != null) {
            sceneState.update();


Minor: it seems cleaner to access `sceneState` directly in both the test and usage rather than mixing them.

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

PR Review: https://git.openjdk.org/jfx/pull/1968#pullrequestreview-3483801411
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2542835636

From psadhukhan at openjdk.org  Wed Nov 19 17:14:51 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Nov 2025 17:14:51 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v9]
In-Reply-To: 
References: 
Message-ID: 

> 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

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

  Review comment + OutputRedirect

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1968/files
  - new: https://git.openjdk.org/jfx/pull/1968/files/f08b7417..f66fff5c

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

  Stats: 21 lines in 2 files changed: 4 ins; 8 del; 9 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 psadhukhan at openjdk.org  Wed Nov 19 17:14:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Nov 2025 17:14:55 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 19 Nov 2025 16:52:08 GMT, Kevin Rushforth  wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassScene.java line 254:
> 
>> 252:         // should only be called on the event thread
>> 253:         if (getSceneState() != null) {
>> 254:             sceneState.update();
> 
> Suggestion:
> 
>         if (sceneState != null) {
>             sceneState.update();
> 
> 
> Minor: it seems cleaner to access `sceneState` directly in both the test and usage rather than mixing them.

ok

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2542898330

From kcr at openjdk.org  Wed Nov 19 17:14:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 19 Nov 2025 17:14:57 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 19 Nov 2025 16:30:01 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 125:

> 123:     }
> 124: }
> 125: 

Very minor: there is an extra blank line here that you might remove.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2542888149

From angorya at openjdk.org  Wed Nov 19 18:12:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 19 Nov 2025 18:12:10 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 19 Nov 2025 00:59:19 GMT, Nir Lisker  wrote:

>> Refactoring of all `StringConverter`s and their tests. General notes:
>> * The documentation language has been unified and `null` parameter rules have been documented.
>> *  Tests have been cleaned up in the vein of https://github.com/openjdk/jfx/pull/1759 and unneeded `@BeforeAll`s were removed.
>> * Internal fields were made `private final` to guarantee immutability.
>> 
>>  Incremental commits are provided for easier reviewing:
>> 
>> ### Parent classes
>> * `StringConverter`: updated documentation
>> * `BaseStringConverter`: a new internal class that implements repeated code from converter implementations and serves as an intermediate superclass. It does empty and `null` string checks that are handled uniformly, except for `DefaultStringConverter`, which has a different formatting mechanism.
>> 
>> ### Primitive-related converters
>> * All primitive (wrapper) converters also document their formatting and parsing mechanism since these are "well-established".
>> 
>> ### Format converter
>> * Checked for `null` during constriction time to avoid runtime NPEs.
>> * There is no test class for this converter. A followup might be desirable.
>> * A followup should deprecate for removal `protected Format getFormat()` (as in [JDK-8314597](https://bugs.openjdk.org/browse/JDK-8314597) and [JDK-8260475](https://bugs.openjdk.org/browse/JDK-8260475)).
>> 
>> ### Number and subclasses converters
>> * The intermediate `locale` and `pattern` fields were removed (along with their tests). The class generated a new formatter from these on each call. This only makes sense for mutable fields where the resulting formatter can change, but here the formatter can be computed once on construction and stored.
>> * The only difference between these classes is a single method for creating a format from a `null` pattern, which was encapsulated in the `getSpecializedNumberFormat` method.
>> * The terminally deprecated `protected NumberFormat getNumberFormat()` was removed. Can be split to its own issue if preferred. In my opinion, it shouldn't exist even internally since testing the internal formatter doesn't help. The only tests here should be for to/from strings, and these are lacking. A followup can be filed for adding more conversion tests.
>> 
>> ### Date/Time converters
>> * Added a documentation note advising users to use the `java.time` classes instead of the old `Date` class.
>> * As with Number converters, only the `dateFormat` field was kept, which is created once on construction instead of on each...
>
> Nir Lisker has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge master
>  - Fix typo
>  - Removed super() invocations
>  - review comments 2
>  - review comments 1
>  - LocalDate/Time converters
>  - Date/Time converters
>  - Number and subclasses converters
>  - Format converter
>  - Primitive-related converters
>  - ... and 1 more: https://git.openjdk.org/jfx/compare/f75fa093...a030ce58

modules/javafx.base/src/main/java/javafx/util/converter/CurrencyStringConverter.java line 37:

> 35: 
> 36:     /// Creates a `CurrencyStringConverter` that uses a formatter/parser based on the user's [Locale].
> 37:     public CurrencyStringConverter() {}

very, very minor: I wish you wouldn't do `{}` - if anything needs to be inserted, it widens the diff.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2543067295

From kcr at openjdk.org  Wed Nov 19 18:30:42 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 19 Nov 2025 18:30:42 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 19 Nov 2025 17:14:51 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment + OutputRedirect

Updated test looks good with one additional suggestion.

tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 99:

> 97:                 Platform.runLater(() -> contentPane.setScene(webView.getScene()));
> 98:                 Thread.sleep(1);
> 99:             }

The calls in the loop to the FX and AWT threads are asynchronous, so I recommend adding the following after the loop to ensure that both threads are finished with the work submitted in the loops:


            // Wait for both threads to process the earlier runnables
            SwingUtilities.invokeAndWait(() -> {});
            Util.runAndWait(() -> {});

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

PR Review: https://git.openjdk.org/jfx/pull/1968#pullrequestreview-3484177788
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2543122814

From angorya at openjdk.org  Wed Nov 19 20:01:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 19 Nov 2025 20:01:46 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 19 Nov 2025 17:14:51 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment + OutputRedirect

Looked at how `stage`, `scene`, `stagePeer`, and `scenePeer` fields are used, looks good.  Left some minor comments for the follow-up/redesign.

Only the test needs to be changed, otherwise looks good.  Thank you @prsadhuk for persistence!

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassScene.java line 253:

> 251:     final void updateSceneState() {
> 252:         // should only be called on the event thread
> 253:         if (sceneState != null) {

L253, this is the original code, but I found the "event thread" words misleading - too similar to "event dispatcher" thread.  Should it be "fx application thread"?

modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 527:

> 525:                 if (hStagePeer != null) {
> 526:                     int focusCause = AbstractEvents.FOCUSEVENT_ACTIVATED;
> 527:                     hStagePeer.setFocused(true, focusCause);

suggestion (for a follow up): document which methods in `EmbeddedStageInterface` can be called from which thread.

`setFocused()` method seems to be thread-safe.

modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 1021:

> 1019:             if ((stage != null) && !stage.isShowing()) {
> 1020:                 stage.show();
> 1021:                 SwingNodeHelper.runOnEDT(() -> sendMoveEventToFX());

for possible followup: L1032 the field returned in `getInputMethodRequests()` in `EmbeddedScene` is not `volatile`.

modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 1116:

> 1114:                 dnd = new SwingDnD(JFXPanel.this, hScenePeer);
> 1115:                 dnd.addNotify();
> 1116:                 if (hScenePeer != null) {

this null check can be removed, since the code will bail out on L1106 if `hScenePeer == null`

tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 98:

> 96:                 Thread.sleep(1);
> 97:                 Platform.runLater(() -> contentPane.setScene(webView.getScene()));
> 98:                 Thread.sleep(1);

discussed offline:

we'll should add some code (`invokeAndWait` + `Util.runAndWait`) here to make sure all the prior events are processed before leaving the try block and doing `OutputRedirect.checkAndRestoreStderr();`

Also, maybe add a `@Timeout` to make sure the test does not hang.

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

PR Review: https://git.openjdk.org/jfx/pull/1968#pullrequestreview-3484167341
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2543126404
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2543329198
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2543356982
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2543363338
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2543115097

From andy.goryachev at oracle.com  Wed Nov 19 20:14:33 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 19 Nov 2025 20:14:33 +0000
Subject: JDK-8372053: RichTextArea keyboard navigation for RTL paragraph
 should be the opposite
In-Reply-To: 
References: 
Message-ID: 

Thank you for providing the feedback and further clarification!

I've got confused because the reproducer in the ticket uses TextArea.  You are right though - the RTL navigation should change with the ParagraphDirection attribute change.  I'll probably just close this ticket and create a new one for the RichTextArea, with your clarifications.

As for RTL support in general - we are still working on it, the RTL functionality in JavaFX is incomplete (see https://bugs.openjdk.org/browse/JDK-8343557 ).  Stay tuned.

And thanks again for checking out RichTextArea and filing the issues - looking forward to it.

-andy



From: openjfx-dev  on behalf of Fouad Almalki 
Date: Tuesday, November 18, 2025 at 17:18
To: openjfx-dev at openjdk.org 
Subject: JDK-8372053: RichTextArea keyboard navigation for RTL paragraph should be the opposite

Hi,

I am the original reporter of the bug JDK-8372053. The issue I was referring to was with the incubator RichTextArea not the regular TextArea. The issue happens when the RichTextArea's node orientation is default (LTR) but the paragraph is right-aligned (TextAlignment.RIGHT and ParagraphDirection.RIGHT_TO_LEFT) with RTL text.

Current behavior is: RIGHT moves caret forward, and LEFT moves caret backward.
Expected behavior is: LEFT moves caret forward, and RIGHT moves caret backward.



Also, currently the text selection of 2 lines of RTL text (does not matter aligned to left or right) is a little buggy. When positioning the caret at the start of second line, then pressing Shift+LEFT:

Current behavior is: both lines will be highlighted and the caret will be at the end of the first line (wrong highlight but correct caret position). If pressing Shift+LEFT again, both lines will still be highlighted and the caret will be at the end of the first line - 1 (again, wrong highlight but correct caret position).
Expected behavior is: The text highlight should be synced with the caret position.



I also reported 2 more issues last week but did not appear yet on bugs.openjdk.org.

Best Regards~
Fouad almalki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From nlisker at openjdk.org  Wed Nov 19 20:19:34 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 19 Nov 2025 20:19:34 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v2]
In-Reply-To: 
References: 
 <6xWWnVedU5-eehKPlHbORXT3dxtIoP7WFyvqQSmyWbk=.048ed0ae-384f-4ffc-9b78-5872fe7b91db@github.com>
 
 
 
Message-ID: 

On Wed, 19 Nov 2025 15:38:44 GMT, Andy Goryachev  wrote:

>> Why would it? It was the same before this change?
>
> Not exactly, if I read it right.
> The lenient flag is not set if the format is specified in the constructor - see L204 in the original class.  The new code clears this flag regardless.

Maybe I'm missing something. The constructor that takes a `DateFormat` directly in the new code is

    public DateTimeStringConverter(DateFormat dateFormat) {
        this.dateFormat = dateFormat != null ? dateFormat :
                create(DEFAULT_LOCALE, DateFormat.DEFAULT, DateFormat.DEFAULT, null);
    }

So `DateFormat#create` isn't called and `setLenient` isn't called.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2543428225

From nlisker at openjdk.org  Wed Nov 19 20:46:16 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 19 Nov 2025 20:46:16 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v4]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 19 Nov 2025 15:43:09 GMT, Andy Goryachev  wrote:

>>> I second John's suggestion with `this.`. It matters when refactoring, even with an IDE.
>> 
>> I'm not sure what you want me to change here exactly. Is it about renaming parameters (see [this discussion](https://github.com/openjdk/jfx/pull/1880#discussion_r2297668458)), or not using `this`, which you didn't seem to mind [here](https://github.com/openjdk/jfx/pull/1880#discussion_r2297721228)?
>
> I meant to suggest using `this` when parameter name is the same as the field name.  Even though the compiler and IDE know which is which, the IDE might stumble during refactoring.
> 
> L50
> 
> chrono = Objects.requireNonNullElse(chrono, DEFAULT_CHRONO);

I don't understand this either :)

What is the field name in L50?

This is the discussed code:

    // fields
    private final DateTimeFormatter formatter;
    private final DateTimeFormatter parser;

    // constructor
    protected BaseTemporalStringConverter(FormatStyle dateStyle, FormatStyle timeStyle, Locale locale, Chronology chrono) {
        locale = Objects.requireNonNullElse(locale, DEFAULT_LOCALE);        // local variable reassignment
        chrono = Objects.requireNonNullElse(chrono, DEFAULT_CHRONO);        // local variable reassignment
        formatter = createFormatter(dateStyle, timeStyle, locale, chrono);  // field assignment
        parser = createParser(dateStyle, timeStyle, locale, chrono);        // field assignment
    }

John is against local variable reassignment, which I understand, but I find it useful in the specific cases of "curating" like clamping and non-null-ing. It avoids mistakes like this:

void area(long length, long width, Shape shape) {
    posLength = length <= 0 ? 1 : length;
    posWidth = width <= 0 ? 1 : width;

    if (shape == TRIANGLE) {
        return (double) (length * width) / 2;
    } else if (shape == RECT) {
        return posLength * posWidth;
    }
}


John also wants `this` when doing field assignments (from what I understood), which one has to use if the parameter name is the same as the field (otherwise I don't think the IDE can know which is which). If it's unambiguous, I tend to avoid `this` when it's not required except for some cases such as uniformity.

I don't mind adding `this` to field assignments or renaming local variables, I just need to understand to consensus.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2543513572

From angorya at openjdk.org  Wed Nov 19 20:46:17 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 19 Nov 2025 20:46:17 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v2]
In-Reply-To: 
References: 
 <6xWWnVedU5-eehKPlHbORXT3dxtIoP7WFyvqQSmyWbk=.048ed0ae-384f-4ffc-9b78-5872fe7b91db@github.com>
 
 
 
 
Message-ID: 

On Wed, 19 Nov 2025 20:15:46 GMT, Nir Lisker  wrote:

>> Not exactly, if I read it right.
>> The lenient flag is not set if the format is specified in the constructor - see L204 in the original class.  The new code clears this flag regardless.
>
> Maybe I'm missing something. The constructor that takes a `DateFormat` directly in the new code is
> 
>     public DateTimeStringConverter(DateFormat dateFormat) {
>         this.dateFormat = dateFormat != null ? dateFormat :
>                 create(DEFAULT_LOCALE, DateFormat.DEFAULT, DateFormat.DEFAULT, null);
>     }
> 
> So `DateFormat#create` isn't called and `setLenient` isn't called.

you are right!  I did not see it's not a constructor (must be turning blind).  please disregard.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2543509924

From angorya at openjdk.org  Wed Nov 19 20:52:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 19 Nov 2025 20:52:23 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v4]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: <3B1RGodbgKq4MrVTrNAicJfAihKuCSTvpFoihslAJwE=.d1aea273-4fce-4e0f-902f-1bdb12298609@github.com>

On Wed, 19 Nov 2025 20:42:58 GMT, Nir Lisker  wrote:

>> I meant to suggest using `this` when parameter name is the same as the field name.  Even though the compiler and IDE know which is which, the IDE might stumble during refactoring.
>> 
>> L50
>> 
>> chrono = Objects.requireNonNullElse(chrono, DEFAULT_CHRONO);
>
> I don't understand this either :)
> 
> What is the field name in L50?
> 
> This is the discussed code:
> 
>     // fields
>     private final DateTimeFormatter formatter;
>     private final DateTimeFormatter parser;
> 
>     // constructor
>     protected BaseTemporalStringConverter(FormatStyle dateStyle, FormatStyle timeStyle, Locale locale, Chronology chrono) {
>         locale = Objects.requireNonNullElse(locale, DEFAULT_LOCALE);        // local variable reassignment
>         chrono = Objects.requireNonNullElse(chrono, DEFAULT_CHRONO);        // local variable reassignment
>         formatter = createFormatter(dateStyle, timeStyle, locale, chrono);  // field assignment
>         parser = createParser(dateStyle, timeStyle, locale, chrono);        // field assignment
>     }
> 
> John is against local variable reassignment, which I understand, but I find it useful in the specific cases of "curating" like clamping and non-null-ing. It avoids mistakes like this:
> 
> void area(long length, long width, Shape shape) {
>     posLength = length <= 0 ? 1 : length;
>     posWidth = width <= 0 ? 1 : width;
> 
>     if (shape == TRIANGLE) {
>         return (double) (length * width) / 2;
>     } else if (shape == RECT) {
>         return posLength * posWidth;
>     }
> }
> 
> 
> John also wants `this` when doing field assignments (from what I understood), which one has to use if the parameter name is the same as the field (otherwise I don't think the IDE can know which is which). If it's unambiguous, I tend to avoid `this` when it's not required except for some cases such as uniformity.
> 
> I don't mind adding `this` to field assignments or renaming local variables, I just need to understand to consensus.

I have to be careful when reviewing in github - I thought it was a field.  chrono is not a field, does not need `this`.

Parameter reassignment is ok (in my opinion).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2543526538

From angorya at openjdk.org  Wed Nov 19 20:52:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 19 Nov 2025 20:52:22 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 19 Nov 2025 00:59:19 GMT, Nir Lisker  wrote:

>> Refactoring of all `StringConverter`s and their tests. General notes:
>> * The documentation language has been unified and `null` parameter rules have been documented.
>> *  Tests have been cleaned up in the vein of https://github.com/openjdk/jfx/pull/1759 and unneeded `@BeforeAll`s were removed.
>> * Internal fields were made `private final` to guarantee immutability.
>> 
>>  Incremental commits are provided for easier reviewing:
>> 
>> ### Parent classes
>> * `StringConverter`: updated documentation
>> * `BaseStringConverter`: a new internal class that implements repeated code from converter implementations and serves as an intermediate superclass. It does empty and `null` string checks that are handled uniformly, except for `DefaultStringConverter`, which has a different formatting mechanism.
>> 
>> ### Primitive-related converters
>> * All primitive (wrapper) converters also document their formatting and parsing mechanism since these are "well-established".
>> 
>> ### Format converter
>> * Checked for `null` during constriction time to avoid runtime NPEs.
>> * There is no test class for this converter. A followup might be desirable.
>> * A followup should deprecate for removal `protected Format getFormat()` (as in [JDK-8314597](https://bugs.openjdk.org/browse/JDK-8314597) and [JDK-8260475](https://bugs.openjdk.org/browse/JDK-8260475)).
>> 
>> ### Number and subclasses converters
>> * The intermediate `locale` and `pattern` fields were removed (along with their tests). The class generated a new formatter from these on each call. This only makes sense for mutable fields where the resulting formatter can change, but here the formatter can be computed once on construction and stored.
>> * The only difference between these classes is a single method for creating a format from a `null` pattern, which was encapsulated in the `getSpecializedNumberFormat` method.
>> * The terminally deprecated `protected NumberFormat getNumberFormat()` was removed. Can be split to its own issue if preferred. In my opinion, it shouldn't exist even internally since testing the internal formatter doesn't help. The only tests here should be for to/from strings, and these are lacking. A followup can be filed for adding more conversion tests.
>> 
>> ### Date/Time converters
>> * Added a documentation note advising users to use the `java.time` classes instead of the old `Date` class.
>> * As with Number converters, only the `dateFormat` field was kept, which is created once on construction instead of on each...
>
> Nir Lisker has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge master
>  - Fix typo
>  - Removed super() invocations
>  - review comments 2
>  - review comments 1
>  - LocalDate/Time converters
>  - Date/Time converters
>  - Number and subclasses converters
>  - Format converter
>  - Primitive-related converters
>  - ... and 1 more: https://git.openjdk.org/jfx/compare/da0b1858...a030ce58

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1880#pullrequestreview-3484693098

From nlisker at openjdk.org  Wed Nov 19 21:04:11 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 19 Nov 2025 21:04:11 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v2]
In-Reply-To: 
References: 
 <6xWWnVedU5-eehKPlHbORXT3dxtIoP7WFyvqQSmyWbk=.048ed0ae-384f-4ffc-9b78-5872fe7b91db@github.com>
 
 
 
Message-ID: 

On Wed, 19 Nov 2025 15:48:19 GMT, Andy Goryachev  wrote:

>> Some do, but that state is immutable. Converters build a formatter/parser on construction (if at all needed) and use it for the duration of their existence. There are some deprecations that we need to do regarding inspecting the internal state.
>
> This is what `DateFormat` javadoc says:
> 
> 
> Synchronization
> Date formats are not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally.
> 
> 
> As long as the `DateTimeStringConverter` is used only in the context of the FX application thread, we should be fine.  But can we guarantee that the application code does not try to call it from other threads?

Huh, looks like even non-modifying methods like `DateFormat#parse` are not thread safe. The wording is still correct in that the classes are immutable, but in the specific case of the Java 8 Date/Time ones, they indeed need to reused on the same thread. I'll add a caveat.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2543556512

From nlisker at openjdk.org  Wed Nov 19 22:01:01 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 19 Nov 2025 22:01:01 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v5]
In-Reply-To: 
References: 
Message-ID: 

> Refactoring of all `StringConverter`s and their tests. General notes:
> * The documentation language has been unified and `null` parameter rules have been documented.
> *  Tests have been cleaned up in the vein of https://github.com/openjdk/jfx/pull/1759 and unneeded `@BeforeAll`s were removed.
> * Internal fields were made `private final` to guarantee immutability.
> 
>  Incremental commits are provided for easier reviewing:
> 
> ### Parent classes
> * `StringConverter`: updated documentation
> * `BaseStringConverter`: a new internal class that implements repeated code from converter implementations and serves as an intermediate superclass. It does empty and `null` string checks that are handled uniformly, except for `DefaultStringConverter`, which has a different formatting mechanism.
> 
> ### Primitive-related converters
> * All primitive (wrapper) converters also document their formatting and parsing mechanism since these are "well-established".
> 
> ### Format converter
> * Checked for `null` during constriction time to avoid runtime NPEs.
> * There is no test class for this converter. A followup might be desirable.
> * A followup should deprecate for removal `protected Format getFormat()` (as in [JDK-8314597](https://bugs.openjdk.org/browse/JDK-8314597) and [JDK-8260475](https://bugs.openjdk.org/browse/JDK-8260475)).
> 
> ### Number and subclasses converters
> * The intermediate `locale` and `pattern` fields were removed (along with their tests). The class generated a new formatter from these on each call. This only makes sense for mutable fields where the resulting formatter can change, but here the formatter can be computed once on construction and stored.
> * The only difference between these classes is a single method for creating a format from a `null` pattern, which was encapsulated in the `getSpecializedNumberFormat` method.
> * The terminally deprecated `protected NumberFormat getNumberFormat()` was removed. Can be split to its own issue if preferred. In my opinion, it shouldn't exist even internally since testing the internal formatter doesn't help. The only tests here should be for to/from strings, and these are lacking. A followup can be filed for adding more conversion tests.
> 
> ### Date/Time converters
> * Added a documentation note advising users to use the `java.time` classes instead of the old `Date` class.
> * As with Number converters, only the `dateFormat` field was kept, which is created once on construction instead of on each call.
> * As with Number converters, the `getSpecialzie...

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

  Clarify thread safety

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1880/files
  - new: https://git.openjdk.org/jfx/pull/1880/files/a030ce58..1b4248c5

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

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

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

From jhendrikx at openjdk.org  Thu Nov 20 01:07:11 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 20 Nov 2025 01:07:11 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v5]
In-Reply-To: <3B1RGodbgKq4MrVTrNAicJfAihKuCSTvpFoihslAJwE=.d1aea273-4fce-4e0f-902f-1bdb12298609@github.com>
References: 
 
 
 
 
 
 
 <3B1RGodbgKq4MrVTrNAicJfAihKuCSTvpFoihslAJwE=.d1aea273-4fce-4e0f-902f-1bdb12298609@github.com>
Message-ID: 

On Wed, 19 Nov 2025 20:48:24 GMT, Andy Goryachev  wrote:

>> I don't understand this either :)
>> 
>> What is the field name in L50?
>> 
>> This is the discussed code:
>> 
>>     // fields
>>     private final DateTimeFormatter formatter;
>>     private final DateTimeFormatter parser;
>> 
>>     // constructor
>>     protected BaseTemporalStringConverter(FormatStyle dateStyle, FormatStyle timeStyle, Locale locale, Chronology chrono) {
>>         locale = Objects.requireNonNullElse(locale, DEFAULT_LOCALE);        // local variable reassignment
>>         chrono = Objects.requireNonNullElse(chrono, DEFAULT_CHRONO);        // local variable reassignment
>>         formatter = createFormatter(dateStyle, timeStyle, locale, chrono);  // field assignment
>>         parser = createParser(dateStyle, timeStyle, locale, chrono);        // field assignment
>>     }
>> 
>> John is against local variable reassignment, which I understand, but I find it useful in the specific cases of "curating" like clamping and non-null-ing. It avoids mistakes like this:
>> 
>> void area(long length, long width, Shape shape) {
>>     posLength = length <= 0 ? 1 : length;
>>     posWidth = width <= 0 ? 1 : width;
>> 
>>     if (shape == TRIANGLE) {
>>         return (double) (length * width) / 2;
>>     } else if (shape == RECT) {
>>         return posLength * posWidth;
>>     }
>> }
>> 
>> 
>> John also wants `this` when doing field assignments (from what I understood), which one has to use if the parameter name is the same as the field (otherwise I don't think the IDE can know which is which). If it's unambiguous, I tend to avoid `this` when it's not required except for some cases such as uniformity.
>> 
>> I don't mind adding `this` to field assignments or renaming local variables, I just need to understand to consensus.
>
> I have to be careful when reviewing in github - I thought it was a field.  chrono is not a field, does not need `this`.
> 
> Parameter reassignment is ok (in my opinion).

I'm just making suggestions, feel free to ignore.

Reassignment of variables is IMHO always bad as it changes the meaning of variables halfway through code, so it should be minimized.  Parameter reassignment being 100% avoidable in all cases makes it possible to turn on an IDE warning/error to simply never allow that.

The reason I suggested `this` in this code is because it is 4 lines, that *look* to be doing the same thing, but in actuality are two parameter assignments, two field assignments.  I was basically suggesting to do either of these, so its clear these two pairs of lines are doing two different things (by avoiding parameter reassignment they become local variable declarations, by using `this` the two bottom lines are clearly different).

Anyway, this doesn't need an infinite discussion.  It's a "nit"; it's not like people can't figure out the code after doing a double take.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2544002828

From jhendrikx at openjdk.org  Thu Nov 20 01:14:18 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 20 Nov 2025 01:14:18 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 19 Nov 2025 22:01:01 GMT, Nir Lisker  wrote:

>> Refactoring of all `StringConverter`s and their tests. General notes:
>> * The documentation language has been unified and `null` parameter rules have been documented.
>> *  Tests have been cleaned up in the vein of https://github.com/openjdk/jfx/pull/1759 and unneeded `@BeforeAll`s were removed.
>> * Internal fields were made `private final` to guarantee immutability.
>> 
>>  Incremental commits are provided for easier reviewing:
>> 
>> ### Parent classes
>> * `StringConverter`: updated documentation
>> * `BaseStringConverter`: a new internal class that implements repeated code from converter implementations and serves as an intermediate superclass. It does empty and `null` string checks that are handled uniformly, except for `DefaultStringConverter`, which has a different formatting mechanism.
>> 
>> ### Primitive-related converters
>> * All primitive (wrapper) converters also document their formatting and parsing mechanism since these are "well-established".
>> 
>> ### Format converter
>> * Checked for `null` during constriction time to avoid runtime NPEs.
>> * There is no test class for this converter. A followup might be desirable.
>> * A followup should deprecate for removal `protected Format getFormat()` (as in [JDK-8314597](https://bugs.openjdk.org/browse/JDK-8314597) and [JDK-8260475](https://bugs.openjdk.org/browse/JDK-8260475)).
>> 
>> ### Number and subclasses converters
>> * The intermediate `locale` and `pattern` fields were removed (along with their tests). The class generated a new formatter from these on each call. This only makes sense for mutable fields where the resulting formatter can change, but here the formatter can be computed once on construction and stored.
>> * The only difference between these classes is a single method for creating a format from a `null` pattern, which was encapsulated in the `getSpecializedNumberFormat` method.
>> * The terminally deprecated `protected NumberFormat getNumberFormat()` was removed. Can be split to its own issue if preferred. In my opinion, it shouldn't exist even internally since testing the internal formatter doesn't help. The only tests here should be for to/from strings, and these are lacking. A followup can be filed for adding more conversion tests.
>> 
>> ### Date/Time converters
>> * Added a documentation note advising users to use the `java.time` classes instead of the old `Date` class.
>> * As with Number converters, only the `dateFormat` field was kept, which is created once on construction instead of on each...
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify thread safety

Marked as reviewed by jhendrikx (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1880#pullrequestreview-3485281477

From jhendrikx at openjdk.org  Thu Nov 20 01:14:20 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 20 Nov 2025 01:14:20 GMT
Subject: RFR: 8250802: Refactor StringConverter and its subclasses [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 25 Aug 2025 09:40:01 GMT, Nir Lisker  wrote:

>> modules/javafx.base/src/main/java/javafx/util/converter/FormatStringConverter.java line 42:
>> 
>>> 40:     private final Format format;
>>> 41: 
>>> 42:     /// Creates a `StringConverter` for arbitrary types that uses the given `Format`.
>> 
>> Shouldn't that be `FormatStringConverter` that it creates?
>> 
>> To be honest, I never bother repeating this on constructors, so I just write "Creates a new instance ... "
>
> All the converters used this language prior. The language on constructors isn't unified across JavaFX and the JDK.  Between "Creates a new default instance", "Creates a default ", "Constructs a..." and others I don't have a preference. I can replace all class names with "new instance" if you think it's better.

I know it is not unified (anywhere).  I only point it out as it wasn't even unified in this PR.  Feel free to ignore if you think it is not important.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1880#discussion_r2544012209

From psadhukhan at openjdk.org  Thu Nov 20 03:35:12 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Nov 2025 03:35:12 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v10]
In-Reply-To: 
References: 
Message-ID: <_RL7TLWvnsq9pz8SvNwAKC9D3zq10601L6noGMBglQI=.691f1c22-a555-488b-95ac-edae9ac7b4ad@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

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

  Review comment. Redundant null check removed, add thread wait for both AWT, FX threads

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1968/files
  - new: https://git.openjdk.org/jfx/pull/1968/files/f66fff5c..e0c5a363

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

  Stats: 9 lines in 2 files changed: 6 ins; 2 del; 1 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 engineer.fouad.a at gmail.com  Thu Nov 20 07:41:39 2025
From: engineer.fouad.a at gmail.com (Fouad Almalki)
Date: Thu, 20 Nov 2025 10:41:39 +0300
Subject: JDK-8372053: RichTextArea keyboard navigation for RTL paragraph
 should be the opposite
In-Reply-To: 
References: 
 
Message-ID: 

Sounds good, thanks Andy.

On Wed, Nov 19, 2025 at 11:14?PM Andy Goryachev 
wrote:

> Thank you for providing the feedback and further clarification!
>
> I've got confused because the reproducer in the ticket uses TextArea.  You
> are right though - the RTL navigation should change with the
> ParagraphDirection attribute change.  I'll probably just close this
> ticket and create a new one for the RichTextArea, with your clarifications.
>
> As for RTL support in general - we are still working on it, the RTL
> functionality in JavaFX is incomplete (see
> https://bugs.openjdk.org/browse/JDK-8343557 ).  Stay tuned.
>
> And thanks again for checking out RichTextArea and filing the issues -
> looking forward to it.
>
> -andy
>
>
>
> *From: *openjfx-dev  on behalf of Fouad
> Almalki 
> *Date: *Tuesday, November 18, 2025 at 17:18
> *To: *openjfx-dev at openjdk.org 
> *Subject: *JDK-8372053: RichTextArea keyboard navigation for RTL
> paragraph should be the opposite
>
> Hi,
>
> I am the original reporter of the bug JDK-8372053. The issue I was
> referring to was with the incubator RichTextArea not the regular TextArea.
> The issue happens when the RichTextArea's node orientation is default (LTR)
> but the paragraph is right-aligned (TextAlignment.RIGHT and
> ParagraphDirection.RIGHT_TO_LEFT) with RTL text.
>
> Current behavior is: RIGHT moves caret forward, and LEFT moves caret
> backward.
> Expected behavior is: LEFT moves caret forward, and RIGHT moves caret
> backward.
>
>
>
> Also, currently the text selection of 2 lines of RTL text (does not matter
> aligned to left or right) is a little buggy. When positioning the caret at
> the start of second line, then pressing Shift+LEFT:
>
> Current behavior is: both lines will be highlighted and the caret will be
> at the end of the first line (wrong highlight but correct caret position).
> If pressing Shift+LEFT again, both lines will still be highlighted and the
> caret will be at the end of the first line - 1 (again, wrong highlight but
> correct caret position).
> Expected behavior is: The text highlight should be synced with the caret
> position.
>
>
>
> I also reported 2 more issues last week but did not appear yet on
> bugs.openjdk.org.
>
> Best Regards~
> Fouad almalki
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mstrauss at openjdk.org  Thu Nov 20 08:30:34 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 20 Nov 2025 08:30:34 GMT
Subject: RFR: 8372203: Piecewise linear easing function
Message-ID: 

Implementation of the [linear](https://www.w3.org/TR/css-easing-2/#the-linear-easing-function) easing function, which is now widely supported by all browsers, but still missing in JavaFX.

It allows developers to approximate arbitrary easing functions with linear segments:


linear(
    /* Start to 1st bounce */
    0, 0.063, 0.25, 0.563, 1 36.4%,
    /* 1st to 2nd bounce */
    0.812, 0.75, 0.813, 1 72.7%,
    /* 2nd to 3rd bounce */
    0.953, 0.938, 0.953, 1 90.9%,
    /* 3rd bounce to end */
    0.984, 1 100% 100%
  )




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

Commit messages:
 - manual test update
 - documentation update
 - test fix
 - Implementation of linear easing function

Changes: https://git.openjdk.org/jfx/pull/1977/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1977&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372203
  Stats: 908 lines in 13 files changed: 890 ins; 2 del; 16 mod
  Patch: https://git.openjdk.org/jfx/pull/1977.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1977/head:pull/1977

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

From mhanl at openjdk.org  Thu Nov 20 08:33:16 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 20 Nov 2025 08:33:16 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 19 Nov 2025 15:56:56 GMT, Andy Goryachev  wrote:

>> modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/util/RichUtils.java line 751:
>> 
>>> 749:     // with the author's permission
>>> 750:     /** returns a parent of the specified type, or null.  if node is an instance of the specified class, returns node */
>>> 751:     public static  T getAncestorOfClass(Class c, Node node) {
>> 
>> I would really recommend to not do anything like that. Normally, the layouting system, especially when requesting a layout should work and bubble up correctly. I wonder why this is needed. And if we found a special case, if we can solve it better.
>> 
>> Background: In the past projects, I often saw code like that and it turned out that this was never needed. It is often less readable and hurts the performance a bit. 
>> We also improve coupling between components, which I would not recommend as well. Especially since subclasses can change a lot and it would be nice if everything still work out of the box.
>
> Thank you @Maran23 for looking into this PR!
> 
> My experience is exactly opposite - I do use it often.  The `Node` (or `JComponent`) hierarchy is a hierarchy, explicitly retaining the pointers to the each member's parent.
> 
> A specific member can be a child of a certain Parent, direct or otherwise, by design, and this method allows to get to that parent easily.
> 
> Let me ask you this - what is the alternative?  Maintain a duplicate pointer?
> 
> Also, keep in mind this is not public API, it's a utility.

What I mean is:
Everything is part of the `RichTextLabel`. Requesting a layout from a node inside should request a layout for each parent, also `RichTextLabel`. So you should normally know that on the `RichTextLabel` level, which also manages the `VFlow`. So it can do the corresponding actions, just by the node requesting the layout.

If we take a look at other more complex Controls, they do the following:
- `VirtualFlow.requestCellLayout` -> sets a flag
- `layout` is requested, and due to the flag, we know what to do

Maybe something that could be done here as well? Could also be done by `Properties` perhaps.

> A specific member can be a child of a certain Parent, direct or otherwise, by design, and this method allows to get to that parent easily.
> ...
> Also, keep in mind this is not public API, it's a utility.

Yes, we can always get the parent hierarchy. But that does not mean we should. 
Making assumptions about the hierarchy will make subclasses and customizations (e.g. in the Skin) worse. If we extend `RichTextLabel` and use another Node then `VFlow`, then we can expect `TextCell`s not to work anymore?

In JavaFX, as you can also see in the codebase and other controls, retrieving an ancestor somewhere in the scene graph is pretty much never done or needed. 
I did not have a look on this particular issue, but what I want to suggest is to take another look at the problem and how to solve it. So we don't need to rely on finding a specific node that might be somewhere in the scene graph.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2544829563

From arapte at openjdk.org  Thu Nov 20 11:43:21 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 20 Nov 2025 11:43:21 GMT
Subject: RFR: 8335748: Rippling of frame on scrolling
Message-ID: 

**Issue:** 
With metal pipeline, frame tearing is observed when scrolling the content. Perform small fling gesture scrolls for observing the issue, the issue occurs/observed easily when scroll is coming to and end.

**Cause:**
vsync is not enabled for metal pipeline.

**Fix:** 
1. Enable vsync for metal pipeline. The vsync shall be enabled by default. It can be disabled with `-Djavafx.animation.fullspeed=true`.
2. Synchronize the access to offline render target texture.
2.1 The `GlassMTLFrameBufferObject._texture` object is created and destroyed by **QuantumRenderer** thread, and
2.2 `GlassMTLFrameBufferObject._texture` is also accessed on **Appkit** thread through function `GlassLayerMTL.blitToScreen()`
2.3 NSLock is created to synchronize the acess
2.4 Without this synchronization, a crash could occur in scenario when JavaFX app window is moved between screens that differ in refresh rate.

**Verification:**
1. Test that no frame tearing is observed, when scrolling(easy to test with small fling scrolls)
2. Test no issue observed when moving window among screens.
3. General sanity testing of UI.

**Test:**
A unit or system test is not possible for this scenario.

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

Commit messages:
 - implement vsync for metal

Changes: https://git.openjdk.org/jfx/pull/1978/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1978&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335748
  Stats: 147 lines in 11 files changed: 76 ins; 25 del; 46 mod
  Patch: https://git.openjdk.org/jfx/pull/1978.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1978/head:pull/1978

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

From psadhukhan at openjdk.org  Thu Nov 20 12:05:37 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Nov 2025 12:05:37 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v11]
In-Reply-To: 
References: 
Message-ID: 

> 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

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Rename var w.r.t the accessing thread for easy perusal
 - comment fix

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1968/files
  - new: https://git.openjdk.org/jfx/pull/1968/files/e0c5a363..2e8d0997

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

  Stats: 41 lines in 2 files changed: 0 ins; 0 del; 41 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 psadhukhan at openjdk.org  Thu Nov 20 12:05:40 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Nov 2025 12:05:40 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v10]
In-Reply-To: <_RL7TLWvnsq9pz8SvNwAKC9D3zq10601L6noGMBglQI=.691f1c22-a555-488b-95ac-edae9ac7b4ad@github.com>
References: 
 <_RL7TLWvnsq9pz8SvNwAKC9D3zq10601L6noGMBglQI=.691f1c22-a555-488b-95ac-edae9ac7b4ad@github.com>
Message-ID: 

On Thu, 20 Nov 2025 03:35:12 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment. Redundant null check removed, add thread wait for both AWT, FX threads

Updated PR to rename var w.r.t accessing thread

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

PR Comment: https://git.openjdk.org/jfx/pull/1968#issuecomment-3557650518

From psadhukhan at openjdk.org  Thu Nov 20 12:05:46 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Nov 2025 12:05:46 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v9]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 19 Nov 2025 18:28:43 GMT, Andy Goryachev  wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment + OutputRedirect
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassScene.java line 253:
> 
>> 251:     final void updateSceneState() {
>> 252:         // should only be called on the event thread
>> 253:         if (sceneState != null) {
> 
> L253, this is the original code, but I found the "event thread" words misleading - too similar to "event dispatcher" thread.  Should it be "fx application thread"?

ok

> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 1116:
> 
>> 1114:                 dnd = new SwingDnD(JFXPanel.this, hScenePeer);
>> 1115:                 dnd.addNotify();
>> 1116:                 if (hScenePeer != null) {
> 
> this null check can be removed, since the code will bail out on L1106 if `hScenePeer == null`

ok

> tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 98:
> 
>> 96:                 Thread.sleep(1);
>> 97:                 Platform.runLater(() -> contentPane.setScene(webView.getScene()));
>> 98:                 Thread.sleep(1);
> 
> discussed offline:
> 
> we'll should add some code (`invokeAndWait` + `Util.runAndWait`) here to make sure all the prior events are processed before leaving the try block and doing `OutputRedirect.checkAndRestoreStderr();`
> 
> Also, maybe add a `@Timeout` to make sure the test does not hang.

fixed

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2545748826
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2545757170
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2545751383

From psadhukhan at openjdk.org  Thu Nov 20 12:05:47 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 20 Nov 2025 12:05:47 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v9]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 19 Nov 2025 18:27:19 GMT, Kevin Rushforth  wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment + OutputRedirect
>
> tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 99:
> 
>> 97:                 Platform.runLater(() -> contentPane.setScene(webView.getScene()));
>> 98:                 Thread.sleep(1);
>> 99:             }
> 
> The calls in the loop to the FX and AWT threads are asynchronous, so I recommend adding the following after the loop to ensure that both threads are finished with the work submitted in the loops:
> 
> 
>             // Wait for both threads to process the earlier runnables
>             SwingUtilities.invokeAndWait(() -> {});
>             Util.runAndWait(() -> {});

added

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2545752084

From duke at openjdk.org  Thu Nov 20 12:58:27 2025
From: duke at openjdk.org (Jurgen)
Date: Thu, 20 Nov 2025 12:58:27 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow
In-Reply-To: 
References: 
 
 
 
Message-ID: <5VyBDD2XQvsuhNu3DRF6XXSwSzTe3BaN_13HdThVwxE=.86a1a532-e60c-4abc-a8f9-953ee2d1546e@github.com>

On Thu, 20 Nov 2025 08:28:57 GMT, Marius Hanl  wrote:

>> Thank you @Maran23 for looking into this PR!
>> 
>> My experience is exactly opposite - I do use it often.  The `Node` (or `JComponent`) hierarchy is a hierarchy, explicitly retaining the pointers to the each member's parent.
>> 
>> A specific member can be a child of a certain Parent, direct or otherwise, by design, and this method allows to get to that parent easily.
>> 
>> Let me ask you this - what is the alternative?  Maintain a duplicate pointer?
>> 
>> Also, keep in mind this is not public API, it's a utility.
>
> What I mean is:
> Everything is part of the `RichTextLabel`. Requesting a layout from a node inside should request a layout for each parent, also `RichTextLabel`. So you should normally know that on the `RichTextLabel` level, which also manages the `VFlow`. So it can do the corresponding actions, just by the node requesting the layout.
> 
> If we take a look at other more complex Controls, they do the following:
> - `VirtualFlow.requestCellLayout` -> sets a flag
> - `layout` is requested, and due to the flag, we know what to do
> 
> Maybe something that could be done here as well? Could also be done by `Properties` perhaps.
> 
>> A specific member can be a child of a certain Parent, direct or otherwise, by design, and this method allows to get to that parent easily.
>> ...
>> Also, keep in mind this is not public API, it's a utility.
> 
> Yes, we can always get the parent hierarchy. But that does not mean we should. 
> Making assumptions about the hierarchy will make subclasses and customizations (e.g. in the Skin) worse. If we extend `RichTextLabel` and use another Node then `VFlow`, then we can expect `TextCell`s not to work anymore?
> 
> In JavaFX, as you can also see in the codebase and other controls, retrieving an ancestor somewhere in the scene graph is pretty much never done or needed. 
> I did not have a look on this particular issue, but what I want to suggest is to take another look at the problem and how to solve it. So we don't need to rely on finding a specific node that might be somewhere in the scene graph.

If I remember correctly from what I've traced, is that _requestLayout_ from the embedded node is propagating upwards until it reaches `TextCell` which extends a `BorderPane`. At this point _requestLayout_ in `Parent` invokes _markDirtyLayout_ with the **forceParentLayout** parameter/flag being **false** and the propagation stops.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2545969921

From duke at openjdk.org  Thu Nov 20 13:12:30 2025
From: duke at openjdk.org (Jurgen)
Date: Thu, 20 Nov 2025 13:12:30 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow
In-Reply-To: 
References: 
Message-ID: <383BM_2gtNxVrZ3C9TEd4i0UVADK5sEu3DKzh6sYJKA=.220c2c6f-b2f9-480e-aa80-6df475ad11f5@github.com>

On Mon, 17 Nov 2025 21:46:06 GMT, Andy Goryachev  wrote:

> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`.
> 
> 
> ### NOTES
> 
> - this PR depends on https://github.com/openjdk/jfx/pull/1974
> - the fix can be verified visually using the latest Monkey Tester
> 
> Screenshot 2025-11-17 at 13 43 12

modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/TextCell.java line 105:

> 103:     public void add(Node node) {
> 104:         flow().getChildren().add(node);
> 105:         embedsNode = true;

Is the intention that if the `TextCell` has no children (neither Text nor embedded nodes) that _getAncestorOfClass_ is bypassed ?
Or is this to indicate that _getAncestorOfClass_ should only be invoked if there are any embedded nodes (non Text ones) present ?
If the latter then note that `add(Node)` is called for both the adding of Text and embedded nodes and maybe you intended to overload the add method with add(Text) ?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2546009654

From mhanl at openjdk.org  Thu Nov 20 13:24:01 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 20 Nov 2025 13:24:01 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow
In-Reply-To: <5VyBDD2XQvsuhNu3DRF6XXSwSzTe3BaN_13HdThVwxE=.86a1a532-e60c-4abc-a8f9-953ee2d1546e@github.com>
References: 
 
 
 
 <5VyBDD2XQvsuhNu3DRF6XXSwSzTe3BaN_13HdThVwxE=.86a1a532-e60c-4abc-a8f9-953ee2d1546e@github.com>
Message-ID: 

On Thu, 20 Nov 2025 12:55:09 GMT, Jurgen  wrote:

>> What I mean is:
>> Everything is part of the `RichTextArea`. Requesting a layout from a node inside should request a layout for each parent, also `RichTextArea`. So you should normally know that on the `RichTextArea` level, which also manages the `VFlow`. So it can do the corresponding actions, just by the node requesting the layout.
>> 
>> If we take a look at other more complex Controls, they do the following:
>> - `VirtualFlow.requestCellLayout` -> sets a flag
>> - `layout` is requested, and due to the flag, we know what to do
>> 
>> Maybe something that could be done here as well? Could also be done by `Properties` perhaps.
>> 
>>> A specific member can be a child of a certain Parent, direct or otherwise, by design, and this method allows to get to that parent easily.
>>> ...
>>> Also, keep in mind this is not public API, it's a utility.
>> 
>> Yes, we can always get the parent hierarchy. But that does not mean we should. 
>> Making assumptions about the hierarchy will make subclasses and customizations (e.g. in the Skin) worse. If we extend `RichTextArea` and use another Node then `VFlow`, then we can expect `TextCell`s not to work anymore?
>> 
>> In JavaFX, as you can also see in the codebase and other controls, retrieving an ancestor somewhere in the scene graph is pretty much never done or needed. 
>> I did not have a look on this particular issue, but what I want to suggest is to take another look at the problem and how to solve it. So we don't need to rely on finding a specific node that might be somewhere in the scene graph.
>
> If I remember correctly from what I've traced, is that _requestLayout_ from the embedded node is propagating upwards until it reaches `TextCell` which extends a `BorderPane`. At this point _requestLayout_ in `Parent` invokes _markDirtyLayout_ with the **forceParentLayout** parameter/flag being **false** and the propagation stops.

I know why. Because the `TextCell` is not managed. 
https://github.com/openjdk/jfx/blob/f87448ec156608527d77a4204e98e08052ffecd1/modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/TextCell.java#L70

Therefore, this will be set:
https://github.com/openjdk/jfx/blob/f87448ec156608527d77a4204e98e08052ffecd1/modules/javafx.graphics/src/main/java/javafx/scene/Parent.java#L1331-L1334

Indeed, the `TextCell` will be handled as layout root, therefore not propagating any layout request further up.
So the real problem is, that the `TextCell` is not managed.

Otherwise the layout would be propagated to the `RichTextArea`, which can do the corresponding actions. So I would suggest looking into that.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2546046293

From kcr at openjdk.org  Thu Nov 20 13:52:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 20 Nov 2025 13:52:13 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 Nov 2025 12:05:37 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename var w.r.t the accessing thread for easy perusal
>  - comment fix

LGTM

@prsadhuk Please file the follow-on bug as discussed and add a comment with the bug ID.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1968#pullrequestreview-3487962667

From kcr at openjdk.org  Thu Nov 20 14:00:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 20 Nov 2025 14:00:16 GMT
Subject: RFR: 8335748: Rippling of frame on scrolling
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 Nov 2025 11:37:53 GMT, Ambarish Rapte  wrote:

> **Issue:** 
> With metal pipeline, frame tearing is observed when scrolling the content. Perform small fling gesture scrolls for observing the issue, the issue occurs/observed easily when scroll is coming to and end.
> 
> **Cause:**
> vsync is not enabled for metal pipeline.
> 
> **Fix:** 
> 1. Enable vsync for metal pipeline. The vsync shall be enabled by default. It can be disabled with `-Djavafx.animation.fullspeed=true`.
> 2. Synchronize the access to offline render target texture.
> 2.1 The `GlassMTLFrameBufferObject._texture` object is created and destroyed by **QuantumRenderer** thread, and
> 2.2 `GlassMTLFrameBufferObject._texture` is also accessed on **Appkit** thread through function `GlassLayerMTL.blitToScreen()`
> 2.3 NSLock is created to synchronize the acess
> 2.4 Without this synchronization, a crash could occur in scenario when JavaFX app window is moved between screens that differ in refresh rate.
> 
> **Verification:**
> 1. Test that no frame tearing is observed, when scrolling(easy to test with small fling scrolls)
> 2. Test no issue observed when moving window among screens.
> 3. General sanity testing of UI.
> 
> **Test:**
> A unit or system test is not possible for this scenario.

Reviewers: @kevinrushforth and @jayathirthrao or @aghaisas

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

PR Comment: https://git.openjdk.org/jfx/pull/1978#issuecomment-3558202493

From lkostyra at openjdk.org  Thu Nov 20 14:49:18 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 20 Nov 2025 14:49:18 GMT
Subject: RFR: 8368629: Texture.update sometimes invoked for a disposed
 Texture [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Nov 2025 14:49:56 GMT, Lukasz Kostyra  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)

Apologies for the delay, I got a bit consumed by D3D12 EA2 release and only now managed to get a closer look at the stack traces.

> I see this NPE (with this fix applied) when I go to more extremes with the amount of images shown

I think both of these don't directly relate to Texture.update causing problems, but the fixes for them are trivial. I filed separate issues for those and will take a closer look at them later down the line:
- https://bugs.openjdk.org/browse/JDK-8372276
- https://bugs.openjdk.org/browse/JDK-8372275


This was waiting a bit for me to go through all the NPEs and stack traces reported, but I think I addressed them all. I'll leave this PR for a bit more time and if there is no objections I will integrate it tomorrow.

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

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

From angorya at openjdk.org  Thu Nov 20 15:34:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Nov 2025 15:34:55 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 Nov 2025 12:05:37 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename var w.r.t the accessing thread for easy perusal
>  - comment fix

Looks good.  Thank you for all the work!

tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 51:

> 49: import test.util.Util;
> 50: 
> 51: @Timeout(value=30000, unit=TimeUnit.MILLISECONDS)

just FYI: the default time unit is SECONDS, so we can simply write
`@Timeout(30)`

(we used MILLISECONDS earlier to minimize the changes going from junit4)

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1968#pullrequestreview-3488489554
PR Review Comment: https://git.openjdk.org/jfx/pull/1968#discussion_r2546542092

From kcr at openjdk.org  Thu Nov 20 16:06:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 20 Nov 2025 16:06:53 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v11]
In-Reply-To: 
References: 
 
Message-ID: <2JB5OjSXb6FAkmDrvDuvM70-4esmk5RMCacP_mTkeQs=.2d9788d9-deae-4b7d-ab9b-529f775472d7@github.com>

On Thu, 20 Nov 2025 12:05:37 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename var w.r.t the accessing thread for easy perusal
>  - comment fix

Looks like JBS is still having connectivity problems. Once it wakes up, this should be marked as ready to integrate.

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

PR Comment: https://git.openjdk.org/jfx/pull/1968#issuecomment-3558835627

From angorya at openjdk.org  Thu Nov 20 16:16:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Nov 2025 16:16:05 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow
In-Reply-To: <383BM_2gtNxVrZ3C9TEd4i0UVADK5sEu3DKzh6sYJKA=.220c2c6f-b2f9-480e-aa80-6df475ad11f5@github.com>
References: 
 <383BM_2gtNxVrZ3C9TEd4i0UVADK5sEu3DKzh6sYJKA=.220c2c6f-b2f9-480e-aa80-6df475ad11f5@github.com>
Message-ID: <7L9QeBGih8QmMdqk0sag9GgtNZ0MT4NCT9peA26t74E=.d3405470-a5b5-45a9-9023-e43e730595cf@github.com>

On Thu, 20 Nov 2025 13:08:37 GMT, Jurgen  wrote:

>> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`.
>> 
>> 
>> ### NOTES
>> 
>> - this PR depends on https://github.com/openjdk/jfx/pull/1974
>> - the fix can be verified visually using the latest Monkey Tester
>> 
>> Screenshot 2025-11-17 at 13 43 12
>
> modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/TextCell.java line 105:
> 
>> 103:     public void add(Node node) {
>> 104:         flow().getChildren().add(node);
>> 105:         embedsNode = true;
> 
> Is the intention that if the `TextCell` has no children (neither Text nor embedded nodes) that _getAncestorOfClass_ is bypassed ?
> Or is this to indicate that _getAncestorOfClass_ should only be invoked if there are any embedded nodes (non Text ones) present ?
> If the latter then note that `add(Node)` is called for both the adding of Text and embedded nodes and maybe you intended to overload the add method with add(Text) ?

All this is by design.  VFlow is the component that lays out the text cells.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2546691131

From angorya at openjdk.org  Thu Nov 20 16:16:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Nov 2025 16:16:06 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow
In-Reply-To: 
References: 
 
 
 
 <5VyBDD2XQvsuhNu3DRF6XXSwSzTe3BaN_13HdThVwxE=.86a1a532-e60c-4abc-a8f9-953ee2d1546e@github.com>
 
Message-ID: 

On Thu, 20 Nov 2025 13:20:45 GMT, Marius Hanl  wrote:

>> If I remember correctly from what I've traced, is that _requestLayout_ from the embedded node is propagating upwards until it reaches `TextCell` which extends a `BorderPane`. At this point _requestLayout_ in `Parent` invokes _markDirtyLayout_ with the **forceParentLayout** parameter/flag being **false** and the propagation stops.
>
> I know why. Because the `TextCell` is not managed. 
> https://github.com/openjdk/jfx/blob/f87448ec156608527d77a4204e98e08052ffecd1/modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/TextCell.java#L70
> 
> Therefore, this will be set:
> https://github.com/openjdk/jfx/blob/f87448ec156608527d77a4204e98e08052ffecd1/modules/javafx.graphics/src/main/java/javafx/scene/Parent.java#L1331-L1334
> 
> Indeed, the `TextCell` will be handled as layout root, therefore not propagating any layout request further up.
> So the real problem is, that the `TextCell` is not managed.
> 
> Otherwise the layout would be propagated to the `RichTextArea`, which can do the corresponding actions. So I would suggest looking into that.

Yes, this is by design.  VFlow is the component that manages the text cells.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2546703726

From angorya at openjdk.org  Thu Nov 20 16:26:32 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Nov 2025 16:26:32 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow
In-Reply-To: 
References: 
 
 
 
 <5VyBDD2XQvsuhNu3DRF6XXSwSzTe3BaN_13HdThVwxE=.86a1a532-e60c-4abc-a8f9-953ee2d1546e@github.com>
 
 
Message-ID: 

On Thu, 20 Nov 2025 16:12:14 GMT, Andy Goryachev  wrote:

>> I know why. Because the `TextCell` is not managed. 
>> https://github.com/openjdk/jfx/blob/f87448ec156608527d77a4204e98e08052ffecd1/modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/TextCell.java#L70
>> 
>> Therefore, this will be set:
>> https://github.com/openjdk/jfx/blob/f87448ec156608527d77a4204e98e08052ffecd1/modules/javafx.graphics/src/main/java/javafx/scene/Parent.java#L1331-L1334
>> 
>> Indeed, the `TextCell` will be handled as layout root, therefore not propagating any layout request further up.
>> So the real problem is, that the `TextCell` is not managed.
>> 
>> Otherwise the layout would be propagated to the `RichTextArea`, which can do the corresponding actions. So I would suggest looking into that.
>
> Yes, this is by design.  VFlow is the component that manages the text cells.

> is to take another look at the problem and how to solve it.

The RTA design is that VFlow deals with the layout.  It views the thing not as a collection of independent cells, but as a virtual flow - a change in one cell might require the reflow of many other parts, toggling scroll bars visibility, reshaping the selection shapes, etc.

In an ideal world, the layout of text and embedded nodes would be a responsibility of the (prism) text layout, making it easier to have for example a Label with rich text.  But we don't have that option, so this design uses a collection of text cells to present the visible area, managed by the VFlow.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2546743823

From duke at openjdk.org  Thu Nov 20 16:44:40 2025
From: duke at openjdk.org (Jurgen)
Date: Thu, 20 Nov 2025 16:44:40 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow
In-Reply-To: 
References: 
Message-ID: 

On Mon, 17 Nov 2025 21:46:06 GMT, Andy Goryachev  wrote:

> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`.
> 
> 
> ### NOTES
> 
> - this PR depends on https://github.com/openjdk/jfx/pull/1974
> - the fix can be verified visually using the latest Monkey Tester
> 
> Screenshot 2025-11-17 at 13 43 12

modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/TextCell.java line 474:

> 472:             if (vf != null) {
> 473:                 vf.requestLayout();
> 474:             }

Would `setNeedsLayout(true);` maybe work here instead ?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2546807506

From angorya at openjdk.org  Thu Nov 20 16:44:41 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Nov 2025 16:44:41 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 Nov 2025 16:40:39 GMT, Jurgen  wrote:

>> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`.
>> 
>> 
>> ### NOTES
>> 
>> - this PR depends on https://github.com/openjdk/jfx/pull/1974
>> - the fix can be verified visually using the latest Monkey Tester
>> 
>> Screenshot 2025-11-17 at 13 43 12
>
> modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/TextCell.java line 474:
> 
>> 472:             if (vf != null) {
>> 473:                 vf.requestLayout();
>> 474:             }
> 
> Would `setNeedsLayout(true);` maybe work here instead ?

no, we need to signal this to VFlow who does the layout.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2546811730

From duke at openjdk.org  Thu Nov 20 16:58:55 2025
From: duke at openjdk.org (Jurgen)
Date: Thu, 20 Nov 2025 16:58:55 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow
In-Reply-To: <7L9QeBGih8QmMdqk0sag9GgtNZ0MT4NCT9peA26t74E=.d3405470-a5b5-45a9-9023-e43e730595cf@github.com>
References: 
 <383BM_2gtNxVrZ3C9TEd4i0UVADK5sEu3DKzh6sYJKA=.220c2c6f-b2f9-480e-aa80-6df475ad11f5@github.com>
 <7L9QeBGih8QmMdqk0sag9GgtNZ0MT4NCT9peA26t74E=.d3405470-a5b5-45a9-9023-e43e730595cf@github.com>
Message-ID: <1tUXZFzRQWmHibKY3njpbabiEENOzhqkPn9tgbOR63E=.2c3e2c2d-ceee-4eaf-9747-25c679215c4b@github.com>

On Thu, 20 Nov 2025 16:09:32 GMT, Andy Goryachev  wrote:

>> modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/TextCell.java line 105:
>> 
>>> 103:     public void add(Node node) {
>>> 104:         flow().getChildren().add(node);
>>> 105:         embedsNode = true;
>> 
>> Is the intention that if the `TextCell` has no children (neither Text nor embedded nodes) that _getAncestorOfClass_ is bypassed ?
>> Or is this to indicate that _getAncestorOfClass_ should only be invoked if there are any embedded nodes (non Text ones) present ?
>> If the latter then note that `add(Node)` is called for both the adding of Text and embedded nodes and maybe you intended to overload the add method with add(Text) ?
>
> All this is by design.  VFlow is the component that lays out the text cells.

Umm, I find this code ambiguous - so just trying to clarify which of the two options presented you intend ?
If it's the first then maybe an alternative variable/flag name should be considered ?
If it's the second then embedsNode is always set true as soon as any content is added which means the first option is what is actually occurring ?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2546863013

From angorya at openjdk.org  Thu Nov 20 17:28:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Nov 2025 17:28:26 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow
In-Reply-To: <1tUXZFzRQWmHibKY3njpbabiEENOzhqkPn9tgbOR63E=.2c3e2c2d-ceee-4eaf-9747-25c679215c4b@github.com>
References: 
 <383BM_2gtNxVrZ3C9TEd4i0UVADK5sEu3DKzh6sYJKA=.220c2c6f-b2f9-480e-aa80-6df475ad11f5@github.com>
 <7L9QeBGih8QmMdqk0sag9GgtNZ0MT4NCT9peA26t74E=.d3405470-a5b5-45a9-9023-e43e730595cf@github.com>
 <1tUXZFzRQWmHibKY3njpbabiEENOzhqkPn9tgbOR63E=.2c3e2c2d-ceee-4eaf-9747-25c679215c4b@github.com>
Message-ID: <_X9T6YWQn9E4gaKMhaJZYvYA0hoxg5FBZE8aUqyxpcQ=.51489ebd-6a5c-415d-83f4-ad24b78aa8ea@github.com>

On Thu, 20 Nov 2025 16:55:59 GMT, Jurgen  wrote:

>> All this is by design.  VFlow is the component that lays out the text cells.
>
> Umm, I find this code ambiguous - so just trying to clarify which of the two options presented you intend ?
> If it's the first then maybe an alternative variable/flag name should be considered ?
> If it's the second then embedsNode is always set true as soon as any content is added which means the first option is what is actually occurring ?

The expectation is that most text cells contain `TextFlow`, with the `VFlow` managing the layout.  Once `VFlow` determines the target width, it queries the `TextFlow` for its preferred height to determine the actual size.

For paragraphs that contains `Regions` - either inline or as whole paragraphs - this logic needs to be augmented to propagate the `requestLayout()` flag up the hierarchy.  We don't want to do this for pure text cells, but we must do it for embedded nodes.

`addNode(Node)` handles the inline node case, `RichParagraph.of(Supplier)` does the "full-width" case.

so to answer your question - if I understand the issue - the `embedsNode` flag was added to enable telling `VFlow` that it needs to reflow because some embedded node asked for it.  Pure text cells don't need this signaling enabled.

Did I answer your question (satisfactorily :-) ?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2546975857

From duke at openjdk.org  Thu Nov 20 18:02:43 2025
From: duke at openjdk.org (Jurgen)
Date: Thu, 20 Nov 2025 18:02:43 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow
In-Reply-To: <_X9T6YWQn9E4gaKMhaJZYvYA0hoxg5FBZE8aUqyxpcQ=.51489ebd-6a5c-415d-83f4-ad24b78aa8ea@github.com>
References: 
 <383BM_2gtNxVrZ3C9TEd4i0UVADK5sEu3DKzh6sYJKA=.220c2c6f-b2f9-480e-aa80-6df475ad11f5@github.com>
 <7L9QeBGih8QmMdqk0sag9GgtNZ0MT4NCT9peA26t74E=.d3405470-a5b5-45a9-9023-e43e730595cf@github.com>
 <1tUXZFzRQWmHibKY3njpbabiEENOzhqkPn9tgbOR63E=.2c3e2c2d-ceee-4eaf-9747-25c679215c4b@github.com>
 <_X9T6YWQn9E4gaKMhaJZYvYA0hoxg5FBZE8aUqyxpcQ=.51489ebd-6a5c-415d-83f4-ad24b78aa8ea@github.com>
Message-ID: 

On Thu, 20 Nov 2025 17:25:26 GMT, Andy Goryachev  wrote:

>> Umm, I find this code ambiguous - so just trying to clarify which of the two options presented you intend ?
>> If it's the first then maybe an alternative variable/flag name should be considered ?
>> If it's the second then embedsNode is always set true as soon as any content is added which means the first option is what is actually occurring ?
>
> The expectation is that most text cells contain `TextFlow`, with the `VFlow` managing the layout.  Once `VFlow` determines the target width, it queries the `TextFlow` for its preferred height to determine the actual size.
> 
> For paragraphs that contains `Regions` - either inline or as whole paragraphs - this logic needs to be augmented to propagate the `requestLayout()` flag up the hierarchy.  We don't want to do this for pure text cells, but we must do it for embedded nodes.
> 
> `addNode(Node)` handles the inline node case, `RichParagraph.of(Supplier)` does the "full-width" case.
> 
> so to answer your question - if I understand the issue - the `embedsNode` flag was added to enable telling `VFlow` that it needs to reflow because some embedded node asked for it.  Pure text cells don't need this signaling enabled.
> 
> Did I answer your question (satisfactorily :-) ?

I think so ....
> Pure text cells don't need this signaling enabled.

If this is what is intended, then from how I read the code that is not what is happening because `add(Node)` is called even for Text only cells. See: 

https://github.com/openjdk/jfx/blob/f87448ec156608527d77a4204e98e08052ffecd1/modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/VFlow.java#L827-L828

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2547084649

From angorya at openjdk.org  Thu Nov 20 19:10:38 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Nov 2025 19:10:38 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow
In-Reply-To: 
References: 
 <383BM_2gtNxVrZ3C9TEd4i0UVADK5sEu3DKzh6sYJKA=.220c2c6f-b2f9-480e-aa80-6df475ad11f5@github.com>
 <7L9QeBGih8QmMdqk0sag9GgtNZ0MT4NCT9peA26t74E=.d3405470-a5b5-45a9-9023-e43e730595cf@github.com>
 <1tUXZFzRQWmHibKY3njpbabiEENOzhqkPn9tgbOR63E=.2c3e2c2d-ceee-4eaf-9747-25c679215c4b@github.com>
 <_X9T6YWQn9E4gaKMhaJZYvYA0hoxg5FBZE8aUqyxpcQ=.51489ebd-6a5c-415d-83f4-ad24b78aa8ea@github.com>
 
Message-ID: 

On Thu, 20 Nov 2025 17:58:53 GMT, Jurgen  wrote:

>> The expectation is that most text cells contain `TextFlow`, with the `VFlow` managing the layout.  Once `VFlow` determines the target width, it queries the `TextFlow` for its preferred height to determine the actual size.
>> 
>> For paragraphs that contains `Regions` - either inline or as whole paragraphs - this logic needs to be augmented to propagate the `requestLayout()` flag up the hierarchy.  We don't want to do this for pure text cells, but we must do it for embedded nodes.
>> 
>> `addNode(Node)` handles the inline node case, `RichParagraph.of(Supplier)` does the "full-width" case.
>> 
>> so to answer your question - if I understand the issue - the `embedsNode` flag was added to enable telling `VFlow` that it needs to reflow because some embedded node asked for it.  Pure text cells don't need this signaling enabled.
>> 
>> Did I answer your question (satisfactorily :-) ?
>
> I think so ....
>> Pure text cells don't need this signaling enabled.
> 
> If this is what is intended, then from how I read the code that is not what is happening because `add(Node)` is called even for Text only cells. See: 
> 
> https://github.com/openjdk/jfx/blob/f87448ec156608527d77a4204e98e08052ffecd1/modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/VFlow.java#L827-L828

you are right, thank you so much!

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2547324661

From angorya at openjdk.org  Thu Nov 20 19:35:14 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Nov 2025 19:35:14 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow [v2]
In-Reply-To: 
References: 
Message-ID: 

> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`.
> 
> 
> ### NOTES
> 
> - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved)
> - the fix can be verified visually using the latest Monkey Tester
> 
> Screenshot 2025-11-17 at 13 43 12

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

  add text segment

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1975/files
  - new: https://git.openjdk.org/jfx/pull/1975/files/2725cf0d..b714faff

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

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

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

From angorya at openjdk.org  Thu Nov 20 19:35:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Nov 2025 19:35:16 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow [v2]
In-Reply-To: 
References: 
 <383BM_2gtNxVrZ3C9TEd4i0UVADK5sEu3DKzh6sYJKA=.220c2c6f-b2f9-480e-aa80-6df475ad11f5@github.com>
 <7L9QeBGih8QmMdqk0sag9GgtNZ0MT4NCT9peA26t74E=.d3405470-a5b5-45a9-9023-e43e730595cf@github.com>
 <1tUXZFzRQWmHibKY3njpbabiEENOzhqkPn9tgbOR63E=.2c3e2c2d-ceee-4eaf-9747-25c679215c4b@github.com>
 <_X9T6YWQn9E4gaKMhaJZYvYA0hoxg5FBZE8aUqyxpcQ=.51489ebd-6a5c-415d-83f4-ad24b78aa8ea@github.com>
 
Message-ID: 

On Thu, 20 Nov 2025 17:58:53 GMT, Jurgen  wrote:

>> The expectation is that most text cells contain `TextFlow`, with the `VFlow` managing the layout.  Once `VFlow` determines the target width, it queries the `TextFlow` for its preferred height to determine the actual size.
>> 
>> For paragraphs that contains `Regions` - either inline or as whole paragraphs - this logic needs to be augmented to propagate the `requestLayout()` flag up the hierarchy.  We don't want to do this for pure text cells, but we must do it for embedded nodes.
>> 
>> `addNode(Node)` handles the inline node case, `RichParagraph.of(Supplier)` does the "full-width" case.
>> 
>> so to answer your question - if I understand the issue - the `embedsNode` flag was added to enable telling `VFlow` that it needs to reflow because some embedded node asked for it.  Pure text cells don't need this signaling enabled.
>> 
>> Did I answer your question (satisfactorily :-) ?
>
> I think so ....
>> Pure text cells don't need this signaling enabled.
> 
> If this is what is intended, then from how I read the code that is not what is happening because `add(Node)` is called even for Text only cells. See: 
> 
> https://github.com/openjdk/jfx/blob/f87448ec156608527d77a4204e98e08052ffecd1/modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/VFlow.java#L827-L828

Thanks again @Jugen for pointing this out.  Sorry, it took a while for me to understand what's going on.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2547416975

From pavelturk2000 at gmail.com  Thu Nov 20 20:31:10 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Thu, 20 Nov 2025 22:31:10 +0200
Subject: About two my issues
In-Reply-To: 
References: 
 
Message-ID: <4af9d337-83fa-4edf-8703-5b2c24ccdf0f@gmail.com>

About JDK-8371781. I understood the problem. The window seems to be created but it is not visible. I recorded a GIF that clearly shows the issue (it is about 15 seconds long, watch until the label text changes) - https://ibb.co/n8Y42bNy

I hope, it will help.

Test code:

public class Test1 extends Application {

 ??? private final Label label = new Label("Miracles don?t happen.");

 ??? @Override
 ??? public void start(Stage stage) {
 ??????? MenuItem item = new MenuItem("Click me!");
 ??????? item.setOnAction(e -> {
 ??????????? label.setText("It?s a miracle!");
 ??????? });
 ??????? Menu menu = new Menu("Menu");
 ??????? menu.getItems().add(item);
 ??????? MenuBar bar = new MenuBar(menu);

 ??????? var stackPane = new StackPane(label);
 ??????? VBox.setVgrow(stackPane, Priority.ALWAYS);
 ??????? label.setStyle("-fx-font-size: 30");
 ??????? VBox root = new VBox(bar, stackPane);

 ??????? Scene scene = new Scene(root, 400, 400);
 ??????? stage.setScene(scene);
 ??????? stage.setTitle("JDK-8371781");
 ??????? stage.show();
 ??? }

 ??? public static void main(String[] args) {
 ??????? launch();
 ??? }
}

Best regards, Pavel

On 11/18/25 18:21, Kevin Rushforth wrote:
> Regarding the second issue, JDK-8372108, I will add your additional information as a comment and reopen the bug.
>
> Regarding the first issue, I see the following, which I presume is the one you filed?
>
> JDK-8371781: Popup for ComboBox, Menu, and Tooltip is not shown sometimes in JavaFX
>
> I don't know why you didn't receive notification when it was processed and transferred to the JDK project in JBS. I see that it was closed as not reproducible. Do you have additional information that would help reproduce it?
>
> -- Kevin
>
>
> On 11/18/2025 8:06 AM, PavelTurk wrote:
>> Hello everyone,
>>
>> On November 10, I opened an issue (using the new redesigned form), and the system showed me the ID 23c3711c-36b1-4b94-a0d3-25bbdcf1b95f. The issue was about the fact that PopupWindow is not always shown on Linux systems, and I described how to reproduce the bug using a Tooltip. However, I still haven?t received any information about my issue.
>>
>> On November 16, I opened another issue (using the old form) about a memory leak in Tab that is related to GRAPHIC. Today I received a message that the issue is JDK-8372108. However, my issue was immediately closed with a note saying that it is a duplicate of JDK-8283449. But it is NOT a duplicate. JDK-8283449 is related to a problem in ContextMenu. I know this issue and I use the following workaround:
>>
>> contextMenu.getProperties().put(KEY, new WeakReference(tab));
>>
>> MenuItem close = new MenuItem(..);
>> close.setOnAction((e) -> {
>> ????? var t = getTab(contextMenu); // from properties
>> });
>>
>> The issue I reported is related to |graphic|. So I believe that there are TWO separate problems with tabs that lead to memory leaks.
>>
>> Best regards, Pavel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Thu Nov 20 22:29:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Nov 2025 22:29:57 GMT
Subject: RFR: 8372303: Remove obsolete tbom files from /doc-files
Message-ID: 

Removed obsolete `.tbom` files.

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

Commit messages:
 - rm tbom

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

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

From psadhukhan at openjdk.org  Fri Nov 21 03:35:41 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 21 Nov 2025 03:35:41 GMT
Subject: Integrated: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Nov 2025 10:37:25 GMT, Prasanta Sadhukhan  wrote:

> 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

This pull request has now been integrated.

Changeset: 33abf5d4
Author:    Prasanta Sadhukhan 
URL:       https://git.openjdk.org/jfx/commit/33abf5d4b3d2b90f66581c4e25c542adf285fadd
Stats:     275 lines in 3 files changed: 202 ins; 6 del; 67 mod

8255248: NullPointerException in JFXPanel due to race condition in HostContainer
8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException

Reviewed-by: angorya, kcr

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

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

From mhanl at openjdk.org  Fri Nov 21 08:44:15 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 21 Nov 2025 08:44:15 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow [v2]
In-Reply-To: 
References: 
 
 
 
 <5VyBDD2XQvsuhNu3DRF6XXSwSzTe3BaN_13HdThVwxE=.86a1a532-e60c-4abc-a8f9-953ee2d1546e@github.com>
 
 
 
Message-ID: 

On Thu, 20 Nov 2025 16:23:13 GMT, Andy Goryachev  wrote:

>> Yes, this is by design.  VFlow is the component that manages the text cells.
>
>> is to take another look at the problem and how to solve it.
> 
> The RTA design is that VFlow deals with the layout.  It views the thing not as a collection of independent cells, but as a virtual flow - a change in one cell might require the reflow of many other parts, toggling scroll bars visibility, reshaping the selection shapes, etc.
> 
> In an ideal world, the layout of text and embedded nodes would be a responsibility of the (prism) text layout, making it easier to have for example a Label with rich text.  But we don't have that option, so this design uses a collection of text cells to present the visible area, managed by the VFlow.

Let me repeat what I mean:
- If you call: `setManaged(false)`, you will effectively tell JavaFX: I'm the layout root, I can handle ALL layout changes from my children without my parents.
- This is not the case here, so making the `TextCell` unmanaged while still retrieving a parent (`VFlow`) fights this design.
- Which leads me to the conclusion: Maybe this should not be unmanaged, since it does not fulfill the required preconditions
- Checking the `VirtualFlow` as an example, it will not set anything to unmanaged

Lets check some existing examples of unmanaged nodes:

`XYChart`. See how this was done by design, the consequences were known:
https://github.com/openjdk/jfx/blob/33abf5d4b3d2b90f66581c4e25c542adf285fadd/modules/javafx.controls/src/main/java/javafx/scene/chart/XYChart.java#L523-L525

---

`ScrollPaneSkin` has actually the same case as you. This is how they dealt with it:
https://github.com/openjdk/jfx/blob/33abf5d4b3d2b90f66581c4e25c542adf285fadd/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java#L652-L653
https://github.com/openjdk/jfx/blob/33abf5d4b3d2b90f66581c4e25c542adf285fadd/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java#L679-L689

This could be a solution for your problem. Since they also set the parent `viewRect` as unmanaged, the layout request will never hit the `ScrollPane`. But with that solution the child of the `viewRect`, called `viewContent` does request the `ScrollPane` layout. A clever solution without anything like ancestor searching. What do you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2548963033

From mhanl at openjdk.org  Fri Nov 21 11:23:21 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 21 Nov 2025 11:23:21 GMT
Subject: RFR: 8372303: Remove obsolete tbom files from /doc-files
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 Nov 2025 22:23:20 GMT, Andy Goryachev  wrote:

> Removed obsolete `.tbom` files.

I don't know what was the usecase of those files in the first place, but removing unused stuff from the repository is always good. 
I checked the `openjdk/jdk` repository and I could not find `.tbom` files there, so this looks safe to do.

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

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1979#pullrequestreview-3492321963

From kcr at openjdk.org  Fri Nov 21 13:08:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 21 Nov 2025 13:08:18 GMT
Subject: RFR: 8255248: NullPointerException in JFXPanel due to race
 condition in HostContainer [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 Nov 2025 12:05:37 GMT, Prasanta Sadhukhan  wrote:

>> 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
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename var w.r.t the accessing thread for easy perusal
>  - comment fix

Regarding my comment:

> I do want to see a follow-up issue filed to consider redesigning the threading model, but I think this PR is a good workaround for the NPEs.

I see you filed [JDK-8372322](https://bugs.openjdk.org/browse/JDK-8372322) as a follow-up issue. Thank you.

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

PR Comment: https://git.openjdk.org/jfx/pull/1968#issuecomment-3562948800

From angorya at openjdk.org  Fri Nov 21 15:41:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Nov 2025 15:41:55 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow [v2]
In-Reply-To: 
References: 
 
 
 
 <5VyBDD2XQvsuhNu3DRF6XXSwSzTe3BaN_13HdThVwxE=.86a1a532-e60c-4abc-a8f9-953ee2d1546e@github.com>
 
 
 
 
Message-ID: <15B47nEG5NEyJ3_nw6BLCYOvM8HhUi2QtYzD4WQjpVI=.21e08564-174a-491b-8071-d7f12556a5cf@github.com>

On Fri, 21 Nov 2025 08:40:18 GMT, Marius Hanl  wrote:

>>> is to take another look at the problem and how to solve it.
>> 
>> The RTA design is that VFlow deals with the layout.  It views the thing not as a collection of independent cells, but as a virtual flow - a change in one cell might require the reflow of many other parts, toggling scroll bars visibility, reshaping the selection shapes, etc.
>> 
>> In an ideal world, the layout of text and embedded nodes would be a responsibility of the (prism) text layout, making it easier to have for example a Label with rich text.  But we don't have that option, so this design uses a collection of text cells to present the visible area, managed by the VFlow.
>
> Let me repeat what I mean:
> - If you call: `setManaged(false)`, you will effectively tell JavaFX: I'm the layout root, I can handle ALL layout changes from my children without my parents.
> - This is not the case here, so making the `TextCell` unmanaged while still retrieving a parent (`VFlow`) fights this design.
> - Which leads me to the conclusion: Maybe this should not be unmanaged, since it does not fulfill the required preconditions
> - Checking the `VirtualFlow` as an example, it will not set anything to unmanaged
> 
> Lets check some existing examples of unmanaged nodes:
> 
> `XYChart`. See how this was done by design, the consequences were known:
> https://github.com/openjdk/jfx/blob/33abf5d4b3d2b90f66581c4e25c542adf285fadd/modules/javafx.controls/src/main/java/javafx/scene/chart/XYChart.java#L523-L525
> 
> ---
> 
> `ScrollPaneSkin` has actually the same case as you. This is how they dealt with it:
> https://github.com/openjdk/jfx/blob/33abf5d4b3d2b90f66581c4e25c542adf285fadd/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java#L652-L653
> https://github.com/openjdk/jfx/blob/33abf5d4b3d2b90f66581c4e25c542adf285fadd/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java#L679-L689
> 
> This could be a solution for your problem. Since they also set the parent `viewRect` as unmanaged, the layout request will never hit the `ScrollPane`. But with that solution the child of the `viewRect`, called `viewContent` does request the `ScrollPane` layout. A clever solution without anything like ancestor searching. What do you think?

The documentation on `Node.managed` property states 

Defines whether or not this node's layout will be managed by its parent. 


The layout of TextCell is not managed by its parent (`VFlow.content`), **by design**.

The `VFlow` is the entity that does the layout, for a reason.  It's a complicated thing, and multiple moving parts are connected (one example: it performs multiple layout cycles in the same layout pass when scrollbars appear/disappear during the layout pass, to avoid jumping and flicker - something we occasionally see with `ScrollPane` and `ListView`, see Note 1).

Notes

1. I occasionally see the continuous flicker/layout when resizing the list of pages in the latest Monkey Tester, but so far I was unable to capture the exact conditions to create a reproducible test case (this is unrelated to this PR)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2550174581

From angorya at openjdk.org  Fri Nov 21 16:44:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Nov 2025 16:44:58 GMT
Subject: RFR: 8372298: RichTextArea: missing API: applyParagraphStyle
Message-ID: 

A missing protected method in StyledTextModel prevents from toggling of an individual paragraph attribute.

This can be tested with he latest Monkey Tester
https://github.com/andy-goryachev-oracle/MonkeyTest

- select the RichTextArea page
- select the RichTextArea model
- select Control -> Context Menu -> RichTextArea menu
- type in several paragraphs
- select all and apply one paragraph attribute, let's say Paragraph Styles -> Background -> (any non-null)
- select a subset of previously selected paragraphs and apply a second paragraph attribute, let's say Paragraph Styles -> Bullet -> (any non-null)

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

Commit messages:
 - test
 - fix

Changes: https://git.openjdk.org/jfx/pull/1980/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1980&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372298
  Stats: 94 lines in 8 files changed: 87 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1980.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1980/head:pull/1980

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

From angorya at openjdk.org  Fri Nov 21 16:51:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Nov 2025 16:51:02 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property [v10]
In-Reply-To: 
References: 
Message-ID: <5HHpZEcRHdBRdd1vIq3k6wv2cpxOPw8ioRWWvbJPGzY=.d8fdb1fb-e5d4-44fa-b77c-6d266092cc21@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
> 
> 
> 
> 
> ## 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 14 additional commits since the last revision:

 - 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
 - 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
 - ... and 4 more: https://git.openjdk.org/jfx/compare/5e09ed29...90aaf4c5

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1773/files
  - new: https://git.openjdk.org/jfx/pull/1773/files/ca4c1739..90aaf4c5

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

  Stats: 1888 lines in 66 files changed: 1546 ins; 65 del; 277 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 chad.preisler at gmail.com  Fri Nov 21 17:15:15 2025
From: chad.preisler at gmail.com (Chad Preisler)
Date: Fri, 21 Nov 2025 11:15:15 -0600
Subject: JavaFX application on KDE Wayland - tiny
Message-ID: 

Hello,

When I run my JavaFX (using JFX25) application on KDE Plasma using Wayland
the fonts are incredibly small. How can I scale the application so that
things are not so tiny?

FYI: I had a similar issue with Netbeans. I know it's different because it
is Swing. I was able to get Netbeans to look good with the following
settings.

-J-Dsun.java2d.uiScale=2 -J-Dflatlaf.uiScale=0.75

Is there something similar I can do for JavaFX?

Thanks,
Chad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kcr at openjdk.org  Fri Nov 21 18:56:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 21 Nov 2025 18:56:20 GMT
Subject: RFR: 8372303: Remove obsolete tbom files from /doc-files
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 Nov 2025 22:23:20 GMT, Andy Goryachev  wrote:

> Removed obsolete `.tbom` files.
> These files were used by a localization toolchain that is no longer in use.

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1979#pullrequestreview-3493990757

From kcr at openjdk.org  Fri Nov 21 18:56:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 21 Nov 2025 18:56:21 GMT
Subject: RFR: 8372303: Remove obsolete tbom files from /doc-files
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 Nov 2025 11:20:09 GMT, Marius Hanl  wrote:

> I don't know what was the usecase of those files in the first place, but removing unused stuff from the repository is always good.

They were added a long time ago in support of automated tools that help identify property strings in need of translation, but they are no longer used (and belong in a closed repo anyway).

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

PR Comment: https://git.openjdk.org/jfx/pull/1979#issuecomment-3564236210

From angorya at openjdk.org  Fri Nov 21 19:03:37 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Nov 2025 19:03:37 GMT
Subject: Integrated: 8372303: Remove obsolete tbom files from /doc-files
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 Nov 2025 22:23:20 GMT, Andy Goryachev  wrote:

> Removed obsolete `.tbom` files.
> These files were used by a localization toolchain that is no longer in use.

This pull request has now been integrated.

Changeset: e2c4a706
Author:    Andy Goryachev 
URL:       https://git.openjdk.org/jfx/commit/e2c4a7066c5ba5c232b7efc7210ac2e1a4a18da6
Stats:     39 lines in 2 files changed: 0 ins; 39 del; 0 mod

8372303: Remove obsolete tbom files from /doc-files

Reviewed-by: mhanl, kcr

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

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

From andy.goryachev at oracle.com  Fri Nov 21 19:10:25 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 21 Nov 2025 19:10:25 +0000
Subject: [External] : Re: RichTextArea Feedback
In-Reply-To: 
References: 
 
Message-ID: 

Dear Jurgen:

To follow up this conversation, after giving it some more thought, I think this change would be problematic - but for a different reason.  The segments in UndoableChange are only available in a model that supports undo.  If the model does not support undo/redo functionality, we don't have the UndoableChange and related segments, and I don't want to generate them.

Assuming that you absolutely cannot support your requirements with the existing APIs, and there is no reasonable workaround, the only possibility I see is to remove the final keyword from StyledTextModel applyStyle() and replace() methods.  The at least you can intercept these calls and do the required processing there.

I still not sure what the use case is for that though - don't you want to always process the updated document?  What is your use case?

Thanks,
-andy


From: Jurgen Doll 
Date: Tuesday, November 4, 2025 at 01:40
To: Andy Goryachev 
Cc: openjfx-dev 
Subject: Re: [External] : Re: RichTextArea Feedback

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  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 
> Date: Monday, November 3, 2025 at 00:36
> To: Andy Goryachev 
> 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: 

From angorya at openjdk.org  Fri Nov 21 19:17:41 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Nov 2025 19:17:41 GMT
Subject: RFR: 8371981: Wrong split caret positioning with mixed text
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 Nov 2025 20:04:42 GMT, Andy Goryachev  wrote:

> Fixing a silly mistake - mixed up `lineX2` and `lineY` parameters in `PrismTextLayout`.

@Ziad-Mid and @arapte could you please take a look?

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

PR Comment: https://git.openjdk.org/jfx/pull/1976#issuecomment-3564295887

From crschnick at xpipe.io  Fri Nov 21 19:33:23 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Fri, 21 Nov 2025 20:33:23 +0100
Subject: JavaFX application on KDE Wayland - tiny
In-Reply-To: 
References: 
Message-ID: <0288ed4e-c313-4d68-b745-3427ca8e4bb7@xpipe.io>

You are probably looking for glass.gtk.uiScale

I think I reported a while ago that the automatic scale detection for 
KDE is not working, but apparently there wasn't an easy API replacement 
available.

On 21/11/2025 18:15, Chad Preisler wrote:
> Hello,
>
> When I run my JavaFX (using JFX25) application on KDE Plasma using 
> Wayland the fonts are incredibly small. How can I scale the 
> application?so that things are not so tiny?
>
> FYI: I had a similar issue with Netbeans. I know it's different 
> because it is Swing. I was able to get Netbeans to look good with the 
> following settings.
>
> -J-Dsun.java2d.uiScale=2 -J-Dflatlaf.uiScale=0.75
>
> Is there something similar I can do for JavaFX?
>
> Thanks,
> Chad
>
>

From kcr at openjdk.org  Fri Nov 21 19:50:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 21 Nov 2025 19:50:21 GMT
Subject: RFR: 8335748: Rippling of frame on scrolling
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 Nov 2025 11:37:53 GMT, Ambarish Rapte  wrote:

> **Issue:** 
> With metal pipeline, frame tearing is observed when scrolling the content. Perform small fling gesture scrolls for observing the issue, the issue occurs/observed easily when scroll is coming to and end.
> 
> **Cause:**
> vsync is not enabled for metal pipeline.
> 
> **Fix:** 
> 1. Enable vsync for metal pipeline. The vsync shall be enabled by default. It can be disabled with `-Djavafx.animation.fullspeed=true`.
> 2. Synchronize the access to offline render target texture.
> 2.1 The `GlassMTLFrameBufferObject._texture` object is created and destroyed by **QuantumRenderer** thread, and
> 2.2 `GlassMTLFrameBufferObject._texture` is also accessed on **Appkit** thread through function `GlassLayerMTL.blitToScreen()`
> 2.3 NSLock is created to synchronize the acess
> 2.4 Without this synchronization, a crash could occur in scenario when JavaFX app window is moved between screens that differ in refresh rate.
> 
> **Verification:**
> 1. Test that no frame tearing is observed, when scrolling(easy to test with small fling scrolls)
> 2. Test no issue observed when moving window among screens.
> 3. General sanity testing of UI.
> 
> **Test:**
> A unit or system test is not possible for this scenario.

LGTM. On my Intel MacBook Pro with discrete graphics I can see the tearing without your fix and it looks good with the fix.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1978#pullrequestreview-3494146974

From kcr at openjdk.org  Fri Nov 21 19:55:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 21 Nov 2025 19:55:58 GMT
Subject: RFR: 8372298: RichTextArea: missing API: applyParagraphStyle
In-Reply-To: 
References: 
Message-ID: 

On Fri, 21 Nov 2025 16:19:07 GMT, Andy Goryachev  wrote:

> A missing protected method in StyledTextModel prevents from toggling of an individual paragraph attribute.
> 
> This can be tested with he latest Monkey Tester
> https://github.com/andy-goryachev-oracle/MonkeyTest
> 
> - select the RichTextArea page
> - select the RichTextArea model
> - select Control -> Context Menu -> RichTextArea menu
> - type in several paragraphs
> - select all and apply one paragraph attribute, let's say Paragraph Styles -> Background -> (any non-null)
> - select a subset of previously selected paragraphs and apply a second paragraph attribute, let's say Paragraph Styles -> Bullet -> (any non-null)

Other than a missing `@since` tag, this all looks good.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 216:

> 214:      * @param index the paragraph index
> 215:      * @param paragraphAttrs the paragraph attributes
> 216:      * @throws UnsupportedOperationException if the model is not {@link #isWritable() writable}

This method needs `@since 26`

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

PR Review: https://git.openjdk.org/jfx/pull/1980#pullrequestreview-3494061903
PR Review Comment: https://git.openjdk.org/jfx/pull/1980#discussion_r2550731997

From angorya at openjdk.org  Fri Nov 21 20:28:31 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Nov 2025 20:28:31 GMT
Subject: RFR: 8372298: RichTextArea: missing API: applyParagraphStyle [v2]
In-Reply-To: 
References: 
Message-ID: <2VNWdIW64BDKgMPe3PuRR7v-Ex5dzVrFnAKh35aqLHM=.834bafc7-cb39-43b3-ba27-1d298058b823@github.com>

> A missing protected method in StyledTextModel prevents from toggling of an individual paragraph attribute.
> 
> This can be tested with he latest Monkey Tester
> https://github.com/andy-goryachev-oracle/MonkeyTest
> 
> - select the RichTextArea page
> - select the RichTextArea model
> - select Control -> Context Menu -> RichTextArea menu
> - type in several paragraphs
> - select all and apply one paragraph attribute, let's say Paragraph Styles -> Background -> (any non-null)
> - select a subset of previously selected paragraphs and apply a second paragraph attribute, let's say Paragraph Styles -> Bullet -> (any non-null)

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

  since

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1980/files
  - new: https://git.openjdk.org/jfx/pull/1980/files/911aa322..0a7e6bb9

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

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

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

From angorya at openjdk.org  Fri Nov 21 20:47:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Nov 2025 20:47:01 GMT
Subject: RFR: 8372298: RichTextArea: missing API: applyParagraphStyle [v3]
In-Reply-To: 
References: 
Message-ID: 

> A missing protected method in StyledTextModel prevents from toggling of an individual paragraph attribute.
> 
> This can be tested with he latest Monkey Tester
> https://github.com/andy-goryachev-oracle/MonkeyTest
> 
> - select the RichTextArea page
> - select the RichTextArea model
> - select Control -> Context Menu -> RichTextArea menu
> - type in several paragraphs
> - select all and apply one paragraph attribute, let's say Paragraph Styles -> Background -> (any non-null)
> - select a subset of previously selected paragraphs and apply a second paragraph attribute, let's say Paragraph Styles -> Bullet -> (any non-null)

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 four additional commits since the last revision:

 - Merge branch 'master' into 8372298.apply
 - since
 - test
 - fix

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1980/files
  - new: https://git.openjdk.org/jfx/pull/1980/files/0a7e6bb9..20fe2077

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

  Stats: 314 lines in 5 files changed: 202 ins; 45 del; 67 mod
  Patch: https://git.openjdk.org/jfx/pull/1980.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1980/head:pull/1980

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

From kcr at openjdk.org  Fri Nov 21 20:59:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 21 Nov 2025 20:59:16 GMT
Subject: RFR: 8372298: RichTextArea: missing API: applyParagraphStyle [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 Nov 2025 20:47:01 GMT, Andy Goryachev  wrote:

>> A missing protected method in StyledTextModel prevents from toggling of an individual paragraph attribute.
>> 
>> This can be tested with he latest Monkey Tester
>> https://github.com/andy-goryachev-oracle/MonkeyTest
>> 
>> - select the RichTextArea page
>> - select the RichTextArea model
>> - select Control -> Context Menu -> RichTextArea menu
>> - type in several paragraphs
>> - select all and apply one paragraph attribute, let's say Paragraph Styles -> Background -> (any non-null)
>> - select a subset of previously selected paragraphs and apply a second paragraph attribute, let's say Paragraph Styles -> Bullet -> (any non-null)
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8372298.apply
>  - since
>  - test
>  - fix

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1980#pullrequestreview-3494330529

From kevin.rushforth at oracle.com  Fri Nov 21 22:00:06 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 21 Nov 2025 14:00:06 -0800
Subject: JavaFX application on KDE Wayland - tiny
In-Reply-To: <0288ed4e-c313-4d68-b745-3427ca8e4bb7@xpipe.io>
References: 
 <0288ed4e-c313-4d68-b745-3427ca8e4bb7@xpipe.io>
Message-ID: <1d585681-2194-4783-a019-d31ca0db0743@oracle.com>

Another workaround is to set the "GDK_SCALE" environment variable, for 
example:

export GDK_SCALE=2

I found the following enhancement request in our bug backlog requesting 
automatic detection of the screen scale:

https://bugs.openjdk.org/browse/JDK-8238077

I changed the title to be more reflective of this and reassigned the 
bug. It's something that we could consider implementing if it isn't too 
difficult.

-- Kevin


On 11/21/2025 11:33 AM, Christopher Schnick wrote:
> You are probably looking for glass.gtk.uiScale
>
> I think I reported a while ago that the automatic scale detection for 
> KDE is not working, but apparently there wasn't an easy API 
> replacement available.
>
> On 21/11/2025 18:15, Chad Preisler wrote:
>> Hello,
>>
>> When I run my JavaFX (using JFX25) application on KDE Plasma using 
>> Wayland the fonts are incredibly small. How can I scale the 
>> application?so that things are not so tiny?
>>
>> FYI: I had a similar issue with Netbeans. I know it's different 
>> because it is Swing. I was able to get Netbeans to look good with the 
>> following settings.
>>
>> -J-Dsun.java2d.uiScale=2 -J-Dflatlaf.uiScale=0.75
>>
>> Is there something similar I can do for JavaFX?
>>
>> Thanks,
>> Chad
>>
>>


From angorya at openjdk.org  Fri Nov 21 22:00:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Nov 2025 22:00:19 GMT
Subject: RFR: 8372203: Piecewise linear easing function
In-Reply-To: 
References: 
Message-ID: <0jypoZLukwB3rjNASv-WAOq2wue_HbtLoC1C0Ncaziw=.1575c162-d9bb-41f1-b23c-06c69eae9a16@github.com>

On Wed, 19 Nov 2025 21:36:36 GMT, Michael Strau?  wrote:

> Implementation of the [linear](https://www.w3.org/TR/css-easing-2/#the-linear-easing-function) easing function, which is now widely supported by all browsers, but still missing in JavaFX.
> 
> It allows developers to approximate arbitrary easing functions with linear segments:
> 
> 
> linear(
>     /* Start to 1st bounce */
>     0, 0.063, 0.25, 0.563, 1 36.4%,
>     /* 1st to 2nd bounce */
>     0.812, 0.75, 0.813, 1 72.7%,
>     /* 2nd to 3rd bounce */
>     0.953, 0.938, 0.953, 1 90.9%,
>     /* 3rd bounce to end */
>     0.984, 1 100% 100%
>   )
> 
> 
> 

Could you provide an example (in the JBS maybe) of a CSS that illustrates the usage?  Or maybe add an example to the javadoc?

modules/javafx.graphics/src/main/java/com/sun/scenario/animation/LinearInterpolator.java line 76:

> 74:         // Ensure that the input progress value of each control point is greater than or equal to the
> 75:         // input progress values of all preceding control points (monotonically non-decreasing).
> 76:         double largestX = controlPoints[0];

Question: what happens when a esquence is specified which is somehow invalid?  Will it throw an exception, write to stderr, or silently ignore?

(I can't think of an invalid sequence, maybe `0, 0 0% 0%, 0 -10%, NaN` ?)

modules/javafx.graphics/src/main/java/com/sun/scenario/animation/LinearInterpolator.java line 198:

> 196: 
> 197:         // Linearly interpolate (or extrapolate) along the segment (ax, ay) -> (bx, by).
> 198:         if (ax == bx) {

FP alert: is it possible for `ax != bx` yet the result of division on L203 to produce an infinity?

modules/javafx.graphics/src/test/java/test/com/sun/scenario/animation/LinearInterpolatorTest.java line 41:

> 39:         try {
> 40:             Field f = LinearInterpolator.class.getDeclaredField("controlPoints");
> 41:             f.setAccessible(true);

should an Accessor be used instead?

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

PR Review: https://git.openjdk.org/jfx/pull/1977#pullrequestreview-3494451006
PR Review Comment: https://git.openjdk.org/jfx/pull/1977#discussion_r2551033935
PR Review Comment: https://git.openjdk.org/jfx/pull/1977#discussion_r2551042657
PR Review Comment: https://git.openjdk.org/jfx/pull/1977#discussion_r2551048049

From crschnick at xpipe.io  Fri Nov 21 22:05:04 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Fri, 21 Nov 2025 23:05:04 +0100
Subject: JavaFX application on KDE Wayland - tiny
In-Reply-To: <1d585681-2194-4783-a019-d31ca0db0743@oracle.com>
References: 
 <0288ed4e-c313-4d68-b745-3427ca8e4bb7@xpipe.io>
 <1d585681-2194-4783-a019-d31ca0db0743@oracle.com>
Message-ID: <3da7d47f-04b2-419e-bf30-e80750460373@xpipe.io>

I think this was the issue I mentioned: 
https://bugs.openjdk.org/browse/JDK-8326428

On 21/11/2025 23:00, Kevin Rushforth wrote:
> Another workaround is to set the "GDK_SCALE" environment variable, for 
> example:
>
> export GDK_SCALE=2
>
> I found the following enhancement request in our bug backlog 
> requesting automatic detection of the screen scale:
>
> https://bugs.openjdk.org/browse/JDK-8238077
>
> I changed the title to be more reflective of this and reassigned the 
> bug. It's something that we could consider implementing if it isn't 
> too difficult.
>
> -- Kevin
>
>
> On 11/21/2025 11:33 AM, Christopher Schnick wrote:
>> You are probably looking for glass.gtk.uiScale
>>
>> I think I reported a while ago that the automatic scale detection for 
>> KDE is not working, but apparently there wasn't an easy API 
>> replacement available.
>>
>> On 21/11/2025 18:15, Chad Preisler wrote:
>>> Hello,
>>>
>>> When I run my JavaFX (using JFX25) application on KDE Plasma using 
>>> Wayland the fonts are incredibly small. How can I scale the 
>>> application?so that things are not so tiny?
>>>
>>> FYI: I had a similar issue with Netbeans. I know it's different 
>>> because it is Swing. I was able to get Netbeans to look good with 
>>> the following settings.
>>>
>>> -J-Dsun.java2d.uiScale=2 -J-Dflatlaf.uiScale=0.75
>>>
>>> Is there something similar I can do for JavaFX?
>>>
>>> Thanks,
>>> Chad
>>>
>>>
>

From angorya at openjdk.org  Fri Nov 21 22:08:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Nov 2025 22:08:03 GMT
Subject: RFR: 8372203: Piecewise linear easing function
In-Reply-To: <0jypoZLukwB3rjNASv-WAOq2wue_HbtLoC1C0Ncaziw=.1575c162-d9bb-41f1-b23c-06c69eae9a16@github.com>
References: 
 <0jypoZLukwB3rjNASv-WAOq2wue_HbtLoC1C0Ncaziw=.1575c162-d9bb-41f1-b23c-06c69eae9a16@github.com>
Message-ID: 

On Fri, 21 Nov 2025 21:46:07 GMT, Andy Goryachev  wrote:

>> Implementation of the [linear](https://www.w3.org/TR/css-easing-2/#the-linear-easing-function) easing function, which is now widely supported by all browsers, but still missing in JavaFX.
>> 
>> It allows developers to approximate arbitrary easing functions with linear segments:
>> 
>> 
>> linear(
>>     /* Start to 1st bounce */
>>     0, 0.063, 0.25, 0.563, 1 36.4%,
>>     /* 1st to 2nd bounce */
>>     0.812, 0.75, 0.813, 1 72.7%,
>>     /* 2nd to 3rd bounce */
>>     0.953, 0.938, 0.953, 1 90.9%,
>>     /* 3rd bounce to end */
>>     0.984, 1 100% 100%
>>   )
>> 
>> 
>> 
>
> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/LinearInterpolator.java line 198:
> 
>> 196: 
>> 197:         // Linearly interpolate (or extrapolate) along the segment (ax, ay) -> (bx, by).
>> 198:         if (ax == bx) {
> 
> FP alert: is it possible for `ax != bx` yet the result of division on L203 to produce an infinity?

jshell> 1 / 9e-310
$25 ==> Infinity

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1977#discussion_r2551083513

From mstrauss at openjdk.org  Sat Nov 22 08:38:03 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 22 Nov 2025 08:38:03 GMT
Subject: RFR: 8372203: Piecewise linear easing function
In-Reply-To: <0jypoZLukwB3rjNASv-WAOq2wue_HbtLoC1C0Ncaziw=.1575c162-d9bb-41f1-b23c-06c69eae9a16@github.com>
References: 
 <0jypoZLukwB3rjNASv-WAOq2wue_HbtLoC1C0Ncaziw=.1575c162-d9bb-41f1-b23c-06c69eae9a16@github.com>
Message-ID: 

On Fri, 21 Nov 2025 21:57:15 GMT, Andy Goryachev  wrote:

> Could you provide an example (in the JBS maybe) of a CSS that illustrates the usage? Or maybe add an example to the javadoc?

I've added three examples of linear easing functions to cssref.html, do you think there's something missing?

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

PR Comment: https://git.openjdk.org/jfx/pull/1977#issuecomment-3566115934

From mstrauss at openjdk.org  Sat Nov 22 08:51:40 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 22 Nov 2025 08:51:40 GMT
Subject: RFR: 8372203: Piecewise linear easing function
In-Reply-To: <0jypoZLukwB3rjNASv-WAOq2wue_HbtLoC1C0Ncaziw=.1575c162-d9bb-41f1-b23c-06c69eae9a16@github.com>
References: 
 <0jypoZLukwB3rjNASv-WAOq2wue_HbtLoC1C0Ncaziw=.1575c162-d9bb-41f1-b23c-06c69eae9a16@github.com>
Message-ID: 

On Fri, 21 Nov 2025 21:40:57 GMT, Andy Goryachev  wrote:

>> Implementation of the [linear](https://www.w3.org/TR/css-easing-2/#the-linear-easing-function) easing function, which is now widely supported by all browsers, but still missing in JavaFX.
>> 
>> It allows developers to approximate arbitrary easing functions with linear segments:
>> 
>> 
>> linear(
>>     /* Start to 1st bounce */
>>     0, 0.063, 0.25, 0.563, 1 36.4%,
>>     /* 1st to 2nd bounce */
>>     0.812, 0.75, 0.813, 1 72.7%,
>>     /* 2nd to 3rd bounce */
>>     0.953, 0.938, 0.953, 1 90.9%,
>>     /* 3rd bounce to end */
>>     0.984, 1 100% 100%
>>   )
>> 
>> 
>> 
>
> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/LinearInterpolator.java line 76:
> 
>> 74:         // Ensure that the input progress value of each control point is greater than or equal to the
>> 75:         // input progress values of all preceding control points (monotonically non-decreasing).
>> 76:         double largestX = controlPoints[0];
> 
> Question: what happens when a esquence is specified which is somehow invalid?  Will it throw an exception, write to stderr, or silently ignore?
> 
> (I can't think of an invalid sequence, maybe `0, 0 0% 0%, 0 -10%, NaN` ?)

The sequence will always be successfully canonicalized, so there's never a log output or exception. In your example, the canonicalized easing function will be 0 for t=0, and NaN for t>0. If you use this function in an animation, you may get weird values and undefined things may happen. This is not unique to easing functions: we almost never handle NaNs in JavaFX. For example, you can construct a `Color` with NaN components (which is what would happen if you used your easing function in a color transition).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1977#discussion_r2552633277

From mstrauss at openjdk.org  Sat Nov 22 09:06:44 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 22 Nov 2025 09:06:44 GMT
Subject: RFR: 8372203: Piecewise linear easing function
In-Reply-To: 
References: 
Message-ID: 

On Wed, 19 Nov 2025 21:36:36 GMT, Michael Strau?  wrote:

> Implementation of the [linear](https://www.w3.org/TR/css-easing-2/#the-linear-easing-function) easing function, which is now widely supported by all browsers, but still missing in JavaFX.
> 
> It allows developers to approximate arbitrary easing functions with linear segments:
> 
> 
> linear(
>     /* Start to 1st bounce */
>     0, 0.063, 0.25, 0.563, 1 36.4%,
>     /* 1st to 2nd bounce */
>     0.812, 0.75, 0.813, 1 72.7%,
>     /* 2nd to 3rd bounce */
>     0.953, 0.938, 0.953, 1 90.9%,
>     /* 3rd bounce to end */
>     0.984, 1 100% 100%
>   )
> 
> 
> 

Maybe we should retire the weird naming scheme used in this class (uppercasing the name of methods), or at least not proliferate it any further. So instead of `LINEAR(Point2D...)` we would have `ofLinear(Point2D...)` or `linear(Point2D...)`. We could add similar variants for the rest of the weird methods (`SPLINE()`, `TANGENT()`, `STEPS()`).

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

PR Comment: https://git.openjdk.org/jfx/pull/1977#issuecomment-3566227558

From mstrauss at openjdk.org  Sat Nov 22 10:06:56 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 22 Nov 2025 10:06:56 GMT
Subject: RFR: 8372203: Piecewise linear easing function [v2]
In-Reply-To: 
References: 
Message-ID: <_ncebwfKqeq-6lsIMtzdLb6mtJg3YvDXfzr-GorD9Y0=.71c88969-b491-4eec-880e-4c0620651249@github.com>

> Implementation of the [linear](https://www.w3.org/TR/css-easing-2/#the-linear-easing-function) easing function, which is now widely supported by all browsers, but still missing in JavaFX.
> 
> It allows developers to approximate arbitrary easing functions with linear segments:
> 
> 
> linear(
>     /* Start to 1st bounce */
>     0, 0.063, 0.25, 0.563, 1 36.4%,
>     /* 1st to 2nd bounce */
>     0.812, 0.75, 0.813, 1 72.7%,
>     /* 2nd to 3rd bounce */
>     0.953, 0.938, 0.953, 1 90.9%,
>     /* 3rd bounce to end */
>     0.984, 1 100% 100%
>   )
> 
> 
> 

Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:

 - numeric overflow to infinity
 - refactor tests

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1977/files
  - new: https://git.openjdk.org/jfx/pull/1977/files/347a0ea4..94bc4fd0

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

  Stats: 72 lines in 2 files changed: 36 ins; 18 del; 18 mod
  Patch: https://git.openjdk.org/jfx/pull/1977.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1977/head:pull/1977

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

From mstrauss at openjdk.org  Sat Nov 22 10:14:00 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 22 Nov 2025 10:14:00 GMT
Subject: RFR: 8372203: Piecewise linear easing function [v2]
In-Reply-To: 
References: 
 <0jypoZLukwB3rjNASv-WAOq2wue_HbtLoC1C0Ncaziw=.1575c162-d9bb-41f1-b23c-06c69eae9a16@github.com>
 
Message-ID: 

On Fri, 21 Nov 2025 22:04:34 GMT, Andy Goryachev  wrote:

>> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/LinearInterpolator.java line 198:
>> 
>>> 196: 
>>> 197:         // Linearly interpolate (or extrapolate) along the segment (ax, ay) -> (bx, by).
>>> 198:         if (ax == bx) {
>> 
>> FP alert: is it possible for `ax != bx` yet the result of division on L203 to produce an infinity?
>
> jshell> 1 / 9e-310
> $25 ==> Infinity

I've added code to ensure that when an infinity is unavoidable, we at least get an infinity consistent with the line (and not, say, NaN). While this makes this interpolator locally consistent, we may still end up passing infinities into the animation system, so it's not a catch-all solution (that would be a completely different thing that we're not going to solve in interpolators).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1977#discussion_r2552853988

From mstrauss at openjdk.org  Sat Nov 22 10:14:01 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 22 Nov 2025 10:14:01 GMT
Subject: RFR: 8372203: Piecewise linear easing function [v2]
In-Reply-To: <0jypoZLukwB3rjNASv-WAOq2wue_HbtLoC1C0Ncaziw=.1575c162-d9bb-41f1-b23c-06c69eae9a16@github.com>
References: 
 <0jypoZLukwB3rjNASv-WAOq2wue_HbtLoC1C0Ncaziw=.1575c162-d9bb-41f1-b23c-06c69eae9a16@github.com>
Message-ID: 

On Fri, 21 Nov 2025 21:48:34 GMT, Andy Goryachev  wrote:

>> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - numeric overflow to infinity
>>  - refactor tests
>
> modules/javafx.graphics/src/test/java/test/com/sun/scenario/animation/LinearInterpolatorTest.java line 41:
> 
>> 39:         try {
>> 40:             Field f = LinearInterpolator.class.getDeclaredField("controlPoints");
>> 41:             f.setAccessible(true);
> 
> should an Accessor be used instead?

I'm not a big fan of that because of its impact on the source code of the class (you know those comments: "package-private only for the sake of testing").

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1977#discussion_r2552859552

From mstrauss at openjdk.org  Sat Nov 22 12:06:00 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 22 Nov 2025 12:06:00 GMT
Subject: RFR: 8335748: Rippling of frame on scrolling
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 Nov 2025 11:37:53 GMT, Ambarish Rapte  wrote:

> **Issue:** 
> With metal pipeline, frame tearing is observed when scrolling the content. Perform small fling gesture scrolls for observing the issue, the issue occurs/observed easily when scroll is coming to and end.
> 
> **Cause:**
> vsync is not enabled for metal pipeline.
> 
> **Fix:** 
> 1. Enable vsync for metal pipeline. The vsync shall be enabled by default. It can be disabled with `-Djavafx.animation.fullspeed=true`.
> 2. Synchronize the access to offline render target texture.
> 2.1 The `GlassMTLFrameBufferObject._texture` object is created and destroyed by **QuantumRenderer** thread, and
> 2.2 `GlassMTLFrameBufferObject._texture` is also accessed on **Appkit** thread through function `GlassLayerMTL.blitToScreen()`
> 2.3 NSLock is created to synchronize the acess
> 2.4 Without this synchronization, a crash could occur in scenario when JavaFX app window is moved between screens that differ in refresh rate.
> 
> **Verification:**
> 1. Test that no frame tearing is observed, when scrolling(easy to test with small fling scrolls)
> 2. Test no issue observed when moving window among screens.
> 3. General sanity testing of UI.
> 
> **Test:**
> A unit or system test is not possible for this scenario.

Tested on iMac M1. I can see that frame tearing is no longer an issue with this fix.

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

Marked as reviewed by mstrauss (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1978#pullrequestreview-3496720574

From chad.preisler at gmail.com  Sat Nov 22 14:23:07 2025
From: chad.preisler at gmail.com (Chad Preisler)
Date: Sat, 22 Nov 2025 08:23:07 -0600
Subject: JavaFX application on KDE Wayland - tiny
In-Reply-To: <3da7d47f-04b2-419e-bf30-e80750460373@xpipe.io>
References: 
 <0288ed4e-c313-4d68-b745-3427ca8e4bb7@xpipe.io>
 <1d585681-2194-4783-a019-d31ca0db0743@oracle.com>
 <3da7d47f-04b2-419e-bf30-e80750460373@xpipe.io>
Message-ID: 

Thanks for the suggestions. Both suggestions work and look good. Here are
some observations from my testing.

glass.gtk.uiScale:
- Looks great.
- Allows for decimal values.
- On my 2k monitor 1.25 looked best.
- If the KDE "Scaled by the system" setting is turned on, then using this
setting makes the scene larger than expected.

export GDK_SCALE=2:
- Looks great.
- It appears it only allows whole numbers, and 2.0 was a little too large
for my taste.
- If the KDE "Scaled by the system" setting is turned on, then using this
setting makes the scene larger than expected.

Scaled by the system:
- Looks great
- Looks like it scales it about 1.25
- Netbeans looks pretty good with this setting, but I needed to
set --fontsize 14 in the netbeans.conf file. Netbeans looks a little better
when it's scaled using uiScale and flatlaf settings.

Under all settings when the application started up it appeared in the top
left corner of the first screen. Pop-ups in the application were not
centered and were up and off the upper left corner of the scene.

I guess until JavaFX can be a pure wayland client I'm personally going to
stick with the "Scaled by the system" setting. I guess if I ever bundle and
deploy my app I would recommend users to do the same.

On Fri, Nov 21, 2025 at 4:05?PM Christopher Schnick 
wrote:

> I think this was the issue I mentioned:
> https://bugs.openjdk.org/browse/JDK-8326428
>
> On 21/11/2025 23:00, Kevin Rushforth wrote:
> > Another workaround is to set the "GDK_SCALE" environment variable, for
> > example:
> >
> > export GDK_SCALE=2
> >
> > I found the following enhancement request in our bug backlog
> > requesting automatic detection of the screen scale:
> >
> > https://bugs.openjdk.org/browse/JDK-8238077
> >
> > I changed the title to be more reflective of this and reassigned the
> > bug. It's something that we could consider implementing if it isn't
> > too difficult.
> >
> > -- Kevin
> >
> >
> > On 11/21/2025 11:33 AM, Christopher Schnick wrote:
> >> You are probably looking for glass.gtk.uiScale
> >>
> >> I think I reported a while ago that the automatic scale detection for
> >> KDE is not working, but apparently there wasn't an easy API
> >> replacement available.
> >>
> >> On 21/11/2025 18:15, Chad Preisler wrote:
> >>> Hello,
> >>>
> >>> When I run my JavaFX (using JFX25) application on KDE Plasma using
> >>> Wayland the fonts are incredibly small. How can I scale the
> >>> application so that things are not so tiny?
> >>>
> >>> FYI: I had a similar issue with Netbeans. I know it's different
> >>> because it is Swing. I was able to get Netbeans to look good with
> >>> the following settings.
> >>>
> >>> -J-Dsun.java2d.uiScale=2 -J-Dflatlaf.uiScale=0.75
> >>>
> >>> Is there something similar I can do for JavaFX?
> >>>
> >>> Thanks,
> >>> Chad
> >>>
> >>>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mhanl at openjdk.org  Sat Nov 22 16:46:16 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 22 Nov 2025 16:46:16 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow [v2]
In-Reply-To: <15B47nEG5NEyJ3_nw6BLCYOvM8HhUi2QtYzD4WQjpVI=.21e08564-174a-491b-8071-d7f12556a5cf@github.com>
References: 
 
 
 
 <5VyBDD2XQvsuhNu3DRF6XXSwSzTe3BaN_13HdThVwxE=.86a1a532-e60c-4abc-a8f9-953ee2d1546e@github.com>
 
 
 
 
 <15B47nEG5NEyJ3_nw6BLCYOvM8HhUi2QtYzD4WQjpVI=.21e08564-174a-491b-8071-d7f12556a5cf@github.com>
Message-ID: <82HYP1uLEGi0kmqTxpcNLzGMcYXvFu1TOTLASSWR6TI=.cf084c42-17ba-4cc5-9ece-11f74f05328d@github.com>

On Fri, 21 Nov 2025 15:39:39 GMT, Andy Goryachev  wrote:

>> Let me repeat what I mean:
>> - If you call: `setManaged(false)`, you will effectively tell JavaFX: I'm the layout root, I can handle ALL layout changes from my children without my parents.
>> - This is not the case here, so making the `TextCell` unmanaged while still retrieving a parent (`VFlow`) fights this design.
>> - Which leads me to the conclusion: Maybe this should not be unmanaged, since it does not fulfill the required preconditions
>> - Checking the `VirtualFlow` as an example, it will not set anything to unmanaged
>> 
>> Lets check some existing examples of unmanaged nodes:
>> 
>> `XYChart`. See how this was done by design, the consequences were known:
>> https://github.com/openjdk/jfx/blob/33abf5d4b3d2b90f66581c4e25c542adf285fadd/modules/javafx.controls/src/main/java/javafx/scene/chart/XYChart.java#L523-L525
>> 
>> ---
>> 
>> `ScrollPaneSkin` has actually the same case as you. This is how they dealt with it:
>> https://github.com/openjdk/jfx/blob/33abf5d4b3d2b90f66581c4e25c542adf285fadd/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java#L652-L653
>> https://github.com/openjdk/jfx/blob/33abf5d4b3d2b90f66581c4e25c542adf285fadd/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java#L679-L689
>> 
>> This could be a solution for your problem. Since they also set the parent `viewRect` as unmanaged, the layout request will never hit the `ScrollPane`. But with that solution the child of the `viewRect`, called `viewContent` does request the `ScrollPane` layout. A clever solution without anything like ancestor searching. What do you think?
>
> The documentation on `Node.managed` property states 
> 
> Defines whether or not this node's layout will be managed by its parent. 
> 
> 
> The layout of TextCell is not managed by its parent (`VFlow.content`), **by design**.
> 
> The `VFlow` is the entity that does the layout, for a reason.  It's a complicated thing, and multiple moving parts are connected (one example: it performs multiple layout cycles in the same layout pass when scrollbars appear/disappear during the layout pass, to avoid jumping and flicker - something we occasionally see with `ScrollPane` and `ListView`, see Note 1).
> 
> Notes
> 
> 1. I occasionally see the continuous flicker/layout when resizing the list of pages in the latest Monkey Tester, but so far I was unable to capture the exact conditions to create a reproducible test case (this is unrelated to this PR)

Did you read what I wrote above? I made multiple suggestions as how we can deal with the situation, even without making things managed again.

To reiterate, what is the problem?
- We now have a dependency from `TextCell` to `VFlow`. Not explicitly, but rather hidden, by searching all parents (which is also costly when doing that often). I would prefer a clear separation of concerns
- This makes subclassing/extending harder. What happens, if I want to write my own `VFlow`, but still use everything else, including `TextCell`? What if I want to use `TextCell` for a component, that has no `VFlow`? What happens if we find a `VFlow` from another component even? Because we used the `TextCell` somewhere else?
- Other components made it clear how to use `managed` and `unamanged` nodes. And how to bubble up a request still. Why do we want to make an exception here? This is the first time we need to search the parent hierarchy
- Why not e.g. binding to the `needsLayoutProperty` from a `TextCell` from within `VFlow` and just request the layout when set?

Also another point: The test is green for me with the changes from: https://github.com/openjdk/jfx/pull/1945
So I would like to know, if maybe there was a bug even?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2553234576

From martinfox656 at gmail.com  Sat Nov 22 17:35:27 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Sat, 22 Nov 2025 09:35:27 -0800
Subject: JavaFX application on KDE Wayland - tiny
In-Reply-To: 
References: 
 <0288ed4e-c313-4d68-b745-3427ca8e4bb7@xpipe.io>
 <1d585681-2194-4783-a019-d31ca0db0743@oracle.com>
 <3da7d47f-04b2-419e-bf30-e80750460373@xpipe.io>
 
Message-ID: 

Chad,

I?d like to better understand why you encountered this problem to begin with. In the past we?ve only had difficulties on KDE when the user configured fractional scaling in System Settings. If the global scale in Display Settings is 200% you should be fine. If it?s something like 175% then JavaFX will misbehave. As Christopher pointed out the details are in https://bugs.openjdk.org/browse/JDK-8326428.

I would like to reproduce your setup. Which distro and version are you running? And what value are you using for global scale in System Settings > Display Configuration?

At least in the past this hasn?t been due to Wayland vs. Xorg. When fractional scaling is in effect KDE plays games with some legacy settings which JavaFX responds to (the fix for JDK-8326428 is to reduce their priority). They?re the GDK_SCALE environment variable and an internal Gnome setting:

	gsettings get org.gnome.desktop.interface scaling-factor

It?s also possible you?re running into some new issue not covered by JDK-8326428. That windows are being misplaced on your system makes me think something more is going on. And we should be able to get that right whether we?re a Wayland client or not.

Thanks,
Martin

> On Nov 22, 2025, at 6:23?AM, Chad Preisler  wrote:
> 
> Thanks for the suggestions. Both suggestions work and look good. Here are some observations from my testing.
> 
> glass.gtk.uiScale:
> - Looks great.
> - Allows for decimal values. 
> - On my 2k monitor 1.25 looked best.
> - If the KDE "Scaled by the system" setting is turned on, then using this setting makes the scene larger than expected.
> 
> export GDK_SCALE=2:
> - Looks great.
> - It appears it only allows whole numbers, and 2.0 was a little too large for my taste.
> - If the KDE "Scaled by the system" setting is turned on, then using this setting makes the scene larger than expected.
> 
> Scaled by the system:
> - Looks great
> - Looks like it scales it about 1.25
> - Netbeans looks pretty good with this setting, but I needed to set --fontsize 14 in the netbeans.conf file. Netbeans looks a little better when it's scaled using uiScale and flatlaf settings.
> 
> Under all settings when the application started up it appeared in the top left corner of the first screen. Pop-ups in the application were not centered and were up and off the upper left corner of the scene.
> 
> I guess until JavaFX can be a pure wayland client I'm personally going to stick with the "Scaled by the system" setting. I guess if I ever bundle and deploy my app I would recommend users to do the same.
> 
> On Fri, Nov 21, 2025 at 4:05?PM Christopher Schnick > wrote:
>> I think this was the issue I mentioned: 
>> https://bugs.openjdk.org/browse/JDK-8326428
>> 
>> On 21/11/2025 23:00, Kevin Rushforth wrote:
>> > Another workaround is to set the "GDK_SCALE" environment variable, for 
>> > example:
>> >
>> > export GDK_SCALE=2
>> >
>> > I found the following enhancement request in our bug backlog 
>> > requesting automatic detection of the screen scale:
>> >
>> > https://bugs.openjdk.org/browse/JDK-8238077
>> >
>> > I changed the title to be more reflective of this and reassigned the 
>> > bug. It's something that we could consider implementing if it isn't 
>> > too difficult.
>> >
>> > -- Kevin
>> >
>> >
>> > On 11/21/2025 11:33 AM, Christopher Schnick wrote:
>> >> You are probably looking for glass.gtk.uiScale
>> >>
>> >> I think I reported a while ago that the automatic scale detection for 
>> >> KDE is not working, but apparently there wasn't an easy API 
>> >> replacement available.
>> >>
>> >> On 21/11/2025 18:15, Chad Preisler wrote:
>> >>> Hello,
>> >>>
>> >>> When I run my JavaFX (using JFX25) application on KDE Plasma using 
>> >>> Wayland the fonts are incredibly small. How can I scale the 
>> >>> application so that things are not so tiny?
>> >>>
>> >>> FYI: I had a similar issue with Netbeans. I know it's different 
>> >>> because it is Swing. I was able to get Netbeans to look good with 
>> >>> the following settings.
>> >>>
>> >>> -J-Dsun.java2d.uiScale=2 -J-Dflatlaf.uiScale=0.75
>> >>>
>> >>> Is there something similar I can do for JavaFX?
>> >>>
>> >>> Thanks,
>> >>> Chad
>> >>>
>> >>>
>> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From john.hendrikx at gmail.com  Sat Nov 22 20:35:56 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sat, 22 Nov 2025 21:35:56 +0100
Subject: Faster listener removal
Message-ID: <447f27e0-372a-4538-9371-c2f775ba04e2@gmail.com>

A long time ago there was some discussion on large listener lists, and
how they perform very poorly when cleaning up (removing existing listeners).

A listener list basically needs to support the following operations:

- append at end, allowing duplicates
- remove by value, removing the first (oldest) match only
- iteration

It has no other needs.

There was some discussion if this could be replaced with a
LinkedHashMap, but it handles duplicates subtly different and is not
very fast at iteration (lots of random memory accesses).

So I created what is best described as an "ordered" bag.? It allows
adding and removal, while maintaining order and because it is backed by
(amongst others) an ordered array, iteration is about as fast as what
ArrayList does.? It has?O(1) insertion, O(1) removal, O(n) iteration,
but about 3x the memory requirements (not including the listener cost
itself), unless the list is small (for small lists the overhead is only
slightly higher than ArrayList).

Insertion is about 5x slower than ArrayList; Removal is far faster (150x
faster for a 10000 listener case); Iteration is?almost equally fast.

Because it has the exact same semantics as an (Array)List with regards
to duplicates and their removal order, it is a drop-in replacement.

Internally it works by maintaining an ordered array (basically what
ArrayList has) which is allowed to have removal gaps that are skipped
during iteration.? When the array needs to grow, it first sees if it can
consolidate the gaps before increasing the size (and it also shrinks on
demand, unlike ArrayList).? Other than that, for lists above a certain
size, it maintains three additional arrays; these are used to maintain
hashed linked lists of similar elements (basically a singly linked list
per bucket, but with fast appends at the end using a tail pointer).

When the number of listeners is low, the implementation falls back on
the simple array only (and the other 3 lists are nulled), which means
that for small lists the overhead is minimal.? It's sort of a best of
both worlds thing (although there is always overhead), where it uses
minimal memory for small lists and simply scans the entire list for
removals, while for large lists it initializes additional structures to
allow for quick removals at any size.

Thoughts?

--John


From chad.preisler at gmail.com  Sat Nov 22 20:57:45 2025
From: chad.preisler at gmail.com (Chad Preisler)
Date: Sat, 22 Nov 2025 14:57:45 -0600
Subject: JavaFX application on KDE Wayland - tiny
In-Reply-To: 
References: 
 <0288ed4e-c313-4d68-b745-3427ca8e4bb7@xpipe.io>
 <1d585681-2194-4783-a019-d31ca0db0743@oracle.com>
 <3da7d47f-04b2-419e-bf30-e80750460373@xpipe.io>
 
 
Message-ID: 

I'm running on a brand new Infinity Book Pro from Tuxedo Computers. Here is
the system info.

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=24.04
DISTRIB_CODENAME=noble
DISTRIB_DESCRIPTION="TUXEDO OS 24.04.3 LTS"
NAME="TUXEDO OS"
VERSION="24.04.3 LTS"
ID=tuxedo
ID_LIKE="ubuntu debian"
PRETTY_NAME="TUXEDO OS"
VERSION_ID="24.04"

KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.17.0
Qt Version: 6.8.2
Kernel: 6.14.0-116036-tuxedo (64-bit)
Graphics: Wayland

I did some more testing and found that the scaling issues happen in a dual
monitor environment where the scaling factor is different between the two
monitors. Here is my setup.

Built-in Screen: 2653x1600, 130%
Samsung Odyssey G5 2560x1440, 0%

When running with two monitors with "Scaled by system" off:
- Things look sharp on the monitor with scaling (Built-in). However, fonts
get pretty blurry on the unscaled monitor (G5).
- If I scale up the unscaled monitor (G5) to 130%, things look sharp.
However, everything is huge on the huge monitor. Not ideal.
- As a side note, Netbeans exhibits the same behavior. It's sharp with tiny
fonts on the scaled monitor and looks terrible on the unscaled.

Running the app on a single screen (built-in) with "Scaled by system" off,
the fonts are sharp, but they are also very small.
Running the app on a single screen (built-in) with "Scaled by system" on,
the font size is larger (perfect in my opinion) but it's not as sharp.

The pop-up is probably not an issue. It seems like it always appears in
about the middle of the screen. I don't use a lot of pop-ups, but a quick
search said that is the default behavior. At some point my app was probably
off center when I noticed the behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From nlisker at gmail.com  Sun Nov 23 03:10:45 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 23 Nov 2025 05:10:45 +0200
Subject: Faster listener removal
In-Reply-To: <447f27e0-372a-4538-9371-c2f775ba04e2@gmail.com>
References: <447f27e0-372a-4538-9371-c2f775ba04e2@gmail.com>
Message-ID: 

When optimizing for these special cases it's important to know the usage.
In most cases, a property will have a small number of listeners. Do we have
a behavior profile for properties with thousands of listeners? Do they add
them slowly and remove them all at once, or add them all at once and remove
them all at once? Is the cleanup of the list frequent or done rarely?

With a small overhead for the common case of only a few listeners, we need
to be careful with proliferation. What if instead of having a few
properties with O(10,000) listeners, I have O(10,000) properties with a few
listeners on each? Will that overhead accumulate?

On Sat, Nov 22, 2025 at 10:36?PM John Hendrikx 
wrote:

> A long time ago there was some discussion on large listener lists, and
> how they perform very poorly when cleaning up (removing existing
> listeners).
>
> A listener list basically needs to support the following operations:
>
> - append at end, allowing duplicates
> - remove by value, removing the first (oldest) match only
> - iteration
>
> It has no other needs.
>
> There was some discussion if this could be replaced with a
> LinkedHashMap, but it handles duplicates subtly different and is not
> very fast at iteration (lots of random memory accesses).
>
> So I created what is best described as an "ordered" bag.  It allows
> adding and removal, while maintaining order and because it is backed by
> (amongst others) an ordered array, iteration is about as fast as what
> ArrayList does.  It has O(1) insertion, O(1) removal, O(n) iteration,
> but about 3x the memory requirements (not including the listener cost
> itself), unless the list is small (for small lists the overhead is only
> slightly higher than ArrayList).
>
> Insertion is about 5x slower than ArrayList; Removal is far faster (150x
> faster for a 10000 listener case); Iteration is almost equally fast.
>
> Because it has the exact same semantics as an (Array)List with regards
> to duplicates and their removal order, it is a drop-in replacement.
>
> Internally it works by maintaining an ordered array (basically what
> ArrayList has) which is allowed to have removal gaps that are skipped
> during iteration.  When the array needs to grow, it first sees if it can
> consolidate the gaps before increasing the size (and it also shrinks on
> demand, unlike ArrayList).  Other than that, for lists above a certain
> size, it maintains three additional arrays; these are used to maintain
> hashed linked lists of similar elements (basically a singly linked list
> per bucket, but with fast appends at the end using a tail pointer).
>
> When the number of listeners is low, the implementation falls back on
> the simple array only (and the other 3 lists are nulled), which means
> that for small lists the overhead is minimal.  It's sort of a best of
> both worlds thing (although there is always overhead), where it uses
> minimal memory for small lists and simply scans the entire list for
> removals, while for large lists it initializes additional structures to
> allow for quick removals at any size.
>
> Thoughts?
>
> --John
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mariushanl at web.de  Sun Nov 23 09:23:58 2025
From: mariushanl at web.de (Marius Hanl)
Date: Sun, 23 Nov 2025 09:23:58 +0000
Subject: Faster listener removal
In-Reply-To: <447f27e0-372a-4538-9371-c2f775ba04e2@gmail.com>
References: <447f27e0-372a-4538-9371-c2f775ba04e2@gmail.com>
Message-ID: 

An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Sun Nov 23 12:28:03 2025
From: duke at openjdk.org (notzed)
Date: Sun, 23 Nov 2025 12:28:03 GMT
Subject: RFR: JDK-8210547 synchronise with OpenGL after the last window is
 presented
Message-ID: 

As discussed on the mailing list.

OpenGL requires an explicit glFinish() to synchronise with the video refresh.  The current usage is incorrect and against the specification.  This patch calls glFinish() after all windows have been drawn following a pulse.

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

Commit messages:
 - JDK-8210547 synchronise with OpenGL after the last window is presented

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

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

From credmond at certak.com  Sun Nov 23 15:14:33 2025
From: credmond at certak.com (Cormac Redmond)
Date: Sun, 23 Nov 2025 15:14:33 +0000
Subject: JFX 26-ea+15 TableView "bug" -- related to 8359599?
Message-ID: 

Hi,

Since 26-ea+15, there may be a "bug" with TableView which appears to be
rendering duplicated nodes.

I first noticed this when using ControlFX's TableRowExpanderColumn (
https://controlsfx.github.io/javadoc/11.2.2/org.controlsfx.controls/org/controlsfx/control/table/TableRowExpanderColumn.html),
which has been working as expected for several years, right up until
26-ea+15. This column just provides a simple way to allow expansion of
table rows.

I have created a gist consisting of a single runnable class. It's quite
small, and no dependencies are required (minimal ControlsFX code copied
into it):

https://gist.github.com/credmond/57ed65a20c1b4d1cf0272a71642077b0


Run this on 26-ea+15, and you'll see the issue re: duplicated rendering;
run it on anything older, and there's no issue. If I had to guess, I'd say
this issue is related to this commit (8359599):

https://github.com/openjdk/jfx/commit/02756a810c54c4068505eca6d43c1ba2a136e04e



The application starts out like this on all versions, there's three rows
(number of rows is irrelevant):
[image: image.png]

Click the +'s and -'s more than once.

26-ea+15 "bug"; notice the duplications that appear just by clicking the +
/ -'s a couple of times:
[image: image.png]

26-ea+14 (and previous) expected / normal behaviour:
[image: image.png]



Kind Regards,
*Cormac Redmond*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 26865 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31020 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14498 bytes
Desc: not available
URL: 

From martinfox656 at gmail.com  Mon Nov 24 00:30:51 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Sun, 23 Nov 2025 16:30:51 -0800
Subject: JavaFX application on KDE Wayland - tiny
In-Reply-To: 
References: 
 <0288ed4e-c313-4d68-b745-3427ca8e4bb7@xpipe.io>
 <1d585681-2194-4783-a019-d31ca0db0743@oracle.com>
 <3da7d47f-04b2-419e-bf30-e80750460373@xpipe.io>
 
 
 
Message-ID: 

Thanks for the detailed information. It?s very helpful.

KDE + multiple monitors + fractional scale + JavaFX. A perfect storm. In an effort to get certain legacy applications to scale KDE is setting the old ?scaling-factor? to the floor of the actual scale. JavaFX is reading that faulty value which is preventing it from computing the correct UI scale on a per-monitor basis. Things go downhill from there. (For the record that?s what KDE in Ubuntu 24 is doing. In Ubuntu 22 it?s setting GDK_SCALE instead.)

The GDK_SCALE and ?scaling-factor? settings are obsolete within their respective toolkits and for some time they were never set. KDE resurrected them and now they?re interfering with fractional scaling and multiple monitor support in JavaFX. I?m putting together a PR to de-emphasize them.

(Along those lines we should probably deprecate ?glass.gtk.uiScale? since it doesn?t work well with multiple monitors. A better approach would be to allow the user to specify a multiplier to be applied to the per-monitor scales that JavaFX computes internally.)

> On Nov 22, 2025, at 12:57?PM, Chad Preisler  wrote:
> 
> I'm running on a brand new Infinity Book Pro from Tuxedo Computers. Here is the system info.
> 
> DISTRIB_ID=Ubuntu 
> DISTRIB_RELEASE=24.04 
> DISTRIB_CODENAME=noble 
> DISTRIB_DESCRIPTION="TUXEDO OS 24.04.3 LTS" 
> NAME="TUXEDO OS" 
> VERSION="24.04.3 LTS" 
> ID=tuxedo 
> ID_LIKE="ubuntu debian" 
> PRETTY_NAME="TUXEDO OS" 
> VERSION_ID="24.04"
> 
> KDE Plasma Version: 6.4.5
> KDE Frameworks Version: 6.17.0
> Qt Version: 6.8.2
> Kernel: 6.14.0-116036-tuxedo (64-bit)
> Graphics: Wayland
> 
> I did some more testing and found that the scaling issues happen in a dual monitor environment where the scaling factor is different between the two monitors. Here is my setup.
> 
> Built-in Screen: 2653x1600, 130%
> Samsung Odyssey G5 2560x1440, 0%
> 
> When running with two monitors with "Scaled by system" off: 
> - Things look sharp on the monitor with scaling (Built-in). However, fonts get pretty blurry on the unscaled monitor (G5).
> - If I scale up the unscaled monitor (G5) to 130%, things look sharp. However, everything is huge on the huge monitor. Not ideal.
> - As a side note, Netbeans exhibits the same behavior. It's sharp with tiny fonts on the scaled monitor and looks terrible on the unscaled.
> 
> Running the app on a single screen (built-in) with "Scaled by system" off, the fonts are sharp, but they are also very small. 
> Running the app on a single screen (built-in) with "Scaled by system" on, the font size is larger (perfect in my opinion) but it's not as sharp.
> 
> The pop-up is probably not an issue. It seems like it always appears in about the middle of the screen. I don't use a lot of pop-ups, but a quick search said that is the default behavior. At some point my app was probably off center when I noticed the behavior.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From john.hendrikx at gmail.com  Mon Nov 24 03:22:03 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 24 Nov 2025 04:22:03 +0100
Subject: Faster listener removal
In-Reply-To: 
References: <447f27e0-372a-4538-9371-c2f775ba04e2@gmail.com>
 
Message-ID: 

The problem is only present when there is an enormous amount of
listeners on a single property, and the list needs maintenance (ie.
removing listeners).? This can happen when users/nodes listen to a
specific Scene or Window property (as there can be many nodes, they
would all accumulate on the single Scene or Window).? In most cases, it
is best to avoid this somehow, but it is not always avoidable.

For properties on those kinds of objects, having a way to deal with
higher than usual amounts of listeners could be useful.

I've however also been thinking of other alternatives for cases where
perhaps many Nodes are interested in a certain Scene or Window
properties.? For most cases, FX already provides something natively (but
it can't be used for your own cases).? A good example is the Scene
property itself; it is mass updated on all nodes when the root is
attached to a different scene.? There is no mass listener accumulation
on the root's Scene property, as each Node can listen to its own copy.?
Something similar applies to the "visible" properties (toggling it at a
high level, also toggles it for every child node, but there is no?
listener registered where each Node listens to its parent's visibility).

Also CSS does mass distribution of information.? A style on root can
affect properties on every Node in the scene, without each of these
Nodes having to actively listen to something in one place.

What I'm currently interested in is a mechanism to figure out whether a
Node is currently part of a Scene, attached to a Window and that window
is showing. Having every interested node register listeners for this
would accumulate listeners on scene's window property and on window's
showing property.? This will not scale well when the scene changes and a
bunch of nodes is replaced with new nodes (the removed nodes will want
to remove their listeners, and when the list is long, this is terribly
slow).

However, I've thought of new solution to my problem; I could mass
distribute this information by walking the scene graph, and checking for
the presence of a property in the Properties list that each Node has.?
An interested Node can put a property in this map, and when the relevant
showing state of the Scene/Window changes, I could inform all interested
nodes by walking the scene graph.? This is likely to be as fast
as?walking a listener list, but doesn't require maintaining a listener
list at all (just a local property on interested Nodes).?

So I may have found an acceptable work-around, and perhaps the
work-around is even better for this case...

Still, a listener list implementation that is actually optimized
specifically for its use case, can still be a useful addition.

--John

On 23/11/2025 10:23, Marius Hanl wrote:
> This idea sounds interesting.?
> Unfortunately, I never looked into the numbers, e.g. I have no idea
> how many listeners plain Nodes, Controls or Charts (with many Data
> points) have.
> That would be interesting to better understand the current situation,
> and how we want to optimize the listener data structure.
> ?
> -- Marius
> *Gesendet: *Samstag, 22. November 2025 um 21:35
> *Von: *"John Hendrikx" 
> *An: *OpenJFX 
> *Betreff: *Faster listener removal
> A long time ago there was some discussion on large listener lists, and
> how they perform very poorly when cleaning up (removing existing
> listeners).
>
> A listener list basically needs to support the following operations:
>
> - append at end, allowing duplicates
> - remove by value, removing the first (oldest) match only
> - iteration
>
> It has no other needs.
>
> There was some discussion if this could be replaced with a
> LinkedHashMap, but it handles duplicates subtly different and is not
> very fast at iteration (lots of random memory accesses).
>
> So I created what is best described as an "ordered" bag.? It allows
> adding and removal, while maintaining order and because it is backed by
> (amongst others) an ordered array, iteration is about as fast as what
> ArrayList does.? It has?O(1) insertion, O(1) removal, O(n) iteration,
> but about 3x the memory requirements (not including the listener cost
> itself), unless the list is small (for small lists the overhead is only
> slightly higher than ArrayList).
>
> Insertion is about 5x slower than ArrayList; Removal is far faster (150x
> faster for a 10000 listener case); Iteration is?almost equally fast.
>
> Because it has the exact same semantics as an (Array)List with regards
> to duplicates and their removal order, it is a drop-in replacement.
>
> Internally it works by maintaining an ordered array (basically what
> ArrayList has) which is allowed to have removal gaps that are skipped
> during iteration.? When the array needs to grow, it first sees if it can
> consolidate the gaps before increasing the size (and it also shrinks on
> demand, unlike ArrayList).? Other than that, for lists above a certain
> size, it maintains three additional arrays; these are used to maintain
> hashed linked lists of similar elements (basically a singly linked list
> per bucket, but with fast appends at the end using a tail pointer).
>
> When the number of listeners is low, the implementation falls back on
> the simple array only (and the other 3 lists are nulled), which means
> that for small lists the overhead is minimal.? It's sort of a best of
> both worlds thing (although there is always overhead), where it uses
> minimal memory for small lists and simply scans the entire list for
> removals, while for large lists it initializes additional structures to
> allow for quick removals at any size.
>
> Thoughts?
>
> --John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jdv at openjdk.org  Mon Nov 24 04:34:01 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 24 Nov 2025 04:34:01 GMT
Subject: RFR: 8335748: Rippling of frame on scrolling
In-Reply-To: 
References: 
Message-ID: <-WIjdgfoM8Nw478Wnq0Sl4JlYR4yJAZJGIPZBnMX-bw=.85fd5c33-4f23-4037-9fb6-1bed550ef264@github.com>

On Thu, 20 Nov 2025 11:37:53 GMT, Ambarish Rapte  wrote:

> **Issue:** 
> With metal pipeline, frame tearing is observed when scrolling the content. Perform small fling gesture scrolls for observing the issue, the issue occurs/observed easily when scroll is coming to and end.
> 
> **Cause:**
> vsync is not enabled for metal pipeline.
> 
> **Fix:** 
> 1. Enable vsync for metal pipeline. The vsync shall be enabled by default. It can be disabled with `-Djavafx.animation.fullspeed=true`.
> 2. Synchronize the access to offline render target texture.
> 2.1 The `GlassMTLFrameBufferObject._texture` object is created and destroyed by **QuantumRenderer** thread, and
> 2.2 `GlassMTLFrameBufferObject._texture` is also accessed on **Appkit** thread through function `GlassLayerMTL.blitToScreen()`
> 2.3 NSLock is created to synchronize the acess
> 2.4 Without this synchronization, a crash could occur in scenario when JavaFX app window is moved between screens that differ in refresh rate.
> 
> **Verification:**
> 1. Test that no frame tearing is observed, when scrolling(easy to test with small fling scrolls)
> 2. Test no issue observed when moving window among screens.
> 3. General sanity testing of UI.
> 
> **Test:**
> A unit or system test is not possible for this scenario.

Is vysnc enabled by default in ES2 also? I see `vSyncRequested` flag getting passed when `MacGLContext` is initialized but i don't see how it is used.

Is there any performance implications because of texture lock/unlock for each blit screen call?

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

PR Comment: https://git.openjdk.org/jfx/pull/1978#issuecomment-3568893090

From mariushanl at web.de  Mon Nov 24 05:49:28 2025
From: mariushanl at web.de (Marius Hanl)
Date: Mon, 24 Nov 2025 05:49:28 +0000
Subject: JFX 26-ea+15 TableView "bug" -- related to 8359599?
In-Reply-To: 
References: 
Message-ID: 

An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 26865 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31020 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14498 bytes
Desc: not available
URL: 

From arapte at openjdk.org  Mon Nov 24 07:56:50 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 24 Nov 2025 07:56:50 GMT
Subject: RFR: 8335748: Rippling of frame on scrolling
In-Reply-To: <-WIjdgfoM8Nw478Wnq0Sl4JlYR4yJAZJGIPZBnMX-bw=.85fd5c33-4f23-4037-9fb6-1bed550ef264@github.com>
References: 
 <-WIjdgfoM8Nw478Wnq0Sl4JlYR4yJAZJGIPZBnMX-bw=.85fd5c33-4f23-4037-9fb6-1bed550ef264@github.com>
Message-ID: 

On Mon, 24 Nov 2025 04:31:04 GMT, Jayathirth D V  wrote:

> Is vysnc enabled by default in ES2 also?

Yes, vsync is enabled by default, for all pipelines. so, by default FPS gets limited to 60. vsync can be disabled by `-Djavafx.animation.fullspeed=true` or `-Dprism.vsync=false`

>Is there any performance implications because of texture lock/unlock for each blit screen call?

With renderperf, there is a variation of +/-5%. This seems to be general variation not due to `NSLock`. 
`NSLock.tryLock()` is a non-blocking inexpensive call.
In normal scenarios i.e. when rtt is NOT resized(without switching screens/ no resizing the window), only `NSLock.tryLock()` gets invoked while displaying rtt content to screen. In this case the lock would be always available.

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

PR Comment: https://git.openjdk.org/jfx/pull/1978#issuecomment-3569375109

From arapte at openjdk.org  Mon Nov 24 08:27:25 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 24 Nov 2025 08:27:25 GMT
Subject: RFR: 8371981: Wrong split caret positioning with mixed text
In-Reply-To: 
References: 
Message-ID: <7dNEdL77eAFxh_lLxKMPVhKs8mVkqrFexGKxbl64nvw=.fde4a13a-07b8-4cd1-a918-83e5e5a0ec86@github.com>

On Tue, 18 Nov 2025 20:04:42 GMT, Andy Goryachev  wrote:

> Fixing a silly mistake - mixed up `lineX2` and `lineY` parameters in `PrismTextLayout`.

lgtm... verified the fix with manually and with system tests.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1976#pullrequestreview-3498880688

From lkostyra at openjdk.org  Mon Nov 24 11:45:48 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 24 Nov 2025 11:45:48 GMT
Subject: RFR: 8210547: [Linux] Uncontrolled framerate [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 14 Nov 2025 23:00:28 GMT, notzed  wrote:

> I do have a couple of patches which fix the problem but I wanted to do some latency testing to confirm it's further utility - but should I just submit a pull request anyway?

@notzed so if I understand this right, this will be a patch that effectively replaces this one?

If whatever your changes do will replace this PR we should probably close this PR and let you submit your own PR. But depending on how complex it is we might have to spend quite a bit of time testing it.

I think for a start, once your changes are ready and your testing is complete, you could create a draft PR and link it here so we can take a closer look at it and decide what to do with it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1929#issuecomment-3570391983

From lkostyra at openjdk.org  Mon Nov 24 11:57:58 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 24 Nov 2025 11:57:58 GMT
Subject: RFR: 8335748: Rippling of frame on scrolling
In-Reply-To: 
References: 
Message-ID: <3gYeWe94Sibwn0AVP3Q7DSCKsH0he3OC5gT5d3TL9iI=.d4b00abc-692b-48ac-ae6b-935ad9a649eb@github.com>

On Thu, 20 Nov 2025 11:37:53 GMT, Ambarish Rapte  wrote:

> **Issue:** 
> With metal pipeline, frame tearing is observed when scrolling the content. Perform small fling gesture scrolls for observing the issue, the issue occurs/observed easily when scroll is coming to and end.
> 
> **Cause:**
> vsync is not enabled for metal pipeline.
> 
> **Fix:** 
> 1. Enable vsync for metal pipeline. The vsync shall be enabled by default. It can be disabled with `-Djavafx.animation.fullspeed=true`.
> 2. Synchronize the access to offline render target texture.
> 2.1 The `GlassMTLFrameBufferObject._texture` object is created and destroyed by **QuantumRenderer** thread, and
> 2.2 `GlassMTLFrameBufferObject._texture` is also accessed on **Appkit** thread through function `GlassLayerMTL.blitToScreen()`
> 2.3 NSLock is created to synchronize the acess
> 2.4 Without this synchronization, a crash could occur in scenario when JavaFX app window is moved between screens that differ in refresh rate.
> 
> **Verification:**
> 1. Test that no frame tearing is observed, when scrolling(easy to test with small fling scrolls)
> 2. Test no issue observed when moving window among screens.
> 3. General sanity testing of UI.
> 
> **Test:**
> A unit or system test is not possible for this scenario.

modules/javafx.graphics/src/main/native-glass/mac/GlassLayerMTL.m line 155:

> 153:     // {
> 154:     //     The texture is locked, either being created/destroyed or being encoded into BlitEncoder
> 155:     //     hence the frame could be dropped.

Just a curiosity question, but would we have a possibility to wait for the texture to become available to us instead of dropping the frame?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1978#discussion_r2556015087

From lkostyra at openjdk.org  Mon Nov 24 12:00:16 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 24 Nov 2025 12:00:16 GMT
Subject: Integrated: 8368629: Texture.update sometimes invoked for a disposed
 Texture
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 15:54:13 GMT, Lukasz Kostyra  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.

This pull request has now been integrated.

Changeset: 8bf8ae6c
Author:    Lukasz Kostyra 
URL:       https://git.openjdk.org/jfx/commit/8bf8ae6c1782e13b1e17fe89062356b96c9b71ad
Stats:     31 lines in 7 files changed: 31 ins; 0 del; 0 mod

8368629: Texture.update sometimes invoked for a disposed Texture

Reviewed-by: angorya, kcr, arapte, jhendrikx

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

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

From kcr at openjdk.org  Mon Nov 24 13:31:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 24 Nov 2025 13:31:18 GMT
Subject: RFR: JDK-8210547 synchronise with OpenGL after the last window is
 presented
In-Reply-To: 
References: 
Message-ID: 

On Sun, 23 Nov 2025 12:21:04 GMT, notzed  wrote:

> As discussed on the mailing list.
> 
> OpenGL requires an explicit glFinish() to synchronise with the video refresh.  The current usage is incorrect and against the specification.  This patch calls glFinish() after all windows have been drawn following a pulse.

This will need careful review.

Reviewers: At least two of: @lukostyra @arapte @kevinrushforth

@notzed Please enable GHA testing for your repo. Go you your "Actions" tab in your repo and enable them with the green "enable workflows" button. Then push an empty commit to trigger a test run.

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

PR Comment: https://git.openjdk.org/jfx/pull/1981#issuecomment-3570787056
PR Comment: https://git.openjdk.org/jfx/pull/1981#issuecomment-3570790860

From kcr at openjdk.org  Mon Nov 24 13:35:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 24 Nov 2025 13:35:20 GMT
Subject: RFR: JDK-8210547 synchronise with OpenGL after the last window is
 presented
In-Reply-To: 
References: 
Message-ID: 

On Sun, 23 Nov 2025 12:21:04 GMT, notzed  wrote:

> As discussed on the mailing list.
> 
> OpenGL requires an explicit glFinish() to synchronise with the video refresh.  The current usage is incorrect and against the specification.  This patch calls glFinish() after all windows have been drawn following a pulse.

@notzed As with the fix @arapte did for PR #1978, you will need to qualify this with `PrismSettings.isVsyncEnabled`.

My quick take on your PR is that the changes are pretty intrusive and not limited to the ES2 pipeline. I recommend exploring whether the changes can be more targeted.

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

PR Comment: https://git.openjdk.org/jfx/pull/1981#issuecomment-3570812277

From mstrauss at openjdk.org  Mon Nov 24 14:36:05 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 24 Nov 2025 14:36:05 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds
Message-ID: 

On Windows, the `Stage.width` and `Stage.height` correspond to the window size as returned by `GetWindowRect`.

Up until Windows 10, the size of a window was identical to its visual borders. However, since Windows 10 has introduced thin visual window borders, the window manager adds an invisible border of a few pixels around the window to make it easier to resize the window. Since `GetWindowRect` returns the window size _including_ these invisible borders, the location and size of a `Stage` isn't exactly what we'd expected.

For example, if we place a `Stage` at `setX(0)` and `setY(0)`, the window appears with a small distance from the screen edge, and the window size extends a few pixels beyond its visual borders:
window-size-1

What we actually want is to have the visual borders line up with the edges of the screen, and have the window size correspond to the visual borders:
window-size-2

The implementation is quite simple: instead of `GetWindowRect`, we use `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)`. This gives us the bounds of the visual window borders. If this function fails, we fall back to `GetWindowRect` (now, I don't know why `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)` would ever fail... maybe an old Windows version in a remote desktop scenario?).

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

Commit messages:
 - Stage size should match extended frame bounds

Changes: https://git.openjdk.org/jfx/pull/1982/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1982&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372415
  Stats: 88 lines in 2 files changed: 45 ins; 14 del; 29 mod
  Patch: https://git.openjdk.org/jfx/pull/1982.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1982/head:pull/1982

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

From zelmidaoui at openjdk.org  Mon Nov 24 15:12:26 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 24 Nov 2025 15:12:26 GMT
Subject: RFR: 8371981: Wrong split caret positioning with mixed text
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 Nov 2025 20:04:42 GMT, Andy Goryachev  wrote:

> Fixing a silly mistake - mixed up `lineX2` and `lineY` parameters in `PrismTextLayout`.

LGTM, the tests are good , manually testing works also

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

Marked as reviewed by zelmidaoui (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1976#pullrequestreview-3500892655

From jdv at openjdk.org  Mon Nov 24 15:23:54 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 24 Nov 2025 15:23:54 GMT
Subject: RFR: 8335748: Rippling of frame on scrolling
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 Nov 2025 11:37:53 GMT, Ambarish Rapte  wrote:

> **Issue:** 
> With metal pipeline, frame tearing is observed when scrolling the content. Perform small fling gesture scrolls for observing the issue, the issue occurs/observed easily when scroll is coming to and end.
> 
> **Cause:**
> vsync is not enabled for metal pipeline.
> 
> **Fix:** 
> 1. Enable vsync for metal pipeline. The vsync shall be enabled by default. It can be disabled with `-Djavafx.animation.fullspeed=true`.
> 2. Synchronize the access to offline render target texture.
> 2.1 The `GlassMTLFrameBufferObject._texture` object is created and destroyed by **QuantumRenderer** thread, and
> 2.2 `GlassMTLFrameBufferObject._texture` is also accessed on **Appkit** thread through function `GlassLayerMTL.blitToScreen()`
> 2.3 NSLock is created to synchronize the acess
> 2.4 Without this synchronization, a crash could occur in scenario when JavaFX app window is moved between screens that differ in refresh rate.
> 
> **Verification:**
> 1. Test that no frame tearing is observed, when scrolling(easy to test with small fling scrolls)
> 2. Test no issue observed when moving window among screens.
> 3. General sanity testing of UI.
> 
> **Test:**
> A unit or system test is not possible for this scenario.

I don't see rippling in Ensemble8 when scrolled with this PR.
Also no issues with moving window between multiple screens.
Code change and Sanity testing looks fine.

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

Marked as reviewed by jdv (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1978#pullrequestreview-3500946133

From angorya at openjdk.org  Mon Nov 24 15:31:31 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Nov 2025 15:31:31 GMT
Subject: RFR: 8371981: Wrong split caret positioning with mixed text
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 Nov 2025 20:04:42 GMT, Andy Goryachev  wrote:

> Fixing a silly mistake - mixed up `lineX2` and `lineY` parameters in `PrismTextLayout`.

thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jfx/pull/1976#issuecomment-3571394448

From angorya at openjdk.org  Mon Nov 24 15:35:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Nov 2025 15:35:10 GMT
Subject: Integrated: 8371981: Wrong split caret positioning with mixed text
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 Nov 2025 20:04:42 GMT, Andy Goryachev  wrote:

> Fixing a silly mistake - mixed up `lineX2` and `lineY` parameters in `PrismTextLayout`.

This pull request has now been integrated.

Changeset: 71faf680
Author:    Andy Goryachev 
URL:       https://git.openjdk.org/jfx/commit/71faf680efc7517c074bcc83dd19cce0dd1d1a95
Stats:     157 lines in 4 files changed: 152 ins; 5 del; 0 mod

8371981: Wrong split caret positioning with mixed text

Reviewed-by: arapte, zelmidaoui

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

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

From daniel.peintner at gmail.com  Mon Nov 24 15:50:06 2025
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Mon, 24 Nov 2025 16:50:06 +0100
Subject: JFX 26-ea+15 TableView "bug" -- related to 8359599?
In-Reply-To: 
References: 
 
Message-ID: 

Hi,

Thank you both for reporting the problem and providing a solution.
I opened https://github.com/controlsfx/controlsfx/issues/1606 to keep track
of the problem.

Marius, I think it would be good if you can provide a fix/PR.

Note: I am not one of the maintainers of ControlsFX but a user and I think
it is good if we can resolve the problem.

Thanks,

-- Daniel


On Mon, Nov 24, 2025 at 6:50?AM Marius Hanl  wrote:

> The refresh changes could only be a problem if something in the Code is
> misbehaving.
> I had a look, and indeed, the *expandedNode* is NEVER removed. The logic
> simply does not work, never did in the previous versions.
> Prior to 26-ea+15, the table refresh was recreating ALL cells. This masked
> the bug.
> But now, the refresh method really refreshes the existing cells. So rows
> and cells need to react to that, as they should before.
>
> The root cause is, that the *expandedNode* is removed from the HashMap
> before it could be cleaned up in the corresponding TableRowSkin.
> So when the TableRowSkin tries to remove the *expandedNode*, it is
> already null.
> Removing the code fixes the issue:
>
>             public BooleanProperty getExpandedProperty(S item) {
>                 BooleanProperty value = expansionState.get(item);
>                 if (value == null) {
>                     value = new SimpleBooleanProperty(item, "expanded",
> false) {
>                         @Override
>                         protected void invalidated() {
> //                            if (!getValue()) {
> //                                expandedNodeCache.remove(getBean());
> //                            }
>                             getTableView().refresh();
>                         }
>                     };
>                     expansionState.put(item, value);
>                 }
>                 return value;
>             }
>
> Again, this was also problematic before, but masked by the recreation.
>
> To restore the old behavior, you could write:
>
>             TableView table = new TableView<>() {
>                 @Override
>                 public void refresh() {
>                     getProperties().put("recreateKey", Boolean.TRUE);
>                 }
>             };
>
> I don't know if ControlsFX is still somewhat maintained. Otherwise I can
> have file a PR there.
>
> -- Marius
>
> *Gesendet: *Sonntag, 23. November 2025 um 16:14
> *Von: *"Cormac Redmond" 
> *An: *openjfx-dev at openjdk.org
> *Betreff: *JFX 26-ea+15 TableView "bug" -- related to 8359599?
> Hi,
>
> Since 26-ea+15, there may be a "bug" with TableView which appears to be
> rendering duplicated nodes.
>
> I first noticed this when using ControlFX's TableRowExpanderColumn (
> https://controlsfx.github.io/javadoc/11.2.2/org.controlsfx.controls/org/controlsfx/control/table/TableRowExpanderColumn.html),
> which has been working as expected for several years, right up until
> 26-ea+15. This column just provides a simple way to allow expansion of
> table rows.
>
> I have created a gist consisting of a single runnable class. It's quite
> small, and no dependencies are required (minimal ControlsFX code copied
> into it):
>
>
> https://gist.github.com/credmond/57ed65a20c1b4d1cf0272a71642077b0
>
>
> Run this on 26-ea+15, and you'll see the issue re: duplicated rendering;
> run it on anything older, and there's no issue. If I had to guess, I'd say
> this issue is related to this commit (8359599):
>
>
>
> https://github.com/openjdk/jfx/commit/02756a810c54c4068505eca6d43c1ba2a136e04e
>
>
>
> The application starts out like this on all versions, there's three rows
> (number of rows is irrelevant):
> [image: image.png]
>
> Click the +'s and -'s more than once.
>
> 26-ea+15 "bug"; notice the duplications that appear just by clicking the +
> / -'s a couple of times:
> [image: image.png]
>
> 26-ea+14 (and previous) expected / normal behaviour:
> [image: image.png]
>
>
>
>
> Kind Regards,
> *Cormac Redmond*
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 26865 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31020 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14498 bytes
Desc: not available
URL: 

From martinfox656 at gmail.com  Mon Nov 24 16:06:06 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Mon, 24 Nov 2025 08:06:06 -0800
Subject: JavaFX application on KDE Wayland - tiny
In-Reply-To: 
References: 
 <0288ed4e-c313-4d68-b745-3427ca8e4bb7@xpipe.io>
 <1d585681-2194-4783-a019-d31ca0db0743@oracle.com>
 <3da7d47f-04b2-419e-bf30-e80750460373@xpipe.io>
 
 
 
 
Message-ID: 

I?ve also verified that newly created JavaFX windows are not being centered correctly under KDE (tested on Ubuntu 22 and 24). Looks like this is already fixed in PR 1789.

> On Nov 23, 2025, at 4:30?PM, Martin Fox  wrote:
> 
> Thanks for the detailed information. It?s very helpful.
> 
> KDE + multiple monitors + fractional scale + JavaFX. A perfect storm. In an effort to get certain legacy applications to scale KDE is setting the old ?scaling-factor? to the floor of the actual scale. JavaFX is reading that faulty value which is preventing it from computing the correct UI scale on a per-monitor basis. Things go downhill from there. (For the record that?s what KDE in Ubuntu 24 is doing. In Ubuntu 22 it?s setting GDK_SCALE instead.)
> 
> The GDK_SCALE and ?scaling-factor? settings are obsolete within their respective toolkits and for some time they were never set. KDE resurrected them and now they?re interfering with fractional scaling and multiple monitor support in JavaFX. I?m putting together a PR to de-emphasize them.
> 
> (Along those lines we should probably deprecate ?glass.gtk.uiScale? since it doesn?t work well with multiple monitors. A better approach would be to allow the user to specify a multiplier to be applied to the per-monitor scales that JavaFX computes internally.)
> 
>> On Nov 22, 2025, at 12:57?PM, Chad Preisler  wrote:
>> 
>> I'm running on a brand new Infinity Book Pro from Tuxedo Computers. Here is the system info.
>> 
>> DISTRIB_ID=Ubuntu 
>> DISTRIB_RELEASE=24.04 
>> DISTRIB_CODENAME=noble 
>> DISTRIB_DESCRIPTION="TUXEDO OS 24.04.3 LTS" 
>> NAME="TUXEDO OS" 
>> VERSION="24.04.3 LTS" 
>> ID=tuxedo 
>> ID_LIKE="ubuntu debian" 
>> PRETTY_NAME="TUXEDO OS" 
>> VERSION_ID="24.04"
>> 
>> KDE Plasma Version: 6.4.5
>> KDE Frameworks Version: 6.17.0
>> Qt Version: 6.8.2
>> Kernel: 6.14.0-116036-tuxedo (64-bit)
>> Graphics: Wayland
>> 
>> I did some more testing and found that the scaling issues happen in a dual monitor environment where the scaling factor is different between the two monitors. Here is my setup.
>> 
>> Built-in Screen: 2653x1600, 130%
>> Samsung Odyssey G5 2560x1440, 0%
>> 
>> When running with two monitors with "Scaled by system" off: 
>> - Things look sharp on the monitor with scaling (Built-in). However, fonts get pretty blurry on the unscaled monitor (G5).
>> - If I scale up the unscaled monitor (G5) to 130%, things look sharp. However, everything is huge on the huge monitor. Not ideal.
>> - As a side note, Netbeans exhibits the same behavior. It's sharp with tiny fonts on the scaled monitor and looks terrible on the unscaled.
>> 
>> Running the app on a single screen (built-in) with "Scaled by system" off, the fonts are sharp, but they are also very small. 
>> Running the app on a single screen (built-in) with "Scaled by system" on, the font size is larger (perfect in my opinion) but it's not as sharp.
>> 
>> The pop-up is probably not an issue. It seems like it always appears in about the middle of the screen. I don't use a lot of pop-ups, but a quick search said that is the default behavior. At some point my app was probably off center when I noticed the behavior.
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Mon Nov 24 16:09:37 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Nov 2025 16:09:37 GMT
Subject: RFR: 8372203: Piecewise linear easing function [v2]
In-Reply-To: 
References: 
 <0jypoZLukwB3rjNASv-WAOq2wue_HbtLoC1C0Ncaziw=.1575c162-d9bb-41f1-b23c-06c69eae9a16@github.com>
 
Message-ID: 

On Sat, 22 Nov 2025 10:11:11 GMT, Michael Strau?  wrote:

>> modules/javafx.graphics/src/test/java/test/com/sun/scenario/animation/LinearInterpolatorTest.java line 41:
>> 
>>> 39:         try {
>>> 40:             Field f = LinearInterpolator.class.getDeclaredField("controlPoints");
>>> 41:             f.setAccessible(true);
>> 
>> should an Accessor be used instead?
>
> I'm not a big fan of that because of its impact on the source code of the class (you know those comments: "package-private only for the sake of testing").

I would recommend to use the Accessor pattern then.

Reflection is brittle, the IDEs won't track the dependency, and I prefer clear and obvious dependencies.  Besides, this is the pattern used throughout the JavaFX code.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1977#discussion_r2556875403

From angorya at openjdk.org  Mon Nov 24 16:20:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Nov 2025 16:20:03 GMT
Subject: RFR: 8372203: Piecewise linear easing function [v2]
In-Reply-To: 
References: 
 <0jypoZLukwB3rjNASv-WAOq2wue_HbtLoC1C0Ncaziw=.1575c162-d9bb-41f1-b23c-06c69eae9a16@github.com>
 
 
Message-ID: 

On Mon, 24 Nov 2025 16:05:36 GMT, Andy Goryachev  wrote:

>> I'm not a big fan of that because of its impact on the source code of the class (you know those comments: "package-private only for the sake of testing").
>
> I would recommend to use the Accessor pattern then.
> 
> Reflection is brittle, the IDEs won't track the dependency, and I prefer clear and obvious dependencies.  Besides, this is the pattern used throughout the JavaFX code.

... I realized it's only for testing.  It's probably ok, for testing.  Maybe add a comment to the field saying that the reflection is used to access this field by tests?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1977#discussion_r2556911914

From angorya at openjdk.org  Mon Nov 24 16:27:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Nov 2025 16:27:10 GMT
Subject: RFR: 8372203: Piecewise linear easing function [v2]
In-Reply-To: <_ncebwfKqeq-6lsIMtzdLb6mtJg3YvDXfzr-GorD9Y0=.71c88969-b491-4eec-880e-4c0620651249@github.com>
References: 
 <_ncebwfKqeq-6lsIMtzdLb6mtJg3YvDXfzr-GorD9Y0=.71c88969-b491-4eec-880e-4c0620651249@github.com>
Message-ID: 

On Sat, 22 Nov 2025 10:06:56 GMT, Michael Strau?  wrote:

>> Implementation of the [linear](https://www.w3.org/TR/css-easing-2/#the-linear-easing-function) easing function, which is now widely supported by all browsers, but still missing in JavaFX.
>> 
>> It allows developers to approximate arbitrary easing functions with linear segments:
>> 
>> 
>> linear(
>>     /* Start to 1st bounce */
>>     0, 0.063, 0.25, 0.563, 1 36.4%,
>>     /* 1st to 2nd bounce */
>>     0.812, 0.75, 0.813, 1 72.7%,
>>     /* 2nd to 3rd bounce */
>>     0.953, 0.938, 0.953, 1 90.9%,
>>     /* 3rd bounce to end */
>>     0.984, 1 100% 100%
>>   )
>> 
>> 
>> 
>
> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - numeric overflow to infinity
>  - refactor tests

Could you provide a complete selector for the example in this PR description please, so I can copy and paste it?

Similarly, do you think it's worth adding the same (complete selector example) to the class javadoc?

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

PR Comment: https://git.openjdk.org/jfx/pull/1977#issuecomment-3571646094

From angorya at openjdk.org  Mon Nov 24 17:13:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Nov 2025 17:13:04 GMT
Subject: RFR: 8372203: Piecewise linear easing function
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 22 Nov 2025 09:03:16 GMT, Michael Strau?  wrote:

> `LINEAR(Point2D...)` we would have `ofLinear(Point2D...)`

+1 for `ofLinear(Point2D ...)`

`Interpolator.LINEAR` is a final object instance, `Interpolator.LINEAR(Point2D...)` is a method.

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

PR Comment: https://git.openjdk.org/jfx/pull/1977#issuecomment-3571847841

From credmond at certak.com  Mon Nov 24 19:37:24 2025
From: credmond at certak.com (Cormac Redmond)
Date: Mon, 24 Nov 2025 19:37:24 +0000
Subject: JFX 26-ea+15 TableView "bug" -- related to 8359599?
In-Reply-To: 
References: 
 
 
Message-ID: 

Hi both,

Thank you Marius for investigating this, and apologies for assuming it was
a JFX bug (I did spend time trying to determine if it was ControlsFX
misbehaving).

Thank you Daniel for following up. I created a PR on ControlsFX:
https://github.com/controlsfx/controlsfx/pull/1607 ...





Kind Regards,
Cormac

On Mon, 24 Nov 2025 at 15:50, Daniel Peintner 
wrote:

> Hi,
>
> Thank you both for reporting the problem and providing a solution.
> I opened https://github.com/controlsfx/controlsfx/issues/1606 to keep
> track of the problem.
>
> Marius, I think it would be good if you can provide a fix/PR.
>
> Note: I am not one of the maintainers of ControlsFX but a user and I think
> it is good if we can resolve the problem.
>
> Thanks,
>
> -- Daniel
>
>
> On Mon, Nov 24, 2025 at 6:50?AM Marius Hanl  wrote:
>
>> The refresh changes could only be a problem if something in the Code is
>> misbehaving.
>> I had a look, and indeed, the *expandedNode* is NEVER removed. The logic
>> simply does not work, never did in the previous versions.
>> Prior to 26-ea+15, the table refresh was recreating ALL cells. This
>> masked the bug.
>> But now, the refresh method really refreshes the existing cells. So rows
>> and cells need to react to that, as they should before.
>>
>> The root cause is, that the *expandedNode* is removed from the HashMap
>> before it could be cleaned up in the corresponding TableRowSkin.
>> So when the TableRowSkin tries to remove the *expandedNode*, it is
>> already null.
>> Removing the code fixes the issue:
>>
>>             public BooleanProperty getExpandedProperty(S item) {
>>                 BooleanProperty value = expansionState.get(item);
>>                 if (value == null) {
>>                     value = new SimpleBooleanProperty(item, "expanded",
>> false) {
>>                         @Override
>>                         protected void invalidated() {
>> //                            if (!getValue()) {
>> //                                expandedNodeCache.remove(getBean());
>> //                            }
>>                             getTableView().refresh();
>>                         }
>>                     };
>>                     expansionState.put(item, value);
>>                 }
>>                 return value;
>>             }
>>
>> Again, this was also problematic before, but masked by the recreation.
>>
>> To restore the old behavior, you could write:
>>
>>             TableView table = new TableView<>() {
>>                 @Override
>>                 public void refresh() {
>>                     getProperties().put("recreateKey", Boolean.TRUE);
>>                 }
>>             };
>>
>> I don't know if ControlsFX is still somewhat maintained. Otherwise I can
>> have file a PR there.
>>
>> -- Marius
>>
>> *Gesendet: *Sonntag, 23. November 2025 um 16:14
>> *Von: *"Cormac Redmond" 
>> *An: *openjfx-dev at openjdk.org
>> *Betreff: *JFX 26-ea+15 TableView "bug" -- related to 8359599?
>> Hi,
>>
>> Since 26-ea+15, there may be a "bug" with TableView which appears to be
>> rendering duplicated nodes.
>>
>> I first noticed this when using ControlFX's TableRowExpanderColumn (
>> https://controlsfx.github.io/javadoc/11.2.2/org.controlsfx.controls/org/controlsfx/control/table/TableRowExpanderColumn.html),
>> which has been working as expected for several years, right up until
>> 26-ea+15. This column just provides a simple way to allow expansion of
>> table rows.
>>
>> I have created a gist consisting of a single runnable class. It's quite
>> small, and no dependencies are required (minimal ControlsFX code copied
>> into it):
>>
>>
>> https://gist.github.com/credmond/57ed65a20c1b4d1cf0272a71642077b0
>>
>>
>> Run this on 26-ea+15, and you'll see the issue re: duplicated rendering;
>> run it on anything older, and there's no issue. If I had to guess, I'd say
>> this issue is related to this commit (8359599):
>>
>>
>>
>> https://github.com/openjdk/jfx/commit/02756a810c54c4068505eca6d43c1ba2a136e04e
>>
>>
>>
>> The application starts out like this on all versions, there's three rows
>> (number of rows is irrelevant):
>> [image: image.png]
>>
>> Click the +'s and -'s more than once.
>>
>> 26-ea+15 "bug"; notice the duplications that appear just by clicking the
>> + / -'s a couple of times:
>> [image: image.png]
>>
>> 26-ea+14 (and previous) expected / normal behaviour:
>> [image: image.png]
>>
>>
>>
>>
>> Kind Regards,
>> *Cormac Redmond*
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 26865 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31020 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14498 bytes
Desc: not available
URL: 

From mstrauss at openjdk.org  Mon Nov 24 19:59:37 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 24 Nov 2025 19:59:37 GMT
Subject: RFR: 8372203: Piecewise linear easing function [v2]
In-Reply-To: 
References: 
 <_ncebwfKqeq-6lsIMtzdLb6mtJg3YvDXfzr-GorD9Y0=.71c88969-b491-4eec-880e-4c0620651249@github.com>
 
Message-ID: 

On Mon, 24 Nov 2025 16:24:58 GMT, Andy Goryachev  wrote:

> Could you provide a complete selector for the example in this PR description please, so I can copy and paste it?

Here it is, for a region with the `rect` style class:


.rect {
  -fx-min-width: 150;
  -fx-min-height: 50;
  -fx-background-color: purple;
  transition-property: -fx-min-width, -fx-background-color;
  transition-duration: 2s;
  transition-timing-function: linear(0, 0.063, 0.25, 0.563, 1 36.4%,
                                     0.812, 0.75, 0.813, 1 72.7%,
                                     0.953, 0.938, 0.953, 1 90.9%,
                                     0.984, 1 100% 100%);
}

.rect:hover {
  -fx-min-width: 400;
  -fx-background-color: green;
}

I've also added this example to tests/manual/graphics/CssTransitionsTest.


> Similarly, do you think it's worth adding the same (complete selector example) to the class javadoc?

No, mainly because the `javafx.animation` package doesn't mention CSS at all, so an example for a CSS selector would be misplaced here. I'm also not sure if a complex example is useful, simple examples are usually easier to understand (and we have three of those).

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

PR Comment: https://git.openjdk.org/jfx/pull/1977#issuecomment-3572473734

From angorya at openjdk.org  Mon Nov 24 19:59:39 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Nov 2025 19:59:39 GMT
Subject: RFR: 8372203: Piecewise linear easing function [v2]
In-Reply-To: 
References: 
 <_ncebwfKqeq-6lsIMtzdLb6mtJg3YvDXfzr-GorD9Y0=.71c88969-b491-4eec-880e-4c0620651249@github.com>
 
 
Message-ID: 

On Mon, 24 Nov 2025 19:53:11 GMT, Michael Strau?  wrote:

> I've also added this example to tests/manual/graphics/CssTransitionsTest.

Thank you very much, this makes the life of the reviewers so much easier!

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

PR Comment: https://git.openjdk.org/jfx/pull/1977#issuecomment-3572483344

From mariushanl at web.de  Mon Nov 24 20:15:10 2025
From: mariushanl at web.de (Marius Hanl)
Date: Mon, 24 Nov 2025 20:15:10 +0000
Subject: JFX 26-ea+15 TableView "bug" -- related to 8359599?
In-Reply-To: 
References: 
 
 
 
Message-ID: 

An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 26865 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31020 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14498 bytes
Desc: not available
URL: 

From angorya at openjdk.org  Mon Nov 24 21:11:37 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Nov 2025 21:11:37 GMT
Subject: RFR: 8372438: SimpleViewOnlyStyledModel: non-text paragraphs
Message-ID: 

Fixing a bug in `SimpleViewOnlyStyledModel.lastParagraph()` which breaks adding text segments after a `Region`-based paragraph.

Test cases:

    @Test
    public void addTextAfterRegion() {
        SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
        m.addParagraph(() -> new Region());
        m.addNodeSegment(() -> new Region());
        assertEquals(2, m.size());
    }

    @Test
    public void addTextAfterRegionAfterText() {
        SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
        m.addNodeSegment(() -> new Region());
        m.addParagraph(() -> new Region());
        m.addSegment("text");
        assertEquals(3, m.size());
    }

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

Commit messages:
 - fix

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

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

From angorya at openjdk.org  Mon Nov 24 21:51:32 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Nov 2025 21:51:32 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow [v3]
In-Reply-To: 
References: 
Message-ID: 

> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`.
> 
> 
> ### NOTES
> 
> - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved)
> - the fix can be verified visually using the latest Monkey Tester
> 
> Screenshot 2025-11-17 at 13 43 12

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 eight additional commits since the last revision:

 - updated test
 - Merge branch 'master' into 8371067.request.layout
 - add text segment
 - Merge branch 'master' into 8371067.request.layout
 - test
 - request layout
 - test
 - fix

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1975/files
  - new: https://git.openjdk.org/jfx/pull/1975/files/b714faff..ecd2c0e7

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

  Stats: 922 lines in 23 files changed: 749 ins; 70 del; 103 mod
  Patch: https://git.openjdk.org/jfx/pull/1975.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1975/head:pull/1975

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

From angorya at openjdk.org  Mon Nov 24 21:51:33 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Nov 2025 21:51:33 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow [v3]
In-Reply-To: <82HYP1uLEGi0kmqTxpcNLzGMcYXvFu1TOTLASSWR6TI=.cf084c42-17ba-4cc5-9ece-11f74f05328d@github.com>
References: 
 
 
 
 <5VyBDD2XQvsuhNu3DRF6XXSwSzTe3BaN_13HdThVwxE=.86a1a532-e60c-4abc-a8f9-953ee2d1546e@github.com>
 
 
 
 
 <15B47nEG5NEyJ3_nw6BLCYOvM8HhUi2QtYzD4WQjpVI=.21e08564-174a-491b-8071-d7f12556a5cf@github.com>
 <82HYP1uLEGi0kmqTxpcNLzGMcYXvFu1TOTL
 ASSWR6TI=.cf084c42-17ba-4cc5-9ece-11f74f05328d@github.com>
Message-ID: <78AAUq6jS0gL-CPRWwuzs3j27I_j2voN7kTYUcPs2Xw=.185ef11c-7661-41a0-bbc1-447b87604419@github.com>

On Sat, 22 Nov 2025 16:42:49 GMT, Marius Hanl  wrote:

>> The documentation on `Node.managed` property states 
>> 
>> Defines whether or not this node's layout will be managed by its parent. 
>> 
>> 
>> The layout of TextCell is not managed by its parent (`VFlow.content`), **by design**.
>> 
>> The `VFlow` is the entity that does the layout, for a reason.  It's a complicated thing, and multiple moving parts are connected (one example: it performs multiple layout cycles in the same layout pass when scrollbars appear/disappear during the layout pass, to avoid jumping and flicker - something we occasionally see with `ScrollPane` and `ListView`, see Note 1).
>> 
>> Notes
>> 
>> 1. I occasionally see the continuous flicker/layout when resizing the list of pages in the latest Monkey Tester, but so far I was unable to capture the exact conditions to create a reproducible test case (this is unrelated to this PR)
>
> Did you read what I wrote above? I made multiple suggestions as how we can deal with the situation, even without making things managed again.
> 
> To reiterate, what is the problem?
> - We now have a dependency from `TextCell` to `VFlow`. Not explicitly, but rather hidden, by searching all parents (which is also costly when doing that often). I would prefer a clear separation of concerns
> - This makes subclassing/extending harder. What happens, if I want to write my own `VFlow`, but still use everything else, including `TextCell`? What if I want to use `TextCell` for a component, that has no `VFlow`? What happens if we find a `VFlow` from another component even? Because we used the `TextCell` somewhere else?
> - Other components made it clear how to use `managed` and `unamanged` nodes. And how to bubble up a request still. Why do we want to make an exception here? This is the first time we need to search the parent hierarchy
> - Why not e.g. binding to the `needsLayoutProperty` from a `TextCell` from within `VFlow` and just request the layout when set?
> 
> Also another point: The test is green for me with the changes from: https://github.com/openjdk/jfx/pull/1945
> So I would like to know, if maybe there was a bug even?

Thank you for looking into this and offering your suggestions!  The thing is, the RTA is a bit more complex than the situation you describe, due to the presence of other requirements (such as side areas that house line numbers and possibly other paragraph decorators).

The design of the skin is such that only `VFlow` does the layout.  The VFlow is the sole actor that deals with its complicated content.  Without a very good reason, this design is unlikely to change.  Furthermore, the `VFlow` is still an implementation detail, so one can't just subclass the skin (this is true for _other controls as well_).  Neither `VFlow` nor TextCell nor `RichUtils` are public API.

Yes, the test is green with #1945 but it fails in master.  And yes, the bug is still there even with #1945 , as can be seen with the monkey tester:

expected:
Screenshot 2025-11-24 at 13 27 15

observed:
Screenshot 2025-11-24 at 13 27 05

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2557810372

From angorya at openjdk.org  Mon Nov 24 21:51:33 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Nov 2025 21:51:33 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow [v3]
In-Reply-To: <78AAUq6jS0gL-CPRWwuzs3j27I_j2voN7kTYUcPs2Xw=.185ef11c-7661-41a0-bbc1-447b87604419@github.com>
References: 
 
 
 
 <5VyBDD2XQvsuhNu3DRF6XXSwSzTe3BaN_13HdThVwxE=.86a1a532-e60c-4abc-a8f9-953ee2d1546e@github.com>
 
 
 
 
 <15B47nEG5NEyJ3_nw6BLCYOvM8HhUi2QtYzD4WQjpVI=.21e08564-174a-491b-8071-d7f12556a5cf@github.com>
 <82HYP1uLEGi0kmqTxpcNLzGMcYXvFu1TOTL
 ASSWR6TI=.cf084c42-17ba-4cc5-9ece-11f74f05328d@github.com>
 <78AAUq6jS0gL-CPRWwuzs3j27I_j2voN7kTYUcPs2Xw=.185ef11c-7661-41a0-bbc1-447b87604419@github.com>
Message-ID: 

On Mon, 24 Nov 2025 21:44:59 GMT, Andy Goryachev  wrote:

>> Did you read what I wrote above? I made multiple suggestions as how we can deal with the situation, even without making things managed again.
>> 
>> To reiterate, what is the problem?
>> - We now have a dependency from `TextCell` to `VFlow`. Not explicitly, but rather hidden, by searching all parents (which is also costly when doing that often). I would prefer a clear separation of concerns
>> - This makes subclassing/extending harder. What happens, if I want to write my own `VFlow`, but still use everything else, including `TextCell`? What if I want to use `TextCell` for a component, that has no `VFlow`? What happens if we find a `VFlow` from another component even? Because we used the `TextCell` somewhere else?
>> - Other components made it clear how to use `managed` and `unamanged` nodes. And how to bubble up a request still. Why do we want to make an exception here? This is the first time we need to search the parent hierarchy
>> - Why not e.g. binding to the `needsLayoutProperty` from a `TextCell` from within `VFlow` and just request the layout when set?
>> 
>> Also another point: The test is green for me with the changes from: https://github.com/openjdk/jfx/pull/1945
>> So I would like to know, if maybe there was a bug even?
>
> Thank you for looking into this and offering your suggestions!  The thing is, the RTA is a bit more complex than the situation you describe, due to the presence of other requirements (such as side areas that house line numbers and possibly other paragraph decorators).
> 
> The design of the skin is such that only `VFlow` does the layout.  The VFlow is the sole actor that deals with its complicated content.  Without a very good reason, this design is unlikely to change.  Furthermore, the `VFlow` is still an implementation detail, so one can't just subclass the skin (this is true for _other controls as well_).  Neither `VFlow` nor TextCell nor `RichUtils` are public API.
> 
> Yes, the test is green with #1945 but it fails in master.  And yes, the bug is still there even with #1945 , as can be seen with the monkey tester:
> 
> expected:
> Screenshot 2025-11-24 at 13 27 15
> 
> observed:
> Screenshot 2025-11-24 at 13 27 05

While looking at the test, discovered an issue with the `SimpleViewOnlyStyledModel`: 
https://bugs.openjdk.org/browse/JDK-8372438

thanks!

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2557815520

From angorya at openjdk.org  Mon Nov 24 22:09:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Nov 2025 22:09:25 GMT
Subject: RFR: 8372203: Piecewise linear easing function [v2]
In-Reply-To: <_ncebwfKqeq-6lsIMtzdLb6mtJg3YvDXfzr-GorD9Y0=.71c88969-b491-4eec-880e-4c0620651249@github.com>
References: 
 <_ncebwfKqeq-6lsIMtzdLb6mtJg3YvDXfzr-GorD9Y0=.71c88969-b491-4eec-880e-4c0620651249@github.com>
Message-ID: 

On Sat, 22 Nov 2025 10:06:56 GMT, Michael Strau?  wrote:

>> Implementation of the [linear](https://www.w3.org/TR/css-easing-2/#the-linear-easing-function) easing function, which is now widely supported by all browsers, but still missing in JavaFX.
>> 
>> It allows developers to approximate arbitrary easing functions with linear segments:
>> 
>> 
>> linear(
>>     /* Start to 1st bounce */
>>     0, 0.063, 0.25, 0.563, 1 36.4%,
>>     /* 1st to 2nd bounce */
>>     0.812, 0.75, 0.813, 1 72.7%,
>>     /* 2nd to 3rd bounce */
>>     0.953, 0.938, 0.953, 1 90.9%,
>>     /* 3rd bounce to end */
>>     0.984, 1 100% 100%
>>   )
>> 
>> 
>> 
>
> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - numeric overflow to infinity
>  - refactor tests

Looks good, left a couple of suggestions.

Used .button selector with transition in the monkey tester, with hilarious results.

modules/javafx.graphics/src/main/java/com/sun/scenario/animation/LinearInterpolator.java line 202:

> 200:         }
> 201: 
> 202:         // Linearly interpolate (or extrapolate) along the segment (ax, ay) -> (bx, by).

Alternative proposal: instead of introducing infinities, we probably should just arrive at the end-of-segment value when the ax ~= bx, something like this:


        // Linearly interpolate (or extrapolate) along the segment (ax, ay) -> (bx, by).
        if (isNear(ax, bx)) {
            // Degenerate segment; just treat as a step.
            return ay;
        }


where isNear is Math.abs(ax - bx) < SMALL_CONSTANT
(can be inline), unless the value of SMALL_CONSTANT depends on the interval.

what do you think?

modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 111:

> 109:      * @since 26
> 110:      */
> 111:     public static Interpolator LINEAR(Point2D... controlPoints) {

as you pointed out earlier, it's probably better to name this method ofLinear() since it is not a final constant.

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

PR Review: https://git.openjdk.org/jfx/pull/1977#pullrequestreview-3502390939
PR Review Comment: https://git.openjdk.org/jfx/pull/1977#discussion_r2557849902
PR Review Comment: https://git.openjdk.org/jfx/pull/1977#discussion_r2557853499

From crschnick at xpipe.io  Mon Nov 24 23:12:59 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Tue, 25 Nov 2025 00:12:59 +0100
Subject: [External] : Re: JavaFX Direct3D 12 - Call for performance
 testing help
In-Reply-To: 
References: 
 
 <953ef489-27df-435b-993f-4a345643aa38@xpipe.io>
 
 
 
 
Message-ID: <9221d447-6df3-4359-ad10-8e0532d40c55@xpipe.io>

Thanks Florian for the built runtime image.

I ran the tests on my AMD system with a Radeon RX 7600. The performance 
on d3d12 seems to be worse, especially the 3DMesh didn't even display 
anything and timeouted a few times.

On 14/11/2025 20:01, Florian Enner wrote:
> Hi Kevin,
>
> Then would it be ok for external people to provide a link on the 
> mailing list?
>
> @Christopher
>
> This one 
> https://drive.google.com/file/d/1BsTiKo0t-u1R50vH2fGTrruaxOC60O7h was 
> built with
>
> %JAVA_HOME%\bin\jlink --module-path "%JAVA_HOME%\jmods;%JAVAFX_JMODS%" 
> ?--add-modules 
> jdk.compiler,javafx.base,javafx.controls,javafx.graphics,jdk.jsobject,javafx.media 
> ?--strip-debug ?--no-header-files ?--no-man-pages ?--output 
> javafx26-d3d-jre-25
> With that it's down to 
> *"\javafx26-d3d-jre-25\bin\java.exe" 
> --enable-native-access=javafx.graphics -Dprism.order=d3d 
> RenderPerfTest.java --output-csv -r 3*
> *
> *
> -- Florian
>
>
> On Fri, Nov 14, 2025 at 7:16?PM Kevin Rushforth 
>  wrote:
>
>     Because we (Oracle) have very strict rules about publishing
>     binaries. We are not allowed to publish anything that hasn't been
>     approved for release, even an experimental test program.
>
>     -- Kevin
>
>
>     On 11/14/2025 10:07 AM, Christopher Schnick wrote:
>>
>>     May I ask why that is not possible?
>>
>>     On 14/11/2025 19:04, Kevin Rushforth wrote:
>>>     While that might be easier, it is not possible for us to provide
>>>     such a binary.
>>>
>>>     We could simplify it a bit by providing instructions to download
>>>     the JMODs (rather than the SDK) from jdk.java.net/direct3d12
>>>      and use jlink to create a JDK
>>>     that includes JavaFX. That way the custom options only need to
>>>     be added one time to jlink; running "javac" and "java" would
>>>     need no options related to finding the JavaFX modules or
>>>     enabling native access.
>>>
>>>     -- Kevin
>>>
>>>
>>>     On 11/14/2025 9:50 AM, Christopher Schnick wrote:
>>>>
>>>>     I will have to check whether I have time to look into this, but
>>>>     I am wondering if it would be possible for these tests to
>>>>     require less manual setup?
>>>>
>>>>     Isn't this where something like jlink could easily solve all
>>>>     these steps and the user would just have to run one of multiple
>>>>     launcher scripts of a prebuilt runtime image? I would argue it
>>>>     would be faster to just build a jlink image and provide a
>>>>     download link compared to writing the detailed instructions so
>>>>     that users run the test exactly as they should.
>>>>
>>>>     On 14/11/2025 15:10, Lukasz Kostyra wrote:
>>>>>
>>>>>     Hello all,
>>>>>
>>>>>     I got feedback on the previous call for performance testing
>>>>>     email that, instead of using the Bash test script on Windows
>>>>>     (and hoping you have Cygwin/MINGW installed) it would be
>>>>>     easier to integrate testing and CSV output functionality into
>>>>>     RenderPerfTest. I made those changes and they are now
>>>>>     available on jfx-sandbox direct3d12 branch (you WON?T find
>>>>>     those on main repo yet):
>>>>>     https://github.com/openjdk/jfx-sandbox/tree/direct3d12/tests/performance/animation/RenderPerfTest/src/renderperf
>>>>>     
>>>>>
>>>>>     Any feedback regarding RenderPerfTest will be updated on that
>>>>>     branch automatically, so it?s indeed a better solution if
>>>>>     there?s more feedback to it :)
>>>>>
>>>>>
>>>>>     *_New steps for running tests:_*
>>>>>
>>>>>      1. Download RenderPerfTest from above link (has to be
>>>>>         jfx-sandbox repo, direct3d12 branch) - best to download
>>>>>         the entire ?renderperf? folder as ZIP as it contains extra
>>>>>         resources needed for the test app
>>>>>      2. Get JavaFX Direct3D 12 build - either download the EA2 SDK
>>>>>         from [ https://jdk.java.net/javafxdirect3d12/
>>>>>         
>>>>>         ] or build it from scratch from direct3d12 [
>>>>>         https://github.com/openjdk/jfx-sandbox/tree/direct3d12
>>>>>         
>>>>>         ] branch (make sure to *build with -PCONF=Release*; at the
>>>>>         time of writing this email there is no functional
>>>>>         difference between the sandbox repo and the EA2 build).
>>>>>      3. RenderPerf can be run with (underlined parts you need to
>>>>>         fill in yourself):
>>>>>         *java --upgrade-module-path="_/lib_"
>>>>>         --add-modules=javafx.base,javafx.controls,javafx.graphics,jdk.jsobject,javafx.media
>>>>>         --enable-native-access=javafx.graphics
>>>>>         -Dprism.order=__ renderperf/RenderPerfTest.java
>>>>>         --output-csv -r _
>>>>>         _*Where:
>>>>>         **?-? path to directory where JavaFX SDK
>>>>>         is located (has to be where JavaFX bin and lib folders reside)
>>>>>         *???  *- short-hand for which Prism backend to use
>>>>>         ** -?how many times each test case should
>>>>>         run;RenderPerf will average FPS results from these runs
>>>>>
>>>>>      4. Running RenderPerf like above will produce
>>>>>         *RenderPerf_results---

> 100:      * Each control point associates an input progress value (X) with an output progress value (Y).

I think an explanation of what these progress values are will help, especially with names such as "input" and "output" associated with them instead of the `x, y` coordinate value names one could expect.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1977#discussion_r2567548606
PR Review Comment: https://git.openjdk.org/jfx/pull/1977#discussion_r2567678868

From mhanl at openjdk.org  Thu Nov 27 09:48:04 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 27 Nov 2025 09:48:04 GMT
Subject: RFR: 8296653: ComboBox promptText is not displayed when the value
 is reset
In-Reply-To: 
References: 
Message-ID: 

On Wed, 26 Nov 2025 16:11:52 GMT, Ziad El Midaoui  wrote:

> The issue occurred because the skin marks the button cell as ?empty? when the value becomes null.
> With the fix clearing the ComboBox value re-shows the prompt text.
> Tested using the code present in the bug.

I think a test would be good here.

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

PR Comment: https://git.openjdk.org/jfx/pull/1989#issuecomment-3584979890

From mhanl at openjdk.org  Thu Nov 27 10:44:05 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 27 Nov 2025 10:44:05 GMT
Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow
 in RTL mode
In-Reply-To: <9YBLOcueh9GZKb25W1ntyDE_sC744To-Ts0CxI201L4=.27113211-ce7b-49ce-8406-6b0c9105406e@github.com>
References: <9YBLOcueh9GZKb25W1ntyDE_sC744To-Ts0CxI201L4=.27113211-ce7b-49ce-8406-6b0c9105406e@github.com>
Message-ID: 

On Wed, 26 Nov 2025 15:25:44 GMT, Ziad El Midaoui  wrote:

> Fix trailing space present for complex text ( LTR text with RTL text ) Example: "Arabic: ???????"
> Added case to handle complex text in `getPosX` of `TextRun`
> Tested the changes with the code present in the bug.

Can this be tested with a JUnit Test? I'm asking as there are quite some problems right now with complex text, fonts and RTL. So every regression test will help in the future

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

PR Comment: https://git.openjdk.org/jfx/pull/1988#issuecomment-3585186128

From mhanl at openjdk.org  Thu Nov 27 11:09:06 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 27 Nov 2025 11:09:06 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v6]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 26 Nov 2025 23:48:33 GMT, Kevin Rushforth  wrote:

> However, I also note that with this patch, even `gradle all` doesn't create `build/publications`. Consider adding a dependency to either `gradle sdk` or, more likely, `gradle all` so that still creates `build/publications`.

Thanks for testing!
Just so we have a common understanding: Depending on the `all` task seems to be a better choice than `sdk`? I guess because then we are sure that everything did run before, right?

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

PR Comment: https://git.openjdk.org/jfx/pull/1970#issuecomment-3585273948

From lkostyra at openjdk.org  Thu Nov 27 12:44:16 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 27 Nov 2025 12:44:16 GMT
Subject: Integrated: 8372275: NPE in D3DResourceFactory.createPresentable
In-Reply-To: 
References: 
Message-ID: 

On Wed, 26 Nov 2025 11:39:28 GMT, Lukasz Kostyra  wrote:

> This PR solves potential NPE in `D3DResourceFactory.createPresentable`.
> 
> The mistake was quite obvious, creating an RTT can potentially return `null` due to lack of resources available in the system. If that happens while dirty opts are enabled, `rtt` would be dereferenced by calling `rtt.contentsUseful()`.
> 
> The fix is to move the check to after we check if `rtt` is null.

This pull request has now been integrated.

Changeset: a39a1da8
Author:    Lukasz Kostyra 
URL:       https://git.openjdk.org/jfx/commit/a39a1da82f3214a2d42912b5a1a21dc743e452dc
Stats:     10 lines in 1 file changed: 5 ins; 5 del; 0 mod

8372275: NPE in D3DResourceFactory.createPresentable

Reviewed-by: mstrauss, kcr, jdv

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

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

From mstrauss at openjdk.org  Thu Nov 27 12:46:49 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 27 Nov 2025 12:46:49 GMT
Subject: RFR: 8372203: Piecewise linear easing function [v9]
In-Reply-To: 
References: 
Message-ID: 

> Implementation of the [linear](https://www.w3.org/TR/css-easing-2/#the-linear-easing-function) easing function, which is now widely supported by all browsers, but still missing in JavaFX.
> 
> It allows developers to approximate arbitrary easing functions with linear segments:
> 
> 
> linear(
>     /* Start to 1st bounce */
>     0, 0.063, 0.25, 0.563, 1 36.4%,
>     /* 1st to 2nd bounce */
>     0.812, 0.75, 0.813, 1 72.7%,
>     /* 2nd to 3rd bounce */
>     0.953, 0.938, 0.953, 1 90.9%,
>     /* 3rd bounce to end */
>     0.984, 1 100% 100%
>   )
> 
> 
> 

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  review changes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1977/files
  - new: https://git.openjdk.org/jfx/pull/1977/files/5839fcb6..b1972ad9

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

  Stats: 12 lines in 2 files changed: 6 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1977.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1977/head:pull/1977

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

From mstrauss at openjdk.org  Thu Nov 27 12:46:54 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 27 Nov 2025 12:46:54 GMT
Subject: RFR: 8372203: Piecewise linear easing function [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 27 Nov 2025 09:00:32 GMT, Nir Lisker  wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   doc change
>
> modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 100:
> 
>> 98:      * Returns a piecewise-linear interpolator with the specified control points.
>> 99:      * 

>> 100:      * Each control point associates an input progress value (X) with an output progress value (Y).
> 
> I think an explanation of what these progress values are will help, especially with names such as "input" and "output" associated with them instead of the `x, y` coordinate value names one could expect.

I've added a section to explain that.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1977#discussion_r2568498674

From nlisker at openjdk.org  Thu Nov 27 13:22:06 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 27 Nov 2025 13:22:06 GMT
Subject: RFR: 8372203: Piecewise linear easing function [v8]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 27 Nov 2025 12:43:45 GMT, Michael Strau?  wrote:

>> modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 100:
>> 
>>> 98:      * Returns a piecewise-linear interpolator with the specified control points.
>>> 99:      * 

>>> 100:      * Each control point associates an input progress value (X) with an output progress value (Y).
>> 
>> I think an explanation of what these progress values are will help, especially with names such as "input" and "output" associated with them instead of the `x, y` coordinate value names one could expect.
>
> I've added a section to explain that.

Much better!

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1977#discussion_r2568651022

From lkostyra at openjdk.org  Thu Nov 27 13:23:12 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 27 Nov 2025 13:23:12 GMT
Subject: RFR: JDK-8210547 synchronise with OpenGL after the last window is
 presented [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 25 Nov 2025 00:33:41 GMT, notzed  wrote:

>> As discussed on the mailing list.
>> 
>> OpenGL requires an explicit glFinish() to synchronise with the video refresh.  The current usage is incorrect and against the specification.  This patch calls glFinish() after all windows have been drawn following a pulse.
>
> notzed has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   JDK-8210547 synchronise with OpenGL after the last window is presented

I tested your changes but they do not fix the original problem which #1929 addresses. I just tested this on my Intel UHD machine and the framerate is not tied to VSync (FPS meter from the original issue is around 1000fps instead of 60fps).

I think it's getting pretty confusing regarding both this change and Thiago's PR, so I would like to figure some things out before we progress. I looked back into the mailing list discussion but I'm still not fully clear on everything.

Is this change actually supposed to address the problem from [JDK-8210547](https://bugs.openjdk.org/browse/JDK-8210547)? If so, is this change in place of #1929 or does it depend on it?

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

PR Comment: https://git.openjdk.org/jfx/pull/1981#issuecomment-3585831140

From zelmidaoui at openjdk.org  Thu Nov 27 14:42:18 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 27 Nov 2025 14:42:18 GMT
Subject: RFR: 8296653: ComboBox promptText is not displayed when the value
 is reset [v2]
In-Reply-To: 
References: 
Message-ID: 

> The issue occurred because the skin marks the button cell as ?empty? when the value becomes null.
> With the fix clearing the ComboBox value re-shows the prompt text.
> Tested using the code present in the bug.

Ziad El Midaoui has updated the pull request incrementally with two additional commits since the last revision:

 - Remove space
 - Added Test and fixed comment

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1989/files
  - new: https://git.openjdk.org/jfx/pull/1989/files/81b6231e..dd62ca2c

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

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

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

From zelmidaoui at openjdk.org  Thu Nov 27 14:42:20 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 27 Nov 2025 14:42:20 GMT
Subject: RFR: 8296653: ComboBox promptText is not displayed when the value
 is reset
In-Reply-To: 
References: 
 
Message-ID: <--3Zs85wWMWDGm7mynWT4NkkpjKpEWP6oGWlXIPDIuk=.465577c1-7c3e-4ca5-9fc6-af801fa5e5ac@github.com>

On Thu, 27 Nov 2025 09:45:56 GMT, Marius Hanl  wrote:

> I think a test would be good here.

I have added one could you please re-review

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

PR Comment: https://git.openjdk.org/jfx/pull/1989#issuecomment-3586212946

From zelmidaoui at openjdk.org  Thu Nov 27 14:42:22 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 27 Nov 2025 14:42:22 GMT
Subject: RFR: 8296653: ComboBox promptText is not displayed when the value
 is reset [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 27 Nov 2025 08:34:37 GMT, Ambarish Rapte  wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ComboBoxListViewSkin.java line 457:
>> 
>>> 455:             if (cell == null) return true;
>>> 456: 
>>> 457:             // JDK-8296653
>> 
>> We generally don't include the bug id. Please remove.
>
> May be we can add a comment to explain the change.

I have updated the code could you please re review

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1989#discussion_r2569020425

From mhanl at openjdk.org  Thu Nov 27 17:40:05 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 27 Nov 2025 17:40:05 GMT
Subject: RFR: 8296653: ComboBox promptText is not displayed when the value
 is reset [v2]
In-Reply-To: 
References: 
 
Message-ID: <7ZG4NrJSc7ePFhi1mcJhdfHHNC8SPLqtFTOrT75G8KI=.9c58c76c-8745-42f1-ad2c-194a54d0b505@github.com>

On Thu, 27 Nov 2025 14:42:18 GMT, Ziad El Midaoui  wrote:

>> The issue occurred because the skin marks the button cell as ?empty? when the value becomes null.
>> With the fix clearing the ComboBox value re-shows the prompt text.
>> Tested using the code present in the bug.
>
> Ziad El Midaoui has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove space
>  - Added Test and fixed comment

modules/javafx.controls/src/main/java/javafx/scene/control/skin/ComboBoxListViewSkin.java line 459:

> 457:             if (cell == buttonCell) {
> 458:                 final String promptText = comboBox.getPromptText();
> 459:                 if (comboBox.getValue() == null

is the `comboBox.getValue()` check needed? Asking, as we are in here only if `empty` is true, so maybe this is not needed to check?

modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 1317:

> 1315:     @Test
> 1316:     public void testPromptTextRestoredAfterSetValueNull() {
> 1317:         comboBox.setPromptText("Select Value");

I would suggest to have a `String` variable with `"Select Value"` as value. And then use it here and the other two occurrences

modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 1323:

> 1321:         sl = new StageLoader(comboBox);
> 1322:         comboBox.applyCss();
> 1323:         comboBox.show();

`applyCss` and `show` are not needed, should be removed

modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 1331:

> 1329:         sm.select(2);
> 1330:         Toolkit.getToolkit().firePulse();
> 1331: 

An assert that the `buttonCell` is not `Select Value` would make sense here (`assertNotEquals`)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1989#discussion_r2569626077
PR Review Comment: https://git.openjdk.org/jfx/pull/1989#discussion_r2569611338
PR Review Comment: https://git.openjdk.org/jfx/pull/1989#discussion_r2569612489
PR Review Comment: https://git.openjdk.org/jfx/pull/1989#discussion_r2569621239

From mariushanl at web.de  Thu Nov 27 20:39:50 2025
From: mariushanl at web.de (Marius Hanl)
Date: Thu, 27 Nov 2025 20:39:50 +0000
Subject: JavaFX Direct3D 12 - Call for performance testing help
In-Reply-To: 
References: 
 
Message-ID: 

An HTML attachment was scrubbed...
URL: 

From lukasz.kostyra at oracle.com  Fri Nov 28 11:30:29 2025
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Fri, 28 Nov 2025 11:30:29 +0000
Subject: JavaFX Direct3D 12 - Call for performance testing help
In-Reply-To: 
References: 
 
 
Message-ID: 

Hi Marius,

Thanks for checking. You can get D3D12 to inform you which GPU was used by adding ?-Dprism.verbose=true? to Java properties on launch. You should see something along the lines of:

=======8<=======
?
OS Information:
        Windows version 10.0 build 26100
DXGI Adapter Information:
        Intel(R) Iris(R) Xe Graphics
        Device ID: ven_8086, dev_46A6, subsys_0B0B1028, rev_0000000C
        Device Memory: VRAM 8000000 System 0 Shared 3EE1D3000
D3D12 Device Information:
        Intel(R) Iris(R) Xe Graphics
        Feature Level: 12_1
        Shader Model: 6.7
vsync: false vpipe: true
=======8<=======

You can also cross-check it with D3D, that same property should print similar information from D3D9.

The only reason I can think of as to why the integrated GPU is sharing some work despite running JFX on discrete GPU is the way these hybrid systems are sometimes designed. A lot depends on where the display physically connects to in the computer, for example on laptops it is a common strategy to wire the screens and HDMI directly to the iGPU and if dGPU is needed the driver implicitly clones drawn frames to iGPU?s memory for presentation on the screen at a cost of some extra work and latency. Some laptops have a way to switch over the HDMI and integrated display output directly to dGPU, but this is mostly on the more expensive higher tier gaming laptops and requires some tinkering in BIOS. Tower PCs can have similar symptoms if displays are connected to motherboard HDMI/DP ports (which wire to iGPU) instead of dGPU ports.

In short, unless you use a tower PC and your HDMI/DP cable is connected to the wrong port I wouldn?t worry about that shared usage that much. If devices listed by D3D and D3D12 are matching and what you expect them to be, both D3D9 and D3D12 use the same GPU. I think it?s more probable that the problem is, as I like to sometimes call it, ?between the chair and the keyboard? of whoever wrote the backend. ;) It is highly probable the Nvidia results are viable, because we did see low and similar performance on discrete GPUs both here and from others who sent over the results.

Regardless, having two benchmarks would be handy, as long as both of them have the D3D9 baseline run on the same GPU. The initialization process should be identical between D3D9 and D3D12 (I essentially wrote it based on D3D9, but with D3D12/DXGI API) so whatever applies to D3D9 should also apply to D3D12 - if it doesn?t let me know.

-Lukasz

From: Marius Hanl 
Sent: Thursday, 27 November 2025 21:40
To: Lukasz Kostyra ; openjfx-dev at openjdk.org
Subject: [External] : RE: RE: JavaFX Direct3D 12 - Call for performance testing help

Hi Lukasz,

I started testing today and noticed that my laptop isn't using the discrete GPU at all.
So I looked around in the NVIDIA Control Panel and found a setting that apparently automatically selects the GPU for the application.
The discrete NVIDIA GPU is used for games, while the internal AMD GPU is used for JavaFX, but also my browser, for example.

When set to use the discrete NVIDIA GPU, he still seems to somewhat share the work between both GPUs when doing the benchmark.
In my case, I can see 40% utilization for the NVIDIA GPU and 15% for the internal AMD GPU.

I wonder if I should do two benchmarks: One with the NVIDIA GPU set, and one where it is not used at all as described above?
And if yes, is there something I need to check for my scenario?

-- Marius
Gesendet: Freitag, 14. November 2025 um 15:10
Von: "Lukasz Kostyra" >
An: "openjfx-dev at openjdk.org" >
Betreff: RE: JavaFX Direct3D 12 - Call for performance testing help
Hello all,

I got feedback on the previous call for performance testing email that, instead of using the Bash test script on Windows (and hoping you have Cygwin/MINGW installed) it would be easier to integrate testing and CSV output functionality into RenderPerfTest. I made those changes and they are now available on jfx-sandbox direct3d12 branch (you WON?T find those on main repo yet): https://github.com/openjdk/jfx-sandbox/tree/direct3d12/tests/performance/animation/RenderPerfTest/src/renderperf

Any feedback regarding RenderPerfTest will be updated on that branch automatically, so it?s indeed a better solution if there?s more feedback to it :)

New steps for running tests:

  1.  Download RenderPerfTest from above link (has to be jfx-sandbox repo, direct3d12 branch) - best to download the entire ?renderperf? folder as ZIP as it contains extra resources needed for the test app
  2.  Get JavaFX Direct3D 12 build - either download the EA2 SDK from [ https://jdk.java.net/javafxdirect3d12/ ] or build it from scratch from direct3d12 [ https://github.com/openjdk/jfx-sandbox/tree/direct3d12 ] branch (make sure to build with -PCONF=Release; at the time of writing this email there is no functional difference between the sandbox repo and the EA2 build).
  3.  RenderPerf can be run with (underlined parts you need to fill in yourself):
    java --upgrade-module-path="/lib" --add-modules=javafx.base,javafx.controls,javafx.graphics,jdk.jsobject,javafx.media --enable-native-access=javafx.graphics -Dprism.order= renderperf/RenderPerfTest.java --output-csv -r 
Where:
     -  path to directory where JavaFX SDK is located (has to be where JavaFX bin and lib folders reside)
     -  short-hand for which Prism backend to use
      - how many times each test case should run; RenderPerf will average FPS results from these runs



  1.  Running RenderPerf like above will produce RenderPerf_results---