From kcr at openjdk.org Mon Oct 3 13:33:39 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 3 Oct 2022 13:33:39 GMT Subject: RFR: 8293795: [Accessibility] [Win] [Narrator] Exceptions when deleting text with continous key press in TextArea and TextField In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 15:15:06 GMT, Ambarish Rapte wrote: > This is a follow up bug-fix to [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281) > > Issue: > When Narrator is running, > Following scenarios with TextField or TextArea cause IllegalArgumentException or NPE > > 1. Move cursor to beginning of line, Press and hold DELETE key > 2. Move cursor to beginning of line, Press and hold CTRL + DELETE key > 3. Move cursor to end of line, Press and hold BACKSPACE key > 4. Move cursor to end of line, Press and hold CTRL + BACKSPACE key > > Fix: > Two variable `start` and `end` in `WinTextRangeProvider` should be validated against text length > 1. Added a method `validateRange()`, and is called several from methods which access text based on `start` and `end` variables > 2. Partially reverted fix of [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281) : > - removed https://github.com/openjdk/jfx/blob/35675c8d27d54a26059b182614e18152794dbcec/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java#L180 > - and used `validateRange()` instead to be symmetrical. > > Verification: > To observe the issue. > > 1. Run any program with TextField and/or TextArea > 2. Launch Windows Narrator > 3. Run the exception causing scenarios several times: > > - Move cursor to beginning of line, Press and hold DELETE key > - Move cursor to beginning of line, Press and hold CTRL + DELETE key > - Move cursor to end of line, Press and hold BACKSPACE key > - Move cursor to end of line, Press and hold CTRL + BACKSPACE key The fix looks good, although I think you can avoid redundantly calling `getAttribute(TEXT)` by passing in `text` as a parameter to `validateRange` (see inline comment). Also, for consistency, you might rep,ace the check on lines 236-237 with a call to `validateRange`. modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 95: > 93: > 94: private void validateRange() { > 95: String text = (String)getAttribute(TEXT); It looks like you already have the `text` everywhere you call this. You might consider passing it in as a parameter rather than calling `getAttribute` redundantly. ------------- PR: https://git.openjdk.org/jfx/pull/907 From kcr at openjdk.org Mon Oct 3 13:47:30 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 3 Oct 2022 13:47:30 GMT Subject: RFR: 8293795: [Accessibility] [Win] [Narrator] Exceptions when deleting text with continous key press in TextArea and TextField In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 15:15:06 GMT, Ambarish Rapte wrote: > This is a follow up bug-fix to [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281) > > Issue: > When Narrator is running, > Following scenarios with TextField or TextArea cause IllegalArgumentException or NPE > > 1. Move cursor to beginning of line, Press and hold DELETE key > 2. Move cursor to beginning of line, Press and hold CTRL + DELETE key > 3. Move cursor to end of line, Press and hold BACKSPACE key > 4. Move cursor to end of line, Press and hold CTRL + BACKSPACE key > > Fix: > Two variable `start` and `end` in `WinTextRangeProvider` should be validated against text length > 1. Added a method `validateRange()`, and is called several from methods which access text based on `start` and `end` variables > 2. Partially reverted fix of [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281) : > - removed https://github.com/openjdk/jfx/blob/35675c8d27d54a26059b182614e18152794dbcec/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java#L180 > - and used `validateRange()` instead to be symmetrical. > > Verification: > To observe the issue. > > 1. Run any program with TextField and/or TextArea > 2. Launch Windows Narrator > 3. Run the exception causing scenarios several times: > > - Move cursor to beginning of line, Press and hold DELETE key > - Move cursor to beginning of line, Press and hold CTRL + DELETE key > - Move cursor to end of line, Press and hold BACKSPACE key > - Move cursor to end of line, Press and hold CTRL + BACKSPACE key @HimaBinduMeda can you be the second reviewer? ------------- PR: https://git.openjdk.org/jfx/pull/907 From arapte at openjdk.org Mon Oct 3 14:31:49 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 3 Oct 2022 14:31:49 GMT Subject: RFR: 8293795: [Accessibility] [Win] [Narrator] Exceptions when deleting text with continous key press in TextArea and TextField [v2] In-Reply-To: References: Message-ID: > This is a follow up bug-fix to [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281) > > Issue: > When Narrator is running, > Following scenarios with TextField or TextArea cause IllegalArgumentException or NPE > > 1. Move cursor to beginning of line, Press and hold DELETE key > 2. Move cursor to beginning of line, Press and hold CTRL + DELETE key > 3. Move cursor to end of line, Press and hold BACKSPACE key > 4. Move cursor to end of line, Press and hold CTRL + BACKSPACE key > > Fix: > Two variable `start` and `end` in `WinTextRangeProvider` should be validated against text length > 1. Added a method `validateRange()`, and is called several from methods which access text based on `start` and `end` variables > 2. Partially reverted fix of [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281) : > - removed https://github.com/openjdk/jfx/blob/35675c8d27d54a26059b182614e18152794dbcec/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java#L180 > - and used `validateRange()` instead to be symmetrical. > > Verification: > To observe the issue. > > 1. Run any program with TextField and/or TextArea > 2. Launch Windows Narrator > 3. Run the exception causing scenarios several times: > > - Move cursor to beginning of line, Press and hold DELETE key > - Move cursor to beginning of line, Press and hold CTRL + DELETE key > - Move cursor to end of line, Press and hold BACKSPACE key > - Move cursor to end of line, Press and hold CTRL + BACKSPACE key Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: pass text as argument to validateRange ------------- Changes: - all: https://git.openjdk.org/jfx/pull/907/files - new: https://git.openjdk.org/jfx/pull/907/files/eb7222f8..78bf9185 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=907&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=907&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/907.diff Fetch: git fetch https://git.openjdk.org/jfx pull/907/head:pull/907 PR: https://git.openjdk.org/jfx/pull/907 From arapte at openjdk.org Mon Oct 3 14:40:27 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 3 Oct 2022 14:40:27 GMT Subject: RFR: 8293795: [Accessibility] [Win] [Narrator] Exceptions when deleting text with continous key press in TextArea and TextField [v3] In-Reply-To: References: Message-ID: > This is a follow up bug-fix to [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281) > > Issue: > When Narrator is running, > Following scenarios with TextField or TextArea cause IllegalArgumentException or NPE > > 1. Move cursor to beginning of line, Press and hold DELETE key > 2. Move cursor to beginning of line, Press and hold CTRL + DELETE key > 3. Move cursor to end of line, Press and hold BACKSPACE key > 4. Move cursor to end of line, Press and hold CTRL + BACKSPACE key > > Fix: > Two variable `start` and `end` in `WinTextRangeProvider` should be validated against text length > 1. Added a method `validateRange()`, and is called several from methods which access text based on `start` and `end` variables > 2. Partially reverted fix of [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281) : > - removed https://github.com/openjdk/jfx/blob/35675c8d27d54a26059b182614e18152794dbcec/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java#L180 > - and used `validateRange()` instead to be symmetrical. > > Verification: > To observe the issue. > > 1. Run any program with TextField and/or TextArea > 2. Launch Windows Narrator > 3. Run the exception causing scenarios several times: > > - Move cursor to beginning of line, Press and hold DELETE key > - Move cursor to beginning of line, Press and hold CTRL + DELETE key > - Move cursor to end of line, Press and hold BACKSPACE key > - Move cursor to end of line, Press and hold CTRL + BACKSPACE key Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: call validateRange() on line 236-237 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/907/files - new: https://git.openjdk.org/jfx/pull/907/files/78bf9185..99e8b68a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=907&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=907&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/907.diff Fetch: git fetch https://git.openjdk.org/jfx pull/907/head:pull/907 PR: https://git.openjdk.org/jfx/pull/907 From arapte at openjdk.org Mon Oct 3 14:40:29 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 3 Oct 2022 14:40:29 GMT Subject: RFR: 8293795: [Accessibility] [Win] [Narrator] Exceptions when deleting text with continous key press in TextArea and TextField [v3] In-Reply-To: References: Message-ID: On Mon, 3 Oct 2022 13:25:00 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> call validateRange() on line 236-237 > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 95: > >> 93: >> 94: private void validateRange() { >> 95: String text = (String)getAttribute(TEXT); > > It looks like you already have the `text` everywhere you call this. You might consider passing it in as a parameter rather than calling `getAttribute` redundantly. Thanks for the review. Addressed both the comments. Please take a re-look. ------------- PR: https://git.openjdk.org/jfx/pull/907 From kcr at openjdk.org Mon Oct 3 14:59:22 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 3 Oct 2022 14:59:22 GMT Subject: RFR: 8293795: [Accessibility] [Win] [Narrator] Exceptions when deleting text with continous key press in TextArea and TextField [v3] In-Reply-To: References: Message-ID: On Mon, 3 Oct 2022 14:40:27 GMT, Ambarish Rapte wrote: >> This is a follow up bug-fix to [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281) >> >> Issue: >> When Narrator is running, >> Following scenarios with TextField or TextArea cause IllegalArgumentException or NPE >> >> 1. Move cursor to beginning of line, Press and hold DELETE key >> 2. Move cursor to beginning of line, Press and hold CTRL + DELETE key >> 3. Move cursor to end of line, Press and hold BACKSPACE key >> 4. Move cursor to end of line, Press and hold CTRL + BACKSPACE key >> >> Fix: >> Two variable `start` and `end` in `WinTextRangeProvider` should be validated against text length >> 1. Added a method `validateRange()`, and is called several from methods which access text based on `start` and `end` variables >> 2. Partially reverted fix of [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281) : >> - removed https://github.com/openjdk/jfx/blob/35675c8d27d54a26059b182614e18152794dbcec/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java#L180 >> - and used `validateRange()` instead to be symmetrical. >> >> Verification: >> To observe the issue. >> >> 1. Run any program with TextField and/or TextArea >> 2. Launch Windows Narrator >> 3. Run the exception causing scenarios several times: >> >> - Move cursor to beginning of line, Press and hold DELETE key >> - Move cursor to beginning of line, Press and hold CTRL + DELETE key >> - Move cursor to end of line, Press and hold BACKSPACE key >> - Move cursor to end of line, Press and hold CTRL + BACKSPACE key > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > call validateRange() on line 236-237 Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/907 From kcr at openjdk.org Mon Oct 3 18:17:39 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 3 Oct 2022 18:17:39 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 15:58:01 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > 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 20 additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8290844.skin.install > - 8290844: unit tests > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - ... and 10 more: https://git.openjdk.org/jfx/compare/c03446c3...d954aafc @johanvos Do you have any thoughts on this enhancement? I'm most interested whether you extend any of the built-in JavaFX skin classes in a way that it might cause problems for you if they move some of their setup code from their constructor to their `install` method? ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Mon Oct 3 21:44:03 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Oct 2022 21:44:03 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin Message-ID: Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). ------------- Commit messages: - 8294589: cleanup - 8294589: executeOnceWhenPropertyIsNonNull - 8294589: review comments - 8294589: fixed leak test - 8294589: menu bar skin memory leak Changes: https://git.openjdk.org/jfx/pull/906/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294589 Stats: 255 lines in 5 files changed: 166 ins; 47 del; 42 mod Patch: https://git.openjdk.org/jfx/pull/906.diff Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906 PR: https://git.openjdk.org/jfx/pull/906 From fastegal at openjdk.org Mon Oct 3 21:44:05 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Mon, 3 Oct 2022 21:44:05 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 23:00:17 GMT, Andy Goryachev wrote: > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinMemoryLeakTest.java line 94: > 92: public void testMemoryLeakSameSkinClass() { > 93: showControl(control, true); > 94: installDefaultSkin(control); no - here we test the isolated skin installation, no need for actually showing it. Please don't change the semantic of existing tests. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinMemoryLeakTest.java line 225: > 223: protected void showControl(Control control, boolean focused) { > 224: // use StageLoader maybe? > 225: if (root == null) { we could, but don't here for consistency - the pattern is used across multiple tests to guarantee full control about the layout (which conceededly is not needed here :) ------------- PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Mon Oct 3 21:44:05 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Oct 2022 21:44:05 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 09:09:33 GMT, Jeanette Winzenburg wrote: >> Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinMemoryLeakTest.java line 94: > >> 92: public void testMemoryLeakSameSkinClass() { >> 93: showControl(control, true); >> 94: installDefaultSkin(control); > > no - here we test the isolated skin installation, no need for actually showing it. Please don't change the semantic of existing tests. So here we have a problem - I know that the memory leak is fixed (I've tested using VisualVM in a real application), but without this change, or without adding a StageLoader, the test fails. Any suggestions? ------------- PR: https://git.openjdk.org/jfx/pull/906 From fastegal at openjdk.org Mon Oct 3 21:44:06 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Mon, 3 Oct 2022 21:44:06 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: Message-ID: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> On Fri, 30 Sep 2022 15:06:19 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinMemoryLeakTest.java line 94: >> >>> 92: public void testMemoryLeakSameSkinClass() { >>> 93: showControl(control, true); >>> 94: installDefaultSkin(control); >> >> no - here we test the isolated skin installation, no need for actually showing it. Please don't change the semantic of existing tests. > > So here we have a problem - I know that the memory leak is fixed (I've tested using VisualVM in a real application), but without this change, or without adding a StageLoader, the test fails. > Any suggestions? hmm, no direct idea but ... sounds like it's not fixed completely: first step would be to track down why it fails for this particular skin and what exactly is different from all other skins (that are fixed so far). If it turns out that there's something special, you can do the special memory testing in SkinCleanupTest (with documentation why that's required). ------------- PR: https://git.openjdk.org/jfx/pull/906 From fastegal at openjdk.org Mon Oct 3 21:44:07 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Mon, 3 Oct 2022 21:44:07 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: On Fri, 30 Sep 2022 15:51:55 GMT, Jeanette Winzenburg wrote: >> So here we have a problem - I know that the memory leak is fixed (I've tested using VisualVM in a real application), but without this change, or without adding a StageLoader, the test fails. >> Any suggestions? > > hmm, no direct idea but ... sounds like it's not fixed completely: first step would be to track down why it fails for this particular skin and what exactly is different from all other skins (that are fixed so far). If it turns out that there's something special, you can do the special memory testing in SkinCleanupTest (with documentation why that's required). btw: I would suggest that you believe the original test :) Added complexity might cancel out an existing problem while the underlying issue still persists in some way .. ------------- PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Mon Oct 3 21:44:08 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Oct 2022 21:44:08 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: On Fri, 30 Sep 2022 15:56:31 GMT, Jeanette Winzenburg wrote: >> hmm, no direct idea but ... sounds like it's not fixed completely: first step would be to track down why it fails for this particular skin and what exactly is different from all other skins (that are fixed so far). If it turns out that there's something special, you can do the special memory testing in SkinCleanupTest (with documentation why that's required). > > btw: I would suggest that you believe the original test :) Added complexity might cancel out an existing problem while the underlying issue still persists in some way .. Perhaps the test is too artificial, something is not being done correctly or exactly as in the real application? Using StageLoader or showControl() hooks up the missing dependencies. ------------- PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Mon Oct 3 21:44:09 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Oct 2022 21:44:09 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: On Fri, 30 Sep 2022 15:57:03 GMT, Andy Goryachev wrote: >> btw: I would suggest that you believe the original test :) Added complexity might cancel out an existing problem while the underlying issue still persists in some way .. > > Perhaps the test is too artificial, something is not being done correctly or exactly as in the real application? Using StageLoader or showControl() hooks up the missing dependencies. > btw: I would suggest that you believe the test Sorry, I trust VisualVM path to GC root. ------------- PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Mon Oct 3 21:44:10 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Oct 2022 21:44:10 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: On Fri, 30 Sep 2022 15:59:32 GMT, Andy Goryachev wrote: >> Perhaps the test is too artificial, something is not being done correctly or exactly as in the real application? Using StageLoader or showControl() hooks up the missing dependencies. > >> btw: I would suggest that you believe the test > > Sorry, I trust VisualVM path to GC root. before: Screen Shot 2022-09-30 at 09 01 23 ------------- PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Mon Oct 3 21:44:10 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Oct 2022 21:44:10 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: On Fri, 30 Sep 2022 16:01:56 GMT, Andy Goryachev wrote: >>> btw: I would suggest that you believe the test >> >> Sorry, I trust VisualVM path to GC root. > > before: > Screen Shot 2022-09-30 at 09 01 23 after: Screen Shot 2022-09-30 at 09 01 36 ------------- PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Mon Oct 3 21:44:11 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Oct 2022 21:44:11 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: On Fri, 30 Sep 2022 16:02:11 GMT, Andy Goryachev wrote: >> before: >> Screen Shot 2022-09-30 at 09 01 23 > > after: > Screen Shot 2022-09-30 at 09 01 36 See https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java ------------- PR: https://git.openjdk.org/jfx/pull/906 From fastegal at openjdk.org Mon Oct 3 21:44:12 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Mon, 3 Oct 2022 21:44:12 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: On Fri, 30 Sep 2022 16:05:57 GMT, Andy Goryachev wrote: >> after: >> Screen Shot 2022-09-30 at 09 01 36 > > See https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java okay, not tested (so treat it as just a wild guess :) - there is this listener on the skinnable's sceneProperty: it's installed only when there's no scene and removed once the scene is set. Without showing, it looks like it's never removed (as it must!) Unrelated: also look at your dispose: it's violating its contract (making SkinDisposeContractTest fail) ------------- PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Mon Oct 3 21:44:12 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Oct 2022 21:44:12 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: On Fri, 30 Sep 2022 16:15:23 GMT, Jeanette Winzenburg wrote: >> See https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > okay, not tested (so treat it as just a wild guess :) - there is this listener on the skinnable's sceneProperty: it's installed only when there's no scene and removed once the scene is set. Without showing, it looks like it's never removed (as it must!) > > Unrelated: also look at your dispose: it's violating its contract (making SkinDisposeContractTest fail) Will definitely do! Some tests were failing yesterday, until all is fixed - it's a draft PR :-) Thank you so much, @kleopatra ------------- PR: https://git.openjdk.org/jfx/pull/906 From fastegal at openjdk.org Mon Oct 3 21:44:13 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Mon, 3 Oct 2022 21:44:13 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: On Fri, 30 Sep 2022 16:19:33 GMT, Andy Goryachev wrote: >> okay, not tested (so treat it as just a wild guess :) - there is this listener on the skinnable's sceneProperty: it's installed only when there's no scene and removed once the scene is set. Without showing, it looks like it's never removed (as it must!) >> >> Unrelated: also look at your dispose: it's violating its contract (making SkinDisposeContractTest fail) > > Will definitely do! Some tests were failing yesterday, until all is fixed - it's a draft PR :-) > Thank you so much, @kleopatra > Perhaps the test is too artificial, something is not being done correctly or exactly as in the real application? Using StageLoader or showControl() hooks up the missing dependencies. one last time: there is _no_ such thing as a "too artificial" test - a class must _always_ fulfil its contract in whatever valid context. It's not enough to do so for some (or even the majority) of use-cases. Plus: logically, any assumption (like: there are no memory leaks) is invalidated by a single counter-example (like the valid test). Have a nice weekend, I'm off now :) ------------- PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Mon Oct 3 21:44:14 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Oct 2022 21:44:14 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: <4FornU_wKFt4lG2ZvJ2hp1NQevypNGb0OZETSaZVDXM=.1300ae4d-6688-494f-8f63-003ce3e72afa@github.com> On Fri, 30 Sep 2022 16:21:32 GMT, Jeanette Winzenburg wrote: >> Will definitely do! Some tests were failing yesterday, until all is fixed - it's a draft PR :-) >> Thank you so much, @kleopatra > >> Perhaps the test is too artificial, something is not being done correctly or exactly as in the real application? Using StageLoader or showControl() hooks up the missing dependencies. > > one last time: there is _no_ such thing as a "too artificial" test - a class must _always_ fulfil its contract in whatever valid context. It's not enough to do so for some (or even the majority) of use-cases. Plus: logically, any assumption (like: there are no memory leaks) is invalidated by a single counter-example (like the valid test). > > Have a nice weekend, I'm off now :) ... as long as the context is *valid" :-) thanks again, have a great weekend! You are right, @kleopatra - this executeOnceWhenPropertyIsNonNull() is installing a listener. perhaps we should add a similar functionality to LambdaMultiplePropertyChangeListenerHandler and actually install a WeakListener instead. Thanks again, @kleopatra With your permission, I'll add tests with and without scene property set. Or do we want to keep the original set? ------------- PR: https://git.openjdk.org/jfx/pull/906 From mstrauss at openjdk.org Mon Oct 3 22:58:05 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 3 Oct 2022 22:58:05 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: On Fri, 30 Sep 2022 16:21:32 GMT, Jeanette Winzenburg wrote: >> Will definitely do! Some tests were failing yesterday, until all is fixed - it's a draft PR :-) >> Thank you so much, @kleopatra > >> Perhaps the test is too artificial, something is not being done correctly or exactly as in the real application? Using StageLoader or showControl() hooks up the missing dependencies. > > one last time: there is _no_ such thing as a "too artificial" test - a class must _always_ fulfil its contract in whatever valid context. It's not enough to do so for some (or even the majority) of use-cases. Plus: logically, any assumption (like: there are no memory leaks) is invalidated by a single counter-example (like the valid test). > > Have a nice weekend, I'm off now :) > You are right, @kleopatra - this executeOnceWhenPropertyIsNonNull() is installing a listener. perhaps we should add a similar functionality to LambdaMultiplePropertyChangeListenerHandler and actually install a WeakListener instead. I'd advise against doing this in an ad-hoc manner. Skins leak memory by adding (but not removing) all kinds of listeners or children to their controls. Some skins try to address this with weak listeners, or by manually removing listeners in the dispose() method. SkinBase attempts to make it easier for skins to not leak listeners with the `registerInvalidationListener` and `registerChangeListener` APIs, which remove an added listener when the skin is disposed (however, both of these methods only accept Consumers, not actual `InvalidationListener`/`ChangeListener` instances, making the API less useful than it could be). But there are more places where memory is leaked: 1. adding, but not removing children to the control 2. adding EventHandlers/EventFilters to the control or to other objects (for example, MenuBarSkin adds EventHandlers to the control's scene) 3. hidden listeners like the one you discovered: Utils.executeOnceWhenPropertyIsNonNull 4. Label.setLabeLFor(control) 5. ListChangeListener, etc. Most skins exhibit one or several of these memory leaks, which causes them to remain strongly referenced by the control even after being disposed. The problem here is that JavaFX doesn't offer good tools and APIs to address these challenges, so it's incredible easy to create a skin that leaks memory. In fact, it's so easy that most built-in skins do it (and these were created by the developers of JavaFX itself, so obviously it's a major problem if even those people get it wrong so often). For me, this is a clear indication that we're dealing with an API problem first and foremost. I think there should be a better API that makes it easy for skins to interact with their associated controls, instead of hand-wiring hundreds of little skin-control dependencies (and sure enough, getting it wrong every so often). ------------- PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Mon Oct 3 23:10:31 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Oct 2022 23:10:31 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: On Mon, 3 Oct 2022 22:54:38 GMT, Michael Strau? wrote: >>> Perhaps the test is too artificial, something is not being done correctly or exactly as in the real application? Using StageLoader or showControl() hooks up the missing dependencies. >> >> one last time: there is _no_ such thing as a "too artificial" test - a class must _always_ fulfil its contract in whatever valid context. It's not enough to do so for some (or even the majority) of use-cases. Plus: logically, any assumption (like: there are no memory leaks) is invalidated by a single counter-example (like the valid test). >> >> Have a nice weekend, I'm off now :) > >> You are right, @kleopatra - this executeOnceWhenPropertyIsNonNull() is installing a listener. perhaps we should add a similar functionality to LambdaMultiplePropertyChangeListenerHandler and actually install a WeakListener instead. > > I'd advise against doing this in an ad-hoc manner. Skins leak memory by adding (but not removing) all kinds of listeners or children to their controls. Some skins try to address this with weak listeners, or by manually removing listeners in the dispose() method. SkinBase attempts to make it easier for skins to not leak listeners with the `registerInvalidationListener` and `registerChangeListener` APIs, which remove an added listener when the skin is disposed (however, both of these methods only accept Consumers, not actual `InvalidationListener`/`ChangeListener` instances, making the API less useful than it could be). > > But there are more places where memory is leaked: > 1. adding, but not removing children to the control > 2. adding EventHandlers/EventFilters to the control or to other objects (for example, MenuBarSkin adds EventHandlers to the control's scene) > 3. hidden listeners like the one you discovered: Utils.executeOnceWhenPropertyIsNonNull > 4. Label.setLabeLFor(control) > 5. ListChangeListener, etc. > > Most skins exhibit one or several of these memory leaks, which causes them to remain strongly referenced by the control even after being disposed. The problem here is that JavaFX doesn't offer good tools and APIs to address these challenges, so it's incredible easy to create a skin that leaks memory. In fact, it's so easy that most built-in skins do it (and these were created by the developers of JavaFX itself, so obviously it's a major problem if even those people get it wrong so often). > > For me, this is a clear indication that we're dealing with an API problem first and foremost. I think there should be a better API that makes it easy for skins to interact with their associated controls, instead of hand-wiring hundreds of little skin-control dependencies (and sure enough, getting it wrong every so often). You are absolutely right! There are so many places where memory leaks are being created. My plan is to go through all the skins and take care of them all. LambdaMultiplePropertyChangeListenerHandler is, I believe, a step in the right direction. I wish there were a more uniform and public way to add various listeners, implemented as a public class - something that can be used to yank all listeners with a single method. I've done something like that on the application level, see https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java What we could do (later) is to keep enhancing LambdaMultiplePropertyChangeListenerHandler by adding more ways of adding listeners, including full-blown change/invalidation listeners, and then rename it, move to a public util package and make it a part of the general purpose API. ------------- PR: https://git.openjdk.org/jfx/pull/906 From mstrauss at openjdk.org Mon Oct 3 23:31:18 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 3 Oct 2022 23:31:18 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: On Mon, 3 Oct 2022 23:07:08 GMT, Andy Goryachev wrote: >>> You are right, @kleopatra - this executeOnceWhenPropertyIsNonNull() is installing a listener. perhaps we should add a similar functionality to LambdaMultiplePropertyChangeListenerHandler and actually install a WeakListener instead. >> >> I'd advise against doing this in an ad-hoc manner. Skins leak memory by adding (but not removing) all kinds of listeners or children to their controls. Some skins try to address this with weak listeners, or by manually removing listeners in the dispose() method. SkinBase attempts to make it easier for skins to not leak listeners with the `registerInvalidationListener` and `registerChangeListener` APIs, which remove an added listener when the skin is disposed (however, both of these methods only accept Consumers, not actual `InvalidationListener`/`ChangeListener` instances, making the API less useful than it could be). >> >> But there are more places where memory is leaked: >> 1. adding, but not removing children to the control >> 2. adding EventHandlers/EventFilters to the control or to other objects (for example, MenuBarSkin adds EventHandlers to the control's scene) >> 3. hidden listeners like the one you discovered: Utils.executeOnceWhenPropertyIsNonNull >> 4. Label.setLabeLFor(control) >> 5. ListChangeListener, etc. >> >> Most skins exhibit one or several of these memory leaks, which causes them to remain strongly referenced by the control even after being disposed. The problem here is that JavaFX doesn't offer good tools and APIs to address these challenges, so it's incredible easy to create a skin that leaks memory. In fact, it's so easy that most built-in skins do it (and these were created by the developers of JavaFX itself, so obviously it's a major problem if even those people get it wrong so often). >> >> For me, this is a clear indication that we're dealing with an API problem first and foremost. I think there should be a better API that makes it easy for skins to interact with their associated controls, instead of hand-wiring hundreds of little skin-control dependencies (and sure enough, getting it wrong every so often). > > You are absolutely right! There are so many places where memory leaks are being created. My plan is to go through all the skins and take care of them all. > > LambdaMultiplePropertyChangeListenerHandler is, I believe, a step in the right direction. I wish there were a more uniform and public way to add various listeners, implemented as a public class - something that can be used to yank all listeners with a single method. > > I've done something like that on the application level, see https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java > > What we could do (later) is to keep enhancing LambdaMultiplePropertyChangeListenerHandler by adding more ways of adding listeners, including full-blown change/invalidation listeners, and then rename it, move to a public util package and make it a part of the general purpose API. Sure, but I think this should be done with a clear vision of where we're going, and not just as a collection of ad-hoc helper methods. There are even more problems that a new API should at least consider: Some skins change their behavior depending on the configuration of their associated control at the time when the skin is installed. For example, `MenuButtonSkinBase` adds a `MOUSE_PRESSED` handler only if the control didn't specify one for its onMousePressed property: if (control.getOnMousePressed() == null) { control.addEventHandler(MouseEvent.MOUSE_PRESSED, ... But what happens if the `onMousePressed` property is set after the skin is installed? Rather than a one-time check, cases like these should probably be a dynamic expression: when control.onMousePressedProperty().isNotNull() and skin.isInstalled() control.addEventHandler otherwise control.removeEventHandler ------------- PR: https://git.openjdk.org/jfx/pull/906 From jvos at openjdk.org Tue Oct 4 09:28:27 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Oct 2022 09:28:27 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 15:58:01 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > 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 20 additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8290844.skin.install > - 8290844: unit tests > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - ... and 10 more: https://git.openjdk.org/jfx/compare/09fb97b3...d954aafc modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 229: > 227: * against this Control, and throw an {@code IllegalArgumentException} if it is not the same. > 228: *

> 229: * A skin may be null. This breaks the 1-1 relationship mentioned above, so it's probably best to mention this as an exception to the 1-1 rule. ------------- PR: https://git.openjdk.org/jfx/pull/845 From jvos at openjdk.org Tue Oct 4 09:40:55 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Oct 2022 09:40:55 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 15:58:01 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > 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 20 additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8290844.skin.install > - 8290844: unit tests > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - ... and 10 more: https://git.openjdk.org/jfx/compare/b96c7ef1...d954aafc modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 83: > 81: * > 82: * @implNote > 83: * Most implementations of Skin in the javafx.controls module If this is only targeting controls in the javafx.controls module, it is not relevant to developers using JavaFX. modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 43: > 41: * It listens and responds to changes in state in a {@code Skinnable}. > 42: *

> 43: * There is typically a one-to-one relationship between a {@code Skinnable} and its The word "typically" doesn't describe when this applies and when not. From the previous comments, I get a better understanding (PopupControl), but developers reading the JavaDoc won't see that. ------------- PR: https://git.openjdk.org/jfx/pull/845 From jvos at openjdk.org Tue Oct 4 09:54:24 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Oct 2022 09:54:24 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Mon, 3 Oct 2022 18:13:25 GMT, Kevin Rushforth wrote: > @johanvos Do you have any thoughts on this enhancement? I'm most interested whether you extend any of the built-in JavaFX skin classes in a way that it might cause problems for you if they move some of their setup code from their constructor to their `install` method? We did a quick internal sanity check, and this won't cause any problems for us. I've read through the comments in the discussions here, and I understand the point "If it ain't broken (badly), don't fix (change) it", but my main thought is that this seems to be our opportunity to fix a design issue. Unless I'm missing something, the refactory efforts for cases that extend build-in skins should be fairly minimal. I added a few comments, mainly related to the javadocs as those should be crystal clear for developers, leaving no room for creative implementations. ------------- PR: https://git.openjdk.org/jfx/pull/845 From hmeda at openjdk.org Tue Oct 4 10:55:37 2022 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 4 Oct 2022 10:55:37 GMT Subject: RFR: 8293795: [Accessibility] [Win] [Narrator] Exceptions when deleting text with continous key press in TextArea and TextField [v3] In-Reply-To: References: Message-ID: On Mon, 3 Oct 2022 14:40:27 GMT, Ambarish Rapte wrote: >> This is a follow up bug-fix to [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281) >> >> Issue: >> When Narrator is running, >> Following scenarios with TextField or TextArea cause IllegalArgumentException or NPE >> >> 1. Move cursor to beginning of line, Press and hold DELETE key >> 2. Move cursor to beginning of line, Press and hold CTRL + DELETE key >> 3. Move cursor to end of line, Press and hold BACKSPACE key >> 4. Move cursor to end of line, Press and hold CTRL + BACKSPACE key >> >> Fix: >> Two variable `start` and `end` in `WinTextRangeProvider` should be validated against text length >> 1. Added a method `validateRange()`, and is called several from methods which access text based on `start` and `end` variables >> 2. Partially reverted fix of [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281) : >> - removed https://github.com/openjdk/jfx/blob/35675c8d27d54a26059b182614e18152794dbcec/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java#L180 >> - and used `validateRange()` instead to be symmetrical. >> >> Verification: >> To observe the issue. >> >> 1. Run any program with TextField and/or TextArea >> 2. Launch Windows Narrator >> 3. Run the exception causing scenarios several times: >> >> - Move cursor to beginning of line, Press and hold DELETE key >> - Move cursor to beginning of line, Press and hold CTRL + DELETE key >> - Move cursor to end of line, Press and hold BACKSPACE key >> - Move cursor to end of line, Press and hold CTRL + BACKSPACE key > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > call validateRange() on line 236-237 Marked as reviewed by hmeda (Author). Exceptions are seen without PR. After applying PR, no exceptions seen. Verified by running the scenarios which cause exceptions. Looks good to me. ------------- PR: https://git.openjdk.org/jfx/pull/907 From arapte at openjdk.org Tue Oct 4 11:09:35 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 4 Oct 2022 11:09:35 GMT Subject: Integrated: 8293795: [Accessibility] [Win] [Narrator] Exceptions when deleting text with continous key press in TextArea and TextField In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 15:15:06 GMT, Ambarish Rapte wrote: > This is a follow up bug-fix to [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281) > > Issue: > When Narrator is running, > Following scenarios with TextField or TextArea cause IllegalArgumentException or NPE > > 1. Move cursor to beginning of line, Press and hold DELETE key > 2. Move cursor to beginning of line, Press and hold CTRL + DELETE key > 3. Move cursor to end of line, Press and hold BACKSPACE key > 4. Move cursor to end of line, Press and hold CTRL + BACKSPACE key > > Fix: > Two variable `start` and `end` in `WinTextRangeProvider` should be validated against text length > 1. Added a method `validateRange()`, and is called several from methods which access text based on `start` and `end` variables > 2. Partially reverted fix of [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281) : > - removed https://github.com/openjdk/jfx/blob/35675c8d27d54a26059b182614e18152794dbcec/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java#L180 > - and used `validateRange()` instead to be symmetrical. > > Verification: > To observe the issue. > > 1. Run any program with TextField and/or TextArea > 2. Launch Windows Narrator > 3. Run the exception causing scenarios several times: > > - Move cursor to beginning of line, Press and hold DELETE key > - Move cursor to beginning of line, Press and hold CTRL + DELETE key > - Move cursor to end of line, Press and hold BACKSPACE key > - Move cursor to end of line, Press and hold CTRL + BACKSPACE key This pull request has now been integrated. Changeset: cc00c8d5 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/cc00c8d5c7a73b9d9bc7c292ad51f8af9e63ff78 Stats: 25 lines in 1 file changed: 15 ins; 5 del; 5 mod 8293795: [Accessibility] [Win] [Narrator] Exceptions when deleting text with continous key press in TextArea and TextField Reviewed-by: kcr, hmeda ------------- PR: https://git.openjdk.org/jfx/pull/907 From fastegal at openjdk.org Tue Oct 4 14:10:28 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 4 Oct 2022 14:10:28 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: On Fri, 30 Sep 2022 16:21:32 GMT, Jeanette Winzenburg wrote: >> Will definitely do! Some tests were failing yesterday, until all is fixed - it's a draft PR :-) >> Thank you so much, @kleopatra > >> Perhaps the test is too artificial, something is not being done correctly or exactly as in the real application? Using StageLoader or showControl() hooks up the missing dependencies. > > one last time: there is _no_ such thing as a "too artificial" test - a class must _always_ fulfil its contract in whatever valid context. It's not enough to do so for some (or even the majority) of use-cases. Plus: logically, any assumption (like: there are no memory leaks) is invalidated by a single counter-example (like the valid test). > > Have a nice weekend, I'm off now :) > Thanks again, @kleopatra With your permission, I'll add tests with and without scene property set. Or do we want to keep the original set? SkinMemoryLeakTest already has both methods, that is testing the replacement of a skin with/out residing in a scene .. no need for adding anything ;) ------------- PR: https://git.openjdk.org/jfx/pull/906 From fastegal at openjdk.org Tue Oct 4 14:24:33 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 4 Oct 2022 14:24:33 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: On Tue, 4 Oct 2022 14:06:59 GMT, Jeanette Winzenburg wrote: >>> Perhaps the test is too artificial, something is not being done correctly or exactly as in the real application? Using StageLoader or showControl() hooks up the missing dependencies. >> >> one last time: there is _no_ such thing as a "too artificial" test - a class must _always_ fulfil its contract in whatever valid context. It's not enough to do so for some (or even the majority) of use-cases. Plus: logically, any assumption (like: there are no memory leaks) is invalidated by a single counter-example (like the valid test). >> >> Have a nice weekend, I'm off now :) > >> Thanks again, @kleopatra With your permission, I'll add tests with and without scene property set. Or do we want to keep the original set? > > SkinMemoryLeakTest already has both methods, that is testing the replacement of a skin with/out residing in a scene .. no need for adding anything ;) > In fact, it's so easy that most built-in skins do it (and these were created by the developers of JavaFX itself, so obviously it's a major problem if even those people get it wrong so often). > well, just guessing games here but: mine is that they didn't put too many thoughts into the possibility of replacing a skin and if they did, they actively prevented it - as seen in the implementation of TextAreaSkin.dispose when we started the current cleanup round: /** {@inheritDoc} */ @Override public void dispose() { super.dispose(); if (behavior != null) { behavior.dispose(); } // TODO Unregister listeners on text editor, paragraph list throw new UnsupportedOperationException(); } ------------- PR: https://git.openjdk.org/jfx/pull/906 From fastegal at openjdk.org Tue Oct 4 14:43:30 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 4 Oct 2022 14:43:30 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: On Tue, 4 Oct 2022 14:20:46 GMT, Jeanette Winzenburg wrote: >>> Thanks again, @kleopatra With your permission, I'll add tests with and without scene property set. Or do we want to keep the original set? >> >> SkinMemoryLeakTest already has both methods, that is testing the replacement of a skin with/out residing in a scene .. no need for adding anything ;) > >> In fact, it's so easy that most built-in skins do it (and these were created by the developers of JavaFX itself, so obviously it's a major problem if even those people get it wrong so often). >> > > well, just guessing games here but: mine is that they didn't put too many thoughts into the possibility of replacing a skin and if they did, they actively prevented it - as seen in the implementation of TextAreaSkin.dispose when we started the current cleanup round: > > /** {@inheritDoc} */ > @Override public void dispose() { > super.dispose(); > > if (behavior != null) { > behavior.dispose(); > } > > // TODO Unregister listeners on text editor, paragraph list > throw new UnsupportedOperationException(); > } > You are right, @kleopatra - this executeOnceWhenPropertyIsNonNull() is installing a listener. perhaps we should add a similar functionality to LambdaMultiplePropertyChangeListenerHandler and actually install a WeakListener instead. - yes, we need weakListeners (to wait for a not-null value to add the event handler) _and_ remove both the weakListener and the event handlers in dispose - adding functionality to the LambdaHandler sounds like a good idea, but needs some thinking and should be done in a separate issue which also adds delegate methods to expose the new functionality in SkinBase for use in sub classes For this issue, you might simply inline the utility method and register the listeners using skinbase api (didn't try, it's your issue :), see TableRowSkin for a similar pattern This conditional adding of handlers/listeners is needed if we have to support path properties (also f.i. when listening to selectedXX in any of the skins with selectionModels as properties). Which basically should be supported by base - but probably without any chance to ever get them ;) ------------- PR: https://git.openjdk.org/jfx/pull/906 From fastegal at openjdk.org Tue Oct 4 14:50:39 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 4 Oct 2022 14:50:39 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: Message-ID: <4EVy11gFJT3NVPQFGKaFH5hwSxko4l_GWENAcEDlDOw=.2002dbda-77b2-494d-8a5f-8611be637769@github.com> On Thu, 29 Sep 2022 23:00:17 GMT, Andy Goryachev wrote: > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LambdaMultiplePropertyChangeListenerHandler.java line 183: > 181: consumer.accept(v); > 182: } > 183: }); beware: unregister removes _all_ listeners (of type InvalidationListener) from the given property ------------- PR: https://git.openjdk.org/jfx/pull/906 From fastegal at openjdk.org Tue Oct 4 15:04:36 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 4 Oct 2022 15:04:36 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: Message-ID: <4dvmWgCoStB1-xT0aVP64ucguT0NN9beUNT2pmAnGq4=.84d58e63-dd3e-4f92-94d2-ddca64db8155@github.com> On Thu, 29 Sep 2022 23:00:17 GMT, Andy Goryachev wrote: > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java line 950: > 948: > 949: getSkinnable().focusedProperty().addListener(weakMenuBarFocusedPropertyListener); > 950: - listeners on skinnable's properties should be installed via skin api - skinnable's properties don't change, so no need to add/remove in rebuild - instead do it once take both with a grain of salt, though, and test if that's really possible :) I think it does - the value is a boolean so the old is always the !current. ------------- PR: https://git.openjdk.org/jfx/pull/906 From fastegal at openjdk.org Tue Oct 4 15:18:35 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 4 Oct 2022 15:18:35 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 23:00:17 GMT, Andy Goryachev wrote: > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java line 328: > 326: mouseEventHandler = t -> { > 327: if (getSkinnable() != null) { > 328: Bounds containerScreenBounds = container.localToScreen(container.getLayoutBounds()); this null check is wrong: skinnable is guaranteed to never be null - except after dispose, at which time it's illegal to access any of the skin's methods/fields/state. So checking here is smearing over a precondition violation of the caller (most probably a dangling handler/listener) which has to be fixed. Note we deliberately removed all null checks in all (cleaned) skins :) If we see any exceptions, the procedure is to - write a test exposing the exception (it's failing), this test belongs into SkinCleanTest - find and fix the violator - see the test passing There might be other exceptions as well (like IOOB or similar) which require a similar procedure, see the available tests. Actually, I think it's a good idea to actively look out for possible macroscopic misbehavior if handlers/listeners are not removed properly. SkinCleanupTest has examples. ------------- PR: https://git.openjdk.org/jfx/pull/906 From kcr at openjdk.org Tue Oct 4 15:22:11 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 4 Oct 2022 15:22:11 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 09:25:00 GMT, Johan Vos 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 20 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into 8290844.skin.install >> - 8290844: unit tests >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - ... and 10 more: https://git.openjdk.org/jfx/compare/b8fb4e8d...d954aafc > > modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 229: > >> 227: * against this Control, and throw an {@code IllegalArgumentException} if it is not the same. >> 228: *

>> 229: * A skin may be null. > > This breaks the 1-1 relationship mentioned above, so it's probably best to mention this as an exception to the 1-1 rule. Maybe something like `will check the return value of {@link Skin#getSkinnable()}, if the Skin is not {@code null}, against this Control...`? > modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 83: > >> 81: * >> 82: * @implNote >> 83: * Most implementations of Skin in the javafx.controls module > > If this is only targeting controls in the javafx.controls module, it is not relevant to developers using JavaFX. It might be best to remove `in the javafx.controls module`, since this advice is relevant for third-party controls as well. > modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 43: > >> 41: * It listens and responds to changes in state in a {@code Skinnable}. >> 42: *

>> 43: * There is typically a one-to-one relationship between a {@code Skinnable} and its > > The word "typically" doesn't describe when this applies and when not. From the previous comments, I get a better understanding (PopupControl), but developers reading the JavaDoc won't see that. Good point. We have a tension between "pure OO" and giving clear advice. In the case of `Skin`, there are only two direct subclasses, so we could call that out here and say that `Control` enforces a 1-to-1 relationship, but `PopupControl` does not. Alternatively, we could change this to say that "Some implementations of Skinnable define a 1-to-1 relationship...". That would key developers to look for that in the the documentation of the implementing class. Which way do you think is best? ------------- PR: https://git.openjdk.org/jfx/pull/845 From fastegal at openjdk.org Tue Oct 4 15:41:37 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 4 Oct 2022 15:41:37 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 15:58:01 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > 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 20 additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8290844.skin.install > - 8290844: unit tests > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - ... and 10 more: https://git.openjdk.org/jfx/compare/37a1855c...d954aafc modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 233: > 231: * @return the skin property for this control > 232: * @throws IllegalArgumentException if {@code skin != null && skin != getSkinnable()} > 233: */ hmm .. shouldn't the condition be `(skin != null && skin.getSkinnable() != Control.this)`? ------------- PR: https://git.openjdk.org/jfx/pull/845 From fastegal at openjdk.org Tue Oct 4 15:44:43 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 4 Oct 2022 15:44:43 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 15:58:01 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > 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 20 additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8290844.skin.install > - 8290844: unit tests > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - ... and 10 more: https://git.openjdk.org/jfx/compare/54bf36d1...d954aafc modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 226: > 224: *

> 225: * To ensure a one-to-one relationship between a {@code Control} and its {@code Skin}, > 226: * {@link Control#setSkin(Skin)} will check the return value of {@link Skin#getSkinnable()} strictly speaking, it's not the method setSkin but the property skin .. ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Tue Oct 4 16:04:38 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 4 Oct 2022 16:04:38 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 15:42:14 GMT, Jeanette Winzenburg 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 20 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into 8290844.skin.install >> - 8290844: unit tests >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - ... and 10 more: https://git.openjdk.org/jfx/compare/d49e0565...d954aafc > > modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 226: > >> 224: *

>> 225: * To ensure a one-to-one relationship between a {@code Control} and its {@code Skin}, >> 226: * {@link Control#setSkin(Skin)} will check the return value of {@link Skin#getSkinnable()} > > strictly speaking, it's not the method setSkin but the property skin .. so maybe `setting the {@link #skinProperty() skin property}`? > modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 233: > >> 231: * @return the skin property for this control >> 232: * @throws IllegalArgumentException if {@code skin != null && skin != getSkinnable()} >> 233: */ > > hmm .. shouldn't the condition be `(skin != null && skin.getSkinnable() != Control.this)`? Oops. My mistake (since Andy copied what I gave him), and good catch. I think the `Control.` is not needed here, since this is the documentation of a property in Control, so maybe just: `(skin != null && skin.getSkinnable() != this)`? ------------- PR: https://git.openjdk.org/jfx/pull/845 From fastegal at openjdk.org Tue Oct 4 16:04:38 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 4 Oct 2022 16:04:38 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 15:58:01 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > 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 20 additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8290844.skin.install > - 8290844: unit tests > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - ... and 10 more: https://git.openjdk.org/jfx/compare/d49e0565...d954aafc modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 43: > 41: *

  • uninstalling of the old skin via its {@link #dispose()} method > 42: *
  • installing of the new skin via {@link #install()} > 43: * - this interface is unrelated to any specific implementation of a Skinnable, at least replace control.setSkin with skinnable.setSkin - technically, it can't be the setSkin method to have any workload (as already discussed and fixed elsewhere) aside from these nit-pickings .. don't we overspecify here (and in the doc of install)? From scratch implementations of a Skinnable/Skin pair might decide to do the complete wiring outside of the property, something like Skinnable skinnable = new .. Skin skin = new ... if (skinnable.getSkin() != null) skinnable.getSkin().dispose(); skin.install(); skinnable.setSkin(skin); ------------- PR: https://git.openjdk.org/jfx/pull/845 From fastegal at openjdk.org Tue Oct 4 16:09:40 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 4 Oct 2022 16:09:40 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 15:58:01 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > 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 20 additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8290844.skin.install > - 8290844: unit tests > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - ... and 10 more: https://git.openjdk.org/jfx/compare/aa698f12...d954aafc modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 90: > 88: */ > 89: default public void install() { } > 90: what about calling install more than once? There are arguments for either: - in symmetry to dispose, it should be allowed - regarding this as an "out-sourced" part of the constructor - to allow/enforce proper cleanup - it shouldn't whatever the decision, it must be specified ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Tue Oct 4 16:22:46 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 4 Oct 2022 16:22:46 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 15:58:43 GMT, Jeanette Winzenburg 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 20 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into 8290844.skin.install >> - 8290844: unit tests >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - ... and 10 more: https://git.openjdk.org/jfx/compare/ae837393...d954aafc > > modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 43: > >> 41: *
  • uninstalling of the old skin via its {@link #dispose()} method >> 42: *
  • installing of the new skin via {@link #install()} >> 43: * > > - this interface is unrelated to any specific implementation of a Skinnable, at least replace control.setSkin with skinnable.setSkin > - technically, it can't be the setSkin method to have any workload (as already discussed and fixed elsewhere) > > aside from these nit-pickings .. don't we overspecify here (and in the doc of install)? From scratch implementations of a Skinnable/Skin pair might decide to do the complete wiring outside of the property, something like > > Skinnable skinnable = new .. > Skin skin = new ... > if (skinnable.getSkin() != null) skinnable.getSkin().dispose(); > skin.install(); > skinnable.setSkin(skin); I don't think we would want to go out of our way to enable this, so I prefer the tighter definition of the life-cycle that Andy is proposing. It seems better to have the Control always call `dispose` and `install` rather than provide an option where the application would call it. ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Tue Oct 4 16:52:44 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 4 Oct 2022 16:52:44 GMT Subject: RFR: 8293444: Creating ScrollPane with same content component causes memory leak [v3] In-Reply-To: <24VyehK8S7W8vjroiKNSkCDCASGMkhy3jLkQ05dMnUo=.e4d2e29b-50f3-4642-8e7f-2379d34fdd17@github.com> References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com> <24VyehK8S7W8vjroiKNSkCDCASGMkhy3jLkQ05dMnUo=.e4d2e29b-50f3-4642-8e7f-2379d34fdd17@github.com> Message-ID: On Wed, 28 Sep 2022 18:02:53 GMT, Andy Goryachev wrote: >> Using Weak*Listeners eliminates the memory leak. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8293444: review comments Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/900 From angorya at openjdk.org Tue Oct 4 18:17:33 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Oct 2022 18:17:33 GMT Subject: Integrated: 8293444: Creating ScrollPane with same content component causes memory leak In-Reply-To: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com> References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com> Message-ID: On Thu, 15 Sep 2022 17:12:14 GMT, Andy Goryachev wrote: > Using Weak*Listeners eliminates the memory leak. This pull request has now been integrated. Changeset: 337c7818 Author: Andy Goryachev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/337c78183be84a3420691f615096b54a68ac4300 Stats: 75 lines in 2 files changed: 66 ins; 0 del; 9 mod 8293444: Creating ScrollPane with same content component causes memory leak Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/900 From angorya at openjdk.org Tue Oct 4 19:11:01 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Oct 2022 19:11:01 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: <32PyeprX3EtYYroMHxUueufQeQ6DuH4SLys4Em_-Ac4=.da2c2f63-2b0c-4181-8846-cc6e76c84be3@github.com> On Tue, 4 Oct 2022 15:06:30 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 229: >> >>> 227: * against this Control, and throw an {@code IllegalArgumentException} if it is not the same. >>> 228: *

    >>> 229: * A skin may be null. >> >> This breaks the 1-1 relationship mentioned above, so it's probably best to mention this as an exception to the 1-1 rule. > > Maybe something like `will check the return value of {@link Skin#getSkinnable()}, if the Skin is not {@code null}, against this Control...`? How about * To ensure a one-to-one relationship between a {@code Skinnable} and its * {@code Skin}, some implementations of {@link Skinnable#setSkin(Skin)} method will check * the return value of {@link Skin#getSkinnable()}, and if it is not {@code null}, compare it * with this Skinnable, throwing an {@code IllegalArgumentException} if it is not the same. >> modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 43: >> >>> 41: * It listens and responds to changes in state in a {@code Skinnable}. >>> 42: *

    >>> 43: * There is typically a one-to-one relationship between a {@code Skinnable} and its >> >> The word "typically" doesn't describe when this applies and when not. From the previous comments, I get a better understanding (PopupControl), but developers reading the JavaDoc won't see that. > > Good point. We have a tension between "pure OO" and giving clear advice. In the case of `Skin`, there are only two direct subclasses, so we could call that out here and say that `Control` enforces a 1-to-1 relationship, but `PopupControl` does not. Alternatively, we could change this to say that "Some implementations of Skinnable define a 1-to-1 relationship...". That would key developers to look for that in the the documentation of the implementing class. > > Which way do you think is best? I like "Some implementations of Skinnable define a 1-to-1 relationship..."... ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Tue Oct 4 19:17:30 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Oct 2022 19:17:30 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: <32PyeprX3EtYYroMHxUueufQeQ6DuH4SLys4Em_-Ac4=.da2c2f63-2b0c-4181-8846-cc6e76c84be3@github.com> References: <32PyeprX3EtYYroMHxUueufQeQ6DuH4SLys4Em_-Ac4=.da2c2f63-2b0c-4181-8846-cc6e76c84be3@github.com> Message-ID: On Tue, 4 Oct 2022 19:08:23 GMT, Andy Goryachev wrote: >> Good point. We have a tension between "pure OO" and giving clear advice. In the case of `Skin`, there are only two direct subclasses, so we could call that out here and say that `Control` enforces a 1-to-1 relationship, but `PopupControl` does not. Alternatively, we could change this to say that "Some implementations of Skinnable define a 1-to-1 relationship...". That would key developers to look for that in the the documentation of the implementing class. >> >> Which way do you think is best? > > I like "Some implementations of Skinnable define a 1-to-1 relationship..."... I re-phrased the javadoc, please see if it's clearer. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Tue Oct 4 19:21:38 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Oct 2022 19:21:38 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 15:54:06 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 233: >> >>> 231: * @return the skin property for this control >>> 232: * @throws IllegalArgumentException if {@code skin != null && skin != getSkinnable()} >>> 233: */ >> >> hmm .. shouldn't the condition be `(skin != null && skin.getSkinnable() != Control.this)`? > > Oops. My mistake (since Andy copied what I gave him), and good catch. I think the `Control.` is not needed here, since this is the documentation of a property in Control, so maybe just: > > `(skin != null && skin.getSkinnable() != this)`? The check is actually inside of a StyleableObjectProperty, so Control.this is appropriate (see line 250), though I think the human-readable explanations in the same javadoc comment might be clear enough (I hope they are clear enough) ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Tue Oct 4 19:27:55 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Oct 2022 19:27:55 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 15:57:28 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 226: >> >>> 224: *

    >>> 225: * To ensure a one-to-one relationship between a {@code Control} and its {@code Skin}, >>> 226: * {@link Control#setSkin(Skin)} will check the return value of {@link Skin#getSkinnable()} >> >> strictly speaking, it's not the method setSkin but the property skin .. > > so maybe `setting the {@link #skinProperty() skin property}`? please check the updated comment, I think it sounds weird... >> modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 43: >> >>> 41: *

  • uninstalling of the old skin via its {@link #dispose()} method >>> 42: *
  • installing of the new skin via {@link #install()} >>> 43: * >> >> - this interface is unrelated to any specific implementation of a Skinnable, at least replace control.setSkin with skinnable.setSkin >> - technically, it can't be the setSkin method to have any workload (as already discussed and fixed elsewhere) >> >> aside from these nit-pickings .. don't we overspecify here (and in the doc of install)? From scratch implementations of a Skinnable/Skin pair might decide to do the complete wiring outside of the property, something like >> >> Skinnable skinnable = new .. >> Skin skin = new ... >> if (skinnable.getSkin() != null) skinnable.getSkin().dispose(); >> skin.install(); >> skinnable.setSkin(skin); > > I don't think we would want to go out of our way to enable this, so I prefer the tighter definition of the life-cycle that Andy is proposing. It seems better to have the Control always call `dispose` and `install` rather than provide an option where the application would call it. I agree with @kevinrushforth , it's one of the cases when the method is public, but it should not be called by an application, only by its Control. Perhaps we should further clarify this fact? ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Tue Oct 4 19:30:55 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Oct 2022 19:30:55 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 16:06:00 GMT, Jeanette Winzenburg 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 20 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into 8290844.skin.install >> - 8290844: unit tests >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - ... and 10 more: https://git.openjdk.org/jfx/compare/74f90618...d954aafc > > modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 90: > >> 88: */ >> 89: default public void install() { } >> 90: > > what about calling install more than once? There are arguments for either: > > - in symmetry to dispose, it should be allowed > - regarding this as an "out-sourced" part of the constructor - to allow/enforce proper cleanup - it shouldn't > > whatever the decision, it must be specified re-phrased the comment, please let me know if the new version is clearer (or suggest an alternative if not). ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Tue Oct 4 19:35:06 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Oct 2022 19:35:06 GMT Subject: RFR: 8290844: Add Skin.install() method [v10] In-Reply-To: References: Message-ID: <38n_zuIaN1Ib0gokKW-r6vvNq5v1olUt5k1tkKPJVQs=.e9d83d7f-8dc4-45de-aad8-abb373908d01@github.com> > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) 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 22 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - 8290844: javadoc - Merge branch 'openjdk:master' into 8290844.skin.install - 8290844: unit tests - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - 8290844: review comments - 8290844: review comments - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - 8290844: review comments - 8290844: review comments - ... and 12 more: https://git.openjdk.org/jfx/compare/9d11e912...6f6b95c0 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/845/files - new: https://git.openjdk.org/jfx/pull/845/files/d954aafc..6f6b95c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=08-09 Stats: 116 lines in 6 files changed: 84 ins; 8 del; 24 mod Patch: https://git.openjdk.org/jfx/pull/845.diff Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845 PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Tue Oct 4 20:19:32 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Oct 2022 20:19:32 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: <4EVy11gFJT3NVPQFGKaFH5hwSxko4l_GWENAcEDlDOw=.2002dbda-77b2-494d-8a5f-8611be637769@github.com> References: <4EVy11gFJT3NVPQFGKaFH5hwSxko4l_GWENAcEDlDOw=.2002dbda-77b2-494d-8a5f-8611be637769@github.com> Message-ID: On Tue, 4 Oct 2022 14:46:38 GMT, Jeanette Winzenburg wrote: >> Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LambdaMultiplePropertyChangeListenerHandler.java line 183: > >> 181: consumer.accept(v); >> 182: } >> 183: }); > > beware: unregister removes _all_ listeners (of type InvalidationListener) from the given property this makes no sense! thank you for pointing it out. perhaps we really *ought to* create a better LambdaMultiplePropertyChangeListenerHandler implementation. ------------- PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Tue Oct 4 20:31:50 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Oct 2022 20:31:50 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: Message-ID: <9mqC_9z2vbBaQ5AOOgcreVkRaRG4aPWOeTYNL9G4HcE=.6c46d4b5-d903-48cd-991f-340e37675188@github.com> On Thu, 29 Sep 2022 23:00:17 GMT, Andy Goryachev wrote: > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). I have a string feeling that this PR should go back to DRAFT state, pending a better listener helper implementation JDK-8294809. Also, this particular skin may need to get it's listeners refactored - I see two scene listeners which seems redundant. ------------- PR: https://git.openjdk.org/jfx/pull/906 From fastegal at openjdk.org Wed Oct 5 11:15:28 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Wed, 5 Oct 2022 11:15:28 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: <4EVy11gFJT3NVPQFGKaFH5hwSxko4l_GWENAcEDlDOw=.2002dbda-77b2-494d-8a5f-8611be637769@github.com> Message-ID: <0vub_5YyoNn-4t_rm-9LHu_RnkzgZAVdcdmgQkFk4bM=.1f1ac0cc-8043-45c7-a25e-9c80f61bc009@github.com> On Tue, 4 Oct 2022 20:15:47 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LambdaMultiplePropertyChangeListenerHandler.java line 183: >> >>> 181: consumer.accept(v); >>> 182: } >>> 183: }); >> >> beware: unregister removes _all_ listeners (of type InvalidationListener) from the given property > > this makes no sense! thank you for pointing it out. > perhaps we really *ought to* create a better LambdaMultiplePropertyChangeListenerHandler implementation. well, it _does_ make sense for listeners registered on properties of the control itself (they don't change and are un/registered once) - and that was it was designed for :) What it can't handle (and was not designed for) are dynamic multiple un/registration of listeners. ------------- PR: https://git.openjdk.org/jfx/pull/906 From fastegal at openjdk.org Wed Oct 5 11:23:35 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Wed, 5 Oct 2022 11:23:35 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: <9mqC_9z2vbBaQ5AOOgcreVkRaRG4aPWOeTYNL9G4HcE=.6c46d4b5-d903-48cd-991f-340e37675188@github.com> References: <9mqC_9z2vbBaQ5AOOgcreVkRaRG4aPWOeTYNL9G4HcE=.6c46d4b5-d903-48cd-991f-340e37675188@github.com> Message-ID: On Tue, 4 Oct 2022 20:29:05 GMT, Andy Goryachev wrote: > I have a string feeling that this PR should go back to DRAFT state, pending a better listener helper implementation JDK-8294809. Also, this particular skin may need to get it's listeners refactored - I see two scene listeners which seems redundant. don't worry: you choose one of the hardest skins to fix as your first - only the comboXX are worse ;) - it has OS-specifics - it needs listeners/handlers on the scene which are very tricky to get right on and off - it's unusual in not having a behavior (that's where the event handlers should reside) - it has nested menus (which are problematic in themselves) - .. probably more :) ------------- PR: https://git.openjdk.org/jfx/pull/906 From fastegal at openjdk.org Wed Oct 5 11:35:38 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Wed, 5 Oct 2022 11:35:38 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: <0vub_5YyoNn-4t_rm-9LHu_RnkzgZAVdcdmgQkFk4bM=.1f1ac0cc-8043-45c7-a25e-9c80f61bc009@github.com> References: <4EVy11gFJT3NVPQFGKaFH5hwSxko4l_GWENAcEDlDOw=.2002dbda-77b2-494d-8a5f-8611be637769@github.com> <0vub_5YyoNn-4t_rm-9LHu_RnkzgZAVdcdmgQkFk4bM=.1f1ac0cc-8043-45c7-a25e-9c80f61bc009@github.com> Message-ID: On Wed, 5 Oct 2022 11:11:46 GMT, Jeanette Winzenburg wrote: >> this makes no sense! thank you for pointing it out. >> perhaps we really *ought to* create a better LambdaMultiplePropertyChangeListenerHandler implementation. > > well, it _does_ make sense for listeners registered on properties of the control itself (they don't change and are un/registered once) - and that was it was designed for :) What it can't handle (and was not designed for) are dynamic multiple un/registration of listeners. btw: the executeOnce pattern is appropriate only if it's guaranteed that the value changes once from null to not-null (not back again) .. which is not the case for the value of a control's scene property - it can change in both directions or not at all (which might be the reason for having added a second listener ;) ------------- PR: https://git.openjdk.org/jfx/pull/906 From fastegal at openjdk.org Wed Oct 5 11:54:24 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Wed, 5 Oct 2022 11:54:24 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 19:24:56 GMT, Andy Goryachev wrote: >> I don't think we would want to go out of our way to enable this, so I prefer the tighter definition of the life-cycle that Andy is proposing. It seems better to have the Control always call `dispose` and `install` rather than provide an option where the application would call it. > > I agree with @kevinrushforth , it's one of the cases when the method is public, but it should not be called by an application, only by its Control. > > Perhaps we should further clarify this fact? Control is _our_ specific implementation - others might differ :) And not talking about application code but a possibly complete skinnable/skin controlling scheme. But I see your point - how can we clearly express that the complete dispose-install cycle should be in the hands of exactly one collaborator (whether a skinnable's property or somewhere else)? The concrete cells have public methods that are marked as "expert api" - maybe we could do something similar here? ------------- PR: https://git.openjdk.org/jfx/pull/845 From fastegal at openjdk.org Wed Oct 5 12:26:23 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Wed, 5 Oct 2022 12:26:23 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 19:27:55 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 90: >> >>> 88: */ >>> 89: default public void install() { } >>> 90: >> >> what about calling install more than once? There are arguments for either: >> >> - in symmetry to dispose, it should be allowed >> - regarding this as an "out-sourced" part of the constructor - to allow/enforce proper cleanup - it shouldn't >> >> whatever the decision, it must be specified > > re-phrased the comment, please let me know if the new version is clearer (or suggest an alternative if not). hmm .. it's still using setSkin :) What about following the lead of dispose doc closely: > Called by Skinnable when the Skin is attached/set (whatever, you are the native speakers ;) to the Skinnable. This method allows a Skin to ... (same as currently) .. > > Must be called exactly once _after_ a previous Skin - if any - is disposed. > > (same as current) > > Still not quite sure the spec is clear enough to express the precondition for this method: in words it's something like "there must not be any other skin with other.getSkinnable() == this.getSkinnable()", that is all other potential skins are disposed - but that sounds a bit unbounded ... Aside: strictly speaking, the dispose doc is over-specified "Called by the Skinnable.." - which is making our own code violating that contract: dispose is called freely from other collaborators, f.i. during auto-sizing of columns, doing layout in VirtualFlow .. just saying :) ------------- PR: https://git.openjdk.org/jfx/pull/845 From fastegal at openjdk.org Wed Oct 5 12:42:38 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Wed, 5 Oct 2022 12:42:38 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 19:22:42 GMT, Andy Goryachev wrote: >> so maybe `setting the {@link #skinProperty() skin property}`? > > please check the updated comment, I think it sounds weird... that change sounds okay to me :) What might be missing is a description of that it actually does, that is taking full control about the old.dispose / new.install sequence as spec'ed in Skin - I think it could be repeated here to emphasize that it's living up to its responsibility. ------------- PR: https://git.openjdk.org/jfx/pull/845 From thiago.sayao at gmail.com Wed Oct 5 20:10:50 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 5 Oct 2022 17:10:50 -0300 Subject: JavaFX 19 Crashes Message-ID: Hi, I'm still experiencing crashes with javafx 19. It happens with openjdk 11.0.16, and it's not reproducible with openjdk 17 (but it does rarely crash). I cannot convince the team that it's not a javafx-19 bug because downgrading back to javafx-16 stops the crash from happening. I can reproduce by selecting an item on a TableView that's inside a Dialog which is called by showAndWait() and pressing ENTER - this triggers the Dialog to close and return the selected item. It does not crash when using the mouse double-click. Oddly enough it does not happen on JavaFX, but this line causes the crash: UUID cdVendaProduto = Generators.timeBasedGenerator().generate(); // https://mvnrepository.com/artifact/com.fasterxml.uuid/java-uuid-generator This line (unrelated to JavaFX) crashes with JavaFX-19 and does not crash with JavaFX-16. I Know this is very odd - and does not seem like a JavaFX bug. Running on IntelliJ idea (CRASHES - note that it adds -XX:TieredStopAtLevel=1 -Xverify:none): Command Line: -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:46069,suspend=y,server=n -Xmx500m -Xms135m -Djava.library.path=./libs/client/linux/x64:./libs/client/linux/x64/tef_simulado:/usr/local/lib -Djavax.net.ssl.trustStore=./configuracoes/cacerts -Djavax.net.ssl.trustStorePassword=changeit -Dsun.awt.disablegrab=true -XX:TieredStopAtLevel=1 -Xverify:none -Dspring.output.ansi.enabled=always -Dcom.sun.management.jmxremote -Dspring.jmx.enabled=true -Dspring.liveBeansView.mbeanDomain -Dspring.application.admin.enabled=true -javaagent:/home/tsayao/idea-IU-212.4746.92/plugins/java/lib/rt/debugger-agent.jar -Dfile.encoding=UTF-8 br.com.clamed.frontend.Launcher Running the jar: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f85cd377a8f, pid=2049284, tid=2049339 # # JRE version: OpenJDK Runtime Environment (11.0.16+8) (build 11.0.16+8-post-Ubuntu-0ubuntu120.04) # Java VM: OpenJDK 64-Bit Server VM (11.0.16+8-post-Ubuntu-0ubuntu120.04, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x5c5a8f] ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/tsayao/IdeaProjects/clamed-sistema-loja/core.2049284) # # If you would like to submit a bug report, please visit: # https://bugs.launchpad.net/ubuntu/+source/openjdk-lts # --------------- S U M M A R Y ------------ Command Line: -Xmx350m -Xms128m -Djava.net.preferIPv4Stack=true -Dsun.awt.disablegrab=true -Djavax.net.ssl.trustStore=./configuracoes/cacerts -Djavax.net.ssl.trustStorePassword=changeit -Djava.library.path=/home/tsayao/IdeaProjects/clamed-sistema-loja/libs/client/linux/x64:/home/tsayao/IdeaProjects/clamed-sistema-loja/libs/client/linux/x64/tef_simulado --add-modules=javafx.controls,javafx.fxml,javafx.web,javafx.swing,javafx.media roda-na-loja/clamed-frontend-loja/target/fl.jar Host: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 8 cores, 7G, Ubuntu 20.04.4 LTS Time: Wed Oct 5 15:31:25 2022 -03 elapsed time: 106.086065 seconds (0d 0h 1m 46s) --------------- T H R E A D --------------- Current thread (0x00007f85980bd800): GCTaskThread "GC Thread#3" [stack: 0x00007f85073a0000,0x00007f85074a0000] [id=2049339] Stack: [0x00007f85073a0000,0x00007f85074a0000], sp=0x00007f850749ead0, free space=1018k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x5c5a8f] ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f V [libjvm.so+0x793999] G1CLDScanClosure::do_cld(ClassLoaderData*)+0x39 V [libjvm.so+0x5c8371] ClassLoaderDataGraph::roots_cld_do(CLDClosure*, CLDClosure*)+0x41 V [libjvm.so+0x7b382b] G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*, unsigned int)+0x6b V [libjvm.so+0x7b3ebb] G1RootProcessor::evacuate_roots(G1ParScanThreadState*, unsigned int)+0x6b V [libjvm.so+0x75b5dc] G1ParTask::work(unsigned int)+0xec V [libjvm.so+0xec387d] GangWorker::loop()+0x4d V [libjvm.so+0xe2a0f0] Thread::call_run()+0x140 V [libjvm.so+0xbe7c6e] thread_native_entry(Thread*)+0xee -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Thu Oct 6 18:09:27 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 6 Oct 2022 15:09:27 -0300 Subject: JavaFX 19 Crashes In-Reply-To: References: Message-ID: Hi, I found the offensor: https://github.com/openjdk/jfx/pull/598 Reverting this patch stops the crash with java11. It does not make any sense to me. Em qua., 5 de out. de 2022 ?s 17:10, Thiago Milczarek Say?o < thiago.sayao at gmail.com> escreveu: > Hi, > > I'm still experiencing crashes with javafx 19. > > It happens with openjdk 11.0.16, and it's not reproducible with openjdk 17 > (but it does rarely crash). > > I cannot convince the team that it's not a javafx-19 bug because > downgrading back to javafx-16 stops the crash from happening. > > I can reproduce by selecting an item on a TableView that's inside a Dialog > which is called by showAndWait() and pressing ENTER > - this triggers the Dialog to close and return the selected item. It does > not crash when using the mouse double-click. > > Oddly enough it does not happen on JavaFX, but this line causes the crash: > > UUID cdVendaProduto = Generators.timeBasedGenerator().generate(); // > https://mvnrepository.com/artifact/com.fasterxml.uuid/java-uuid-generator > > This line (unrelated to JavaFX) crashes with JavaFX-19 and does not crash > with JavaFX-16. > > I Know this is very odd - and does not seem like a JavaFX bug. > > Running on IntelliJ idea (CRASHES - note that it adds > -XX:TieredStopAtLevel=1 -Xverify:none): > Command Line: -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:46069,suspend=y,server=n > -Xmx500m -Xms135m > -Djava.library.path=./libs/client/linux/x64:./libs/client/linux/x64/tef_simulado:/usr/local/lib > -Djavax.net.ssl.trustStore=./configuracoes/cacerts > -Djavax.net.ssl.trustStorePassword=changeit -Dsun.awt.disablegrab=true > -XX:TieredStopAtLevel=1 -Xverify:none -Dspring.output.ansi.enabled=always > -Dcom.sun.management.jmxremote -Dspring.jmx.enabled=true > -Dspring.liveBeansView.mbeanDomain -Dspring.application.admin.enabled=true > -javaagent:/home/tsayao/idea-IU-212.4746.92/plugins/java/lib/rt/debugger-agent.jar > -Dfile.encoding=UTF-8 br.com.clamed.frontend.Launcher > > Running the jar: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007f85cd377a8f, pid=2049284, tid=2049339 > # > # JRE version: OpenJDK Runtime Environment (11.0.16+8) (build > 11.0.16+8-post-Ubuntu-0ubuntu120.04) > # Java VM: OpenJDK 64-Bit Server VM (11.0.16+8-post-Ubuntu-0ubuntu120.04, > mixed mode, tiered, compressed oops, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x5c5a8f] > ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f > # > # Core dump will be written. Default location: Core dumps may be processed > with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" > (or dumping to /home/tsayao/IdeaProjects/clamed-sistema-loja/core.2049284) > # > # If you would like to submit a bug report, please visit: > # https://bugs.launchpad.net/ubuntu/+source/openjdk-lts > # > > --------------- S U M M A R Y ------------ > > Command Line: -Xmx350m -Xms128m -Djava.net.preferIPv4Stack=true > -Dsun.awt.disablegrab=true > -Djavax.net.ssl.trustStore=./configuracoes/cacerts > -Djavax.net.ssl.trustStorePassword=changeit > -Djava.library.path=/home/tsayao/IdeaProjects/clamed-sistema-loja/libs/client/linux/x64:/home/tsayao/IdeaProjects/clamed-sistema-loja/libs/client/linux/x64/tef_simulado > --add-modules=javafx.controls,javafx.fxml,javafx.web,javafx.swing,javafx.media > roda-na-loja/clamed-frontend-loja/target/fl.jar > > Host: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 8 cores, 7G, Ubuntu 20.04.4 > LTS > Time: Wed Oct 5 15:31:25 2022 -03 elapsed time: 106.086065 seconds (0d 0h > 1m 46s) > > --------------- T H R E A D --------------- > > Current thread (0x00007f85980bd800): GCTaskThread "GC Thread#3" [stack: > 0x00007f85073a0000,0x00007f85074a0000] [id=2049339] > > Stack: [0x00007f85073a0000,0x00007f85074a0000], sp=0x00007f850749ead0, > free space=1018k > Native frames: (J=compiled Java code, A=aot compiled Java code, > j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x5c5a8f] > ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f > V [libjvm.so+0x793999] G1CLDScanClosure::do_cld(ClassLoaderData*)+0x39 > V [libjvm.so+0x5c8371] ClassLoaderDataGraph::roots_cld_do(CLDClosure*, > CLDClosure*)+0x41 > V [libjvm.so+0x7b382b] > G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*, > unsigned int)+0x6b > V [libjvm.so+0x7b3ebb] > G1RootProcessor::evacuate_roots(G1ParScanThreadState*, unsigned int)+0x6b > V [libjvm.so+0x75b5dc] G1ParTask::work(unsigned int)+0xec > V [libjvm.so+0xec387d] GangWorker::loop()+0x4d > V [libjvm.so+0xe2a0f0] Thread::call_run()+0x140 > V [libjvm.so+0xbe7c6e] thread_native_entry(Thread*)+0xee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.vos at gluonhq.com Thu Oct 6 18:29:52 2022 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 6 Oct 2022 20:29:52 +0200 Subject: JavaFX 19 Crashes In-Reply-To: References: Message-ID: That is a bit unexpected indeed, but not totally. We know that there are things in the glass-gtk code that are subject to improvement. To me, this seems one more reason to pick up the work you started on https://github.com/openjdk/jfx/pull/367 -- I'm willing to help with this. - Johan On Thu, Oct 6, 2022 at 8:11 PM Thiago Milczarek Say?o < thiago.sayao at gmail.com> wrote: > Hi, > > I found the offensor: > https://github.com/openjdk/jfx/pull/598 > > Reverting this patch stops the crash with java11. > > It does not make any sense to me. > > > > Em qua., 5 de out. de 2022 ?s 17:10, Thiago Milczarek Say?o < > thiago.sayao at gmail.com> escreveu: > >> Hi, >> >> I'm still experiencing crashes with javafx 19. >> >> It happens with openjdk 11.0.16, and it's not reproducible with openjdk >> 17 (but it does rarely crash). >> >> I cannot convince the team that it's not a javafx-19 bug because >> downgrading back to javafx-16 stops the crash from happening. >> >> I can reproduce by selecting an item on a TableView that's inside a >> Dialog which is called by showAndWait() and pressing ENTER >> - this triggers the Dialog to close and return the selected item. It >> does not crash when using the mouse double-click. >> >> Oddly enough it does not happen on JavaFX, but this line causes the crash: >> >> UUID cdVendaProduto = Generators.timeBasedGenerator().generate(); // >> https://mvnrepository.com/artifact/com.fasterxml.uuid/java-uuid-generator >> >> This line (unrelated to JavaFX) crashes with JavaFX-19 and does not crash >> with JavaFX-16. >> >> I Know this is very odd - and does not seem like a JavaFX bug. >> >> Running on IntelliJ idea (CRASHES - note that it adds >> -XX:TieredStopAtLevel=1 -Xverify:none): >> Command Line: -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:46069,suspend=y,server=n >> -Xmx500m -Xms135m >> -Djava.library.path=./libs/client/linux/x64:./libs/client/linux/x64/tef_simulado:/usr/local/lib >> -Djavax.net.ssl.trustStore=./configuracoes/cacerts >> -Djavax.net.ssl.trustStorePassword=changeit -Dsun.awt.disablegrab=true >> -XX:TieredStopAtLevel=1 -Xverify:none -Dspring.output.ansi.enabled=always >> -Dcom.sun.management.jmxremote -Dspring.jmx.enabled=true >> -Dspring.liveBeansView.mbeanDomain -Dspring.application.admin.enabled=true >> -javaagent:/home/tsayao/idea-IU-212.4746.92/plugins/java/lib/rt/debugger-agent.jar >> -Dfile.encoding=UTF-8 br.com.clamed.frontend.Launcher >> >> Running the jar: >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x00007f85cd377a8f, pid=2049284, tid=2049339 >> # >> # JRE version: OpenJDK Runtime Environment (11.0.16+8) (build >> 11.0.16+8-post-Ubuntu-0ubuntu120.04) >> # Java VM: OpenJDK 64-Bit Server VM (11.0.16+8-post-Ubuntu-0ubuntu120.04, >> mixed mode, tiered, compressed oops, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x5c5a8f] >> ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f >> # >> # Core dump will be written. Default location: Core dumps may be >> processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g >> -- %E" (or dumping to >> /home/tsayao/IdeaProjects/clamed-sistema-loja/core.2049284) >> # >> # If you would like to submit a bug report, please visit: >> # https://bugs.launchpad.net/ubuntu/+source/openjdk-lts >> # >> >> --------------- S U M M A R Y ------------ >> >> Command Line: -Xmx350m -Xms128m -Djava.net.preferIPv4Stack=true >> -Dsun.awt.disablegrab=true >> -Djavax.net.ssl.trustStore=./configuracoes/cacerts >> -Djavax.net.ssl.trustStorePassword=changeit >> -Djava.library.path=/home/tsayao/IdeaProjects/clamed-sistema-loja/libs/client/linux/x64:/home/tsayao/IdeaProjects/clamed-sistema-loja/libs/client/linux/x64/tef_simulado >> --add-modules=javafx.controls,javafx.fxml,javafx.web,javafx.swing,javafx.media >> roda-na-loja/clamed-frontend-loja/target/fl.jar >> >> Host: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 8 cores, 7G, Ubuntu >> 20.04.4 LTS >> Time: Wed Oct 5 15:31:25 2022 -03 elapsed time: 106.086065 seconds (0d >> 0h 1m 46s) >> >> --------------- T H R E A D --------------- >> >> Current thread (0x00007f85980bd800): GCTaskThread "GC Thread#3" [stack: >> 0x00007f85073a0000,0x00007f85074a0000] [id=2049339] >> >> Stack: [0x00007f85073a0000,0x00007f85074a0000], sp=0x00007f850749ead0, >> free space=1018k >> Native frames: (J=compiled Java code, A=aot compiled Java code, >> j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x5c5a8f] >> ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f >> V [libjvm.so+0x793999] G1CLDScanClosure::do_cld(ClassLoaderData*)+0x39 >> V [libjvm.so+0x5c8371] ClassLoaderDataGraph::roots_cld_do(CLDClosure*, >> CLDClosure*)+0x41 >> V [libjvm.so+0x7b382b] >> G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*, >> unsigned int)+0x6b >> V [libjvm.so+0x7b3ebb] >> G1RootProcessor::evacuate_roots(G1ParScanThreadState*, unsigned int)+0x6b >> V [libjvm.so+0x75b5dc] G1ParTask::work(unsigned int)+0xec >> V [libjvm.so+0xec387d] GangWorker::loop()+0x4d >> V [libjvm.so+0xe2a0f0] Thread::call_run()+0x140 >> V [libjvm.so+0xbe7c6e] thread_native_entry(Thread*)+0xee >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Fri Oct 7 01:22:13 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 6 Oct 2022 18:22:13 -0700 Subject: JavaFX 19 Crashes In-Reply-To: References: Message-ID: That seems odd, since it looks like a hotspot bug to me. It isn't 100% out of the question that something changed by that patch is causing a memory corruption problem, but it's a very simple patch, and I can't see anything in it that would explain this. Most likely, this is a hotspot problem that is just being provoked, possibly one that has been fixed. Have you tried it with JDK 19? -- Kevin On 10/6/2022 11:29 AM, Johan Vos wrote: > That is a bit unexpected indeed, but not totally. We know that there > are things in the glass-gtk code that are subject to improvement. To > me, this seems one more reason to pick up the work you started on > https://github.com/openjdk/jfx/pull/367 -- I'm willing to help with this. > > - Johan > > On Thu, Oct 6, 2022 at 8:11 PM Thiago Milczarek Say?o > wrote: > > Hi, > > I found the offensor: > https://github.com/openjdk/jfx/pull/598 > > Reverting this patch stops the crash with java11. > > It does not make any sense to me. > > > > Em qua., 5 de out. de 2022 ?s 17:10, Thiago Milczarek Say?o > escreveu: > > Hi, > > I'm still experiencing crashes with javafx 19. > > It happens with openjdk 11.0.16, and it's not reproducible > with openjdk 17 (but it does rarely crash). > > I cannot convince the team that it's not a javafx-19 bug > because downgrading back to javafx-16 stops the crash from > happening. > > I can reproduce by selecting an item on a TableView that's > inside a Dialog which is called by showAndWait() and pressing > ENTER > ?- this triggers the Dialog to close and return the selected > item. It does not crash when using the mouse double-click. > > Oddly enough it does not happen on JavaFX, but this line > causes the crash: > > UUID cdVendaProduto = > Generators.timeBasedGenerator().generate(); > //https://mvnrepository.com/artifact/com.fasterxml.uuid/java-uuid-generator > > This line (unrelated to JavaFX) crashes with JavaFX-19 and > does not crash with JavaFX-16. > > I Know this is very odd - and does not seem like a JavaFX bug. > > Running on IntelliJ idea (CRASHES - note that it adds > -XX:TieredStopAtLevel=1 -Xverify:none): > Command Line: > -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:46069 > ,suspend=y,server=n -Xmx500m -Xms135m > -Djava.library.path=./libs/client/linux/x64:./libs/client/linux/x64/tef_simulado:/usr/local/lib > -Djavax.net.ssl.trustStore=./configuracoes/cacerts > -Djavax.net.ssl.trustStorePassword=changeit > -Dsun.awt.disablegrab=true -XX:TieredStopAtLevel=1 > -Xverify:none -Dspring.output.ansi.enabled=always > -Dcom.sun.management.jmxremote -Dspring.jmx.enabled=true > -Dspring.liveBeansView.mbeanDomain > -Dspring.application.admin.enabled=true > -javaagent:/home/tsayao/idea-IU-212.4746.92/plugins/java/lib/rt/debugger-agent.jar > -Dfile.encoding=UTF-8 br.com.clamed.frontend.Launcher > > Running?the jar: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # ?SIGSEGV (0xb) at pc=0x00007f85cd377a8f, pid=2049284, > tid=2049339 > # > # JRE version: OpenJDK Runtime Environment (11.0.16+8) (build > 11.0.16+8-post-Ubuntu-0ubuntu120.04) > # Java VM: OpenJDK 64-Bit Server VM > (11.0.16+8-post-Ubuntu-0ubuntu120.04, mixed mode, tiered, > compressed oops, g1 gc, linux-amd64) > # Problematic frame: > # V ?[libjvm.so+0x5c5a8f] > ?ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f > # > # Core dump will be written. Default location: Core dumps may > be processed with "/usr/share/apport/apport -p%p -s%s -c%c > -d%d -P%P -u%u -g%g -- %E" (or dumping to > /home/tsayao/IdeaProjects/clamed-sistema-loja/core.2049284) > # > # If you would like to submit a bug report, please visit: > # https://bugs.launchpad.net/ubuntu/+source/openjdk-lts > # > > --------------- ?S U M M A R Y ------------ > > Command Line: -Xmx350m -Xms128m > -Djava.net.preferIPv4Stack=true -Dsun.awt.disablegrab=true > -Djavax.net.ssl.trustStore=./configuracoes/cacerts > -Djavax.net.ssl.trustStorePassword=changeit > -Djava.library.path=/home/tsayao/IdeaProjects/clamed-sistema-loja/libs/client/linux/x64:/home/tsayao/IdeaProjects/clamed-sistema-loja/libs/client/linux/x64/tef_simulado > --add-modules=javafx.controls,javafx.fxml,javafx.web,javafx.swing,javafx.media > roda-na-loja/clamed-frontend-loja/target/fl.jar > > Host: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 8 cores, 7G, > Ubuntu 20.04.4 LTS > Time: Wed Oct ?5 15:31:25 2022 -03 elapsed time: 106.086065 > seconds (0d 0h 1m 46s) > > --------------- ?T H R E A D ?--------------- > > Current thread (0x00007f85980bd800): ?GCTaskThread "GC > Thread#3" [stack: 0x00007f85073a0000,0x00007f85074a0000] > [id=2049339] > > Stack: [0x00007f85073a0000,0x00007f85074a0000], > ?sp=0x00007f850749ead0, ?free space=1018k > Native frames: (J=compiled Java code, A=aot compiled Java > code, j=interpreted, Vv=VM code, C=native code) > V ?[libjvm.so+0x5c5a8f] > ?ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f > V ?[libjvm.so+0x793999] > ?G1CLDScanClosure::do_cld(ClassLoaderData*)+0x39 > V ?[libjvm.so+0x5c8371] > ?ClassLoaderDataGraph::roots_cld_do(CLDClosure*, CLDClosure*)+0x41 > V ?[libjvm.so+0x7b382b] > ?G1RootProcessor::process_java_roots(G1RootClosures*, > G1GCPhaseTimes*, unsigned int)+0x6b > V ?[libjvm.so+0x7b3ebb] > ?G1RootProcessor::evacuate_roots(G1ParScanThreadState*, > unsigned int)+0x6b > V ?[libjvm.so+0x75b5dc] ?G1ParTask::work(unsigned int)+0xec > V ?[libjvm.so+0xec387d] ?GangWorker::loop()+0x4d > V ?[libjvm.so+0xe2a0f0] ?Thread::call_run()+0x140 > V ?[libjvm.so+0xbe7c6e] ?thread_native_entry(Thread*)+0xee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aghaisas at openjdk.org Fri Oct 7 05:53:34 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 7 Oct 2022 05:53:34 GMT Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode [v13] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 19:07:26 GMT, Andy Goryachev wrote: >> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled. >> >> Changes: >> - modified TreeTableRow.updateSelection() > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8292353: review comments Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/875 From thiago.sayao at gmail.com Fri Oct 7 12:59:49 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 7 Oct 2022 09:59:49 -0300 Subject: JavaFX 19 Crashes In-Reply-To: References: Message-ID: This specific crash (that I can always reproduce with java-11) does not happen with java-17. Java 17: openjdk 17.0.4 2022-07-19 OpenJDK Runtime Environment (build 17.0.4+8-Ubuntu-120.04) OpenJDK 64-Bit Server VM (build 17.0.4+8-Ubuntu-120.04, mixed mode, sharing) Java 11: openjdk 11.0.16 2022-07-19 OpenJDK Runtime Environment (build 11.0.16+8-post-Ubuntu-0ubuntu120.04) OpenJDK 64-Bit Server VM (build 11.0.16+8-post-Ubuntu-0ubuntu120.04, mixed mode, sharing) Em qui., 6 de out. de 2022 ?s 22:22, Kevin Rushforth < kevin.rushforth at oracle.com> escreveu: > That seems odd, since it looks like a hotspot bug to me. It isn't 100% out > of the question that something changed by that patch is causing a memory > corruption problem, but it's a very simple patch, and I can't see anything > in it that would explain this. Most likely, this is a hotspot problem that > is just being provoked, possibly one that has been fixed. Have you tried it > with JDK 19? > > -- Kevin > > > On 10/6/2022 11:29 AM, Johan Vos wrote: > > That is a bit unexpected indeed, but not totally. We know that there are > things in the glass-gtk code that are subject to improvement. To me, this > seems one more reason to pick up the work you started on > https://github.com/openjdk/jfx/pull/367 -- I'm willing to help with this. > > - Johan > > On Thu, Oct 6, 2022 at 8:11 PM Thiago Milczarek Say?o < > thiago.sayao at gmail.com> wrote: > >> Hi, >> >> I found the offensor: >> https://github.com/openjdk/jfx/pull/598 >> >> Reverting this patch stops the crash with java11. >> >> It does not make any sense to me. >> >> >> >> Em qua., 5 de out. de 2022 ?s 17:10, Thiago Milczarek Say?o < >> thiago.sayao at gmail.com> escreveu: >> >>> Hi, >>> >>> I'm still experiencing crashes with javafx 19. >>> >>> It happens with openjdk 11.0.16, and it's not reproducible with openjdk >>> 17 (but it does rarely crash). >>> >>> I cannot convince the team that it's not a javafx-19 bug because >>> downgrading back to javafx-16 stops the crash from happening. >>> >>> I can reproduce by selecting an item on a TableView that's inside a >>> Dialog which is called by showAndWait() and pressing ENTER >>> - this triggers the Dialog to close and return the selected item. It >>> does not crash when using the mouse double-click. >>> >>> Oddly enough it does not happen on JavaFX, but this line causes the >>> crash: >>> >>> UUID cdVendaProduto = Generators.timeBasedGenerator().generate(); // >>> https://mvnrepository.com/artifact/com.fasterxml.uuid/java-uuid-generator >>> >>> This line (unrelated to JavaFX) crashes with JavaFX-19 and does not >>> crash with JavaFX-16. >>> >>> I Know this is very odd - and does not seem like a JavaFX bug. >>> >>> Running on IntelliJ idea (CRASHES - note that it adds >>> -XX:TieredStopAtLevel=1 -Xverify:none): >>> Command Line: -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:46069,suspend=y,server=n >>> -Xmx500m -Xms135m >>> -Djava.library.path=./libs/client/linux/x64:./libs/client/linux/x64/tef_simulado:/usr/local/lib >>> -Djavax.net.ssl.trustStore=./configuracoes/cacerts >>> -Djavax.net.ssl.trustStorePassword=changeit -Dsun.awt.disablegrab=true >>> -XX:TieredStopAtLevel=1 -Xverify:none -Dspring.output.ansi.enabled=always >>> -Dcom.sun.management.jmxremote -Dspring.jmx.enabled=true >>> -Dspring.liveBeansView.mbeanDomain -Dspring.application.admin.enabled=true >>> -javaagent:/home/tsayao/idea-IU-212.4746.92/plugins/java/lib/rt/debugger-agent.jar >>> -Dfile.encoding=UTF-8 br.com.clamed.frontend.Launcher >>> >>> Running the jar: >>> >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # SIGSEGV (0xb) at pc=0x00007f85cd377a8f, pid=2049284, tid=2049339 >>> # >>> # JRE version: OpenJDK Runtime Environment (11.0.16+8) (build >>> 11.0.16+8-post-Ubuntu-0ubuntu120.04) >>> # Java VM: OpenJDK 64-Bit Server VM >>> (11.0.16+8-post-Ubuntu-0ubuntu120.04, mixed mode, tiered, compressed oops, >>> g1 gc, linux-amd64) >>> # Problematic frame: >>> # V [libjvm.so+0x5c5a8f] >>> ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f >>> # >>> # Core dump will be written. Default location: Core dumps may be >>> processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g >>> -- %E" (or dumping to >>> /home/tsayao/IdeaProjects/clamed-sistema-loja/core.2049284) >>> # >>> # If you would like to submit a bug report, please visit: >>> # https://bugs.launchpad.net/ubuntu/+source/openjdk-lts >>> # >>> >>> --------------- S U M M A R Y ------------ >>> >>> Command Line: -Xmx350m -Xms128m -Djava.net.preferIPv4Stack=true >>> -Dsun.awt.disablegrab=true >>> -Djavax.net.ssl.trustStore=./configuracoes/cacerts >>> -Djavax.net.ssl.trustStorePassword=changeit >>> -Djava.library.path=/home/tsayao/IdeaProjects/clamed-sistema-loja/libs/client/linux/x64:/home/tsayao/IdeaProjects/clamed-sistema-loja/libs/client/linux/x64/tef_simulado >>> --add-modules=javafx.controls,javafx.fxml,javafx.web,javafx.swing,javafx.media >>> roda-na-loja/clamed-frontend-loja/target/fl.jar >>> >>> Host: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 8 cores, 7G, Ubuntu >>> 20.04.4 LTS >>> Time: Wed Oct 5 15:31:25 2022 -03 elapsed time: 106.086065 seconds (0d >>> 0h 1m 46s) >>> >>> --------------- T H R E A D --------------- >>> >>> Current thread (0x00007f85980bd800): GCTaskThread "GC Thread#3" [stack: >>> 0x00007f85073a0000,0x00007f85074a0000] [id=2049339] >>> >>> Stack: [0x00007f85073a0000,0x00007f85074a0000], sp=0x00007f850749ead0, >>> free space=1018k >>> Native frames: (J=compiled Java code, A=aot compiled Java code, >>> j=interpreted, Vv=VM code, C=native code) >>> V [libjvm.so+0x5c5a8f] >>> ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f >>> V [libjvm.so+0x793999] G1CLDScanClosure::do_cld(ClassLoaderData*)+0x39 >>> V [libjvm.so+0x5c8371] ClassLoaderDataGraph::roots_cld_do(CLDClosure*, >>> CLDClosure*)+0x41 >>> V [libjvm.so+0x7b382b] >>> G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*, >>> unsigned int)+0x6b >>> V [libjvm.so+0x7b3ebb] >>> G1RootProcessor::evacuate_roots(G1ParScanThreadState*, unsigned int)+0x6b >>> V [libjvm.so+0x75b5dc] G1ParTask::work(unsigned int)+0xec >>> V [libjvm.so+0xec387d] GangWorker::loop()+0x4d >>> V [libjvm.so+0xe2a0f0] Thread::call_run()+0x140 >>> V [libjvm.so+0xbe7c6e] thread_native_entry(Thread*)+0xee >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Fri Oct 7 13:32:32 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 7 Oct 2022 06:32:32 -0700 Subject: [External] : Re: JavaFX 19 Crashes In-Reply-To: References: Message-ID: <43b4b868-9057-fe13-0469-7e5e64c22cd8@oracle.com> That's another indicator that this is likely a hotspot bug -- possibly one that has been fixed, but not backported to 11.x. Btw, if this is the case, it will no longer happen with JavaFX 20, since JavaFX 20 requires JDK 17 or later. -- Kevin On 10/7/2022 5:59 AM, Thiago Milczarek Say?o wrote: > This specific crash (that I can always reproduce with java-11) does > not happen with java-17. > > Java 17: > openjdk 17.0.4 2022-07-19 > OpenJDK Runtime Environment (build 17.0.4+8-Ubuntu-120.04) > OpenJDK 64-Bit Server VM (build 17.0.4+8-Ubuntu-120.04, mixed mode, > sharing) > > Java 11: > openjdk 11.0.16 2022-07-19 > OpenJDK Runtime Environment (build 11.0.16+8-post-Ubuntu-0ubuntu120.04) > OpenJDK 64-Bit Server VM (build 11.0.16+8-post-Ubuntu-0ubuntu120.04, > mixed mode, sharing) > > Em qui., 6 de out. de 2022 ?s 22:22, Kevin Rushforth > escreveu: > > That seems odd, since it looks like a hotspot bug to me. It isn't > 100% out of the question that something changed by that patch is > causing a memory corruption problem, but it's a very simple patch, > and I can't see anything in it that would explain this. Most > likely, this is a hotspot problem that is just being provoked, > possibly one that has been fixed. Have you tried it with JDK 19? > > -- Kevin > > > On 10/6/2022 11:29 AM, Johan Vos wrote: >> That is a bit unexpected indeed, but not totally. We know that >> there are things in the glass-gtk code that are subject to >> improvement. To me, this seems one more reason to pick up the >> work you started on https://github.com/openjdk/jfx/pull/367 >> >> -- I'm willing to help with this. >> >> - Johan >> >> On Thu, Oct 6, 2022 at 8:11 PM Thiago Milczarek Say?o >> wrote: >> >> Hi, >> >> I found the offensor: >> https://github.com/openjdk/jfx/pull/598 >> >> >> Reverting this patch stops the crash with java11. >> >> It does not make any sense to me. >> >> >> >> Em qua., 5 de out. de 2022 ?s 17:10, Thiago Milczarek Say?o >> escreveu: >> >> Hi, >> >> I'm still experiencing crashes with javafx 19. >> >> It happens with openjdk 11.0.16, and it's not >> reproducible with openjdk 17 (but it does rarely crash). >> >> I cannot convince the team that it's not a javafx-19 bug >> because downgrading back to javafx-16 stops the crash >> from happening. >> >> I can reproduce by selecting an item on a TableView >> that's inside a Dialog which is called by showAndWait() >> and pressing ENTER >> ?- this triggers the Dialog to close and return the >> selected item. It does not crash when using the mouse >> double-click. >> >> Oddly enough it does not happen on JavaFX, but this line >> causes the crash: >> >> UUID cdVendaProduto = >> Generators.timeBasedGenerator().generate(); >> //https://mvnrepository.com/artifact/com.fasterxml.uuid/java-uuid-generator >> >> >> This line (unrelated to JavaFX) crashes with JavaFX-19 >> and does not crash with JavaFX-16. >> >> I Know this is very odd - and does not seem like a JavaFX >> bug. >> >> Running on IntelliJ idea (CRASHES - note that it adds >> -XX:TieredStopAtLevel=1 -Xverify:none): >> Command Line: >> -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:46069 >> ,suspend=y,server=n >> -Xmx500m -Xms135m >> -Djava.library.path=./libs/client/linux/x64:./libs/client/linux/x64/tef_simulado:/usr/local/lib >> -Djavax.net.ssl.trustStore=./configuracoes/cacerts >> -Djavax.net.ssl.trustStorePassword=changeit >> -Dsun.awt.disablegrab=true -XX:TieredStopAtLevel=1 >> -Xverify:none -Dspring.output.ansi.enabled=always >> -Dcom.sun.management.jmxremote -Dspring.jmx.enabled=true >> -Dspring.liveBeansView.mbeanDomain >> -Dspring.application.admin.enabled=true >> -javaagent:/home/tsayao/idea-IU-212.4746.92/plugins/java/lib/rt/debugger-agent.jar >> -Dfile.encoding=UTF-8 br.com.clamed.frontend.Launcher >> >> Running?the jar: >> >> # >> # A fatal error has been detected by the Java Runtime >> Environment: >> # >> # ?SIGSEGV (0xb) at pc=0x00007f85cd377a8f, pid=2049284, >> tid=2049339 >> # >> # JRE version: OpenJDK Runtime Environment (11.0.16+8) >> (build 11.0.16+8-post-Ubuntu-0ubuntu120.04) >> # Java VM: OpenJDK 64-Bit Server VM >> (11.0.16+8-post-Ubuntu-0ubuntu120.04, mixed mode, tiered, >> compressed oops, g1 gc, linux-amd64) >> # Problematic frame: >> # V ?[libjvm.so+0x5c5a8f] >> ?ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f >> # >> # Core dump will be written. Default location: Core dumps >> may be processed with "/usr/share/apport/apport -p%p -s%s >> -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to >> /home/tsayao/IdeaProjects/clamed-sistema-loja/core.2049284) >> # >> # If you would like to submit a bug report, please visit: >> # https://bugs.launchpad.net/ubuntu/+source/openjdk-lts >> >> # >> >> --------------- ?S U M M A R Y ------------ >> >> Command Line: -Xmx350m -Xms128m >> -Djava.net.preferIPv4Stack=true >> -Dsun.awt.disablegrab=true >> -Djavax.net.ssl.trustStore=./configuracoes/cacerts >> -Djavax.net.ssl.trustStorePassword=changeit >> -Djava.library.path=/home/tsayao/IdeaProjects/clamed-sistema-loja/libs/client/linux/x64:/home/tsayao/IdeaProjects/clamed-sistema-loja/libs/client/linux/x64/tef_simulado >> --add-modules=javafx.controls,javafx.fxml,javafx.web,javafx.swing,javafx.media >> roda-na-loja/clamed-frontend-loja/target/fl.jar >> >> Host: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 8 cores, >> 7G, Ubuntu 20.04.4 LTS >> Time: Wed Oct ?5 15:31:25 2022 -03 elapsed time: >> 106.086065 seconds (0d 0h 1m 46s) >> >> --------------- ?T H R E A D ?--------------- >> >> Current thread (0x00007f85980bd800): ?GCTaskThread "GC >> Thread#3" [stack: 0x00007f85073a0000,0x00007f85074a0000] >> [id=2049339] >> >> Stack: [0x00007f85073a0000,0x00007f85074a0000], >> ?sp=0x00007f850749ead0, ?free space=1018k >> Native frames: (J=compiled Java code, A=aot compiled Java >> code, j=interpreted, Vv=VM code, C=native code) >> V ?[libjvm.so+0x5c5a8f] >> ?ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f >> V ?[libjvm.so+0x793999] >> ?G1CLDScanClosure::do_cld(ClassLoaderData*)+0x39 >> V ?[libjvm.so+0x5c8371] >> ?ClassLoaderDataGraph::roots_cld_do(CLDClosure*, >> CLDClosure*)+0x41 >> V ?[libjvm.so+0x7b382b] >> ?G1RootProcessor::process_java_roots(G1RootClosures*, >> G1GCPhaseTimes*, unsigned int)+0x6b >> V ?[libjvm.so+0x7b3ebb] >> ?G1RootProcessor::evacuate_roots(G1ParScanThreadState*, >> unsigned int)+0x6b >> V ?[libjvm.so+0x75b5dc] ?G1ParTask::work(unsigned int)+0xec >> V ?[libjvm.so+0xec387d] ?GangWorker::loop()+0x4d >> V ?[libjvm.so+0xe2a0f0] ?Thread::call_run()+0x140 >> V ?[libjvm.so+0xbe7c6e] ?thread_native_entry(Thread*)+0xee >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Fri Oct 7 15:55:21 2022 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 7 Oct 2022 15:55:21 +0000 Subject: Alternative CONSTRAINED_RESIZE_POLICY for Tree/TableView Message-ID: Dear colleagues: I would like to propose a replacement for the current constrained column resize policy implementation in Tree/TableView and related public API changes. Please refer to the main ticket https://bugs.openjdk.org/browse/JDK-8293119 and a draft PR https://github.com/openjdk/jfx/pull/897 for more details. To illustrate behavior of the new policies, please check out a tester app, ATableViewResizeTester, located in tests/manual/controls. In addition, you can compare the new policies against the old CONSTRAINED_RESIZE_POLICY if you switch to a https://github.com/andy-goryachev-oracle/jfx/tree/8293119.constrained.demo branch, where the old policy has not yet been replaced with the new alternative. Your comments, suggestions, and especially any behavioral issues you might see with the tester will be greatly appreciated! Thank you in advance, -andy Problem The existing constrained column resize policy (Tree/TableView.CONSTRAINED_RESIZE_POLICY) has a number of issues most of which are listed in detail in ? JDK-8292810. The current implementation fails to honor constraints, fails with empty tree/table, fails with multiple tables, shows/flickers the horizontal scroll bar, shows weird behavior when manually resizing columns in the presence of constraints; but the main issue is that the user simply cannot create a custom column resize policy with setColumnResizePolicy() due to absence of public APIs that provide the target width or allow for changing the column widths. Proposed Solution 1. Introduce a ConstrainedColumnResizeBase class as a base class for any constrained resize policy. The main purpose - turn off the horizontal scroll bar and provide a "constrained-resize" pseudostyle via its toString() method. 2. Provide a new implementation via ConstrainedColumnResize class. The new implementation supports several resizing modes - some similar to JTable resize modes, and two new modes that try to behave as the current resize policy (minus the bugs). 3. The current CONSTRAINED_RESIZE_POLICY constants in Tree/TableView is marked as deprecated. 4. The new resize policies are made available to the users via new constants (see below). 5. The current CONSTRAINED_RESIZE_POLICY becomes an alias for CONSTRAINED_RESIZE_POLICY_FLEX_TAIL, preserving binary compatibility and providing a similar user experience. 6. Add code to dynamically remove "constrained-resize" pseudostyle when tree/table width exceeds the sum of maximum widths of all the columns, resulting in an empty space appearing to the right of the columns. This in turn requires the vertical line at the right border of the last column to be painted. Resize Modes /** * A policy that tries to adjust other columns in order to fit the table width. *

    * When column constraints make it impossible to fit all the columns into the allowed area, * the columns are either clipped, or an empty space appears. This policy disables the horizontal * scroll bar. */ public static final Callback CONSTRAINED_RESIZE_POLICY_ALL_COLUMNS /** * A policy that tries to adjust last column in order to fit the table width. *

    * When column constraints make it impossible to fit all the columns into the allowed area, * the columns are either clipped, or an empty space appears. This policy disables the horizontal * scroll bar. */ public static final Callback CONSTRAINED_RESIZE_POLICY_LAST_COLUMN /** * A policy adjusts the next column in the opposite way in order to fit the table width. *

    * When column constraints make it impossible to fit all the columns into the allowed area, * the columns are either clipped, or an empty space appears. This policy disables the horizontal * scroll bar. */ public static final Callback CONSTRAINED_RESIZE_POLICY_NEXT_COLUMN /** * A policy that tries to adjust subsequent columns in order to fit the table width. *

    * When column constraints make it impossible to fit all the columns into the allowed area, * the columns are either clipped, or an empty space appears. This policy disables the horizontal * scroll bar. */ public static final Callback CONSTRAINED_RESIZE_POLICY_SUBSEQUENT_COLUMNS /** * A policy that tries to adjust columns, starting with the next one, in order to fit the table width. *

    * When column constraints make it impossible to fit all the columns into the allowed area, * the columns are either clipped, or an empty space appears. This policy disables the horizontal * scroll bar. */ public static final Callback CONSTRAINED_RESIZE_POLICY_FLEX_HEAD /** * A policy that tries to adjust columns, starting with the last one, in order to fit the table width. *

    * When column constraints make it impossible to fit all the columns into the allowed area, * the columns are either clipped, or an empty space appears. This policy disables the horizontal * scroll bar. */ public static final Callback CONSTRAINED_RESIZE_POLICY_FLEX_TAIL Public API Changes Please refer to a CSR https://bugs.openjdk.org/browse/JDK-8294398 for more details; here is a brief summary: ResizeFeaturesBase class: - added getContentWidth() - added setColumnWidth(TableColumnBase, double); new abstract ConstrainedColumnResizeBase class: - marker class, disables the horizontal scroll bar Tree/TableView classes: - added new policy constants (see above) - @Deprecated(since="20") CONSTRAINED_RESIZE_POLICY = CONSTRAINED_RESIZE_POLICY_FLEX_TAIL; Testing I have no idea how to unit test new policies (see ResizeHelperTest). I wanted to exercise all the combinations of { policy | table width | number of columns (0,1,5) | constraints (min,pref,max) }, but this test takes too much time even on fast machine. The other alternative is to test only a few basic scenarios, but I feel it would be rather incomplete. A tester app seems to be the best solution so far, but it is certainly cannot be automated. [Graphical user interface, application, table, Excel Description automatically generated] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 258731 bytes Desc: image001.png URL: From angorya at openjdk.org Fri Oct 7 16:14:46 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Oct 2022 16:14:46 GMT Subject: Integrated: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 19:40:21 GMT, Andy Goryachev wrote: > The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled. > > Changes: > - modified TreeTableRow.updateSelection() This pull request has now been integrated. Changeset: 9768b5e4 Author: Andy Goryachev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/9768b5e42391e2d48aefffa3a3f6b1de6c30ef9d Stats: 507 lines in 4 files changed: 498 ins; 4 del; 5 mod 8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.org/jfx/pull/875 From stnordstrom at gmail.com Fri Oct 7 17:06:02 2022 From: stnordstrom at gmail.com (Sten Nordstrom) Date: Fri, 7 Oct 2022 20:06:02 +0300 Subject: JavaFX 19 Crashes In-Reply-To: References: Message-ID: Have you tried 11.0.16.1? It fixes a C2 regression. https://bugs.openjdk.org/browse/JDK-8292260 Best regards Sten On Fri 7. Oct 2022 at 16.00 Thiago Milczarek Say?o wrote: > This specific crash (that I can always reproduce with java-11) does not > happen with java-17. > > Java 17: > openjdk 17.0.4 2022-07-19 > OpenJDK Runtime Environment (build 17.0.4+8-Ubuntu-120.04) > OpenJDK 64-Bit Server VM (build 17.0.4+8-Ubuntu-120.04, mixed mode, > sharing) > > Java 11: > openjdk 11.0.16 2022-07-19 > OpenJDK Runtime Environment (build 11.0.16+8-post-Ubuntu-0ubuntu120.04) > OpenJDK 64-Bit Server VM (build 11.0.16+8-post-Ubuntu-0ubuntu120.04, mixed > mode, sharing) > > Em qui., 6 de out. de 2022 ?s 22:22, Kevin Rushforth < > kevin.rushforth at oracle.com> escreveu: > >> That seems odd, since it looks like a hotspot bug to me. It isn't 100% >> out of the question that something changed by that patch is causing a >> memory corruption problem, but it's a very simple patch, and I can't see >> anything in it that would explain this. Most likely, this is a hotspot >> problem that is just being provoked, possibly one that has been fixed. Have >> you tried it with JDK 19? >> >> -- Kevin >> >> >> On 10/6/2022 11:29 AM, Johan Vos wrote: >> >> That is a bit unexpected indeed, but not totally. We know that there are >> things in the glass-gtk code that are subject to improvement. To me, this >> seems one more reason to pick up the work you started on >> https://github.com/openjdk/jfx/pull/367 -- I'm willing to help with this. >> >> - Johan >> >> On Thu, Oct 6, 2022 at 8:11 PM Thiago Milczarek Say?o < >> thiago.sayao at gmail.com> wrote: >> >>> Hi, >>> >>> I found the offensor: >>> https://github.com/openjdk/jfx/pull/598 >>> >>> Reverting this patch stops the crash with java11. >>> >>> It does not make any sense to me. >>> >>> >>> >>> Em qua., 5 de out. de 2022 ?s 17:10, Thiago Milczarek Say?o < >>> thiago.sayao at gmail.com> escreveu: >>> >>>> Hi, >>>> >>>> I'm still experiencing crashes with javafx 19. >>>> >>>> It happens with openjdk 11.0.16, and it's not reproducible with openjdk >>>> 17 (but it does rarely crash). >>>> >>>> I cannot convince the team that it's not a javafx-19 bug because >>>> downgrading back to javafx-16 stops the crash from happening. >>>> >>>> I can reproduce by selecting an item on a TableView that's inside a >>>> Dialog which is called by showAndWait() and pressing ENTER >>>> - this triggers the Dialog to close and return the selected item. It >>>> does not crash when using the mouse double-click. >>>> >>>> Oddly enough it does not happen on JavaFX, but this line causes the >>>> crash: >>>> >>>> UUID cdVendaProduto = Generators.timeBasedGenerator().generate(); // >>>> https://mvnrepository.com/artifact/com.fasterxml.uuid/java-uuid-generator >>>> >>>> This line (unrelated to JavaFX) crashes with JavaFX-19 and does not >>>> crash with JavaFX-16. >>>> >>>> I Know this is very odd - and does not seem like a JavaFX bug. >>>> >>>> Running on IntelliJ idea (CRASHES - note that it adds >>>> -XX:TieredStopAtLevel=1 -Xverify:none): >>>> Command Line: -agentlib:jdwp=transport=dt_socket,address= >>>> 127.0.0.1:46069,suspend=y,server=n -Xmx500m -Xms135m >>>> -Djava.library.path=./libs/client/linux/x64:./libs/client/linux/x64/tef_simulado:/usr/local/lib >>>> -Djavax.net.ssl.trustStore=./configuracoes/cacerts >>>> -Djavax.net.ssl.trustStorePassword=changeit -Dsun.awt.disablegrab=true >>>> -XX:TieredStopAtLevel=1 -Xverify:none -Dspring.output.ansi.enabled=always >>>> -Dcom.sun.management.jmxremote -Dspring.jmx.enabled=true >>>> -Dspring.liveBeansView.mbeanDomain -Dspring.application.admin.enabled=true >>>> -javaagent:/home/tsayao/idea-IU-212.4746.92/plugins/java/lib/rt/debugger-agent.jar >>>> -Dfile.encoding=UTF-8 br.com.clamed.frontend.Launcher >>>> >>>> Running the jar: >>>> >>>> # >>>> # A fatal error has been detected by the Java Runtime Environment: >>>> # >>>> # SIGSEGV (0xb) at pc=0x00007f85cd377a8f, pid=2049284, tid=2049339 >>>> # >>>> # JRE version: OpenJDK Runtime Environment (11.0.16+8) (build >>>> 11.0.16+8-post-Ubuntu-0ubuntu120.04) >>>> # Java VM: OpenJDK 64-Bit Server VM >>>> (11.0.16+8-post-Ubuntu-0ubuntu120.04, mixed mode, tiered, compressed oops, >>>> g1 gc, linux-amd64) >>>> # Problematic frame: >>>> # V [libjvm.so+0x5c5a8f] >>>> ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f >>>> # >>>> # Core dump will be written. Default location: Core dumps may be >>>> processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g >>>> -- %E" (or dumping to >>>> /home/tsayao/IdeaProjects/clamed-sistema-loja/core.2049284) >>>> # >>>> # If you would like to submit a bug report, please visit: >>>> # https://bugs.launchpad.net/ubuntu/+source/openjdk-lts >>>> # >>>> >>>> --------------- S U M M A R Y ------------ >>>> >>>> Command Line: -Xmx350m -Xms128m -Djava.net.preferIPv4Stack=true >>>> -Dsun.awt.disablegrab=true >>>> -Djavax.net.ssl.trustStore=./configuracoes/cacerts >>>> -Djavax.net.ssl.trustStorePassword=changeit >>>> -Djava.library.path=/home/tsayao/IdeaProjects/clamed-sistema-loja/libs/client/linux/x64:/home/tsayao/IdeaProjects/clamed-sistema-loja/libs/client/linux/x64/tef_simulado >>>> --add-modules=javafx.controls,javafx.fxml,javafx.web,javafx.swing,javafx.media >>>> roda-na-loja/clamed-frontend-loja/target/fl.jar >>>> >>>> Host: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 8 cores, 7G, Ubuntu >>>> 20.04.4 LTS >>>> Time: Wed Oct 5 15:31:25 2022 -03 elapsed time: 106.086065 seconds (0d >>>> 0h 1m 46s) >>>> >>>> --------------- T H R E A D --------------- >>>> >>>> Current thread (0x00007f85980bd800): GCTaskThread "GC Thread#3" >>>> [stack: 0x00007f85073a0000,0x00007f85074a0000] [id=2049339] >>>> >>>> Stack: [0x00007f85073a0000,0x00007f85074a0000], sp=0x00007f850749ead0, >>>> free space=1018k >>>> Native frames: (J=compiled Java code, A=aot compiled Java code, >>>> j=interpreted, Vv=VM code, C=native code) >>>> V [libjvm.so+0x5c5a8f] >>>> ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f >>>> V [libjvm.so+0x793999] G1CLDScanClosure::do_cld(ClassLoaderData*)+0x39 >>>> V [libjvm.so+0x5c8371] >>>> ClassLoaderDataGraph::roots_cld_do(CLDClosure*, CLDClosure*)+0x41 >>>> V [libjvm.so+0x7b382b] >>>> G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*, >>>> unsigned int)+0x6b >>>> V [libjvm.so+0x7b3ebb] >>>> G1RootProcessor::evacuate_roots(G1ParScanThreadState*, unsigned int)+0x6b >>>> V [libjvm.so+0x75b5dc] G1ParTask::work(unsigned int)+0xec >>>> V [libjvm.so+0xec387d] GangWorker::loop()+0x4d >>>> V [libjvm.so+0xe2a0f0] Thread::call_run()+0x140 >>>> V [libjvm.so+0xbe7c6e] thread_native_entry(Thread*)+0xee >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Oct 7 18:48:22 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Oct 2022 18:48:22 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 12:38:57 GMT, Jeanette Winzenburg wrote: >> please check the updated comment, I think it sounds weird... > > that change sounds okay to me :) > > What might be missing is a description of that it actually does, that is taking full control about the old.dispose / new.install sequence as spec'ed in Skin - I think it could be repeated here to emphasize that it's living up to its responsibility. I think it's a good idea, and a good spot for the explanation. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Fri Oct 7 18:55:56 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Oct 2022 18:55:56 GMT Subject: RFR: 8290844: Add Skin.install() method [v11] In-Reply-To: References: Message-ID: > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) 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 24 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - 8290844: javadoc - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - 8290844: javadoc - Merge branch 'openjdk:master' into 8290844.skin.install - 8290844: unit tests - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - 8290844: review comments - 8290844: review comments - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - ... and 14 more: https://git.openjdk.org/jfx/compare/0fc6517a...15731a2c ------------- Changes: - all: https://git.openjdk.org/jfx/pull/845/files - new: https://git.openjdk.org/jfx/pull/845/files/6f6b95c0..15731a2c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=09-10 Stats: 519 lines in 6 files changed: 503 ins; 4 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/845.diff Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845 PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Fri Oct 7 18:55:57 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Oct 2022 18:55:57 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 12:21:22 GMT, Jeanette Winzenburg wrote: >> re-phrased the comment, please let me know if the new version is clearer (or suggest an alternative if not). > > hmm .. it's still using setSkin :) > > What about following the lead of dispose doc closely: > >> Called by Skinnable when the Skin is attached/set (whatever, you are the native speakers ;) to the Skinnable. This method allows a Skin to ... (same as currently) .. >> >> Must be called exactly once _after_ a previous Skin - if any - is disposed. >> >> (same as current) >> >> > > Still not quite sure the spec is clear enough to express the precondition for this method: in words it's something like "there must not be any other skin with other.getSkinnable() == this.getSkinnable()", that is all other potential skins are disposed - but that sounds a bit unbounded ... > > Aside: strictly speaking, the dispose doc is over-specified "Called by the Skinnable.." - which is making our own code violating that contract: dispose is called freely from other collaborators, f.i. during auto-sizing of columns, doing layout in VirtualFlow .. just saying :) re-phrased a bit, see if you like it better. ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Sat Oct 8 15:46:22 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 8 Oct 2022 15:46:22 GMT Subject: RFR: 8290844: Add Skin.install() method [v11] In-Reply-To: References: Message-ID: On Fri, 7 Oct 2022 18:55:56 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > 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 24 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - Merge branch 'openjdk:master' into 8290844.skin.install > - 8290844: unit tests > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - ... and 14 more: https://git.openjdk.org/jfx/compare/c435607c...15731a2c A few comments left inline. modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 227: > 225: * To ensure a one-to-one relationship between a {@code Control} and its {@code Skin}, > 226: * setting the {@link #skinProperty() skin property} first triggers a check of the return value of > 227: * {@link Skin#getSkinnable()} against this Control, and throw an {@code IllegalArgumentException} I think you still need to say "if not null" here. Also, I think "triggers a check of" can be replaced with "checks". Further, "throw" should be "throws", so maybe something more like: setting the {@link #skinProperty() skin property} to a non-null {@code Skin} first checks the return value of {@link Skin#getSkinnable()} against this Control, and throws ... modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 232: > 230: * to complete the process. Only inside of {@link Skin#install()} should {@code Skin} implementations > 231: * set/overwrite properties of their {@code Control} (though commutative operations like add/remove listener > 232: * can still be done in the {@code Skin} constructor. I don't think "commutative" is quite the right term here, although I get what you are saying. This is trying to describe an operation that can be reversed (undone) without side effect. So commutativity is part of it, but not the whole thing. The property we want is: f(A, A`) == empty f(A, B, B`) == f(A) f(A, B, A`) == f(B) Is there a single term that describes this? Oh, and you are missing a closing parenthesis. modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 237: > 235: * > 236: * @return the skin property for this control > 237: * @throws IllegalArgumentException if {@code (skin != null && skin.getSkinnable() != Control.this)} Saying `Control.this` is leaking an implementation detail into the spec. The fact that the proposed implementation "just so happens" to do the check in a lambda, causing the implementation to use `Control.this`, is of no relevance to the spec. You should replace `Control.this` with `this`. modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 39: > 37: *

  • instantiation > 38: *
  • configuration, such as passing of dependencies and parameters > 39: *
  • inside of {@link Control#setSkin(Skin)}: Same comment as earlier: replace "inside of Control.setSkin" with "when the skin is set on a Skinnable". modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 75: > 73: > 74: /** > 75: * Called once by {@link Skinnable#setSkin(Skin)} after the Same comment as earlier: replace "Called once by Skinnable.setSkin" with "Called once when the skin is set". modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 80: > 78: * required properties and/or event handlers. > 79: *

    > 80: * Client code must not call this method. I think saying "Application code" would be clearer (to remove the ambiguity over who the "client" is). ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Sat Oct 8 15:46:25 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 8 Oct 2022 15:46:25 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: <32PyeprX3EtYYroMHxUueufQeQ6DuH4SLys4Em_-Ac4=.da2c2f63-2b0c-4181-8846-cc6e76c84be3@github.com> References: <32PyeprX3EtYYroMHxUueufQeQ6DuH4SLys4Em_-Ac4=.da2c2f63-2b0c-4181-8846-cc6e76c84be3@github.com> Message-ID: On Tue, 4 Oct 2022 19:05:56 GMT, Andy Goryachev wrote: >> Maybe something like `will check the return value of {@link Skin#getSkinnable()}, if the Skin is not {@code null}, against this Control...`? > > How about > > > * To ensure a one-to-one relationship between a {@code Skinnable} and its > * {@code Skin}, some implementations of {@link Skinnable#setSkin(Skin)} method will check > * the return value of {@link Skin#getSkinnable()}, and if it is not {@code null}, compare it > * with this Skinnable, throwing an {@code IllegalArgumentException} if it is not the same. The problem with this proposed wording (which I see you didn't go with) is that it is the skin itself that could be null -- you can't even call `getSkinnable()` if the skin is null. Also, it has the problem Jeanette mentioned -- we don't want to refer to "the setSkin method". Instead, you can say something like "when the skin property is set" (or just "when the skin is set"). The reason for this is that the skin property can also be set by calling `skinProperty().set()`. ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Sat Oct 8 15:46:25 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 8 Oct 2022 15:46:25 GMT Subject: RFR: 8290844: Add Skin.install() method [v9] In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 11:50:23 GMT, Jeanette Winzenburg wrote: >> I agree with @kevinrushforth , it's one of the cases when the method is public, but it should not be called by an application, only by its Control. >> >> Perhaps we should further clarify this fact? > > Control is _our_ specific implementation - others might differ :) And not talking about application code but a possibly complete skinnable/skin controlling scheme. > > But I see your point - how can we clearly express that the complete dispose-install cycle should be in the hands of exactly one collaborator (whether a skinnable's property or somewhere else)? > > The concrete cells have public methods that are marked as "expert api" - maybe we could do something similar here? I'm not sure that we need to provide for other implementations of Skinnable/Skin. If we can figure out a good way to express the needed invariants in a more neutral way, that's OK, but I'd rather err on the side of clearly defining the requirements of our implementation of Skinnable/Skin. ------------- PR: https://git.openjdk.org/jfx/pull/845 From thiago.sayao at gmail.com Mon Oct 10 15:44:01 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 10 Oct 2022 12:44:01 -0300 Subject: TextField blurry inside AnchorPane - Is it a bug? Message-ID: Hi, This FXML below (just open on SceneBuilder) causes the TextField to be blurry. I'm not sure if it's expected or a bug. Possibly the same as: https://bugs.openjdk.org/browse/JDK-8089499 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlemmermann at gmail.com Mon Oct 10 17:15:14 2022 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Mon, 10 Oct 2022 19:15:14 +0200 Subject: RFR: 8191995: Regression: DatePicker must commit on focusLost In-Reply-To: References: Message-ID: <26B52ABE-86C8-40A2-9B5A-54660DB80B39@gmail.com> Just submitted a bug report related to this issue. The DatePicker could now commit back to the old / previous value when the user selection of a new date via the dropdown also triggers the closing of the dialog that is showing the date picker. In that case the newly added commitValue() method will use the date expressed by the text inside the editor (TextField), which is actually the old date. Dirk > On 7 Dec 2021, at 14:11, Kevin Rushforth wrote: > > On Wed, 24 Nov 2021 09:09:53 GMT, Marius Hanl wrote: > >> This PR fixes an issue where the `DatePicker` is not committing his text as value when the focus is lost. >> As the ticket also mentions, this is a regression which last worked on JavaFX 8 and got broken by this refactoring: [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) >> >> The fix is to provide the same api to the `DatePicker` which was introduced by [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) for `ComboBox` and `Spinner`. >> >> Note: While fixing this I found a possible bug which I tracked here: [JDK-8277756](https://bugs.openjdk.java.net/browse/JDK-8277756) >> -> When creating a `DatePicker` with the second constructor (with `LocalDate` as parameter) two listener won't be added since they are only added at the first constructor (That's also why I added the focusProperty listener in the second constructor). > > Looks good. I've also "Reviewed" the CSR, so it can be finalized. > > ------------- > > Marked as reviewed by kcr (Lead). > > PR: https://git.openjdk.java.net/jfx/pull/679 From angorya at openjdk.org Mon Oct 10 16:23:16 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Oct 2022 16:23:16 GMT Subject: RFR: 8290844: Add Skin.install() method [v11] In-Reply-To: References: Message-ID: On Fri, 7 Oct 2022 22:51:07 GMT, Kevin Rushforth 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 24 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge branch 'openjdk:master' into 8290844.skin.install >> - 8290844: unit tests >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - ... and 14 more: https://git.openjdk.org/jfx/compare/a785e7c0...15731a2c > > modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 232: > >> 230: * to complete the process. Only inside of {@link Skin#install()} should {@code Skin} implementations >> 231: * set/overwrite properties of their {@code Control} (though commutative operations like add/remove listener >> 232: * can still be done in the {@code Skin} constructor. > > I don't think "commutative" is quite the right term here, although I get what you are saying. This is trying to describe an operation that can be reversed (undone) without side effect. So commutativity is part of it, but not the whole thing. The property we want is: > > > f(A, A`) == empty > f(A, B, B`) == f(A) > f(A, B, A`) == f(B) > > > Is there a single term that describes this? > > Oh, and you are missing a closing parenthesis. re-phrased. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Mon Oct 10 16:33:13 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Oct 2022 16:33:13 GMT Subject: RFR: 8290844: Add Skin.install() method [v12] In-Reply-To: References: Message-ID: > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290844: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/845/files - new: https://git.openjdk.org/jfx/pull/845/files/15731a2c..97ad66c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=10-11 Stats: 10 lines in 2 files changed: 1 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/845.diff Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845 PR: https://git.openjdk.org/jfx/pull/845 From kevin.rushforth at oracle.com Mon Oct 10 17:46:57 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 10 Oct 2022 10:46:57 -0700 Subject: RFR: 8191995: Regression: DatePicker must commit on focusLost In-Reply-To: <26B52ABE-86C8-40A2-9B5A-54660DB80B39@gmail.com> References: <26B52ABE-86C8-40A2-9B5A-54660DB80B39@gmail.com> Message-ID: <88451527-f413-b21c-e5f5-ff4843829697@oracle.com> Thanks for reporting this. -- Kevin On 10/10/2022 10:15 AM, Dirk Lemmermann wrote: > Just submitted a bug report related to this issue. The DatePicker could now commit back to the old / previous value when the user selection of a new date via the dropdown also triggers the closing of the dialog that is showing the date picker. In that case the newly added commitValue() method will use the date expressed by the text inside the editor (TextField), which is actually the old date. > > Dirk > > >> On 7 Dec 2021, at 14:11, Kevin Rushforth wrote: >> >> On Wed, 24 Nov 2021 09:09:53 GMT, Marius Hanl wrote: >> >>> This PR fixes an issue where the `DatePicker` is not committing his text as value when the focus is lost. >>> As the ticket also mentions, this is a regression which last worked on JavaFX 8 and got broken by this refactoring: [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) >>> >>> The fix is to provide the same api to the `DatePicker` which was introduced by [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) for `ComboBox` and `Spinner`. >>> >>> Note: While fixing this I found a possible bug which I tracked here: [JDK-8277756](https://bugs.openjdk.java.net/browse/JDK-8277756) >>> -> When creating a `DatePicker` with the second constructor (with `LocalDate` as parameter) two listener won't be added since they are only added at the first constructor (That's also why I added the focusProperty listener in the second constructor). >> Looks good. I've also "Reviewed" the CSR, so it can be finalized. >> >> ------------- >> >> Marked as reviewed by kcr (Lead). >> >> PR: https://git.openjdk.java.net/jfx/pull/679 From angorya at openjdk.org Mon Oct 10 18:00:16 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Oct 2022 18:00:16 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v2] In-Reply-To: References: Message-ID: > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8294589: unnecessary null checks ------------- Changes: - all: https://git.openjdk.org/jfx/pull/906/files - new: https://git.openjdk.org/jfx/pull/906/files/1adbc9ad..7824baa8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=00-01 Stats: 23 lines in 1 file changed: 1 ins; 7 del; 15 mod Patch: https://git.openjdk.org/jfx/pull/906.diff Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906 PR: https://git.openjdk.org/jfx/pull/906 From tsayao at openjdk.org Mon Oct 10 23:45:32 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 10 Oct 2022 23:45:32 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v25] In-Reply-To: References: <6gBNdAxOqgSHOKfj86nzOUc6_1UWY0kmUnKhf9TwiK8=.7d722669-0d59-42b1-931d-36022d274bc3@github.com> <9GXnzwJwsUwutske-Y64hdOx2d28Bcm_COZfJbNEyaI=.9afc48fa-85df-471d-b363-0b7c88ad1055@github.com> <41DeoC5Ij7KsuyYv0YZVGlGPs6UK10zwlzC2HJ0wM5Y=.cacffc47-9de1-4b3b-8d3a-cace992499f5@github.com> Message-ID: On Fri, 30 Sep 2022 06:49:40 GMT, Johan Vos wrote: >> Testing: >> >> **master** >> ![master](https://user-images.githubusercontent.com/30704286/111889893-6e793f80-89c3-11eb-8f38-640e8123794c.png) >> >> **tsayao:glass_gtk_new_position_and_size** >> ![branch](https://user-images.githubusercontent.com/30704286/111889897-733df380-89c3-11eb-9929-2ed55471638e.png) >> >> `--tests test.robot.javafx.scene.RobotTest` causes some intermittent error but eventually all passes. > > @tsayao The work in this PR looks really good. If you want to continue with this, I will review it. There are some conflicts but those can easily be solved. @johanvos I think I can rework it better now. ------------- PR: https://git.openjdk.org/jfx/pull/367 From almatvee at openjdk.org Tue Oct 11 00:08:26 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 11 Oct 2022 00:08:26 GMT Subject: RFR: 8287822: [macos] Remove support of duplicated formats from macOS Message-ID: - Added support for JAR and JRT protocol to AVFoundation platform. - Removed H.264/MP3 and AAC support from GStreamer platform, which was primary used to playback these formats for JAR and JRT protocols. - Added ability to FXMediaPlayer sample to generate playlist for JAR and JRT protocols for testing. See FXMedia.java for how to use it. - H.265/HEVC via JAR/JRT protocols should work on macOS after this change. Before it did not work because GStreamer platform did not support H.265/HEVC and AVFoundation did not support JAR/JRT protocols. - Minor code clean up. After this changes: GSTPlatform: AIFF and WAV for all protocols. AVFoundation: MP3, AAC, HLS, H.264 and H.265 for all protocols. This change is transparent for end user and does not affect list of supported formats by JavaFX Media. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into JDK-8287822 - 8287822: [macos] Remove support of duplicated formats from macOS Changes: https://git.openjdk.org/jfx/pull/909/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=909&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287822 Stats: 3269 lines in 27 files changed: 436 ins; 2784 del; 49 mod Patch: https://git.openjdk.org/jfx/pull/909.diff Fetch: git fetch https://git.openjdk.org/jfx pull/909/head:pull/909 PR: https://git.openjdk.org/jfx/pull/909 From mhanl at openjdk.org Tue Oct 11 09:13:14 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 11 Oct 2022 09:13:14 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane Message-ID: The problem here is, that the `AnchorPane` does not use its snapped insets. Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. Line 2995 in `modena.css`: .titled-pane > .content > AnchorPane { -fx-padding: 0.8em; } which translates to 9.6px. ------------- Commit messages: - 8295078: TextField blurry when inside an TitledPane -> AnchorPane Changes: https://git.openjdk.org/jfx/pull/910/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=910&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295078 Stats: 74 lines in 2 files changed: 59 ins; 5 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/910.diff Fetch: git fetch https://git.openjdk.org/jfx pull/910/head:pull/910 PR: https://git.openjdk.org/jfx/pull/910 From jvos at openjdk.org Tue Oct 11 09:33:34 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 11 Oct 2022 09:33:34 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v25] In-Reply-To: References: <6gBNdAxOqgSHOKfj86nzOUc6_1UWY0kmUnKhf9TwiK8=.7d722669-0d59-42b1-931d-36022d274bc3@github.com> <9GXnzwJwsUwutske-Y64hdOx2d28Bcm_COZfJbNEyaI=.9afc48fa-85df-471d-b363-0b7c88ad1055@github.com> <41DeoC5Ij7KsuyYv0YZVGlGPs6UK10zwlzC2HJ0wM5Y=.cacffc47-9de1-4b3b-8d3a-cace992499f5@github.com> Message-ID: On Fri, 30 Sep 2022 06:49:40 GMT, Johan Vos wrote: >> Testing: >> >> **master** >> ![master](https://user-images.githubusercontent.com/30704286/111889893-6e793f80-89c3-11eb-8f38-640e8123794c.png) >> >> **tsayao:glass_gtk_new_position_and_size** >> ![branch](https://user-images.githubusercontent.com/30704286/111889897-733df380-89c3-11eb-9929-2ed55471638e.png) >> >> `--tests test.robot.javafx.scene.RobotTest` causes some intermittent error but eventually all passes. > > @tsayao The work in this PR looks really good. If you want to continue with this, I will review it. There are some conflicts but those can easily be solved. > @johanvos I think I can rework it better now. Do you mean you want to close this PR and create a new one? That's fine -- let me know if you need some help or a first review even before it's ready. ------------- PR: https://git.openjdk.org/jfx/pull/367 From tsayao at openjdk.org Tue Oct 11 11:26:46 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 11 Oct 2022 11:26:46 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v25] In-Reply-To: References: <6gBNdAxOqgSHOKfj86nzOUc6_1UWY0kmUnKhf9TwiK8=.7d722669-0d59-42b1-931d-36022d274bc3@github.com> <9GXnzwJwsUwutske-Y64hdOx2d28Bcm_COZfJbNEyaI=.9afc48fa-85df-471d-b363-0b7c88ad1055@github.com> <41DeoC5Ij7KsuyYv0YZVGlGPs6UK10zwlzC2HJ0wM5Y=.cacffc47-9de1-4b3b-8d3a-cace992499f5@github.com> Message-ID: On Tue, 11 Oct 2022 09:29:54 GMT, Johan Vos wrote: >> @tsayao The work in this PR looks really good. If you want to continue with this, I will review it. There are some conflicts but those can easily be solved. > >> @johanvos I think I can rework it better now. > > Do you mean you want to close this PR and create a new one? That's fine -- let me know if you need some help or a first review even before it's ready. @johanvos Yes, I have started working on it at https://github.com/tsayao/jfx/tree/clean_glass_gtk ------------- PR: https://git.openjdk.org/jfx/pull/367 From dlemmermann at gmail.com Tue Oct 11 15:36:54 2022 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Tue, 11 Oct 2022 17:36:54 +0200 Subject: Negative coordinates do not work on Linux(Gnome), but on Windows Message-ID: <56064622-5DE3-4058-A8B3-798B145FD75B@gmail.com> I just ran into this issue: https://bugs.openjdk.org/browse/JDK-8222794 The ticket is closed and marked as ?not an issue?. Unfortunately there is no description why this is not an issue. In our app we removed the window decorations of our main stage and use a custom design. For this to work we also have to reimplement the moving / dragging around of the window but with the limitation expressed by the ticket this seems to be impossible. I don?t really see a good reason why programmatically setting the x- or y-coordinate should not result in the window being shown on a different screen. However, I am open for being told why that is :-) Dirk -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Oct 11 15:48:39 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 11 Oct 2022 15:48:39 GMT Subject: RFR: 8287822: [macos] Remove support of duplicated formats from macOS In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 00:01:18 GMT, Alexander Matveev wrote: > - Added support for JAR and JRT protocol to AVFoundation platform. > - Removed H.264/MP3 and AAC support from GStreamer platform, which was primary used to playback these formats for JAR and JRT protocols. > - Added ability to FXMediaPlayer sample to generate playlist for JAR and JRT protocols for testing. See FXMedia.java for how to use it. > - H.265/HEVC via JAR/JRT protocols should work on macOS after this change. Before it did not work because GStreamer platform did not support H.265/HEVC and AVFoundation did not support JAR/JRT protocols. > - Minor code clean up. > > After this changes: > GSTPlatform: AIFF and WAV for all protocols. > AVFoundation: MP3, AAC, HLS, H.264 and H.265 for all protocols. > > This change is transparent for end user and does not affect list of supported formats by JavaFX Media. Changes requested by angorya (Author). modules/javafx.media/src/main/native/jfxmedia/Locator/Locator.cpp line 73: > 71: if (javaEnv.clearException()) > 72: return NULL; > 73: minor: would it make sense to wrap return in { }, line 67 and 72? tests/manual/media/FXMediaPlayer/src/fxmediaplayer/FXMediaPlayer.java line 165: > 163: > 164: // Create Media, MediaPlayer, MediaView and ImageView > 165: System.out.println("FXMediaPlayer source: " + source); probably needs to be removed? tests/manual/media/FXMediaPlayer/src/fxmediaplayer/media/FXMedia.java line 66: > 64: * [Windows] jlink --output dist/FXMediaPlayer -p ../../../../build/jmods;dist --add-modules javafx.base,javafx.controls,javafx.media,javafx.graphics,FXMediaPlayer --launcher FXMediaPlayer=FXMediaPlayer/fxmediaplayer.FXMediaPlayer > 65: * [Windows] dist\FXMediaPlayer\bin\FXMediaPlayer.bat > 66: */ minor: this javadoc will likely not render as expected. perhaps use

     from line 50 to 61 or 65.
    also, spelling "protcol" on line 50
    
    tests/manual/media/FXMediaPlayer/src/fxmediaplayer/media/FXMedia.java line 97:
    
    > 95:                 uri = FXMedia.class.getResource("/fxmediaplayer/media").toURI();
    > 96: 
    > 97:                 if (uri.getScheme().equals("jar")) {
    
    is it possible for uri scheme to be null?
    may be "jar".equals(uri.getScheme()) ?
    
    tests/manual/media/FXMediaPlayer/src/fxmediaplayer/media/FXMedia.java line 131:
    
    > 129:             });
    > 130:         } catch (URISyntaxException | IOException ex) {
    > 131:             System.out.println("Exception: " + ex);
    
    should System.out be removed?
    
    general question: do we want to use logging in places like this?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/909
    
    From thiago.sayao at gmail.com  Tue Oct 11 16:52:36 2022
    From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
    Date: Tue, 11 Oct 2022 13:52:36 -0300
    Subject: Negative coordinates do not work on Linux(Gnome), but on Windows
    In-Reply-To: <56064622-5DE3-4058-A8B3-798B145FD75B@gmail.com>
    References: <56064622-5DE3-4058-A8B3-798B145FD75B@gmail.com>
    Message-ID: 
    
    Hi Dirk,
    
    I have tried your example, it seems the window manager is denying the
    application from being moved into negative coordinates, unless using the
    window manager itself.
    
    It might be due to security reasons, but that's just me wondering.
    
    It might have a different behaviour on other window managers (modern gnome
    uses mutter).
    
    
    
    Em ter., 11 de out. de 2022 ?s 12:37, Dirk Lemmermann 
    escreveu:
    
    > I just ran into this issue: https://bugs.openjdk.org/browse/JDK-8222794
    >
    > The ticket is closed and marked as ?not an issue?. Unfortunately there is
    > no description why this is not an issue.
    >
    > In our app we removed the window decorations of our main stage and use a
    > custom design. For this to work we also have to reimplement the moving /
    > dragging around of the window but with the limitation expressed by the
    > ticket this seems to be impossible.
    >
    > I don?t really see a good reason why programmatically setting the x- or
    > y-coordinate should not result in the window being shown on a different
    > screen. However, I am open for being told why that is :-)
    >
    > Dirk
    >
    >
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From angorya at openjdk.org  Tue Oct 11 18:59:44 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Tue, 11 Oct 2022 18:59:44 GMT
    Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v2]
    In-Reply-To: 
    References: 
     
    Message-ID: 
    
    On Tue, 4 Oct 2022 15:14:43 GMT, Jeanette Winzenburg  wrote:
    
    >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
    >> 
    >>   8294589: unnecessary null checks
    >
    > modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java line 328:
    > 
    >> 326:         mouseEventHandler = t -> {
    >> 327:             if (getSkinnable() != null) {
    >> 328:                 Bounds containerScreenBounds = container.localToScreen(container.getLayoutBounds());
    > 
    > this null check is wrong: skinnable is guaranteed to never be null - except after dispose, at which time it's illegal to access any of the skin's methods/fields/state. So checking here is smearing over a precondition violation of the caller (most probably a dangling handler/listener) which has to be fixed.
    > 
    > Note we deliberately removed all null checks in all (cleaned) skins :) If we see any exceptions, the procedure is to 
    > 
    > - write a test exposing the exception (it's failing), this test belongs into SkinCleanTest
    > - find and fix the violator
    > - see the test passing
    > 
    > There might be other exceptions as well (like IOOB or similar) which require a similar procedure, see the available tests. Actually, I think it's a good idea to actively look out for possible macroscopic misbehavior if handlers/listeners are not removed properly. SkinCleanupTest has examples.
    
    agreed.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/906
    
    From angorya at openjdk.org  Tue Oct 11 18:59:40 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Tue, 11 Oct 2022 18:59:40 GMT
    Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v2]
    In-Reply-To: 
    References: 
     <4EVy11gFJT3NVPQFGKaFH5hwSxko4l_GWENAcEDlDOw=.2002dbda-77b2-494d-8a5f-8611be637769@github.com>
     
     <0vub_5YyoNn-4t_rm-9LHu_RnkzgZAVdcdmgQkFk4bM=.1f1ac0cc-8043-45c7-a25e-9c80f61bc009@github.com>
     
    Message-ID: <3TVqG5RGGRmI8gr5SbD7pviGa6WKTaktWGqMmk54jkM=.57d2b885-a951-4147-b7bf-826e0bc9be34@github.com>
    
    On Wed, 5 Oct 2022 11:32:04 GMT, Jeanette Winzenburg  wrote:
    
    >> well, it _does_ make sense for listeners registered on properties of the control itself (they don't change and are un/registered once) - and that was it was designed for :) What it can't handle (and was not designed for) are dynamic multiple un/registration of listeners.
    >
    > btw: the executeOnce pattern is appropriate only if it's guaranteed that the value changes once from null to not-null (not back again) .. which is not the case for the value of a control's scene property - it can change in both directions or not at all (which might be the reason for having added a second listener ;)
    
    you are so right here.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/906
    
    From angorya at openjdk.org  Tue Oct 11 18:59:46 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Tue, 11 Oct 2022 18:59:46 GMT
    Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v2]
    In-Reply-To: 
    References: 
     
     
     <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com>
     
     
     
     
     
     
     
     
     
     
     
     
    Message-ID: 
    
    On Tue, 4 Oct 2022 14:39:47 GMT, Jeanette Winzenburg  wrote:
    
    >>> In fact, it's so easy that most built-in skins do it (and these were created by the developers of JavaFX itself, so obviously it's a major problem if even those people get it wrong so often).
    >>> 
    >> 
    >> well, just guessing games here but: mine is that they didn't put too many thoughts into the possibility of replacing a skin and if they did, they actively prevented it - as seen in the implementation of TextAreaSkin.dispose when we started the current cleanup round:
    >> 
    >>     /** {@inheritDoc} */
    >>     @Override public void dispose() {
    >>         super.dispose();
    >> 
    >>         if (behavior != null) {
    >>             behavior.dispose();
    >>         }
    >> 
    >>         // TODO Unregister listeners on text editor, paragraph list
    >>         throw new UnsupportedOperationException();
    >>     }
    >
    >> You are right, @kleopatra - this executeOnceWhenPropertyIsNonNull() is installing a listener. perhaps we should add a similar functionality to LambdaMultiplePropertyChangeListenerHandler and actually install a WeakListener instead.
    > 
    > - yes, we need weakListeners (to wait for a not-null value to add the event handler) _and_ remove both the weakListener and the event handlers in dispose
    > - adding functionality to the LambdaHandler sounds like a good idea, but needs some thinking and should be done in a separate issue which also adds delegate methods to expose the new functionality in SkinBase for use in sub classes
    > 
    > For this issue, you might simply inline the utility method and register the listeners using skinbase api (didn't try, it's your issue :), see TableRowSkin for a similar pattern 
    > 
    > This conditional adding of handlers/listeners is needed if we have to support path properties (also f.i. when listening to selectedXX in any of the skins with selectionModels as properties). Which basically should be supported by base - but probably without any chance to ever get them ;)
    
    ListenerHelper - replacement for LambdaMultiplePropertyChangeListenerHandler .
    Please take a look at https://github.com/openjdk/jfx/pull/908
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/906
    
    From angorya at openjdk.org  Tue Oct 11 19:05:26 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Tue, 11 Oct 2022 19:05:26 GMT
    Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v3]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose().
    > 
    > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler.
    > See https://github.com/openjdk/jfx/pull/908
    
    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 20 additional commits since the last revision:
    
     - 8294589: cleanup
     - 8294589: using listener helper
     - Merge branch '8294809.listener.helper' into 8294589.menubarskin.leak.listener.helper
     - 8294809: event handlers and filters
     - Merge branch '8294589.menubarskin.leak' into 8294589.menubarskin.leak.listener.helper
     - 8294589: unnecessary null checks
     - 8294589: unnecessary null checks
     - Merge branch '8294809.listener.helper' into 8294589.menubarskin.leak.listener.helper
     - 8294809: cleanup
     - 8294809: override
     - ... and 10 more: https://git.openjdk.org/jfx/compare/cb41158d...5e1cef12
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/906/files
      - new: https://git.openjdk.org/jfx/pull/906/files/7824baa8..5e1cef12
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=02
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=01-02
    
      Stats: 1622 lines in 12 files changed: 1383 ins; 202 del; 37 mod
      Patch: https://git.openjdk.org/jfx/pull/906.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906
    
    PR: https://git.openjdk.org/jfx/pull/906
    
    From thiago.sayao at gmail.com  Tue Oct 11 20:22:26 2022
    From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
    Date: Tue, 11 Oct 2022 17:22:26 -0300
    Subject: Negative coordinates do not work on Linux(Gnome), but on Windows
    In-Reply-To: 
    References: <56064622-5DE3-4058-A8B3-798B145FD75B@gmail.com>
     
    Message-ID: 
    
    Hi,
    
    The correct way to implement this on Linux would be:
    
    https://specifications.freedesktop.org/wm-spec/wm-spec-1.4.html
    _NET_WM_MOVERESIZE
    We would need to implement a specific API to do this.
    
    This specification is to tell the Window Manager: Start a window move
    operation.
    
    -- Thiago.
    
    Em ter., 11 de out. de 2022 ?s 13:52, Thiago Milczarek Say?o <
    thiago.sayao at gmail.com> escreveu:
    
    > Hi Dirk,
    >
    > I have tried your example, it seems the window manager is denying the
    > application from being moved into negative coordinates, unless using the
    > window manager itself.
    >
    > It might be due to security reasons, but that's just me wondering.
    >
    > It might have a different behaviour on other window managers (modern gnome
    > uses mutter).
    >
    >
    >
    > Em ter., 11 de out. de 2022 ?s 12:37, Dirk Lemmermann <
    > dlemmermann at gmail.com> escreveu:
    >
    >> I just ran into this issue: https://bugs.openjdk.org/browse/JDK-8222794
    >>
    >> The ticket is closed and marked as ?not an issue?. Unfortunately there is
    >> no description why this is not an issue.
    >>
    >> In our app we removed the window decorations of our main stage and use a
    >> custom design. For this to work we also have to reimplement the moving /
    >> dragging around of the window but with the limitation expressed by the
    >> ticket this seems to be impossible.
    >>
    >> I don?t really see a good reason why programmatically setting the x- or
    >> y-coordinate should not result in the window being shown on a different
    >> screen. However, I am open for being told why that is :-)
    >>
    >> Dirk
    >>
    >>
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From angorya at openjdk.org  Tue Oct 11 20:32:47 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Tue, 11 Oct 2022 20:32:47 GMT
    Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v4]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose().
    > 
    > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler.
    > See https://github.com/openjdk/jfx/pull/908
    
    Andy Goryachev has updated the pull request incrementally with three additional commits since the last revision:
    
     - Merge branch '8294809.listener.helper' into 8294589.menubarskin.leak
     - 8294809: whitespace
     - 8294589: whitespace
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/906/files
      - new: https://git.openjdk.org/jfx/pull/906/files/5e1cef12..f1b2d931
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=03
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=02-03
    
      Stats: 13 lines in 2 files changed: 1 ins; 0 del; 12 mod
      Patch: https://git.openjdk.org/jfx/pull/906.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906
    
    PR: https://git.openjdk.org/jfx/pull/906
    
    From angorya at openjdk.org  Tue Oct 11 20:37:11 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Tue, 11 Oct 2022 20:37:11 GMT
    Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v5]
    In-Reply-To: 
    References: 
    Message-ID: <-3JV6Ty3e3BgTFWKR4ryjnn9cb8FBKht5bRybaPIE7w=.33fcabc1-684e-45f9-93f1-8b6dc5debe40@github.com>
    
    > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose().
    > 
    > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler.
    > See https://github.com/openjdk/jfx/pull/908
    
    Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
    
      8294589: whitespace
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/906/files
      - new: https://git.openjdk.org/jfx/pull/906/files/f1b2d931..43841d5e
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=04
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=03-04
    
      Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod
      Patch: https://git.openjdk.org/jfx/pull/906.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906
    
    PR: https://git.openjdk.org/jfx/pull/906
    
    From tom.schindl at bestsolution.at  Tue Oct 11 21:21:45 2022
    From: tom.schindl at bestsolution.at (Tom Schindl)
    Date: Tue, 11 Oct 2022 23:21:45 +0200
    Subject: Negative coordinates do not work on Linux(Gnome), but on Windows 
    In-Reply-To: 
    References: 
    Message-ID: <82A3CB2B-6D76-4D1E-9A47-4EF18A39F4A4@bestsolution.at>
    
    An HTML attachment was scrubbed...
    URL: 
    
    From kcr at openjdk.org  Tue Oct 11 21:52:15 2022
    From: kcr at openjdk.org (Kevin Rushforth)
    Date: Tue, 11 Oct 2022 21:52:15 GMT
    Subject: RFR: 8287822: [macos] Remove support of duplicated formats from
     macOS
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Tue, 11 Oct 2022 00:01:18 GMT, Alexander Matveev  wrote:
    
    > - Added support for JAR and JRT protocol to AVFoundation platform.
    >  - Removed H.264/MP3 and AAC support from GStreamer platform, which was primary used to playback these formats for JAR and JRT protocols.
    >  - Added ability to FXMediaPlayer sample to generate playlist for JAR and JRT protocols for testing. See FXMedia.java for how to use it.
    >  - H.265/HEVC via JAR/JRT protocols should work on macOS after this change. Before it did not work because GStreamer platform did not support H.265/HEVC and AVFoundation did not support JAR/JRT protocols.
    >  - Minor code clean up.
    > 
    > After this changes:
    > GSTPlatform: AIFF and WAV for all protocols.
    > AVFoundation: MP3, AAC, HLS, H.264 and H.265 for all protocols.
    > 
    > This change is transparent for end user and does not affect list of supported formats by JavaFX Media.
    
    I left a few comments. I'll want to do some quick testing, but don't have time today.
    
    I presume you have carefully tested this on macOS. Have you done some minimal testing on Windows and Linux, too (since there are platform-independent changes)?
    
    modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/platform/gstreamer/GSTMedia.java line 95:
    
    > 93:                                           String contentType,
    > 94:                                           long sizeHint,
    > 95:                                           long[] nativeMediaHandle);
    
    This file contains whitespace-only changes. Maybe revert the file since it is otherwise unchanged?
    
    modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 89:
    
    > 87: 
    > 88: // Max number of bytes we will provide per request
    > 89: #define MAX_READ_SIZE 1048576
    
    Optional suggestion: define this as `(1024 * 1024)` ? It's OK to leave it as is if you prefer. Maybe add a comment in that case?
    
    modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 779:
    
    > 777: 
    > 778:         // Do not provide more then MAX_READ_SIZE at one call, otherwise
    > 779:         // AVFoundation might fail if we providing too much data.
    
    Minor: "providing" --> "provide"
    
    tests/manual/media/FXMediaPlayer/src/fxmediaplayer/media/FXMedia.java line 141:
    
    > 139:     }
    > 140: 
    > 141: }
    
    Minor: missing newline at end of file.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/909
    
    From kcr at openjdk.org  Tue Oct 11 21:52:17 2022
    From: kcr at openjdk.org (Kevin Rushforth)
    Date: Tue, 11 Oct 2022 21:52:17 GMT
    Subject: RFR: 8287822: [macos] Remove support of duplicated formats from
     macOS
    In-Reply-To: 
    References: 
     
    Message-ID: <35KRhzTe1DPOhJjYfTUBpSRL38uakb-74PZjhg3GDMM=.d454696c-cbfc-4226-afdd-c9d5e129d82f@github.com>
    
    On Tue, 11 Oct 2022 15:44:46 GMT, Andy Goryachev  wrote:
    
    >> - Added support for JAR and JRT protocol to AVFoundation platform.
    >>  - Removed H.264/MP3 and AAC support from GStreamer platform, which was primary used to playback these formats for JAR and JRT protocols.
    >>  - Added ability to FXMediaPlayer sample to generate playlist for JAR and JRT protocols for testing. See FXMedia.java for how to use it.
    >>  - H.265/HEVC via JAR/JRT protocols should work on macOS after this change. Before it did not work because GStreamer platform did not support H.265/HEVC and AVFoundation did not support JAR/JRT protocols.
    >>  - Minor code clean up.
    >> 
    >> After this changes:
    >> GSTPlatform: AIFF and WAV for all protocols.
    >> AVFoundation: MP3, AAC, HLS, H.264 and H.265 for all protocols.
    >> 
    >> This change is transparent for end user and does not affect list of supported formats by JavaFX Media.
    >
    > modules/javafx.media/src/main/native/jfxmedia/Locator/Locator.cpp line 73:
    > 
    >> 71:     if (javaEnv.clearException())
    >> 72:         return NULL;
    >> 73: 
    > 
    > minor: would it make sense to wrap return in { }, line 67 and 72?
    
    A lot of our third-party native code doesn't (I would insist on the `{}` if this were Java code), so if this were a gstreamer file it would be better to follow their convention, but since this is entirely our code, it makes sense to enclose in `{}`.
    
    > tests/manual/media/FXMediaPlayer/src/fxmediaplayer/media/FXMedia.java line 66:
    > 
    >> 64:  * [Windows] jlink --output dist/FXMediaPlayer -p ../../../../build/jmods;dist --add-modules javafx.base,javafx.controls,javafx.media,javafx.graphics,FXMediaPlayer --launcher FXMediaPlayer=FXMediaPlayer/fxmediaplayer.FXMediaPlayer
    >> 65:  * [Windows] dist\FXMediaPlayer\bin\FXMediaPlayer.bat
    >> 66:  */
    > 
    > minor: this javadoc will likely not render as expected.  perhaps use 
     from line 50 to 61 or 65.
    > also, spelling "protcol" on line 50
    
    Also minor: you can shorten the command lines by removing `javafx.base` and `javafx.graphics` from the list of added modules, since `javafx.controls` transiently requires them.
    
    > tests/manual/media/FXMediaPlayer/src/fxmediaplayer/media/FXMedia.java line 97:
    > 
    >> 95:                 uri = FXMedia.class.getResource("/fxmediaplayer/media").toURI();
    >> 96: 
    >> 97:                 if (uri.getScheme().equals("jar")) {
    > 
    > is it possible for uri scheme to be null?
    > may be "jar".equals(uri.getScheme()) ?
    
    Related question: Can `uri` itself be null?
    
    > tests/manual/media/FXMediaPlayer/src/fxmediaplayer/media/FXMedia.java line 131:
    > 
    >> 129:             });
    >> 130:         } catch (URISyntaxException | IOException ex) {
    >> 131:             System.out.println("Exception: " + ex);
    > 
    > should System.out be removed?
    > 
    > general question: do we want to use logging in places like this?
    
    Since this is a test app, I wouldn't bother with logging. We generally would use `System.err` rather than `System.out` for printing exceptions, but that's a minor point.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/909
    
    From angorya at openjdk.org  Tue Oct 11 23:19:41 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Tue, 11 Oct 2022 23:19:41 GMT
    Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v6]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose().
    > 
    > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler.
    > See https://github.com/openjdk/jfx/pull/908
    
    Andy Goryachev has updated the pull request incrementally with four additional commits since the last revision:
    
     - 8294589: register
     - Merge branch '8294809.listener.helper' into 8294589.menubarskin.leak
     - 8294809: change listener with callback
     - 8294809: skin base
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/906/files
      - new: https://git.openjdk.org/jfx/pull/906/files/43841d5e..21fc352e
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=05
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=04-05
    
      Stats: 102 lines in 3 files changed: 92 ins; 6 del; 4 mod
      Patch: https://git.openjdk.org/jfx/pull/906.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906
    
    PR: https://git.openjdk.org/jfx/pull/906
    
    From angorya at openjdk.org  Wed Oct 12 15:33:53 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 12 Oct 2022 15:33:53 GMT
    Subject: RFR: 8293119: Alternative CONSTRAINED_RESIZE_POLICY
    Message-ID: 
    
    The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
    
    We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
    
    - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
    - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
    - add corresponding public static constants to Tree/TableView
    - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
    - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase
    - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
    - update javadoc
    
    
    Notes
    
    1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
    2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.
    
    -------------
    
    Commit messages:
     - 8293119: javadoc
     - Merge remote-tracking branch 'origin/master' into 8293119.constrained
     - 8293119: whitespace + javadoc
     - 8293119: show right boundary when needed
     - 8293119: not abstract
     - 8293119: whitespace
     - 8293119: cleanup
     - 8293119: cleanup
     - 8293119: test
     - 8293119: tester
     - ... and 37 more: https://git.openjdk.org/jfx/compare/9768b5e4...ec8ca564
    
    Changes: https://git.openjdk.org/jfx/pull/897/files
     Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=00
      Issue: https://bugs.openjdk.org/browse/JDK-8293119
      Stats: 2094 lines in 10 files changed: 1824 ins; 260 del; 10 mod
      Patch: https://git.openjdk.org/jfx/pull/897.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/897/head:pull/897
    
    PR: https://git.openjdk.org/jfx/pull/897
    
    From mhanl at openjdk.org  Wed Oct 12 15:33:54 2022
    From: mhanl at openjdk.org (Marius Hanl)
    Date: Wed, 12 Oct 2022 15:33:54 GMT
    Subject: RFR: 8293119: Alternative CONSTRAINED_RESIZE_POLICY
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Mon, 12 Sep 2022 21:58:47 GMT, Andy Goryachev  wrote:
    
    > The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
    > 
    > We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
    > 
    > - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
    > - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
    > - add corresponding public static constants to Tree/TableView
    > - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
    > - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase
    > - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
    > - update javadoc
    > 
    > 
    > Notes
    > 
    > 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
    > 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.
    
    modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 440:
    
    > 438: 
    > 439:     // TODO to be renamed to CONSTRAINED_RESIZE_POLICY
    > 440:     public static final Callback CONSTRAINED_RESIZE_POLICY_SUBSEQUENT_COLUMNS =
    
    Instead of renaming we can also deprecate the 'old' `CONSTRAINED_RESIZE_POLICY` ?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/897
    
    From angorya at openjdk.org  Wed Oct 12 15:33:55 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 12 Oct 2022 15:33:55 GMT
    Subject: RFR: 8293119: Alternative CONSTRAINED_RESIZE_POLICY
    In-Reply-To: 
    References: 
     
    Message-ID: 
    
    On Wed, 14 Sep 2022 06:25:56 GMT, Marius Hanl  wrote:
    
    >> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
    >> 
    >> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
    >> 
    >> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
    >> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
    >> - add corresponding public static constants to Tree/TableView
    >> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
    >> - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase
    >> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
    >> - update javadoc
    >> 
    >> 
    >> Notes
    >> 
    >> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
    >> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.
    >
    > modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 440:
    > 
    >> 438: 
    >> 439:     // TODO to be renamed to CONSTRAINED_RESIZE_POLICY
    >> 440:     public static final Callback CONSTRAINED_RESIZE_POLICY_SUBSEQUENT_COLUMNS =
    > 
    > Instead of renaming we can also deprecate the 'old' `CONSTRAINED_RESIZE_POLICY` ?
    
    Good question.
    
    We could deprecate the old policy, although leaving it as is also leaves all its issues in place (see JDK-8292810).  There is a subtle behavioral difference between the old CONSTRAINED_RESIZE_POLICY and CONSTRAINED_RESIZE_POLICY_SUBSEQUENT_COLUMNS that people might notice and may not like.  The difference is that the old policy works similar to CONSTRAINED_RESIZE_POLICY_LAST_COLUMN until the last column cannot be resized, then it resizes one before it.
    
    Another option is that we could add another policy which will work exactly (minus bugs) as the old one.  What do you think?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/897
    
    From angorya at openjdk.org  Wed Oct 12 15:33:56 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 12 Oct 2022 15:33:56 GMT
    Subject: RFR: 8293119: Alternative CONSTRAINED_RESIZE_POLICY
    In-Reply-To: 
    References: 
     
     
    Message-ID: 
    
    On Wed, 14 Sep 2022 15:25:16 GMT, Andy Goryachev  wrote:
    
    >> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 440:
    >> 
    >>> 438: 
    >>> 439:     // TODO to be renamed to CONSTRAINED_RESIZE_POLICY
    >>> 440:     public static final Callback CONSTRAINED_RESIZE_POLICY_SUBSEQUENT_COLUMNS =
    >> 
    >> Instead of renaming we can also deprecate the 'old' `CONSTRAINED_RESIZE_POLICY` ?
    >
    > Good question.
    > 
    > We could deprecate the old policy, although leaving it as is also leaves all its issues in place (see JDK-8292810).  There is a subtle behavioral difference between the old CONSTRAINED_RESIZE_POLICY and CONSTRAINED_RESIZE_POLICY_SUBSEQUENT_COLUMNS that people might notice and may not like.  The difference is that the old policy works similar to CONSTRAINED_RESIZE_POLICY_LAST_COLUMN until the last column cannot be resized, then it resizes one before it.
    > 
    > Another option is that we could add another policy which will work exactly (minus bugs) as the old one.  What do you think?
    
    Try tests/manual/controls/ATableViewResizeTester.java to see the behavior.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/897
    
    From mhanl at openjdk.org  Wed Oct 12 15:33:56 2022
    From: mhanl at openjdk.org (Marius Hanl)
    Date: Wed, 12 Oct 2022 15:33:56 GMT
    Subject: RFR: 8293119: Alternative CONSTRAINED_RESIZE_POLICY
    In-Reply-To: 
    References: 
     
     
     
    Message-ID: 
    
    On Wed, 14 Sep 2022 15:26:03 GMT, Andy Goryachev  wrote:
    
    >> Good question.
    >> 
    >> We could deprecate the old policy, although leaving it as is also leaves all its issues in place (see JDK-8292810).  There is a subtle behavioral difference between the old CONSTRAINED_RESIZE_POLICY and CONSTRAINED_RESIZE_POLICY_SUBSEQUENT_COLUMNS that people might notice and may not like.  The difference is that the old policy works similar to CONSTRAINED_RESIZE_POLICY_LAST_COLUMN until the last column cannot be resized, then it resizes one before it.
    >> 
    >> Another option is that we could add another policy which will work exactly (minus bugs) as the old one.  What do you think?
    >
    > Try tests/manual/controls/ATableViewResizeTester.java to see the behavior.
    
    > We could deprecate the old policy, although leaving it as is also leaves all its issues in place (see JDK-8292810). There is a subtle behavioral difference between the old CONSTRAINED_RESIZE_POLICY and CONSTRAINED_RESIZE_POLICY_SUBSEQUENT_COLUMNS that people might notice and may not like. The difference is that the old policy works similar to CONSTRAINED_RESIZE_POLICY_LAST_COLUMN until the last column cannot be resized, then it resizes one before it.
    > 
    > Another option is that we could add another policy which will work exactly (minus bugs) as the old one. What do you think?
    
    I like that all new constrained resize policies have a more describing name and I think we should stick to it, therefore I'm in favor of deprecating the 'old', more generic named resize policy.
    Regarding the behaviour change, we may want to implement a constrained resize policy which does the same as the old one, but without bugs and a name similar to the other ones.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/897
    
    From angorya at openjdk.org  Wed Oct 12 21:05:48 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 12 Oct 2022 21:05:48 GMT
    Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners
    Message-ID: 
    
    Introduction
    
    There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class).
    
    This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance
    https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java
    
    Proposal
    
    It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which:
    
    - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc.
    - keeps track of the listeners and the corresponding ObservableValues
    - provides a single disconnect() method to remove all the listeners in one go.
    - optionally, it should be possible to add a lambda (Runnable) to a group of properties
    - optionally, there should be a boolean flag to fire the lambda immediately
    - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method
    
    Make it Public Later
    
    Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later.
    
    Where It Will Be Useful
    
    [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin"
    and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler.
    
    https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft
    
    -------------
    
    Commit messages:
     - 8294809: use weak reference correctly this time
     - 8294809: tests
     - 8294809: remove
     - 8294809: change listener with callback
     - 8294809: skin base
     - 8294809: whitespace
     - 8294809: event handlers and filters
     - 8294809: cleanup
     - 8294809: override
     - 8294809: null checks
     - ... and 4 more: https://git.openjdk.org/jfx/compare/9768b5e4...af77693c
    
    Changes: https://git.openjdk.org/jfx/pull/908/files
     Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=00
      Issue: https://bugs.openjdk.org/browse/JDK-8294809
      Stats: 1498 lines in 4 files changed: 1495 ins; 2 del; 1 mod
      Patch: https://git.openjdk.org/jfx/pull/908.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/908/head:pull/908
    
    PR: https://git.openjdk.org/jfx/pull/908
    
    From almatvee at openjdk.org  Wed Oct 12 22:42:52 2022
    From: almatvee at openjdk.org (Alexander Matveev)
    Date: Wed, 12 Oct 2022 22:42:52 GMT
    Subject: RFR: 8287822: [macos] Remove support of duplicated formats from
     macOS [v2]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > - Added support for JAR and JRT protocol to AVFoundation platform.
    >  - Removed H.264/MP3 and AAC support from GStreamer platform, which was primary used to playback these formats for JAR and JRT protocols.
    >  - Added ability to FXMediaPlayer sample to generate playlist for JAR and JRT protocols for testing. See FXMedia.java for how to use it.
    >  - H.265/HEVC via JAR/JRT protocols should work on macOS after this change. Before it did not work because GStreamer platform did not support H.265/HEVC and AVFoundation did not support JAR/JRT protocols.
    >  - Minor code clean up.
    > 
    > After this changes:
    > GSTPlatform: AIFF and WAV for all protocols.
    > AVFoundation: MP3, AAC, HLS, H.264 and H.265 for all protocols.
    > 
    > This change is transparent for end user and does not affect list of supported formats by JavaFX Media.
    
    Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
    
      8287822: [macos] Remove support of duplicated formats from macOS [v2]
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/909/files
      - new: https://git.openjdk.org/jfx/pull/909/files/3a0cc087..9b76b9e9
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=909&range=01
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=909&range=00-01
    
      Stats: 15 lines in 4 files changed: 4 ins; 0 del; 11 mod
      Patch: https://git.openjdk.org/jfx/pull/909.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/909/head:pull/909
    
    PR: https://git.openjdk.org/jfx/pull/909
    
    From almatvee at openjdk.org  Wed Oct 12 22:42:53 2022
    From: almatvee at openjdk.org (Alexander Matveev)
    Date: Wed, 12 Oct 2022 22:42:53 GMT
    Subject: RFR: 8287822: [macos] Remove support of duplicated formats from
     macOS
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Tue, 11 Oct 2022 00:01:18 GMT, Alexander Matveev  wrote:
    
    > - Added support for JAR and JRT protocol to AVFoundation platform.
    >  - Removed H.264/MP3 and AAC support from GStreamer platform, which was primary used to playback these formats for JAR and JRT protocols.
    >  - Added ability to FXMediaPlayer sample to generate playlist for JAR and JRT protocols for testing. See FXMedia.java for how to use it.
    >  - H.265/HEVC via JAR/JRT protocols should work on macOS after this change. Before it did not work because GStreamer platform did not support H.265/HEVC and AVFoundation did not support JAR/JRT protocols.
    >  - Minor code clean up.
    > 
    > After this changes:
    > GSTPlatform: AIFF and WAV for all protocols.
    > AVFoundation: MP3, AAC, HLS, H.264 and H.265 for all protocols.
    > 
    > This change is transparent for end user and does not affect list of supported formats by JavaFX Media.
    
    I did full testing on all three platforms and tested all formats via all protocols. Mostly to make sure that changes for FXMediaPlayer works on all platforms.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/909
    
    From almatvee at openjdk.org  Wed Oct 12 22:42:57 2022
    From: almatvee at openjdk.org (Alexander Matveev)
    Date: Wed, 12 Oct 2022 22:42:57 GMT
    Subject: RFR: 8287822: [macos] Remove support of duplicated formats from
     macOS [v2]
    In-Reply-To: 
    References: 
     
    Message-ID: 
    
    On Tue, 11 Oct 2022 21:07:34 GMT, Kevin Rushforth  wrote:
    
    >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
    >> 
    >>   8287822: [macos] Remove support of duplicated formats from macOS [v2]
    >
    > modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/platform/gstreamer/GSTMedia.java line 95:
    > 
    >> 93:                                           String contentType,
    >> 94:                                           long sizeHint,
    >> 95:                                           long[] nativeMediaHandle);
    > 
    > This file contains whitespace-only changes. Maybe revert the file since it is otherwise unchanged?
    
    Reverted.
    
    > modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 89:
    > 
    >> 87: 
    >> 88: // Max number of bytes we will provide per request
    >> 89: #define MAX_READ_SIZE 1048576
    > 
    > Optional suggestion: define this as `(1024 * 1024)` ? It's OK to leave it as is if you prefer. Maybe add a comment in that case?
    
    Fixed.
    
    > modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 779:
    > 
    >> 777: 
    >> 778:         // Do not provide more then MAX_READ_SIZE at one call, otherwise
    >> 779:         // AVFoundation might fail if we providing too much data.
    > 
    > Minor: "providing" --> "provide"
    
    Fixed.
    
    > tests/manual/media/FXMediaPlayer/src/fxmediaplayer/media/FXMedia.java line 141:
    > 
    >> 139:     }
    >> 140: 
    >> 141: }
    > 
    > Minor: missing newline at end of file.
    
    Fixed.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/909
    
    From almatvee at openjdk.org  Wed Oct 12 22:43:00 2022
    From: almatvee at openjdk.org (Alexander Matveev)
    Date: Wed, 12 Oct 2022 22:43:00 GMT
    Subject: RFR: 8287822: [macos] Remove support of duplicated formats from
     macOS [v2]
    In-Reply-To: <35KRhzTe1DPOhJjYfTUBpSRL38uakb-74PZjhg3GDMM=.d454696c-cbfc-4226-afdd-c9d5e129d82f@github.com>
    References: 
     
     <35KRhzTe1DPOhJjYfTUBpSRL38uakb-74PZjhg3GDMM=.d454696c-cbfc-4226-afdd-c9d5e129d82f@github.com>
    Message-ID: 
    
    On Tue, 11 Oct 2022 21:19:05 GMT, Kevin Rushforth  wrote:
    
    >> modules/javafx.media/src/main/native/jfxmedia/Locator/Locator.cpp line 73:
    >> 
    >>> 71:     if (javaEnv.clearException())
    >>> 72:         return NULL;
    >>> 73: 
    >> 
    >> minor: would it make sense to wrap return in { }, line 67 and 72?
    >
    > A lot of our third-party native code doesn't (I would insist on the `{}` if this were Java code), so if this were a gstreamer file it would be better to follow their convention, but since this is entirely our code, it makes sense to enclose in `{}`.
    
    Fixed.
    
    >> tests/manual/media/FXMediaPlayer/src/fxmediaplayer/media/FXMedia.java line 66:
    >> 
    >>> 64:  * [Windows] jlink --output dist/FXMediaPlayer -p ../../../../build/jmods;dist --add-modules javafx.base,javafx.controls,javafx.media,javafx.graphics,FXMediaPlayer --launcher FXMediaPlayer=FXMediaPlayer/fxmediaplayer.FXMediaPlayer
    >>> 65:  * [Windows] dist\FXMediaPlayer\bin\FXMediaPlayer.bat
    >>> 66:  */
    >> 
    >> minor: this javadoc will likely not render as expected.  perhaps use 
     from line 50 to 61 or 65.
    >> also, spelling "protcol" on line 50
    >
    > Also minor: you can shorten the command lines by removing `javafx.base` and `javafx.graphics` from the list of added modules, since `javafx.controls` transiently requires them.
    
    Spelling fixed and javafx.base and javafx.graphics is removed. I do not think that we need to worry about javadoc, since we do not generate it for this app.
    
    >> tests/manual/media/FXMediaPlayer/src/fxmediaplayer/media/FXMedia.java line 131:
    >> 
    >>> 129:             });
    >>> 130:         } catch (URISyntaxException | IOException ex) {
    >>> 131:             System.out.println("Exception: " + ex);
    >> 
    >> should System.out be removed?
    >> 
    >> general question: do we want to use logging in places like this?
    >
    > Since this is a test app, I wouldn't bother with logging. We generally would use `System.err` rather than `System.out` for printing exceptions, but that's a minor point.
    
    I change it to System.err.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/909
    
    From almatvee at openjdk.org  Wed Oct 12 22:43:02 2022
    From: almatvee at openjdk.org (Alexander Matveev)
    Date: Wed, 12 Oct 2022 22:43:02 GMT
    Subject: RFR: 8287822: [macos] Remove support of duplicated formats from
     macOS [v2]
    In-Reply-To: 
    References: 
     
    Message-ID: 
    
    On Tue, 11 Oct 2022 15:37:15 GMT, Andy Goryachev  wrote:
    
    >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
    >> 
    >>   8287822: [macos] Remove support of duplicated formats from macOS [v2]
    >
    > tests/manual/media/FXMediaPlayer/src/fxmediaplayer/FXMediaPlayer.java line 165:
    > 
    >> 163: 
    >> 164:         // Create Media, MediaPlayer, MediaView and ImageView
    >> 165:         System.out.println("FXMediaPlayer source: " + source);
    > 
    > probably needs to be removed?
    
    No, I done it on purpose to see which files we loading. Makes it easy to test a lot of files via playlist.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/909
    
    From angorya at openjdk.org  Wed Oct 12 23:00:14 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 12 Oct 2022 23:00:14 GMT
    Subject: RFR: 8287822: [macos] Remove support of duplicated formats from
     macOS [v2]
    In-Reply-To: 
    References: 
     
     <35KRhzTe1DPOhJjYfTUBpSRL38uakb-74PZjhg3GDMM=.d454696c-cbfc-4226-afdd-c9d5e129d82f@github.com>
     
    Message-ID: 
    
    On Wed, 12 Oct 2022 22:36:09 GMT, Alexander Matveev  wrote:
    
    >> Also minor: you can shorten the command lines by removing `javafx.base` and `javafx.graphics` from the list of added modules, since `javafx.controls` transiently requires them.
    >
    > Spelling fixed and javafx.base and javafx.graphics is removed. I do not think that we need to worry about javadoc, since we do not generate it for this app.
    
    This is just a suggestion, really, especially if it is in test code.
    However, Eclipse IDE shows javadoc (something I routinely use, the javadoc tab is always open):
    
    Screen Shot 2022-10-12 at 15 55 55
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/909
    
    From mhanl at openjdk.org  Thu Oct 13 01:41:11 2022
    From: mhanl at openjdk.org (Marius Hanl)
    Date: Thu, 13 Oct 2022 01:41:11 GMT
    Subject: RFR: 8295078: TextField blurry when inside an TitledPane ->
     AnchorPane [v2]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > The problem here is, that the `AnchorPane` does not use its snapped insets.
    > Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods.
    > 
    > Note: The reason the `AnchorPane` inside  a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content.
    > Line 2995 in `modena.css`:
    > 
    > .titled-pane > .content > AnchorPane {
    >     -fx-padding: 0.8em;
    > }
    > 
    > which translates to 9.6px.
    > 
    > EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource`
    
    Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
    
      8295078: Adjusted Copyright year
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/910/files
      - new: https://git.openjdk.org/jfx/pull/910/files/a8e6e508..901416db
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=910&range=01
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=910&range=00-01
    
      Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
      Patch: https://git.openjdk.org/jfx/pull/910.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/910/head:pull/910
    
    PR: https://git.openjdk.org/jfx/pull/910
    
    From almatvee at openjdk.org  Thu Oct 13 04:25:19 2022
    From: almatvee at openjdk.org (Alexander Matveev)
    Date: Thu, 13 Oct 2022 04:25:19 GMT
    Subject: RFR: 8287822: [macos] Remove support of duplicated formats from
     macOS [v3]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > - Added support for JAR and JRT protocol to AVFoundation platform.
    >  - Removed H.264/MP3 and AAC support from GStreamer platform, which was primary used to playback these formats for JAR and JRT protocols.
    >  - Added ability to FXMediaPlayer sample to generate playlist for JAR and JRT protocols for testing. See FXMedia.java for how to use it.
    >  - H.265/HEVC via JAR/JRT protocols should work on macOS after this change. Before it did not work because GStreamer platform did not support H.265/HEVC and AVFoundation did not support JAR/JRT protocols.
    >  - Minor code clean up.
    > 
    > After this changes:
    > GSTPlatform: AIFF and WAV for all protocols.
    > AVFoundation: MP3, AAC, HLS, H.264 and H.265 for all protocols.
    > 
    > This change is transparent for end user and does not affect list of supported formats by JavaFX Media.
    
    Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
    
      8287822: [macos] Remove support of duplicated formats from macOS [v3]
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/909/files
      - new: https://git.openjdk.org/jfx/pull/909/files/9b76b9e9..d4eaaa89
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=909&range=02
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=909&range=01-02
    
      Stats: 22 lines in 1 file changed: 16 ins; 0 del; 6 mod
      Patch: https://git.openjdk.org/jfx/pull/909.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/909/head:pull/909
    
    PR: https://git.openjdk.org/jfx/pull/909
    
    From almatvee at openjdk.org  Thu Oct 13 04:25:20 2022
    From: almatvee at openjdk.org (Alexander Matveev)
    Date: Thu, 13 Oct 2022 04:25:20 GMT
    Subject: RFR: 8287822: [macos] Remove support of duplicated formats from
     macOS [v3]
    In-Reply-To: 
    References: 
     
     <35KRhzTe1DPOhJjYfTUBpSRL38uakb-74PZjhg3GDMM=.d454696c-cbfc-4226-afdd-c9d5e129d82f@github.com>
     
     
    Message-ID: 
    
    On Wed, 12 Oct 2022 22:57:51 GMT, Andy Goryachev  wrote:
    
    >> Spelling fixed and javafx.base and javafx.graphics is removed. I do not think that we need to worry about javadoc, since we do not generate it for this app.
    >
    > This is just a suggestion, really, especially if it is in test code.
    > However, Eclipse IDE shows javadoc (something I routinely use, the javadoc tab is always open):
    > 
    > Screen Shot 2022-10-12 at 15 55 55
    
    Fixed.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/909
    
    From john.hendrikx at gmail.com  Thu Oct 13 06:40:46 2022
    From: john.hendrikx at gmail.com (John Hendrikx)
    Date: Thu, 13 Oct 2022 08:40:46 +0200
    Subject: RFR: 8294809: ListenerHelper for managing and disconnecting
     listeners
    In-Reply-To: 
    References: 
    Message-ID: <095d4083-1e54-1a81-4563-3ba14aaf7353@gmail.com>
    
    Hi Andy,
    
    There is another PR that will help with this: 
    https://github.com/openjdk/jfx/pull/830
    
    It adds a `when` method on `ObservableValue`:
    
     ????? default ObservableValue when(ObservableValue condition)
    
    This method can be used for all kinds of things, and one of them is that 
    it could be used to manage listeners.
    
    It would work like this:
    
     ? ? ObservableValue active = new SimpleBooleanProperty(true);
    
     ? ? MySkin() {
    getSkinnable().textProperty().when(active).addListener(this::updateSkinStuffs);
    getSkinnable().fontProperty().when(active).addListener(this::updateSkinStuffs);
    getSkinnable().wrapTextProperty().when(active).addListener(this::updateSkinStuffs);
     ? ? }
    
     ? ? void dispose() {
     ? ?? ??? active.set(false);? // kills all listeners/bindings/etc in a 
    single line
     ? ? }
    
    Also, it's possible to extend (and later expose) the 
    `com.sun.javafx.binding.Subscription` class, which can help as well:
    
    It has these methods, but more can be added:
    
     ???? Subscription subscribe(ObservableValue observableValue, 
    Consumer subscriber)
    
     ?? ? Subscription subscribeInvalidations(ObservableValue 
    observableValue, Runnable runnable)
    
    It could be used like this to manage subscriptions:
    
     ???? Subscription subscription = 
    Subscription.subscribe(label.textProperty(), value -> { ... } );
    
    Subscriptions can be chained:
    
     ???? Subscription subscription = 
    Subscription.subscribe(label.textProperty(), value -> { ... } )
     ??????????? .and(Subscription.subscribe(label.fontProperty(), value -> 
    { ... } )
     ??????????? .and(Subscription.subscribe(label.wrapTextProperty(), value 
    -> { ... } );
    
    They can then be released all at once by doing:
    
     ???? subscription.unsubscribe();
    
    Reading your proposal I see you might be looking to support weak 
    listeners as well. Personally, I believe these are better replaced with 
    lazy listeners (via `ObservableValue`'s fluent methods) instead of 
    doubling down on these and adding special support.
    
    Perhaps we can collaborate on this.? Nir Lisker also has interests in 
    this area I believe :-)
    
    I added some more comments inline.
    
    --John
    
    On 12/10/2022 23:05, Andy Goryachev wrote:
    > Introduction
    >
    > There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class).
    >
    > This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance
    > https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java
    >
    > Proposal
    >
    > It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which:
    >
    > - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc.
    `Subscription` has some of these, and the `when` proposal would not need 
    them as the original methods can be used.? For fluent bindings with 
    `when` weak listeners are probably not need at all.
    > - keeps track of the listeners and the corresponding ObservableValues
    Both `Subscription` and the `when` proposal could do this. `Subcription` 
    by keeping track of a result value, `when` by creating a boolean value 
    that can be toggled.? Note that the boolean value if toggled back to 
    `true` would resubscribe automatically -- it acts as a breaker between 
    the actual property and the listener that can turned on and off.
    > - provides a single disconnect() method to remove all the listeners in one go.
    Yes, `Subscription#unsubscribe` or for `when` by toggling the boolean 
    value to `false`.
    > - optionally, it should be possible to add a lambda (Runnable) to a group of properties
    
    I suppose that could be a signature like:
    
     ????? Subscription#subscribeInvalidations(Runnable runnable, 
    ObservableValue ... values);
    
    > - optionally, there should be a boolean flag to fire the lambda immediately
    I'm guessing you mean for invalidation listeners, as for change 
    listeners this already happens (this is not entirely clear, and not well 
    documented).? I do know that `Subscription#subscribe` with a `Consumer` 
    will always eagerly send you the current value.
    > - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method
    `Subscription` has this.
    > Make it Public Later
    >
    > Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later.
    >
    > Where It Will Be Useful
    >
    > [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin"
    > and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler.
    >
    > https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft
    >
    > -------------
    >
    > Commit messages:
    >   - 8294809: use weak reference correctly this time
    >   - 8294809: tests
    >   - 8294809: remove
    >   - 8294809: change listener with callback
    >   - 8294809: skin base
    >   - 8294809: whitespace
    >   - 8294809: event handlers and filters
    >   - 8294809: cleanup
    >   - 8294809: override
    >   - 8294809: null checks
    >   - ... and 4 more: https://git.openjdk.org/jfx/compare/9768b5e4...af77693c
    >
    > Changes: https://git.openjdk.org/jfx/pull/908/files
    >   Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=00
    >    Issue: https://bugs.openjdk.org/browse/JDK-8294809
    >    Stats: 1498 lines in 4 files changed: 1495 ins; 2 del; 1 mod
    >    Patch: https://git.openjdk.org/jfx/pull/908.diff
    >    Fetch: git fetch https://git.openjdk.org/jfx pull/908/head:pull/908
    >
    > PR: https://git.openjdk.org/jfx/pull/908
    
    From nlisker at gmail.com  Thu Oct 13 08:47:10 2022
    From: nlisker at gmail.com (Nir Lisker)
    Date: Thu, 13 Oct 2022 11:47:10 +0300
    Subject: RFR: 8294809: ListenerHelper for managing and disconnecting
     listeners
    In-Reply-To: <095d4083-1e54-1a81-4563-3ba14aaf7353@gmail.com>
    References: 
     <095d4083-1e54-1a81-4563-3ba14aaf7353@gmail.com>
    Message-ID: 
    
    Hi,
    
    I agree with John. The work on managing listeners has been in the works for
    a long while now and it provides a lot more flexibility for less technical
    debt. I have already reviewed his 'when' proposal (sans its implementation
    on Node) and I think that it's the way to go.
    Fluent bindings already existed for years in ReactFX, on which they are
    based. As such, the community has a lot of experience with its paradigms (I
    have used its Val/Var since 2016 continuously). 'when', which is called
    'conditionOn' in ReactFX, was proposed with the initial set of fluent
    bindings, but I suggested at the time to separate it to make the process
    more smooth and manageable (it's one of those special PRs that requires 3
    reviewers...).
    In addition, phase 2 of the plan is to expose Subscription as a public API.
    This should be sufficient to address these concerns.
    
    Listeners are deeply ingrained in JavaFX. This work is not done in a
    vacuum. For example, John recently found another issue with regards to GC,
    where ExpressionHelper still holds the value of the observable. These
    should be taken into account when making strides in this area,
    
    The history can be traced back through this (broken) thread:
    https://mail.openjdk.org/pipermail/openjfx-dev/2021-March/029405.html
    https://mail.openjdk.org/pipermail/openjfx-dev/2021-April/029574.html
    https://mail.openjdk.org/pipermail/openjfx-dev/2021-September/031952.html
    etc.
    
    On Thu, Oct 13, 2022 at 9:40 AM John Hendrikx 
    wrote:
    
    > Hi Andy,
    >
    > There is another PR that will help with this:
    > https://github.com/openjdk/jfx/pull/830
    >
    > It adds a `when` method on `ObservableValue`:
    >
    >        default ObservableValue when(ObservableValue condition)
    >
    > This method can be used for all kinds of things, and one of them is that
    > it could be used to manage listeners.
    >
    > It would work like this:
    >
    >      ObservableValue active = new SimpleBooleanProperty(true);
    >
    >      MySkin() {
    >
    > getSkinnable().textProperty().when(active).addListener(this::updateSkinStuffs);
    >
    > getSkinnable().fontProperty().when(active).addListener(this::updateSkinStuffs);
    >
    > getSkinnable().wrapTextProperty().when(active).addListener(this::updateSkinStuffs);
    >      }
    >
    >      void dispose() {
    >           active.set(false);  // kills all listeners/bindings/etc in a
    > single line
    >      }
    >
    > Also, it's possible to extend (and later expose) the
    > `com.sun.javafx.binding.Subscription` class, which can help as well:
    >
    > It has these methods, but more can be added:
    >
    >       Subscription subscribe(ObservableValue observableValue,
    > Consumer subscriber)
    >
    >       Subscription subscribeInvalidations(ObservableValue
    > observableValue, Runnable runnable)
    >
    > It could be used like this to manage subscriptions:
    >
    >       Subscription subscription =
    > Subscription.subscribe(label.textProperty(), value -> { ... } );
    >
    > Subscriptions can be chained:
    >
    >       Subscription subscription =
    > Subscription.subscribe(label.textProperty(), value -> { ... } )
    >              .and(Subscription.subscribe(label.fontProperty(), value ->
    > { ... } )
    >              .and(Subscription.subscribe(label.wrapTextProperty(), value
    > -> { ... } );
    >
    > They can then be released all at once by doing:
    >
    >       subscription.unsubscribe();
    >
    > Reading your proposal I see you might be looking to support weak
    > listeners as well. Personally, I believe these are better replaced with
    > lazy listeners (via `ObservableValue`'s fluent methods) instead of
    > doubling down on these and adding special support.
    >
    > Perhaps we can collaborate on this.  Nir Lisker also has interests in
    > this area I believe :-)
    >
    > I added some more comments inline.
    >
    > --John
    >
    > On 12/10/2022 23:05, Andy Goryachev wrote:
    > > Introduction
    > >
    > > There is a number of places where various listeners (strong as well as
    > weak) are added, to be later disconnected in one go. For example, Skin
    > implementations use dispose() method to clean up the listeners installed in
    > the corresponding Control (sometimes using
    > LambdaMultiplePropertyChangeListenerHandler class).
    > >
    > > This pattern is also used by app developers, but there is no public
    > utility class to do that, so every one must invent their own, see for
    > instance
    > >
    > https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java
    > >
    > > Proposal
    > >
    > > It might be beneficial to create a class (ListenerHelper, feel free to
    > suggest a better name) which:
    > >
    > > - provides convenient methods like addChangeListener,
    > addInvalidationListener, addWeakChangeListener, etc.
    > `Subscription` has some of these, and the `when` proposal would not need
    > them as the original methods can be used.  For fluent bindings with
    > `when` weak listeners are probably not need at all.
    > > - keeps track of the listeners and the corresponding ObservableValues
    > Both `Subscription` and the `when` proposal could do this. `Subcription`
    > by keeping track of a result value, `when` by creating a boolean value
    > that can be toggled.  Note that the boolean value if toggled back to
    > `true` would resubscribe automatically -- it acts as a breaker between
    > the actual property and the listener that can turned on and off.
    > > - provides a single disconnect() method to remove all the listeners in
    > one go.
    > Yes, `Subscription#unsubscribe` or for `when` by toggling the boolean
    > value to `false`.
    > > - optionally, it should be possible to add a lambda (Runnable) to a
    > group of properties
    >
    > I suppose that could be a signature like:
    >
    >        Subscription#subscribeInvalidations(Runnable runnable,
    > ObservableValue ... values);
    >
    > > - optionally, there should be a boolean flag to fire the lambda
    > immediately
    > I'm guessing you mean for invalidation listeners, as for change
    > listeners this already happens (this is not entirely clear, and not well
    > documented).  I do know that `Subscription#subscribe` with a `Consumer`
    > will always eagerly send you the current value.
    > > - strongly suggest implementing an IDisconnectable functional interface
    > with a single disconnect() method
    > `Subscription` has this.
    > > Make it Public Later
    > >
    > > Initially, I think we could place the new class in package
    > com.sun.javafx.scene.control; to be made publicly accessible later.
    > >
    > > Where It Will Be Useful
    > >
    > > [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589)
    > "MenuBarSkin: memory leak when changing skin"
    > > and other skins, as a replacement for
    > LambdaMultiplePropertyChangeListenerHandler.
    > >
    > >
    > https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft
    > >
    > > -------------
    > >
    > > Commit messages:
    > >   - 8294809: use weak reference correctly this time
    > >   - 8294809: tests
    > >   - 8294809: remove
    > >   - 8294809: change listener with callback
    > >   - 8294809: skin base
    > >   - 8294809: whitespace
    > >   - 8294809: event handlers and filters
    > >   - 8294809: cleanup
    > >   - 8294809: override
    > >   - 8294809: null checks
    > >   - ... and 4 more:
    > https://git.openjdk.org/jfx/compare/9768b5e4...af77693c
    > >
    > > Changes: https://git.openjdk.org/jfx/pull/908/files
    > >   Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=00
    > >    Issue: https://bugs.openjdk.org/browse/JDK-8294809
    > >    Stats: 1498 lines in 4 files changed: 1495 ins; 2 del; 1 mod
    > >    Patch: https://git.openjdk.org/jfx/pull/908.diff
    > >    Fetch: git fetch https://git.openjdk.org/jfx pull/908/head:pull/908
    > >
    > > PR: https://git.openjdk.org/jfx/pull/908
    >
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From dlemmermann at gmail.com  Thu Oct 13 10:11:04 2022
    From: dlemmermann at gmail.com (Dirk Lemmermann)
    Date: Thu, 13 Oct 2022 12:11:04 +0200
    Subject: Negative coordinates do not work on Linux(Gnome), but on Windows
    In-Reply-To: <82A3CB2B-6D76-4D1E-9A47-4EF18A39F4A4@bestsolution.at>
    References: 
     <82A3CB2B-6D76-4D1E-9A47-4EF18A39F4A4@bestsolution.at>
    Message-ID: 
    
    Should someone want to look into this issue then I can recommend using the ScreensView in the GemsFX project for debugging purposes. You can see it here: https://www.youtube.com/watch?v=Kv7jo9fF9tc 
    
    Dirk
    
    > On 11 Oct 2022, at 23:21, Tom Schindl  wrote:
    > 
    > As I have implemented something like this for Windows I can confirm that there you also need to use native win32 APIs for the move because only then you eg get docking and snapping correct which does not work if you use the FX-Stage APIs!
    > 
    > For OS-X I?d have to look up the code because I can not member it.
    > 
    > Tom
    > 
    > Von meinem iPhone gesendet
    > 
    >> Am 11.10.2022 um 22:23 schrieb Thiago Milczarek Say?o :
    >> 
    >> ?
    >> Hi,
    >> 
    >> The correct way to implement this on Linux would be:
    >> 
    >> https://specifications.freedesktop.org/wm-spec/wm-spec-1.4.html 
    >> _NET_WM_MOVERESIZE
    >> 
    >> We would need to implement a specific API to do this.
    >> 
    >> This specification is to tell the Window Manager: Start a window move operation.
    >> 
    >> -- Thiago.
    >> 
    >> Em ter., 11 de out. de 2022 ?s 13:52, Thiago Milczarek Say?o > escreveu:
    >> Hi Dirk,
    >> 
    >> I have tried your example, it seems the window manager is denying the application from being moved into negative coordinates, unless using the window manager itself.
    >> 
    >> It might be due to security reasons, but that's just me wondering.
    >> 
    >> It might have a different behaviour on other window managers (modern gnome uses mutter).
    >> 
    >> 
    >> 
    >> Em ter., 11 de out. de 2022 ?s 12:37, Dirk Lemmermann > escreveu:
    >> I just ran into this issue: https://bugs.openjdk.org/browse/JDK-8222794 
    >> 
    >> The ticket is closed and marked as ?not an issue?. Unfortunately there is no description why this is not an issue.
    >> 
    >> In our app we removed the window decorations of our main stage and use a custom design. For this to work we also have to reimplement the moving / dragging around of the window but with the limitation expressed by the ticket this seems to be impossible.
    >> 
    >> I don?t really see a good reason why programmatically setting the x- or y-coordinate should not result in the window being shown on a different screen. However, I am open for being told why that is :-)
    >> 
    >> Dirk
    >> 
    
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From duke at openjdk.org  Thu Oct 13 11:38:58 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Thu, 13 Oct 2022 11:38:58 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D
    Message-ID: 
    
    The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. I also changed formatting in the method signatures of equals(), hashCode() and toString().
    
    For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    
    -------------
    
    Commit messages:
     - Update JavaDoc in javafx.geometry.Point3D
    
    Changes: https://git.openjdk.org/jfx/pull/913/files
     Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=913&range=00
      Issue: https://bugs.openjdk.org/browse/JDK-8295236
      Stats: 11 lines in 1 file changed: 6 ins; 0 del; 5 mod
      Patch: https://git.openjdk.org/jfx/pull/913.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/913/head:pull/913
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From kcr at openjdk.org  Thu Oct 13 11:38:58 2022
    From: kcr at openjdk.org (Kevin Rushforth)
    Date: Thu, 13 Oct 2022 11:38:58 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Wed, 12 Oct 2022 17:28:42 GMT, Douglas Held  wrote:
    
    > The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. I also changed formatting in the method signatures of equals(), hashCode() and toString().
    > 
    > For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    
    This is now available in JBS as [JDK-8295236](https://bugs.openjdk.org/browse/JDK-8295236). Once you update the title of this PR ~~and fix your whitespace errors~~, it will be made `rfr`.
    
    Looks fine to me, but I'll let @arapte review and sponsor this.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From nlisker at openjdk.org  Thu Oct 13 14:20:17 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Thu, 13 Oct 2022 14:20:17 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D
    In-Reply-To: 
    References: 
    Message-ID: <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
    
    On Wed, 12 Oct 2022 17:28:42 GMT, Douglas Held  wrote:
    
    > The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. I also changed formatting in the method signatures of equals(), hashCode() and toString().
    > 
    > For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    
    Changes requested by nlisker (Reviewer).
    
    modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 413:
    
    > 411: 
    > 412:     /**
    > 413:      * Determines whether or not two objects are equal. Two instances of {@code Point3D}
    
    Since this object is known, I would start with "Determines if this point is equals to a given object".
    
    modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 414:
    
    > 412:     /**
    > 413:      * Determines whether or not two objects are equal. Two instances of {@code Point3D}
    > 414:      * are equal if the values of their x, y, and z properties are equal.
    
    I would even write "i.f.f" because it's bidirectional.
    
    Also, `x`, `y`, and `z` should be in `{@code}`.
    
    modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 415:
    
    > 413:      * Determines whether or not two objects are equal. Two instances of {@code Point3D}
    > 414:      * are equal if the values of their x, y, and z properties are equal.
    > 415:      * @param obj an object to be compared with this {@code Point3D}.
    
    We tend to put a new line before the tags to separate them from the description, not sure if it's enforced.
    
    modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 417:
    
    > 415:      * @param obj an object to be compared with this {@code Point3D}.
    > 416:      * @return true if the object to be compared is an instance of Point3D and
    > 417:      * has the same values; false otherwise.
    
    `true`, `Point3D` and `false` should be in `{@code}`.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From kcr at openjdk.org  Thu Oct 13 15:53:51 2022
    From: kcr at openjdk.org (Kevin Rushforth)
    Date: Thu, 13 Oct 2022 15:53:51 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Wed, 12 Oct 2022 17:28:42 GMT, Douglas Held  wrote:
    
    > The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. I also changed formatting in the method signatures of equals(), hashCode() and toString().
    > 
    > For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    
    A couple comments.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From kcr at openjdk.org  Thu Oct 13 15:53:54 2022
    From: kcr at openjdk.org (Kevin Rushforth)
    Date: Thu, 13 Oct 2022 15:53:54 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D
    In-Reply-To: <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
    References: 
     <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
    Message-ID: 
    
    On Thu, 13 Oct 2022 14:14:44 GMT, Nir Lisker  wrote:
    
    >> The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. I also changed formatting in the method signatures of equals(), hashCode() and toString().
    >> 
    >> For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    >
    > modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 414:
    > 
    >> 412:     /**
    >> 413:      * Determines whether or not two objects are equal. Two instances of {@code Point3D}
    >> 414:      * are equal if the values of their x, y, and z properties are equal.
    > 
    > I would even write "i.f.f" because it's bidirectional.
    > 
    > Also, `x`, `y`, and `z` should be in `{@code}`.
    
    I think this one is OK either as "if" or "if and only if" (if you do change it, I recommend spelling it out, although "iff" with no punctuation, would be acceptable). I agree with the request to use code style.
    
    > modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 415:
    > 
    >> 413:      * Determines whether or not two objects are equal. Two instances of {@code Point3D}
    >> 414:      * are equal if the values of their x, y, and z properties are equal.
    >> 415:      * @param obj an object to be compared with this {@code Point3D}.
    > 
    > We tend to put a new line before the tags to separate them from the description, not sure if it's enforced.
    
    Not strictly enforced, but adding a blank line does aid readability (of the source code...the generated docs don't care).
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From angorya at openjdk.org  Thu Oct 13 15:56:30 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Thu, 13 Oct 2022 15:56:30 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
    Message-ID: <24S2xIDXEseZu7VqN4evg9d3FLeAFnMY7y78E4FlG0E=.f1287216-7041-4f0b-afd7-cd6ae1061d4a@github.com>
    
    On Thu, 29 Sep 2022 15:02:13 GMT, John Hendrikx  wrote:
    
    >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`.
    >> 
    >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here).
    >> 
    >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property:
    >> 
    >>      label.textProperty().bind(longLivedProperty.when(label::isShowingProperty));
    >> 
    >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing.  When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`.  A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along.
    >> 
    >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR.
    >> 
    >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out.
    >> 
    >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window.
    >
    > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
    > 
    >  - Merge remote-tracking branch 'origin/master' into
    >    feature/conditional-bindings
    >    
    >    # Conflicts:
    >    #	modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java
    >  - Fix review comments
    >  - Add missing new line
    >  - Small wording fixes
    >  - Update javadoc of "when" with better phrasing
    >  - Rename showing property to shown as it is already used in subclasses
    >  - Add conditional bindings to ObservableValue
    >  - Change explanatory comment to block comment
    >  - Fix bug where ObjectBinding returns null when revalidated immediately
    >    
    >    Introduced with the fluent bindings PR
    
    modules/javafx.base/src/main/java/com/sun/javafx/binding/ConditionalBinding.java line 19:
    
    > 17: 
    > 18:         // condition is always observed and never unsubscribed
    > 19:         Subscription.subscribe(nonNullCondition, current -> {
    
    do I understand this correctly - if the transient Nodes are created and hooked up with ConditionalBinding and then discarded, we'll have a memory leak?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From tsayao at openjdk.org  Thu Oct 13 18:06:39 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Thu, 13 Oct 2022 18:06:39 GMT
    Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v27]
    In-Reply-To: 
    References: 
     
    Message-ID: 
    
    On Mon, 28 Jun 2021 23:50:31 GMT, Thiago Milczarek Sayao  wrote:
    
    >> This is a new approach to rewrite parts of gtk glass backend to be more clean.
    >> 
    >> I will provide small "manageable" PR to incrementally make the backend better.
    >> 
    >> This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain.
    >> 
    >> Current status (Ubuntu 20.04):
    >> ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png)
    >> 
    >> (*) Some of the iconify tests are also failing on the main branch. 
    >> 
    >> `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures.
    >
    > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   Fix build
    >   gtk_widget_set_sensitive has no effect
    
    Closed in favor of #915
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/367
    
    From tsayao at openjdk.org  Thu Oct 13 18:19:55 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Thu, 13 Oct 2022 18:19:55 GMT
    Subject: Withdrawn: 8260528: Clean glass-gtk sizing and positioning code
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Tue, 15 Dec 2020 12:24:01 GMT, Thiago Milczarek Sayao  wrote:
    
    > This is a new approach to rewrite parts of gtk glass backend to be more clean.
    > 
    > I will provide small "manageable" PR to incrementally make the backend better.
    > 
    > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain.
    > 
    > Current status (Ubuntu 20.04):
    > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png)
    > 
    > (*) Some of the iconify tests are also failing on the main branch. 
    > 
    > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures.
    
    This pull request has been closed without being integrated.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/367
    
    From jhendrikx at openjdk.org  Thu Oct 13 20:46:01 2022
    From: jhendrikx at openjdk.org (John Hendrikx)
    Date: Thu, 13 Oct 2022 20:46:01 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: <24S2xIDXEseZu7VqN4evg9d3FLeAFnMY7y78E4FlG0E=.f1287216-7041-4f0b-afd7-cd6ae1061d4a@github.com>
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <24S2xIDXEseZu7VqN4evg9d3FLeAFnMY7y78E4FlG0E=.f1287216-7041-4f0b-afd7-cd6ae1061d4a@github.com>
    Message-ID: 
    
    On Thu, 13 Oct 2022 15:52:46 GMT, Andy Goryachev  wrote:
    
    >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
    >> 
    >>  - Merge remote-tracking branch 'origin/master' into
    >>    feature/conditional-bindings
    >>    
    >>    # Conflicts:
    >>    #	modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java
    >>  - Fix review comments
    >>  - Add missing new line
    >>  - Small wording fixes
    >>  - Update javadoc of "when" with better phrasing
    >>  - Rename showing property to shown as it is already used in subclasses
    >>  - Add conditional bindings to ObservableValue
    >>  - Change explanatory comment to block comment
    >>  - Fix bug where ObjectBinding returns null when revalidated immediately
    >>    
    >>    Introduced with the fluent bindings PR
    >
    > modules/javafx.base/src/main/java/com/sun/javafx/binding/ConditionalBinding.java line 19:
    > 
    >> 17: 
    >> 18:         // condition is always observed and never unsubscribed
    >> 19:         Subscription.subscribe(nonNullCondition, current -> {
    > 
    > do I understand this correctly - if the transient Nodes are created and hooked up with ConditionalBinding and then discarded, we'll have a memory leak?
    
    I'm not sure I fully understand what you mean here with the transient nodes, so if you have an example where you think this doesn't work as you'd like, I'd be happy to take a look at it.  However, I'll try explain though what's going on as best I can:
    
    There are two important things at play here:
    
    1) The bindings resulting from `map`, `when`, etc. are lazy bindings because they're created with the fluent system.  This means that if they're not observed themselves, they remove their listeners to their source.  For example, a chain of values (with arrows pointing from referrer to referent):
    
              A <-- B <-- C <-- D
    
    Or in Java:
    
              b = a.map(...); c = b.map(...); d = c.map(...);
    
    Here B observes A, C observes B and D observes C.  These will only create listeners on their source when they are observed themselves.  In their unobserved state, D can be GC'd, then C, then B, then A. When the listeners are present, the chain looks like:
    
             A <-> B <-> C <-> D <----> something is observing D
    
    Now nothing can be GC'd as long as whatever is observing D is strongly referenced. However, as soon as the observer on D disappears, the chain reverts back to single directional pointers because all listeners are removed when unobserved.
    
    2) The condition for `when` acts as an additional requirement for an observable value to create a listener on its source.  If it is `false`, no listener on its source is created, even when observed itself.  If it is `true`, then a listener is only created on its source if it is observed itself, otherwise still no listener is created.
    
    This means when you have:
    
          ObservableValue active = new SimpleBooleanProperty(true);
     
    And then use it as the condition for another property:
    
          ObservableValue x = label.textProperty().when(active);
    
          x.addListener(xyz);
    
    Then the `ObservableValue` that results from the call to `when` ("x") will always be subscribed to the `active` value. That means as long as `active` is referred, that `x` cannot be GC'd -- this is what you want, as when I toggle `active` back and forth, the thing we're toggling should not disappear.
    
    In this case, there is a listener AND the condition is `true`, so label's text property is referencing `x` as `x` will have added a listener to label's text property.
    
             label.text <-> x <-----> listener
             x <-> active
    
    If the condition is `false`, the graph instead looks like:
    
             label.text <-- x <-----> listener
             x <-> active
    
    This is a very subtle difference, but it does mean that the `label` no longer has any influence on keeping these objects alive.  If only `label` is strongly referenced, then toggling `active` to `false`, and then purposely removing all references to `active` would mean the system can freely remove all these observables, including the listener as there is no way you could turn the switch back on again...
    
    If you however kept a reference to one of these (either `listener`, `x` or `active`) then they all are referenced, as they should be, as I could toggle `active` back to `true` and expect the whole chain to work again as before.
    
    The fact that the lifecycle of the condition and its resulting observable value are tied to each other should not matter, and in fact, has to work that way or switching on/off wouldn't do what you'd expect anymore if the properties being switched could be GC'd.
    
    In an earlier example I showed this:
    
        ObservableValue active = new SimpleBooleanProperty(true);
    
        MySkin() {
             getSkinnable().textProperty().when(active).addListener(this::updateSkinStuffs);
             getSkinnable().fontProperty().when(active).addListener(this::updateSkinStuffs);
             getSkinnable().wrapTextProperty().when(active).addListener(this::updateSkinStuffs);
        }
    
        void dispose() {
             active.set(false);  // kills all listeners/bindings/etc in a single line
        }
    
    Assuming the Skin itself is not strongly referenced at some point, the listeners in the above example are all still referenced by the control resulting from `getSkinnable` and can't be GC'd.  Skinnable refers to its text property, the text property refers to the `when` observable, the `when` observable refers to the `updateSkinStuffs` method, and that method pointer (but also the `when` observable which refers to `active`) keeps the entire Skin and all its listeners alive.
    
    However, if you set `active` to false, that chain is broken.  Specifically, the text property no longer references the `when` observable, because the `when` observable will unsubscribe itself.  Since there are no other references to the skin anymore, the entire skin, including the `active` observable boolean is GC'd.  The fact that `when` and `active` reference each other makes no difference.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From jhendrikx at openjdk.org  Thu Oct 13 21:05:44 2022
    From: jhendrikx at openjdk.org (John Hendrikx)
    Date: Thu, 13 Oct 2022 21:05:44 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <24S2xIDXEseZu7VqN4evg9d3FLeAFnMY7y78E4FlG0E=.f1287216-7041-4f0b-afd7-cd6ae1061d4a@github.com>
     
    Message-ID: 
    
    On Thu, 13 Oct 2022 20:42:31 GMT, John Hendrikx  wrote:
    
    >> modules/javafx.base/src/main/java/com/sun/javafx/binding/ConditionalBinding.java line 19:
    >> 
    >>> 17: 
    >>> 18:         // condition is always observed and never unsubscribed
    >>> 19:         Subscription.subscribe(nonNullCondition, current -> {
    >> 
    >> do I understand this correctly - if the transient Nodes are created and hooked up with ConditionalBinding and then discarded, we'll have a memory leak?
    >
    > I'm not sure I fully understand what you mean here with the transient nodes, so if you have an example where you think this doesn't work as you'd like, I'd be happy to take a look at it.  However, I'll try explain though what's going on as best I can:
    > 
    > There are two important things at play here:
    > 
    > 1) The bindings resulting from `map`, `when`, etc. are lazy bindings because they're created with the fluent system.  This means that if they're not observed themselves, they remove their listeners to their source.  For example, a chain of values (with arrows pointing from referrer to referent):
    > 
    >           A <-- B <-- C <-- D
    > 
    > Or in Java:
    > 
    >           b = a.map(...); c = b.map(...); d = c.map(...);
    > 
    > Here B observes A, C observes B and D observes C.  These will only create listeners on their source when they are observed themselves.  In their unobserved state, D can be GC'd, then C, then B, then A. When the listeners are present, the chain looks like:
    > 
    >          A <-> B <-> C <-> D <----> something is observing D
    > 
    > Now nothing can be GC'd as long as whatever is observing D is strongly referenced. However, as soon as the observer on D disappears, the chain reverts back to single directional pointers because all listeners are removed when unobserved.
    > 
    > 2) The condition for `when` acts as an additional requirement for an observable value to create a listener on its source.  If it is `false`, no listener on its source is created, even when observed itself.  If it is `true`, then a listener is only created on its source if it is observed itself, otherwise still no listener is created.
    > 
    > This means when you have:
    > 
    >       ObservableValue active = new SimpleBooleanProperty(true);
    >  
    > And then use it as the condition for another property:
    > 
    >       ObservableValue x = label.textProperty().when(active);
    > 
    >       x.addListener(xyz);
    > 
    > Then the `ObservableValue` that results from the call to `when` ("x") will always be subscribed to the `active` value. That means as long as `active` is referred, that `x` cannot be GC'd -- this is what you want, as when I toggle `active` back and forth, the thing we're toggling should not disappear.
    > 
    > In this case, there is a listener AND the condition is `true`, so label's text property is referencing `x` as `x` will have added a listener to label's text property.
    > 
    >          label.text <-> x <-----> listener
    >          x <-> active
    > 
    > If the condition is `false`, the graph instead looks like:
    > 
    >          label.text <-- x <-----> listener
    >          x <-> active
    > 
    > This is a very subtle difference, but it does mean that the `label` no longer has any influence on keeping these objects alive.  If only `label` is strongly referenced, then toggling `active` to `false`, and then purposely removing all references to `active` would mean the system can freely remove all these observables, including the listener as there is no way you could turn the switch back on again...
    > 
    > If you however kept a reference to one of these (either `listener`, `x` or `active`) then they all are referenced, as they should be, as I could toggle `active` back to `true` and expect the whole chain to work again as before.
    > 
    > The fact that the lifecycle of the condition and its resulting observable value are tied to each other should not matter, and in fact, has to work that way or switching on/off wouldn't do what you'd expect anymore if the properties being switched could be GC'd.
    > 
    > In an earlier example I showed this:
    > 
    >     ObservableValue active = new SimpleBooleanProperty(true);
    > 
    >     MySkin() {
    >          getSkinnable().textProperty().when(active).addListener(this::updateSkinStuffs);
    >          getSkinnable().fontProperty().when(active).addListener(this::updateSkinStuffs);
    >          getSkinnable().wrapTextProperty().when(active).addListener(this::updateSkinStuffs);
    >     }
    > 
    >     void dispose() {
    >          active.set(false);  // kills all listeners/bindings/etc in a single line
    >     }
    > 
    > Assuming the Skin itself is not strongly referenced at some point, the listeners in the above example are all still referenced by the control resulting from `getSkinnable` and can't be GC'd.  Skinnable refers to its text property, the text property refers to the `when` observable, the `when` observable refers to the `updateSkinStuffs` method, and that method pointer (but also the `when` observable which refers to `active`) keeps the entire Skin and all its listeners alive.
    > 
    > However, if you set `active` to false, that chain is broken.  Specifically, the text property no longer references the `when` observable, because the `when` observable will unsubscribe itself.  Since there are no other references to the skin anymore, the entire skin, including the `active` observable boolean is GC'd.  The fact that `when` and `active` reference each other makes no difference.
    
    Since this was quite wordy, and since pictures are worth a thousand words...
    
    Here is the situation when you have a Label with its Skin:
    
    ![image](https://user-images.githubusercontent.com/995917/195709660-0bdad680-9240-48e9-9f8e-ae4b40ab7047.png)
    
    When that Skin is replaced, dispose is called which toggles `active` to `false`.  Furthermore, the Label will no longer reference the Skin.  This image then shows the state of the references, and which objects can be GC'd:
    
    ![image](https://user-images.githubusercontent.com/995917/195710017-413af0ec-1c0f-4329-adb5-d5c3072c0008.png)
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Thu Oct 13 22:10:12 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Thu, 13 Oct 2022 22:10:12 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <24S2xIDXEseZu7VqN4evg9d3FLeAFnMY7y78E4FlG0E=.f1287216-7041-4f0b-afd7-cd6ae1061d4a@github.com>
     
     
    Message-ID: 
    
    On Thu, 13 Oct 2022 21:03:36 GMT, John Hendrikx  wrote:
    
    >> I'm not sure I fully understand what you mean here with the transient nodes, so if you have an example where you think this doesn't work as you'd like, I'd be happy to take a look at it.  However, I'll try explain though what's going on as best I can:
    >> 
    >> There are two important things at play here:
    >> 
    >> 1) The bindings resulting from `map`, `when`, etc. are lazy bindings because they're created with the fluent system.  This means that if they're not observed themselves, they remove their listeners to their source.  For example, a chain of values (with arrows pointing from referrer to referent):
    >> 
    >>           A <-- B <-- C <-- D
    >> 
    >> Or in Java:
    >> 
    >>           b = a.map(...); c = b.map(...); d = c.map(...);
    >> 
    >> Here B observes A, C observes B and D observes C.  These will only create listeners on their source when they are observed themselves.  In their unobserved state, D can be GC'd, then C, then B, then A. When the listeners are present, the chain looks like:
    >> 
    >>          A <-> B <-> C <-> D <----> something is observing D
    >> 
    >> Now nothing can be GC'd as long as whatever is observing D is strongly referenced. However, as soon as the observer on D disappears, the chain reverts back to single directional pointers because all listeners are removed when unobserved.
    >> 
    >> 2) The condition for `when` acts as an additional requirement for an observable value to create a listener on its source.  If it is `false`, no listener on its source is created, even when observed itself.  If it is `true`, then a listener is only created on its source if it is observed itself, otherwise still no listener is created.
    >> 
    >> This means when you have:
    >> 
    >>       ObservableValue active = new SimpleBooleanProperty(true);
    >>  
    >> And then use it as the condition for another property:
    >> 
    >>       ObservableValue x = label.textProperty().when(active);
    >> 
    >>       x.addListener(xyz);
    >> 
    >> Then the `ObservableValue` that results from the call to `when` ("x") will always be subscribed to the `active` value. That means as long as `active` is referred, that `x` cannot be GC'd -- this is what you want, as when I toggle `active` back and forth, the thing we're toggling should not disappear.
    >> 
    >> In this case, there is a listener AND the condition is `true`, so label's text property is referencing `x` as `x` will have added a listener to label's text property.
    >> 
    >>          label.text <-> x <-----> listener
    >>          x <-> active
    >> 
    >> If the condition is `false`, the graph instead looks like:
    >> 
    >>          label.text <-- x <-----> listener
    >>          x <-> active
    >> 
    >> This is a very subtle difference, but it does mean that the `label` no longer has any influence on keeping these objects alive.  If only `label` is strongly referenced, then toggling `active` to `false`, and then purposely removing all references to `active` would mean the system can freely remove all these observables, including the listener as there is no way you could turn the switch back on again...
    >> 
    >> If you however kept a reference to one of these (either `listener`, `x` or `active`) then they all are referenced, as they should be, as I could toggle `active` back to `true` and expect the whole chain to work again as before.
    >> 
    >> The fact that the lifecycle of the condition and its resulting observable value are tied to each other should not matter, and in fact, has to work that way or switching on/off wouldn't do what you'd expect anymore if the properties being switched could be GC'd.
    >> 
    >> In an earlier example I showed this:
    >> 
    >>     ObservableValue active = new SimpleBooleanProperty(true);
    >> 
    >>     MySkin() {
    >>          getSkinnable().textProperty().when(active).addListener(this::updateSkinStuffs);
    >>          getSkinnable().fontProperty().when(active).addListener(this::updateSkinStuffs);
    >>          getSkinnable().wrapTextProperty().when(active).addListener(this::updateSkinStuffs);
    >>     }
    >> 
    >>     void dispose() {
    >>          active.set(false);  // kills all listeners/bindings/etc in a single line
    >>     }
    >> 
    >> Assuming the Skin itself is not strongly referenced at some point, the listeners in the above example are all still referenced by the control resulting from `getSkinnable` and can't be GC'd.  Skinnable refers to its text property, the text property refers to the `when` observable, the `when` observable refers to the `updateSkinStuffs` method, and that method pointer (but also the `when` observable which refers to `active`) keeps the entire Skin and all its listeners alive.
    >> 
    >> However, if you set `active` to false, that chain is broken.  Specifically, the text property no longer references the `when` observable, because the `when` observable will unsubscribe itself.  Since there are no other references to the skin anymore, the entire skin, including the `active` observable boolean is GC'd.  The fact that `when` and `active` reference each other makes no difference.
    >
    > Since this was quite wordy, and since pictures are worth a thousand words...
    > 
    > Here is the situation when you have a Label with its Skin:
    > 
    > ![image](https://user-images.githubusercontent.com/995917/195709660-0bdad680-9240-48e9-9f8e-ae4b40ab7047.png)
    > 
    > When that Skin is replaced, dispose is called which toggles `active` to `false`.  Furthermore, the Label will no longer reference the Skin.  This image then shows the state of the references, and which objects can be GC'd:
    > 
    > ![image](https://user-images.githubusercontent.com/995917/195710017-413af0ec-1c0f-4329-adb5-d5c3072c0008.png)
    
    Thank you for explanations, @hjohn .
    
    This *might* work for Skins, of course, though it is not exactly what is needed for Skins (I will explain why in https://github.com/openjdk/jfx/pull/908 because of context).
    
    In the context of this PR, I can see how a memory leak can be created when a developer has the `active` property as long lived and that would prevent the whole chain from being collected.  An example would be trying to attach to the Window.showingProperty(), adding listeners that reference Nodes that are supposed to be GC'd when removed from the said window (dynamically creating detail panes as response to selection event, for example).
    
    I think what you propose here is good, but, as any other place where listeners are added, must be used with caution (may be reflect that fact in javadoc?)
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Thu Oct 13 22:15:06 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Thu, 13 Oct 2022 22:15:06 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <24S2xIDXEseZu7VqN4evg9d3FLeAFnMY7y78E4FlG0E=.f1287216-7041-4f0b-afd7-cd6ae1061d4a@github.com>
     
     
     
    Message-ID: 
    
    On Thu, 13 Oct 2022 22:06:15 GMT, Andy Goryachev  wrote:
    
    >> Since this was quite wordy, and since pictures are worth a thousand words...
    >> 
    >> Here is the situation when you have a Label with its Skin:
    >> 
    >> ![image](https://user-images.githubusercontent.com/995917/195709660-0bdad680-9240-48e9-9f8e-ae4b40ab7047.png)
    >> 
    >> When that Skin is replaced, dispose is called which toggles `active` to `false`.  Furthermore, the Label will no longer reference the Skin.  This image then shows the state of the references, and which objects can be GC'd:
    >> 
    >> ![image](https://user-images.githubusercontent.com/995917/195710017-413af0ec-1c0f-4329-adb5-d5c3072c0008.png)
    >
    > Thank you for explanations, @hjohn .
    > 
    > This *might* work for Skins, of course, though it is not exactly what is needed for Skins (I will explain why in https://github.com/openjdk/jfx/pull/908 because of context).
    > 
    > In the context of this PR, I can see how a memory leak can be created when a developer has the `active` property as long lived and that would prevent the whole chain from being collected.  An example would be trying to attach to the Window.showingProperty(), adding listeners that reference Nodes that are supposed to be GC'd when removed from the said window (dynamically creating detail panes as response to selection event, for example).
    > 
    > I think what you propose here is good, but, as any other place where listeners are added, must be used with caution (may be reflect that fact in javadoc?)
    
    And, more specifically, is there a way to break the strong reference between the `active` property and the dependent fluent chain?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Thu Oct 13 22:19:10 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Thu, 13 Oct 2022 22:19:10 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <24S2xIDXEseZu7VqN4evg9d3FLeAFnMY7y78E4FlG0E=.f1287216-7041-4f0b-afd7-cd6ae1061d4a@github.com>
     
     
     
     
    Message-ID: 
    
    On Thu, 13 Oct 2022 22:11:12 GMT, Andy Goryachev  wrote:
    
    >> Thank you for explanations, @hjohn .
    >> 
    >> This *might* work for Skins, of course, though it is not exactly what is needed for Skins (I will explain why in https://github.com/openjdk/jfx/pull/908 because of context).
    >> 
    >> In the context of this PR, I can see how a memory leak can be created when a developer has the `active` property as long lived and that would prevent the whole chain from being collected.  An example would be trying to attach to the Window.showingProperty(), adding listeners that reference Nodes that are supposed to be GC'd when removed from the said window (dynamically creating detail panes as response to selection event, for example).
    >> 
    >> I think what you propose here is good, but, as any other place where listeners are added, must be used with caution (may be reflect that fact in javadoc?)
    >
    > And, more specifically, is there a way to break the strong reference between the `active` property and the dependent fluent chain?
    
    Also, using your example above, it might be too easy to create a memory leak by inadvertently referring to a long lived object:
    
    
    getSkinnable().textProperty().when(active).addListener((src,prev,current) -> {
      getSkinnable().setSomething(window.getSomething() + "..."); // window reference makes the listener lambda uncollectable, resulting in a memory leak
    });
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Thu Oct 13 22:29:13 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Thu, 13 Oct 2022 22:29:13 GMT
    Subject: RFR: 8287822: [macos] Remove support of duplicated formats from
     macOS [v3]
    In-Reply-To: 
    References: 
     
    Message-ID: 
    
    On Thu, 13 Oct 2022 04:25:19 GMT, Alexander Matveev  wrote:
    
    >> - Added support for JAR and JRT protocol to AVFoundation platform.
    >>  - Removed H.264/MP3 and AAC support from GStreamer platform, which was primary used to playback these formats for JAR and JRT protocols.
    >>  - Added ability to FXMediaPlayer sample to generate playlist for JAR and JRT protocols for testing. See FXMedia.java for how to use it.
    >>  - H.265/HEVC via JAR/JRT protocols should work on macOS after this change. Before it did not work because GStreamer platform did not support H.265/HEVC and AVFoundation did not support JAR/JRT protocols.
    >>  - Minor code clean up.
    >> 
    >> After this changes:
    >> GSTPlatform: AIFF and WAV for all protocols.
    >> AVFoundation: MP3, AAC, HLS, H.264 and H.265 for all protocols.
    >> 
    >> This change is transparent for end user and does not affect list of supported formats by JavaFX Media.
    >
    > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   8287822: [macos] Remove support of duplicated formats from macOS [v3]
    
    Changes requested by angorya (Author).
    
    tests/manual/media/FXMediaPlayer/src/fxmediaplayer/media/FXMedia.java line 118:
    
    > 116:                     path = fileSystem.getPath("fxmediaplayer", "media");
    > 117:                 } else {
    > 118:                     path = Path.of(uri);
    
    should we explicitly check if it is a file?
    if("file".equals(uri.getScheme()) { ...
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/909
    
    From angorya at openjdk.org  Thu Oct 13 22:29:14 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Thu, 13 Oct 2022 22:29:14 GMT
    Subject: RFR: 8287822: [macos] Remove support of duplicated formats from
     macOS [v3]
    In-Reply-To: <35KRhzTe1DPOhJjYfTUBpSRL38uakb-74PZjhg3GDMM=.d454696c-cbfc-4226-afdd-c9d5e129d82f@github.com>
    References: 
     
     <35KRhzTe1DPOhJjYfTUBpSRL38uakb-74PZjhg3GDMM=.d454696c-cbfc-4226-afdd-c9d5e129d82f@github.com>
    Message-ID: 
    
    On Tue, 11 Oct 2022 21:41:55 GMT, Kevin Rushforth  wrote:
    
    >> tests/manual/media/FXMediaPlayer/src/fxmediaplayer/media/FXMedia.java line 97:
    >> 
    >>> 95:                 uri = FXMedia.class.getResource("/fxmediaplayer/media").toURI();
    >>> 96: 
    >>> 97:                 if (uri.getScheme().equals("jar")) {
    >> 
    >> is it possible for uri scheme to be null?
    >> may be "jar".equals(uri.getScheme()) ?
    >
    > Related question: Can `uri` itself be null?
    
    so the logic seems to be either a "jar", or else it's a file, right?
    is it possible to be something else (i.e. the resource is missing altogether)? or some other condition?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/909
    
    From angorya at openjdk.org  Thu Oct 13 22:50:11 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Thu, 13 Oct 2022 22:50:11 GMT
    Subject: RFR: 8294809: ListenerHelper for managing and disconnecting
     listeners
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Fri, 7 Oct 2022 20:50:55 GMT, Andy Goryachev  wrote:
    
    > Introduction
    > 
    > There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class).
    > 
    > This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance
    > https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java
    > 
    > Proposal
    > 
    > It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which:
    > 
    > - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc.
    > - keeps track of the listeners and the corresponding ObservableValues
    > - provides a single disconnect() method to remove all the listeners in one go.
    > - optionally, it should be possible to add a lambda (Runnable) to a group of properties
    > - optionally, there should be a boolean flag to fire the lambda immediately
    > - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method
    > 
    > Make it Public Later
    > 
    > Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later.
    > 
    > Where It Will Be Useful
    > 
    > [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin"
    > and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler.
    > 
    > https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft
    > 
    > https://github.com/openjdk/jfx/pull/914
    
    Thank you @nlisker and @hjohn for providing the link and explanations.  
    
    You are right, ListenerHelper is somewhat similar to Subscription in that it allows for quick disconnect().
    
    It is, however, designed for a different purpose, that goes beyond what is needed from a simple listener management.  Specifically,
    
    - it assumes multiple listeners/handlers/callbacks from the start
    - it allows for invoking listeners/callbacks immediately as it is a frequent pattern not only in Skins but also in application code (I do want to make this class a part of public API eventually)
    - unlike Subscription, we can addEventHandlers and addEventFilters
    - unlike Subscription, we can add Weak listeners/callbacks, though I admit it might be a design decision to use or not to use that
    
    to summarize, I see some minor overlap between Subscription and ListenerHelper, but mostly these are two different beasts designed for two different purposes.
    
    I do agree with the call to cooperate!  Would love to.
    
    what do you think?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/908
    
    From jhendrikx at openjdk.org  Thu Oct 13 23:06:03 2022
    From: jhendrikx at openjdk.org (John Hendrikx)
    Date: Thu, 13 Oct 2022 23:06:03 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <24S2xIDXEseZu7VqN4evg9d3FLeAFnMY7y78E4FlG0E=.f1287216-7041-4f0b-afd7-cd6ae1061d4a@github.com>
     
     
     
     
     
    Message-ID: 
    
    On Thu, 13 Oct 2022 22:17:09 GMT, Andy Goryachev  wrote:
    
    > Also, using your example above, it might be too easy to create a memory leak by inadvertently referring to a long lived object:
    > 
    > ```
    > getSkinnable().textProperty().when(active).addListener((src,prev,current) -> {
    >   getSkinnable().setSomething(window.getSomething() + "..."); // window reference makes the listener lambda uncollectable, resulting in a memory leak
    > });
    > ```
    
    I'm not sure I follow your meaning.  Why would referring to `window` make the lambda uncollectable? The lambda is referring to `window`, not the other way around.
    
    The current "alternative", which is weak listeners, is not what it is cracked up to be.  A weak listener that is not strongly referenced will be collected at a random time, including never, (almost) immediately or in 5 minutes.  All that time, the listener still functions, responds to potential events and property changes, even though the reason for its existence has since disappeared.
    
    When a weak reference is collected depends on many things, including the chosen GC, its parameters, JDK versions, memory pressure, etc.  This proposal is specifically tailored to make the process of removing listeners deterministic without having to manually unregister listeners.  Weak listeners are completely unpredictable and could potentially live much longer than expected on certain GC's (or future improvements of GC's) that have different strategies for cleaning weak references.
    
    A weak reference specifically is NOT something that gets cleaned up immediately upon the last reference disappearing. This can cause all kinds of phantom effects in JavaFX applications, if your listener does something like persisting state or printing something to the console. For example, a long lived model gets a weak listener attached to it when a dialog opens; the listener persists the last selected item.  The dialog is closed and reopened.  Now there might be two listeners, both persisting the last selected item. This may show up on your console as two database calls where one is expected.
    
    You can argue this is bad programming and that those listeners should have been cleaned up specifically with a dispose method, and I agree, you get predictable behavior that way. And that's exactly what this proposal also brings, predictable behavior, using a syntax that doesn't require you to keep track of your listeners explicitely:
    
           longLivedModel.indexProperty().when(dialog::shownProperty).addListener(persistPosition);
    
    This detaches the listener immediately after the dialog is closed.  Not in 3 seconds or 5 minutes, but as soon as it is no longer visible.  Opening a new dialog will not reinstate this listener. Reusing the same dialog however would, and it would start working again exactly as you'd expect as soon as the dialog is visible again.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Thu Oct 13 23:10:06 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Thu, 13 Oct 2022 23:10:06 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
    Message-ID: 
    
    On Thu, 29 Sep 2022 15:02:13 GMT, John Hendrikx  wrote:
    
    >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`.
    >> 
    >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here).
    >> 
    >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property:
    >> 
    >>      label.textProperty().bind(longLivedProperty.when(label::isShowingProperty));
    >> 
    >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing.  When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`.  A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along.
    >> 
    >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR.
    >> 
    >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out.
    >> 
    >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window.
    >
    > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
    > 
    >  - Merge remote-tracking branch 'origin/master' into
    >    feature/conditional-bindings
    >    
    >    # Conflicts:
    >    #	modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java
    >  - Fix review comments
    >  - Add missing new line
    >  - Small wording fixes
    >  - Update javadoc of "when" with better phrasing
    >  - Rename showing property to shown as it is already used in subclasses
    >  - Add conditional bindings to ObservableValue
    >  - Change explanatory comment to block comment
    >  - Fix bug where ObjectBinding returns null when revalidated immediately
    >    
    >    Introduced with the fluent bindings PR
    
    I am late to the party (should have commented in #675) - "Subscription" is way too generic and overloaded word for a functional interface.  Any one who is using real Subscriptions will get confused ;-)
    
    Probably too late to change now.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From jhendrikx at openjdk.org  Thu Oct 13 23:13:05 2022
    From: jhendrikx at openjdk.org (John Hendrikx)
    Date: Thu, 13 Oct 2022 23:13:05 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     
    Message-ID: 
    
    On Thu, 13 Oct 2022 23:06:05 GMT, Andy Goryachev  wrote:
    
    > I am late to the party (should have commented in #675) - "Subscription" is way too generic and overloaded word for a functional interface. Any one who is using real Subscriptions will get confused ;-)
    > 
    > Probably too late to change now.
    
    No, you're not too late.  The `Subscription` class is already part of JFX 19, but it is not public.
    
    Subscription was the term using in ReactFX and similar frameworks, and was quite clear, but if you have a suggestion for a name that is even better suited than it can still be changed.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Thu Oct 13 23:17:04 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Thu, 13 Oct 2022 23:17:04 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <24S2xIDXEseZu7VqN4evg9d3FLeAFnMY7y78E4FlG0E=.f1287216-7041-4f0b-afd7-cd6ae1061d4a@github.com>
     
     
     
     
     
     
    Message-ID: 
    
    On Thu, 13 Oct 2022 23:03:56 GMT, John Hendrikx  wrote:
    
    >> Also, using your example above, it might be too easy to create a memory leak by inadvertently referring to a long lived object:
    >> 
    >> 
    >> getSkinnable().textProperty().when(active).addListener((src,prev,current) -> {
    >>   getSkinnable().setSomething(window.getSomething() + "..."); // window reference makes the listener lambda uncollectable, resulting in a memory leak
    >> });
    >
    >> Also, using your example above, it might be too easy to create a memory leak by inadvertently referring to a long lived object:
    >> 
    >> ```
    >> getSkinnable().textProperty().when(active).addListener((src,prev,current) -> {
    >>   getSkinnable().setSomething(window.getSomething() + "..."); // window reference makes the listener lambda uncollectable, resulting in a memory leak
    >> });
    >> ```
    > 
    > I'm not sure I follow your meaning.  Why would referring to `window` make the lambda uncollectable? The lambda is referring to `window`, not the other way around.
    > 
    > The current "alternative", which is weak listeners, is not what it is cracked up to be.  A weak listener that is not strongly referenced will be collected at a random time, including never, (almost) immediately or in 5 minutes.  All that time, the listener still functions, responds to potential events and property changes, even though the reason for its existence has since disappeared.
    > 
    > When a weak reference is collected depends on many things, including the chosen GC, its parameters, JDK versions, memory pressure, etc.  This proposal is specifically tailored to make the process of removing listeners deterministic without having to manually unregister listeners.  Weak listeners are completely unpredictable and could potentially live much longer than expected on certain GC's (or future improvements of GC's) that have different strategies for cleaning weak references.
    > 
    > A weak reference specifically is NOT something that gets cleaned up immediately upon the last reference disappearing. This can cause all kinds of phantom effects in JavaFX applications, if your listener does something like persisting state or printing something to the console. For example, a long lived model gets a weak listener attached to it when a dialog opens; the listener persists the last selected item.  The dialog is closed and reopened.  Now there might be two listeners, both persisting the last selected item. This may show up on your console as two database calls where one is expected.
    > 
    > You can argue this is bad programming and that those listeners should have been cleaned up specifically with a dispose method, and I agree, you get predictable behavior that way. And that's exactly what this proposal also brings, predictable behavior, using a syntax that doesn't require you to keep track of your listeners explicitely:
    > 
    >        longLivedModel.indexProperty().when(dialog::shownProperty).addListener(persistPosition);
    > 
    > This detaches the listener immediately after the dialog is closed.  Not in 3 seconds or 5 minutes, but as soon as it is no longer visible.  Opening a new dialog will not reinstate this listener. Reusing the same dialog however would, and it would start working again exactly as you'd expect as soon as the dialog is visible again.
    
    let me try to create a unit test (and I could be wrong, of course).
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Thu Oct 13 23:21:13 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Thu, 13 Oct 2022 23:21:13 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
    Message-ID: 
    
    On Thu, 29 Sep 2022 15:02:13 GMT, John Hendrikx  wrote:
    
    >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`.
    >> 
    >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here).
    >> 
    >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property:
    >> 
    >>      label.textProperty().bind(longLivedProperty.when(label::isShowingProperty));
    >> 
    >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing.  When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`.  A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along.
    >> 
    >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR.
    >> 
    >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out.
    >> 
    >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window.
    >
    > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
    > 
    >  - Merge remote-tracking branch 'origin/master' into
    >    feature/conditional-bindings
    >    
    >    # Conflicts:
    >    #	modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java
    >  - Fix review comments
    >  - Add missing new line
    >  - Small wording fixes
    >  - Update javadoc of "when" with better phrasing
    >  - Rename showing property to shown as it is already used in subclasses
    >  - Add conditional bindings to ObservableValue
    >  - Change explanatory comment to block comment
    >  - Fix bug where ObjectBinding returns null when revalidated immediately
    >    
    >    Introduced with the fluent bindings PR
    
    I would expect to get some items (messages, real time streams) from a Subscription.  Even your javadoc for unsubscribe() says "Cancels this subscription."
    
    In this case, something along the lines of
    `ICancellable.cancel()`
    might be better, or 
    
    `IDisconnectable.disconnect()`
    as in
    https://github.com/openjdk/jfx/blob/af77693c4c7e778f27f03063bb0256b579de3bb9/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/IDisconnectable.java
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From jhendrikx at openjdk.org  Thu Oct 13 23:27:14 2022
    From: jhendrikx at openjdk.org (John Hendrikx)
    Date: Thu, 13 Oct 2022 23:27:14 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <24S2xIDXEseZu7VqN4evg9d3FLeAFnMY7y78E4FlG0E=.f1287216-7041-4f0b-afd7-cd6ae1061d4a@github.com>
     
     
     
     
     
     
     
    Message-ID: 
    
    On Thu, 13 Oct 2022 23:13:25 GMT, Andy Goryachev  wrote:
    
    >>> Also, using your example above, it might be too easy to create a memory leak by inadvertently referring to a long lived object:
    >>> 
    >>> ```
    >>> getSkinnable().textProperty().when(active).addListener((src,prev,current) -> {
    >>>   getSkinnable().setSomething(window.getSomething() + "..."); // window reference makes the listener lambda uncollectable, resulting in a memory leak
    >>> });
    >>> ```
    >> 
    >> I'm not sure I follow your meaning.  Why would referring to `window` make the lambda uncollectable? The lambda is referring to `window`, not the other way around.
    >> 
    >> The current "alternative", which is weak listeners, is not what it is cracked up to be.  A weak listener that is not strongly referenced will be collected at a random time, including never, (almost) immediately or in 5 minutes.  All that time, the listener still functions, responds to potential events and property changes, even though the reason for its existence has since disappeared.
    >> 
    >> When a weak reference is collected depends on many things, including the chosen GC, its parameters, JDK versions, memory pressure, etc.  This proposal is specifically tailored to make the process of removing listeners deterministic without having to manually unregister listeners.  Weak listeners are completely unpredictable and could potentially live much longer than expected on certain GC's (or future improvements of GC's) that have different strategies for cleaning weak references.
    >> 
    >> A weak reference specifically is NOT something that gets cleaned up immediately upon the last reference disappearing. This can cause all kinds of phantom effects in JavaFX applications, if your listener does something like persisting state or printing something to the console. For example, a long lived model gets a weak listener attached to it when a dialog opens; the listener persists the last selected item.  The dialog is closed and reopened.  Now there might be two listeners, both persisting the last selected item. This may show up on your console as two database calls where one is expected.
    >> 
    >> You can argue this is bad programming and that those listeners should have been cleaned up specifically with a dispose method, and I agree, you get predictable behavior that way. And that's exactly what this proposal also brings, predictable behavior, using a syntax that doesn't require you to keep track of your listeners explicitely:
    >> 
    >>        longLivedModel.indexProperty().when(dialog::shownProperty).addListener(persistPosition);
    >> 
    >> This detaches the listener immediately after the dialog is closed.  Not in 3 seconds or 5 minutes, but as soon as it is no longer visible.  Opening a new dialog will not reinstate this listener. Reusing the same dialog however would, and it would start working again exactly as you'd expect as soon as the dialog is visible again.
    >
    > let me try to create a unit test (and I could be wrong, of course).
    
    > In the context of this PR, I can see how a memory leak can be created when a developer has the `active` property as long lived and that would prevent the whole chain from being collected. An example would be trying to attach to the Window.showingProperty(), adding listeners that reference Nodes that are supposed to be GC'd when removed from the said window (dynamically creating detail panes as response to selection event, for example).
    
    What would be the purpose of having a long lived `active` property?  If it has any purpose, then the properties it is controlling must stay referenced, so yes, that would prevent the chain from being GC'd otherwise it could suddenly break your application.
    
    Just like this application breaks currently because of weak listeners:
    
             label.textProperty().concat("A").addListener((src, old, current) -> System.out.println(current));
    
    The above code will stop working at a random time due to the weak listener created by `concat`.  The same code without `concat` will keep working... this is very hard to explain to users.
    
    Now, if you had used `map`, this wouldn't happen.  This is because `map` uses a normal listener, since it is observed itself.  If the above is what the user wants to do, then who are we to break this when a GC happens?
    
    You also mentioned the `Window.showingProperty`. You have to use the correct path to access this property.  You don't want to make it depend on whether the window is showing.  No, you want to make it depend on whether the label has a scene which is part of a showing window:
    
           ObservableValue showing = label.flatMap(Node::sceneProperty())
                 .flatMap(Scene::windowProperty)
                 .orElse(false);
    
    Or short version:
    
           ObservableValue showing = label.shownProperty();
    
    Now, the listener on your label is added like this:
    
           label.textProperty().when(showing).addListener( xyz );
    
    Or inlined:
    
           label.textProperty().when(label::shownProperty).addListener( xyz );
    
    When you remove this label, it's Scene is cleared. `showing` will therefore become `false`, and in turn the listener will stop functioning.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From almatvee at openjdk.org  Thu Oct 13 23:40:07 2022
    From: almatvee at openjdk.org (Alexander Matveev)
    Date: Thu, 13 Oct 2022 23:40:07 GMT
    Subject: RFR: 8287822: [macos] Remove support of duplicated formats from
     macOS [v3]
    In-Reply-To: 
    References: 
     
     <35KRhzTe1DPOhJjYfTUBpSRL38uakb-74PZjhg3GDMM=.d454696c-cbfc-4226-afdd-c9d5e129d82f@github.com>
     
    Message-ID: 
    
    On Thu, 13 Oct 2022 22:23:08 GMT, Andy Goryachev  wrote:
    
    >> Related question: Can `uri` itself be null?
    >
    > so the logic seems to be either a "jar", or else it's a file, right?
    > is it possible to be something else (i.e. the resource is missing altogether)? or some other condition?
    
    Yes, when we run jar file it will be jar and if we run unpacked it will be file. If resource is missing we will not enumerate files and it is acceptable condition. We should fallback to default playlist if no files present.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/909
    
    From almatvee at openjdk.org  Thu Oct 13 23:44:05 2022
    From: almatvee at openjdk.org (Alexander Matveev)
    Date: Thu, 13 Oct 2022 23:44:05 GMT
    Subject: RFR: 8287822: [macos] Remove support of duplicated formats from
     macOS [v3]
    In-Reply-To: 
    References: 
     
     
    Message-ID: 
    
    On Thu, 13 Oct 2022 22:24:06 GMT, Andy Goryachev  wrote:
    
    >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
    >> 
    >>   8287822: [macos] Remove support of duplicated formats from macOS [v3]
    >
    > tests/manual/media/FXMediaPlayer/src/fxmediaplayer/media/FXMedia.java line 118:
    > 
    >> 116:                     path = fileSystem.getPath("fxmediaplayer", "media");
    >> 117:                 } else {
    >> 118:                     path = Path.of(uri);
    > 
    > should we explicitly check if it is a file?
    > if("file".equals(uri.getScheme()) { ...
    
    I do not see a point of doing it, since it should be a file.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/909
    
    From angorya at openjdk.org  Thu Oct 13 23:47:11 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Thu, 13 Oct 2022 23:47:11 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <24S2xIDXEseZu7VqN4evg9d3FLeAFnMY7y78E4FlG0E=.f1287216-7041-4f0b-afd7-cd6ae1061d4a@github.com>
     
     
     
     
     
     
     
     
    Message-ID: 
    
    On Thu, 13 Oct 2022 23:25:05 GMT, John Hendrikx  wrote:
    
    >> let me try to create a unit test (and I could be wrong, of course).
    >
    >> In the context of this PR, I can see how a memory leak can be created when a developer has the `active` property as long lived and that would prevent the whole chain from being collected. An example would be trying to attach to the Window.showingProperty(), adding listeners that reference Nodes that are supposed to be GC'd when removed from the said window (dynamically creating detail panes as response to selection event, for example).
    > 
    > What would be the purpose of having a long lived `active` property?  If it has any purpose, then the properties it is controlling must stay referenced, so yes, that would prevent the chain from being GC'd otherwise it could suddenly break your application.
    > 
    > Just like this application breaks currently because of weak listeners:
    > 
    >          label.textProperty().concat("A").addListener((src, old, current) -> System.out.println(current));
    > 
    > The above code will stop working at a random time due to the weak listener created by `concat`.  The same code without `concat` will keep working... this is very hard to explain to users.
    > 
    > Now, if you had used `map`, this wouldn't happen.  This is because `map` uses a normal listener, since it is observed itself.  If the above is what the user wants to do, then who are we to break this when a GC happens?
    > 
    > You also mentioned the `Window.showingProperty`. You have to use the correct path to access this property.  You don't want to make it depend on whether the window is showing.  No, you want to make it depend on whether the label has a scene which is part of a showing window:
    > 
    >        ObservableValue showing = label.sceneProperty()
    >              .flatMap(Scene::windowProperty)
    >              .flatMap(Window::showingProperty)
    >              .orElse(false);
    > 
    > Or short version:
    > 
    >        ObservableValue showing = label.shownProperty();
    > 
    > Now, the listener on your label is added like this:
    > 
    >        label.textProperty().when(showing).addListener( xyz );
    > 
    > Or inlined:
    > 
    >        label.textProperty().when(label::shownProperty).addListener( xyz );
    > 
    > When you remove this label, it's Scene is cleared. `showing` will therefore become `false`, and in turn the listener will stop functioning.
    
    sorry for including multiple topics in one comment.
    
    1. it looks like your proposal will work, as long as the `active` property is not referenced outside of its owner (in our discussion, Skin).  If that is true, as soon as you set active=false, the listener is disconnected and the skin, the active property, and the lambda can be collected.  Thus, as you correctly explained, we need to create a large aggregate with two flat maps in order to avoid the memory leak (whether you hide this complexity behind shownProperty is irrelevant).  So yes, it will work, as long as the developer makes no mistakes and does not wire the thing directly (a mistake I readily made)
    
    2. as a side note, I would discourage a pattern where Nodes are reused and need to be reconnected.  at least in my applications, I never do that, but I can see situation when this might be useful.
    
    3. is when() a good name?  it sort of implies a time-domain criterion instead of when a boolean becomes true (whenTrue? whenAllowed?)  i could be wrong here.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From jhendrikx at openjdk.org  Fri Oct 14 00:03:11 2022
    From: jhendrikx at openjdk.org (John Hendrikx)
    Date: Fri, 14 Oct 2022 00:03:11 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
    Message-ID: 
    
    On Thu, 29 Sep 2022 15:02:13 GMT, John Hendrikx  wrote:
    
    >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`.
    >> 
    >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here).
    >> 
    >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property:
    >> 
    >>      label.textProperty().bind(longLivedProperty.when(label::isShowingProperty));
    >> 
    >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing.  When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`.  A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along.
    >> 
    >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR.
    >> 
    >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out.
    >> 
    >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window.
    >
    > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
    > 
    >  - Merge remote-tracking branch 'origin/master' into
    >    feature/conditional-bindings
    >    
    >    # Conflicts:
    >    #	modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java
    >  - Fix review comments
    >  - Add missing new line
    >  - Small wording fixes
    >  - Update javadoc of "when" with better phrasing
    >  - Rename showing property to shown as it is already used in subclasses
    >  - Add conditional bindings to ObservableValue
    >  - Change explanatory comment to block comment
    >  - Fix bug where ObjectBinding returns null when revalidated immediately
    >    
    >    Introduced with the fluent bindings PR
    
    I made another image that shows what happens when you have a Label that is listening on a long lived property that is protected by using a `when(label::shownProperty)`.  The reference in the green circle disappears once the label is not part of a scene anymore that is part of a window that is currently showing:
    
    ![image](https://user-images.githubusercontent.com/995917/195733168-01ca3241-3af2-45de-bce9-1273777741ee.png)
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From jhendrikx at openjdk.org  Fri Oct 14 00:30:06 2022
    From: jhendrikx at openjdk.org (John Hendrikx)
    Date: Fri, 14 Oct 2022 00:30:06 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <24S2xIDXEseZu7VqN4evg9d3FLeAFnMY7y78E4FlG0E=.f1287216-7041-4f0b-afd7-cd6ae1061d4a@github.com>
     
     
     
     
     
     
     
     
     
    Message-ID: 
    
    On Thu, 13 Oct 2022 23:45:10 GMT, Andy Goryachev  wrote:
    
    > 1. it looks like your proposal will work, as long as the `active` property is not referenced outside of its owner (in our discussion, Skin).  If that is true, as soon as you set active=false, the listener is disconnected and the skin, the active property, and the lambda can be collected.  Thus, as you correctly explained, we need to create a large aggregate with two flat maps in order to avoid the memory leak (whether you hide this complexity behind shownProperty is irrelevant).
    
    Yes, the `shownProperty` is there purely for convenience, and more useful for regular controls, not the skin scenario I think.  I have this helper that I use for this purpose at the moment:
    
        public static ObservableValue showing(Node node) {
          return node.sceneProperty()
            .flatMap(Scene::windowProperty)
            .flatMap(Window::showingProperty)
            .orElse(false);
        }
    
    >  So yes, it will work, as long as the developer makes no mistakes and does not wire the thing directly (a mistake I readily made)
    
    Yes, that's certainly true, I think the `shownProperty` will help with that though, as I think it will prevent people from storing the flatMap aggregate and reusing it, and perhaps then reusing it for the wrong controls.  Reuse however can still be fine for groups of listeners of several controls that go together.  If your control's lifecycle is tied to a group, container or dialog, then it is perfectly fine to use one of their shown properties.
    
    > 2. as a side note, I would discourage a pattern where Nodes are reused and need to be reconnected.  at least in my applications, I never do that, but I can see situation when this might be useful.
    
    I'm not in favor of that either, and I don't think I ever do it, but it is allowed by JavaFX, and so if you did, then the listeners would be restored as they were, and since you had to have a reference to this reused control still, nothing will have been GC'd yet.
    
    > 3. is when() a good name?  it sort of implies a time-domain criterion instead of when a boolean becomes true (whenTrue? whenAllowed?)  i could be wrong here.
    
    ReactFX used `conditionOn` and had a special version `conditionOnShowing` which accepts a `Node` (this would however create a circular reference between projects base and graphics).  I proposed `when` as it is nice and short, inspired by the recent developments in the area of switch expressions.  Even better would be `while` IMHO, but that is unfortunately a reserved keyword.  Still, when works reasonably well: "Listen to changes of this long lived property **when** this condition holds".  While would definitely be better or perhaps "as long as" or "whenever" :)
    
    I don't think we should add "true" in the name, no other conditionals do this (like `Stream#filter` or `List#removeIf`).
    
    `filter` itself is also not an option, as this has a different meaning which we may implement in the future. `filter` would allow you to remove certain values, which would set the value to empty:
    
           textProperty.filter(text -> !isRudeWord()).orElse("").addListener(...);
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From C-Schmitz at t-systems.com  Fri Oct 14 06:36:47 2022
    From: C-Schmitz at t-systems.com (C-Schmitz at t-systems.com)
    Date: Fri, 14 Oct 2022 06:36:47 +0000
    Subject: Java 1.8.0_341 - JDK-8282229 - Customizable visibility timing for
     Tooltip BUG!?
    Message-ID: 
    
    Hi,
    
    we have a problem with the JavaFX implementation for the Tooltip class (this issue https://bugs.openjdk.org/browse/JDK-8090477 and https://bugs.openjdk.org/browse/JDK-8282229#).
    The problem is related to Java version 1.8.0_341. We use the Tooltip class without explicit usage of the new timing methods. When you position the mouse on a Textfield (where a tooltip is attached to), waiting for a second, the tooltip appears. If you do not move the mouse, the tooltip disappears after 5 seconds. When the tooltip appears and you move the mouse away from the Textfield, the tooltip stays open and did not hide anymore.
    
    I've compared both tooltip versions (1.8.0_333 versus 1.8.0_341) and I think the problem could be the following:
    
    1.8.0_333
    
    [cid:image001.png at 01D8DFA8.14B89310]
    
    
    1.8.0_341
    
    
    [cid:image002.png at 01D8DFA8.14B89310]
    
    Possible bug reason:
    
    When you move the mouse away from the TextField which shows the tooltip the yellow code line in the new version: Tooltip t = ...
    does not return the currently shown tooltip. Instead it returns null, so that the leftTimer does not start to finally close the tooltip.
    The old version always starts the leftTimer, so that the tooltip gets closed.
    
    Is there any way to force a fix for this in the next JRE/JDK-version for Java8?
    
    Thanks and best regards
    Christian
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: image001.png
    Type: image/png
    Size: 26038 bytes
    Desc: image001.png
    URL: 
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: image002.png
    Type: image/png
    Size: 32863 bytes
    Desc: image002.png
    URL: 
    
    From duke at openjdk.org  Fri Oct 14 15:00:14 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Fri, 14 Oct 2022 15:00:14 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D
    In-Reply-To: <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
    References: 
     <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
    Message-ID: 
    
    On Thu, 13 Oct 2022 14:13:27 GMT, Nir Lisker  wrote:
    
    >> The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. I also changed formatting in the method signatures of equals(), hashCode() and toString().
    >> 
    >> For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    >
    > modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 413:
    > 
    >> 411: 
    >> 412:     /**
    >> 413:      * Determines whether or not two objects are equal. Two instances of {@code Point3D}
    > 
    > Since this object is known, I would start with "Determines if this point is equals to a given object".
    
    Agree. I propose the very similar wording "Determines whether this Point3D is equal to a given object."
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Fri Oct 14 15:07:07 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Fri, 14 Oct 2022 15:07:07 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D
    In-Reply-To: 
    References: 
     <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
     
    Message-ID: 
    
    On Thu, 13 Oct 2022 15:49:58 GMT, Kevin Rushforth  wrote:
    
    >> modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 414:
    >> 
    >>> 412:     /**
    >>> 413:      * Determines whether or not two objects are equal. Two instances of {@code Point3D}
    >>> 414:      * are equal if the values of their x, y, and z properties are equal.
    >> 
    >> I would even write "i.f.f" because it's bidirectional.
    >> 
    >> Also, `x`, `y`, and `z` should be in `{@code}`.
    >
    > I think this one is OK either as "if" or "if and only if" (if you do change it, I recommend spelling it out, although "iff" with no punctuation, would be acceptable). I agree with the request to use code style.
    
    I disagree with both suggestions. 
    
    1. I think the extra verbosity (while factually correct) adds nothing, for such a straightforward concept as equality of points in 3 space.
    2. x, y and z are private and are not exposed in the JavaDoc. Further, the exposed methods getX() etc. that I **could** link to, are not actually what are evaluated in the method body.
    
    I'd propose alternately that we keep "x, y and z" but call them "coordinates" and not "properties". This agrees with other parts of the JavaDoc such as the constructor, and getX() etc. method documentation.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Fri Oct 14 15:12:16 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Fri, 14 Oct 2022 15:12:16 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D
    In-Reply-To: 
    References: 
     <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
     
    Message-ID: 
    
    On Thu, 13 Oct 2022 15:50:38 GMT, Kevin Rushforth  wrote:
    
    >> modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 415:
    >> 
    >>> 413:      * Determines whether or not two objects are equal. Two instances of {@code Point3D}
    >>> 414:      * are equal if the values of their x, y, and z properties are equal.
    >>> 415:      * @param obj an object to be compared with this {@code Point3D}.
    >> 
    >> We tend to put a new line before the tags to separate them from the description, not sure if it's enforced.
    >
    > Not strictly enforced, but adding a blank line does aid readability (of the source code...the generated docs don't care).
    
    If I were to add empty lines before JavaDoc tags such as @param etc, then for consistency I think I should do it for the whole class, where they are not present.
    
    Note, on line 32: **// PENDING_DOC_REVIEW of this whole class**
    Maybe we should first decide whether we are scrubbing all doc for the whole class, or making a minimal change to the obviously incorrect information. My feeling is now tending toward the latter.
    
    It could very well be that I misunderstood the comment by nlisker.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Fri Oct 14 15:21:10 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Fri, 14 Oct 2022 15:21:10 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D
    In-Reply-To: 
    References: 
     <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
     
     
    Message-ID: 
    
    On Fri, 14 Oct 2022 15:03:41 GMT, Douglas Held  wrote:
    
    >> I think this one is OK either as "if" or "if and only if" (if you do change it, I recommend spelling it out, although "iff" with no punctuation, would be acceptable). I agree with the request to use code style.
    >
    > I disagree with both suggestions. 
    > 
    > 1. I think the extra verbosity (while factually correct) adds nothing, for such a straightforward concept as equality of points in 3 space.
    > 2. x, y and z are private and are not exposed in the JavaDoc. Further, the exposed methods getX() etc. that I **could** link to, are not actually what are evaluated in the method body.
    > 
    > I'd propose alternately that we keep "x, y and z" but call them "coordinates" and not "properties". This agrees with other parts of the JavaDoc such as the constructor, and getX() etc. method documentation.
    
    Correction: getX() etc. are used in the method. I will put the methods into code tags.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Fri Oct 14 15:21:11 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Fri, 14 Oct 2022 15:21:11 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D
    In-Reply-To: <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
    References: 
     <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
    Message-ID: 
    
    On Thu, 13 Oct 2022 14:15:58 GMT, Nir Lisker  wrote:
    
    >> The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. I also changed formatting in the method signatures of equals(), hashCode() and toString().
    >> 
    >> For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    >
    > modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 417:
    > 
    >> 415:      * @param obj an object to be compared with this {@code Point3D}.
    >> 416:      * @return true if the object to be compared is an instance of Point3D and
    >> 417:      * has the same values; false otherwise.
    > 
    > `true`, `Point3D` and `false` should be in `{@code}`.
    
    Looking at the JavaDoc in the rest of the class, the {@code Point3D} tags are not used outside of these two methods hashCode() and equals(). I'd propose actually that we remove them, for consistency with the rest of the JavaDoc in this class.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Fri Oct 14 15:21:12 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Fri, 14 Oct 2022 15:21:12 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D
    In-Reply-To: 
    References: 
     <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
     
    Message-ID: 
    
    On Fri, 14 Oct 2022 15:13:41 GMT, Douglas Held  wrote:
    
    >> modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 417:
    >> 
    >>> 415:      * @param obj an object to be compared with this {@code Point3D}.
    >>> 416:      * @return true if the object to be compared is an instance of Point3D and
    >>> 417:      * has the same values; false otherwise.
    >> 
    >> `true`, `Point3D` and `false` should be in `{@code}`.
    >
    > Looking at the JavaDoc in the rest of the class, the {@code Point3D} tags are not used outside of these two methods hashCode() and equals(). I'd propose actually that we remove them, for consistency with the rest of the JavaDoc in this class.
    
    ...correction, found in toString() as well.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Fri Oct 14 15:24:02 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Fri, 14 Oct 2022 15:24:02 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v2]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. I also changed formatting in the method signatures of equals(), hashCode() and toString().
    > 
    > For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    
    Douglas Held has updated the pull request incrementally with one additional commit since the last revision:
    
      Update Point3D.java
      
      Undoing changes outside of equals() method.
      Accepting some but not all review comments in documentation for equals()
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/913/files
      - new: https://git.openjdk.org/jfx/pull/913/files/d7dff6be..36b4dfb6
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=913&range=01
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=913&range=00-01
    
      Stats: 8 lines in 1 file changed: 1 ins; 2 del; 5 mod
      Patch: https://git.openjdk.org/jfx/pull/913.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/913/head:pull/913
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Fri Oct 14 15:30:10 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Fri, 14 Oct 2022 15:30:10 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v3]
    In-Reply-To: 
    References: 
    Message-ID: <6LEZsq5LCJppqiQ7KTwlwTfg2JtFFsNK33JwLQSdUfo=.dea4005a-9411-4ac6-86f9-e9bded34fcf1@github.com>
    
    > The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. I also changed formatting in the method signatures of equals(), hashCode() and toString().
    > 
    > For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    
    Douglas Held has updated the pull request incrementally with one additional commit since the last revision:
    
      Update Point3D.java
      
      Removal of two line-end whitespace characters
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/913/files
      - new: https://git.openjdk.org/jfx/pull/913/files/36b4dfb6..0c52ce57
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=913&range=02
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=913&range=01-02
    
      Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
      Patch: https://git.openjdk.org/jfx/pull/913.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/913/head:pull/913
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Fri Oct 14 15:32:49 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Fri, 14 Oct 2022 15:32:49 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v3]
    In-Reply-To: <6LEZsq5LCJppqiQ7KTwlwTfg2JtFFsNK33JwLQSdUfo=.dea4005a-9411-4ac6-86f9-e9bded34fcf1@github.com>
    References: 
     <6LEZsq5LCJppqiQ7KTwlwTfg2JtFFsNK33JwLQSdUfo=.dea4005a-9411-4ac6-86f9-e9bded34fcf1@github.com>
    Message-ID: <5RRyVcc50Ei2Iq6h07uHatpLr4Xk8qlEB9-vwPfWMsw=.d1e9354f-b34d-437e-b952-0748d1acd1cf@github.com>
    
    On Fri, 14 Oct 2022 15:30:10 GMT, Douglas Held  wrote:
    
    >> The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. I also changed formatting in the method signatures of equals(), hashCode() and toString().
    >> 
    >> For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    >
    > Douglas Held has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   Update Point3D.java
    >   
    >   Removal of two line-end whitespace characters
    
    I've reverted some of my changes which fell outside of the egregious documentation error.
    
    If we are to correct further doc style, then that might be addressed as a whole-file review of the doc. (per the comment on line 32)
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Fri Oct 14 15:55:29 2022
    From: duke at openjdk.org (eduardsdv)
    Date: Fri, 14 Oct 2022 15:55:29 GMT
    Subject: RFR: 8295324: JavaFX: Blank pages when printing
    Message-ID: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com>
    
    This fixes a race condition between application and 'Print Job Thread' threads when printing.
    
    The race condition occurs when application thread calls `endJob()`, which in effect sets the `jobDone` flag to true,
    and when the 'Print Job Thread' thread was in the `synchronized` block in `waitForNextPage()` at that time.
    The 'Print Job Thread' thread checks `jobDone` flag after exiting the `synchronized` block and, if it is true, skips the last page.
    
    In this fix, not only the `jobDone` is checked, but also that there is no other page to be printed.
    It was also needed to introduce a new flag 'jobCanceled', to skip the page if the printing was canceled by 'cancelJob()'.
    
    -------------
    
    Commit messages:
     - 8295324: Fix skipping of pages when printing
     - 8295324: Apply patch with junit from the issue
    
    Changes: https://git.openjdk.org/jfx/pull/916/files
     Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=916&range=00
      Issue: https://bugs.openjdk.org/browse/JDK-8295324
      Stats: 463 lines in 6 files changed: 444 ins; 0 del; 19 mod
      Patch: https://git.openjdk.org/jfx/pull/916.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/916/head:pull/916
    
    PR: https://git.openjdk.org/jfx/pull/916
    
    From angorya at openjdk.org  Fri Oct 14 16:23:11 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Fri, 14 Oct 2022 16:23:11 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <24S2xIDXEseZu7VqN4evg9d3FLeAFnMY7y78E4FlG0E=.f1287216-7041-4f0b-afd7-cd6ae1061d4a@github.com>
     
     
     
     
     
     
     
     
     
     
    Message-ID: 
    
    On Fri, 14 Oct 2022 00:26:42 GMT, John Hendrikx  wrote:
    
    >> sorry for including multiple topics in one comment.
    >> 
    >> 1. it looks like your proposal will work, as long as the `active` property is not referenced outside of its owner (in our discussion, Skin).  If that is true, as soon as you set active=false, the listener is disconnected and the skin, the active property, and the lambda can be collected.  Thus, as you correctly explained, we need to create a large aggregate with two flat maps in order to avoid the memory leak (whether you hide this complexity behind shownProperty is irrelevant).  So yes, it will work, as long as the developer makes no mistakes and does not wire the thing directly (a mistake I readily made)
    >> 
    >> 2. as a side note, I would discourage a pattern where Nodes are reused and need to be reconnected.  at least in my applications, I never do that, but I can see situation when this might be useful.
    >> 
    >> 3. is when() a good name?  it sort of implies a time-domain criterion instead of when a boolean becomes true (whenTrue? whenAllowed?)  i could be wrong here.
    >
    >> 1. it looks like your proposal will work, as long as the `active` property is not referenced outside of its owner (in our discussion, Skin).  If that is true, as soon as you set active=false, the listener is disconnected and the skin, the active property, and the lambda can be collected.  Thus, as you correctly explained, we need to create a large aggregate with two flat maps in order to avoid the memory leak (whether you hide this complexity behind shownProperty is irrelevant).
    > 
    > Yes, the `shownProperty` is there purely for convenience, and more useful for regular controls, not the skin scenario I think.  I have this helper that I use for this purpose at the moment:
    > 
    >     public static ObservableValue showing(Node node) {
    >       return node.sceneProperty()
    >         .flatMap(Scene::windowProperty)
    >         .flatMap(Window::showingProperty)
    >         .orElse(false);
    >     }
    > 
    >>  So yes, it will work, as long as the developer makes no mistakes and does not wire the thing directly (a mistake I readily made)
    > 
    > Yes, that's certainly true, I think the `shownProperty` will help with that though, as I think it will prevent people from storing the flatMap aggregate and reusing it, and perhaps then reusing it for the wrong controls.  Reuse however can still be fine for groups of listeners of several controls that go together.  If your control's lifecycle is tied to a group, container or dialog, then it is perfectly fine to use one of their shown properties.
    > 
    >> 2. as a side note, I would discourage a pattern where Nodes are reused and need to be reconnected.  at least in my applications, I never do that, but I can see situation when this might be useful.
    > 
    > I'm not in favor of that either, and I don't think I ever do it, but it is allowed by JavaFX, and so if you did, then the listeners would be restored as they were, and since you had to have a reference to this reused control still, nothing will have been GC'd yet.
    > 
    >> 3. is when() a good name?  it sort of implies a time-domain criterion instead of when a boolean becomes true (whenTrue? whenAllowed?)  i could be wrong here.
    > 
    > ReactFX used `conditionOn` and had a special version `conditionOnShowing` which accepts a `Node` (this would however create a circular reference between projects base and graphics).  I proposed `when` as it is nice and short, inspired by the recent developments in the area of switch expressions.  Even better would be `while` IMHO, but that is unfortunately a reserved keyword.  Still, when works reasonably well: "Listen to changes of this long lived property **when** this condition holds".  While would definitely be better or perhaps "as long as" or "whenever" :)
    > 
    > I don't think we should add "true" in the name, no other conditionals do this (like `Stream#filter` or `List#removeIf`).
    > 
    > `filter` itself is also not an option, as this has a different meaning which we may implement in the future. `filter` would allow you to remove certain values, which would set the value to empty:
    > 
    >        textProperty.filter(text -> !isRudeWord()).orElse("").addListener(...);
    
    thank you for clarifications.
    
    If I were to choose, I'd pick `conditionOn` as it implies a boolean.
    
    Also, since I've fallen into this trap when reviewing this PR, I think it might be a good idea to explain how to avoid memory leak by using a local property in `conditionOn/when` so as not to create a memory leak.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Fri Oct 14 16:23:11 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Fri, 14 Oct 2022 16:23:11 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     
     
     
     
    Message-ID: 
    
    On Thu, 1 Sep 2022 12:55:36 GMT, Nir Lisker  wrote:
    
    >> Do you want me to make this part of the PR? Basically, `Bindings.when` with `map` or `flatMap` depending on whether or not you refer to a value or another property in `then` or `otherwise`.
    >
    > Changing the documentation for `When` should not be part of this PR I think. What we should do maybe is add a note that this method should not be confused with `Bindings.when`. I'll let others weigh in.
    
    I like `conditionOn`.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Fri Oct 14 18:38:37 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Fri, 14 Oct 2022 18:38:37 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
    Message-ID: <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
    
    On Thu, 29 Sep 2022 15:02:13 GMT, John Hendrikx  wrote:
    
    >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`.
    >> 
    >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here).
    >> 
    >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property:
    >> 
    >>      label.textProperty().bind(longLivedProperty.when(label::isShowingProperty));
    >> 
    >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing.  When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`.  A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along.
    >> 
    >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR.
    >> 
    >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out.
    >> 
    >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window.
    >
    > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
    > 
    >  - Merge remote-tracking branch 'origin/master' into
    >    feature/conditional-bindings
    >    
    >    # Conflicts:
    >    #	modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java
    >  - Fix review comments
    >  - Add missing new line
    >  - Small wording fixes
    >  - Update javadoc of "when" with better phrasing
    >  - Rename showing property to shown as it is already used in subclasses
    >  - Add conditional bindings to ObservableValue
    >  - Change explanatory comment to block comment
    >  - Fix bug where ObjectBinding returns null when revalidated immediately
    >    
    >    Introduced with the fluent bindings PR
    
    Changes requested by angorya (Author).
    
    modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 1162:
    
    > 1160:                 }
    > 1161:             }
    > 1162:         }
    
    Is it possible to add the scenario that simulates configurations you so beautifully illustrated in the comments in this PR?  For example, simulate the removal of the "Skin" (without involving a real Skin implementation, just re-create the classes and properties in the same configuration)?
    
    modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1420:
    
    > 1418:      * @since 20
    > 1419:      */
    > 1420:     private ReadOnlyBooleanProperty shown;
    
    I would recommend against adding this property, as it adds a pointer to every Node regardless of whether it's needed or not.
    
    Another reason not to add is that, at least in my experience, there is rarely a need to base the logic on whether a particular Node is shown or not - instead, the logic to disconnect (one or more) listeners should be based on a Window/Dialog or a container pane.  And for that I think a better solution might be - sorry for self plug - something like ListenerHelper https://github.com/openjdk/jfx/pull/908
    
    And another thing - Window and Dialog are not Nodes, but they do have `showing` property.
    
    I would suggest either remove the changes pertaining to Node, or perhaps provide a utility method to create the property and store it in Node.getProperties() or Window.getProperties() (sadly, there is no Dialog.getProperties())
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Fri Oct 14 18:46:07 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Fri, 14 Oct 2022 18:46:07 GMT
    Subject: RFR: 8294809: ListenerHelper for managing and disconnecting
     listeners
    In-Reply-To: 
    References: 
     
    Message-ID: <-38RUa0_CykZtkCsGCgFPbjhaH22gCgVxN5KvDlhnIw=.fe9b2a1e-48e8-4917-aac8-d427222f8e98@github.com>
    
    On Thu, 13 Oct 2022 10:56:54 GMT, Nir Lisker  wrote:
    
    > Reading your proposal I see you might be looking to support weak
    listeners as well. Personally, I believe these are better replaced 
    
    You have a *very* good point here, considering the purpose of this class.  Let me see if support for weak listeners should be removed. Thank you!
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/908
    
    From angorya at openjdk.org  Fri Oct 14 19:11:08 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Fri, 14 Oct 2022 19:11:08 GMT
    Subject: RFR: 8294809: ListenerHelper for managing and disconnecting
     listeners [v2]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > Introduction
    > 
    > There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class).
    > 
    > This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance
    > https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java
    > 
    > Proposal
    > 
    > It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which:
    > 
    > - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc.
    > - keeps track of the listeners and the corresponding ObservableValues
    > - provides a single disconnect() method to remove all the listeners in one go.
    > - optionally, it should be possible to add a lambda (Runnable) to a group of properties
    > - optionally, there should be a boolean flag to fire the lambda immediately
    > - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method
    > 
    > Make it Public Later
    > 
    > Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later.
    > 
    > Where It Will Be Useful
    > 
    > [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin"
    > and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler.
    > 
    > https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft
    > 
    > https://github.com/openjdk/jfx/pull/914
    
    Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
    
      8294809: removed weak listeners support
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/908/files
      - new: https://git.openjdk.org/jfx/pull/908/files/af77693c..2df4a85d
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=01
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=00-01
    
      Stats: 644 lines in 2 files changed: 1 ins; 643 del; 0 mod
      Patch: https://git.openjdk.org/jfx/pull/908.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/908/head:pull/908
    
    PR: https://git.openjdk.org/jfx/pull/908
    
    From angorya at openjdk.org  Fri Oct 14 19:11:24 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Fri, 14 Oct 2022 19:11:24 GMT
    Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v7]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose().
    > 
    > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler.
    > See https://github.com/openjdk/jfx/pull/908
    
    Andy Goryachev has updated the pull request incrementally with six additional commits since the last revision:
    
     - 8294589: removed weak listeners
     - Merge branch '8294809.listener.helper' into 8294589.menubarskin.leak
     - 8294809: removed weak listeners support
     - 8294809: use weak reference correctly this time
     - 8294809: tests
     - 8294809: remove
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/906/files
      - new: https://git.openjdk.org/jfx/pull/906/files/21fc352e..2ea27fc9
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=06
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=05-06
    
      Stats: 765 lines in 3 files changed: 422 ins; 337 del; 6 mod
      Patch: https://git.openjdk.org/jfx/pull/906.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906
    
    PR: https://git.openjdk.org/jfx/pull/906
    
    From jhendrikx at openjdk.org  Fri Oct 14 20:55:08 2022
    From: jhendrikx at openjdk.org (John Hendrikx)
    Date: Fri, 14 Oct 2022 20:55:08 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
    Message-ID: <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
    
    On Fri, 14 Oct 2022 18:30:43 GMT, Andy Goryachev  wrote:
    
    >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
    >> 
    >>  - Merge remote-tracking branch 'origin/master' into
    >>    feature/conditional-bindings
    >>    
    >>    # Conflicts:
    >>    #	modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java
    >>  - Fix review comments
    >>  - Add missing new line
    >>  - Small wording fixes
    >>  - Update javadoc of "when" with better phrasing
    >>  - Rename showing property to shown as it is already used in subclasses
    >>  - Add conditional bindings to ObservableValue
    >>  - Change explanatory comment to block comment
    >>  - Fix bug where ObjectBinding returns null when revalidated immediately
    >>    
    >>    Introduced with the fluent bindings PR
    >
    > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1420:
    > 
    >> 1418:      * @since 20
    >> 1419:      */
    >> 1420:     private ReadOnlyBooleanProperty shown;
    > 
    > I would recommend against adding this property, as it adds a pointer to every Node regardless of whether it's needed or not.
    > 
    > Another reason not to add is that, at least in my experience, there is rarely a need to base the logic on whether a particular Node is shown or not - instead, the logic to disconnect (one or more) listeners should be based on a Window/Dialog or a container pane.  And for that I think a better solution might be - sorry for self plug - something like ListenerHelper https://github.com/openjdk/jfx/pull/908
    > 
    > And another thing - Window and Dialog are not Nodes, but they do have `showing` property.
    > 
    > I would suggest either remove the changes pertaining to Node, or perhaps provide a utility method to create the property and store it in Node.getProperties() or Window.getProperties() (sadly, there is no Dialog.getProperties())
    
    I agree with your first point, but I think limiting any changes to `Node` because it would add another field is not a good enough argument.  It would depend on its merits.
    
    The second point, there is much more to the `shownProperty` then you might think at first glance. In combination with `when`, it offers a standard way to manage life cycles for controls.  It is a very natural fit to tie the lifecycle of bindings and listeners to whether a control is actually currently shown.  You may think that a Listener helper class would be just as flexible, but it isn't.  The helper is not available everywhere (unless you propose to integrate it into Node), which means when constructing complicated UI's which may have smaller groups of controls that are created by other classes, methods or factories, that you may have to pass along an instance of your helper to all these to make sure they register their bindings and listeners with it (or perhaps to link multiple Listener helper classes together in some kind of hierarchy, that matches the control groupings that might have separate life cycles).
    
    The `shownProperty` does not have this problem. Since you can tie the lifecycle to your own small piece of the UI (ie, a factory that creates a `BorderPane` with several controls, can tie all these to the lifecycle of the `BorderPane`).  When this `BorderPane` is just a piece of UI used as part of a larger whole, its lifecycle still works as expected -- if it is not shown, its listeners disappear.  If the whole window is destroyed, then the same happens.  If however the Pane next to it is destroyed, only their listeners disappear.  With a helper system, you'd need to coordinate this somehow, perhaps having that `BorderPane` return its helper, so the large UI can tie it to its helper, so when the main helper is called to unsubscribe, that all its child helpers are also unsubscribed...
    
    Another advantage is that a listener does not have to start working right away.  When setting up a new pane of controls, many subscriptions may need to be made.  When using `when(control::shownProperty)` these listeners don't immediately become active (potentially while still constructing and initializing your control).  Only when the control is fully constructed, and added to an active Scene and Window do all the listeners become active.  This can be important when listening to external properties that change often and may even change during construction.
    
    In ReactFX it the `shownProperty` was deemed important enough to go one step further and even create a separate method on what would be `ObservableValue` called `conditionOnShowing`.  
    
    In short, `when` and the `shownProperty` is basically used every time you create a binding or add a listener between two properties that have a different lifecycle, like between a model and a control.  This completely removes the responsibility of having to track these bindings or listeners separately; it becomes automatic. Subscribing all at once when it becomes first shown becomes automatic (and you immediately get the first value), unsubscribing when it goes invisible is automatic, and resubscribing if a control becomes shown again is completely transparent.
    
    In my projects, I've completely eliminated memory leaks without a single call to `removeListener` or `unbind` anywhere. 
    There are no explicit weak listeners (and not just because they're incredibly cumbersome to use), nor is there anywhere where subscriptions or bindings are being tracked (aside from the `when` construct).  I'm very picky about memory leaks, so I have a Scene scanner, that maintains weak references to all Nodes at all times, and warns me if any are not getting GC'd after not being part of a Scene for a while.  In 99% of the cases, I forgot a `when`, where in plain JavaFX you'd be forced to use a weak listener.
    
    The simple rule to follow is, whenever you bind or listen to or on a property, if they have different lifecycles, then use a `when`, otherwise bind or listen directly.
    
    Some examples of how it is used:
    
    Below is a very common pattern when binding any property that has a different lifecycle than its target, this is one of many:
    
        longLivedModel.selectedItem
             .when(this::shownProperty)   // this = BorderPane, and the code is part of its constructor)
             .addListener((obs, old, current) -> {
                  // code that starts a transition from the previous item to the next item
             }
        );
    
    Below some binding examples where several properties are bound to long lived versions:
    
        ObservableValue shown = pane.shownProperty();
    
        pane.model.work.bind(presentation.root.when(shown));
        pane.model.missingFraction.bind(presentation.missingFraction.when(shown));
        pane.model.watchedFraction.bind(presentation.watchedFraction.when(shown));
    
    Below a "bidirectional binding" for a `Slider` control, where one direction is long lived.  The binding vanishes on its own when the UI that is using it is closed -- this is part of a UI generator, so this code has no idea where the UI might end up being used or for how long, but it can still manage the lifecycle easily:
    
        longLivedValue.conditionOn(slider::shownProperty).map(toNumber).subscribe(slider.valueProperty()::setValue);
        slider.valueProperty().map(fromNumber).subscribe(value::setValue);
    
    Another example to make sure a `Timeline` is stopped/started automatically based on visibility (Timeline's will keep references around if not stopped):
    
        center.shownProperty()  // center here is a Pane
          .addListener((obs, old, visible) -> {
            if(visible) timeline.playFromStart();
            else timeline.stop();
          });
    
    So, I think it certainly has some merit to include it :)
    
    > And another thing - Window and Dialog are not Nodes, but they do have showing property.
    
    I'm unsure what you are saying here.  I don't think we need to tie anything directly to a Window or Dialog, only to controls they might contain.  Also the `shownProperty` is not useful for properties not associated with controls; depending on what the properties are used for people may have to create their own `active` property or something else that identifies the lifecycle of those properties.  For control properties though, their lifecycle is quite clear and I think it makes great sense to tie to whether they're actually visible or not.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From jhendrikx at openjdk.org  Fri Oct 14 21:07:05 2022
    From: jhendrikx at openjdk.org (John Hendrikx)
    Date: Fri, 14 Oct 2022 21:07:05 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
    Message-ID: 
    
    On Fri, 14 Oct 2022 18:35:26 GMT, Andy Goryachev  wrote:
    
    >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
    >> 
    >>  - Merge remote-tracking branch 'origin/master' into
    >>    feature/conditional-bindings
    >>    
    >>    # Conflicts:
    >>    #	modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java
    >>  - Fix review comments
    >>  - Add missing new line
    >>  - Small wording fixes
    >>  - Update javadoc of "when" with better phrasing
    >>  - Rename showing property to shown as it is already used in subclasses
    >>  - Add conditional bindings to ObservableValue
    >>  - Change explanatory comment to block comment
    >>  - Fix bug where ObjectBinding returns null when revalidated immediately
    >>    
    >>    Introduced with the fluent bindings PR
    >
    > modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 1162:
    > 
    >> 1160:                 }
    >> 1161:             }
    >> 1162:         }
    > 
    > Is it possible to add the scenario that simulates configurations you so beautifully illustrated in the comments in this PR?  For example, simulate the removal of the "Skin" (without involving a real Skin implementation, just re-create the classes and properties in the same configuration)?
    
    You mean something like calling `setSkin` on a `Button` in a loop with a new skin that uses this form of listener management?  And seeing if the old skin instances don't stick around?
    
    I suppose I could make a copy of one of the smaller skins, tweak it to use `when` and then testing this. Is that what you'd be looking for?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Fri Oct 14 21:36:05 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Fri, 14 Oct 2022 21:36:05 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
     
    Message-ID: 
    
    On Fri, 14 Oct 2022 21:04:58 GMT, John Hendrikx  wrote:
    
    >> modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 1162:
    >> 
    >>> 1160:                 }
    >>> 1161:             }
    >>> 1162:         }
    >> 
    >> Is it possible to add the scenario that simulates configurations you so beautifully illustrated in the comments in this PR?  For example, simulate the removal of the "Skin" (without involving a real Skin implementation, just re-create the classes and properties in the same configuration)?
    >
    > You mean something like calling `setSkin` on a `Button` in a loop with a new skin that uses this form of listener management?  And seeing if the old skin instances don't stick around?
    > 
    > I suppose I could make a copy of one of the smaller skins, tweak it to use `when` and then testing this. Is that what you'd be looking for?
    
    never mind, please disregard.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Fri Oct 14 23:04:05 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Fri, 14 Oct 2022 23:04:05 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
     <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
    Message-ID: 
    
    On Fri, 14 Oct 2022 20:53:01 GMT, John Hendrikx  wrote:
    
    >> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1420:
    >> 
    >>> 1418:      * @since 20
    >>> 1419:      */
    >>> 1420:     private ReadOnlyBooleanProperty shown;
    >> 
    >> I would recommend against adding this property, as it adds a pointer to every Node regardless of whether it's needed or not.
    >> 
    >> Another reason not to add is that, at least in my experience, there is rarely a need to base the logic on whether a particular Node is shown or not - instead, the logic to disconnect (one or more) listeners should be based on a Window/Dialog or a container pane.  And for that I think a better solution might be - sorry for self plug - something like ListenerHelper https://github.com/openjdk/jfx/pull/908
    >> 
    >> And another thing - Window and Dialog are not Nodes, but they do have `showing` property.
    >> 
    >> I would suggest either remove the changes pertaining to Node, or perhaps provide a utility method to create the property and store it in Node.getProperties() or Window.getProperties() (sadly, there is no Dialog.getProperties())
    >
    > I agree with your first point, but I think limiting any changes to `Node` because it would add another field is not a good enough argument.  It would depend on its merits.
    > 
    > The second point, there is much more to the `shownProperty` then you might think at first glance. In combination with `when`, it offers a standard way to manage life cycles for controls.  It is a very natural fit to tie the lifecycle of bindings and listeners to whether a control is actually currently shown.  You may think that a Listener helper class would be just as flexible, but it isn't.  The helper is not available everywhere (unless you propose to integrate it into Node), which means when constructing complicated UI's which may have smaller groups of controls that are created by other classes, methods or factories, that you may have to pass along an instance of your helper to all these to make sure they register their bindings and listeners with it (or perhaps to link multiple Listener helper classes together in some kind of hierarchy, that matches the control groupings that might have separate life cycles).
    > 
    > The `shownProperty` does not have this problem. Since you can tie the lifecycle to your own small piece of the UI (ie, a factory that creates a `BorderPane` with several controls, can tie all these to the lifecycle of the `BorderPane`).  When this `BorderPane` is just a piece of UI used as part of a larger whole, its lifecycle still works as expected -- if it is not shown, its listeners disappear.  If the whole window is destroyed, then the same happens.  If however the Pane next to it is destroyed, only their listeners disappear.  With a helper system, you'd need to coordinate this somehow, perhaps having that `BorderPane` return its helper, so the large UI can tie it to its helper, so when the main helper is called to unsubscribe, that all its child helpers are also unsubscribed...
    > 
    > Another advantage is that a listener does not have to start working right away.  When setting up a new pane of controls, many subscriptions may need to be made.  When using `when(control::shownProperty)` these listeners don't immediately become active (potentially while still constructing and initializing your control).  Only when the control is fully constructed, and added to an active Scene and Window do all the listeners become active.  This can be important when listening to external properties that change often and may even change during construction.
    > 
    > In ReactFX it the `shownProperty` was deemed important enough to go one step further and even create a separate method on what would be `ObservableValue` called `conditionOnShowing`.  
    > 
    > In short, `when` and the `shownProperty` is basically used every time you create a binding or add a listener between two properties that have a different lifecycle, like between a model and a control.  This completely removes the responsibility of having to track these bindings or listeners separately; it becomes automatic. Subscribing all at once when it becomes first shown becomes automatic (and you immediately get the first value), unsubscribing when it goes invisible is automatic, and resubscribing if a control becomes shown again is completely transparent.
    > 
    > In my projects, I've completely eliminated memory leaks without a single call to `removeListener` or `unbind` anywhere. 
    > There are no explicit weak listeners (and not just because they're incredibly cumbersome to use), nor is there anywhere where subscriptions or bindings are being tracked (aside from the `when` construct).  I'm very picky about memory leaks, so I have a Scene scanner, that maintains weak references to all Nodes at all times, and warns me if any are not getting GC'd after not being part of a Scene for a while.  In 99% of the cases, I forgot a `when`, where in plain JavaFX you'd be forced to use a weak listener.
    > 
    > The simple rule to follow is, whenever you bind or listen to or on a property, if they have different lifecycles, then use a `when`, otherwise bind or listen directly.
    > 
    > Some examples of how it is used:
    > 
    > Below is a very common pattern when binding any property that has a different lifecycle than its target, this is one of many:
    > 
    >     longLivedModel.selectedItem
    >          .when(this::shownProperty)   // this = BorderPane, and the code is part of its constructor)
    >          .addListener((obs, old, current) -> {
    >               // code that starts a transition from the previous item to the next item
    >          }
    >     );
    > 
    > Below some binding examples where several properties are bound to long lived versions:
    > 
    >     ObservableValue shown = pane.shownProperty();
    > 
    >     pane.model.work.bind(presentation.root.when(shown));
    >     pane.model.missingFraction.bind(presentation.missingFraction.when(shown));
    >     pane.model.watchedFraction.bind(presentation.watchedFraction.when(shown));
    > 
    > Below a "bidirectional binding" for a `Slider` control, where one direction is long lived.  The binding vanishes on its own when the UI that is using it is closed -- this is part of a UI generator, so this code has no idea where the UI might end up being used or for how long, but it can still manage the lifecycle easily:
    > 
    >     longLivedValue.when(slider::shownProperty).map(toNumber).subscribe(slider.valueProperty()::setValue);
    >     slider.valueProperty().map(fromNumber).subscribe(longLivedValue::setValue);
    > 
    > Another example to make sure a `Timeline` is stopped/started automatically based on visibility (Timeline's will keep references around if not stopped):
    > 
    >     center.shownProperty()  // center here is a Pane
    >       .addListener((obs, old, visible) -> {
    >         if(visible) timeline.playFromStart();
    >         else timeline.stop();
    >       });
    > 
    > So, I think it certainly has some merit to include it :)
    > 
    >> And another thing - Window and Dialog are not Nodes, but they do have showing property.
    > 
    > I'm unsure what you are saying here.  I don't think we need to tie anything directly to a Window or Dialog, only to controls they might contain.  Also the `shownProperty` is not useful for properties not associated with controls; depending on what the properties are used for people may have to create their own `active` property or something else that identifies the lifecycle of those properties.  For control properties though, their lifecycle is quite clear and I think it makes great sense to tie to whether they're actually visible or not.
    
    What I meant is you can add it in Node.getProperties() and not to add a pointer to every Node everywhere.  If it's used, the actual properties will be created in a few containers.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From tsayao at openjdk.org  Sun Oct 16 23:31:34 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Sun, 16 Oct 2022 23:31:34 GMT
    Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code
    Message-ID: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    
    This cleans size and positioning code, reducing special cases, code complexity and size.
    
    Changes:
    
    - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    - frame extents are received in process_property_notify;
    - window geometry, min/max size are centralized in update_window_constraints and uses  `XSetWMNormalHints` because it supports initial position;
    - window_configure: Changes can be requested directly to the window manager with `XReconfigureWMWindow` - it's compatible with `windowChangesMask`, `windowChanges`;
    - request_focus uses `_NET_ACTIVE_WINDOW` directly as it does not seem to have focus stealing problems.
    
    I have left some debug print statements which will be removed when we finish testing.
    
    -------------
    
    Commit messages:
     - Move / Resize notify
     - Clean
     - Cache extents
     - Frame extents
     - Merge remote-tracking branch 'origin/clean_glass_gtk' into clean_glass_gtk
     - work
     - work
     - Minor adjustments
     - Remove extents quirk
     - It builds
     - ... and 26 more: https://git.openjdk.org/jfx/compare/35675c8d...27eac46e
    
    Changes: https://git.openjdk.org/jfx/pull/915/files
     Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=00
      Issue: https://bugs.openjdk.org/browse/JDK-8260528
      Stats: 474 lines in 4 files changed: 106 ins; 261 del; 107 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From tsayao at openjdk.org  Sun Oct 16 23:56:05 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Sun, 16 Oct 2022 23:56:05 GMT
    Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v2]
    In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    Message-ID: 
    
    > This cleans size and positioning code, reducing special cases, code complexity and size.
    > 
    > Changes:
    > 
    > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    > - frame extents are received in process_property_notify;
    > - window geometry, min/max size are centralized in update_window_constraints and uses  `XSetWMNormalHints` because it supports initial position;
    > - window_configure: Changes can be requested directly to the window manager with `XReconfigureWMWindow` - it's compatible with `windowChangesMask`, `windowChanges`;
    > - request_focus uses `_NET_ACTIVE_WINDOW` directly as it does not seem to have focus stealing problems.
    > 
    > I have left some debug print statements which will be removed when we finish testing.
    
    Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
    
      Fix for Exception Dialog / expand
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/915/files
      - new: https://git.openjdk.org/jfx/pull/915/files/27eac46e..621ea2dc
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=01
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=00-01
    
      Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From tsayao at openjdk.org  Mon Oct 17 00:10:29 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Mon, 17 Oct 2022 00:10:29 GMT
    Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v3]
    In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    Message-ID: 
    
    > This cleans size and positioning code, reducing special cases, code complexity and size.
    > 
    > Changes:
    > 
    > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    > - frame extents are received in process_property_notify;
    > - window geometry, min/max size are centralized in update_window_constraints and uses  `XSetWMNormalHints` because it supports initial position;
    > - window_configure: Changes can be requested directly to the window manager with `XReconfigureWMWindow` - it's compatible with `windowChangesMask`, `windowChanges`;
    > - request_focus uses `_NET_ACTIVE_WINDOW` directly as it does not seem to have focus stealing problems.
    > 
    > I have left some debug print statements which will be removed when we finish testing.
    
    Thiago Milczarek Sayao 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:
    
      8260528: Clean glass-gtk sizing and positioning code
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/915/files
      - new: https://git.openjdk.org/jfx/pull/915/files/621ea2dc..9fb69ece
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=02
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=01-02
    
      Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From tsayao at openjdk.org  Mon Oct 17 00:16:27 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Mon, 17 Oct 2022 00:16:27 GMT
    Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v4]
    In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    Message-ID: 
    
    > This cleans size and positioning code, reducing special cases, code complexity and size.
    > 
    > Changes:
    > 
    > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    > - frame extents are received in process_property_notify;
    > - window geometry, min/max size are centralized in update_window_constraints and uses  `XSetWMNormalHints` because it supports initial position;
    > - window_configure: Changes can be requested directly to the window manager with `XReconfigureWMWindow` - it's compatible with `windowChangesMask`, `windowChanges`;
    > - request_focus uses `_NET_ACTIVE_WINDOW` directly as it does not seem to have focus stealing problems.
    > 
    > I have left some debug print statements which will be removed when we finish testing.
    
    Thiago Milczarek Sayao 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:
    
      8260528: Clean glass-gtk sizing and positioning code
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/915/files
      - new: https://git.openjdk.org/jfx/pull/915/files/9fb69ece..bfdb4ad7
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=03
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=02-03
    
      Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From duke at openjdk.org  Mon Oct 17 07:12:00 2022
    From: duke at openjdk.org (eduardsdv)
    Date: Mon, 17 Oct 2022 07:12:00 GMT
    Subject: RFR: 8295324: JavaFX: Blank pages when printing [v2]
    In-Reply-To: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com>
    References: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com>
    Message-ID: 
    
    > This fixes a race condition between application and 'Print Job Thread' threads when printing.
    > 
    > The race condition occurs when application thread calls `endJob()`, which in effect sets the `jobDone` flag to true,
    > and when the 'Print Job Thread' thread was in the `synchronized` block in `waitForNextPage()` at that time.
    > The 'Print Job Thread' thread checks `jobDone` flag after exiting the `synchronized` block and, if it is true, skips the last page.
    > 
    > In this fix, not only the `jobDone` is checked, but also that there is no other page to be printed.
    > It was also needed to introduce a new flag 'jobCanceled', to skip the page if the printing was canceled by 'cancelJob()'.
    
    eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
    
      8295324: Fix race condition in junit test
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/916/files
      - new: https://git.openjdk.org/jfx/pull/916/files/fa47d169..fdec73d8
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=916&range=01
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=916&range=00-01
    
      Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
      Patch: https://git.openjdk.org/jfx/pull/916.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/916/head:pull/916
    
    PR: https://git.openjdk.org/jfx/pull/916
    
    From arapte at openjdk.org  Mon Oct 17 09:46:39 2022
    From: arapte at openjdk.org (Ambarish Rapte)
    Date: Mon, 17 Oct 2022 09:46:39 GMT
    Subject: RFR: 8294722: FX: Update copyright year in docs, readme files to 2023
    Message-ID: 
    
    Update Copyright year in these 3 doc files to 2023.
    
    -------------
    
    Commit messages:
     - copyright update in docs
    
    Changes: https://git.openjdk.org/jfx/pull/917/files
     Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=917&range=00
      Issue: https://bugs.openjdk.org/browse/JDK-8294722
      Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
      Patch: https://git.openjdk.org/jfx/pull/917.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/917/head:pull/917
    
    PR: https://git.openjdk.org/jfx/pull/917
    
    From arapte at openjdk.org  Mon Oct 17 15:26:52 2022
    From: arapte at openjdk.org (Ambarish Rapte)
    Date: Mon, 17 Oct 2022 15:26:52 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v3]
    In-Reply-To: 
    References: 
     <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
     
     
    Message-ID: 
    
    On Fri, 14 Oct 2022 15:15:27 GMT, Douglas Held  wrote:
    
    >> Looking at the JavaDoc in the rest of the class, the {@code Point3D} tags are not used outside of these two methods hashCode() and equals(). I'd propose actually that we remove them, for consistency with the rest of the JavaDoc in this class.
    >
    > ...correction, found in toString() as well.
    
    It would be suitable to align with our existing doc comment in other classes, for example as here,
    
    1. https://github.com/openjdk/jfx/blob/9768b5e42391e2d48aefffa3a3f6b1de6c30ef9d/modules/javafx.graphics/src/main/java/javafx/geometry/Point2D.java#L374
    2. https://github.com/openjdk/jfx/blob/9768b5e42391e2d48aefffa3a3f6b1de6c30ef9d/modules/javafx.graphics/src/main/java/javafx/geometry/Insets.java#L103
    3. https://github.com/openjdk/jfx/blob/9768b5e42391e2d48aefffa3a3f6b1de6c30ef9d/modules/javafx.graphics/src/main/java/javafx/geometry/BoundingBox.java#L169
    
    
    I would recommend to use as in Point2D,
    
    
        /**
         * Indicates whether some other object is "equal to" this one.
         *
         * @param obj the reference object with which to compare
         * @return true if this Point3D is the same as the obj argument; false otherwise
         */
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From angorya at openjdk.org  Mon Oct 17 16:15:01 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Mon, 17 Oct 2022 16:15:01 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
     <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
     
    Message-ID: 
    
    On Fri, 14 Oct 2022 23:01:48 GMT, Andy Goryachev  wrote:
    
    >> I agree with your first point, but I think limiting any changes to `Node` because it would add another field is not a good enough argument.  It would depend on its merits.
    >> 
    >> The second point, there is much more to the `shownProperty` then you might think at first glance. In combination with `when`, it offers a standard way to manage life cycles for controls.  It is a very natural fit to tie the lifecycle of bindings and listeners to whether a control is actually currently shown.  You may think that a Listener helper class would be just as flexible, but it isn't.  The helper is not available everywhere (unless you propose to integrate it into Node), which means when constructing complicated UI's which may have smaller groups of controls that are created by other classes, methods or factories, that you may have to pass along an instance of your helper to all these to make sure they register their bindings and listeners with it (or perhaps to link multiple Listener helper classes together in some kind of hierarchy, that matches the control groupings that might have separate life cycles).
    >> 
    >> The `shownProperty` does not have this problem. Since you can tie the lifecycle to your own small piece of the UI (ie, a factory that creates a `BorderPane` with several controls, can tie all these to the lifecycle of the `BorderPane`).  When this `BorderPane` is just a piece of UI used as part of a larger whole, its lifecycle still works as expected -- if it is not shown, its listeners disappear.  If the whole window is destroyed, then the same happens.  If however the Pane next to it is destroyed, only their listeners disappear.  With a helper system, you'd need to coordinate this somehow, perhaps having that `BorderPane` return its helper, so the large UI can tie it to its helper, so when the main helper is called to unsubscribe, that all its child helpers are also unsubscribed...
    >> 
    >> Another advantage is that a listener does not have to start working right away.  When setting up a new pane of controls, many subscriptions may need to be made.  When using `when(control::shownProperty)` these listeners don't immediately become active (potentially while still constructing and initializing your control).  Only when the control is fully constructed, and added to an active Scene and Window do all the listeners become active.  This can be important when listening to external properties that change often and may even change during construction.
    >> 
    >> In ReactFX it the `shownProperty` was deemed important enough to go one step further and even create a separate method on what would be `ObservableValue` called `conditionOnShowing`.  
    >> 
    >> In short, `when` and the `shownProperty` is basically used every time you create a binding or add a listener between two properties that have a different lifecycle, like between a model and a control.  This completely removes the responsibility of having to track these bindings or listeners separately; it becomes automatic. Subscribing all at once when it becomes first shown becomes automatic (and you immediately get the first value), unsubscribing when it goes invisible is automatic, and resubscribing if a control becomes shown again is completely transparent.
    >> 
    >> In my projects, I've completely eliminated memory leaks without a single call to `removeListener` or `unbind` anywhere. 
    >> There are no explicit weak listeners (and not just because they're incredibly cumbersome to use), nor is there anywhere where subscriptions or bindings are being tracked (aside from the `when` construct).  I'm very picky about memory leaks, so I have a Scene scanner, that maintains weak references to all Nodes at all times, and warns me if any are not getting GC'd after not being part of a Scene for a while.  In 99% of the cases, I forgot a `when`, where in plain JavaFX you'd be forced to use a weak listener.
    >> 
    >> The simple rule to follow is, whenever you bind or listen to or on a property, if they have different lifecycles, then use a `when`, otherwise bind or listen directly.
    >> 
    >> Some examples of how it is used:
    >> 
    >> Below is a very common pattern when binding any property that has a different lifecycle than its target, this is one of many:
    >> 
    >>     longLivedModel.selectedItem
    >>          .when(this::shownProperty)   // this = BorderPane, and the code is part of its constructor)
    >>          .addListener((obs, old, current) -> {
    >>               // code that starts a transition from the previous item to the next item
    >>          }
    >>     );
    >> 
    >> Below some binding examples where several properties are bound to long lived versions:
    >> 
    >>     ObservableValue shown = pane.shownProperty();
    >> 
    >>     pane.model.work.bind(presentation.root.when(shown));
    >>     pane.model.missingFraction.bind(presentation.missingFraction.when(shown));
    >>     pane.model.watchedFraction.bind(presentation.watchedFraction.when(shown));
    >> 
    >> Below a "bidirectional binding" for a `Slider` control, where one direction is long lived.  The binding vanishes on its own when the UI that is using it is closed -- this is part of a UI generator, so this code has no idea where the UI might end up being used or for how long, but it can still manage the lifecycle easily:
    >> 
    >>     longLivedValue.when(slider::shownProperty).map(toNumber).subscribe(slider.valueProperty()::setValue);
    >>     slider.valueProperty().map(fromNumber).subscribe(longLivedValue::setValue);
    >> 
    >> Another example to make sure a `Timeline` is stopped/started automatically based on visibility (Timeline's will keep references around if not stopped):
    >> 
    >>     center.shownProperty()  // center here is a Pane
    >>       .addListener((obs, old, visible) -> {
    >>         if(visible) timeline.playFromStart();
    >>         else timeline.stop();
    >>       });
    >> 
    >> So, I think it certainly has some merit to include it :)
    >> 
    >>> And another thing - Window and Dialog are not Nodes, but they do have showing property.
    >> 
    >> I'm unsure what you are saying here.  I don't think we need to tie anything directly to a Window or Dialog, only to controls they might contain.  Also the `shownProperty` is not useful for properties not associated with controls; depending on what the properties are used for people may have to create their own `active` property or something else that identifies the lifecycle of those properties.  For control properties though, their lifecycle is quite clear and I think it makes great sense to tie to whether they're actually visible or not.
    >
    > What I meant is you can add it in Node.getProperties() and not to add a pointer to every Node everywhere.  If it's used, the actual properties will be created in a few containers.
    
    private static final Object KEY = new Object();
    
    public final ReadOnlyBooleanProperty shownProperty() {
      Object x = getProperties().get(KEY);
      if (x instanceof ReadOnlyBooleanProperty p) {
        return p;
      }
      ReadOnlyBooleanProperty p = ... // create
      getProperties().put(KEY, p);
      return p;
    }
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From nlisker at openjdk.org  Mon Oct 17 17:14:21 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Mon, 17 Oct 2022 17:14:21 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v3]
    In-Reply-To: 
    References: 
     <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
     
     
    Message-ID: <7YFxikJnXAPBtPhjAxmiVI4J9aSw2C8KmcrsteGFGAU=.b8bb32cf-c050-4080-9f5a-3facb2284ba5@github.com>
    
    On Fri, 14 Oct 2022 15:08:24 GMT, Douglas Held  wrote:
    
    >> Not strictly enforced, but adding a blank line does aid readability (of the source code...the generated docs don't care).
    >
    > If I were to add empty lines before JavaDoc tags such as @param etc, then for consistency I think I should do it for the whole class, where they are not present.
    > 
    > Note, on line 32: **// PENDING_DOC_REVIEW of this whole class**
    > Maybe we should first decide whether we are scrubbing all doc for the whole class, or making a minimal change to the obviously incorrect information. My feeling is now tending toward the latter.
    > 
    > It could very well be that I misunderstood the comment by nlisker.
    
    We just tend to separate the words section from the tags section with an empty line in the source code. You don't have to do it for the whole class (unless you want to), I just suggest to do it here since you're making a change anyway.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From nlisker at openjdk.org  Mon Oct 17 17:14:21 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Mon, 17 Oct 2022 17:14:21 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v3]
    In-Reply-To: 
    References: 
     <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
     
     
     
    Message-ID: 
    
    On Mon, 17 Oct 2022 15:24:48 GMT, Ambarish Rapte  wrote:
    
    >> ...correction, found in toString() as well.
    >
    > It would be suitable to align with our existing doc comment in other classes, for example as here,
    > 
    > 1. https://github.com/openjdk/jfx/blob/9768b5e42391e2d48aefffa3a3f6b1de6c30ef9d/modules/javafx.graphics/src/main/java/javafx/geometry/Point2D.java#L374
    > 2. https://github.com/openjdk/jfx/blob/9768b5e42391e2d48aefffa3a3f6b1de6c30ef9d/modules/javafx.graphics/src/main/java/javafx/geometry/Insets.java#L103
    > 3. https://github.com/openjdk/jfx/blob/9768b5e42391e2d48aefffa3a3f6b1de6c30ef9d/modules/javafx.graphics/src/main/java/javafx/geometry/BoundingBox.java#L169
    > 
    > 
    > I would recommend to use as in Point2D,
    > 
    > 
    >     /**
    >      * Indicates whether some other object is "equal to" this one.
    >      *
    >      * @param obj the reference object with which to compare
    >      * @return true if this Point3D is the same as the obj argument; false otherwise
    >      */
    
    I think that we should explain what makes 2 objects equal. Even if we don't explicitly name the methods used for comparison, we could say "2 points are equals if their coordinates are equal".
    
    By the way, I have https://bugs.openjdk.org/browse/JDK-8226930 assigned to go over some dubious equals/hashcode implementations, in case you want to delegate the task.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From kcr at openjdk.org  Tue Oct 18 03:03:22 2022
    From: kcr at openjdk.org (Kevin Rushforth)
    Date: Tue, 18 Oct 2022 03:03:22 GMT
    Subject: RFR: 8294722: FX: Update copyright year in docs,
     readme files to 2023
    In-Reply-To: 
    References: 
    Message-ID: <2D8dmbk9nfgmN2W0BmNDkvbIuSg5WR0mCto1fWVeREg=.5df6fff8-0b5a-4f06-9195-6eeb27a8ca73@github.com>
    
    On Mon, 17 Oct 2022 09:36:55 GMT, Ambarish Rapte  wrote:
    
    > Update Copyright year in these 3 doc files to 2023.
    
    Marked as reviewed by kcr (Lead).
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/917
    
    From arapte at openjdk.org  Tue Oct 18 04:50:52 2022
    From: arapte at openjdk.org (Ambarish Rapte)
    Date: Tue, 18 Oct 2022 04:50:52 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v3]
    In-Reply-To: 
    References: 
     <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
     
     
     
     
    Message-ID: 
    
    On Mon, 17 Oct 2022 17:07:40 GMT, Nir Lisker  wrote:
    
    >> It would be suitable to align with our existing doc comment in other classes, for example as here,
    >> 
    >> 1. https://github.com/openjdk/jfx/blob/9768b5e42391e2d48aefffa3a3f6b1de6c30ef9d/modules/javafx.graphics/src/main/java/javafx/geometry/Point2D.java#L374
    >> 2. https://github.com/openjdk/jfx/blob/9768b5e42391e2d48aefffa3a3f6b1de6c30ef9d/modules/javafx.graphics/src/main/java/javafx/geometry/Insets.java#L103
    >> 3. https://github.com/openjdk/jfx/blob/9768b5e42391e2d48aefffa3a3f6b1de6c30ef9d/modules/javafx.graphics/src/main/java/javafx/geometry/BoundingBox.java#L169
    >> 
    >> 
    >> I would recommend to use as in Point2D,
    >> 
    >> 
    >>     /**
    >>      * Indicates whether some other object is "equal to" this one.
    >>      *
    >>      * @param obj the reference object with which to compare
    >>      * @return true if this Point3D is the same as the obj argument; false otherwise
    >>      */
    >
    > I think that we should explain what makes 2 objects equal. Even if we don't explicitly name the methods used for comparison, we could say "2 points are equals if their coordinates are equal".
    > 
    > By the way, I have https://bugs.openjdk.org/browse/JDK-8226930 assigned to go over some dubious equals/hashcode implementations, in case you want to delegate the task.
    
    Agreed, mentioning equality criteria sounds good to me too. How does this look ?
    
    
        /**
         * Indicates whether some other object is "equal to" this one.
         * Two instances of Point3D are equal if the return values of their
         * {@code getX}, {@code getY}, and {@code getZ} methods are equal.
         *
         * @param obj the reference object with which to compare
         * @return true if this Point3D is the same as the obj argument; false otherwise
         */
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From jhendrikx at openjdk.org  Tue Oct 18 05:43:08 2022
    From: jhendrikx at openjdk.org (John Hendrikx)
    Date: Tue, 18 Oct 2022 05:43:08 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
     <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
     
     
    Message-ID: 
    
    On Mon, 17 Oct 2022 16:11:32 GMT, Andy Goryachev  wrote:
    
    >> What I meant is you can add it in Node.getProperties() and not to add a pointer to every Node everywhere.  If it's used, the actual properties will be created in a few containers.
    >
    > private static final Object KEY = new Object();
    > 
    > public final ReadOnlyBooleanProperty shownProperty() {
    >   Object x = getProperties().get(KEY);
    >   if (x instanceof ReadOnlyBooleanProperty p) {
    >     return p;
    >   }
    >   ReadOnlyBooleanProperty p = ... // create
    >   getProperties().put(KEY, p);
    >   return p;
    > }
    
    Thanks, I understand, what I find odd is that this would be the first property in `Node` to be stored this way.  If this was so important, then why isn't this done for other properties? There seem to be sufficient candidates for this approach to "slim" down `Node` (infrequently used properties like `Subscene`, `id`, `style`, `blendMode`).
    
    There's even a `MiscProperties` objects which is described as "Misc Seldom Used Properties" that is created only when needed with these properties:
    
            private LazyBoundsProperty boundsInParent;
            private LazyBoundsProperty boundsInLocal;
            private BooleanProperty cache;
            private ObjectProperty cacheHint;
            private ObjectProperty clip;
            private ObjectProperty cursor;
            private ObjectProperty depthTest;
            private BooleanProperty disable;
            private ObjectProperty effect;
            private ObjectProperty inputMethodRequests;
            private BooleanProperty mouseTransparent;
            private DoubleProperty viewOrder;
    
    Let's see what others think before I change this. It does sound like a reasonable approach though.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From jhendrikx at openjdk.org  Tue Oct 18 06:17:43 2022
    From: jhendrikx at openjdk.org (John Hendrikx)
    Date: Tue, 18 Oct 2022 06:17:43 GMT
    Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding
     and other classes
    In-Reply-To: 
    References: 
     
     
     
     
    Message-ID: 
    
    On Tue, 28 Apr 2020 00:00:28 GMT, Kevin Rushforth  wrote:
    
    >> I will review this too anyway.
    >
    >> I will review this too anyway.
    > 
    > Thank you. That will be helpful.
    
    @kevinrushforth I was going through my open JDK tickets, and saw that this slipped through the cracks.
    
    This ticket would need another reviewer still, @arapte could you take a look?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/198
    
    From nlisker at openjdk.org  Tue Oct 18 11:34:12 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Tue, 18 Oct 2022 11:34:12 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v3]
    In-Reply-To: 
    References: 
     <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
     
     
     
     
     
    Message-ID: 
    
    On Tue, 18 Oct 2022 04:47:38 GMT, Ambarish Rapte  wrote:
    
    >> I think that we should explain what makes 2 objects equal. Even if we don't explicitly name the methods used for comparison, we could say "2 points are equals if their coordinates are equal".
    >> 
    >> By the way, I have https://bugs.openjdk.org/browse/JDK-8226930 assigned to go over some dubious equals/hashcode implementations, in case you want to delegate the task.
    >
    > Agreed, mentioning equality criteria sounds good to me too. How does this look ?
    > 
    > 
    >     /**
    >      * Indicates whether some other object is "equal to" this one.
    >      * Two instances of Point3D are equal if the return values of their
    >      * {@code getX}, {@code getY}, and {@code getZ} methods are equal.
    >      *
    >      * @param obj the reference object with which to compare
    >      * @return true if this Point3D is the same as the obj argument; false otherwise
    >      */
    
    This is the current proposal by Douglas and align with `Object::equals` which it is overriding. I'm fine with this wording. Just need to add the `@code` tags.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From kcr at openjdk.org  Tue Oct 18 12:58:20 2022
    From: kcr at openjdk.org (Kevin Rushforth)
    Date: Tue, 18 Oct 2022 12:58:20 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
     <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
     
     
     
    Message-ID: 
    
    On Tue, 18 Oct 2022 05:40:59 GMT, John Hendrikx  wrote:
    
    >> private static final Object KEY = new Object();
    >> 
    >> public final ReadOnlyBooleanProperty shownProperty() {
    >>   Object x = getProperties().get(KEY);
    >>   if (x instanceof ReadOnlyBooleanProperty p) {
    >>     return p;
    >>   }
    >>   ReadOnlyBooleanProperty p = ... // create
    >>   getProperties().put(KEY, p);
    >>   return p;
    >> }
    >
    > Thanks, I understand, what I find odd is that this would be the first property in `Node` to be stored this way.  If this was so important, then why isn't this done for other properties? There seem to be sufficient candidates for this approach to "slim" down `Node` (infrequently used properties like `Subscene`, `id`, `style`, `blendMode`).
    > 
    > There's even a `MiscProperties` objects which is described as "Misc Seldom Used Properties" that is created only when needed with these properties:
    > 
    >         private LazyBoundsProperty boundsInParent;
    >         private LazyBoundsProperty boundsInLocal;
    >         private BooleanProperty cache;
    >         private ObjectProperty cacheHint;
    >         private ObjectProperty clip;
    >         private ObjectProperty cursor;
    >         private ObjectProperty depthTest;
    >         private BooleanProperty disable;
    >         private ObjectProperty effect;
    >         private ObjectProperty inputMethodRequests;
    >         private BooleanProperty mouseTransparent;
    >         private DoubleProperty viewOrder;
    > 
    > Let's see what others think before I change this. It does sound like a reasonable approach though.
    
    I don't have time to review this as I am busy with JavaOne, so this is just a quick note to say that if there is sufficient benefit to add a `shown` property to the core of JavaFX, then it should be added _as_ a property -- possibly in MiscProperties if we think it is a seldom-used property. I don't like the idea of using `getProperties` for this.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From kcr at openjdk.org  Tue Oct 18 12:59:11 2022
    From: kcr at openjdk.org (Kevin Rushforth)
    Date: Tue, 18 Oct 2022 12:59:11 GMT
    Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding
     and other classes
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Mon, 27 Apr 2020 11:43:28 GMT, John Hendrikx  wrote:
    
    > This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in subsequent unbind calls to be no-ops, unless bind was called again first.
    > 
    > I had to rewrite the parameterized test slightly as Parameterized will only call the parameters method once, and my new test modifies the internal state of the bindings used as parameters (by doing some unbind calls) which was making other tests fail.
    
    Yes, it did fall through the cracks. I wasn't sure it was still relevant, but since it is, I'll put it on my queue.
    
    Perhaps either @arapte or @nlisker can be the second reviewer.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/198
    
    From nlisker at openjdk.org  Tue Oct 18 13:51:17 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Tue, 18 Oct 2022 13:51:17 GMT
    Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v7]
    In-Reply-To: 
    References: 
     
    Message-ID: 
    
    On Thu, 1 Sep 2022 11:23:44 GMT, Nir Lisker  wrote:
    
    >> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier.
    >> 
    >> Since there are many small changes, I'm giving a full list here:
    >> 
    >> **Java**
    >> 
    >> * `NGShape3D.java`
    >>   * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`.
    >>   * Normalized the direction here instead of in the native code.
    >>   * Ambient light is now only set when it exists (and is not black).
    >> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method).
    >> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change.
    >> 
    >> **Native C++**
    >> 
    >> * Initialized the class members of `D3DLight`, `D3DMeshView`  and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). 
    >> * `D3DLight`
    >>   * Commented out unused methods. Were they supposed to be used at some point?
    >>   * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing.
    >> * `D3DPhongShader.h`
    >>   * Renamed some of the register constants for more clarity.
    >>   * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused.
    >>   * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position.
    >> * `D3DMeshView.cc`
    >>   * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders.
    >>   * Removed the direction normalization as stated in the change for `NGShape3D.java`.
    >>   * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`.
    >> 
    >> **Native shaders**
    >> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera).
    >> * Commented out many unused functions. I don't know what they are for, so I didn't remove them.
    >> * `vsConstants`
    >>   * Removed the light color from here since it's unused, only the position is.
    >>   * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead.
    >> * `vs2ps`
    >>   * Removed the ambient color interpolation, which frees a register (no change in performance).
    >>   * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?).
    >> * `Mtl1PS` and `psMath`
    >>   * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity.
    >>   * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`.
    >> 
    >> No changes in performance were measured and the behavior stayed the same.
    >
    > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   Addressed review comment
    
    @kevinrushforth If this fell through the cracks please add it to the list too :) It's a blocker for future work.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/789
    
    From arapte at openjdk.org  Tue Oct 18 14:37:15 2022
    From: arapte at openjdk.org (Ambarish Rapte)
    Date: Tue, 18 Oct 2022 14:37:15 GMT
    Subject: Integrated: 8294722: FX: Update copyright year in docs,
     readme files to 2023
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Mon, 17 Oct 2022 09:36:55 GMT, Ambarish Rapte  wrote:
    
    > Update Copyright year in these 3 doc files to 2023.
    
    This pull request has now been integrated.
    
    Changeset: f448e9ad
    Author:    Ambarish Rapte 
    URL:       https://git.openjdk.org/jfx/commit/f448e9ad589caa01f24c345d1db37c933c8e0dc8
    Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod
    
    8294722: FX: Update copyright year in docs, readme files to 2023
    
    Reviewed-by: kcr
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/917
    
    From angorya at openjdk.org  Tue Oct 18 16:08:50 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Tue, 18 Oct 2022 16:08:50 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
     <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
     
     
     
     
    Message-ID: 
    
    On Tue, 18 Oct 2022 12:54:22 GMT, Kevin Rushforth  wrote:
    
    >> Thanks, I understand, what I find odd is that this would be the first property in `Node` to be stored this way.  If this was so important, then why isn't this done for other properties? There seem to be sufficient candidates for this approach to "slim" down `Node` (infrequently used properties like `Subscene`, `id`, `style`, `blendMode`).
    >> 
    >> There's even a `MiscProperties` objects which is described as "Misc Seldom Used Properties" that is created only when needed with these properties:
    >> 
    >>         private LazyBoundsProperty boundsInParent;
    >>         private LazyBoundsProperty boundsInLocal;
    >>         private BooleanProperty cache;
    >>         private ObjectProperty cacheHint;
    >>         private ObjectProperty clip;
    >>         private ObjectProperty cursor;
    >>         private ObjectProperty depthTest;
    >>         private BooleanProperty disable;
    >>         private ObjectProperty effect;
    >>         private ObjectProperty inputMethodRequests;
    >>         private BooleanProperty mouseTransparent;
    >>         private DoubleProperty viewOrder;
    >> 
    >> Let's see what others think before I change this. It does sound like a reasonable approach though.
    >
    > I don't have time to review this as I am busy with JavaOne, so this is just a quick note to say that if there is sufficient benefit to add a `shown` property to the core of JavaFX, then it should be added _as_ a property -- possibly in MiscProperties if we think it is a seldom-used property. I don't like the idea of using `getProperties` for this.
    
    I'd respectfully disagree: in a large application, there might be hundreds (a thousand?) Nodes, and only a handful (10-20?) Nodes with this property (2%), so it's a waste of RAM.  One may think it's only 8Kb on a 64 bit machine, but it does add up quickly.  Even the access pattern is basically 'get it once to establish the fluent pipeline', with no more calls to the Node accessor (unlike MiscProperties constituents, some of which get accessed rather frequently).
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From mstrauss at openjdk.org  Tue Oct 18 17:51:30 2022
    From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
    Date: Tue, 18 Oct 2022 17:51:30 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
     <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
     
     
     
     
     
    Message-ID: <4qaP2ODitUQ99yAAef-F-6edSEJ29yRDx8Jiw5I9ce4=.eee98893-f18d-4470-8ddd-63f4c25fbb73@github.com>
    
    On Tue, 18 Oct 2022 16:03:39 GMT, Andy Goryachev  wrote:
    
    > I'd respectfully disagree: in a large application, there might be hundreds (a thousand?) Nodes, and only a handful (10-20?) Nodes with this property (2%), so it's a waste of RAM. One may think it's only 8Kb on a 64 bit machine, but it does add up quickly. Even the access pattern is basically 'get it once to establish the fluent pipeline', with no more calls to the Node accessor (unlike MiscProperties constituents, some of which get accessed rather frequently).
    
    I understand your point, but I don't think that this is sufficient reason to introduce a new way of storing property instances in an ad-hoc manner. If memory consumption is a concern, I would rather analyze the issue in a separate enhancement proposal, think it through in terms of API, and then transition all relevant property instances to the new storage mechanism. Part of that proposal should also be an evaluation of the trade-offs between memory consumption and performance in terms of cache locality and lookup speed.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From nlisker at openjdk.org  Tue Oct 18 18:09:15 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Tue, 18 Oct 2022 18:09:15 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: <4qaP2ODitUQ99yAAef-F-6edSEJ29yRDx8Jiw5I9ce4=.eee98893-f18d-4470-8ddd-63f4c25fbb73@github.com>
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
     <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
     
     
     
     
     
     <4qaP2ODitUQ99yAAef-F-6edSEJ29yRDx8Jiw5I9ce4=.eee98893-f18d-4470-8ddd-63f4c25fbb73@github.com>
    Message-ID: 
    
    On Tue, 18 Oct 2022 17:47:38 GMT, Michael Strau?  wrote:
    
    >> I'd respectfully disagree: in a large application, there might be hundreds (a thousand?) Nodes, and only a handful (10-20?) Nodes with this property (2%), so it's a waste of RAM.  One may think it's only 8Kb on a 64 bit machine, but it does add up quickly.  Even the access pattern is basically 'get it once to establish the fluent pipeline', with no more calls to the Node accessor (unlike MiscProperties constituents, some of which get accessed rather frequently).
    >
    >> I'd respectfully disagree: in a large application, there might be hundreds (a thousand?) Nodes, and only a handful (10-20?) Nodes with this property (2%), so it's a waste of RAM. One may think it's only 8Kb on a 64 bit machine, but it does add up quickly. Even the access pattern is basically 'get it once to establish the fluent pipeline', with no more calls to the Node accessor (unlike MiscProperties constituents, some of which get accessed rather frequently).
    > 
    > I understand your point, but I don't think that this is sufficient reason to introduce a new way of storing property instances in an ad-hoc manner. If memory consumption is a concern, I would rather analyze the issue in a separate enhancement proposal, think it through in terms of API, and then transition all relevant property instances to the new storage mechanism. Part of that proposal should also be an evaluation of the trade-offs between memory consumption and performance in terms of cache locality and lookup speed.
    
    `getProperties()` isn't the place for this. After looking at the grouping of properties, there might be merit to reevaluate the distribution of properties into their helper classes in the case that a single use of a common property will create many other unused ones.
    
    As for RAM usage, Hotspot can compress pointers on a 64bit machine. I don't think that the change in memory here will be more significant than in other areas in `Node` that can be addressed.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Tue Oct 18 18:37:12 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Tue, 18 Oct 2022 18:37:12 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
     <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
     
     
     
     
     
     <4qaP2ODitUQ99yAAef-F-6edSEJ29yRDx8Jiw5I9ce4=.eee98893-f18d-4470-8ddd-63f4c25fbb73@github.com>
     
    Message-ID: 
    
    On Tue, 18 Oct 2022 18:06:49 GMT, Nir Lisker  wrote:
    
    > `getProperties()` isn't the place for this.
    
    can you explain why?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Tue Oct 18 18:47:14 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Tue, 18 Oct 2022 18:47:14 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: <4qaP2ODitUQ99yAAef-F-6edSEJ29yRDx8Jiw5I9ce4=.eee98893-f18d-4470-8ddd-63f4c25fbb73@github.com>
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
     <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
     
     
     
     
     
     <4qaP2ODitUQ99yAAef-F-6edSEJ29yRDx8Jiw5I9ce4=.eee98893-f18d-4470-8ddd-63f4c25fbb73@github.com>
    Message-ID: 
    
    On Tue, 18 Oct 2022 17:47:38 GMT, Michael Strau?  wrote:
    
    >> I'd respectfully disagree: in a large application, there might be hundreds (a thousand?) Nodes, and only a handful (10-20?) Nodes with this property (2%), so it's a waste of RAM.  One may think it's only 8Kb on a 64 bit machine, but it does add up quickly.  Even the access pattern is basically 'get it once to establish the fluent pipeline', with no more calls to the Node accessor (unlike MiscProperties constituents, some of which get accessed rather frequently).
    >
    >> I'd respectfully disagree: in a large application, there might be hundreds (a thousand?) Nodes, and only a handful (10-20?) Nodes with this property (2%), so it's a waste of RAM. One may think it's only 8Kb on a 64 bit machine, but it does add up quickly. Even the access pattern is basically 'get it once to establish the fluent pipeline', with no more calls to the Node accessor (unlike MiscProperties constituents, some of which get accessed rather frequently).
    > 
    > I understand your point, but I don't think that this is sufficient reason to introduce a new way of storing property instances in an ad-hoc manner. If memory consumption is a concern, I would rather analyze the issue in a separate enhancement proposal, think it through in terms of API, and then transition all relevant property instances to the new storage mechanism. Part of that proposal should also be an evaluation of the trade-offs between memory consumption and performance in terms of cache locality and lookup speed.
    
    @mstr2 : 
    `getProperties()` is a perfectly fine way of storing a property instance, especially considering the fact that this property will be called exactly once - during the fluent pipeline setup.  Of course, it does not apply to other properties that are being called all the time.
    
    A separate ticket for optimizing property storage might be a good idea, I agree.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From duke at openjdk.org  Tue Oct 18 22:15:35 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Tue, 18 Oct 2022 22:15:35 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v4]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting in the method signatures of equals(), hashCode() and toString().~~
    > 
    > For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    
    Douglas Held has updated the pull request incrementally with one additional commit since the last revision:
    
      Update Point3D.java
      
      Per review
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/913/files
      - new: https://git.openjdk.org/jfx/pull/913/files/0c52ce57..eb08b561
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=913&range=03
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=913&range=02-03
    
      Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
      Patch: https://git.openjdk.org/jfx/pull/913.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/913/head:pull/913
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Tue Oct 18 22:22:15 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Tue, 18 Oct 2022 22:22:15 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v4]
    In-Reply-To: <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
    References: 
     <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
    Message-ID: 
    
    On Thu, 13 Oct 2022 14:16:23 GMT, Nir Lisker  wrote:
    
    >> Douglas Held has updated the pull request incrementally with one additional commit since the last revision:
    >> 
    >>   Update Point3D.java
    >>   
    >>   Per review
    >
    > Changes requested by nlisker (Reviewer).
    
    Tagged @nlisker to validate the code tags are included appropriately.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Tue Oct 18 22:22:15 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Tue, 18 Oct 2022 22:22:15 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v4]
    In-Reply-To: 
    References: 
     <17WMD-wOVrryvXZA6VH0HtDiRu-M9kpVEHOFguZBA6w=.47f51b0d-3310-4360-ba2d-6af9a794f6ad@github.com>
     
     
     
     
     
     
    Message-ID: 
    
    On Tue, 18 Oct 2022 11:32:04 GMT, Nir Lisker  wrote:
    
    >> Agreed, mentioning equality criteria sounds good to me too. How does this look ?
    >> 
    >> 
    >>     /**
    >>      * Indicates whether some other object is "equal to" this one.
    >>      * Two instances of Point3D are equal if the return values of their
    >>      * {@code getX}, {@code getY}, and {@code getZ} methods are equal.
    >>      *
    >>      * @param obj the reference object with which to compare
    >>      * @return true if this Point3D is the same as the obj argument; false otherwise
    >>      */
    >
    > This is the current proposal by Douglas and align with `Object::equals` which it is overriding. I'm fine with this wording. Just need to add the `@code` tags.
    
    I have added a commit to match the proposed block by arapte.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From nlisker at openjdk.org  Tue Oct 18 23:42:15 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Tue, 18 Oct 2022 23:42:15 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v4]
    In-Reply-To: 
    References: 
     
    Message-ID: 
    
    On Tue, 18 Oct 2022 22:15:35 GMT, Douglas Held  wrote:
    
    >> The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting in the method signatures of equals(), hashCode() and toString().~~
    >> 
    >> For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    >
    > Douglas Held has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   Update Point3D.java
    >   
    >   Per review
    
    modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 414:
    
    > 412:     /**
    > 413:      * Indicates whether some other object is "equal to" this one.
    > 414:      * Two instances of Point3D are equal if the return values of their
    
    `Point3D` also needs `@code`.
    
    modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 418:
    
    > 416:      *
    > 417:      * @param obj the reference object with which to compare
    > 418:      * @return true if this Point3D is the same as the obj argument; false otherwise
    
    `Point3D`, `true`, `false` and `obj` need `@code`.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Wed Oct 19 12:34:15 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Wed, 19 Oct 2022 12:34:15 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v5]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting in the method signatures of equals(), hashCode() and toString().~~
    > 
    > For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    
    Douglas Held has updated the pull request incrementally with one additional commit since the last revision:
    
      Update Point3D.java
      
      Per review
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/913/files
      - new: https://git.openjdk.org/jfx/pull/913/files/eb08b561..374f51e5
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=913&range=04
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=913&range=03-04
    
      Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
      Patch: https://git.openjdk.org/jfx/pull/913.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/913/head:pull/913
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Wed Oct 19 12:35:43 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Wed, 19 Oct 2022 12:35:43 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v4]
    In-Reply-To: 
    References: 
     
    Message-ID: 
    
    On Tue, 18 Oct 2022 22:15:35 GMT, Douglas Held  wrote:
    
    >> The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting in the method signatures of equals(), hashCode() and toString().~~
    >> 
    >> For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    >
    > Douglas Held has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   Update Point3D.java
    >   
    >   Per review
    
    I think this equals() method JavaDoc should be compliant now.
    
    I must apologise. I thought the code tags produced hyperlinks. Now I can see they only apply a fixed width type font. Of course, the formatting tags need to apply in all of the places discussed.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From nlisker at openjdk.org  Wed Oct 19 12:38:39 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Wed, 19 Oct 2022 12:38:39 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v5]
    In-Reply-To: 
    References: 
     
    Message-ID: 
    
    On Wed, 19 Oct 2022 12:34:15 GMT, Douglas Held  wrote:
    
    >> The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting in the method signatures of equals(), hashCode() and toString().~~
    >> 
    >> For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    >
    > Douglas Held has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   Update Point3D.java
    >   
    >   Per review
    
    modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 417:
    
    > 415:      * {@code getX}, {@code getY}, and {@code getZ} methods are equal.
    > 416:      *
    > 417:      * @param {@code obj} the reference object with which to compare
    
    Don't use `@code` for the parameter declaration, they are treated automatically by the javadoc tool.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Wed Oct 19 12:51:21 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Wed, 19 Oct 2022 12:51:21 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v6]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting in the method signatures of equals(), hashCode() and toString().~~
    > 
    > For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    
    Douglas Held has updated the pull request incrementally with one additional commit since the last revision:
    
      Update Point3D.java
      
      Per review by nlisker
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/913/files
      - new: https://git.openjdk.org/jfx/pull/913/files/374f51e5..323b2f81
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=913&range=05
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=913&range=04-05
    
      Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
      Patch: https://git.openjdk.org/jfx/pull/913.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/913/head:pull/913
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From nlisker at openjdk.org  Wed Oct 19 12:51:21 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Wed, 19 Oct 2022 12:51:21 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v6]
    In-Reply-To: 
    References: 
     
    Message-ID: <7vGQsoMm-S25B8jFkTnf4QSxcfKsVikyLx-_2u-CoD4=.b2d9fd17-3730-4b8d-9dea-ab1e3077c185@github.com>
    
    On Wed, 19 Oct 2022 12:47:31 GMT, Douglas Held  wrote:
    
    >> The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting in the method signatures of equals(), hashCode() and toString().~~
    >> 
    >> For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    >
    > Douglas Held has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   Update Point3D.java
    >   
    >   Per review by nlisker
    
    Marked as reviewed by nlisker (Reviewer).
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From nlisker at openjdk.org  Wed Oct 19 12:51:21 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Wed, 19 Oct 2022 12:51:21 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v4]
    In-Reply-To: 
    References: 
     
     
    Message-ID: 
    
    On Wed, 19 Oct 2022 12:33:37 GMT, Douglas Held  wrote:
    
    > I thought the code tags produced hyperlinks.
    
    Those would be the `@link` tags, or `@linkplain`.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Wed Oct 19 12:51:22 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Wed, 19 Oct 2022 12:51:22 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v5]
    In-Reply-To: 
    References: 
     
    Message-ID: 
    
    On Wed, 19 Oct 2022 12:34:15 GMT, Douglas Held  wrote:
    
    >> The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting in the method signatures of equals(), hashCode() and toString().~~
    >> 
    >> For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    >
    > Douglas Held has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   Update Point3D.java
    >   
    >   Per review
    
    I think there's something else of quality worth discussing here. Is `==` appropriate given the values under comparison are `double`?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Wed Oct 19 12:51:22 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Wed, 19 Oct 2022 12:51:22 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v5]
    In-Reply-To: 
    References: 
     
     
    Message-ID: 
    
    On Wed, 19 Oct 2022 12:36:30 GMT, Nir Lisker  wrote:
    
    >> Douglas Held has updated the pull request incrementally with one additional commit since the last revision:
    >> 
    >>   Update Point3D.java
    >>   
    >>   Per review
    >
    > modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 417:
    > 
    >> 415:      * {@code getX}, {@code getY}, and {@code getZ} methods are equal.
    >> 416:      *
    >> 417:      * @param {@code obj} the reference object with which to compare
    > 
    > Don't use `@code` for the parameter declaration, they are treated automatically by the javadoc tool.
    
    Don't use it for `obj` you mean?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From nlisker at openjdk.org  Wed Oct 19 12:51:22 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Wed, 19 Oct 2022 12:51:22 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v5]
    In-Reply-To: 
    References: 
     
     
     
    Message-ID: 
    
    On Wed, 19 Oct 2022 12:38:54 GMT, Douglas Held  wrote:
    
    >> modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 417:
    >> 
    >>> 415:      * {@code getX}, {@code getY}, and {@code getZ} methods are equal.
    >>> 416:      *
    >>> 417:      * @param {@code obj} the reference object with which to compare
    >> 
    >> Don't use `@code` for the parameter declaration, they are treated automatically by the javadoc tool.
    >
    > Don't use it for `obj` you mean?
    
    Here, yes. The parameter name following `@param` is taken care of automatically (a hyphen is also added after it).
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Wed Oct 19 12:51:22 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Wed, 19 Oct 2022 12:51:22 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v5]
    In-Reply-To: 
    References: 
     
     
     
     
    Message-ID: 
    
    On Wed, 19 Oct 2022 12:41:20 GMT, Nir Lisker  wrote:
    
    >> Don't use it for `obj` you mean?
    >
    > Here, yes. The parameter name following `@param` is taken care of automatically (a hyphen is also added after it).
    
    and we don't need period `.` at the end of each `param` or `returns` line?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From nlisker at openjdk.org  Wed Oct 19 12:54:45 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Wed, 19 Oct 2022 12:54:45 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v5]
    In-Reply-To: 
    References: 
     
     
    Message-ID: 
    
    On Wed, 19 Oct 2022 12:46:03 GMT, Douglas Held  wrote:
    
    > I think there's something else of quality worth discussing here. Is `==` appropriate given the values under comparison are `double`?
    
    It's not. I have mentioned this exact case in https://bugs.openjdk.org/browse/JDK-8226930. I can assign it to you (or self-assign it yourself) if you want to work on it. If not, I will get to it at some point (no pun intended). This issue will require to go over the classes that override equals and see if they do it properly, including `hashcode`. Sometimes the `equals` implementation is "good enough", so there's not need to rewrite it in all the classes, but especially for public APIs, users should expect correct implementations.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Wed Oct 19 12:54:46 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Wed, 19 Oct 2022 12:54:46 GMT
    Subject: Integrated: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Wed, 12 Oct 2022 17:28:42 GMT, Douglas Held  wrote:
    
    > The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting in the method signatures of equals(), hashCode() and toString().~~
    > 
    > For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    
    This pull request has now been integrated.
    
    Changeset: 60a79156
    Author:    Douglas Held 
    Committer: Nir Lisker 
    URL:       https://git.openjdk.org/jfx/commit/60a79156ebce8b610af002ee6e4283a3409c732b
    Stats:     8 lines in 1 file changed: 5 ins; 0 del; 3 mod
    
    8295236: Update JavaDoc in javafx.geometry.Point3D
    
    Reviewed-by: nlisker
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Wed Oct 19 13:12:15 2022
    From: duke at openjdk.org (Douglas Held)
    Date: Wed, 19 Oct 2022 13:12:15 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v6]
    In-Reply-To: 
    References: 
     
    Message-ID: <3itvoUM4-2PbjFMURGmBrmr9z9U1GqGyDq_Ex1YlONQ=.1fa0e40a-95a6-48a7-854a-813ac5f64f29@github.com>
    
    On Wed, 19 Oct 2022 12:51:21 GMT, Douglas Held  wrote:
    
    >> The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting in the method signatures of equals(), hashCode() and toString().~~
    >> 
    >> For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    >
    > Douglas Held has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   Update Point3D.java
    >   
    >   Per review by nlisker
    
    I wouldn't want to take on this fix, as I'm not well educated in floating point types. I'm glad it is an identified issue.
    
    --
    Douglas Held
    Senior Principal Security Consultant
    NetSuite Product Security Team
    ***@***.***
    
    Note: Sent from a phone/microphone which may have introduced errors I didn?t catch
    
    On 19 Oct 2022, at 13:52, nlisker ***@***.***> wrote:
    
    ?
    
    I think there's something else of quality worth discussing here. Is == appropriate given the values under comparison are double?
    
    It's not. I have mentioned this exact case in https://bugs.openjdk.org/browse/JDK-8226930. I can assign it to you (or self-assign it yourself) if you want to work on it. If not, I will get to it at some point (no pun intended). This issue will require to go over the classes that override equals and see if they do it properly, including hashcode. Sometimes the equals implementation is "good enough", so there's not need to rewrite it in all the classes, but especially for public APIs, users should expect correct implementations.
    
    ?
    Reply to this email directly, view it on GitHub, or unsubscribe.
    You are receiving this because you were mentioned.Message ID: ***@***.***>
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From kcr at openjdk.org  Wed Oct 19 13:16:06 2022
    From: kcr at openjdk.org (Kevin Rushforth)
    Date: Wed, 19 Oct 2022 13:16:06 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v5]
    In-Reply-To: 
    References: 
     
     
     
    Message-ID: 
    
    On Wed, 19 Oct 2022 12:52:33 GMT, Nir Lisker  wrote:
    
    > It's not. I have mentioned this exact case in https://bugs.openjdk.org/browse/JDK-8226930. I can assign it to you (or self-assign it yourself) if you want to work on it. If not, I will get to it at some point (no pun intended). This issue will require to go over the classes that override equals and see if they do it properly, including `hashcode`. Sometimes the `equals` implementation is "good enough", so there's no need to rewrite it in all the classes, but especially for public APIs, users should expect correct implementations.
    
    And it's not just a doc issue: Point3D (at least) violates the contract of `equals` and `hashCode`, since two objects that are considered `equals` can produce different hash codes (e.g., the case of two points, one of which has a value of `+0.0` for one of the coords, and the other of which has `-0.0` for the same coord). Depending on how we change it, it might need a CSR.
    
    So I'd prefer that either you keep the bug or @arapte take it.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From nlisker at openjdk.org  Wed Oct 19 13:35:04 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Wed, 19 Oct 2022 13:35:04 GMT
    Subject: RFR: JDK-8295236: Update JavaDoc in javafx.geometry.Point3D [v6]
    In-Reply-To: 
    References: 
     
    Message-ID: <-zTqvztQSxH_14r3ROzM37BTF1Bhk2vwwUNjuwRFtSw=.d1001295-0ddd-429a-893d-70eb0ee59cab@github.com>
    
    On Wed, 19 Oct 2022 12:51:21 GMT, Douglas Held  wrote:
    
    >> The JavaDoc for equals had a copy/paste error. I normalized the text based on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting in the method signatures of equals(), hashCode() and toString().~~
    >> 
    >> For good measure, some kind of copy/paste detection should probably be added to the many automated checks. For the entire OpenJDK project.
    >
    > Douglas Held has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   Update Point3D.java
    >   
    >   Per review by nlisker
    
    I can keep it.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/913
    
    From duke at openjdk.org  Wed Oct 19 15:00:53 2022
    From: duke at openjdk.org (Lukasz Kostyra)
    Date: Wed, 19 Oct 2022 15:00:53 GMT
    Subject: RFR: 8278426: ImagePool uses terminally deprecated
     System.runFinalization method
    Message-ID: 
    
    This change removes runFinalization calls in ImagePool::pruneCache method.
    
    Finalizers are deprecated in JDK 18 and will be removed soon.
    
    -------------
    
    Commit messages:
     - 8278426: Remove runFinalization calls in ImagePool::pruneCache
    
    Changes: https://git.openjdk.org/jfx/pull/918/files
     Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=918&range=00
      Issue: https://bugs.openjdk.org/browse/JDK-8278426
      Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
      Patch: https://git.openjdk.org/jfx/pull/918.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/918/head:pull/918
    
    PR: https://git.openjdk.org/jfx/pull/918
    
    From arapte at openjdk.org  Wed Oct 19 15:00:54 2022
    From: arapte at openjdk.org (Ambarish Rapte)
    Date: Wed, 19 Oct 2022 15:00:54 GMT
    Subject: RFR: 8278426: ImagePool uses terminally deprecated
     System.runFinalization method
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Mon, 17 Oct 2022 14:02:52 GMT, Lukasz Kostyra  wrote:
    
    > This change removes runFinalization calls in ImagePool::pruneCache method.
    > 
    > Finalizers are deprecated in JDK 18 and will be removed soon.
    
    LGTM. approving.
    We can integrate once OCA is verified.
    
    The title of the PR should be derived from bug as=>  `7 digit BUG-ID: BUG-SUMMARY`
    So it would look as: `8278426: ImagePool uses terminally deprecated System.runFinalization method`
    It is described here in point 3 : [Submitting your changes via a pull request](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#submitting-your-changes-via-a-pull-request)
    
    Alternatively, if you think the bug summary can be re-written using a better statement then you could do so in JBS and then use the updated summary in PR title.
    
    -------------
    
    Marked as reviewed by arapte (Reviewer).
    
    PR: https://git.openjdk.org/jfx/pull/918
    
    From kcr at openjdk.org  Wed Oct 19 15:00:55 2022
    From: kcr at openjdk.org (Kevin Rushforth)
    Date: Wed, 19 Oct 2022 15:00:55 GMT
    Subject: RFR: 8278426: ImagePool uses terminally deprecated
     System.runFinalization method
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Mon, 17 Oct 2022 14:02:52 GMT, Lukasz Kostyra  wrote:
    
    > This change removes runFinalization calls in ImagePool::pruneCache method.
    > 
    > Finalizers are deprecated in JDK 18 and will be removed soon.
    
    Can you enable GitHub actions testing for your repo? See this comment:
    
    https://github.com/openjdk/jfx/pull/918/checks?check_run_id=8936136932
    
    Once you do, you should be able to manually trigger a GHA run (it will be automatically triggered on future pushes to your branches).
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/918
    
    From duke at openjdk.org  Wed Oct 19 15:00:55 2022
    From: duke at openjdk.org (Lukasz Kostyra)
    Date: Wed, 19 Oct 2022 15:00:55 GMT
    Subject: RFR: 8278426: ImagePool uses terminally deprecated
     System.runFinalization method
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Mon, 17 Oct 2022 14:02:52 GMT, Lukasz Kostyra  wrote:
    
    > This change removes runFinalization calls in ImagePool::pruneCache method.
    > 
    > Finalizers are deprecated in JDK 18 and will be removed soon.
    
    All done! Tests are in progress now.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/918
    
    From angorya at openjdk.org  Wed Oct 19 15:08:13 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 19 Oct 2022 15:08:13 GMT
    Subject: RFR: 8278426: ImagePool uses terminally deprecated
     System.runFinalization method
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Mon, 17 Oct 2022 14:02:52 GMT, Lukasz Kostyra  wrote:
    
    > This change removes runFinalization calls in ImagePool::pruneCache method.
    > 
    > Finalizers are deprecated in JDK 18 and will be removed soon.
    
    Marked as reviewed by angorya (Author).
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/918
    
    From jvos at openjdk.org  Wed Oct 19 15:23:55 2022
    From: jvos at openjdk.org (Johan Vos)
    Date: Wed, 19 Oct 2022 15:23:55 GMT
    Subject: [jfx17u] RFR: 8295660: Change JavaFX release version to 17.0.6 in
     jfx17u
    Message-ID: <1YYx_p7um75pf65lEPPknkj4lsnGyMtnjWqSid36SzI=.23fb8924-0d27-4852-801b-722e28941dea@github.com>
    
    Update JavaFX 17 release version to 17.0.6
    Fix for JDK-8295660
    
    -------------
    
    Commit messages:
     - Update JavaFX 17 release version to 17.0.6
    
    Changes: https://git.openjdk.org/jfx17u/pull/83/files
     Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=83&range=00
      Issue: https://bugs.openjdk.org/browse/JDK-8295660
      Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
      Patch: https://git.openjdk.org/jfx17u/pull/83.diff
      Fetch: git fetch https://git.openjdk.org/jfx17u pull/83/head:pull/83
    
    PR: https://git.openjdk.org/jfx17u/pull/83
    
    From jvos at openjdk.org  Wed Oct 19 15:27:01 2022
    From: jvos at openjdk.org (Johan Vos)
    Date: Wed, 19 Oct 2022 15:27:01 GMT
    Subject: [jfx11u] RFR: 8295659: Change JavaFX release version to 11.0.18 in
     jfx11u
    Message-ID: 
    
    update javaFX release version to 11.0.18
    Fix for JDK-8295659
    
    -------------
    
    Commit messages:
     - update javaFX release version to 11.0.18
    
    Changes: https://git.openjdk.org/jfx11u/pull/114/files
     Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=114&range=00
      Issue: https://bugs.openjdk.org/browse/JDK-8295659
      Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
      Patch: https://git.openjdk.org/jfx11u/pull/114.diff
      Fetch: git fetch https://git.openjdk.org/jfx11u pull/114/head:pull/114
    
    PR: https://git.openjdk.org/jfx11u/pull/114
    
    From angorya at openjdk.org  Wed Oct 19 15:40:42 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 19 Oct 2022 15:40:42 GMT
    Subject: RFR: 8294809: ListenerHelper for managing and disconnecting
     listeners [v3]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > Introduction
    > 
    > There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class).
    > 
    > This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance
    > https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java
    > 
    > Proposal
    > 
    > It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which:
    > 
    > - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc.
    > - keeps track of the listeners and the corresponding ObservableValues
    > - provides a single disconnect() method to remove all the listeners in one go.
    > - optionally, it should be possible to add a lambda (Runnable) to a group of properties
    > - optionally, there should be a boolean flag to fire the lambda immediately
    > - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method
    > 
    > Make it Public Later
    > 
    > Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later.
    > 
    > Where It Will Be Useful
    > 
    > [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin"
    > and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler.
    > 
    > https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft
    > 
    > https://github.com/openjdk/jfx/pull/914
    
    Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
    
      Revert "8294809: removed weak listeners support"
      
      This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18.
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/908/files
      - new: https://git.openjdk.org/jfx/pull/908/files/2df4a85d..c518cbf9
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=02
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=01-02
    
      Stats: 644 lines in 2 files changed: 643 ins; 1 del; 0 mod
      Patch: https://git.openjdk.org/jfx/pull/908.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/908/head:pull/908
    
    PR: https://git.openjdk.org/jfx/pull/908
    
    From angorya at openjdk.org  Wed Oct 19 15:40:45 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 19 Oct 2022 15:40:45 GMT
    Subject: RFR: 8294809: ListenerHelper for managing and disconnecting
     listeners [v2]
    In-Reply-To: 
    References: 
     
    Message-ID: 
    
    On Fri, 14 Oct 2022 19:11:08 GMT, Andy Goryachev  wrote:
    
    >> Introduction
    >> 
    >> There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class).
    >> 
    >> This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance
    >> https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java
    >> 
    >> Proposal
    >> 
    >> It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which:
    >> 
    >> - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc.
    >> - keeps track of the listeners and the corresponding ObservableValues
    >> - provides a single disconnect() method to remove all the listeners in one go.
    >> - optionally, it should be possible to add a lambda (Runnable) to a group of properties
    >> - optionally, there should be a boolean flag to fire the lambda immediately
    >> - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method
    >> 
    >> Make it Public Later
    >> 
    >> Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later.
    >> 
    >> Where It Will Be Useful
    >> 
    >> [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin"
    >> and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler.
    >> 
    >> https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft
    >> 
    >> https://github.com/openjdk/jfx/pull/914
    >
    > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   8294809: removed weak listeners support
    
    Support for weak listeners cannot be removed, for example in a situation when Control gets removed from the scene graph and therefore becomes eligible for collection.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/908
    
    From angorya at openjdk.org  Wed Oct 19 15:49:17 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 19 Oct 2022 15:49:17 GMT
    Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v8]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose().
    > 
    > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler.
    > See https://github.com/openjdk/jfx/pull/908
    
    Andy Goryachev has updated the pull request incrementally with three additional commits since the last revision:
    
     - Merge branch '8294809.listener.helper' into 8294589.menubarskin.leak
     - Revert "8294809: removed weak listeners support"
       
       This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18.
     - Revert "8294589: removed weak listeners"
       
       This reverts commit 2ea27fc912178cf2f22155794e047f20950d0d7d.
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/906/files
      - new: https://git.openjdk.org/jfx/pull/906/files/2ea27fc9..92418aaf
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=07
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=06-07
    
      Stats: 649 lines in 3 files changed: 643 ins; 1 del; 5 mod
      Patch: https://git.openjdk.org/jfx/pull/906.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906
    
    PR: https://git.openjdk.org/jfx/pull/906
    
    From nlisker at openjdk.org  Wed Oct 19 20:18:03 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Wed, 19 Oct 2022 20:18:03 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
     <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
     
     
     
     
     
     <4qaP2ODitUQ99yAAef-F-6edSEJ29yRDx8Jiw5I9ce4=.eee98893-f18d-4470-8ddd-63f4c25fbb73@github.com>
     
    Message-ID: 
    
    On Tue, 18 Oct 2022 18:44:58 GMT, Andy Goryachev  wrote:
    
    >>> I'd respectfully disagree: in a large application, there might be hundreds (a thousand?) Nodes, and only a handful (10-20?) Nodes with this property (2%), so it's a waste of RAM. One may think it's only 8Kb on a 64 bit machine, but it does add up quickly. Even the access pattern is basically 'get it once to establish the fluent pipeline', with no more calls to the Node accessor (unlike MiscProperties constituents, some of which get accessed rather frequently).
    >> 
    >> I understand your point, but I don't think that this is sufficient reason to introduce a new way of storing property instances in an ad-hoc manner. If memory consumption is a concern, I would rather analyze the issue in a separate enhancement proposal, think it through in terms of API, and then transition all relevant property instances to the new storage mechanism. Part of that proposal should also be an evaluation of the trade-offs between memory consumption and performance in terms of cache locality and lookup speed.
    >
    > @mstr2 : 
    > `getProperties()` is a perfectly fine way of storing a property instance, especially considering the fact that this property will be called exactly once - during the fluent pipeline setup.  Of course, it does not apply to other properties that are being called all the time.
    > 
    > See ButtonBarSkin:136
    > 
    > A separate ticket for optimizing property storage might be a good idea, I agree.
    
    > > `getProperties()` isn't the place for this.
    > 
    > can you explain why?
    
    This map is used for storing values for the node. As the API note says, layout managers use this to store constraints that be updated by the user. I think that this is already not the best way to do it. The user can also store arbitrary data like markers or other associations. Storing a `Property` is like storing functionality, not data.
    
    In addition, the map is publicly accessible, so the user can clear it. In this case you risk GC of the instance. This is equivalent to making a property field both `public` and not `final`, allowing the user to overwrite the reference - a rather disastrous scenario.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Wed Oct 19 20:41:58 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 19 Oct 2022 20:41:58 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
    Message-ID: 
    
    On Thu, 29 Sep 2022 15:02:13 GMT, John Hendrikx  wrote:
    
    >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`.
    >> 
    >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here).
    >> 
    >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property:
    >> 
    >>      label.textProperty().bind(longLivedProperty.when(label::isShowingProperty));
    >> 
    >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing.  When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`.  A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along.
    >> 
    >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR.
    >> 
    >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out.
    >> 
    >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window.
    >
    > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
    > 
    >  - Merge remote-tracking branch 'origin/master' into
    >    feature/conditional-bindings
    >    
    >    # Conflicts:
    >    #	modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java
    >  - Fix review comments
    >  - Add missing new line
    >  - Small wording fixes
    >  - Update javadoc of "when" with better phrasing
    >  - Rename showing property to shown as it is already used in subclasses
    >  - Add conditional bindings to ObservableValue
    >  - Change explanatory comment to block comment
    >  - Fix bug where ObjectBinding returns null when revalidated immediately
    >    
    >    Introduced with the fluent bindings PR
    
    Changes requested by angorya (Author).
    
    Poll: would you rather name the method `when` or `onCondition` ?
    
    modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1442:
    
    > 1440: 
    > 1441:     // Candidate to make publicly available or to add as a convience method to ObservableValue
    > 1442:     private static class ReadOnlyBooleanDelegate extends ReadOnlyBooleanProperty {
    
    should this class be moved elsewhere?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From nlisker at openjdk.org  Wed Oct 19 20:41:59 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Wed, 19 Oct 2022 20:41:59 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     
     
     
     
     
    Message-ID: 
    
    On Fri, 14 Oct 2022 16:19:02 GMT, Andy Goryachev  wrote:
    
    >> Changing the documentation for `When` should not be part of this PR I think. What we should do maybe is add a note that this method should not be confused with `Bindings.when`. I'll let others weigh in.
    >
    > I like `conditionOn`.
    
    I actually like `asLongAs` that was mentioned in another comment, but it looks odd :)
    
    Lately, as I was reading some unrelated codebases and I came up with `updateWhile` (or `updateWhen`). The reason is that names like `when` and `conditionOn`, and even the restricted `if` and `while`, tell me just half the story. They tell me what happens "when", but not what happens "when not". The `bindings.When` binding is phrased as "`when` condition `then` A, `otherwise` B", which is I think it great. This binding is phrased as "`when` condition", but then what and what otherwise?
    
    Because the binding updates its value when/while/as long as the condition holds and *doesn't update when the condition doesn't hold* (it just stays the same), I think that the phrasing "`update while` condition" (and don't update while not condition) gives a better description of the functionality.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Wed Oct 19 20:41:59 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 19 Oct 2022 20:41:59 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
     <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
     
     
     
     
     
     <4qaP2ODitUQ99yAAef-F-6edSEJ29yRDx8Jiw5I9ce4=.eee98893-f18d-4470-8ddd-63f4c25fbb73@github.com>
     
     
    Message-ID: <2P0ExaB_pX5lfgPySlj6i_f3fc0yIxYAcf8gMRfAweU=.0cd29c2c-7687-4079-bf5a-207d4d05f4b0@github.com>
    
    On Wed, 19 Oct 2022 20:14:18 GMT, Nir Lisker  wrote:
    
    >> @mstr2 : 
    >> `getProperties()` is a perfectly fine way of storing a property instance, especially considering the fact that this property will be called exactly once - during the fluent pipeline setup.  Of course, it does not apply to other properties that are being called all the time.
    >> 
    >> See ButtonBarSkin:136
    >> 
    >> A separate ticket for optimizing property storage might be a good idea, I agree.
    >
    >> > `getProperties()` isn't the place for this.
    >> 
    >> can you explain why?
    > 
    > This map is used for storing values for the node. As the API note says, layout managers use this to store constraints that be updated by the user. I think that this is already not the best way to do it. The user can also store arbitrary data like markers or other associations. Storing a `Property` is like storing functionality, not data.
    > 
    > In addition, the map is publicly accessible, so the user can clear it. In this case you risk GC of the instance. This is equivalent to making a property field both `public` and not `final`, allowing the user to overwrite the reference - a rather disastrous scenario.
    
    Thank you.  You do bring a good point - clearing the map.  There is some mild language warning about clearing the map in javadoc already, but perhaps `Node.getProperties().clear()` should be forbidden (throw an IOE?).  
    
    Also, the devs risk unexpected side effects if they try to use Strings as keys, due to possible collision with keys used by FX internals.
    
    And, of course, the API does not preclude storing properties in `getProperties()`, and FX is already doing it, as illustrated by ButtonBarSkin:136 (perhaps more, I did not perform an exhaustive check).
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Wed Oct 19 20:49:15 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 19 Oct 2022 20:49:15 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     
     
     
     
     
     
    Message-ID: 
    
    On Wed, 19 Oct 2022 20:37:46 GMT, Nir Lisker  wrote:
    
    >> I like `conditionOn`.
    >
    > I actually like `asLongAs` that was mentioned in another comment, but it looks odd :)
    > 
    > Lately, as I was reading some unrelated codebases and I came up with `updateWhile` (or `updateWhen`). The reason is that names like `when` and `conditionOn`, and even the restricted `if` and `while`, tell me just half the story. They tell me what happens "when", but not what happens "when not". The `bindings.When` binding is phrased as "`when` condition `then` A, `otherwise` B", which is I think it great. This binding is phrased as "`when` condition", but then what and what otherwise?
    > 
    > Because the binding updates its value when/while/as long as the condition holds and *doesn't update when the condition doesn't hold* (it just stays the same), I think that the phrasing "`update while` condition" (and don't update while not condition) gives a better description of the functionality.
    
    Does `asLongAs` imply recurrent nature?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From nlisker at openjdk.org  Wed Oct 19 21:00:12 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Wed, 19 Oct 2022 21:00:12 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     
     
     
     
     
     
     
    Message-ID: 
    
    On Wed, 19 Oct 2022 20:45:41 GMT, Andy Goryachev  wrote:
    
    >> I actually like `asLongAs` that was mentioned in another comment, but it looks odd :)
    >> 
    >> Lately, as I was reading some unrelated codebases and I came up with `updateWhile` (or `updateWhen`). The reason is that names like `when` and `conditionOn`, and even the restricted `if` and `while`, tell me just half the story. They tell me what happens "when", but not what happens "when not". The `bindings.When` binding is phrased as "`when` condition `then` A, `otherwise` B", which is I think it great. This binding is phrased as "`when` condition", but then what and what otherwise?
    >> 
    >> Because the binding updates its value when/while/as long as the condition holds and *doesn't update when the condition doesn't hold* (it just stays the same), I think that the phrasing "`update while` condition" (and don't update while not condition) gives a better description of the functionality.
    >
    > Does `asLongAs` imply recurrent nature?
    
    I don't see why not.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Wed Oct 19 21:11:47 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 19 Oct 2022 21:11:47 GMT
    Subject: RFR: 8294809: ListenerHelper for managing and disconnecting
     listeners [v4]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > Introduction
    > 
    > There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class).
    > 
    > This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance
    > https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java
    > 
    > Proposal
    > 
    > It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which:
    > 
    > - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc.
    > - keeps track of the listeners and the corresponding ObservableValues
    > - provides a single disconnect() method to remove all the listeners in one go.
    > - optionally, it should be possible to add a lambda (Runnable) to a group of properties
    > - optionally, there should be a boolean flag to fire the lambda immediately
    > - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method
    > 
    > Make it Public Later
    > 
    > Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later.
    > 
    > Where It Will Be Useful
    > 
    > [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin"
    > and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler.
    > 
    > https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft
    > 
    > https://github.com/openjdk/jfx/pull/914
    
    Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
    
      8294809: is alive
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/908/files
      - new: https://git.openjdk.org/jfx/pull/908/files/c518cbf9..e36d3289
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=03
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=02-03
    
      Stats: 708 lines in 2 files changed: 54 ins; 595 del; 59 mod
      Patch: https://git.openjdk.org/jfx/pull/908.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/908/head:pull/908
    
    PR: https://git.openjdk.org/jfx/pull/908
    
    From angorya at openjdk.org  Wed Oct 19 21:18:06 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 19 Oct 2022 21:18:06 GMT
    Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v9]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose().
    > 
    > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler.
    > See https://github.com/openjdk/jfx/pull/908
    
    Andy Goryachev has updated the pull request incrementally with three additional commits since the last revision:
    
     - 8294589: owner
     - Merge branch '8294809.listener.helper' into 8294589.menubarskin.leak
     - 8294809: is alive
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/906/files
      - new: https://git.openjdk.org/jfx/pull/906/files/92418aaf..1adc2a93
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=08
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=07-08
    
      Stats: 714 lines in 3 files changed: 54 ins; 595 del; 65 mod
      Patch: https://git.openjdk.org/jfx/pull/906.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906
    
    PR: https://git.openjdk.org/jfx/pull/906
    
    From angorya at openjdk.org  Wed Oct 19 22:12:27 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 19 Oct 2022 22:12:27 GMT
    Subject: RFR: 8294809: ListenerHelper for managing and disconnecting
     listeners [v5]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > Introduction
    > 
    > There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class).
    > 
    > This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance
    > https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java
    > 
    > Proposal
    > 
    > It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which:
    > 
    > - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc.
    > - keeps track of the listeners and the corresponding ObservableValues
    > - provides a single disconnect() method to remove all the listeners in one go.
    > - optionally, it should be possible to add a lambda (Runnable) to a group of properties
    > - optionally, there should be a boolean flag to fire the lambda immediately
    > - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method
    > 
    > Make it Public Later
    > 
    > Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later.
    > 
    > Where It Will Be Useful
    > 
    > [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin"
    > and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler.
    > 
    > https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft
    > 
    > https://github.com/openjdk/jfx/pull/914
    
    Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
    
      8294809: generics
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/908/files
      - new: https://git.openjdk.org/jfx/pull/908/files/e36d3289..71ca35ee
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=04
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=03-04
    
      Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
      Patch: https://git.openjdk.org/jfx/pull/908.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/908/head:pull/908
    
    PR: https://git.openjdk.org/jfx/pull/908
    
    From angorya at openjdk.org  Wed Oct 19 22:18:46 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Wed, 19 Oct 2022 22:18:46 GMT
    Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v10]
    In-Reply-To: 
    References: 
    Message-ID: <_tfYmK22AOUVrka5pcbZs3zLWNxnOwjI7z5fX4aWi2c=.60e63d1e-1686-49d5-91ac-30b8f6bdefc5@github.com>
    
    > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose().
    > 
    > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler.
    > See https://github.com/openjdk/jfx/pull/908
    
    Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
    
     - Merge branch '8294809.listener.helper' into 8294589.menubarskin.leak
     - 8294809: generics
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/906/files
      - new: https://git.openjdk.org/jfx/pull/906/files/1adc2a93..bc3869ac
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=09
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=08-09
    
      Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
      Patch: https://git.openjdk.org/jfx/pull/906.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906
    
    PR: https://git.openjdk.org/jfx/pull/906
    
    From mstrauss at openjdk.org  Wed Oct 19 22:24:00 2022
    From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
    Date: Wed, 19 Oct 2022 22:24:00 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: <2P0ExaB_pX5lfgPySlj6i_f3fc0yIxYAcf8gMRfAweU=.0cd29c2c-7687-4079-bf5a-207d4d05f4b0@github.com>
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
     <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
     
     
     
     
     
     <4qaP2ODitUQ99yAAef-F-6edSEJ29yRDx8Jiw5I9ce4=.eee98893-f18d-4470-8ddd-63f4c25fbb73@github.com>
     
     
     <2P0ExaB_pX5lfgPySlj6i_f3fc0yIxYAcf8gMRfAweU=.0cd29c2c-7687-4079-bf5a-207d4d05f4b0@github.com>
    Message-ID: <_fi-BrwjWfj-FkbfmYHHEmuSv0M6CJ-K0BjY9qCdGGc=.f1741b60-c1d2-4c0b-840a-b76484fe206a@github.com>
    
    On Wed, 19 Oct 2022 20:37:34 GMT, Andy Goryachev  wrote:
    
    > Thank you. You do bring a good point - clearing the map. There is some mild language warning about clearing the map in javadoc already, but perhaps `Node.getProperties().clear()` should be forbidden (throw an IOE?).
    
    A map can also be cleared with `Map.keySet().clear()`, or by enumerating its keys and removing each mapping one by one.
    I don't think we can make the `getProperties()` map mutable, but at the same time safe to store final objects, while still respecting the `Map` contract.
    
    Maybe we could have something like "hidden" keys, which are not enumerable and are never cleared by bulk operations.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From kcr at openjdk.org  Thu Oct 20 01:26:10 2022
    From: kcr at openjdk.org (Kevin Rushforth)
    Date: Thu, 20 Oct 2022 01:26:10 GMT
    Subject: [jfx11u] RFR: 8295659: Change JavaFX release version to 11.0.18 in
     jfx11u
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Wed, 19 Oct 2022 15:02:42 GMT, Johan Vos  wrote:
    
    > update javaFX release version to 11.0.18
    > Fix for JDK-8295659
    
    Marked as reviewed by kcr (Lead).
    
    -------------
    
    PR: https://git.openjdk.org/jfx11u/pull/114
    
    From kcr at openjdk.org  Thu Oct 20 01:26:11 2022
    From: kcr at openjdk.org (Kevin Rushforth)
    Date: Thu, 20 Oct 2022 01:26:11 GMT
    Subject: [jfx17u] RFR: 8295660: Change JavaFX release version to 17.0.6 in
     jfx17u
    In-Reply-To: <1YYx_p7um75pf65lEPPknkj4lsnGyMtnjWqSid36SzI=.23fb8924-0d27-4852-801b-722e28941dea@github.com>
    References: <1YYx_p7um75pf65lEPPknkj4lsnGyMtnjWqSid36SzI=.23fb8924-0d27-4852-801b-722e28941dea@github.com>
    Message-ID: 
    
    On Wed, 19 Oct 2022 14:55:40 GMT, Johan Vos  wrote:
    
    > Update JavaFX 17 release version to 17.0.6
    > Fix for JDK-8295660
    
    Marked as reviewed by kcr (Lead).
    
    -------------
    
    PR: https://git.openjdk.org/jfx17u/pull/83
    
    From duke at openjdk.org  Thu Oct 20 06:23:01 2022
    From: duke at openjdk.org (Lukasz Kostyra)
    Date: Thu, 20 Oct 2022 06:23:01 GMT
    Subject: Integrated: 8278426: ImagePool uses terminally deprecated
     System.runFinalization method
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Mon, 17 Oct 2022 14:02:52 GMT, Lukasz Kostyra  wrote:
    
    > This change removes runFinalization calls in ImagePool::pruneCache method.
    > 
    > Finalizers are deprecated in JDK 18 and will be removed soon.
    
    This pull request has now been integrated.
    
    Changeset: 91e1a278
    Author:    Lukasz Kostyra 
    Committer: Ambarish Rapte 
    URL:       https://git.openjdk.org/jfx/commit/91e1a278ac0087d7fa767342824023488e652761
    Stats:     4 lines in 1 file changed: 0 ins; 3 del; 1 mod
    
    8278426: ImagePool uses terminally deprecated System.runFinalization method
    
    Reviewed-by: arapte, angorya
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/918
    
    From thomas.reinhardt at s4p.de  Thu Oct 20 06:42:04 2022
    From: thomas.reinhardt at s4p.de (Thomas Reinhardt)
    Date: Thu, 20 Oct 2022 08:42:04 +0200
    Subject: Platform independent deployment
    Message-ID: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
    
    
    Hi!
    
    Apologizes if this is not the proper list to ask my question.
    
    For context: we are using the WebView of JavaFX in our legacy swing 
    based frontend application. For now that is the only component we are 
    using but we might migrate completely at a later point in time.
    
    I have an issue with the way platform dependent dependencies are 
    handled. We are using maven btw.
    My understanding is that during the build a profile is selected based on 
    the host os name and architecture. That profile then sets a property 
    (javafx.platform) that is in turn used as the classifier for platform 
    dependent dependencies.
    (Offtopic to my question: eclipse warns that the profile ids are not 
    unique in the org.openjfx:javafx pom.xml).
    
    Which means that the result of my build is locked to a single platform. 
    But we have customers for windows and linux and don't want to have 
    separate artifacts as that would mean we also have to handle that 
    distinction in our installer etc.
    
    I know I can override the automatically detected platform but that does 
    not solve the issue.
    
    Ideally I would use something like -Djavafx.platform=all but that does 
    not exist.
    
    My question is: is there an existing solution where I can just include 
    all platform dependencies for say windows and linux and the runtime 
    "sorts it out"? A naive test (manual copying of artifacts) of mine 
    unfortunately failed. Of course I could just use custom classloaders and 
    do it myself but I really would prefer to use an existing solution and 
    not implement some workaround.
    
    If there is no solution (yet), is there interest in such a feature? We 
    might be able to contribute to the project.
    
    
    -Thomas
    
    From jvos at openjdk.org  Thu Oct 20 06:51:29 2022
    From: jvos at openjdk.org (Johan Vos)
    Date: Thu, 20 Oct 2022 06:51:29 GMT
    Subject: [jfx11u] Integrated: 8295659: Change JavaFX release version to 11.0.18
     in jfx11u
    In-Reply-To: 
    References: 
    Message-ID: <1RUsiisY7dULGnB1xxrR-XcK24hQkwq68BmApkdCDJs=.17398fa9-e556-4689-8e44-bfcd663273c3@github.com>
    
    On Wed, 19 Oct 2022 15:02:42 GMT, Johan Vos  wrote:
    
    > update javaFX release version to 11.0.18
    > Fix for JDK-8295659
    
    This pull request has now been integrated.
    
    Changeset: 8e1d7fe0
    Author:    Johan Vos 
    URL:       https://git.openjdk.org/jfx11u/commit/8e1d7fe0f96999db95deb82c4575131338b2bfd4
    Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod
    
    8295659: Change JavaFX release version to 11.0.18 in jfx11u
    
    Reviewed-by: kcr
    
    -------------
    
    PR: https://git.openjdk.org/jfx11u/pull/114
    
    From jvos at openjdk.org  Thu Oct 20 06:53:05 2022
    From: jvos at openjdk.org (Johan Vos)
    Date: Thu, 20 Oct 2022 06:53:05 GMT
    Subject: [jfx17u] Integrated: 8295660: Change JavaFX release version to 17.0.6
     in jfx17u
    In-Reply-To: <1YYx_p7um75pf65lEPPknkj4lsnGyMtnjWqSid36SzI=.23fb8924-0d27-4852-801b-722e28941dea@github.com>
    References: <1YYx_p7um75pf65lEPPknkj4lsnGyMtnjWqSid36SzI=.23fb8924-0d27-4852-801b-722e28941dea@github.com>
    Message-ID: <0bgA0DBwhHJI0PgAilJGLnlwDq4NrWLwJlupN9_Q1O0=.8f2fd50e-d501-4ee7-9e06-c66d0893376b@github.com>
    
    On Wed, 19 Oct 2022 14:55:40 GMT, Johan Vos  wrote:
    
    > Update JavaFX 17 release version to 17.0.6
    > Fix for JDK-8295660
    
    This pull request has now been integrated.
    
    Changeset: 32fd4dec
    Author:    Johan Vos 
    URL:       https://git.openjdk.org/jfx17u/commit/32fd4dec86dc8862fd1b4ba03d75a34dbf4d7494
    Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod
    
    8295660: Change JavaFX release version to 17.0.6 in jfx17u
    
    Reviewed-by: kcr
    
    -------------
    
    PR: https://git.openjdk.org/jfx17u/pull/83
    
    From arapte at openjdk.org  Thu Oct 20 11:39:34 2022
    From: arapte at openjdk.org (Ambarish Rapte)
    Date: Thu, 20 Oct 2022 11:39:34 GMT
    Subject: RFR: 8295725: Update copyright header for files modified in 2022
    Message-ID: <0OHEkg2vF_59IVVtBi1qXlsu7pgeyuCnnMFLsIsjQ08=.b9425169-5097-45a1-a5f1-d2fbf147938a@github.com>
    
    Updating last modified year in copyright header of the files that were modified during year 2022.
    
    -------------
    
    Commit messages:
     - copyright header year update
    
    Changes: https://git.openjdk.org/jfx/pull/923/files
     Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=923&range=00
      Issue: https://bugs.openjdk.org/browse/JDK-8295725
      Stats: 84 lines in 84 files changed: 0 ins; 0 del; 84 mod
      Patch: https://git.openjdk.org/jfx/pull/923.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/923/head:pull/923
    
    PR: https://git.openjdk.org/jfx/pull/923
    
    From jvos at openjdk.org  Thu Oct 20 14:44:39 2022
    From: jvos at openjdk.org (Johan Vos)
    Date: Thu, 20 Oct 2022 14:44:39 GMT
    Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using
     multiple hidpi monitors
    Message-ID: 
    
    The root problem is actually broader than stated in the JBS issue. This PR now translates screencoordinates from absolute coordinates into coordinates that take the platformScale into account. 
    The whole process is complicated by the fact that throughout our code, we use e.g. `x` and `y` without clearly stating if those are absolute, logical, screen or rendering coordinates. 
    I believe the most consistent approach is to have the different entry points (e.g. a Glass Window or a JFXPanel) to deal with platformScale before passing screen coordinates. This is already done in the Glass approach, and this PR does the same in JFXPanel. That means some code is duplicated, but since this is only about 12 lines, and said code lives in 2 different modules, I think it's not worth the hassle of moving that into e.g. the base module.
    
    -------------
    
    Commit messages:
     - Transform coordinates using platform scale if needed when bridging from
    
    Changes: https://git.openjdk.org/jfx/pull/924/files
     Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=924&range=00
      Issue: https://bugs.openjdk.org/browse/JDK-8222210
      Stats: 50 lines in 2 files changed: 45 ins; 0 del; 5 mod
      Patch: https://git.openjdk.org/jfx/pull/924.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/924/head:pull/924
    
    PR: https://git.openjdk.org/jfx/pull/924
    
    From angorya at openjdk.org  Thu Oct 20 15:31:00 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Thu, 20 Oct 2022 15:31:00 GMT
    Subject: RFR: 8295725: Update copyright header for files modified in 2022
    In-Reply-To: <0OHEkg2vF_59IVVtBi1qXlsu7pgeyuCnnMFLsIsjQ08=.b9425169-5097-45a1-a5f1-d2fbf147938a@github.com>
    References: <0OHEkg2vF_59IVVtBi1qXlsu7pgeyuCnnMFLsIsjQ08=.b9425169-5097-45a1-a5f1-d2fbf147938a@github.com>
    Message-ID: 
    
    On Thu, 20 Oct 2022 11:31:43 GMT, Ambarish Rapte  wrote:
    
    > Updating last modified year in copyright header of the files that were modified during year 2022.
    
    Marked as reviewed by angorya (Author).
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/923
    
    From nlisker at gmail.com  Thu Oct 20 15:52:40 2022
    From: nlisker at gmail.com (Nir Lisker)
    Date: Thu, 20 Oct 2022 18:52:40 +0300
    Subject: Platform independent deployment
    In-Reply-To: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
    Message-ID: 
    
    Hi Thomas,
    
    Did you try to just specify the platform-specific dependencies in the POM?
    
        
            org.openjfx
            javafx-graphics
            19
            win
        
        
            org.openjfx
            javafx-graphics
            19
            linux
        
        
            org.openjfx
            javafx-graphics
            19
            mac
        
    
    Seems more of a question for help forums, though if this information is not
    mentioned in https://openjfx.io/openjfx-docs/#introduction, it might be
    worth adding it.
    
    On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt 
    wrote:
    
    >
    > Hi!
    >
    > Apologizes if this is not the proper list to ask my question.
    >
    > For context: we are using the WebView of JavaFX in our legacy swing
    > based frontend application. For now that is the only component we are
    > using but we might migrate completely at a later point in time.
    >
    > I have an issue with the way platform dependent dependencies are
    > handled. We are using maven btw.
    > My understanding is that during the build a profile is selected based on
    > the host os name and architecture. That profile then sets a property
    > (javafx.platform) that is in turn used as the classifier for platform
    > dependent dependencies.
    > (Offtopic to my question: eclipse warns that the profile ids are not
    > unique in the org.openjfx:javafx pom.xml).
    >
    > Which means that the result of my build is locked to a single platform.
    > But we have customers for windows and linux and don't want to have
    > separate artifacts as that would mean we also have to handle that
    > distinction in our installer etc.
    >
    > I know I can override the automatically detected platform but that does
    > not solve the issue.
    >
    > Ideally I would use something like -Djavafx.platform=all but that does
    > not exist.
    >
    > My question is: is there an existing solution where I can just include
    > all platform dependencies for say windows and linux and the runtime
    > "sorts it out"? A naive test (manual copying of artifacts) of mine
    > unfortunately failed. Of course I could just use custom classloaders and
    > do it myself but I really would prefer to use an existing solution and
    > not implement some workaround.
    >
    > If there is no solution (yet), is there interest in such a feature? We
    > might be able to contribute to the project.
    >
    >
    > -Thomas
    >
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From angorya at openjdk.org  Thu Oct 20 16:11:04 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Thu, 20 Oct 2022 16:11:04 GMT
    Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using
     multiple hidpi monitors
    In-Reply-To: 
    References: 
    Message-ID: <6E9g4Pg7kY2-APS31PUXCrxPS9da9_8BHdmsyusd_vE=.55ea53e4-1f6c-47a5-bfae-0f0a01ef8395@github.com>
    
    On Thu, 20 Oct 2022 14:37:04 GMT, Johan Vos  wrote:
    
    > The root problem is actually broader than stated in the JBS issue. This PR now translates screencoordinates from absolute coordinates into coordinates that take the platformScale into account. 
    > The whole process is complicated by the fact that throughout our code, we use e.g. `x` and `y` without clearly stating if those are absolute, logical, screen or rendering coordinates. 
    > I believe the most consistent approach is to have the different entry points (e.g. a Glass Window or a JFXPanel) to deal with platformScale before passing screen coordinates. This is already done in the Glass approach, and this PR does the same in JFXPanel. That means some code is duplicated, but since this is only about 12 lines, and said code lives in 2 different modules, I think it's not worth the hassle of moving that into e.g. the base module.
    
    modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 375:
    
    > 373:         AffineTransform awtScales = graphicsConfiguration.getDefaultTransform();
    > 374:         for (Screen screen : Screen.getScreens()) {
    > 375:             if ((Math.abs(screen.getPlatformX() - awtBounds.getX() * awtScales.getScaleX()) < 0.001) &&
    
    minor: would it be better to create a standard method?
    
    isNearZero(double)?
    
    although the value of the constant might depend on a situation.
    
    modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 385:
    
    > 383:     }
    > 384: 
    > 385:     private Dimension2D getSwingToFxPixel(GraphicsConfiguration g, float wx, float wy) {
    
    minor: convertSwingToFxPixel() ?
    
    modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 451:
    
    > 449:         Dimension2D onScreen = getSwingToFxPixel(getGraphicsConfiguration(), e.getXOnScreen(), e.getYOnScreen());
    > 450:         int fxXOnScreen = (int) onScreen.getWidth();
    > 451:         int fxYOnScreen = (int) onScreen.getHeight();
    
    question: should it be (int) or Math.round()?
    also, coordinates can be negative - will it work then?
    
    modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 646:
    
    > 644:                 Dimension2D fxcoord = getSwingToFxPixel(getGraphicsConfiguration(), p.x, p.y);
    > 645:                 screenX = (int)fxcoord.getWidth();
    > 646:                 screenY = (int)fxcoord.getHeight();
    
    same question about negative coordinates.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/924
    
    From thomas.reinhardt at s4p.de  Thu Oct 20 17:03:03 2022
    From: thomas.reinhardt at s4p.de (Thomas Reinhardt)
    Date: Thu, 20 Oct 2022 19:03:03 +0200
    Subject: Platform independent deployment
    In-Reply-To: 
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
    Message-ID: <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
    
    
    Hi Nir,
    
    Does not work (I testet it) and it can not work (see below).
    
    Also, this is exactly what my naive test was (I did not use maven to 
    copy the artifacts, but the result obviously is the same).
    
    It can not work as the implementation classes have the same name and 
    thus the jre can not distinguish which one to load. For example both 
    javafx-web-18-win and javafx-web-18-linux define a class 
    "javafx.scene.web.WebEngine". From the jre's point of view they are the 
    same.
    
    What would be needed is
    
    Either: a class "javafx.scene.web.WebEngine" that is only a thin wrapper 
    to javafx.scene.web.linux.WebEngine.
    
    Or: a class that loads only one of the implementations during 
    application startup (technically it could load both implementations with 
    different classloaders, but lets not go there).
    
    There might be other solutions but I am not aware of any.
    
    
    I was looking for a help forum but did only find the #introduction link 
    you mentioned.
    
    
    	-Thomas
    
    
    
    On 20/10/2022 17:52, Nir Lisker wrote:
    > Hi Thomas,
    > 
    > Did you try to just specify the platform-specific dependencies in the POM?
    > 
    >  ? ? 
    >  ? ? ? ? org.openjfx
    >  ? ? ? ? javafx-graphics
    >  ? ? ? ? 19
    >  ? ? ? ? win
    >  ? ? 
    >  ? ? 
    >  ? ? ? ? org.openjfx
    >  ? ? ? ? javafx-graphics
    >  ? ? ? ? 19
    >  ? ? ? ? linux
    >  ? ? 
    >  ? ? 
    >  ? ? ? ? org.openjfx
    >  ? ? ? ? javafx-graphics
    >  ? ? ? ? 19
    >  ? ? ? ? mac
    >  ? ? 
    > 
    > Seems more of a question for help forums, though if this information is 
    > not mentioned in https://openjfx.io/openjfx-docs/#introduction 
    > , it might be worth 
    > adding it.
    > 
    > On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt 
    > > wrote:
    > 
    > 
    >     Hi!
    > 
    >     Apologizes if this is not the proper list to ask my question.
    > 
    >     For context: we are using the WebView of JavaFX in our legacy swing
    >     based frontend application. For now that is the only component we are
    >     using but we might migrate completely at a later point in time.
    > 
    >     I have an issue with the way platform dependent dependencies are
    >     handled. We are using maven btw.
    >     My understanding is that during the build a profile is selected
    >     based on
    >     the host os name and architecture. That profile then sets a property
    >     (javafx.platform) that is in turn used as the classifier for platform
    >     dependent dependencies.
    >     (Offtopic to my question: eclipse warns that the profile ids are not
    >     unique in the org.openjfx:javafx pom.xml).
    > 
    >     Which means that the result of my build is locked to a single platform.
    >     But we have customers for windows and linux and don't want to have
    >     separate artifacts as that would mean we also have to handle that
    >     distinction in our installer etc.
    > 
    >     I know I can override the automatically detected platform but that does
    >     not solve the issue.
    > 
    >     Ideally I would use something like -Djavafx.platform=all but that does
    >     not exist.
    > 
    >     My question is: is there an existing solution where I can just include
    >     all platform dependencies for say windows and linux and the runtime
    >     "sorts it out"? A naive test (manual copying of artifacts) of mine
    >     unfortunately failed. Of course I could just use custom classloaders
    >     and
    >     do it myself but I really would prefer to use an existing solution and
    >     not implement some workaround.
    > 
    >     If there is no solution (yet), is there interest in such a feature? We
    >     might be able to contribute to the project.
    > 
    > 
    >     -Thomas
    > 
    
    From tsayao at openjdk.org  Thu Oct 20 17:04:31 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Thu, 20 Oct 2022 17:04:31 GMT
    Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v5]
    In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    Message-ID: 
    
    > This cleans size and positioning code, reducing special cases, code complexity and size.
    > 
    > Changes:
    > 
    > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    > - frame extents are received in process_property_notify;
    > - window geometry, min/max size are centralized in update_window_constraints and uses  `XSetWMNormalHints` because it supports initial position;
    > - window_configure: Changes can be requested directly to the window manager with `XReconfigureWMWindow` - it's compatible with `windowChangesMask`, `windowChanges`;
    > - request_focus uses `_NET_ACTIVE_WINDOW` directly as it does not seem to have focus stealing problems.
    > 
    > I have left some debug print statements which will be removed when we finish testing.
    
    Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
    
      Remove debug statements
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/915/files
      - new: https://git.openjdk.org/jfx/pull/915/files/bfdb4ad7..990c2245
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=04
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=03-04
    
      Stats: 18 lines in 1 file changed: 0 ins; 18 del; 0 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From nlisker at gmail.com  Thu Oct 20 17:09:44 2022
    From: nlisker at gmail.com (Nir Lisker)
    Date: Thu, 20 Oct 2022 20:09:44 +0300
    Subject: Platform independent deployment
    In-Reply-To: <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
    Message-ID: 
    
    I use this in a gradle project I have and it works for me. All the
    OS-specific modules are packaged and I can run the app on all 3 desktop
    platforms.
    
    It seems that you are doing something more special. Maybe someone else has
    insights.
    
    On Thu, Oct 20, 2022 at 8:03 PM Thomas Reinhardt 
    wrote:
    
    >
    > Hi Nir,
    >
    > Does not work (I testet it) and it can not work (see below).
    >
    > Also, this is exactly what my naive test was (I did not use maven to
    > copy the artifacts, but the result obviously is the same).
    >
    > It can not work as the implementation classes have the same name and
    > thus the jre can not distinguish which one to load. For example both
    > javafx-web-18-win and javafx-web-18-linux define a class
    > "javafx.scene.web.WebEngine". From the jre's point of view they are the
    > same.
    >
    > What would be needed is
    >
    > Either: a class "javafx.scene.web.WebEngine" that is only a thin wrapper
    > to javafx.scene.web.linux.WebEngine.
    >
    > Or: a class that loads only one of the implementations during
    > application startup (technically it could load both implementations with
    > different classloaders, but lets not go there).
    >
    > There might be other solutions but I am not aware of any.
    >
    >
    > I was looking for a help forum but did only find the #introduction link
    > you mentioned.
    >
    >
    >         -Thomas
    >
    >
    >
    > On 20/10/2022 17:52, Nir Lisker wrote:
    > > Hi Thomas,
    > >
    > > Did you try to just specify the platform-specific dependencies in the
    > POM?
    > >
    > >      
    > >          org.openjfx
    > >          javafx-graphics
    > >          19
    > >          win
    > >      
    > >      
    > >          org.openjfx
    > >          javafx-graphics
    > >          19
    > >          linux
    > >      
    > >      
    > >          org.openjfx
    > >          javafx-graphics
    > >          19
    > >          mac
    > >      
    > >
    > > Seems more of a question for help forums, though if this information is
    > > not mentioned in https://openjfx.io/openjfx-docs/#introduction
    > > , it might be worth
    > > adding it.
    > >
    > > On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt
    > > > wrote:
    > >
    > >
    > >     Hi!
    > >
    > >     Apologizes if this is not the proper list to ask my question.
    > >
    > >     For context: we are using the WebView of JavaFX in our legacy swing
    > >     based frontend application. For now that is the only component we are
    > >     using but we might migrate completely at a later point in time.
    > >
    > >     I have an issue with the way platform dependent dependencies are
    > >     handled. We are using maven btw.
    > >     My understanding is that during the build a profile is selected
    > >     based on
    > >     the host os name and architecture. That profile then sets a property
    > >     (javafx.platform) that is in turn used as the classifier for platform
    > >     dependent dependencies.
    > >     (Offtopic to my question: eclipse warns that the profile ids are not
    > >     unique in the org.openjfx:javafx pom.xml).
    > >
    > >     Which means that the result of my build is locked to a single
    > platform.
    > >     But we have customers for windows and linux and don't want to have
    > >     separate artifacts as that would mean we also have to handle that
    > >     distinction in our installer etc.
    > >
    > >     I know I can override the automatically detected platform but that
    > does
    > >     not solve the issue.
    > >
    > >     Ideally I would use something like -Djavafx.platform=all but that
    > does
    > >     not exist.
    > >
    > >     My question is: is there an existing solution where I can just
    > include
    > >     all platform dependencies for say windows and linux and the runtime
    > >     "sorts it out"? A naive test (manual copying of artifacts) of mine
    > >     unfortunately failed. Of course I could just use custom classloaders
    > >     and
    > >     do it myself but I really would prefer to use an existing solution
    > and
    > >     not implement some workaround.
    > >
    > >     If there is no solution (yet), is there interest in such a feature?
    > We
    > >     might be able to contribute to the project.
    > >
    > >
    > >     -Thomas
    > >
    >
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From jvos at openjdk.org  Thu Oct 20 17:10:25 2022
    From: jvos at openjdk.org (Johan Vos)
    Date: Thu, 20 Oct 2022 17:10:25 GMT
    Subject: [jfx17u] RFR: 8291625: DialogPane without header nor headerText nor
     graphic node adds padding to the left of the content pane
    Message-ID: 
    
    clean backport of 8291625: DialogPane without header nor headerText nor graphic node adds padding to the left of the content pane
    
    Reviewed-by: aghaisas
    
    -------------
    
    Commit messages:
     - 8291625: DialogPane without header nor headerText nor graphic node adds padding to the left of the content pane
    
    Changes: https://git.openjdk.org/jfx17u/pull/84/files
     Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=84&range=00
      Issue: https://bugs.openjdk.org/browse/JDK-8291625
      Stats: 47 lines in 2 files changed: 40 ins; 3 del; 4 mod
      Patch: https://git.openjdk.org/jfx17u/pull/84.diff
      Fetch: git fetch https://git.openjdk.org/jfx17u pull/84/head:pull/84
    
    PR: https://git.openjdk.org/jfx17u/pull/84
    
    From andy.goryachev at oracle.com  Thu Oct 20 17:12:35 2022
    From: andy.goryachev at oracle.com (Andy Goryachev)
    Date: Thu, 20 Oct 2022 17:12:35 +0000
    Subject: Platform independent deployment
    In-Reply-To: <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
    Message-ID: 
    
    Thomas:
    
    if your installer can change the command line it uses to launch java, you could modify the classpath to point to a subdirectory or a set of platform-specific jars.  do you think this might work?
    
    -andy
    
    
    From: openjfx-dev  on behalf of Thomas Reinhardt 
    Date: Thursday, 2022/10/20 at 10:03
    To: openjfx-dev at openjdk.org 
    Subject: Re: Platform independent deployment
    
    Hi Nir,
    
    Does not work (I testet it) and it can not work (see below).
    
    Also, this is exactly what my naive test was (I did not use maven to
    copy the artifacts, but the result obviously is the same).
    
    It can not work as the implementation classes have the same name and
    thus the jre can not distinguish which one to load. For example both
    javafx-web-18-win and javafx-web-18-linux define a class
    "javafx.scene.web.WebEngine". From the jre's point of view they are the
    same.
    
    What would be needed is
    
    Either: a class "javafx.scene.web.WebEngine" that is only a thin wrapper
    to javafx.scene.web.linux.WebEngine.
    
    Or: a class that loads only one of the implementations during
    application startup (technically it could load both implementations with
    different classloaders, but lets not go there).
    
    There might be other solutions but I am not aware of any.
    
    
    I was looking for a help forum but did only find the #introduction link
    you mentioned.
    
    
            -Thomas
    
    
    
    On 20/10/2022 17:52, Nir Lisker wrote:
    > Hi Thomas,
    >
    > Did you try to just specify the platform-specific dependencies in the POM?
    >
    >      
    >          org.openjfx
    >          javafx-graphics
    >          19
    >          win
    >      
    >      
    >          org.openjfx
    >          javafx-graphics
    >          19
    >          linux
    >      
    >      
    >          org.openjfx
    >          javafx-graphics
    >          19
    >          mac
    >      
    >
    > Seems more of a question for help forums, though if this information is
    > not mentioned in https://openjfx.io/openjfx-docs/#introduction
    > , it might be worth
    > adding it.
    >
    > On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt
    > > wrote:
    >
    >
    >     Hi!
    >
    >     Apologizes if this is not the proper list to ask my question.
    >
    >     For context: we are using the WebView of JavaFX in our legacy swing
    >     based frontend application. For now that is the only component we are
    >     using but we might migrate completely at a later point in time.
    >
    >     I have an issue with the way platform dependent dependencies are
    >     handled. We are using maven btw.
    >     My understanding is that during the build a profile is selected
    >     based on
    >     the host os name and architecture. That profile then sets a property
    >     (javafx.platform) that is in turn used as the classifier for platform
    >     dependent dependencies.
    >     (Offtopic to my question: eclipse warns that the profile ids are not
    >     unique in the org.openjfx:javafx pom.xml).
    >
    >     Which means that the result of my build is locked to a single platform.
    >     But we have customers for windows and linux and don't want to have
    >     separate artifacts as that would mean we also have to handle that
    >     distinction in our installer etc.
    >
    >     I know I can override the automatically detected platform but that does
    >     not solve the issue.
    >
    >     Ideally I would use something like -Djavafx.platform=all but that does
    >     not exist.
    >
    >     My question is: is there an existing solution where I can just include
    >     all platform dependencies for say windows and linux and the runtime
    >     "sorts it out"? A naive test (manual copying of artifacts) of mine
    >     unfortunately failed. Of course I could just use custom classloaders
    >     and
    >     do it myself but I really would prefer to use an existing solution and
    >     not implement some workaround.
    >
    >     If there is no solution (yet), is there interest in such a feature? We
    >     might be able to contribute to the project.
    >
    >
    >     -Thomas
    >
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From tsayao at openjdk.org  Thu Oct 20 17:25:00 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Thu, 20 Oct 2022 17:25:00 GMT
    Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
     [v5]
    In-Reply-To: 
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
     
    Message-ID: 
    
    On Thu, 20 Oct 2022 17:04:31 GMT, Thiago Milczarek Sayao  wrote:
    
    >> This cleans size and positioning code, reducing special cases, code complexity and size.
    >> 
    >> Changes:
    >> 
    >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    >> - frame extents are received in process_property_notify;
    >> - window geometry, min/max size are centralized in update_window_constraints and uses  `XSetWMNormalHints` because it supports initial position;
    >> - window_configure: Changes can be requested directly to the window manager with `XReconfigureWMWindow` - it's compatible with `windowChangesMask`, `windowChanges`;
    >> - request_focus uses `_NET_ACTIVE_WINDOW` directly as it does not seem to have focus stealing problems.
    >> 
    >> I have left some debug print statements which will be removed when we finish testing.
    >
    > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   Remove debug statements
    
    Found a bug that sometimes windows pops up on wrong location, back to WIP.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From jvos at openjdk.org  Thu Oct 20 17:32:46 2022
    From: jvos at openjdk.org (Johan Vos)
    Date: Thu, 20 Oct 2022 17:32:46 GMT
    Subject: [jfx17u] RFR: 8284665: First selected item of a TreeItem multiple
     selection gets removed if new items are constantly added to the TreeTableView
    Message-ID: 
    
    clean backport of 8284665: First selected item of a TreeItem multiple selection gets removed if new items are constantly added to the TreeTableView
    
    Reviewed-by: aghaisas
    
    -------------
    
    Commit messages:
     - 8284665: First selected item of a TreeItem multiple selection gets removed if new items are constantly added to the TreeTableView
    
    Changes: https://git.openjdk.org/jfx17u/pull/85/files
     Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=85&range=00
      Issue: https://bugs.openjdk.org/browse/JDK-8284665
      Stats: 101 lines in 4 files changed: 99 ins; 0 del; 2 mod
      Patch: https://git.openjdk.org/jfx17u/pull/85.diff
      Fetch: git fetch https://git.openjdk.org/jfx17u pull/85/head:pull/85
    
    PR: https://git.openjdk.org/jfx17u/pull/85
    
    From jvos at openjdk.org  Thu Oct 20 17:42:24 2022
    From: jvos at openjdk.org (Johan Vos)
    Date: Thu, 20 Oct 2022 17:42:24 GMT
    Subject: [jfx17u] RFR: 8277785: ListView scrollTo jumps to wrong location when
     CellHeight is changed
    Message-ID: 
    
    clean backport of 8277785: ListView scrollTo jumps to wrong location when CellHeight is?changed
    
    Reviewed-by: kcr, fkirmaier, aghaisas
    
    -------------
    
    Commit messages:
     - 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed
    
    Changes: https://git.openjdk.org/jfx17u/pull/86/files
     Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=86&range=00
      Issue: https://bugs.openjdk.org/browse/JDK-8277785
      Stats: 372 lines in 4 files changed: 332 ins; 19 del; 21 mod
      Patch: https://git.openjdk.org/jfx17u/pull/86.diff
      Fetch: git fetch https://git.openjdk.org/jfx17u pull/86/head:pull/86
    
    PR: https://git.openjdk.org/jfx17u/pull/86
    
    From thomas.reinhardt at s4p.de  Thu Oct 20 18:04:35 2022
    From: thomas.reinhardt at s4p.de (Thomas Reinhardt)
    Date: Thu, 20 Oct 2022 18:04:35 +0000
    Subject: Platform independent deployment
    Message-ID: 
    
    
    Hi Andy,
    
    This is actually a good suggestion. There are compatibility issues with existing installations (end users could change the commandline/arguments). I will have to check.
    
            - Thomas
    
    
    Mit freundlichen Gr??en,
    
    Thomas Reinhardt
    
    Am 20.10.2022 19:12 schrieb Andy Goryachev :
    
    Thomas:
    
    
    
    if your installer can change the command line it uses to launch java, you could modify the classpath to point to a subdirectory or a set of platform-specific jars.  do you think this might work?
    
    
    
    -andy
    
    
    
    
    
    From: openjfx-dev  on behalf of Thomas Reinhardt 
    Date: Thursday, 2022/10/20 at 10:03
    To: openjfx-dev at openjdk.org 
    Subject: Re: Platform independent deployment
    
    Hi Nir,
    
    Does not work (I testet it) and it can not work (see below).
    
    Also, this is exactly what my naive test was (I did not use maven to
    copy the artifacts, but the result obviously is the same).
    
    It can not work as the implementation classes have the same name and
    thus the jre can not distinguish which one to load. For example both
    javafx-web-18-win and javafx-web-18-linux define a class
    "javafx.scene.web.WebEngine". From the jre's point of view they are the
    same.
    
    What would be needed is
    
    Either: a class "javafx.scene.web.WebEngine" that is only a thin wrapper
    to javafx.scene.web.linux.WebEngine.
    
    Or: a class that loads only one of the implementations during
    application startup (technically it could load both implementations with
    different classloaders, but lets not go there).
    
    There might be other solutions but I am not aware of any.
    
    
    I was looking for a help forum but did only find the #introduction link
    you mentioned.
    
    
            -Thomas
    
    
    
    On 20/10/2022 17:52, Nir Lisker wrote:
    > Hi Thomas,
    >
    > Did you try to just specify the platform-specific dependencies in the POM?
    >
    >      
    >          org.openjfx
    >          javafx-graphics
    >          19
    >          win
    >      
    >      
    >          org.openjfx
    >          javafx-graphics
    >          19
    >          linux
    >      
    >      
    >          org.openjfx
    >          javafx-graphics
    >          19
    >          mac
    >      
    >
    > Seems more of a question for help forums, though if this information is
    > not mentioned in https://openjfx.io/openjfx-docs/#introduction
    > , it might be worth
    > adding it.
    >
    > On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt
    > > wrote:
    >
    >
    >     Hi!
    >
    >     Apologizes if this is not the proper list to ask my question.
    >
    >     For context: we are using the WebView of JavaFX in our legacy swing
    >     based frontend application. For now that is the only component we are
    >     using but we might migrate completely at a later point in time.
    >
    >     I have an issue with the way platform dependent dependencies are
    >     handled. We are using maven btw.
    >     My understanding is that during the build a profile is selected
    >     based on
    >     the host os name and architecture. That profile then sets a property
    >     (javafx.platform) that is in turn used as the classifier for platform
    >     dependent dependencies.
    >     (Offtopic to my question: eclipse warns that the profile ids are not
    >     unique in the org.openjfx:javafx pom.xml).
    >
    >     Which means that the result of my build is locked to a single platform.
    >     But we have customers for windows and linux and don't want to have
    >     separate artifacts as that would mean we also have to handle that
    >     distinction in our installer etc.
    >
    >     I know I can override the automatically detected platform but that does
    >     not solve the issue.
    >
    >     Ideally I would use something like -Djavafx.platform=all but that does
    >     not exist.
    >
    >     My question is: is there an existing solution where I can just include
    >     all platform dependencies for say windows and linux and the runtime
    >     "sorts it out"? A naive test (manual copying of artifacts) of mine
    >     unfortunately failed. Of course I could just use custom classloaders
    >     and
    >     do it myself but I really would prefer to use an existing solution and
    >     not implement some workaround.
    >
    >     If there is no solution (yet), is there interest in such a feature? We
    >     might be able to contribute to the project.
    >
    >
    >     -Thomas
    >
    
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From angorya at openjdk.org  Thu Oct 20 19:07:47 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Thu, 20 Oct 2022 19:07:47 GMT
    Subject: RFR: 8290844: Add Skin.install() method [v13]
    In-Reply-To: 
    References: 
    Message-ID: <5U-nxVPjLCe3VKLCpvfI-Bjxmsl0PPH3UIDC9Hrv5nA=.91db11b7-8703-4526-a4c8-504ce3c013c5@github.com>
    
    > - added Skin.install()
    > - javadoc changes for Skinnable.setSkin(Skin)
    
    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 26 additional commits since the last revision:
    
     - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
     - 8290844: review comments
     - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
     - 8290844: javadoc
     - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
     - 8290844: javadoc
     - Merge branch 'openjdk:master' into 8290844.skin.install
     - 8290844: unit tests
     - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
     - 8290844: review comments
     - ... and 16 more: https://git.openjdk.org/jfx/compare/f2250911...4aaf422b
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/845/files
      - new: https://git.openjdk.org/jfx/pull/845/files/97ad66c0..4aaf422b
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=12
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=11-12
    
      Stats: 15 lines in 5 files changed: 5 ins; 3 del; 7 mod
      Patch: https://git.openjdk.org/jfx/pull/845.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845
    
    PR: https://git.openjdk.org/jfx/pull/845
    
    From john.hendrikx at gmail.com  Thu Oct 20 20:03:12 2022
    From: john.hendrikx at gmail.com (John Hendrikx)
    Date: Thu, 20 Oct 2022 22:03:12 +0200
    Subject: Platform independent deployment
    In-Reply-To: <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
    Message-ID: <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
    
    Correct me if I'm wrong, but all the classes in the artifacts for win, 
    linux and mac are actually exactly the same -- this is Java code after 
    all, why would all Java classes for a platform be platform specific?? It 
    doesn't matter which one is packaged.? The platform specific stuff lives 
    in the native libraries -- my shaded jar just includes all of them for 
    all platforms (dll for windows, so for linux, dylib for mac).? I'm 
    pretty sure I used this exact same jar to run my software on windows and 
    linux.? Never tested mac as I don't own one.
    
    My pom therefore includes all three, like Nir Lisker has, and my shaded 
    artifact just packages them all (I get a lot of warnings about duplicate 
    classes, but those can just be ignored).
    
    --John
    
    On 20/10/2022 19:03, Thomas Reinhardt wrote:
    >
    > Hi Nir,
    >
    > Does not work (I testet it) and it can not work (see below).
    >
    > Also, this is exactly what my naive test was (I did not use maven to 
    > copy the artifacts, but the result obviously is the same).
    >
    > It can not work as the implementation classes have the same name and 
    > thus the jre can not distinguish which one to load. For example both 
    > javafx-web-18-win and javafx-web-18-linux define a class 
    > "javafx.scene.web.WebEngine". From the jre's point of view they are 
    > the same.
    >
    > What would be needed is
    >
    > Either: a class "javafx.scene.web.WebEngine" that is only a thin 
    > wrapper to javafx.scene.web.linux.WebEngine.
    >
    > Or: a class that loads only one of the implementations during 
    > application startup (technically it could load both implementations 
    > with different classloaders, but lets not go there).
    >
    > There might be other solutions but I am not aware of any.
    >
    >
    > I was looking for a help forum but did only find the #introduction 
    > link you mentioned.
    >
    >
    > ????-Thomas
    >
    >
    >
    > On 20/10/2022 17:52, Nir Lisker wrote:
    >> Hi Thomas,
    >>
    >> Did you try to just specify the platform-specific dependencies in the 
    >> POM?
    >>
    >> ?? ? 
    >> ?? ? ? ? org.openjfx
    >> ?? ? ? ? javafx-graphics
    >> ?? ? ? ? 19
    >> ?? ? ? ? win
    >> ?? ? 
    >> ?? ? 
    >> ?? ? ? ? org.openjfx
    >> ?? ? ? ? javafx-graphics
    >> ?? ? ? ? 19
    >> ?? ? ? ? linux
    >> ?? ? 
    >> ?? ? 
    >> ?? ? ? ? org.openjfx
    >> ?? ? ? ? javafx-graphics
    >> ?? ? ? ? 19
    >> ?? ? ? ? mac
    >> ?? ? 
    >>
    >> Seems more of a question for help forums, though if this information 
    >> is not mentioned in https://openjfx.io/openjfx-docs/#introduction 
    >> , it might be worth 
    >> adding it.
    >>
    >> On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt 
    >> > wrote:
    >>
    >>
    >> ??? Hi!
    >>
    >> ??? Apologizes if this is not the proper list to ask my question.
    >>
    >> ??? For context: we are using the WebView of JavaFX in our legacy swing
    >> ??? based frontend application. For now that is the only component we 
    >> are
    >> ??? using but we might migrate completely at a later point in time.
    >>
    >> ??? I have an issue with the way platform dependent dependencies are
    >> ??? handled. We are using maven btw.
    >> ??? My understanding is that during the build a profile is selected
    >> ??? based on
    >> ??? the host os name and architecture. That profile then sets a property
    >> ??? (javafx.platform) that is in turn used as the classifier for 
    >> platform
    >> ??? dependent dependencies.
    >> ??? (Offtopic to my question: eclipse warns that the profile ids are not
    >> ??? unique in the org.openjfx:javafx pom.xml).
    >>
    >> ??? Which means that the result of my build is locked to a single 
    >> platform.
    >> ??? But we have customers for windows and linux and don't want to have
    >> ??? separate artifacts as that would mean we also have to handle that
    >> ??? distinction in our installer etc.
    >>
    >> ??? I know I can override the automatically detected platform but 
    >> that does
    >> ??? not solve the issue.
    >>
    >> ??? Ideally I would use something like -Djavafx.platform=all but that 
    >> does
    >> ??? not exist.
    >>
    >> ??? My question is: is there an existing solution where I can just 
    >> include
    >> ??? all platform dependencies for say windows and linux and the runtime
    >> ??? "sorts it out"? A naive test (manual copying of artifacts) of mine
    >> ??? unfortunately failed. Of course I could just use custom classloaders
    >> ??? and
    >> ??? do it myself but I really would prefer to use an existing 
    >> solution and
    >> ??? not implement some workaround.
    >>
    >> ??? If there is no solution (yet), is there interest in such a 
    >> feature? We
    >> ??? might be able to contribute to the project.
    >>
    >>
    >> ??? -Thomas
    >>
    
    From andy.goryachev at oracle.com  Thu Oct 20 20:53:31 2022
    From: andy.goryachev at oracle.com (Andy Goryachev)
    Date: Thu, 20 Oct 2022 20:53:31 +0000
    Subject: Platform independent deployment
    In-Reply-To: <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
     <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
    Message-ID: 
    
    Good point - are we packaging platform-specific javafx parts incorrectly?
    
    -andy
    
    From: openjfx-dev  on behalf of John Hendrikx 
    Date: Thursday, 2022/10/20 at 13:03
    To: openjfx-dev at openjdk.org 
    Subject: Re: Platform independent deployment
    Correct me if I'm wrong, but all the classes in the artifacts for win,
    linux and mac are actually exactly the same -- this is Java code after
    all, why would all Java classes for a platform be platform specific?  It
    doesn't matter which one is packaged.  The platform specific stuff lives
    in the native libraries -- my shaded jar just includes all of them for
    all platforms (dll for windows, so for linux, dylib for mac).  I'm
    pretty sure I used this exact same jar to run my software on windows and
    linux.  Never tested mac as I don't own one.
    
    My pom therefore includes all three, like Nir Lisker has, and my shaded
    artifact just packages them all (I get a lot of warnings about duplicate
    classes, but those can just be ignored).
    
    --John
    
    On 20/10/2022 19:03, Thomas Reinhardt wrote:
    >
    > Hi Nir,
    >
    > Does not work (I testet it) and it can not work (see below).
    >
    > Also, this is exactly what my naive test was (I did not use maven to
    > copy the artifacts, but the result obviously is the same).
    >
    > It can not work as the implementation classes have the same name and
    > thus the jre can not distinguish which one to load. For example both
    > javafx-web-18-win and javafx-web-18-linux define a class
    > "javafx.scene.web.WebEngine". From the jre's point of view they are
    > the same.
    >
    > What would be needed is
    >
    > Either: a class "javafx.scene.web.WebEngine" that is only a thin
    > wrapper to javafx.scene.web.linux.WebEngine.
    >
    > Or: a class that loads only one of the implementations during
    > application startup (technically it could load both implementations
    > with different classloaders, but lets not go there).
    >
    > There might be other solutions but I am not aware of any.
    >
    >
    > I was looking for a help forum but did only find the #introduction
    > link you mentioned.
    >
    >
    >     -Thomas
    >
    >
    >
    > On 20/10/2022 17:52, Nir Lisker wrote:
    >> Hi Thomas,
    >>
    >> Did you try to just specify the platform-specific dependencies in the
    >> POM?
    >>
    >>      
    >>          org.openjfx
    >>          javafx-graphics
    >>          19
    >>          win
    >>      
    >>      
    >>          org.openjfx
    >>          javafx-graphics
    >>          19
    >>          linux
    >>      
    >>      
    >>          org.openjfx
    >>          javafx-graphics
    >>          19
    >>          mac
    >>      
    >>
    >> Seems more of a question for help forums, though if this information
    >> is not mentioned in https://openjfx.io/openjfx-docs/#introduction
    >> , it might be worth
    >> adding it.
    >>
    >> On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt
    >> > wrote:
    >>
    >>
    >>     Hi!
    >>
    >>     Apologizes if this is not the proper list to ask my question.
    >>
    >>     For context: we are using the WebView of JavaFX in our legacy swing
    >>     based frontend application. For now that is the only component we
    >> are
    >>     using but we might migrate completely at a later point in time.
    >>
    >>     I have an issue with the way platform dependent dependencies are
    >>     handled. We are using maven btw.
    >>     My understanding is that during the build a profile is selected
    >>     based on
    >>     the host os name and architecture. That profile then sets a property
    >>     (javafx.platform) that is in turn used as the classifier for
    >> platform
    >>     dependent dependencies.
    >>     (Offtopic to my question: eclipse warns that the profile ids are not
    >>     unique in the org.openjfx:javafx pom.xml).
    >>
    >>     Which means that the result of my build is locked to a single
    >> platform.
    >>     But we have customers for windows and linux and don't want to have
    >>     separate artifacts as that would mean we also have to handle that
    >>     distinction in our installer etc.
    >>
    >>     I know I can override the automatically detected platform but
    >> that does
    >>     not solve the issue.
    >>
    >>     Ideally I would use something like -Djavafx.platform=all but that
    >> does
    >>     not exist.
    >>
    >>     My question is: is there an existing solution where I can just
    >> include
    >>     all platform dependencies for say windows and linux and the runtime
    >>     "sorts it out"? A naive test (manual copying of artifacts) of mine
    >>     unfortunately failed. Of course I could just use custom classloaders
    >>     and
    >>     do it myself but I really would prefer to use an existing
    >> solution and
    >>     not implement some workaround.
    >>
    >>     If there is no solution (yet), is there interest in such a
    >> feature? We
    >>     might be able to contribute to the project.
    >>
    >>
    >>     -Thomas
    >>
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From thomas.reinhardt at s4p.de  Thu Oct 20 21:05:04 2022
    From: thomas.reinhardt at s4p.de (Thomas Reinhardt)
    Date: Thu, 20 Oct 2022 21:05:04 +0000
    Subject: Platform independent deployment
    In-Reply-To: 
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
     <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
     
    Message-ID: 
    
    Interesting. I will repeat my test more carefully. Maybe I am just doing something incredible stupid. But Andy has a good point: why include the java classes at all in the platform-specific jars - shouldn't they just contain the native libraries if all the java code is indeed the same?
    
    ??????-Thomas
    
    ________________________________
    From: openjfx-dev  on behalf of Andy Goryachev 
    Sent: 20 October 2022 22:53
    To: John Hendrikx ; openjfx-dev at openjdk.org 
    Subject: Re: Platform independent deployment
    
    
    Good point - are we packaging platform-specific javafx parts incorrectly?
    
    
    
    -andy
    
    
    
    From: openjfx-dev  on behalf of John Hendrikx 
    Date: Thursday, 2022/10/20 at 13:03
    To: openjfx-dev at openjdk.org 
    Subject: Re: Platform independent deployment
    
    Correct me if I'm wrong, but all the classes in the artifacts for win,
    linux and mac are actually exactly the same -- this is Java code after
    all, why would all Java classes for a platform be platform specific?  It
    doesn't matter which one is packaged.  The platform specific stuff lives
    in the native libraries -- my shaded jar just includes all of them for
    all platforms (dll for windows, so for linux, dylib for mac).  I'm
    pretty sure I used this exact same jar to run my software on windows and
    linux.  Never tested mac as I don't own one.
    
    My pom therefore includes all three, like Nir Lisker has, and my shaded
    artifact just packages them all (I get a lot of warnings about duplicate
    classes, but those can just be ignored).
    
    --John
    
    On 20/10/2022 19:03, Thomas Reinhardt wrote:
    >
    > Hi Nir,
    >
    > Does not work (I testet it) and it can not work (see below).
    >
    > Also, this is exactly what my naive test was (I did not use maven to
    > copy the artifacts, but the result obviously is the same).
    >
    > It can not work as the implementation classes have the same name and
    > thus the jre can not distinguish which one to load. For example both
    > javafx-web-18-win and javafx-web-18-linux define a class
    > "javafx.scene.web.WebEngine". From the jre's point of view they are
    > the same.
    >
    > What would be needed is
    >
    > Either: a class "javafx.scene.web.WebEngine" that is only a thin
    > wrapper to javafx.scene.web.linux.WebEngine.
    >
    > Or: a class that loads only one of the implementations during
    > application startup (technically it could load both implementations
    > with different classloaders, but lets not go there).
    >
    > There might be other solutions but I am not aware of any.
    >
    >
    > I was looking for a help forum but did only find the #introduction
    > link you mentioned.
    >
    >
    >     -Thomas
    >
    >
    >
    > On 20/10/2022 17:52, Nir Lisker wrote:
    >> Hi Thomas,
    >>
    >> Did you try to just specify the platform-specific dependencies in the
    >> POM?
    >>
    >>      
    >>          org.openjfx
    >>          javafx-graphics
    >>          19
    >>          win
    >>      
    >>      
    >>          org.openjfx
    >>          javafx-graphics
    >>          19
    >>          linux
    >>      
    >>      
    >>          org.openjfx
    >>          javafx-graphics
    >>          19
    >>          mac
    >>      
    >>
    >> Seems more of a question for help forums, though if this information
    >> is not mentioned in https://openjfx.io/openjfx-docs/#introduction
    >> , it might be worth
    >> adding it.
    >>
    >> On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt
    >> > wrote:
    >>
    >>
    >>     Hi!
    >>
    >>     Apologizes if this is not the proper list to ask my question.
    >>
    >>     For context: we are using the WebView of JavaFX in our legacy swing
    >>     based frontend application. For now that is the only component we
    >> are
    >>     using but we might migrate completely at a later point in time.
    >>
    >>     I have an issue with the way platform dependent dependencies are
    >>     handled. We are using maven btw.
    >>     My understanding is that during the build a profile is selected
    >>     based on
    >>     the host os name and architecture. That profile then sets a property
    >>     (javafx.platform) that is in turn used as the classifier for
    >> platform
    >>     dependent dependencies.
    >>     (Offtopic to my question: eclipse warns that the profile ids are not
    >>     unique in the org.openjfx:javafx pom.xml).
    >>
    >>     Which means that the result of my build is locked to a single
    >> platform.
    >>     But we have customers for windows and linux and don't want to have
    >>     separate artifacts as that would mean we also have to handle that
    >>     distinction in our installer etc.
    >>
    >>     I know I can override the automatically detected platform but
    >> that does
    >>     not solve the issue.
    >>
    >>     Ideally I would use something like -Djavafx.platform=all but that
    >> does
    >>     not exist.
    >>
    >>     My question is: is there an existing solution where I can just
    >> include
    >>     all platform dependencies for say windows and linux and the runtime
    >>     "sorts it out"? A naive test (manual copying of artifacts) of mine
    >>     unfortunately failed. Of course I could just use custom classloaders
    >>     and
    >>     do it myself but I really would prefer to use an existing
    >> solution and
    >>     not implement some workaround.
    >>
    >>     If there is no solution (yet), is there interest in such a
    >> feature? We
    >>     might be able to contribute to the project.
    >>
    >>
    >>     -Thomas
    >>
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From nlisker at gmail.com  Thu Oct 20 21:14:50 2022
    From: nlisker at gmail.com (Nir Lisker)
    Date: Fri, 21 Oct 2022 00:14:50 +0300
    Subject: Platform independent deployment
    In-Reply-To: 
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
     <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
     
     
    Message-ID: 
    
    There was a discussion on this some years ago, it started here:
    https://mail.openjdk.org/pipermail/openjfx-dev/2018-April/021762.html (and
    continued in
    https://mail.openjdk.org/pipermail/openjfx-dev/2018-May/021774.html).
    There might have been another discussion after that, I don't remember.
    
    Thomas, the graphics, media, and web modules contain OS-specific libraries.
    You will need to do what I showed for any of these that you use.
    
    On Fri, Oct 21, 2022 at 12:05 AM Thomas Reinhardt 
    wrote:
    
    > Interesting. I will repeat my test more carefully. Maybe I am just doing
    > something incredible stupid. But Andy has a good point: why include the
    > java classes at all in the platform-specific jars - shouldn't they just
    > contain the native libraries if all the java code is indeed the same?
    >
    > -Thomas
    >
    > ------------------------------
    > *From:* openjfx-dev  on behalf of Andy
    > Goryachev 
    > *Sent:* 20 October 2022 22:53
    > *To:* John Hendrikx ; openjfx-dev at openjdk.org <
    > openjfx-dev at openjdk.org>
    > *Subject:* Re: Platform independent deployment
    >
    >
    > Good point - are we packaging platform-specific javafx parts incorrectly?
    >
    >
    >
    > -andy
    >
    >
    >
    > *From: *openjfx-dev  on behalf of John
    > Hendrikx 
    > *Date: *Thursday, 2022/10/20 at 13:03
    > *To: *openjfx-dev at openjdk.org 
    > *Subject: *Re: Platform independent deployment
    >
    > Correct me if I'm wrong, but all the classes in the artifacts for win,
    > linux and mac are actually exactly the same -- this is Java code after
    > all, why would all Java classes for a platform be platform specific?  It
    > doesn't matter which one is packaged.  The platform specific stuff lives
    > in the native libraries -- my shaded jar just includes all of them for
    > all platforms (dll for windows, so for linux, dylib for mac).  I'm
    > pretty sure I used this exact same jar to run my software on windows and
    > linux.  Never tested mac as I don't own one.
    >
    > My pom therefore includes all three, like Nir Lisker has, and my shaded
    > artifact just packages them all (I get a lot of warnings about duplicate
    > classes, but those can just be ignored).
    >
    > --John
    >
    > On 20/10/2022 19:03, Thomas Reinhardt wrote:
    > >
    > > Hi Nir,
    > >
    > > Does not work (I testet it) and it can not work (see below).
    > >
    > > Also, this is exactly what my naive test was (I did not use maven to
    > > copy the artifacts, but the result obviously is the same).
    > >
    > > It can not work as the implementation classes have the same name and
    > > thus the jre can not distinguish which one to load. For example both
    > > javafx-web-18-win and javafx-web-18-linux define a class
    > > "javafx.scene.web.WebEngine". From the jre's point of view they are
    > > the same.
    > >
    > > What would be needed is
    > >
    > > Either: a class "javafx.scene.web.WebEngine" that is only a thin
    > > wrapper to javafx.scene.web.linux.WebEngine.
    > >
    > > Or: a class that loads only one of the implementations during
    > > application startup (technically it could load both implementations
    > > with different classloaders, but lets not go there).
    > >
    > > There might be other solutions but I am not aware of any.
    > >
    > >
    > > I was looking for a help forum but did only find the #introduction
    > > link you mentioned.
    > >
    > >
    > >     -Thomas
    > >
    > >
    > >
    > > On 20/10/2022 17:52, Nir Lisker wrote:
    > >> Hi Thomas,
    > >>
    > >> Did you try to just specify the platform-specific dependencies in the
    > >> POM?
    > >>
    > >>      
    > >>          org.openjfx
    > >>          javafx-graphics
    > >>          19
    > >>          win
    > >>      
    > >>      
    > >>          org.openjfx
    > >>          javafx-graphics
    > >>          19
    > >>          linux
    > >>      
    > >>      
    > >>          org.openjfx
    > >>          javafx-graphics
    > >>          19
    > >>          mac
    > >>      
    > >>
    > >> Seems more of a question for help forums, though if this information
    > >> is not mentioned in https://openjfx.io/openjfx-docs/#introduction
    > >> , it might be worth
    > >> adding it.
    > >>
    > >> On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt
    > >>  >> wrote:
    > >>
    > >>
    > >>     Hi!
    > >>
    > >>     Apologizes if this is not the proper list to ask my question.
    > >>
    > >>     For context: we are using the WebView of JavaFX in our legacy swing
    > >>     based frontend application. For now that is the only component we
    > >> are
    > >>     using but we might migrate completely at a later point in time.
    > >>
    > >>     I have an issue with the way platform dependent dependencies are
    > >>     handled. We are using maven btw.
    > >>     My understanding is that during the build a profile is selected
    > >>     based on
    > >>     the host os name and architecture. That profile then sets a property
    > >>     (javafx.platform) that is in turn used as the classifier for
    > >> platform
    > >>     dependent dependencies.
    > >>     (Offtopic to my question: eclipse warns that the profile ids are not
    > >>     unique in the org.openjfx:javafx pom.xml).
    > >>
    > >>     Which means that the result of my build is locked to a single
    > >> platform.
    > >>     But we have customers for windows and linux and don't want to have
    > >>     separate artifacts as that would mean we also have to handle that
    > >>     distinction in our installer etc.
    > >>
    > >>     I know I can override the automatically detected platform but
    > >> that does
    > >>     not solve the issue.
    > >>
    > >>     Ideally I would use something like -Djavafx.platform=all but that
    > >> does
    > >>     not exist.
    > >>
    > >>     My question is: is there an existing solution where I can just
    > >> include
    > >>     all platform dependencies for say windows and linux and the runtime
    > >>     "sorts it out"? A naive test (manual copying of artifacts) of mine
    > >>     unfortunately failed. Of course I could just use custom classloaders
    > >>     and
    > >>     do it myself but I really would prefer to use an existing
    > >> solution and
    > >>     not implement some workaround.
    > >>
    > >>     If there is no solution (yet), is there interest in such a
    > >> feature? We
    > >>     might be able to contribute to the project.
    > >>
    > >>
    > >>     -Thomas
    > >>
    >
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From thomas.reinhardt at s4p.de  Thu Oct 20 22:28:55 2022
    From: thomas.reinhardt at s4p.de (Thomas Reinhardt)
    Date: Thu, 20 Oct 2022 22:28:55 +0000
    Subject: Platform independent deployment
    In-Reply-To: 
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
     <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
     
     
     
    Message-ID: 
    
    Thanks Nir for the links to the other discussions. I got the thing to run with the simple approach of including all artifacts. Probably did miss some before but it's late in the night here :)
    
    One thing that still bugs me is that I have to do dependency resolution manually if I want to include artifacts for different platforms. Not a huge problem but far from a perfect solution.  And I can't stop to think what other big projects are doing. Apart from toy-applications that run on the development system only, everybody should have the same problems I had. Or maybe I am just the last one striving for a platform independent application.
    
    Thank you all for helping out!
    
    ________________________________
    From: Nir Lisker 
    Sent: 20 October 2022 23:14
    To: Thomas Reinhardt 
    Cc: openjfx-dev at openjdk.org 
    Subject: Re: Platform independent deployment
    
    There was a discussion on this some years ago, it started here: https://mail.openjdk.org/pipermail/openjfx-dev/2018-April/021762.html (and continued in https://mail.openjdk.org/pipermail/openjfx-dev/2018-May/021774.html).
    There might have been another discussion after that, I don't remember.
    
    Thomas, the graphics, media, and web modules contain OS-specific libraries. You will need to do what I showed for any of these that you use.
    
    On Fri, Oct 21, 2022 at 12:05 AM Thomas Reinhardt > wrote:
    Interesting. I will repeat my test more carefully. Maybe I am just doing something incredible stupid. But Andy has a good point: why include the java classes at all in the platform-specific jars - shouldn't they just contain the native libraries if all the java code is indeed the same?
    
    ??????-Thomas
    
    ________________________________
    From: openjfx-dev > on behalf of Andy Goryachev >
    Sent: 20 October 2022 22:53
    To: John Hendrikx >; openjfx-dev at openjdk.org >
    Subject: Re: Platform independent deployment
    
    
    Good point - are we packaging platform-specific javafx parts incorrectly?
    
    
    
    -andy
    
    
    
    From: openjfx-dev > on behalf of John Hendrikx >
    Date: Thursday, 2022/10/20 at 13:03
    To: openjfx-dev at openjdk.org >
    Subject: Re: Platform independent deployment
    
    Correct me if I'm wrong, but all the classes in the artifacts for win,
    linux and mac are actually exactly the same -- this is Java code after
    all, why would all Java classes for a platform be platform specific?  It
    doesn't matter which one is packaged.  The platform specific stuff lives
    in the native libraries -- my shaded jar just includes all of them for
    all platforms (dll for windows, so for linux, dylib for mac).  I'm
    pretty sure I used this exact same jar to run my software on windows and
    linux.  Never tested mac as I don't own one.
    
    My pom therefore includes all three, like Nir Lisker has, and my shaded
    artifact just packages them all (I get a lot of warnings about duplicate
    classes, but those can just be ignored).
    
    --John
    
    On 20/10/2022 19:03, Thomas Reinhardt wrote:
    >
    > Hi Nir,
    >
    > Does not work (I testet it) and it can not work (see below).
    >
    > Also, this is exactly what my naive test was (I did not use maven to
    > copy the artifacts, but the result obviously is the same).
    >
    > It can not work as the implementation classes have the same name and
    > thus the jre can not distinguish which one to load. For example both
    > javafx-web-18-win and javafx-web-18-linux define a class
    > "javafx.scene.web.WebEngine". From the jre's point of view they are
    > the same.
    >
    > What would be needed is
    >
    > Either: a class "javafx.scene.web.WebEngine" that is only a thin
    > wrapper to javafx.scene.web.linux.WebEngine.
    >
    > Or: a class that loads only one of the implementations during
    > application startup (technically it could load both implementations
    > with different classloaders, but lets not go there).
    >
    > There might be other solutions but I am not aware of any.
    >
    >
    > I was looking for a help forum but did only find the #introduction
    > link you mentioned.
    >
    >
    >     -Thomas
    >
    >
    >
    > On 20/10/2022 17:52, Nir Lisker wrote:
    >> Hi Thomas,
    >>
    >> Did you try to just specify the platform-specific dependencies in the
    >> POM?
    >>
    >>      
    >>          org.openjfx
    >>          javafx-graphics
    >>          19
    >>          win
    >>      
    >>      
    >>          org.openjfx
    >>          javafx-graphics
    >>          19
    >>          linux
    >>      
    >>      
    >>          org.openjfx
    >>          javafx-graphics
    >>          19
    >>          mac
    >>      
    >>
    >> Seems more of a question for help forums, though if this information
    >> is not mentioned in https://openjfx.io/openjfx-docs/#introduction
    >> , it might be worth
    >> adding it.
    >>
    >> On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt
    >>  > wrote:
    >>
    >>
    >>     Hi!
    >>
    >>     Apologizes if this is not the proper list to ask my question.
    >>
    >>     For context: we are using the WebView of JavaFX in our legacy swing
    >>     based frontend application. For now that is the only component we
    >> are
    >>     using but we might migrate completely at a later point in time.
    >>
    >>     I have an issue with the way platform dependent dependencies are
    >>     handled. We are using maven btw.
    >>     My understanding is that during the build a profile is selected
    >>     based on
    >>     the host os name and architecture. That profile then sets a property
    >>     (javafx.platform) that is in turn used as the classifier for
    >> platform
    >>     dependent dependencies.
    >>     (Offtopic to my question: eclipse warns that the profile ids are not
    >>     unique in the org.openjfx:javafx pom.xml).
    >>
    >>     Which means that the result of my build is locked to a single
    >> platform.
    >>     But we have customers for windows and linux and don't want to have
    >>     separate artifacts as that would mean we also have to handle that
    >>     distinction in our installer etc.
    >>
    >>     I know I can override the automatically detected platform but
    >> that does
    >>     not solve the issue.
    >>
    >>     Ideally I would use something like -Djavafx.platform=all but that
    >> does
    >>     not exist.
    >>
    >>     My question is: is there an existing solution where I can just
    >> include
    >>     all platform dependencies for say windows and linux and the runtime
    >>     "sorts it out"? A naive test (manual copying of artifacts) of mine
    >>     unfortunately failed. Of course I could just use custom classloaders
    >>     and
    >>     do it myself but I really would prefer to use an existing
    >> solution and
    >>     not implement some workaround.
    >>
    >>     If there is no solution (yet), is there interest in such a
    >> feature? We
    >>     might be able to contribute to the project.
    >>
    >>
    >>     -Thomas
    >>
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From nlisker at gmail.com  Thu Oct 20 22:38:29 2022
    From: nlisker at gmail.com (Nir Lisker)
    Date: Fri, 21 Oct 2022 01:38:29 +0300
    Subject: Platform independent deployment
    In-Reply-To: 
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
     <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
     
     
     
     
    Message-ID: 
    
    It doesn't look to me like a big problem, regardless of the size of the
    project. You just include the modules you want depending on what your
    application needs and which platforms it targets. In Gradle, it's just 2
    lines of code.
    
    There is also the JavaFX plugin that might help with this, but it's
    unrelated to the development here:
    Gradle variant - https://github.com/openjfx/javafx-gradle-plugin
    Maven variant - https://github.com/openjfx/javafx-maven-plugin
    
    On Fri, Oct 21, 2022 at 1:29 AM Thomas Reinhardt 
    wrote:
    
    > Thanks Nir for the links to the other discussions. I got the thing to run
    > with the simple approach of including all artifacts. Probably did miss some
    > before but it's late in the night here :)
    >
    > One thing that still bugs me is that I have to do dependency resolution
    > manually if I want to include artifacts for different platforms. Not a huge
    > problem but far from a perfect solution.  And I can't stop to think what
    > other big projects are doing. Apart from toy-applications that run on the
    > development system only, everybody should have the same problems I had. Or
    > maybe I am just the last one striving for a platform independent
    > application.
    >
    > Thank you all for helping out!
    >
    > ------------------------------
    > *From:* Nir Lisker 
    > *Sent:* 20 October 2022 23:14
    > *To:* Thomas Reinhardt 
    > *Cc:* openjfx-dev at openjdk.org 
    > *Subject:* Re: Platform independent deployment
    >
    > There was a discussion on this some years ago, it started here:
    > https://mail.openjdk.org/pipermail/openjfx-dev/2018-April/021762.html
    > (and continued in
    > https://mail.openjdk.org/pipermail/openjfx-dev/2018-May/021774.html).
    > There might have been another discussion after that, I don't remember.
    >
    > Thomas, the graphics, media, and web modules contain OS-specific
    > libraries. You will need to do what I showed for any of these that you use.
    >
    > On Fri, Oct 21, 2022 at 12:05 AM Thomas Reinhardt 
    > wrote:
    >
    > Interesting. I will repeat my test more carefully. Maybe I am just doing
    > something incredible stupid. But Andy has a good point: why include the
    > java classes at all in the platform-specific jars - shouldn't they just
    > contain the native libraries if all the java code is indeed the same?
    >
    > -Thomas
    >
    > ------------------------------
    > *From:* openjfx-dev  on behalf of Andy
    > Goryachev 
    > *Sent:* 20 October 2022 22:53
    > *To:* John Hendrikx ; openjfx-dev at openjdk.org <
    > openjfx-dev at openjdk.org>
    > *Subject:* Re: Platform independent deployment
    >
    >
    > Good point - are we packaging platform-specific javafx parts incorrectly?
    >
    >
    >
    > -andy
    >
    >
    >
    > *From: *openjfx-dev  on behalf of John
    > Hendrikx 
    > *Date: *Thursday, 2022/10/20 at 13:03
    > *To: *openjfx-dev at openjdk.org 
    > *Subject: *Re: Platform independent deployment
    >
    > Correct me if I'm wrong, but all the classes in the artifacts for win,
    > linux and mac are actually exactly the same -- this is Java code after
    > all, why would all Java classes for a platform be platform specific?  It
    > doesn't matter which one is packaged.  The platform specific stuff lives
    > in the native libraries -- my shaded jar just includes all of them for
    > all platforms (dll for windows, so for linux, dylib for mac).  I'm
    > pretty sure I used this exact same jar to run my software on windows and
    > linux.  Never tested mac as I don't own one.
    >
    > My pom therefore includes all three, like Nir Lisker has, and my shaded
    > artifact just packages them all (I get a lot of warnings about duplicate
    > classes, but those can just be ignored).
    >
    > --John
    >
    > On 20/10/2022 19:03, Thomas Reinhardt wrote:
    > >
    > > Hi Nir,
    > >
    > > Does not work (I testet it) and it can not work (see below).
    > >
    > > Also, this is exactly what my naive test was (I did not use maven to
    > > copy the artifacts, but the result obviously is the same).
    > >
    > > It can not work as the implementation classes have the same name and
    > > thus the jre can not distinguish which one to load. For example both
    > > javafx-web-18-win and javafx-web-18-linux define a class
    > > "javafx.scene.web.WebEngine". From the jre's point of view they are
    > > the same.
    > >
    > > What would be needed is
    > >
    > > Either: a class "javafx.scene.web.WebEngine" that is only a thin
    > > wrapper to javafx.scene.web.linux.WebEngine.
    > >
    > > Or: a class that loads only one of the implementations during
    > > application startup (technically it could load both implementations
    > > with different classloaders, but lets not go there).
    > >
    > > There might be other solutions but I am not aware of any.
    > >
    > >
    > > I was looking for a help forum but did only find the #introduction
    > > link you mentioned.
    > >
    > >
    > >     -Thomas
    > >
    > >
    > >
    > > On 20/10/2022 17:52, Nir Lisker wrote:
    > >> Hi Thomas,
    > >>
    > >> Did you try to just specify the platform-specific dependencies in the
    > >> POM?
    > >>
    > >>      
    > >>          org.openjfx
    > >>          javafx-graphics
    > >>          19
    > >>          win
    > >>      
    > >>      
    > >>          org.openjfx
    > >>          javafx-graphics
    > >>          19
    > >>          linux
    > >>      
    > >>      
    > >>          org.openjfx
    > >>          javafx-graphics
    > >>          19
    > >>          mac
    > >>      
    > >>
    > >> Seems more of a question for help forums, though if this information
    > >> is not mentioned in https://openjfx.io/openjfx-docs/#introduction
    > >> , it might be worth
    > >> adding it.
    > >>
    > >> On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt
    > >>  >> wrote:
    > >>
    > >>
    > >>     Hi!
    > >>
    > >>     Apologizes if this is not the proper list to ask my question.
    > >>
    > >>     For context: we are using the WebView of JavaFX in our legacy swing
    > >>     based frontend application. For now that is the only component we
    > >> are
    > >>     using but we might migrate completely at a later point in time.
    > >>
    > >>     I have an issue with the way platform dependent dependencies are
    > >>     handled. We are using maven btw.
    > >>     My understanding is that during the build a profile is selected
    > >>     based on
    > >>     the host os name and architecture. That profile then sets a property
    > >>     (javafx.platform) that is in turn used as the classifier for
    > >> platform
    > >>     dependent dependencies.
    > >>     (Offtopic to my question: eclipse warns that the profile ids are not
    > >>     unique in the org.openjfx:javafx pom.xml).
    > >>
    > >>     Which means that the result of my build is locked to a single
    > >> platform.
    > >>     But we have customers for windows and linux and don't want to have
    > >>     separate artifacts as that would mean we also have to handle that
    > >>     distinction in our installer etc.
    > >>
    > >>     I know I can override the automatically detected platform but
    > >> that does
    > >>     not solve the issue.
    > >>
    > >>     Ideally I would use something like -Djavafx.platform=all but that
    > >> does
    > >>     not exist.
    > >>
    > >>     My question is: is there an existing solution where I can just
    > >> include
    > >>     all platform dependencies for say windows and linux and the runtime
    > >>     "sorts it out"? A naive test (manual copying of artifacts) of mine
    > >>     unfortunately failed. Of course I could just use custom classloaders
    > >>     and
    > >>     do it myself but I really would prefer to use an existing
    > >> solution and
    > >>     not implement some workaround.
    > >>
    > >>     If there is no solution (yet), is there interest in such a
    > >> feature? We
    > >>     might be able to contribute to the project.
    > >>
    > >>
    > >>     -Thomas
    > >>
    >
    >
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From kcr at openjdk.org  Fri Oct 21 00:50:55 2022
    From: kcr at openjdk.org (Kevin Rushforth)
    Date: Fri, 21 Oct 2022 00:50:55 GMT
    Subject: RFR: 8295725: Update copyright header for files modified in 2022
    In-Reply-To: <0OHEkg2vF_59IVVtBi1qXlsu7pgeyuCnnMFLsIsjQ08=.b9425169-5097-45a1-a5f1-d2fbf147938a@github.com>
    References: <0OHEkg2vF_59IVVtBi1qXlsu7pgeyuCnnMFLsIsjQ08=.b9425169-5097-45a1-a5f1-d2fbf147938a@github.com>
    Message-ID: 
    
    On Thu, 20 Oct 2022 11:31:43 GMT, Ambarish Rapte  wrote:
    
    > Updating last modified year in copyright header of the files that were modified during year 2022.
    
    Marked as reviewed by kcr (Lead).
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/923
    
    From philip.race at oracle.com  Fri Oct 21 06:11:41 2022
    From: philip.race at oracle.com (Philip Race)
    Date: Thu, 20 Oct 2022 23:11:41 -0700
    Subject: Platform independent deployment
    In-Reply-To: <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
     <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
    Message-ID: 
    
     > this is Java code after all, why would all Java classes for a 
    platform be platform specific?
    
    There absolutely CAN be such things as platform-specific Java classes in 
    code that ports to a platform.
    OpenJDK is littered with subdirectories named "windows" and "linux" etc.
    And it takes great care to build and ship these only on appropriate 
    platforms.
    
    In JavaFX such things also exist that are less clear but still 
    platform-specific
    For example what place does
    modules/javafx.graphics/src/main/java/com/sun/javafx/font/coretext have 
    in the windows build, or
    modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite 
    have in the macos build ?
    
    None, really, and even though they are there, they really should not be.
    
    So the bottom line is that you should not assume that a platform like 
    JavaFX can be
    delivered only with platform independent Java code.
    
    -phil
    
    
    On 10/20/22 1:03 PM, John Hendrikx wrote:
    > Correct me if I'm wrong, but all the classes in the artifacts for win, 
    > linux and mac are actually exactly the same -- this is Java code after 
    > all, why would all Java classes for a platform be platform specific?? 
    > It doesn't matter which one is packaged.? The platform specific stuff 
    > lives in the native libraries -- my shaded jar just includes all of 
    > them for all platforms (dll for windows, so for linux, dylib for 
    > mac).? I'm pretty sure I used this exact same jar to run my software 
    > on windows and linux.? Never tested mac as I don't own one.
    >
    > My pom therefore includes all three, like Nir Lisker has, and my 
    > shaded artifact just packages them all (I get a lot of warnings about 
    > duplicate classes, but those can just be ignored).
    >
    > --John
    >
    > On 20/10/2022 19:03, Thomas Reinhardt wrote:
    >>
    >> Hi Nir,
    >>
    >> Does not work (I testet it) and it can not work (see below).
    >>
    >> Also, this is exactly what my naive test was (I did not use maven to 
    >> copy the artifacts, but the result obviously is the same).
    >>
    >> It can not work as the implementation classes have the same name and 
    >> thus the jre can not distinguish which one to load. For example both 
    >> javafx-web-18-win and javafx-web-18-linux define a class 
    >> "javafx.scene.web.WebEngine". From the jre's point of view they are 
    >> the same.
    >>
    >> What would be needed is
    >>
    >> Either: a class "javafx.scene.web.WebEngine" that is only a thin 
    >> wrapper to javafx.scene.web.linux.WebEngine.
    >>
    >> Or: a class that loads only one of the implementations during 
    >> application startup (technically it could load both implementations 
    >> with different classloaders, but lets not go there).
    >>
    >> There might be other solutions but I am not aware of any.
    >>
    >>
    >> I was looking for a help forum but did only find the #introduction 
    >> link you mentioned.
    >>
    >>
    >> ????-Thomas
    >>
    >>
    >>
    >> On 20/10/2022 17:52, Nir Lisker wrote:
    >>> Hi Thomas,
    >>>
    >>> Did you try to just specify the platform-specific dependencies in 
    >>> the POM?
    >>>
    >>> ?? ? 
    >>> ?? ? ? ? org.openjfx
    >>> ?? ? ? ? javafx-graphics
    >>> ?? ? ? ? 19
    >>> ?? ? ? ? win
    >>> ?? ? 
    >>> ?? ? 
    >>> ?? ? ? ? org.openjfx
    >>> ?? ? ? ? javafx-graphics
    >>> ?? ? ? ? 19
    >>> ?? ? ? ? linux
    >>> ?? ? 
    >>> ?? ? 
    >>> ?? ? ? ? org.openjfx
    >>> ?? ? ? ? javafx-graphics
    >>> ?? ? ? ? 19
    >>> ?? ? ? ? mac
    >>> ?? ? 
    >>>
    >>> Seems more of a question for help forums, though if this information 
    >>> is not mentioned in https://openjfx.io/openjfx-docs/#introduction 
    >>> , it might be worth 
    >>> adding it.
    >>>
    >>> On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt 
    >>> > wrote:
    >>>
    >>>
    >>> ??? Hi!
    >>>
    >>> ??? Apologizes if this is not the proper list to ask my question.
    >>>
    >>> ??? For context: we are using the WebView of JavaFX in our legacy swing
    >>> ??? based frontend application. For now that is the only component 
    >>> we are
    >>> ??? using but we might migrate completely at a later point in time.
    >>>
    >>> ??? I have an issue with the way platform dependent dependencies are
    >>> ??? handled. We are using maven btw.
    >>> ??? My understanding is that during the build a profile is selected
    >>> ??? based on
    >>> ??? the host os name and architecture. That profile then sets a 
    >>> property
    >>> ??? (javafx.platform) that is in turn used as the classifier for 
    >>> platform
    >>> ??? dependent dependencies.
    >>> ??? (Offtopic to my question: eclipse warns that the profile ids are 
    >>> not
    >>> ??? unique in the org.openjfx:javafx pom.xml).
    >>>
    >>> ??? Which means that the result of my build is locked to a single 
    >>> platform.
    >>> ??? But we have customers for windows and linux and don't want to have
    >>> ??? separate artifacts as that would mean we also have to handle that
    >>> ??? distinction in our installer etc.
    >>>
    >>> ??? I know I can override the automatically detected platform but 
    >>> that does
    >>> ??? not solve the issue.
    >>>
    >>> ??? Ideally I would use something like -Djavafx.platform=all but 
    >>> that does
    >>> ??? not exist.
    >>>
    >>> ??? My question is: is there an existing solution where I can just 
    >>> include
    >>> ??? all platform dependencies for say windows and linux and the runtime
    >>> ??? "sorts it out"? A naive test (manual copying of artifacts) of mine
    >>> ??? unfortunately failed. Of course I could just use custom 
    >>> classloaders
    >>> ??? and
    >>> ??? do it myself but I really would prefer to use an existing 
    >>> solution and
    >>> ??? not implement some workaround.
    >>>
    >>> ??? If there is no solution (yet), is there interest in such a 
    >>> feature? We
    >>> ??? might be able to contribute to the project.
    >>>
    >>>
    >>> ??? -Thomas
    >>>
    
    
    From jvos at openjdk.org  Fri Oct 21 07:20:51 2022
    From: jvos at openjdk.org (Johan Vos)
    Date: Fri, 21 Oct 2022 07:20:51 GMT
    Subject: [jfx17u] Integrated: 8291625: DialogPane without header nor headerText
     nor graphic node adds padding to the left of the content pane
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Thu, 20 Oct 2022 16:55:22 GMT, Johan Vos  wrote:
    
    > clean backport of 8291625: DialogPane without header nor headerText nor graphic node adds padding to the left of the content pane
    > 
    > Reviewed-by: aghaisas
    
    This pull request has now been integrated.
    
    Changeset: aa7edf2e
    Author:    Johan Vos 
    URL:       https://git.openjdk.org/jfx17u/commit/aa7edf2e579505ca53262affeef2c90f81daa5bf
    Stats:     47 lines in 2 files changed: 40 ins; 3 del; 4 mod
    
    8291625: DialogPane without header nor headerText nor graphic node adds padding to the left of the content pane
    
    Backport-of: bee2dfb848c908c62764a1fa9c071d2cfcf9c1f4
    
    -------------
    
    PR: https://git.openjdk.org/jfx17u/pull/84
    
    From jvos at openjdk.org  Fri Oct 21 07:21:32 2022
    From: jvos at openjdk.org (Johan Vos)
    Date: Fri, 21 Oct 2022 07:21:32 GMT
    Subject: [jfx17u] Integrated: 8284665: First selected item of a TreeItem
     multiple selection gets removed if new items are constantly added to the
     TreeTableView
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Thu, 20 Oct 2022 17:24:57 GMT, Johan Vos  wrote:
    
    > clean backport of 8284665: First selected item of a TreeItem multiple selection gets removed if new items are constantly added to the TreeTableView
    > 
    > Reviewed-by: aghaisas
    
    This pull request has now been integrated.
    
    Changeset: 7bef58e4
    Author:    Johan Vos 
    URL:       https://git.openjdk.org/jfx17u/commit/7bef58e4c3f09bb1f0d7b737f4cf7ab3e805bd65
    Stats:     101 lines in 4 files changed: 99 ins; 0 del; 2 mod
    
    8284665: First selected item of a TreeItem multiple selection gets removed if new items are constantly added to the TreeTableView
    
    Backport-of: 83a46e0cef3f041b349c59cd9108d9a5895e79c9
    
    -------------
    
    PR: https://git.openjdk.org/jfx17u/pull/85
    
    From john.hendrikx at gmail.com  Fri Oct 21 08:22:20 2022
    From: john.hendrikx at gmail.com (John Hendrikx)
    Date: Fri, 21 Oct 2022 10:22:20 +0200
    Subject: Platform independent deployment
    In-Reply-To: 
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
     <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
     
    Message-ID: <58b6e5bc-4b91-3827-5b96-d87f2a3c265a@gmail.com>
    
    Thanks Phil, I wasn't aware of those.
    
    I think the point still stands though that the same class never has 
    different contents (in JavaFX at least) for a different platform (ie, 
    there aren't three different versions of ButtonSkin for the different 
    platforms). Additional classes specific to a platform with unique names 
    that are only used on that platform are okay -- you should still be able 
    to package all of the artifacts, strip out duplicates and make a fat jar 
    out of it that runs on all platforms.
    
    --John
    
    On 21/10/2022 08:11, Philip Race wrote:
    > > this is Java code after all, why would all Java classes for a 
    > platform be platform specific?
    >
    > There absolutely CAN be such things as platform-specific Java classes 
    > in code that ports to a platform.
    > OpenJDK is littered with subdirectories named "windows" and "linux" etc.
    > And it takes great care to build and ship these only on appropriate 
    > platforms.
    >
    > In JavaFX such things also exist that are less clear but still 
    > platform-specific
    > For example what place does
    > modules/javafx.graphics/src/main/java/com/sun/javafx/font/coretext 
    > have in the windows build, or
    > modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite 
    > have in the macos build ?
    >
    > None, really, and even though they are there, they really should not be.
    >
    > So the bottom line is that you should not assume that a platform like 
    > JavaFX can be
    > delivered only with platform independent Java code.
    >
    > -phil
    >
    >
    > On 10/20/22 1:03 PM, John Hendrikx wrote:
    >> Correct me if I'm wrong, but all the classes in the artifacts for 
    >> win, linux and mac are actually exactly the same -- this is Java code 
    >> after all, why would all Java classes for a platform be platform 
    >> specific?? It doesn't matter which one is packaged.? The platform 
    >> specific stuff lives in the native libraries -- my shaded jar just 
    >> includes all of them for all platforms (dll for windows, so for 
    >> linux, dylib for mac).? I'm pretty sure I used this exact same jar to 
    >> run my software on windows and linux.? Never tested mac as I don't 
    >> own one.
    >>
    >> My pom therefore includes all three, like Nir Lisker has, and my 
    >> shaded artifact just packages them all (I get a lot of warnings about 
    >> duplicate classes, but those can just be ignored).
    >>
    >> --John
    >>
    >> On 20/10/2022 19:03, Thomas Reinhardt wrote:
    >>>
    >>> Hi Nir,
    >>>
    >>> Does not work (I testet it) and it can not work (see below).
    >>>
    >>> Also, this is exactly what my naive test was (I did not use maven to 
    >>> copy the artifacts, but the result obviously is the same).
    >>>
    >>> It can not work as the implementation classes have the same name and 
    >>> thus the jre can not distinguish which one to load. For example both 
    >>> javafx-web-18-win and javafx-web-18-linux define a class 
    >>> "javafx.scene.web.WebEngine". From the jre's point of view they are 
    >>> the same.
    >>>
    >>> What would be needed is
    >>>
    >>> Either: a class "javafx.scene.web.WebEngine" that is only a thin 
    >>> wrapper to javafx.scene.web.linux.WebEngine.
    >>>
    >>> Or: a class that loads only one of the implementations during 
    >>> application startup (technically it could load both implementations 
    >>> with different classloaders, but lets not go there).
    >>>
    >>> There might be other solutions but I am not aware of any.
    >>>
    >>>
    >>> I was looking for a help forum but did only find the #introduction 
    >>> link you mentioned.
    >>>
    >>>
    >>> ????-Thomas
    >>>
    >>>
    >>>
    >>> On 20/10/2022 17:52, Nir Lisker wrote:
    >>>> Hi Thomas,
    >>>>
    >>>> Did you try to just specify the platform-specific dependencies in 
    >>>> the POM?
    >>>>
    >>>> ?? ? 
    >>>> ?? ? ? ? org.openjfx
    >>>> javafx-graphics
    >>>> ?? ? ? ? 19
    >>>> ?? ? ? ? win
    >>>> ?? ? 
    >>>> ?? ? 
    >>>> ?? ? ? ? org.openjfx
    >>>> javafx-graphics
    >>>> ?? ? ? ? 19
    >>>> ?? ? ? ? linux
    >>>> ?? ? 
    >>>> ?? ? 
    >>>> ?? ? ? ? org.openjfx
    >>>> javafx-graphics
    >>>> ?? ? ? ? 19
    >>>> ?? ? ? ? mac
    >>>> ?? ? 
    >>>>
    >>>> Seems more of a question for help forums, though if this 
    >>>> information is not mentioned in 
    >>>> https://openjfx.io/openjfx-docs/#introduction 
    >>>> , it might be worth 
    >>>> adding it.
    >>>>
    >>>> On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt 
    >>>> > wrote:
    >>>>
    >>>>
    >>>> ??? Hi!
    >>>>
    >>>> ??? Apologizes if this is not the proper list to ask my question.
    >>>>
    >>>> ??? For context: we are using the WebView of JavaFX in our legacy 
    >>>> swing
    >>>> ??? based frontend application. For now that is the only component 
    >>>> we are
    >>>> ??? using but we might migrate completely at a later point in time.
    >>>>
    >>>> ??? I have an issue with the way platform dependent dependencies are
    >>>> ??? handled. We are using maven btw.
    >>>> ??? My understanding is that during the build a profile is selected
    >>>> ??? based on
    >>>> ??? the host os name and architecture. That profile then sets a 
    >>>> property
    >>>> ??? (javafx.platform) that is in turn used as the classifier for 
    >>>> platform
    >>>> ??? dependent dependencies.
    >>>> ??? (Offtopic to my question: eclipse warns that the profile ids 
    >>>> are not
    >>>> ??? unique in the org.openjfx:javafx pom.xml).
    >>>>
    >>>> ??? Which means that the result of my build is locked to a single 
    >>>> platform.
    >>>> ??? But we have customers for windows and linux and don't want to have
    >>>> ??? separate artifacts as that would mean we also have to handle that
    >>>> ??? distinction in our installer etc.
    >>>>
    >>>> ??? I know I can override the automatically detected platform but 
    >>>> that does
    >>>> ??? not solve the issue.
    >>>>
    >>>> ??? Ideally I would use something like -Djavafx.platform=all but 
    >>>> that does
    >>>> ??? not exist.
    >>>>
    >>>> ??? My question is: is there an existing solution where I can just 
    >>>> include
    >>>> ??? all platform dependencies for say windows and linux and the 
    >>>> runtime
    >>>> ??? "sorts it out"? A naive test (manual copying of artifacts) of mine
    >>>> ??? unfortunately failed. Of course I could just use custom 
    >>>> classloaders
    >>>> ??? and
    >>>> ??? do it myself but I really would prefer to use an existing 
    >>>> solution and
    >>>> ??? not implement some workaround.
    >>>>
    >>>> ??? If there is no solution (yet), is there interest in such a 
    >>>> feature? We
    >>>> ??? might be able to contribute to the project.
    >>>>
    >>>>
    >>>> ??? -Thomas
    >>>>
    >
    
    From johan at lodgon.com  Fri Oct 21 08:54:50 2022
    From: johan at lodgon.com (Johan Vos)
    Date: Fri, 21 Oct 2022 10:54:50 +0200
    Subject: Platform independent deployment
    In-Reply-To: 
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
     <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
     
     
     
     
     
    Message-ID: 
    
    Unless I misunderstand the discussion here, the plugins [1][2] Nir refers
    to are exactly created to solve the original problem. For reasons Phil
    explains very well, we do need different jars for different platforms.
    
    The maven and gradle plugins take away the task from the developer to
    specify what platform is used at runtime. No need to use all jars on a
    single platform.
    
    How to use them is explained at https://openjfx.io/openjfx-docs/#maven
    --note that you do not specify the classifier in the end-user pom.xml
    
    - Johan
    
    [1]  Gradle variant - https://github.com/openjfx/javafx-gradle-plugin
    
    [2] Maven variant - https://github.com/openjfx/javafx-maven-plugin
    
    Op vr 21 okt. 2022 om 00:39 schreef Nir Lisker :
    
    > It doesn't look to me like a big problem, regardless of the size of the
    > project. You just include the modules you want depending on what your
    > application needs and which platforms it targets. In Gradle, it's just 2
    > lines of code.
    >
    > There is also the JavaFX plugin that might help with this, but it's
    > unrelated to the development here:
    > Gradle variant - https://github.com/openjfx/javafx-gradle-plugin
    > Maven variant - https://github.com/openjfx/javafx-maven-plugin
    >
    > On Fri, Oct 21, 2022 at 1:29 AM Thomas Reinhardt 
    > wrote:
    >
    >> Thanks Nir for the links to the other discussions. I got the thing to run
    >> with the simple approach of including all artifacts. Probably did miss some
    >> before but it's late in the night here :)
    >>
    >> One thing that still bugs me is that I have to do dependency resolution
    >> manually if I want to include artifacts for different platforms. Not a huge
    >> problem but far from a perfect solution.  And I can't stop to think what
    >> other big projects are doing. Apart from toy-applications that run on the
    >> development system only, everybody should have the same problems I had. Or
    >> maybe I am just the last one striving for a platform independent
    >> application.
    >>
    >> Thank you all for helping out!
    >>
    >> ------------------------------
    >> *From:* Nir Lisker 
    >> *Sent:* 20 October 2022 23:14
    >> *To:* Thomas Reinhardt 
    >> *Cc:* openjfx-dev at openjdk.org 
    >> *Subject:* Re: Platform independent deployment
    >>
    >> There was a discussion on this some years ago, it started here:
    >> https://mail.openjdk.org/pipermail/openjfx-dev/2018-April/021762.html
    >> (and continued in
    >> https://mail.openjdk.org/pipermail/openjfx-dev/2018-May/021774.html).
    >> There might have been another discussion after that, I don't remember.
    >>
    >> Thomas, the graphics, media, and web modules contain OS-specific
    >> libraries. You will need to do what I showed for any of these that you use.
    >>
    >> On Fri, Oct 21, 2022 at 12:05 AM Thomas Reinhardt <
    >> thomas.reinhardt at s4p.de> wrote:
    >>
    >> Interesting. I will repeat my test more carefully. Maybe I am just doing
    >> something incredible stupid. But Andy has a good point: why include the
    >> java classes at all in the platform-specific jars - shouldn't they just
    >> contain the native libraries if all the java code is indeed the same?
    >>
    >> -Thomas
    >>
    >> ------------------------------
    >> *From:* openjfx-dev  on behalf of Andy
    >> Goryachev 
    >> *Sent:* 20 October 2022 22:53
    >> *To:* John Hendrikx ; openjfx-dev at openjdk.org <
    >> openjfx-dev at openjdk.org>
    >> *Subject:* Re: Platform independent deployment
    >>
    >>
    >> Good point - are we packaging platform-specific javafx parts incorrectly?
    >>
    >>
    >>
    >> -andy
    >>
    >>
    >>
    >> *From: *openjfx-dev  on behalf of John
    >> Hendrikx 
    >> *Date: *Thursday, 2022/10/20 at 13:03
    >> *To: *openjfx-dev at openjdk.org 
    >> *Subject: *Re: Platform independent deployment
    >>
    >> Correct me if I'm wrong, but all the classes in the artifacts for win,
    >> linux and mac are actually exactly the same -- this is Java code after
    >> all, why would all Java classes for a platform be platform specific?  It
    >> doesn't matter which one is packaged.  The platform specific stuff lives
    >> in the native libraries -- my shaded jar just includes all of them for
    >> all platforms (dll for windows, so for linux, dylib for mac).  I'm
    >> pretty sure I used this exact same jar to run my software on windows and
    >> linux.  Never tested mac as I don't own one.
    >>
    >> My pom therefore includes all three, like Nir Lisker has, and my shaded
    >> artifact just packages them all (I get a lot of warnings about duplicate
    >> classes, but those can just be ignored).
    >>
    >> --John
    >>
    >> On 20/10/2022 19:03, Thomas Reinhardt wrote:
    >> >
    >> > Hi Nir,
    >> >
    >> > Does not work (I testet it) and it can not work (see below).
    >> >
    >> > Also, this is exactly what my naive test was (I did not use maven to
    >> > copy the artifacts, but the result obviously is the same).
    >> >
    >> > It can not work as the implementation classes have the same name and
    >> > thus the jre can not distinguish which one to load. For example both
    >> > javafx-web-18-win and javafx-web-18-linux define a class
    >> > "javafx.scene.web.WebEngine". From the jre's point of view they are
    >> > the same.
    >> >
    >> > What would be needed is
    >> >
    >> > Either: a class "javafx.scene.web.WebEngine" that is only a thin
    >> > wrapper to javafx.scene.web.linux.WebEngine.
    >> >
    >> > Or: a class that loads only one of the implementations during
    >> > application startup (technically it could load both implementations
    >> > with different classloaders, but lets not go there).
    >> >
    >> > There might be other solutions but I am not aware of any.
    >> >
    >> >
    >> > I was looking for a help forum but did only find the #introduction
    >> > link you mentioned.
    >> >
    >> >
    >> >     -Thomas
    >> >
    >> >
    >> >
    >> > On 20/10/2022 17:52, Nir Lisker wrote:
    >> >> Hi Thomas,
    >> >>
    >> >> Did you try to just specify the platform-specific dependencies in the
    >> >> POM?
    >> >>
    >> >>      
    >> >>          org.openjfx
    >> >>          javafx-graphics
    >> >>          19
    >> >>          win
    >> >>      
    >> >>      
    >> >>          org.openjfx
    >> >>          javafx-graphics
    >> >>          19
    >> >>          linux
    >> >>      
    >> >>      
    >> >>          org.openjfx
    >> >>          javafx-graphics
    >> >>          19
    >> >>          mac
    >> >>      
    >> >>
    >> >> Seems more of a question for help forums, though if this information
    >> >> is not mentioned in https://openjfx.io/openjfx-docs/#introduction
    >> >> , it might be worth
    >> >> adding it.
    >> >>
    >> >> On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt
    >> >> > >> wrote:
    >> >>
    >> >>
    >> >>     Hi!
    >> >>
    >> >>     Apologizes if this is not the proper list to ask my question.
    >> >>
    >> >>     For context: we are using the WebView of JavaFX in our legacy swing
    >> >>     based frontend application. For now that is the only component we
    >> >> are
    >> >>     using but we might migrate completely at a later point in time.
    >> >>
    >> >>     I have an issue with the way platform dependent dependencies are
    >> >>     handled. We are using maven btw.
    >> >>     My understanding is that during the build a profile is selected
    >> >>     based on
    >> >>     the host os name and architecture. That profile then sets a
    >> property
    >> >>     (javafx.platform) that is in turn used as the classifier for
    >> >> platform
    >> >>     dependent dependencies.
    >> >>     (Offtopic to my question: eclipse warns that the profile ids are
    >> not
    >> >>     unique in the org.openjfx:javafx pom.xml).
    >> >>
    >> >>     Which means that the result of my build is locked to a single
    >> >> platform.
    >> >>     But we have customers for windows and linux and don't want to have
    >> >>     separate artifacts as that would mean we also have to handle that
    >> >>     distinction in our installer etc.
    >> >>
    >> >>     I know I can override the automatically detected platform but
    >> >> that does
    >> >>     not solve the issue.
    >> >>
    >> >>     Ideally I would use something like -Djavafx.platform=all but that
    >> >> does
    >> >>     not exist.
    >> >>
    >> >>     My question is: is there an existing solution where I can just
    >> >> include
    >> >>     all platform dependencies for say windows and linux and the runtime
    >> >>     "sorts it out"? A naive test (manual copying of artifacts) of mine
    >> >>     unfortunately failed. Of course I could just use custom
    >> classloaders
    >> >>     and
    >> >>     do it myself but I really would prefer to use an existing
    >> >> solution and
    >> >>     not implement some workaround.
    >> >>
    >> >>     If there is no solution (yet), is there interest in such a
    >> >> feature? We
    >> >>     might be able to contribute to the project.
    >> >>
    >> >>
    >> >>     -Thomas
    >> >>
    >>
    >>
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From thomas.reinhardt at s4p.de  Fri Oct 21 09:36:52 2022
    From: thomas.reinhardt at s4p.de (Thomas Reinhardt)
    Date: Fri, 21 Oct 2022 11:36:52 +0200
    Subject: Platform independent deployment
    In-Reply-To: 
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
     <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
     
     
     
     
     
    Message-ID: <400dccca-1f3b-4221-4347-2eaf8bb2f14a@s4p.de>
    
    
    Hi Nir,
    
    No, it is not a "big problem", but it certainly is an annoyance. I went 
    from 2 dependencies that manage transitive dependencies themselves to 12 
    handcrafted depdendencies. I also have to manage versions for all the 
    platform specific artifacts by hand. That is 6 artifacts for two 
    platforms and most have a platform independent version also. Totalling 
    to 18 versions that I have to manage in my bom. All of that is "easy" 
    but it has to be done and clutters my poms. If we ever want to support 
    another os I will have to add even more noise to my poms.
    
    As for the javafx-maven-plugin: I don't see how this would help here. It 
    states on the github page "JavaFX dependencies are added as usual".
    
    Don't get me wrong, I am perfectly fine with doing it that way. But the 
    situation is far from easy or painless. And after a little digging I 
    think half of the artifacts should not have been platform dependent in 
    the first place:
    
    
    $ diff -rq javafx-base-19-linux/ javafx-base-19-win/ | wc -l
    1
    
    $ diff -rq javafx-controls-19-linux/ javafx-controls-19-win/ | wc -l
    6
    
    $ diff -rq javafx-fxml-19-linux/ javafx-fxml-19-win/ | wc -l
    0
    
    $ diff -rq javafx-graphics-19-linux/ javafx-graphics-19-win/ | wc -l
    72
    
    $ diff -rq javafx-media-19-linux/ javafx-media-19-win/ | wc -l
    13
    
    $ diff -rq javafx-swing-19-linux/ javafx-swing-19-win/ | wc -l
    0
    
    $ diff -rq javafx-web-19-linux/ javafx-web-19-win/ | wc -l
    2
    
    javafx-base only differs in VersionInfo.class, javafx-fxml and 
    javafx-swing are completely identical so 3 out of 7 artifacts really 
    should not be platform dependent at all.
    
    javafx-controls only differs in .bss files (binary css? interesting). 
    seems like a packaging artifact to me as the (corresponding?) .css files 
    are identical. So this artifact probably should not be platform 
    dependent either.
    
    javafx-graphics differs in a handful of java classes and native 
    libraries of course.
    
    javafx-media and javafx-web which differ only in native libraries.
    
    
    I would really like to see the platform dependency be removed from
    javafx-base, javafx-fxml, javafx-swing and javafx-controls. That would 
    be a big step to ease platform independent deployments.
    
    
    Sorry for the big wall of text :)
    
    
    	-Thomas
    
    
    
    On 21/10/2022 00:38, Nir Lisker wrote:
    > It doesn't look to me like a big problem, regardless of the size of the 
    > project. You just include the modules you want depending on what your 
    > application needs and which platforms it targets. In Gradle, it's just 2 
    > lines of code.
    > 
    > There is also the JavaFX plugin that might help with this, but it's 
    > unrelated to the development here:
    > Gradle variant - https://github.com/openjfx/javafx-gradle-plugin 
    > 
    > Maven variant - https://github.com/openjfx/javafx-maven-plugin 
    > 
    > 
    > On Fri, Oct 21, 2022 at 1:29 AM Thomas Reinhardt 
    > > wrote:
    > 
    >     Thanks Nir for the links to the other discussions. I got the thing
    >     to run with the simple approach of including all artifacts. Probably
    >     did miss some before but it's late in the night here :)
    > 
    >     One thing that still bugs me is that I have to do dependency
    >     resolution manually if I want to include artifacts for different
    >     platforms. Not a huge problem but far from a perfect solution.? And
    >     I can't stop to think what other big projects are doing. Apart from
    >     toy-applications that run on the development system only, everybody
    >     should have the same problems I had. Or maybe I am just the last one
    >     striving for a platform independent application.
    > 
    >     Thank you all for helping out!
    > 
    >     ------------------------------------------------------------------------
    >     *From:* Nir Lisker >
    >     *Sent:* 20 October 2022 23:14
    >     *To:* Thomas Reinhardt      >
    >     *Cc:* openjfx-dev at openjdk.org 
    >     >
    >     *Subject:* Re: Platform independent deployment
    >     There was a discussion on this some years ago, it started here:
    >     https://mail.openjdk.org/pipermail/openjfx-dev/2018-April/021762.html  (and continued in https://mail.openjdk.org/pipermail/openjfx-dev/2018-May/021774.html ).
    >     There might have been another discussion after that, I don't remember.
    > 
    >     Thomas, the graphics, media, and web modules contain OS-specific
    >     libraries. You will need to do what I showed for any of these that
    >     you use.
    > 
    >     On Fri, Oct 21, 2022 at 12:05 AM Thomas Reinhardt
    >     > wrote:
    > 
    >         Interesting. I will repeat my test more carefully. Maybe I am
    >         just doing something incredible stupid. But Andy has a good
    >         point: why include the java classes at all in the
    >         platform-specific jars - shouldn't they just contain the native
    >         libraries if all the java code is indeed the same?
    > 
    >         ??????-Thomas
    > 
    >         ------------------------------------------------------------------------
    >         *From:* openjfx-dev          > on behalf of Andy
    >         Goryachev          >
    >         *Sent:* 20 October 2022 22:53
    >         *To:* John Hendrikx          >; openjfx-dev at openjdk.org
    >                   >
    >         *Subject:* Re: Platform independent deployment
    > 
    >         Good point - are we packaging platform-specific javafx parts
    >         incorrectly?
    > 
    >         -andy
    > 
    >         *From: *openjfx-dev          > on behalf of John
    >         Hendrikx >
    >         *Date: *Thursday, 2022/10/20 at 13:03
    >         *To: *openjfx-dev at openjdk.org 
    >         >
    >         *Subject: *Re: Platform independent deployment
    > 
    >         Correct me if I'm wrong, but all the classes in the artifacts
    >         for win,
    >         linux and mac are actually exactly the same -- this is Java code
    >         after
    >         all, why would all Java classes for a platform be platform
    >         specific?? It
    >         doesn't matter which one is packaged.? The platform specific
    >         stuff lives
    >         in the native libraries -- my shaded jar just includes all of
    >         them for
    >         all platforms (dll for windows, so for linux, dylib for mac).? I'm
    >         pretty sure I used this exact same jar to run my software on
    >         windows and
    >         linux.? Never tested mac as I don't own one.
    > 
    >         My pom therefore includes all three, like Nir Lisker has, and my
    >         shaded
    >         artifact just packages them all (I get a lot of warnings about
    >         duplicate
    >         classes, but those can just be ignored).
    > 
    >         --John
    > 
    >         On 20/10/2022 19:03, Thomas Reinhardt wrote:
    >         >
    >         > Hi Nir,
    >         >
    >         > Does not work (I testet it) and it can not work (see below).
    >         >
    >         > Also, this is exactly what my naive test was (I did not use maven to 
    >         > copy the artifacts, but the result obviously is the same).
    >         >
    >         > It can not work as the implementation classes have the same name and 
    >         > thus the jre can not distinguish which one to load. For example both 
    >         > javafx-web-18-win and javafx-web-18-linux define a class 
    >         > "javafx.scene.web.WebEngine". From the jre's point of view they are 
    >         > the same.
    >         >
    >         > What would be needed is
    >         >
    >         > Either: a class "javafx.scene.web.WebEngine" that is only a thin 
    >         > wrapper to javafx.scene.web.linux.WebEngine.
    >         >
    >         > Or: a class that loads only one of the implementations during 
    >         > application startup (technically it could load both implementations 
    >         > with different classloaders, but lets not go there).
    >         >
    >         > There might be other solutions but I am not aware of any.
    >         >
    >         >
    >         > I was looking for a help forum but did only find the #introduction 
    >         > link you mentioned.
    >         >
    >         >
    >         > ????-Thomas
    >         >
    >         >
    >         >
    >         > On 20/10/2022 17:52, Nir Lisker wrote:
    >         >> Hi Thomas,
    >         >>
    >         >> Did you try to just specify the platform-specific dependencies in the 
    >         >> POM?
    >         >>
    >         >> ?? ? 
    >         >> ?? ? ? ? org.openjfx
    >         >> ?? ? ? ? javafx-graphics
    >         >> ?? ? ? ? 19
    >         >> ?? ? ? ? win
    >         >> ?? ? 
    >         >> ?? ? 
    >         >> ?? ? ? ? org.openjfx
    >         >> ?? ? ? ? javafx-graphics
    >         >> ?? ? ? ? 19
    >         >> ?? ? ? ? linux
    >         >> ?? ? 
    >         >> ?? ? 
    >         >> ?? ? ? ? org.openjfx
    >         >> ?? ? ? ? javafx-graphics
    >         >> ?? ? ? ? 19
    >         >> ?? ? ? ? mac
    >         >> ?? ? 
    >         >>
    >         >> Seems more of a question for help forums, though if this information 
    >         >> is not mentioned in https://openjfx.io/openjfx-docs/#introduction
    >         
    >         >>          >, it might be worth
    >         >> adding it.
    >         >>
    >         >> On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt 
    >         >> 
    >                  >> wrote:
    >         >>
    >         >>
    >         >> ??? Hi!
    >         >>
    >         >> ??? Apologizes if this is not the proper list to ask my question.
    >         >>
    >         >> ??? For context: we are using the WebView of JavaFX in our legacy swing
    >         >> ??? based frontend application. For now that is the only component we 
    >         >> are
    >         >> ??? using but we might migrate completely at a later point in time.
    >         >>
    >         >> ??? I have an issue with the way platform dependent dependencies are
    >         >> ??? handled. We are using maven btw.
    >         >> ??? My understanding is that during the build a profile is selected
    >         >> ??? based on
    >         >> ??? the host os name and architecture. That profile then sets a property
    >         >> ??? (javafx.platform) that is in turn used as the classifier for 
    >         >> platform
    >         >> ??? dependent dependencies.
    >         >> ??? (Offtopic to my question: eclipse warns that the profile ids are not
    >         >> ??? unique in the org.openjfx:javafx pom.xml).
    >         >>
    >         >> ??? Which means that the result of my build is locked to a single 
    >         >> platform.
    >         >> ??? But we have customers for windows and linux and don't want to have
    >         >> ??? separate artifacts as that would mean we also have to handle that
    >         >> ??? distinction in our installer etc.
    >         >>
    >         >> ??? I know I can override the automatically detected platform but 
    >         >> that does
    >         >> ??? not solve the issue.
    >         >>
    >         >> ??? Ideally I would use something like -Djavafx.platform=all but that 
    >         >> does
    >         >> ??? not exist.
    >         >>
    >         >> ??? My question is: is there an existing solution where I can just 
    >         >> include
    >         >> ??? all platform dependencies for say windows and linux and the runtime
    >         >> ??? "sorts it out"? A naive test (manual copying of artifacts) of mine
    >         >> ??? unfortunately failed. Of course I could just use custom classloaders
    >         >> ??? and
    >         >> ??? do it myself but I really would prefer to use an existing 
    >         >> solution and
    >         >> ??? not implement some workaround.
    >         >>
    >         >> ??? If there is no solution (yet), is there interest in such a 
    >         >> feature? We
    >         >> ??? might be able to contribute to the project.
    >         >>
    >         >>
    >         >> ??? -Thomas
    >         >>
    > 
    
    From johan.vos at gluonhq.com  Fri Oct 21 09:54:24 2022
    From: johan.vos at gluonhq.com (Johan Vos)
    Date: Fri, 21 Oct 2022 11:54:24 +0200
    Subject: Platform independent deployment
    In-Reply-To: <400dccca-1f3b-4221-4347-2eaf8bb2f14a@s4p.de>
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
     <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
     
     
     
     
     
     <400dccca-1f3b-4221-4347-2eaf8bb2f14a@s4p.de>
    Message-ID: 
    
    On Fri, Oct 21, 2022 at 11:38 AM Thomas Reinhardt 
    wrote:
    
    >
    > As for the javafx-maven-plugin: I don't see how this would help here. It
    > states on the github page "JavaFX dependencies are added as usual".
    >
    
    ... but you don't have to add a classifier (or an exhaustive list of
    classifiers) as that is what the plugin takes care about. Hence: you just
    depend on javafx.controls and you don't mention
    javafx.controls:linux-x86_64 etc in your pom at all.
    
    Unless I'm missing something, I don't see the problem (no need for having
    12 dependencies instead of 2).
    
    - Johan
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From duke at openjdk.org  Fri Oct 21 13:36:07 2022
    From: duke at openjdk.org (eduardsdv)
    Date: Fri, 21 Oct 2022 13:36:07 GMT
    Subject: RFR: 8295324: JavaFX: Blank pages when printing [v2]
    In-Reply-To: 
    References: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com>
     
    Message-ID: 
    
    On Mon, 17 Oct 2022 07:12:00 GMT, eduardsdv  wrote:
    
    >> This fixes a race condition between application and 'Print Job Thread' threads when printing.
    >> 
    >> The race condition occurs when application thread calls `endJob()`, which in effect sets the `jobDone` flag to true,
    >> and when the 'Print Job Thread' thread was in the `synchronized` block in `waitForNextPage()` at that time.
    >> The 'Print Job Thread' thread checks `jobDone` flag after exiting the `synchronized` block and, if it is true, skips the last page.
    >> 
    >> In this fix, not only the `jobDone` is checked, but also that there is no other page to be printed.
    >> It was also needed to introduce a new flag 'jobCanceled', to skip the page if the printing was canceled by 'cancelJob()'.
    >
    > eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   8295324: Fix race condition in junit test
    
    Please review
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/916
    
    From arapte at openjdk.org  Fri Oct 21 15:22:49 2022
    From: arapte at openjdk.org (Ambarish Rapte)
    Date: Fri, 21 Oct 2022 15:22:49 GMT
    Subject: Integrated: 8295725: Update copyright header for files modified in
     2022
    In-Reply-To: <0OHEkg2vF_59IVVtBi1qXlsu7pgeyuCnnMFLsIsjQ08=.b9425169-5097-45a1-a5f1-d2fbf147938a@github.com>
    References: <0OHEkg2vF_59IVVtBi1qXlsu7pgeyuCnnMFLsIsjQ08=.b9425169-5097-45a1-a5f1-d2fbf147938a@github.com>
    Message-ID: 
    
    On Thu, 20 Oct 2022 11:31:43 GMT, Ambarish Rapte  wrote:
    
    > Updating last modified year in copyright header of the files that were modified during year 2022.
    
    This pull request has now been integrated.
    
    Changeset: b3eec1d6
    Author:    Ambarish Rapte 
    URL:       https://git.openjdk.org/jfx/commit/b3eec1d655ca8d17d13615ea430e92058d99ec1c
    Stats:     84 lines in 84 files changed: 0 ins; 0 del; 84 mod
    
    8295725: Update copyright header for files modified in 2022
    
    Reviewed-by: angorya, kcr
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/923
    
    From thomas.reinhardt at s4p.de  Fri Oct 21 16:04:59 2022
    From: thomas.reinhardt at s4p.de (Thomas Reinhardt)
    Date: Fri, 21 Oct 2022 18:04:59 +0200
    Subject: Platform independent deployment
    In-Reply-To: 
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
     <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
     
     
     
     
     
     <400dccca-1f3b-4221-4347-2eaf8bb2f14a@s4p.de>
     
    Message-ID: 
    
    
    I think there is a misunderstanding here.
    
    What I want is basically create a zip that contains all needed jars and 
    run my application via "java -jar myapp.jar". Of course there exists a 
    proper exe for windows users etc but thats besides the point. The one 
    thing the whole discussion is about is that I want to use the same zip 
    for all supported platforms (linux and windows in my case). What I 
    specifically NOT want is platform dependent zips. We have a very large 
    number of dependencies and the size of the whole thing (zipped) is about 
    300MB. Having os specific versions would basically double that size for 
    our nexus instance, the download server etc.
    
    To be clear: the whole thing has to run on the classpath and is not 
    modularized (yet). Not what we want but what other dependencies are 
    forcing us to do.
    
    
    If I read the source correctly, the javafx-maven-plugin can either run 
    the application on my dev machine (why?) or create platform dependent 
    runtime images.
    Am I missing something?
    
    
    Seriously, isn't the sole existence of this plugin an indicator that 
    something is not quite right?
    
    
    
    
    Again, apologies if this sounds personal or unfriendly in any way. Not 
    intended at all.
    
    
    	-Thomas
    
    
    
    
    
    
    
    On 21/10/2022 11:54, Johan Vos wrote:
    > 
    > 
    > On Fri, Oct 21, 2022 at 11:38 AM Thomas Reinhardt 
    > > wrote:
    > 
    > 
    >     As for the javafx-maven-plugin: I don't see how this would help
    >     here. It
    >     states on the github page "JavaFX dependencies are added as usual".
    > 
    > 
    > ... but you don't have to add a classifier (or an exhaustive list of 
    > classifiers) as that is what the plugin takes care about. Hence: you 
    > just depend on javafx.controls and you don't mention 
    > javafx.controls:linux-x86_64 etc in your pom at all.
    > 
    > Unless I'm missing something, I don't see the problem (no need for 
    > having 12 dependencies instead of 2).
    > 
    > - Johan
    
    From johan.vos at gluonhq.com  Fri Oct 21 16:44:10 2022
    From: johan.vos at gluonhq.com (Johan Vos)
    Date: Fri, 21 Oct 2022 18:44:10 +0200
    Subject: Platform independent deployment
    In-Reply-To: 
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
     <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
     
     
     
     
     
     <400dccca-1f3b-4221-4347-2eaf8bb2f14a@s4p.de>
     
     
    Message-ID: 
    
    On Fri, Oct 21, 2022 at 6:06 PM Thomas Reinhardt 
    wrote:
    
    >
    > I think there is a misunderstanding here.
    >
    > What I want is basically create a zip that contains all needed jars and
    > run my application via "java -jar myapp.jar".
    
    
    This assumes that end users have at least a JRE on their local machine,
    which is already platform dependent. So they already download platform
    dependent code, hence it makes sense to me that they also download platform
    dependent zips, no?
    But if you go one step beyond requiring a JRE, you could also require
    maven to be available locally, in which case you let maven download the
    required parts (and only those parts required at runtime for your specific
    OS).
    The even better option here, imho, is to use jpackage (which can also be
    invoked from the plugins) to build platform-specific applications.
    
    
    > Of course there exists a
    > proper exe for windows users etc but thats besides the point. The one
    > thing the whole discussion is about is that I want to use the same zip
    > for all supported platforms (linux and windows in my case). What I
    > specifically NOT want is platform dependent zips. We have a very large
    > number of dependencies and the size of the whole thing (zipped) is about
    > 300MB. Having os specific versions would basically double that size for
    > our nexus instance, the download server etc.
    >
    
    I agree different versions would lead to more disk space on your nexus if
    you have 300MB jars. But apart from that, a single version would be
    annoying for users. They will have to download OS-specific libraries that
    are useless on their machines. For example, the native libs required for
    webkit are about 100MB. If you are going to bundle only the desktop ones
    (linux/win/mac arm/amd) you will have about 600MB already, of which 500MB
    is useless. Apart from requiring more diskspace for the end user, it will
    also increase the data transfer drastically.
    
    >
    > To be clear: the whole thing has to run on the classpath and is not
    > modularized (yet). Not what we want but what other dependencies are
    > forcing us to do.
    >
    
    That's fine -- happens often and not much you can do about it.
    
    >
    >
    > If I read the source correctly, the javafx-maven-plugin can either run
    > the application on my dev machine (why?) or create platform dependent
    > runtime images.
    > Am I missing something?
    >
    
    I still think the platform dependent runtime images (or the platform
    independent pom files) are the best approach. The only drawback I see is
    that indeed those images will then consume disk space on your nexus.
    
    
    > Seriously, isn't the sole existence of this plugin an indicator that
    > something is not quite right?
    >
    
    I don't see why. The goal of OpenJFX is to deliver the JavaFX code, which
    has a platform independent Java API and a number of implementations that
    contain a mix of platform independent Java code, platform dependent Java
    code, and platform dependent native code. This is the same situation as in
    OpenJDK.
    The plugins allow developers to deal with this relative complexity, but
    they solve a different problem. Since there are different requirements for
    different environments (e.g. some environments do not allow a JVM), there
    is no one size fits all. The javafx maven/gradle plugins in github mainly
    help developer use cases, and allow for bundling required mods with jlink
    in a platform-dependent bundle. If you go one step further, the Gluon
    plugins allow to pre-compile everything ahead of time and bundle everything
    in a binary that doesn't require/bundles a JVM (see
    https://github.com/gluonhq/gluonfx-maven-plugin and
    https://github.com/gluonhq/gluonfx-gradle-plugin).
    We don't have these plugins because the concepts in OpenJFX are broken, but
    they make life of a large number of developers and users easier. Granted,
    they don't cover all use cases. The specific case you talk about where you
    want to have a zip with all native libs combined is not out of the box
    covered, but it can easily be added -- I just don't think this usecase is
    very common for the reasons I already mentioned.
    
    >
    > Again, apologies if this sounds personal or unfriendly in any way. Not
    > intended at all.
    >
    
    Don't worry, no problem at all, it's good to ask and discuss those things!
    
    
    >
    >
    >         -Thomas
    >
    >
    >
    >
    >
    >
    >
    > On 21/10/2022 11:54, Johan Vos wrote:
    > >
    > >
    > > On Fri, Oct 21, 2022 at 11:38 AM Thomas Reinhardt
    > > > wrote:
    > >
    > >
    > >     As for the javafx-maven-plugin: I don't see how this would help
    > >     here. It
    > >     states on the github page "JavaFX dependencies are added as usual".
    > >
    > >
    > > ... but you don't have to add a classifier (or an exhaustive list of
    > > classifiers) as that is what the plugin takes care about. Hence: you
    > > just depend on javafx.controls and you don't mention
    > > javafx.controls:linux-x86_64 etc in your pom at all.
    > >
    > > Unless I'm missing something, I don't see the problem (no need for
    > > having 12 dependencies instead of 2).
    > >
    > > - Johan
    >
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From john at status6.com  Fri Oct 21 17:19:14 2022
    From: john at status6.com (John Neffenger)
    Date: Fri, 21 Oct 2022 10:19:14 -0700
    Subject: Platform independent deployment
    In-Reply-To: <400dccca-1f3b-4221-4347-2eaf8bb2f14a@s4p.de>
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
     <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
     
     
     
     
     
     <400dccca-1f3b-4221-4347-2eaf8bb2f14a@s4p.de>
    Message-ID: 
    
    On 10/21/22 2:36 AM, Thomas Reinhardt wrote:
    > And after a little digging I think half of the artifacts should not have been platform dependent in the first place:
    
    Indeed. See the last paragraph of the following pull request comment:
    
    jgneff commented on Nov 22, 2021
    https://github.com/openjdk/jfx/pull/446#issuecomment-976010424
    
    reproduced below:
    
    One bonus with reproducible builds is that you can compare across 
    systems. For example, the following JAR files are now identical across 
    operating systems and hardware architectures, just as one would expect:
    
         javafx.base.jar
         javafx.fxml.jar
         javafx.swing.jar
         javafx-swt.jar
         javafx.web.jar
    
    I think the 'javafx.controls.jar' file will be identical as well once 
    the build path problem is fixed (item #4 at the top of that pull request).
    
    John
    
    
    From john.hendrikx at gmail.com  Fri Oct 21 19:27:55 2022
    From: john.hendrikx at gmail.com (John Hendrikx)
    Date: Fri, 21 Oct 2022 21:27:55 +0200
    Subject: Platform independent deployment
    In-Reply-To: 
    References: <22f535c5-186e-358f-f86f-587c41061180@s4p.de>
     
     <947373e8-8317-b215-dbc4-791080432bff@s4p.de>
     <1972d3c1-c5cd-07dd-4c48-88d35656bb12@gmail.com>
     
     
     
     
     
     <400dccca-1f3b-4221-4347-2eaf8bb2f14a@s4p.de>
     
     
    Message-ID: <412cd227-dc49-5467-b950-1b1b32b50e68@gmail.com>
    
    On 21/10/2022 18:04, Thomas Reinhardt wrote:
    >
    > I think there is a misunderstanding here.
    >
    > What I want is basically create a zip that contains all needed jars 
    > and run my application via "java -jar myapp.jar". Of course there 
    > exists a proper exe for windows users etc but thats besides the point. 
    > The one thing the whole discussion is about is that I want to use the 
    > same zip for all supported platforms (linux and windows in my case). 
    > What I specifically NOT want is platform dependent zips. We have a 
    > very large number of dependencies and the size of the whole thing 
    > (zipped) is about 300MB. Having os specific versions would basically 
    > double that size for our nexus instance, the download server etc.
    
    This is exactly how I package my stuff.? You get a jar, with everything 
    in it which runs on all the platforms.
    
    I include these dependencies in Maven, AFAIK the rest isn't platfrom 
    dependent:
    
     ??? 
     ????? org.openjfx
     ????? javafx-graphics
     ????? win
     ??? 
     ??? 
     ????? org.openjfx
     ????? javafx-graphics
     ????? linux
     ??? 
     ??? 
     ????? org.openjfx
     ????? javafx-graphics
     ????? mac
     ??? 
    
    Then just package the whole bunch with the shade plugin:
    
     ????? 
     ??????? org.apache.maven.plugins
     ??????? maven-shade-plugin
     ??????? 
     ????????? 
     ??????????? 
     ????????????? shade
     ??????????? 
     ??????????? 
    true
     ????????????? 
     ??????????????? 
    hs.mediasystem.local.client.NonJavaFXFrontEndRunner
     ??????????????? 
     ????????????? 
     ??????????? 
     ????????? 
     ??????? 
     ????? 
    
    This yields a fat jar.? When you unzip it, all JavaFX classes, all 
    native libraries etc. are included, and it runs without any special 
    command line arguments.
    
    >
    > To be clear: the whole thing has to run on the classpath and is not 
    > modularized (yet). Not what we want but what other dependencies are 
    > forcing us to do.
    
    Nor is mine, and I never intend to modularize it, and it will never be 
    needed as long as there are source files.
    
    I even use this to avoid the modularize startup that JavaFX seemingly 
    enforces:
    
     ??? public class NonJavaFXFrontEndRunner {
     ??? ? public static void main(String[] args) {
     ??? ??? FrontEndRunner.main(args);? // Workaround for javafx.graphics 
    named module check when bundled as fat jar
     ??? ? }
     ??? }
    
    Where FrontEndRunner has another main entry point which implements 
    Application:
    
     ??? public class FrontEndRunner extends Application {
    
     ??? ? public static void main(String[] args) {
     ??? ??? System.setProperty("prism.lcdtext", "false");
    
     ??? ??? Application.launch(args);
     ??? ? }
    
    >
    > If I read the source correctly, the javafx-maven-plugin can either run 
    > the application on my dev machine (why?) or create platform dependent 
    > runtime images.
    > Am I missing something?
    >
    >
    > Seriously, isn't the sole existence of this plugin an indicator that 
    > something is not quite right?
    
    I'm not sure what, I never needed this plugin, and I agree, needing a 
    specific plugin for a dependency would be odd, but turns out you don't 
    need it :)
    
    --John
    
    
    
    From angorya at openjdk.org  Fri Oct 21 20:24:07 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Fri, 21 Oct 2022 20:24:07 GMT
    Subject: RFR: 8294809: ListenerHelper for managing and disconnecting
     listeners [v6]
    In-Reply-To: 
    References: 
    Message-ID: <3ENx-4GXr9i0N08c2eeDPzOOEDhJVGG5RWgHg4t_S9w=.e65f9e55-b2e1-4cd5-936b-85442cdbacff@github.com>
    
    > Introduction
    > 
    > There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class).
    > 
    > This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance
    > https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java
    > 
    > Proposal
    > 
    > It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which:
    > 
    > - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc.
    > - keeps track of the listeners and the corresponding ObservableValues
    > - provides a single disconnect() method to remove all the listeners in one go.
    > - optionally, it should be possible to add a lambda (Runnable) to a group of properties
    > - optionally, there should be a boolean flag to fire the lambda immediately
    > - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method
    > 
    > Make it Public Later
    > 
    > Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later.
    > 
    > Where It Will Be Useful
    > 
    > [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin"
    > and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler.
    > 
    > https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft
    > 
    > https://github.com/openjdk/jfx/pull/914
    
    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 20 additional commits since the last revision:
    
     - 8294809: map change listener
     - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper
     - 8294809: generics
     - 8294809: is alive
     - Revert "8294809: removed weak listeners support"
       
       This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18.
     - 8294809: removed weak listeners support
     - 8294809: use weak reference correctly this time
     - 8294809: tests
     - 8294809: remove
     - 8294809: change listener with callback
     - ... and 10 more: https://git.openjdk.org/jfx/compare/ad0c8cb8...7a1fa625
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/908/files
      - new: https://git.openjdk.org/jfx/pull/908/files/71ca35ee..7a1fa625
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=05
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=04-05
    
      Stats: 164 lines in 90 files changed: 61 ins; 11 del; 92 mod
      Patch: https://git.openjdk.org/jfx/pull/908.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/908/head:pull/908
    
    PR: https://git.openjdk.org/jfx/pull/908
    
    From ltorokrl at gmail.com  Sat Oct 22 11:36:50 2022
    From: ltorokrl at gmail.com (=?UTF-8?B?TGFkaXNsYXYgVMO2csO2aw==?=)
    Date: Sat, 22 Oct 2022 13:36:50 +0200
    Subject: javafx.preloader property
    Message-ID: 
    
    Hi,
    
    the use of the javafx.preloader property to properly use Preloader
    after JavaFx 9 should be documented.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From info at michaelhoffer.de  Sat Oct 22 16:10:45 2022
    From: info at michaelhoffer.de (Michael Hoffer)
    Date: Sat, 22 Oct 2022 18:10:45 +0200
    Subject: Fixing TouchEvents on modern Windows
    Message-ID: 
    
    Hi all,
    
    it's been a while since I was active on this mailing list. Sorry for the
    long silence. I am still working with JavaFX and generally very happy.
    
    However, a couple of days ago I noticed that direct touch support on
    Windows is broken on a surprisingly large number of devices since JavaFX
    16. I tracked the problem down to a relatively naive attempt at
    distinguishing *direct* touch events (finger based touch) from *indirect*
    stylus/pen based touch events (which are basically just mouse events) which
    was introduced as part of fixing https://bugs.openjdk.org/browse/JDK-8249737
    .
    
    The problem is that on a large number of touch devices without a pen, touch
    events are always reported as indirect. Examples are iiyama touch monitors
    (capacitive, multitouch) for Windows PCs .Those devices and even most
    Surface devices since the Surface Pro 3 (verified with Surface Pro 4, 7 and
    Studio) fall under that category.
    
    The unfortunate result is that only gesture based multitouch works as
    expected. I created a PR on GitHub that fixes the issue by introducing a
    boolean property to the Scene class. The proposed interface can be seen
    here:
    https://github.com/openjdk/jfx/pull/927/commits/0caf15712a7e2e4492e6c2b5bb13417a514e41a5
    
    I tried to explain the reasons for this API proposal here:
    https://github.com/openjdk/jfx/pull/927
    
    I fully understand that such a change cannot be introduced without prior
    discussion. But since it's very urgent for our company to get this fixed, I
    created the PR anyway. Just as a public draft. And we are documenting
    the changes that we introduced in our JFX build. In the meantime, our
    company will roll out a custom JFX build with the proposed API.
    
    What are your thoughts? Do you agree with the proposed API? Would you
    prefer a different solution?
    
    Regards,
    Michael
    
    
    
    
    
    
    --
    
    
    
    
    
             
    
    
    
    
    Dr. Michael Hoffer
    
    Website:  www.mihosoft.eu
    
    Email:      info at michaelhoffer.de
    
    
    
    [image: social-icon-twitter] 
    
    [image: social-icon-linkedin] 
    
    [image: social-icon-github] 
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From tsayao at openjdk.org  Sat Oct 22 23:35:50 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Sat, 22 Oct 2022 23:35:50 GMT
    Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
     [v6]
    In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    Message-ID: <3ISEOBcrh-nFqs1NIFIrRg-swL0UFmTl3-COB3rRFxo=.1c557393-06d8-479a-97d0-687929fb80a4@github.com>
    
    > This cleans size and positioning code, reducing special cases, code complexity and size.
    > 
    > Changes:
    > 
    > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    > - frame extents are received in process_property_notify;
    > - window geometry, min/max size are centralized in update_window_constraints and uses  `XSetWMNormalHints` because it supports initial position;
    > - window_configure: Changes can be requested directly to the window manager with `XReconfigureWMWindow` - it's compatible with `windowChangesMask`, `windowChanges`;
    > - request_focus uses `_NET_ACTIVE_WINDOW` directly as it does not seem to have focus stealing problems.
    > 
    > I have left some debug print statements which will be removed when we finish testing.
    
    Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
    
      Skip frame extents when zero
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/915/files
      - new: https://git.openjdk.org/jfx/pull/915/files/990c2245..0be4fca9
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=05
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=04-05
    
      Stats: 18 lines in 1 file changed: 3 ins; 0 del; 15 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From tsayao at openjdk.org  Sun Oct 23 01:16:53 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Sun, 23 Oct 2022 01:16:53 GMT
    Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
     [v7]
    In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    Message-ID: 
    
    > This cleans size and positioning code, reducing special cases, code complexity and size.
    > 
    > Changes:
    > 
    > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    > - frame extents are received in process_property_notify;
    > - window geometry, min/max size are centralized in update_window_constraints and uses  `XSetWMNormalHints` because it supports initial position;
    > - window_configure: Changes can be requested directly to the window manager with `XReconfigureWMWindow` - it's compatible with `windowChangesMask`, `windowChanges`;
    > - request_focus uses `_NET_ACTIVE_WINDOW` directly as it does not seem to have focus stealing problems.
    > 
    > I have left some debug print statements which will be removed when we finish testing.
    
    Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
    
      Fix initial size
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/915/files
      - new: https://git.openjdk.org/jfx/pull/915/files/0be4fca9..e8bfec02
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=06
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=05-06
    
      Stats: 65 lines in 2 files changed: 42 ins; 14 del; 9 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From jvos at openjdk.org  Sun Oct 23 16:57:43 2022
    From: jvos at openjdk.org (Johan Vos)
    Date: Sun, 23 Oct 2022 16:57:43 GMT
    Subject: [jfx17u] Integrated: 8277785: ListView scrollTo jumps to wrong
     location when CellHeight is changed
    In-Reply-To: 
    References: 
    Message-ID: <_N-WNcEbYmvyrxNmSRvkAWtBQrUsJ2L09INetfTSIr0=.3610a42a-0ec8-4506-8a59-72834ae6aa7d@github.com>
    
    On Thu, 20 Oct 2022 17:33:46 GMT, Johan Vos  wrote:
    
    > clean backport of 8277785: ListView scrollTo jumps to wrong location when CellHeight is?changed
    > 
    > Reviewed-by: kcr, fkirmaier, aghaisas
    
    This pull request has now been integrated.
    
    Changeset: e3c85a8b
    Author:    Johan Vos 
    URL:       https://git.openjdk.org/jfx17u/commit/e3c85a8b85087e963d0fcef66c40c8468f16f5c5
    Stats:     372 lines in 4 files changed: 332 ins; 19 del; 21 mod
    
    8277785: ListView scrollTo jumps to wrong location when CellHeight is changed
    
    Backport-of: b8302f64f49e746a8645020cb778a4f3e4f4b893
    
    -------------
    
    PR: https://git.openjdk.org/jfx17u/pull/86
    
    From tsayao at openjdk.org  Mon Oct 24 02:22:52 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Mon, 24 Oct 2022 02:22:52 GMT
    Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
     [v8]
    In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    Message-ID: <46jCMX94_y2Ozv2MwQ_jTw9-XwXV2j3pgDt-2Uf8nnQ=.2a0757aa-dd63-4896-b7fd-76fd9208341d@github.com>
    
    > This cleans size and positioning code, reducing special cases, code complexity and size.
    > 
    > Changes:
    > 
    > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    > - frame extents are received in process_property_notify;
    > - window geometry, min/max size are centralized in update_window_constraints and uses  `XSetWMNormalHints` because it supports initial position;
    > - window_configure: Changes can be requested directly to the window manager with `XReconfigureWMWindow` - it's compatible with `windowChangesMask`, `windowChanges`;
    > - request_focus uses `_NET_ACTIVE_WINDOW` directly as it does not seem to have focus stealing problems.
    > 
    > I have left some debug print statements which will be removed when we finish testing.
    
    Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
    
      Work
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/915/files
      - new: https://git.openjdk.org/jfx/pull/915/files/e8bfec02..051b6fe0
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=07
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=06-07
    
      Stats: 209 lines in 2 files changed: 41 ins; 78 del; 90 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From tsayao at openjdk.org  Mon Oct 24 02:29:15 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Mon, 24 Oct 2022 02:29:15 GMT
    Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
     [v9]
    In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    Message-ID: <_yAzujwi6LGS1GQYjP_DBcrFF4loMNNGJI0vWKaM2mg=.9ff874b9-516e-4782-9345-d4be7928d107@github.com>
    
    > This cleans size and positioning code, reducing special cases, code complexity and size.
    > 
    > Changes:
    > 
    > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    > - frame extents are received in process_property_notify;
    > - window geometry, min/max size are centralized in update_window_constraints and uses  `XSetWMNormalHints` because it supports initial position;
    > - window_configure: Changes can be requested directly to the window manager with `XReconfigureWMWindow` - it's compatible with `windowChangesMask`, `windowChanges`;
    > - request_focus uses `_NET_ACTIVE_WINDOW` directly as it does not seem to have focus stealing problems.
    > 
    > I have left some debug print statements which will be removed when we finish testing.
    
    Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
    
     - I'm going to sleep
     - Fix request_focus
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/915/files
      - new: https://git.openjdk.org/jfx/pull/915/files/051b6fe0..479630c6
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=08
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=07-08
    
      Stats: 19 lines in 1 file changed: 0 ins; 17 del; 2 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From tsayao at openjdk.org  Mon Oct 24 14:02:04 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Mon, 24 Oct 2022 14:02:04 GMT
    Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
     [v10]
    In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    Message-ID: 
    
    > This cleans size and positioning code, reducing special cases, code complexity and size.
    > 
    > Changes:
    > 
    > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    > - window geometry, min/max size are centralized in update_window_constraints;
    > - Frame extents (the window decoration size used for "total window size":
    >     - frame extents are received in process_property_notify;
    >     - removed quirks in java code;
    >     - When received, call set_bounds again to adjust the size;
    > - `gtk_window_set_focus_on_map` to fix https://bugs.openjdk.org/browse/JDK-8292922
    > - `windowGeometry->final_width.type`, `windowGeometry->final_height.type` simplified to `windowGeometry->bounds_type` because there's no mixed size orientation (i think :));
    > - `requested_bounds` removed - not necessary;
    > - `window_configure` incorporated in set_bounds with `gtk_window_move` and `gtk_window_resize`
    
    Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
    
      Static Atoms
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/915/files
      - new: https://git.openjdk.org/jfx/pull/915/files/479630c6..0871f07d
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=09
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=08-09
    
      Stats: 18 lines in 1 file changed: 7 ins; 9 del; 2 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From tsayao at openjdk.org  Mon Oct 24 14:09:06 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Mon, 24 Oct 2022 14:09:06 GMT
    Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
     [v11]
    In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    Message-ID: 
    
    > This cleans size and positioning code, reducing special cases, code complexity and size.
    > 
    > Changes:
    > 
    > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    > - window geometry, min/max size are centralized in update_window_constraints;
    > - Frame extents (the window decoration size used for "total window size":
    >     - frame extents are received in process_property_notify;
    >     - removed quirks in java code;
    >     - When received, call set_bounds again to adjust the size;
    > - `gtk_window_set_focus_on_map` to fix https://bugs.openjdk.org/browse/JDK-8292922
    > - `windowGeometry->final_width.type`, `windowGeometry->final_height.type` simplified to `windowGeometry->bounds_type` because there's no mixed size orientation (i think :));
    > - `requested_bounds` removed - not necessary;
    > - `window_configure` incorporated in set_bounds with `gtk_window_move` and `gtk_window_resize`
    
    Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
    
      Restore function location
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/915/files
      - new: https://git.openjdk.org/jfx/pull/915/files/0871f07d..881f816b
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=10
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=09-10
    
      Stats: 72 lines in 1 file changed: 36 ins; 36 del; 0 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From tsayao at openjdk.org  Mon Oct 24 14:46:13 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Mon, 24 Oct 2022 14:46:13 GMT
    Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
     [v12]
    In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    Message-ID: 
    
    > This cleans size and positioning code, reducing special cases, code complexity and size.
    > 
    > Changes:
    > 
    > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    > - window geometry, min/max size are centralized in update_window_constraints;
    > - Frame extents (the window decoration size used for "total window size":
    >     - frame extents are received in process_property_notify;
    >     - removed quirks in java code;
    >     - When received, call set_bounds again to adjust the size;
    > - `gtk_window_set_focus_on_map` to fix https://bugs.openjdk.org/browse/JDK-8292922
    > - `windowGeometry->final_width.type`, `windowGeometry->final_height.type` simplified to `windowGeometry->bounds_type` because there's no mixed size orientation (i think :));
    > - `requested_bounds` removed - not necessary;
    > - `window_configure` incorporated in set_bounds with `gtk_window_move` and `gtk_window_resize`
    
    Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
    
      Ops, forgot to save size
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/915/files
      - new: https://git.openjdk.org/jfx/pull/915/files/881f816b..6e69f7c0
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=11
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=10-11
    
      Stats: 14 lines in 2 files changed: 13 ins; 0 del; 1 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From tsayao at openjdk.org  Mon Oct 24 14:51:55 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Mon, 24 Oct 2022 14:51:55 GMT
    Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
     [v13]
    In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    Message-ID: 
    
    > This cleans size and positioning code, reducing special cases, code complexity and size.
    > 
    > Changes:
    > 
    > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    > - window geometry, min/max size are centralized in update_window_constraints;
    > - Frame extents (the window decoration size used for "total window size":
    >     - frame extents are received in process_property_notify;
    >     - removed quirks in java code;
    >     - When received, call set_bounds again to adjust the size;
    > - `gtk_window_set_focus_on_map` to fix https://bugs.openjdk.org/browse/JDK-8292922
    > - `windowGeometry->final_width.type`, `windowGeometry->final_height.type` simplified to `windowGeometry->bounds_type` because there's no mixed size orientation (i think :));
    > - `requested_bounds` removed - not necessary;
    > - `window_configure` incorporated in set_bounds with `gtk_window_move` and `gtk_window_resize`
    
    Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
    
      Raise window on map
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/915/files
      - new: https://git.openjdk.org/jfx/pull/915/files/6e69f7c0..1e4afbe9
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=12
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=11-12
    
      Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From tsayao at openjdk.org  Mon Oct 24 15:00:05 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Mon, 24 Oct 2022 15:00:05 GMT
    Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
     [v13]
    In-Reply-To: 
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
     
    Message-ID: <-gNps1orM6vnCFTmQm4rPdRWbbIwxAj4io23JuHxV54=.c4e5ba17-62b6-484b-a86b-ca2b9cb9ea61@github.com>
    
    On Mon, 24 Oct 2022 14:51:55 GMT, Thiago Milczarek Sayao  wrote:
    
    >> This cleans size and positioning code, reducing special cases, code complexity and size.
    >> 
    >> Changes:
    >> 
    >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    >> - window geometry, min/max size are centralized in update_window_constraints;
    >> - Frame extents (the window decoration size used for "total window size":
    >>     - frame extents are received in process_property_notify;
    >>     - removed quirks in java code;
    >>     - When received, call set_bounds again to adjust the size;
    >> - `gtk_window_set_focus_on_map` to fix https://bugs.openjdk.org/browse/JDK-8292922 and re-fix  https://bugs.openjdk.org/browse/JDK-8271054
    >> - `windowGeometry->final_width.type`, `windowGeometry->final_height.type` simplified to `windowGeometry->bounds_type` because there's no mixed size orientation (i think :));
    >> - `requested_bounds` removed - not necessary;
    >> - `window_configure` incorporated in set_bounds with `gtk_window_move` and `gtk_window_resize`
    >
    > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   Raise window on map
    
    @johanvos I think is coming into shape. If you want you can take a look.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From swpalmer at gmail.com  Mon Oct 24 19:07:01 2022
    From: swpalmer at gmail.com (Scott Palmer)
    Date: Mon, 24 Oct 2022 15:07:01 -0400
    Subject: Support for Ligatures
    Message-ID: 
    
    Something I noticed while experimenting with RichTextFX, when I set it to use Fira Code for the font, like I do in NetBeans, I see that JavaFX doesn't support ligatures.  I found this issue that's been around for quite some time:
    https://bugs.openjdk.org/browse/JDK-8091616?
    
    Is there any drive to get this implemented within the next few releases?  I would help, but unfortunately I suspect it will take more time than I can commit to it.
    I?m hoping that eliminating some of the remaining gaps between what JavaFX supports and Swing supports would be a priority, as it removes some barriers to JavaFX adoption... but maybe not?
    
    Regards,
    
    Scott
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: jira-favicon-hires.png
    Type: image/png
    Size: 1085 bytes
    Desc: not available
    URL: 
    
    From philip.race at oracle.com  Mon Oct 24 19:43:33 2022
    From: philip.race at oracle.com (Philip Race)
    Date: Mon, 24 Oct 2022 12:43:33 -0700
    Subject: Support for Ligatures
    In-Reply-To: 
    References: 
    Message-ID: <8f240376-8f60-3432-3937-31d4d498647c@oracle.com>
    
    FX does (of course) support required ligatures, meaning those without 
    which some script (eg Arabic)
    can't even be rendered.
    
    But that is implementation, no API.
    
    So this is about adding an API to request optional ligatures - and other 
    OpenType features.
    For example I think we'd want to support things like small caps etc.
    
    Of course we'd need to make sure all the measuring code is up to that .. 
    and BTW
    the APIs to do measurement probably should be in the queue ahead of this ..
    
    And I am not sure about just an API to request ligatures without an API 
    to query
    if ligatures are available for a font. However that may turn out to be 
    tricky for a
    few reasons, but we should at least study it.
    
    And to try to answer the "when" question .. it is on a "desired" list in 
    my head and maybe
    even on a wiki somewhere .. but no concrete timetable exists.
    
    But it is good to get feedback like this so we know it is interesting to 
    developers.
    
    -phil.
    
    On 10/24/22 12:07 PM, Scott Palmer wrote:
    > Something I noticed while experimenting with RichTextFX, when I set it 
    > to use Fira Code for the font, like I do in NetBeans, I see that 
    > JavaFX doesn't support ligatures. ?I found this issue that's been 
    > around for quite some time:
    > [JDK-8091616] Prism: font: ligature and kerning support - Java Bug 
    > System 
    > bugs.openjdk.org 
    > 	jira-favicon-hires.png 
    >
    > 
    >
    > Is there any drive to get this implemented within the next few 
    > releases? ?I would help, but unfortunately I suspect it will take more 
    > time than I can commit to it.
    > I?m hoping that eliminating some of the remaining gaps between what 
    > JavaFX supports and Swing supports would be a priority, as it removes 
    > some barriers to JavaFX adoption... but maybe not?
    >
    > Regards,
    >
    > Scott
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: jira-favicon-hires.png
    Type: image/png
    Size: 1085 bytes
    Desc: not available
    URL: 
    
    From tsayao at openjdk.org  Tue Oct 25 00:52:07 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Tue, 25 Oct 2022 00:52:07 GMT
    Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
     [v14]
    In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    Message-ID: 
    
    > This cleans size and positioning code, reducing special cases, code complexity and size.
    > 
    > Changes:
    > 
    > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    > - window geometry, min/max size are centralized in update_window_constraints;
    > - Frame extents (the window decoration size used for "total window size":
    >     - frame extents are received in process_property_notify;
    >     - removed quirks in java code;
    >     - When received, call set_bounds again to adjust the size;
    > - `gtk_window_set_focus_on_map` to fix https://bugs.openjdk.org/browse/JDK-8292922 and re-fix  https://bugs.openjdk.org/browse/JDK-8271054
    > - `windowGeometry->final_width.type`, `windowGeometry->final_height.type` simplified to `windowGeometry->bounds_type` because there's no mixed size orientation (i think :));
    > - `requested_bounds` removed - not necessary;
    > - `window_configure` incorporated in set_bounds with `gtk_window_move` and `gtk_window_resize`
    
    Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
    
      Allow to set content size + partial window size (only width or height)
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/915/files
      - new: https://git.openjdk.org/jfx/pull/915/files/1e4afbe9..b9cd818e
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=13
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=12-13
    
      Stats: 191 lines in 2 files changed: 90 ins; 78 del; 23 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From tsayao at openjdk.org  Tue Oct 25 00:54:29 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Tue, 25 Oct 2022 00:54:29 GMT
    Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
     [v15]
    In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    Message-ID: 
    
    > This cleans size and positioning code, reducing special cases, code complexity and size.
    > 
    > Changes:
    > 
    > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    > - window geometry, min/max size are centralized in update_window_constraints;
    > - Frame extents (the window decoration size used for "total window size":
    >     - frame extents are received in process_property_notify;
    >     - removed quirks in java code;
    >     - When received, call set_bounds again to adjust the size;
    > - `gtk_window_set_focus_on_map` to fix https://bugs.openjdk.org/browse/JDK-8292922 and re-fix  https://bugs.openjdk.org/browse/JDK-8271054
    > - `windowGeometry->final_width.type`, `windowGeometry->final_height.type` simplified to `windowGeometry->bounds_type` because there's no mixed size orientation (i think :));
    > - `requested_bounds` removed - not necessary;
    > - `window_configure` incorporated in set_bounds with `gtk_window_move` and `gtk_window_resize`
    
    Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
    
      Style
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/915/files
      - new: https://git.openjdk.org/jfx/pull/915/files/b9cd818e..3b3f53e2
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=14
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=13-14
    
      Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From tsayao at openjdk.org  Tue Oct 25 00:56:46 2022
    From: tsayao at openjdk.org (Thiago Milczarek Sayao)
    Date: Tue, 25 Oct 2022 00:56:46 GMT
    Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
     [v16]
    In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
    Message-ID: 
    
    > This cleans size and positioning code, reducing special cases, code complexity and size.
    > 
    > Changes:
    > 
    > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
    > - window geometry, min/max size are centralized in update_window_constraints;
    > - Frame extents (the window decoration size used for "total window size":
    >     - frame extents are received in process_property_notify;
    >     - removed quirks in java code;
    >     - When received, call set_bounds again to adjust the size;
    > - `gtk_window_set_focus_on_map` to fix https://bugs.openjdk.org/browse/JDK-8292922 and re-fix  https://bugs.openjdk.org/browse/JDK-8271054
    > - `windowGeometry->final_width.type`, `windowGeometry->final_height.type` simplified to `windowGeometry->bounds_type` because there's no mixed size orientation (i think :));
    > - `requested_bounds` removed - not necessary;
    > - `window_configure` incorporated in set_bounds with `gtk_window_move` and `gtk_window_resize`
    
    Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
    
      Remove debug statement
    
    -------------
    
    Changes:
      - all: https://git.openjdk.org/jfx/pull/915/files
      - new: https://git.openjdk.org/jfx/pull/915/files/3b3f53e2..52cb9af5
    
    Webrevs:
     - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=15
     - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=14-15
    
      Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
      Patch: https://git.openjdk.org/jfx/pull/915.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915
    
    PR: https://git.openjdk.org/jfx/pull/915
    
    From swpalmer at gmail.com  Tue Oct 25 02:25:18 2022
    From: swpalmer at gmail.com (Scott Palmer)
    Date: Mon, 24 Oct 2022 22:25:18 -0400
    Subject: Support for Ligatures
    In-Reply-To: <8f240376-8f60-3432-3937-31d4d498647c@oracle.com>
    References: 
     <8f240376-8f60-3432-3937-31d4d498647c@oracle.com>
    Message-ID: <745B02B6-B3F5-496E-960D-A24AE3C8BFE9@gmail.com>
    
    I guess everything you?ve written below about querying and requesting features still falls into the hole of ?stuff we could do with Swing, but can?t do with JavaFX?.  I don?t use Swing anymore, but every once in a while I run into one of these issues. There are workarounds for some, like NSMenuFX to get proper menu support on macOS, or using AWT Desktop support in combination with JavaFX to get the missing support for the system tray, dock, opening documents with the OS-defined default handler, etc... but it?s less than ideal.   However, this issue doesn?t appear to have any workaround.
    
    I did a quick search in the JavaFX code for ligature support and it seems there is quite a bit of incomplete support in many parts of the font processing.  E.g. com.sun.javafx.scene.control.skin.Utils contains the commented out block that appears to be from older AWT code:
    
        private static boolean requiresComplexLayout(Font font, String string) {
            /*        Map attrs = font.getAttributes();
               if (contains(attrs, KERNING, KERNING_ON) ||
               contains(attrs, LIGATURES, LIGATURES_ON) ||
               (attrs.containsKey(TRACKING) && attrs.get(TRACKING) != null)) {
               return true;
               }
               return isComplexLayout(string.toCharArray(), 0, string.length());
             */
            return false;
        }
    
    So complexLayout is always ?false', which is good because where it is used the path for 'true' looks like:
            if (complexLayout) {
                // TODO needs implementation
                return 0;
            } else {
    
    
    com.sun.javafx.font.FontResources defines a bunch of constants related to ligatures, but they don?t appear to be used anywhere.  Looks like they are intended for the value returned by getFeatures() in FontResource and PGFont.
    
    com.sun.javafx.font.PrismFont and the interface it implements PGFont (what does PG stand for?) defines a getFeatures method:
        /*
         * Returns the features the user has requested.
         * (kerning, ligatures, etc)
         */
        @Override public int getFeatures() {
            return features;
        }
    
    but features is always 0, with no means to set it.
    
    com.sun.javafx.text.GlyphLayout where ?features? is used in two places compares the features of Font to FontResource. PrismFont defaults to 0, and the PrismFontFile implementation of FontResource returns -1, so for GlyphLayout  the supported features are always ?everything? and the requested features are always ?nothing?, so boolean feature = false, always. This is used to compute ?complex? (initially false)
                        if (!complex) {
                            complex = feature || ScriptMapper.isComplexCharCode(codePoint);
                        }
    So ScriptMapper is the only thing really deciding what?s ?complex?? which seems to bring me back to what you?ve stated, that required ligatures like those needed for Arabic are supported.  Now I wonder if ?feature? was true would my Fira Code experiment render correctly or is there a lot more to it than that?
    
    It seems there is some otherwise ?dead? code already in place to support requesting these openType features.
    Is exposing an API to initialize the features of FontResource enough to get some meaningful results?
    
    I was going to try some experiments, but I?m unable to build OpenJFX on my Mac for some reason:
    
    > > Task :graphics:compileJava FAILED
    > You specified both --module-source-path and a sourcepath. These options are mutually exclusive. Ignoring sourcepath.
    > error: option --upgrade-module-path cannot be used together with --release
    > Usage: javac  
    > use --help for a list of possible options
    
     (using JDK 17 running a simple ./gradlew)
    I didn?t have trouble when I last built it a couple years ago, so I?m not sure what?s changed.
    
    Cheers,
    
    Scott
    
    > On Oct 24, 2022, at 3:43 PM, Philip Race  wrote:
    > 
    > FX does (of course) support required ligatures, meaning those without which some script (eg Arabic)
    > can't even be rendered.
    > 
    > But that is implementation, no API.
    > 
    > So this is about adding an API to request optional ligatures - and other OpenType features.
    > For example I think we'd want to support things like small caps etc.
    > 
    > Of course we'd need to make sure all the measuring code is up to that .. and BTW
    > the APIs to do measurement probably should be in the queue ahead of this ..
    > 
    > And I am not sure about just an API to request ligatures without an API to query
    > if ligatures are available for a font. However that may turn out to be tricky for a
    > few reasons, but we should at least study it.
    > 
    > And to try to answer the "when" question .. it is on a "desired" list in my head and maybe
    > even on a wiki somewhere .. but no concrete timetable exists.
    > 
    > But it is good to get feedback like this so we know it is interesting to developers.
    > 
    > -phil.
    > 
    > On 10/24/22 12:07 PM, Scott Palmer wrote:
    >> Something I noticed while experimenting with RichTextFX, when I set it to use Fira Code for the font, like I do in NetBeans, I see that JavaFX doesn't support ligatures.  I found this issue that's been around for quite some time:
    >> https://bugs.openjdk.org/browse/JDK-8091616
    >> 
    >> Is there any drive to get this implemented within the next few releases?  I would help, but unfortunately I suspect it will take more time than I can commit to it.
    >> I?m hoping that eliminating some of the remaining gaps between what JavaFX supports and Swing supports would be a priority, as it removes some barriers to JavaFX adoption... but maybe not?
    >> 
    >> Regards,
    >> 
    >> Scott
    > 
    
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: 
    
    From almatvee at openjdk.org  Tue Oct 25 05:14:20 2022
    From: almatvee at openjdk.org (Alexander Matveev)
    Date: Tue, 25 Oct 2022 05:14:20 GMT
    Subject: RFR: 8294400: Provide media support for libavcodec version 59
    Message-ID: 
    
    - Added support for libavcodec 59.
     - libavcodec 59 removed several deprecated APIs and avplugin code was updated to use replacement APIs instead.
     - No changes to avplugin when used with 58 or below.
     - Note: Support for libavcodec 59 was added based on ffmpeg only. libav does not have version 59.
    
    -------------
    
    Commit messages:
     - 8294400: Provide media support for libavcodec version 59
    
    Changes: https://git.openjdk.org/jfx/pull/932/files
     Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=932&range=00
      Issue: https://bugs.openjdk.org/browse/JDK-8294400
      Stats: 138 lines in 9 files changed: 107 ins; 0 del; 31 mod
      Patch: https://git.openjdk.org/jfx/pull/932.diff
      Fetch: git fetch https://git.openjdk.org/jfx pull/932/head:pull/932
    
    PR: https://git.openjdk.org/jfx/pull/932
    
    From duke at openjdk.org  Tue Oct 25 07:58:52 2022
    From: duke at openjdk.org (eduardsdv)
    Date: Tue, 25 Oct 2022 07:58:52 GMT
    Subject: RFR: 8295324: JavaFX: Blank pages when printing [v2]
    In-Reply-To: 
    References: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com>
     
    Message-ID: 
    
    On Mon, 17 Oct 2022 07:12:00 GMT, eduardsdv  wrote:
    
    >> This fixes a race condition between application and 'Print Job Thread' threads when printing.
    >> 
    >> The race condition occurs when application thread calls `endJob()`, which in effect sets the `jobDone` flag to true,
    >> and when the 'Print Job Thread' thread was in the `synchronized` block in `waitForNextPage()` at that time.
    >> The 'Print Job Thread' thread checks `jobDone` flag after exiting the `synchronized` block and, if it is true, skips the last page.
    >> 
    >> In this fix, not only the `jobDone` is checked, but also that there is no other page to be printed.
    >> It was also needed to introduce a new flag 'jobCanceled', to skip the page if the printing was canceled by 'cancelJob()'.
    >
    > eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   8295324: Fix race condition in junit test
    
    It seems that not all errors were fixed with this PR. Yesterday, a blank page was printed again. I will analyze what this can be due to.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/916
    
    From kcr at openjdk.org  Tue Oct 25 13:31:55 2022
    From: kcr at openjdk.org (Kevin Rushforth)
    Date: Tue, 25 Oct 2022 13:31:55 GMT
    Subject: RFR: 8294400: Provide media support for libavcodec version 59
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Tue, 25 Oct 2022 05:07:05 GMT, Alexander Matveev  wrote:
    
    > - Added support for libavcodec 59.
    >  - libavcodec 59 removed several deprecated APIs and avplugin code was updated to use replacement APIs instead.
    >  - No changes to avplugin when used with 58 or below.
    >  - Note: Support for libavcodec 59 was added based on ffmpeg only. libav does not have version 59.
    
    I did a successful test build, but I don't currently have a system with libav59 libraries to test it on.
    
    The fix looks good to me with one exception. You also need to add an entry for `"avplugin-ffmpeg-59"` in the [NativeMediaManager constructor](https://github.com/openjdk/jfx/blob/bb4cead00e952484896191ca0e41f1608ae5b41e/modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/NativeMediaManager.java#L127).
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/932
    
    From jhendrikx at openjdk.org  Tue Oct 25 17:25:02 2022
    From: jhendrikx at openjdk.org (John Hendrikx)
    Date: Tue, 25 Oct 2022 17:25:02 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: <_fi-BrwjWfj-FkbfmYHHEmuSv0M6CJ-K0BjY9qCdGGc=.f1741b60-c1d2-4c0b-840a-b76484fe206a@github.com>
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
     <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
     
     
     
     
     
     <4qaP2ODitUQ99yAAef-F-6edSEJ29yRDx8Jiw5I9ce4=.eee98893-f18d-4470-8ddd-63f4c25fbb73@github.com>
     
     
     <2P0ExaB_pX5lfgPySlj6i_f3fc0yIxYAcf8gMRfAweU=.0cd29c2c-7687-4079-bf5a-207d4d05f4b0@github.com>
     <_fi-BrwjWfj-FkbfmYHHEmuSv0M6CJ-K0BjY9qCdGGc=.f1741b60-c1d2-4c0b-840a-b76484fe206a@github.com>
    Message-ID: 
    
    On Wed, 19 Oct 2022 22:21:49 GMT, Michael Strau?  wrote:
    
    >> Thank you.  You do bring a good point - clearing the map.  There is some mild language warning about clearing the map in javadoc already, but perhaps `Node.getProperties().clear()` should be forbidden (throw an IOE?).  
    >> 
    >> Also, the devs risk unexpected side effects if they try to use Strings as keys, due to possible collision with keys used by FX internals.
    >> 
    >> And, of course, the API does not preclude storing properties in `getProperties()`, and FX is already doing it, as illustrated by ButtonBarSkin:136 (perhaps more, I did not perform an exhaustive check).
    >
    >> Thank you. You do bring a good point - clearing the map. There is some mild language warning about clearing the map in javadoc already, but perhaps `Node.getProperties().clear()` should be forbidden (throw an IOE?).
    > 
    > A map can also be cleared with `Map.keySet().clear()`, or by enumerating its keys and removing each mapping one by one.
    > I don't think we can make the `getProperties()` map mutable, but at the same time safe to store final objects, while still respecting the `Map` contract.
    > 
    > Maybe we could have something like "hidden" keys, which are not enumerable and are never cleared by bulk operations.
    
    I think we can conclude here that this is a bit outside the scope of this PR.
    
    I certainly wouldn't be in favor of wrapping the property map to prevent clearing or any such thing; if we want to save space in `Node` this way, a dedicated structure that can't be accessed by users would be the way to go in my opinion.  The space we save should compensate for the pointer to this structure.  
    
    Before we'd even consider that though, I'd like to see where most memory is used in FX so efforts can be focused in areas where it would net the greatest effect.  For example, Properties are far more numerous than nodes.
    
    I noticed the use of the properties map by JavaFX itself -- the API states that this is the case, but I wonder if that's really required.  It might be better to keep these things in `WeakHashMap`, which is intended for this purpose instead of strewing these properties about over the various nodes which are then forced to instantiate the properties map vs just a single `WeakHashMap`.
    
    For example, `ButtonBarSkin` seems to do it to keep track of a variable amount of listeners. It effectively creates the properties map for each button added (assuming the map is usually empty) vs a single `WeakHashMap`; also it does this on an `ObservableList`.  This looks like something that could be a standard pattern (given an observable collection, automatically add/remove a given listener as the collection changes).  ReactFX had `Subscription#dynamic` for this.
    
    It also looks like `ButtonBarSkin` might be buggy, which it wouldn't have been if had used a `WeakHashMap`.  I see no `dispose` method and the listeners added don't use the `register` system, which means it can leave behind listeners that it stores in properties.  A new skin may conclude the listener on some buttons is already present.  Or an old skin may not get garbage collected.
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From jhendrikx at openjdk.org  Tue Oct 25 17:31:05 2022
    From: jhendrikx at openjdk.org (John Hendrikx)
    Date: Tue, 25 Oct 2022 17:31:05 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v2]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     
     <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
     
     
    Message-ID: 
    
    On Thu, 1 Sep 2022 17:38:39 GMT, Nir Lisker  wrote:
    
    >> Edit: I missed some nuance, below is the correct version.
    >> 
    >> There are three objects involved here: the parent observable, the new observable and the conditional.
    >> 
    >> What `when` should achieve is to make the new observable and conditional easy to garbage collect when the conditional is `false` (the parent observable is considered to be long lived so GC doesn't really apply there).  The conditional and new observable refer to each other so they must have a similar life cycle.
    >> 
    >>> What happens if they are GC'd and the conditional becomes `true` later?
    >> 
    >> This can't happen, the conditional refers to the new observable, their life cycles are tied to each other.
    >> 
    >> Strong references look like this when conditional is `true`:
    >> 
    >>       conditional <--> new observable <--> parent observable
    >> 
    >> When it is `false`:
    >> 
    >>      conditional <--> new observable --> parent observable
    >> 
    >> Conditional must have a similar life cycle as new observable if your purpose is to use `when` to break strong references to allow for GC.
    >
    > If I have a (dumb) method
    > 
    > 
    > void someMethod(ObservableValue longLivedProperty) {
    >     ObservableValue condition = new SimpleBooleanProperty(true);
    >     ObservableValue whenProperty = longLivedProperty.when(condition)
    > }
    > 
    > 
    > then shouldn't `condition` and `whenProperty` be eligible for GC even when `condition` holds `true`? If not, do I not get a memory leak because I can't change `condition` to `false` to allow garbage collection?
    
    @nlisker is this adequate, or should the docs reflect this better?
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From angorya at openjdk.org  Tue Oct 25 18:13:58 2022
    From: angorya at openjdk.org (Andy Goryachev)
    Date: Tue, 25 Oct 2022 18:13:58 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: 
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
     <3g49GfLKix3OJIeqhCFv8fN9btKVe1ldDmFjwBXYk_o=.0a96a91d-b662-4acc-92ba-5949d21fa91b@github.com>
     <-vln0rtTAeHa-0ma4FxHCqB6-_g_mQfUzq2EuvIDz24=.d52d42d5-a7dd-4303-b44a-cbd17566f676@github.com>
     
     
     
     
     
     <4qaP2ODitUQ99yAAef-F-6edSEJ29yRDx8Jiw5I9ce4=.eee98893-f18d-4470-8ddd-63f4c25fbb73@github.com>
     
     
     <2P0ExaB_pX5lfgPySlj6i_f3fc0yIxYAcf8gMRfAweU=.0cd29c2c-7687-4079-bf5a-207d4d05f4b0@github.com>
     <_fi-BrwjWfj-FkbfmYHHEmuSv0M6CJ-K0BjY9qCdGGc=.f1741b60-c1d2-4c0b-840a-b76484fe206a@github.com>
     
    Message-ID: 
    
    On Tue, 25 Oct 2022 17:22:44 GMT, John Hendrikx  wrote:
    
    >>> Thank you. You do bring a good point - clearing the map. There is some mild language warning about clearing the map in javadoc already, but perhaps `Node.getProperties().clear()` should be forbidden (throw an IOE?).
    >> 
    >> A map can also be cleared with `Map.keySet().clear()`, or by enumerating its keys and removing each mapping one by one.
    >> I don't think we can make the `getProperties()` map mutable, but at the same time safe to store final objects, while still respecting the `Map` contract.
    >> 
    >> Maybe we could have something like "hidden" keys, which are not enumerable and are never cleared by bulk operations.
    >
    > I think we can conclude here that this is a bit outside the scope of this PR.
    > 
    > I certainly wouldn't be in favor of wrapping the property map to prevent clearing or any such thing; if we want to save space in `Node` this way, a dedicated structure that can't be accessed by users would be the way to go in my opinion.  The space we save should compensate for the pointer to this structure.  
    > 
    > Before we'd even consider that though, I'd like to see where most memory is used in FX so efforts can be focused in areas where it would net the greatest effect.  For example, Properties are far more numerous than nodes.
    > 
    > I noticed the use of the properties map by JavaFX itself -- the API states that this is the case, but I wonder if that's really required.  It might be better to keep these things in `WeakHashMap`, which is intended for this purpose instead of strewing these properties about over the various nodes which are then forced to instantiate the properties map vs just a single `WeakHashMap`.
    > 
    > For example, `ButtonBarSkin` seems to do it to keep track of a variable amount of listeners. It effectively creates the properties map for each button added (assuming the map is usually empty) vs a single `WeakHashMap`; also it does this on an `ObservableList`.  This looks like something that could be a standard pattern (given an observable collection, automatically add/remove a given listener as the collection changes).  ReactFX had `Subscription#dynamic` for this.
    > 
    > It also looks like `ButtonBarSkin` might be buggy, which it wouldn't have been if had used a `WeakHashMap`.  I see no `dispose` method and the listeners added don't use the `register` system, which means it can leave behind listeners that it stores in properties.  A new skin may conclude the listener on some buttons is already present.  Or an old skin may not get garbage collected.
    
    FYI, `ButtonBarSkin` does have memory leak issues, which are addressed in https://github.com/openjdk/jfx/pull/921
    
    -------------
    
    PR: https://git.openjdk.org/jfx/pull/830
    
    From nlisker at openjdk.org  Tue Oct 25 21:13:05 2022
    From: nlisker at openjdk.org (Nir Lisker)
    Date: Tue, 25 Oct 2022 21:13:05 GMT
    Subject: RFR: 8290040: Provide simplified deterministic way to manage
     listeners [v6]
    In-Reply-To: <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
    References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
     <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>
    Message-ID: 
    
    On Thu, 29 Sep 2022 15:02:13 GMT, John Hendrikx  wrote:
    
    >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`.
    >> 
    >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here).
    >> 
    >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property:
    >> 
    >>      label.textProperty().bind(longLivedProperty.when(label::isShowingProperty));
    >> 
    >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing.  When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`.  A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along.
    >> 
    >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR.
    >> 
    >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out.
    >> 
    >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window.
    >
    > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
    > 
    >  - Merge remote-tracking branch 'origin/master' into
    >    feature/conditional-bindings
    >    
    >    # Conflicts:
    >    #	modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java
    >  - Fix review comments
    >  - Add missing new line
    >  - Small wording fixes
    >  - Update javadoc of "when" with better phrasing
    >  - Rename showing property to shown as it is already used in subclasses
    >  - Add conditional bindings to ObservableValue
    >  - Change explanatory comment to block comment
    >  - Fix bug where ObjectBinding returns null when revalidated immediately
    >    
    >    Introduced with the fluent bindings PR
    
    I personally think that it's fine to include the changes to `Node` here. It adds a good amount of value to the new method and can help avoid many memory leaks with this combination.
    
    modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1415:
    
    > 1413:      *
    > 1414:      * 

    Note that the {@code Node} does not need to be visible for this property > 1415: * to be {@code true}. I think that the definition of "shown" is important enough to make it the main focus of the description with something like: Indicates whether or not this {@code Node} is shown. A node is considered shown if it's part of a {@code Window} whose {@link shown #Window::showingProperty} is {@code true}. The {@link visibility #visibleProperty} of the node or its scene do not affect this property. I think that there's no need to repeat the showing conditions for a window. Also we need to be careful not to confuse `shown` with `showing`, which are properties on `ComboBox`, `ChoiceBox` and others. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1417: > 1415: * to be {@code true}. > 1416: * > 1417: * @defaultValue false I don't think a default value is relevant. It can't be set and the node is not responsible for its value. It's true, though, that by default, since the node does not belong to a window, it's `false`, but I don't know how helpful it is. ------------- Changes requested by nlisker (Reviewer). PR: https://git.openjdk.org/jfx/pull/830 From nlisker at openjdk.org Tue Oct 25 21:16:48 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 25 Oct 2022 21:16:48 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v6] In-Reply-To: <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com> Message-ID: On Thu, 29 Sep 2022 15:02:13 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge remote-tracking branch 'origin/master' into > feature/conditional-bindings > > # Conflicts: > # modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java > - Fix review comments > - Add missing new line > - Small wording fixes > - Update javadoc of "when" with better phrasing > - Rename showing property to shown as it is already used in subclasses > - Add conditional bindings to ObservableValue > - Change explanatory comment to block comment > - Fix bug where ObjectBinding returns null when revalidated immediately > > Introduced with the fluent bindings PR modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1426: > 1424: if (s == null) return false; > 1425: Window w = s.getWindow(); > 1426: return w != null && w.isShowing(); Are you avoiding calling `get` on the property to avoid its initialization? ------------- PR: https://git.openjdk.org/jfx/pull/830 From almatvee at openjdk.org Tue Oct 25 21:31:01 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 25 Oct 2022 21:31:01 GMT Subject: RFR: 8294400: Provide media support for libavcodec version 59 [v2] In-Reply-To: References: Message-ID: > - Added support for libavcodec 59. > - libavcodec 59 removed several deprecated APIs and avplugin code was updated to use replacement APIs instead. > - No changes to avplugin when used with 58 or below. > - Note: Support for libavcodec 59 was added based on ffmpeg only. libav does not have version 59. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8294400: Provide media support for libavcodec version 59 [v2] ------------- Changes: - all: https://git.openjdk.org/jfx/pull/932/files - new: https://git.openjdk.org/jfx/pull/932/files/bb4cead0..86fd01fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=932&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=932&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/932.diff Fetch: git fetch https://git.openjdk.org/jfx pull/932/head:pull/932 PR: https://git.openjdk.org/jfx/pull/932 From almatvee at openjdk.org Tue Oct 25 21:31:02 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 25 Oct 2022 21:31:02 GMT Subject: RFR: 8294400: Provide media support for libavcodec version 59 In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 05:07:05 GMT, Alexander Matveev wrote: > - Added support for libavcodec 59. > - libavcodec 59 removed several deprecated APIs and avplugin code was updated to use replacement APIs instead. > - No changes to avplugin when used with 58 or below. > - Note: Support for libavcodec 59 was added based on ffmpeg only. libav does not have version 59. 8294400: Provide media support for libavcodec version 59 [v2] - Added `avplugin-ffmpeg-59` in the NativeMediaManager constructor. ------------- PR: https://git.openjdk.org/jfx/pull/932 From nlisker at openjdk.org Tue Oct 25 21:54:39 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 25 Oct 2022 21:54:39 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v6] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com> Message-ID: On Tue, 25 Oct 2022 21:06:15 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: >> >> - Merge remote-tracking branch 'origin/master' into >> feature/conditional-bindings >> >> # Conflicts: >> # modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java >> - Fix review comments >> - Add missing new line >> - Small wording fixes >> - Update javadoc of "when" with better phrasing >> - Rename showing property to shown as it is already used in subclasses >> - Add conditional bindings to ObservableValue >> - Change explanatory comment to block comment >> - Fix bug where ObjectBinding returns null when revalidated immediately >> >> Introduced with the fluent bindings PR > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1415: > >> 1413: * >> 1414: *

    Note that the {@code Node} does not need to be visible for this property >> 1415: * to be {@code true}. > > I think that the definition of "shown" is important enough to make it the main focus of the description with something like: > > > Indicates whether or not this {@code Node} is shown. A node is considered shown if it's > part of a {@code Window} whose {@link shown #Window::showingProperty} is {@code true}. > The {@link visibility #visibleProperty} of the node or its scene do not affect this property. > > > I think that there's no need to repeat the showing conditions for a window. > Also we need to be careful not to confuse `shown` with `showing`, which are properties on `ComboBox`, `ChoiceBox` and others. We might also want to add a paragraph explaining its use. Something like: This property can be used in conjunction with {@link ObservableValue#when} as a source for listeners that should be collected when the node is not shown. If there are other uses we can mention them as well. ------------- PR: https://git.openjdk.org/jfx/pull/830 From kcr at openjdk.org Tue Oct 25 22:51:37 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Oct 2022 22:51:37 GMT Subject: RFR: 8294400: Provide media support for libavcodec version 59 [v2] In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 21:31:01 GMT, Alexander Matveev wrote: >> - Added support for libavcodec 59. >> - libavcodec 59 removed several deprecated APIs and avplugin code was updated to use replacement APIs instead. >> - No changes to avplugin when used with 58 or below. >> - Note: Support for libavcodec 59 was added based on ffmpeg only. libav does not have version 59. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8294400: Provide media support for libavcodec version 59 [v2] Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/932 From kcr at openjdk.org Tue Oct 25 23:23:40 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Oct 2022 23:23:40 GMT Subject: RFR: 8294400: Provide media support for libavcodec version 59 [v2] In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 21:31:01 GMT, Alexander Matveev wrote: >> - Added support for libavcodec 59. >> - libavcodec 59 removed several deprecated APIs and avplugin code was updated to use replacement APIs instead. >> - No changes to avplugin when used with 58 or below. >> - Note: Support for libavcodec 59 was added based on ffmpeg only. libav does not have version 59. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8294400: Provide media support for libavcodec version 59 [v2] This needs a second reviewer. ------------- PR: https://git.openjdk.org/jfx/pull/932 From tsayao at openjdk.org Wed Oct 26 01:03:54 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 26 Oct 2022 01:03:54 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v17] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in update_window_constraints; > - Frame extents (the window decoration size used for "total window size": > - frame extents are received in process_property_notify; > - removed quirks in java code; > - When received, call set_bounds again to adjust the size; > - `gtk_window_set_focus_on_map` to fix https://bugs.openjdk.org/browse/JDK-8292922 and re-fix https://bugs.openjdk.org/browse/JDK-8271054 > - `requested_bounds` removed - not necessary; > - `window_configure` incorporated in set_bounds with `gtk_window_move` and `gtk_window_resize` Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Partially prevent focus stealing notification ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/52cb9af5..4a2ed9e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=16 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=15-16 Stats: 13 lines in 1 file changed: 6 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From jhendrikx at openjdk.org Wed Oct 26 07:39:44 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 26 Oct 2022 07:39:44 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v7] In-Reply-To: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: > This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. > > It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). > > Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: > > label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); > > The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. > > The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. > > Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. > > (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Fix comment in test - Improve documentation of shown property ------------- Changes: - all: https://git.openjdk.org/jfx/pull/830/files - new: https://git.openjdk.org/jfx/pull/830/files/4fa45c76..ea546998 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=05-06 Stats: 13 lines in 2 files changed: 3 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/830.diff Fetch: git fetch https://git.openjdk.org/jfx pull/830/head:pull/830 PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Wed Oct 26 07:39:45 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 26 Oct 2022 07:39:45 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v6] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com> Message-ID: On Tue, 25 Oct 2022 21:50:50 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1415: >> >>> 1413: * >>> 1414: *

    Note that the {@code Node} does not need to be visible for this property >>> 1415: * to be {@code true}. >> >> I think that the definition of "shown" is important enough to make it the main focus of the description with something like: >> >> >> Indicates whether or not this {@code Node} is shown. A node is considered shown if it's >> part of a {@code Window} whose {@link shown #Window::showingProperty} is {@code true}. >> The {@link visibility #visibleProperty} of the node or its scene do not affect this property. >> >> >> I think that there's no need to repeat the showing conditions for a window. >> Also we need to be careful not to confuse `shown` with `showing`, which are properties on `ComboBox`, `ChoiceBox` and others. > > We might also want to add a paragraph explaining its use. Something like: > > This property can be used in conjunction with {@link ObservableValue#when} > as a source for listeners that should be collected when the node is not shown. > > If there are other uses we can mention them as well. I've changed the documentation as you suggested, and I also included that the `Node` must be part of a `Scene`, although I suppose that is a given since you can't show a node in a window otherwise. > Also we need to be careful not to confuse shown with showing, which are properties on ComboBox, ChoiceBox and others. Definitely, I had `showing` in the initial version only to discover it was already present in common controls. I also added your suggested paragraph but rephrased as: > This property can be used in conjunction with {@link ObservableValue#when} to create bindings which are only actively listening to their source when the node is shown. Other uses could be to disable animations when not shown. For example, `ProgressBarSkin` and some other controls only animate their controls when visible (they however do a visibility check as well). See `isTreeShowing`. For example, I've used this property to start animations as soon as a `Node` becomes shown, and to stop the animation when it is no longer shown. I've added this to the docs: > This property can also be used to start animations when the node is shown, and to stop them when it is no longer shown. I also added a `@see ObservableValue#when(ObservableValue)` -- not sure if that is needed. ------------- PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Wed Oct 26 07:39:45 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 26 Oct 2022 07:39:45 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v7] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Wed, 19 Oct 2022 20:56:43 GMT, Nir Lisker wrote: >> Does `asLongAs` imply recurrent nature? > > I don't see why not. About `Bindings.when` confusion: `Bindings.when` serves a different purpose. `Bindings.when(condition).then(x).otherwise(y)` is the same as `map(condition ? x : y)`. The fact that it uses "when" and "otherwise" is more because "if" and "else" are unavailable. `when` has the implication of it being a near certain event somewhere in the future, and IMHO was never a good match for `Bindings.when` but there was little choice when naming such a construct. In `ObservableValue` I think `when` is a name that is quite a good match to describe its purpose in fluent bindings; it is not used for a simple if/else condition that may never be `true` or `false` like it would be in a simple `map`, but for a condition that **will** change in the future. Why do I say this? `when` doesn't change the source value, only passes it through. If the condition would never change in the future, then there is no point in using `when` -- you could either just always pass it through, or always map it to the empty value -- so when a binding uses `when` it is a near certainty that the condition changes at some point in the future. ------------- PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Wed Oct 26 07:39:50 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 26 Oct 2022 07:39:50 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v6] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com> Message-ID: On Tue, 25 Oct 2022 20:54:55 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: >> >> - Merge remote-tracking branch 'origin/master' into >> feature/conditional-bindings >> >> # Conflicts: >> # modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java >> - Fix review comments >> - Add missing new line >> - Small wording fixes >> - Update javadoc of "when" with better phrasing >> - Rename showing property to shown as it is already used in subclasses >> - Add conditional bindings to ObservableValue >> - Change explanatory comment to block comment >> - Fix bug where ObjectBinding returns null when revalidated immediately >> >> Introduced with the fluent bindings PR > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1417: > >> 1415: * to be {@code true}. >> 1416: * >> 1417: * @defaultValue false > > I don't think a default value is relevant. It can't be set and the node is not responsible for its value. It's true, though, that by default, since the node does not belong to a window, it's `false`, but I don't know how helpful it is. You're right, this is a copy/paste error. Makes no sense for a read only property. I will remove it. > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1426: > >> 1424: if (s == null) return false; >> 1425: Window w = s.getWindow(); >> 1426: return w != null && w.isShowing(); > > Are you avoiding calling `get` on the property to avoid its initialization? Yeah, I actually copied this pattern from an older method that has since been removed (`isWindowShowing`) in an effort to avoid initializing the property if all you're doing is calling its getter. I personally don't mind either way, but as it seems `Node` goes through every effort to delay initialization, I followed that pattern. It does duplicate the logic of the property which uses `flatMap`s to achieve the same. ------------- PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Wed Oct 26 07:39:50 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 26 Oct 2022 07:39:50 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v6] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com> Message-ID: On Wed, 19 Oct 2022 18:18:48 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: >> >> - Merge remote-tracking branch 'origin/master' into >> feature/conditional-bindings >> >> # Conflicts: >> # modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java >> - Fix review comments >> - Add missing new line >> - Small wording fixes >> - Update javadoc of "when" with better phrasing >> - Rename showing property to shown as it is already used in subclasses >> - Add conditional bindings to ObservableValue >> - Change explanatory comment to block comment >> - Fix bug where ObjectBinding returns null when revalidated immediately >> >> Introduced with the fluent bindings PR > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1442: > >> 1440: >> 1441: // Candidate to make publicly available or to add as a convience method to ObservableValue >> 1442: private static class ReadOnlyBooleanDelegate extends ReadOnlyBooleanProperty { > > should this class be moved elsewhere? It can be, generally I tend to this when there is a second use of the class. In that case we may also want to introduce the other primitive versions. So for now I would leave it here, until there is another use case. ------------- PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Wed Oct 26 07:43:16 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 26 Oct 2022 07:43:16 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v6] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com> <24S2xIDXEseZu7VqN4evg9d3FLeAFnMY7y78E4FlG0E=.f1287216-7041-4f0b-afd7-cd6ae1061d4a@github.com> Message-ID: On Fri, 14 Oct 2022 16:17:24 GMT, Andy Goryachev wrote: >>> 1. it looks like your proposal will work, as long as the `active` property is not referenced outside of its owner (in our discussion, Skin). If that is true, as soon as you set active=false, the listener is disconnected and the skin, the active property, and the lambda can be collected. Thus, as you correctly explained, we need to create a large aggregate with two flat maps in order to avoid the memory leak (whether you hide this complexity behind shownProperty is irrelevant). >> >> Yes, the `shownProperty` is there purely for convenience, and more useful for regular controls, not the skin scenario I think. I have this helper that I use for this purpose at the moment: >> >> public static ObservableValue showing(Node node) { >> return node.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false); >> } >> >>> So yes, it will work, as long as the developer makes no mistakes and does not wire the thing directly (a mistake I readily made) >> >> Yes, that's certainly true, I think the `shownProperty` will help with that though, as I think it will prevent people from storing the flatMap aggregate and reusing it, and perhaps then reusing it for the wrong controls. Reuse however can still be fine for groups of listeners of several controls that go together. If your control's lifecycle is tied to a group, container or dialog, then it is perfectly fine to use one of their shown properties. >> >>> 2. as a side note, I would discourage a pattern where Nodes are reused and need to be reconnected. at least in my applications, I never do that, but I can see situation when this might be useful. >> >> I'm not in favor of that either, and I don't think I ever do it, but it is allowed by JavaFX, and so if you did, then the listeners would be restored as they were, and since you had to have a reference to this reused control still, nothing will have been GC'd yet. >> >>> 3. is when() a good name? it sort of implies a time-domain criterion instead of when a boolean becomes true (whenTrue? whenAllowed?) i could be wrong here. >> >> ReactFX used `conditionOn` and had a special version `conditionOnShowing` which accepts a `Node` (this would however create a circular reference between projects base and graphics). I proposed `when` as it is nice and short, inspired by the recent developments in the area of switch expressions. Even better would be `while` IMHO, but that is unfortunately a reserved keyword. Still, when works reasonably well: "Listen to changes of this long lived property **when** this condition holds". While would definitely be better or perhaps "as long as" or "whenever" :) >> >> I don't think we should add "true" in the name, no other conditionals do this (like `Stream#filter` or `List#removeIf`). >> >> `filter` itself is also not an option, as this has a different meaning which we may implement in the future. `filter` would allow you to remove certain values, which would set the value to empty: >> >> textProperty.filter(text -> !isRudeWord()).orElse("").addListener(...); > > thank you for clarifications. > > If I were to choose, I'd pick `conditionOn` as it implies a boolean. > > Also, since I've fallen into this trap when reviewing this PR, I think it might be a good idea to explain how to avoid memory leak by using a local property in `conditionOn/when` so as not to create a memory leak. @andy-goryachev-oracle About avoiding the memory leak. The documentation for `when` currently says: > The returned {@code ObservableValue} only observes this value when {@code condition} holds {@code true}. **This allows this {@code ObservableValue} and the conditional {@code ObservableValue} to be garbage collected if neither is otherwise strongly referenced when {@code condition} holds {@code false}.** This is in contrast to the general behavior of bindings, where the binding is only eligible for garbage collection when not observed itself. The second sentence I think explains the reason that it should be a property with a similar lifecycle. Do you think I should expand on this further? ------------- PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Wed Oct 26 07:56:52 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 26 Oct 2022 07:56:52 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v8] In-Reply-To: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: > This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. > > It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). > > Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: > > label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); > > The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. > > The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. > > Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. > > (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix javadoc error ------------- Changes: - all: https://git.openjdk.org/jfx/pull/830/files - new: https://git.openjdk.org/jfx/pull/830/files/ea546998..46f206aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/830.diff Fetch: git fetch https://git.openjdk.org/jfx pull/830/head:pull/830 PR: https://git.openjdk.org/jfx/pull/830 From nlisker at gmail.com Wed Oct 26 20:24:59 2022 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 26 Oct 2022 23:24:59 +0300 Subject: JDK-8091393: Observable collections for ObservableMap views In-Reply-To: References: <732c2991-b2e2-0048-e86d-b894fd95640c@bestsolution.at> <2cc3e30a-2b92-a78d-8b9d-f7f1a2aba155@gmail.com> Message-ID: I'm CC'ing Stuart Marks who has recently dealt with a similar issue when working on Sequenced Collections [1], and wrote a compatibility report [2] that includes an item about covariant overrides ("Covariant Overrides of `SequencedMap` View Collection Methods"), which is similar to what is discussed here. I contacted him off list to get his insights into the risks involved here. To recap, ObservableMap inherits keySet(), entrySet() and values() from Map, which return the standard Set and Collection interfaces. ObservableMap should provide ObservableSet and perhaps the not-yet-existing ObservableCollection. There are 2 options here: one is to add additional default methods to ObservableMap that return observable collection, the second is to override the methods inherited from Map and change the return value. The latter has some backwards compatibility issues. It comes down to implementations of ObservableMap in the wild. I have yet to see any, personally. JavaFX does not itself expose any of its implementations, as ObservableMaps are obtained through FXCollections static methods. I'd like to continue this discussion about the API side. I have already had some advances on the implementation. [1] https://openjdk.org/jeps/431 [2] https://bugs.openjdk.org/browse/JDK-8266572 On Tue, May 31, 2022 at 12:02 AM Nir Lisker wrote: > Then maybe a solution would be around adding new methods like > observableKeySet(). These will need to be default methods, and the > implementation could test if keySet() already returns an ObservableSet, in > which case it returns it, and if not it wraps the Set in an > ObservableSetWrapper or something like that. > > On Mon, May 30, 2022 at 11:50 AM John Hendrikx > wrote: > >> Sorry, I misunderstood, I missed that the methods weren't already >> defined in ObservableMap, so no existing signature is changed. >> >> --John >> >> On 30/05/2022 09:39, Tom Schindl wrote: >> > Hi, >> > >> > Well the binary compat IMHO is not a problem. If your subtype >> > overwrites the return type of a method the compiler will inserts a >> > bridge method: >> > >> > Take this example >> > >> > package bla; >> > >> > import java.util.ArrayList; >> > import java.util.Collection; >> > import java.util.List; >> > >> > public class Test { >> > public interface IB { >> > public Collection get(); >> > } >> > >> > public interface I extends IB { >> > public List get(); >> > } >> > >> > public class C implements I { >> > public ArrayList get() { >> > return new ArrayList(); >> > } >> > } >> > } >> > >> > if you look at C with javap you'll notice >> > >> > Compiled from "Test.java" >> > public class bla.Test$C implements bla.Test$I { >> > final bla.Test this$0; >> > public bla.Test$C(bla.Test); >> > public java.util.ArrayList get(); >> > public java.util.Collection get(); >> > public java.util.List get(); >> > } >> > >> > >> > The problem is more that if someone directly implemented ObservableMap >> > him/her self that it won't compile anymore. So it is a source >> > incompatible change. >> > >> > Tom >> > >> > Am 30.05.22 um 08:58 schrieb John Hendrikx: >> >> It's not binary compatible, as changing the return type results in a >> >> new method that compiled code won't be able to find. >> >> >> >> See also "change result type (including void)" here: >> >> >> https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interfaces_-_API_methods >> >> >> >> >> >> --John >> >> >> >> On 30/05/2022 03:22, Nir Lisker wrote: >> >>> Hi, >> >>> >> >>> Picking up an old issue, JDK-8091393 [1], I went ahead and looked at >> >>> the >> >>> work needed to implement it. >> >>> >> >>> keySet() and entrySet() can both be made to return ObservableSet >> rather >> >>> easily. values() will probably require an ObservableCollection >> type. >> >>> >> >>> Before discussing these details, my question is: is it backwards >> >>> compatible >> >>> to require that these methods now return a more refined type? I >> >>> think that >> >>> it will break implementations of ObservableMap out in the wild if it >> >>> overrides these methods in Map. What is the assessment here? >> >>> >> >>> https://bugs.openjdk.java.net/browse/JDK-8091393 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Wed Oct 26 22:44:56 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Oct 2022 22:44:56 GMT Subject: RFR: 8295962: Reference to State in Task.java is ambiguous when building with JDK 19 Message-ID: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> This PR replaces all occurrences of `State` with `Worker.State` in `javafx.concurrent.Task`. The `javafx.concurrent.Task` class implements `javafx.concurrent.Worker` and extends `java.util.concurrent.FutureTask`, which in turn implements `java.util.concurrent.Future`. `Worker` has a nested `State` enum, which is used in the implementing `Task` class without being qualified -- since `Task` is a `Worker`, we can just say `State` instead of `Worker.State`. [JDK-8277090](https://bugs.openjdk.org/browse/JDK-8277090) added a nested `State` enum to the `java.util.concurrent.Future` interface in JDK 19, so an unqualified reference to `State` from the `Task` class is now ambiguous when using JDK 19 to build. The javadoc task fails with an error (and the only reason the javac task doesn't is that we use `--release 17`). With this fix, a local build and test using JDK 19 passes. ------------- Commit messages: - 8295962: Reference to State in Task.java is ambiguous when building with JDK 19 Changes: https://git.openjdk.org/jfx/pull/933/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=933&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295962 Stats: 14 lines in 1 file changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/933.diff Fetch: git fetch https://git.openjdk.org/jfx pull/933/head:pull/933 PR: https://git.openjdk.org/jfx/pull/933 From angorya at openjdk.org Wed Oct 26 22:51:39 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 26 Oct 2022 22:51:39 GMT Subject: RFR: 8295962: Reference to State in Task.java is ambiguous when building with JDK 19 In-Reply-To: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> References: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> Message-ID: On Wed, 26 Oct 2022 22:38:15 GMT, Kevin Rushforth wrote: > This PR replaces all occurrences of `State` with `Worker.State` in `javafx.concurrent.Task`. > > The `javafx.concurrent.Task` class implements `javafx.concurrent.Worker` and extends `java.util.concurrent.FutureTask`, which in turn implements `java.util.concurrent.Future`. > > `Worker` has a nested `State` enum, which is used in the implementing `Task` class without being qualified -- since `Task` is a `Worker`, we can just say `State` instead of `Worker.State`. > > [JDK-8277090](https://bugs.openjdk.org/browse/JDK-8277090) added a nested `State` enum to the `java.util.concurrent.Future` interface in JDK 19, so an unqualified reference to `State` from the `Task` class is now ambiguous when using JDK 19 to build. The javadoc task fails with an error (and the only reason the javac task doesn't is that we use `--release 17`). > > With this fix, a local build and test using JDK 19 passes. all instances in Task class ------------- Marked as reviewed by angorya (Author). PR: https://git.openjdk.org/jfx/pull/933 From kcr at openjdk.org Thu Oct 27 15:58:00 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Oct 2022 15:58:00 GMT Subject: RFR: 8290844: Add Skin.install() method [v13] In-Reply-To: <5U-nxVPjLCe3VKLCpvfI-Bjxmsl0PPH3UIDC9Hrv5nA=.91db11b7-8703-4526-a4c8-504ce3c013c5@github.com> References: <5U-nxVPjLCe3VKLCpvfI-Bjxmsl0PPH3UIDC9Hrv5nA=.91db11b7-8703-4526-a4c8-504ce3c013c5@github.com> Message-ID: On Thu, 20 Oct 2022 19:07:47 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > 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 26 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - Merge branch 'openjdk:master' into 8290844.skin.install > - 8290844: unit tests > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - ... and 16 more: https://git.openjdk.org/jfx/compare/9bab17bd...4aaf422b The javadoc now looks good to me with two minor changes requested. Once you make those changes, go ahead and update the CSR and "Propose" it. modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 226: > 224: *

    > 225: * To ensure a one-to-one relationship between a {@code Control} and its {@code Skin}, > 226: * setting the {@link #skinProperty() skin property} to a non-null {@code Skin} first checks This need not be a link, since it is already in the skin property. I recommend changing it to code style. modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 46: > 44: * and its {@code Skin}. Every {@code Skin} maintains a back reference to the > 45: * {@code Skinnable}. When required, this relationship is enforced inside {@link Skinnable#setSkin(Skin)} method > 46: * which checks the return value of {@link Skin#getSkinnable()} against this {@code Skinnable}, As with other occurrences, I recommend changing `inside {@link Skinnable#setSkin(Skin)} method` to `when the skin is set`. ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Thu Oct 27 15:58:01 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Oct 2022 15:58:01 GMT Subject: RFR: 8290844: Add Skin.install() method [v13] In-Reply-To: References: <5U-nxVPjLCe3VKLCpvfI-Bjxmsl0PPH3UIDC9Hrv5nA=.91db11b7-8703-4526-a4c8-504ce3c013c5@github.com> Message-ID: <9mtowGVBrMhrgW31JrCEHQf2k3JC7FS-WmxsHTieX0U=.35a5ce49-9c3b-4777-825b-791c267d8511@github.com> On Thu, 27 Oct 2022 15:50:06 GMT, Kevin Rushforth 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 26 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge branch 'openjdk:master' into 8290844.skin.install >> - 8290844: unit tests >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - ... and 16 more: https://git.openjdk.org/jfx/compare/9bab17bd...4aaf422b > > modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 226: > >> 224: *

    >> 225: * To ensure a one-to-one relationship between a {@code Control} and its {@code Skin}, >> 226: * setting the {@link #skinProperty() skin property} to a non-null {@code Skin} first checks > > This need not be a link, since it is already in the skin property. I recommend changing it to code style. Actually, it's better to just remove the link and leave it as plain text. ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Thu Oct 27 17:11:42 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Oct 2022 17:11:42 GMT Subject: RFR: 8294400: Provide media support for libavcodec version 59 [v2] In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 21:31:01 GMT, Alexander Matveev wrote: >> - Added support for libavcodec 59. >> - libavcodec 59 removed several deprecated APIs and avplugin code was updated to use replacement APIs instead. >> - No changes to avplugin when used with 58 or below. >> - Note: Support for libavcodec 59 was added based on ffmpeg only. libav does not have version 59. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8294400: Provide media support for libavcodec version 59 [v2] @johanvos or @tiainen Do you want to test this? It should be a straight-forward update, but since it doesn't get run via GitHub actions, you might want to urn this in your CI. We've already run it on our CI. ------------- PR: https://git.openjdk.org/jfx/pull/932 From angorya at openjdk.org Thu Oct 27 17:12:59 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Oct 2022 17:12:59 GMT Subject: RFR: 8290844: Add Skin.install() method [v14] In-Reply-To: References: Message-ID: > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290844: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/845/files - new: https://git.openjdk.org/jfx/pull/845/files/4aaf422b..4d1fb937 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=13 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=12-13 Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/845.diff Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845 PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Oct 27 17:16:02 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Oct 2022 17:16:02 GMT Subject: RFR: 8290844: Add Skin.install() method [v15] In-Reply-To: References: Message-ID: > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) 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 28 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - 8290844: review comments - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - 8290844: review comments - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - 8290844: javadoc - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - 8290844: javadoc - Merge branch 'openjdk:master' into 8290844.skin.install - 8290844: unit tests - ... and 18 more: https://git.openjdk.org/jfx/compare/abf85c85...3235d433 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/845/files - new: https://git.openjdk.org/jfx/pull/845/files/4d1fb937..3235d433 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=14 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=13-14 Stats: 84 lines in 84 files changed: 0 ins; 0 del; 84 mod Patch: https://git.openjdk.org/jfx/pull/845.diff Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845 PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Thu Oct 27 17:33:48 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Oct 2022 17:33:48 GMT Subject: RFR: 8290844: Add Skin.install() method [v15] In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 17:16:02 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > 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 28 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - Merge branch 'openjdk:master' into 8290844.skin.install > - 8290844: unit tests > - ... and 18 more: https://git.openjdk.org/jfx/compare/2c98cac5...3235d433 modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 46: > 44: * and its {@code Skin}. Every {@code Skin} maintains a back reference to the > 45: * {@code Skinnable}. When required, this relationship is enforced when the {@code Skin} is set, > 46: * throwing an {@code IllegalArgumentException}. It looks like you removed too much. I think you need to retain the information about what will cause the exception. Maybe something like `,throwing an {@code IllegalArgumentException} if the return value of {@link Skin#getSkinnable()} is not the same as this {@code Skinnable}.`? ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Oct 27 17:38:34 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Oct 2022 17:38:34 GMT Subject: RFR: 8290844: Add Skin.install() method [v16] In-Reply-To: References: Message-ID: > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290844: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/845/files - new: https://git.openjdk.org/jfx/pull/845/files/3235d433..5ea8a5fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=15 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=14-15 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/845.diff Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845 PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Oct 27 17:38:42 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Oct 2022 17:38:42 GMT Subject: RFR: 8290844: Add Skin.install() method [v15] In-Reply-To: References: Message-ID: <1xf9UAFXelAt2PX2rn7I9VMk2kvm7IJQ1jkfmkewq58=.45e87cfa-95c6-4be9-873d-2df230e0c570@github.com> On Thu, 27 Oct 2022 17:31:32 GMT, Kevin Rushforth 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 28 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge branch 'openjdk:master' into 8290844.skin.install >> - 8290844: unit tests >> - ... and 18 more: https://git.openjdk.org/jfx/compare/d8f9480c...3235d433 > > modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 46: > >> 44: * and its {@code Skin}. Every {@code Skin} maintains a back reference to the >> 45: * {@code Skinnable}. When required, this relationship is enforced when the {@code Skin} is set, >> 46: * throwing an {@code IllegalArgumentException}. > > It looks like you removed too much. I think you need to retain the information about what will cause the exception. Maybe something like `,throwing an {@code IllegalArgumentException} if the return value of {@link Skin#getSkinnable()} is not the same as this {@code Skinnable}.`? corrected, thanks! ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Thu Oct 27 17:42:30 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Oct 2022 17:42:30 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v6] In-Reply-To: <3ENx-4GXr9i0N08c2eeDPzOOEDhJVGG5RWgHg4t_S9w=.e65f9e55-b2e1-4cd5-936b-85442cdbacff@github.com> References: <3ENx-4GXr9i0N08c2eeDPzOOEDhJVGG5RWgHg4t_S9w=.e65f9e55-b2e1-4cd5-936b-85442cdbacff@github.com> Message-ID: On Fri, 21 Oct 2022 20:24:07 GMT, Andy Goryachev wrote: >> Introduction >> >> There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class). >> >> This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance >> https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java >> >> Proposal >> >> It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which: >> >> - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc. >> - keeps track of the listeners and the corresponding ObservableValues >> - provides a single disconnect() method to remove all the listeners in one go. >> - optionally, it should be possible to add a lambda (Runnable) to a group of properties >> - optionally, there should be a boolean flag to fire the lambda immediately >> - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method >> >> Make it Public Later >> >> Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later. >> >> Where It Will Be Useful >> >> [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin" >> and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler. >> >> https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft >> >> https://github.com/openjdk/jfx/pull/914 > > 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 20 additional commits since the last revision: > > - 8294809: map change listener > - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper > - 8294809: generics > - 8294809: is alive > - Revert "8294809: removed weak listeners support" > > This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. > - 8294809: removed weak listeners support > - 8294809: use weak reference correctly this time > - 8294809: tests > - 8294809: remove > - 8294809: change listener with callback > - ... and 10 more: https://git.openjdk.org/jfx/compare/836729e3...7a1fa625 The stated intention of this PR is to provide a helpful utility to enable Skins to more easily manage their listeners to avoid memory leaks. I am not sold on the idea of this migrating to public API, but we can defer that (longer) discussion. As long as this does not impact the public API surface, we can evaluate it as a internal helper class that enables a few memory leak bug fixes. To that end, you will need at least one change, since this PR _does_ add to the public API surface (and exposes an internal type in the process). modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 86: > 84: * map (although it doesn't really do much harm). > 85: */ > 86: @Deprecated // replace with listenerHelper We only use `@Deprecated` annotation on public API, so you should limit this to a comment. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 222: > 220: * @since 20 > 221: */ > 222: protected ListenerHelper listenerHelper() { This would make it part of the public API, so you will need to find some other way to do this without adding anything to the public API surface. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 241: > 239: */ > 240: // TODO I would like to deprecate and remove these methods, and replace them by listenerHelper().add**() > 241: protected final void registerChangeListener(ObservableValue observable, Consumer> operation) { I don't think we want to deprecate this. It is part of the public API, so there would need to be a compelling reason to deprecate it. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/908 From jhendrikx at openjdk.org Thu Oct 27 18:25:56 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 27 Oct 2022 18:25:56 GMT Subject: RFR: 8290844: Add Skin.install() method [v15] In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 17:16:02 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > 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 28 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - Merge branch 'openjdk:master' into 8290844.skin.install > - 8290844: unit tests > - ... and 18 more: https://git.openjdk.org/jfx/compare/f0ef8135...3235d433 I've read through all the docs and code, and added a few suggestions. modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 228: > 226: * setting the skin property to a non-null {@code Skin} first checks > 227: * the return value of {@link Skin#getSkinnable()} against this Control, > 228: * and throws an {@code IllegalArgumentException} if it is not the same. Suggestion: * To ensure a one-to-one relationship between a {@code Control} and its {@code Skin}, * skins which were not created for this control are rejected with an {@code IllegalArgumentException}. No need to emphasize this is only in the not null case, as null skins are documented to be allowed. modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 261: > 259: throw new IllegalArgumentException("Skin does not correspond to this Control"); > 260: } > 261: } Suggestion: if (skin != null && skin.getSkinnable() != Control.this) { unbind(); set(oldValue); throw new IllegalArgumentException("Skin does not correspond to this Control"); } modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 44: > 42: *

  • installing of the new skin via {@link #install()} > 43: * > 44: * It says it describes the life cycle of a Skin, but instead goes into detail about the skin replacement mechanism. The lifecycle is much simpler: - Instantiation (constructor) - Acceptance (#install) - Disposal (#dispose) I also think that `install` may not be the correct name. It is like an event that already occurred, and should be past tense (like `invalidated`). The Control has done its checks and has accepted the new skin. Perhaps `installed` or `accepted`? Suggestion: * {@link #install()} method. A skin has the following life cycle: *
      *
    • instantiation: a skin should not make permanent changes to its associated control during this phase *
    • acceptance: a skin was accepted as the new skin for its control and can now change the control as needed *
    • disposal: a skin, which was previously accepted, is about to be unassociated with its control and should undo any permanent changes and clean up any bindings and listeners on the control *
    modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 78: > 76: * previous skin, if any, has been uninstalled via its {@link #dispose()} method. > 77: * This method allows a Skin to register listeners, add child nodes, set > 78: * required properties and/or event handlers. I don't see how it is relevant for this interface to know what happens to the previous skin. The interface should simply describe what is expected, and not go into detail here. Suggestion: * Called when the {@link Skin} is accepted for its control. The skin can now * safely make changes to its associated control, like registering listeners, adding * child nodes and modifying properties and event handlers. * *

    When the control calls this method, it guarantees a future call to {@link #dispose} * when the skin is removed. modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 87: > 85: * Most implementations of Skin > 86: * do not need to implement {@code install} unless they must set one or more > 87: * properties in the corresponding Skinnable. I think this might be better: Suggestion: * Skins only need to implement {@code install} if they need to make direct changes to the control * like overwriting properties or event handlers. Such skins should ensure these changes are undone in * their {@link #dipose()} method. modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 97: > 95: * This method allows a {@link Skin} to implement any logic necessary to clean up itself after > 96: * the {@code Skin} is no longer needed. It may be used to release native resources. > 97: * The methods {@link #getSkinnable()} and {@link #getNode()} I don't think this is correct "Disconnects the skin from its skinnable" -- the control does this. I also think "clean up" covers the "native resources" bit, and not something that should be mentioned in an interface description. May I suggest: > Called when a previously installed skin is about to be removed from its associated control. This allows the skin to do clean up, like removing listeners and bindings, and undo any permanent changes to its control. After this method completes, {@link #getSkinnable()} and {@link #getNode()} should return {@code null}. modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 41: > 39: * The Skin is responsible for rendering this {@code Skinnable}. From the > 40: * perspective of the {@code Skinnable}, the {@code Skin} is a black box. > 41: * It listens and responds to changes in state in a {@code Skinnable}. I think the start is incorrect (in both old and new version). It should either be "The skin **that** is responsible for" or "The skin responsible for". Suggestion: * The Skin responsible for rendering this {@code Skinnable}. From the * perspective of the {@code Skinnable}, the {@code Skin} is a black box. * It listens and responds to changes in state of its {@code Skinnable}. modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlTest.java line 816: > 814: SkinStub skin = new SkinStub(new ControlStub()); > 815: c.setSkin(skin); > 816: } Is Junit 5 availabe for this project? If so I'd recommend writing: Suggestion: @Test public void skinMustCorrespondToControl() { SkinStub skin = new SkinStub(new ControlStub()); assertThrows(IllegalArgumentException.class, () -> c.setSkin(skin)); } ------------- PR: https://git.openjdk.org/jfx/pull/845 From jvos at openjdk.org Thu Oct 27 19:44:31 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 27 Oct 2022 19:44:31 GMT Subject: RFR: 8294400: Provide media support for libavcodec version 59 [v2] In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 21:31:01 GMT, Alexander Matveev wrote: >> - Added support for libavcodec 59. >> - libavcodec 59 removed several deprecated APIs and avplugin code was updated to use replacement APIs instead. >> - No changes to avplugin when used with 58 or below. >> - Note: Support for libavcodec 59 was added based on ffmpeg only. libav does not have version 59. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8294400: Provide media support for libavcodec version 59 [v2] I'll build + do basic tests ------------- PR: https://git.openjdk.org/jfx/pull/932 From angorya at openjdk.org Thu Oct 27 22:22:29 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Oct 2022 22:22:29 GMT Subject: RFR: 8290844: Add Skin.install() method [v15] In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 17:37:11 GMT, John Hendrikx 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 28 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge branch 'openjdk:master' into 8290844.skin.install >> - 8290844: unit tests >> - ... and 18 more: https://git.openjdk.org/jfx/compare/81a0647c...3235d433 > > modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 228: > >> 226: * setting the skin property to a non-null {@code Skin} first checks >> 227: * the return value of {@link Skin#getSkinnable()} against this Control, >> 228: * and throws an {@code IllegalArgumentException} if it is not the same. > > Suggestion: > > * To ensure a one-to-one relationship between a {@code Control} and its {@code Skin}, > * skins which were not created for this control are rejected with an {@code IllegalArgumentException}. > > No need to emphasize this is only in the not null case, as null skins are documented to be allowed. i like that, thank you. > modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 261: > >> 259: throw new IllegalArgumentException("Skin does not correspond to this Control"); >> 260: } >> 261: } > > Suggestion: > > if (skin != null && skin.getSkinnable() != Control.this) { > unbind(); > set(oldValue); > throw new IllegalArgumentException("Skin does not correspond to this Control"); > } i prefer to have one statement per line. ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Thu Oct 27 23:00:38 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Oct 2022 23:00:38 GMT Subject: RFR: 8254676: Alert disables Tab selection when TabDragPolicy REORDER is used In-Reply-To: References: Message-ID: On Sun, 11 Sep 2022 12:13:47 GMT, Johan Vos wrote: > Don't set TabHeader to mouseTransparent, since it might get stuck in that state (e.g. in case an Alert is shown). > The TabPaneSkin deals with the dragging internally, and does not require the dragged node to be mouseTransparent. The fix looks fine to me. I tested it and all is as expected. I also don't remember the reason for the initial setting of `mouseTransparent`, but it was in the initial implementation of draggable tabs [JDK-8187074](https://bugs.openjdk.org/browse/JDK-8187074). Johan's guess seems plausible. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/895 From angorya at openjdk.org Thu Oct 27 23:20:21 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Oct 2022 23:20:21 GMT Subject: RFR: 8290844: Add Skin.install() method [v15] In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 17:57:02 GMT, John Hendrikx 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 28 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge branch 'openjdk:master' into 8290844.skin.install >> - 8290844: unit tests >> - ... and 18 more: https://git.openjdk.org/jfx/compare/d4b53975...3235d433 > > modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 44: > >> 42: *

  • installing of the new skin via {@link #install()} >> 43: * >> 44: * > > It says it describes the life cycle of a Skin, but instead goes into detail about the skin replacement mechanism. The lifecycle is much simpler: > > - Instantiation (constructor) > - Acceptance (#install) > - Disposal (#dispose) > > I also think that `install` may not be the correct name. It is like an event that already occurred, and should be past tense (like `invalidated`). The Control has done its checks and has accepted the new skin. Perhaps `installed` or `accepted`? > > Suggestion: > > * {@link #install()} method. A skin has the following life cycle: > *
      > *
    • instantiation: a skin should not make permanent changes to its associated control during this phase > *
    • acceptance: a skin was accepted as the new skin for its control and can now change the control as needed > *
    • disposal: a skin, which was previously accepted, is about to be unassociated with its control and should undo any permanent changes and clean up any bindings and listeners on the control > *
    Not sure if I agree here. For one thing, Swing ComponentUI uses installUI(), so it's very clear to anyone familiar with the swing. Secondly, install() installs the skin in its control, i.e. sets various fields and properties on that control instance. I'd prefer to keep existing install() name. > modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 87: > >> 85: * Most implementations of Skin >> 86: * do not need to implement {@code install} unless they must set one or more >> 87: * properties in the corresponding Skinnable. > > I think this might be better: > > Suggestion: > > * Skins only need to implement {@code install} if they need to make direct changes to the control > * like overwriting properties or event handlers. Such skins should ensure these changes are undone in > * their {@link #dipose()} method. Your version is so much better, than you. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Oct 27 23:25:34 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Oct 2022 23:25:34 GMT Subject: RFR: 8290844: Add Skin.install() method [v15] In-Reply-To: References: Message-ID: <4MaF0vsyhLoVB1AbGt9B6zIBooga3CNnxE0xaVd4W3U=.26a501df-2d1d-4290-9b06-65debd4f7698@github.com> On Thu, 27 Oct 2022 18:15:23 GMT, John Hendrikx 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 28 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge branch 'openjdk:master' into 8290844.skin.install >> - 8290844: unit tests >> - ... and 18 more: https://git.openjdk.org/jfx/compare/f37cfff0...3235d433 > > modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 97: > >> 95: * This method allows a {@link Skin} to implement any logic necessary to clean up itself after >> 96: * the {@code Skin} is no longer needed. It may be used to release native resources. >> 97: * The methods {@link #getSkinnable()} and {@link #getNode()} > > I don't think this is correct "Disconnects the skin from its skinnable" -- the control does this. I also think "clean up" covers the "native resources" bit, and not something that should be mentioned in an interface description. > > May I suggest: > >> Called when a previously installed skin is about to be removed from its associated control. This allows the skin to do clean up, like removing listeners and bindings, and undo any permanent changes to its control. After this method completes, {@link #getSkinnable()} and {@link #getNode()} should return {@code null}. I like this too, except for "permanent", which I think is a misnomer. ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Thu Oct 27 23:40:27 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Oct 2022 23:40:27 GMT Subject: RFR: 8290844: Add Skin.install() method [v15] In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 23:16:26 GMT, Andy Goryachev wrote: > I'd prefer to keep existing install() name. I prefer `install` as well. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Oct 27 23:40:35 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Oct 2022 23:40:35 GMT Subject: RFR: 8290844: Add Skin.install() method [v15] In-Reply-To: References: Message-ID: <-BoFdgtVGhLv334O5DNbtQ8x4TAf57jgJNobzd4FbVM=.0a4c3691-6f70-4a0d-995e-899f65a4c0d1@github.com> On Thu, 27 Oct 2022 18:05:36 GMT, John Hendrikx 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 28 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge branch 'openjdk:master' into 8290844.skin.install >> - 8290844: unit tests >> - ... and 18 more: https://git.openjdk.org/jfx/compare/b3cfd555...3235d433 > > modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 78: > >> 76: * previous skin, if any, has been uninstalled via its {@link #dispose()} method. >> 77: * This method allows a Skin to register listeners, add child nodes, set >> 78: * required properties and/or event handlers. > > I don't see how it is relevant for this interface to know what happens to the previous skin. The interface should simply describe what is expected, and not go into detail here. > > Suggestion: > > * Called when the {@link Skin} is accepted for its control. The skin can now > * safely make changes to its associated control, like registering listeners, adding > * child nodes and modifying properties and event handlers. > * > *

    When the control calls this method, it guarantees a future call to {@link #dispose} > * when the skin is removed. I do think it's important, but I like John's wording of the second sentence. I'd rather not add the sentence about future call - there is no such guarantee. ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Thu Oct 27 23:40:35 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Oct 2022 23:40:35 GMT Subject: RFR: 8290844: Add Skin.install() method [v15] In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 18:21:53 GMT, John Hendrikx 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 28 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge branch 'openjdk:master' into 8290844.skin.install >> - 8290844: unit tests >> - ... and 18 more: https://git.openjdk.org/jfx/compare/b3cfd555...3235d433 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlTest.java line 816: > >> 814: SkinStub skin = new SkinStub(new ControlStub()); >> 815: c.setSkin(skin); >> 816: } > > Is Junit 5 availabe for this project? If so I'd recommend writing: > Suggestion: > > @Test > public void skinMustCorrespondToControl() { > SkinStub skin = new SkinStub(new ControlStub()); > assertThrows(IllegalArgumentException.class, () -> c.setSkin(skin)); > } We don't want to mix JUnit 4 and JUnit 5 in the same file, and it seems out of scope to change this existing test class to use Junit5. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Oct 27 23:40:35 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Oct 2022 23:40:35 GMT Subject: RFR: 8290844: Add Skin.install() method [v15] In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 23:30:39 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlTest.java line 816: >> >>> 814: SkinStub skin = new SkinStub(new ControlStub()); >>> 815: c.setSkin(skin); >>> 816: } >> >> Is Junit 5 availabe for this project? If so I'd recommend writing: >> Suggestion: >> >> @Test >> public void skinMustCorrespondToControl() { >> SkinStub skin = new SkinStub(new ControlStub()); >> assertThrows(IllegalArgumentException.class, () -> c.setSkin(skin)); >> } > > We don't want to mix JUnit 4 and JUnit 5 in the same file, and it seems out of scope to change this existing test class to use Junit5. Are we mixing? I believe the tests have been converted to JUnit5 some time ago, [JDK-8292678](https://bugs.openjdk.org/browse/JDK-8292678) at least in Eclipse. I think this is a valid change. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Oct 27 23:40:35 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Oct 2022 23:40:35 GMT Subject: RFR: 8290844: Add Skin.install() method [v15] In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 23:36:21 GMT, Andy Goryachev wrote: >> We don't want to mix JUnit 4 and JUnit 5 in the same file, and it seems out of scope to change this existing test class to use Junit5. > > Are we mixing? I believe the tests have been converted to JUnit5 some time ago, [JDK-8292678](https://bugs.openjdk.org/browse/JDK-8292678) at least in Eclipse. > I think this is a valid change. (and it was me who added @Test(expected=IllegalArgumentException.class) test) ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Oct 27 23:43:52 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Oct 2022 23:43:52 GMT Subject: RFR: 8290844: Add Skin.install() method [v17] In-Reply-To: References: Message-ID: > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290844: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/845/files - new: https://git.openjdk.org/jfx/pull/845/files/5ea8a5fe..b818719d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=16 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=15-16 Stats: 20 lines in 4 files changed: 2 ins; 2 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/845.diff Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845 PR: https://git.openjdk.org/jfx/pull/845 From jvos at openjdk.org Fri Oct 28 06:42:21 2022 From: jvos at openjdk.org (Johan Vos) Date: Fri, 28 Oct 2022 06:42:21 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v2] In-Reply-To: References: Message-ID: > The root problem is actually broader than stated in the JBS issue. This PR now translates screencoordinates from absolute coordinates into coordinates that take the platformScale into account. > The whole process is complicated by the fact that throughout our code, we use e.g. `x` and `y` without clearly stating if those are absolute, logical, screen or rendering coordinates. > I believe the most consistent approach is to have the different entry points (e.g. a Glass Window or a JFXPanel) to deal with platformScale before passing screen coordinates. This is already done in the Glass approach, and this PR does the same in JFXPanel. That means some code is duplicated, but since this is only about 12 lines, and said code lives in 2 different modules, I think it's not worth the hassle of moving that into e.g. the base module. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: address reviewer comments Fix detection on screen, based on awtScale factors ------------- Changes: - all: https://git.openjdk.org/jfx/pull/924/files - new: https://git.openjdk.org/jfx/pull/924/files/0458c740..af931bed Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=924&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=924&range=00-01 Stats: 13 lines in 1 file changed: 4 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/924.diff Fetch: git fetch https://git.openjdk.org/jfx pull/924/head:pull/924 PR: https://git.openjdk.org/jfx/pull/924 From jvos at openjdk.org Fri Oct 28 06:43:29 2022 From: jvos at openjdk.org (Johan Vos) Date: Fri, 28 Oct 2022 06:43:29 GMT Subject: RFR: 8294400: Provide media support for libavcodec version 59 [v2] In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 21:31:01 GMT, Alexander Matveev wrote: >> - Added support for libavcodec 59. >> - libavcodec 59 removed several deprecated APIs and avplugin code was updated to use replacement APIs instead. >> - No changes to avplugin when used with 58 or below. >> - Note: Support for libavcodec 59 was added based on ffmpeg only. libav does not have version 59. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8294400: Provide media support for libavcodec version 59 [v2] Works fine, but fails to build on win32. ------------- PR: https://git.openjdk.org/jfx/pull/932 From jvos at openjdk.org Fri Oct 28 06:58:31 2022 From: jvos at openjdk.org (Johan Vos) Date: Fri, 28 Oct 2022 06:58:31 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v2] In-Reply-To: <6E9g4Pg7kY2-APS31PUXCrxPS9da9_8BHdmsyusd_vE=.55ea53e4-1f6c-47a5-bfae-0f0a01ef8395@github.com> References: <6E9g4Pg7kY2-APS31PUXCrxPS9da9_8BHdmsyusd_vE=.55ea53e4-1f6c-47a5-bfae-0f0a01ef8395@github.com> Message-ID: On Thu, 20 Oct 2022 16:02:46 GMT, Andy Goryachev wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> address reviewer comments >> Fix detection on screen, based on awtScale factors > > modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 375: > >> 373: AffineTransform awtScales = graphicsConfiguration.getDefaultTransform(); >> 374: for (Screen screen : Screen.getScreens()) { >> 375: if ((Math.abs(screen.getPlatformX() - awtBounds.getX() * awtScales.getScaleX()) < 0.001) && > > minor: would it be better to create a standard method? > > isNearZero(double)? > > although the value of the constant might depend on a situation. it's a good question, and I don't know the "best" answer. What we want to achieve here is to get the FX Screen that matches the AWT graphicsConfiguration. I *assume* that the `screen.getPlatformX()` being equal to the `bounds.getX()` etc, but I have no evidence for it. I could not find clear definitions of either the JavaFX Screen parameters nor the AWT concepts. In practice, the approach above (which I tweaked because at least on my Ubuntu, there are differences between the JavaFX platformScale and the AWT scales) works correctly. However, as I don't see any clear definition, I think it is safe to account for rounding errors (given the mixture of int, float, doubles that are used in the different areas). > modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 385: > >> 383: } >> 384: >> 385: private Dimension2D getSwingToFxPixel(GraphicsConfiguration g, float wx, float wy) { > > minor: convertSwingToFxPixel() ? done. ------------- PR: https://git.openjdk.org/jfx/pull/924 From jvos at openjdk.org Fri Oct 28 07:04:18 2022 From: jvos at openjdk.org (Johan Vos) Date: Fri, 28 Oct 2022 07:04:18 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v2] In-Reply-To: <6E9g4Pg7kY2-APS31PUXCrxPS9da9_8BHdmsyusd_vE=.55ea53e4-1f6c-47a5-bfae-0f0a01ef8395@github.com> References: <6E9g4Pg7kY2-APS31PUXCrxPS9da9_8BHdmsyusd_vE=.55ea53e4-1f6c-47a5-bfae-0f0a01ef8395@github.com> Message-ID: On Thu, 20 Oct 2022 16:06:36 GMT, Andy Goryachev wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> address reviewer comments >> Fix detection on screen, based on awtScale factors > > modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 451: > >> 449: Dimension2D onScreen = getSwingToFxPixel(getGraphicsConfiguration(), e.getXOnScreen(), e.getYOnScreen()); >> 450: int fxXOnScreen = (int) onScreen.getWidth(); >> 451: int fxYOnScreen = (int) onScreen.getHeight(); > > question: should it be (int) or Math.round()? > also, coordinates can be negative - will it work then? I believe these values should be int in the first place. Otherwise, we have issues in JavaFX where we process them as ints. About negative coordinates: yes, that works. Is the question about using Dimension2D (width/height) for something that is actually a Point2D? We can use a Point2D here as well, but that class seems to have a bit more overhead than Dimension2D for this goal -- but I'm open to change it to Point2D. ------------- PR: https://git.openjdk.org/jfx/pull/924 From jhendrikx at openjdk.org Fri Oct 28 08:02:22 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 28 Oct 2022 08:02:22 GMT Subject: RFR: 8290844: Add Skin.install() method [v15] In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 23:36:58 GMT, Andy Goryachev wrote: >> Are we mixing? I believe the tests have been converted to JUnit5 some time ago, [JDK-8292678](https://bugs.openjdk.org/browse/JDK-8292678) at least in Eclipse. >> I think this is a valid change. > > (and it was me who added @Test(expected=IllegalArgumentException.class) test) I said it wrong, the asserts can be used in both 4 and 5, so `assertThrows` can always be used now that it is available (the upgrade to JUnit 5 also updated JUnit 4 to a version which supports `assertThrows`). ------------- PR: https://git.openjdk.org/jfx/pull/845 From jhendrikx at openjdk.org Fri Oct 28 08:05:38 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 28 Oct 2022 08:05:38 GMT Subject: RFR: 8290844: Add Skin.install() method [v15] In-Reply-To: <1xf9UAFXelAt2PX2rn7I9VMk2kvm7IJQ1jkfmkewq58=.45e87cfa-95c6-4be9-873d-2df230e0c570@github.com> References: <1xf9UAFXelAt2PX2rn7I9VMk2kvm7IJQ1jkfmkewq58=.45e87cfa-95c6-4be9-873d-2df230e0c570@github.com> Message-ID: On Thu, 27 Oct 2022 17:34:16 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 46: >> >>> 44: * and its {@code Skin}. Every {@code Skin} maintains a back reference to the >>> 45: * {@code Skinnable}. When required, this relationship is enforced when the {@code Skin} is set, >>> 46: * throwing an {@code IllegalArgumentException}. >> >> It looks like you removed too much. I think you need to retain the information about what will cause the exception. Maybe something like `,throwing an {@code IllegalArgumentException} if the return value of {@link Skin#getSkinnable()} is not the same as this {@code Skinnable}.`? > > corrected, thanks! I sort of left that out on purpose, since I think that's too much detail for an interface description. The relationship is enforced, and it's not up to the docs to describe the exact mechanism (or future mechanisms). ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Fri Oct 28 11:52:36 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Oct 2022 11:52:36 GMT Subject: RFR: 8294400: Provide media support for libavcodec version 59 [v2] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 06:39:40 GMT, Johan Vos wrote: > Works fine, but fails to build on win32. That is surprising since the libav changes are limited to Linux-specific code. Have you confirmed that the win32 build passes without this fix and fails with this fix? How does it fail? ------------- PR: https://git.openjdk.org/jfx/pull/932 From kcr at openjdk.org Fri Oct 28 11:57:30 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Oct 2022 11:57:30 GMT Subject: RFR: 8290844: Add Skin.install() method [v15] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 07:58:40 GMT, John Hendrikx wrote: >> (and it was me who added @Test(expected=IllegalArgumentException.class) test) > > I said it wrong, the asserts can be used in both 4 and 5, so `assertThrows` can always be used now that it is available (the upgrade to JUnit 5 also updated JUnit 4 to a version which supports `assertThrows`). In that case, this is fine. What I meant when I said we don't want to mix 4 and 5 in the same file is that we should not use some APIs from JUnit 4 (e.g., `org.junit.Assert`) and some from JUnit 5 (e.g., `org.junit.jupiter.api.Assertions`) in the same file. ------------- PR: https://git.openjdk.org/jfx/pull/845 From dlemmermann at gmail.com Fri Oct 28 12:43:34 2022 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Fri, 28 Oct 2022 14:43:34 +0200 Subject: Virtual Flow enhancements In-Reply-To: References: <7b5d420e-c81d-6cfa-78b5-349562751269@gmail.com> <3845162C-7988-45A2-A474-177286C3B343@gmail.com> Message-ID: <4E285C52-C692-4C03-992A-CC76B0E91A04@gmail.com> Looks like I missed this last replay from Johan. In my last email I was referring to a work-around where one VirtualFlow gets repositioned via scrollTo() method calls in response to changes in the other VirtualFlow. Not only are the rows alignments way off but updates are lagging behind. But let?s leave that behind for now and let?s try to find an existing property that would make our use-case work again. For the ?FlexGanttFX? use-case where I need to syncronize the scrolling of a TreeTableView and a ListView I would love to be able to simply bind the ?position? properties of those two controls with each other. That feels very intuitive to me. If both controls have the same number of rows and each row?s height matches the row?s height in the other control then this should work, but currently it does not. The ?position? property gets updated by the VirtualFlow. When the flow sets this property to a certain value then I would hope setting the same value from outside would place the virtual flow at the exact same position. Basically I am hoping that this is a bijective mapping but it is not ?. unless ? the user scrolled all the way down in both views. Then it becomes a bijective mapping. So I guess after having made all rows visible the calculations are based on hard facts (as in ?actual row height?) and not on estimates. To summarise the requirement: there should be a way to bind a property of VirtualFlow so that two instances with the same content can be scrolled in sync (content = same rows with same heights resulting in same total virtual height). Dirk > On 15 Sep 2022, at 21:20, Johan Vos wrote: > > > > On Wed, Sep 14, 2022 at 12:19 PM Dirk Lemmermann > wrote: > Hi, > > > FlexGanttFX used to make this work via bidirectional bindings of the properties of the vertical scrollbars of both VirtualFlows. With the latest fixes to the VirtualFlow the assumption that two identically populated VirtualFlows would provide identical values to the ScrollBar properties is no longer true. The attempt to bind the ?position? property also failed and a work-around that Johan provided also has not been successful, yet (a customer of mine is still evaluating it). > > I don't know what work-around you refer to, but I often point to public methods in VirtualFlow that, when properly combined, allow many usecases. I sometimes see code where the information about the positioning of elements in the VirtualFlow is obtained via the position of the scrollbar thumb, which seems a really odd way to get this info (and especially unreliable as the relation with the real positioning of cells is unspecified). There are other methods on VirtualFlow that imho are better suited for getting/setting information. > What I want to avoid is that we have 2 API's that almost achieve the same. Hence, before considering a new method or property, I think we should make sure that there is currently no existing (documented) way to achieve it. I am pretty sure there are cases that can not be solved with the existing set of API's, and those cases are exactly what I'm looking for. > > - Johan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Oct 28 13:54:40 2022 From: duke at openjdk.org (eduardsdv) Date: Fri, 28 Oct 2022 13:54:40 GMT Subject: RFR: 8295324: JavaFX: Blank pages when printing [v3] In-Reply-To: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com> References: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com> Message-ID: > This fixes a race condition between application and 'Print Job Thread' threads when printing. > > The race condition occurs when application thread calls `endJob()`, which in effect sets the `jobDone` flag to true, > and when the 'Print Job Thread' thread was in the `synchronized` block in `waitForNextPage()` at that time. > The 'Print Job Thread' thread checks `jobDone` flag after exiting the `synchronized` block and, if it is true, skips the last page. > > In this fix, not only the `jobDone` is checked, but also that there is no other page to be printed. > It was also needed to introduce a new flag 'jobCanceled', to skip the page if the printing was canceled by 'cancelJob()'. eduardsdv has updated the pull request incrementally with two additional commits since the last revision: - 8295324: Fix skipping of pages when printing This occurs in print(Graphics, PageFormat, int) if the 'jobDone' flag was previously set by the 'endJob()' method. - 8295324: Adjust the J2DPrinterJobTest The test now also checks for the second race condition around 'jobDone' flag, which is in the print(Graphics, PageFormat, int) method. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/916/files - new: https://git.openjdk.org/jfx/pull/916/files/fdec73d8..acd4825b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=916&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=916&range=01-02 Stats: 85 lines in 2 files changed: 47 ins; 18 del; 20 mod Patch: https://git.openjdk.org/jfx/pull/916.diff Fetch: git fetch https://git.openjdk.org/jfx pull/916/head:pull/916 PR: https://git.openjdk.org/jfx/pull/916 From duke at openjdk.org Fri Oct 28 14:26:45 2022 From: duke at openjdk.org (eduardsdv) Date: Fri, 28 Oct 2022 14:26:45 GMT Subject: RFR: 8295324: JavaFX: Blank pages when printing [v3] In-Reply-To: References: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com> Message-ID: On Fri, 28 Oct 2022 13:54:40 GMT, eduardsdv wrote: >> This fixes a race condition between application and 'Print Job Thread' threads when printing. >> >> The race condition occurs when application thread calls `endJob()`, which in effect sets the `jobDone` flag to true, >> and when the 'Print Job Thread' thread was in the `synchronized` block in `waitForNextPage()` at that time. >> The 'Print Job Thread' thread checks `jobDone` flag after exiting the `synchronized` block and, if it is true, skips the last page. >> >> In this fix, not only the `jobDone` is checked, but also that there is no other page to be printed. >> It was also needed to introduce a new flag 'jobCanceled', to skip the page if the printing was canceled by 'cancelJob()'. > > eduardsdv has updated the pull request incrementally with two additional commits since the last revision: > > - 8295324: Fix skipping of pages when printing > > This occurs in print(Graphics, PageFormat, int) if the 'jobDone' flag > was previously set by the 'endJob()' method. > - 8295324: Adjust the J2DPrinterJobTest > > The test now also checks for the second race condition around 'jobDone' > flag, which is in the print(Graphics, PageFormat, int) method. I found the second place with the race condition. It was in the print(Graphics g, PageFormat pf, int pageIndex) method. Also here "jobDone" was checked without checking if a page was pending. Please review. ------------- PR: https://git.openjdk.org/jfx/pull/916 From angorya at openjdk.org Fri Oct 28 15:42:05 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Oct 2022 15:42:05 GMT Subject: RFR: 8290844: Add Skin.install() method [v18] In-Reply-To: References: Message-ID: > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290844: spelling ------------- Changes: - all: https://git.openjdk.org/jfx/pull/845/files - new: https://git.openjdk.org/jfx/pull/845/files/b818719d..de347231 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=17 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=16-17 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/845.diff Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845 PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Fri Oct 28 16:17:00 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Oct 2022 16:17:00 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v2] In-Reply-To: References: <6E9g4Pg7kY2-APS31PUXCrxPS9da9_8BHdmsyusd_vE=.55ea53e4-1f6c-47a5-bfae-0f0a01ef8395@github.com> Message-ID: On Fri, 28 Oct 2022 07:01:02 GMT, Johan Vos wrote: >> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 451: >> >>> 449: Dimension2D onScreen = getSwingToFxPixel(getGraphicsConfiguration(), e.getXOnScreen(), e.getYOnScreen()); >>> 450: int fxXOnScreen = (int) onScreen.getWidth(); >>> 451: int fxYOnScreen = (int) onScreen.getHeight(); >> >> question: should it be (int) or Math.round()? >> also, coordinates can be negative - will it work then? > > I believe these values should be int in the first place. Otherwise, we have issues in JavaFX where we process them as ints. > About negative coordinates: yes, that works. Is the question about using Dimension2D (width/height) for something that is actually a Point2D? We can use a Point2D here as well, but that class seems to have a bit more overhead than Dimension2D for this goal -- but I'm open to change it to Point2D. No, what I meant is this: System.out.println("(int)-1.9999=" + (int)-1.9999 + " (int)Math.round(-1.9999)=" + (int)(Math.round(-1.9999))); prints (int)-1.9999=-1 (int)Math.round(-1.9999)=-2 i.e. typecast to int is equivalent to Math.ceil for negative values and Math.floor for positive. We probably should use Math.round(). This code should be better tested on Windows with a) second monitor positioned to the left of the main one, making its coordinates negative b) using fractional HiDPI scaling which is only available on Windows it seems And yes, I did not see Dimension2D - we probably should remove confusion and use Point2D (why does it have more overhead?) ------------- PR: https://git.openjdk.org/jfx/pull/924 From angorya at openjdk.org Fri Oct 28 16:17:04 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Oct 2022 16:17:04 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v2] In-Reply-To: <6E9g4Pg7kY2-APS31PUXCrxPS9da9_8BHdmsyusd_vE=.55ea53e4-1f6c-47a5-bfae-0f0a01ef8395@github.com> References: <6E9g4Pg7kY2-APS31PUXCrxPS9da9_8BHdmsyusd_vE=.55ea53e4-1f6c-47a5-bfae-0f0a01ef8395@github.com> Message-ID: On Thu, 20 Oct 2022 16:07:20 GMT, Andy Goryachev wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> address reviewer comments >> Fix detection on screen, based on awtScale factors > > modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 646: > >> 644: Dimension2D fxcoord = getSwingToFxPixel(getGraphicsConfiguration(), p.x, p.y); >> 645: screenX = (int)fxcoord.getWidth(); >> 646: screenY = (int)fxcoord.getHeight(); > > same question about negative coordinates. and Point2D :-) ------------- PR: https://git.openjdk.org/jfx/pull/924 From kcr at openjdk.org Fri Oct 28 16:25:28 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Oct 2022 16:25:28 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v2] In-Reply-To: References: <6E9g4Pg7kY2-APS31PUXCrxPS9da9_8BHdmsyusd_vE=.55ea53e4-1f6c-47a5-bfae-0f0a01ef8395@github.com> Message-ID: On Fri, 28 Oct 2022 16:13:31 GMT, Andy Goryachev wrote: >> I believe these values should be int in the first place. Otherwise, we have issues in JavaFX where we process them as ints. >> About negative coordinates: yes, that works. Is the question about using Dimension2D (width/height) for something that is actually a Point2D? We can use a Point2D here as well, but that class seems to have a bit more overhead than Dimension2D for this goal -- but I'm open to change it to Point2D. > > No, what I meant is this: > > System.out.println("(int)-1.9999=" + (int)-1.9999 + " (int)Math.round(-1.9999)=" + (int)(Math.round(-1.9999))); > prints > (int)-1.9999=-1 (int)Math.round(-1.9999)=-2 > > > i.e. typecast to int is equivalent to Math.ceil for negative values and Math.floor for positive. We probably should use Math.round(). > > This code should be better tested on Windows with > a) second monitor positioned to the left of the main one, making its coordinates negative > b) using fractional HiDPI scaling which is only available on Windows it seems > > And yes, I did not see Dimension2D - we probably should remove confusion and use Point2D (why does it have more overhead?) Depending on the desired result, we use `Math.floor`, `Math.ceil`, or `Math.round` -- it's important to pick the right one. But yes, using one of those is (almost always) better than just casting to `(int)` if the value might be negative. ------------- PR: https://git.openjdk.org/jfx/pull/924 From swpalmer at gmail.com Fri Oct 28 16:49:30 2022 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 28 Oct 2022 12:49:30 -0400 Subject: Virtual Flow enhancements In-Reply-To: <4E285C52-C692-4C03-992A-CC76B0E91A04@gmail.com> References: <7b5d420e-c81d-6cfa-78b5-349562751269@gmail.com> <3845162C-7988-45A2-A474-177286C3B343@gmail.com> <4E285C52-C692-4C03-992A-CC76B0E91A04@gmail.com> Message-ID: While reading this I was thinking of a similar, but not quite the same use case. A visual Diff program that is showing two versions of the same source file side-by-side. Scrolling both views in a synchronized way such that lines that are the same are aligned is a common feature, but since one file may have a different number of lines the two sides won't scroll exactly the same amount to keep the views where you want them. Regardless, the need for exact positioning between the two views exists. I haven't attempted to do this yet, but it is something that may come up soon in a project I'm working on. Knowing any relevant tricks or gotcha cases will be helpful. Cheers, Scott On Fri, Oct 28, 2022 at 8:43 AM Dirk Lemmermann wrote: > Looks like I missed this last replay from Johan. In my last email I was > referring to a work-around where one VirtualFlow gets repositioned via > scrollTo() method calls in response to changes in the other VirtualFlow. > Not only are the rows alignments way off but updates are lagging behind. > > But let?s leave that behind for now and let?s try to find an existing > property that would make our use-case work again. > > For the ?FlexGanttFX? use-case where I need to syncronize the scrolling > of a TreeTableView and a ListView I would love to be able to simply bind > the ?position? properties of those two controls with each other. That feels > very intuitive to me. If both controls have the same number of rows and > each row?s height matches the row?s height in the other control then this > should work, but currently it does not. > > The ?position? property gets updated by the VirtualFlow. When the flow > sets this property to a certain value then I would hope setting the same > value from outside would place the virtual flow at the exact same position. > Basically I am hoping that this is a bijective mapping but it is not ?. > unless ? the user scrolled all the way down in both views. Then it becomes > a bijective mapping. So I guess after having made all rows visible the > calculations are based on hard facts (as in ?actual row height?) and not on > estimates. > > To summarise the requirement: there should be a way to bind a property of > VirtualFlow so that two instances with the same content can be scrolled in > sync (content = same rows with same heights resulting in same total virtual > height). > > Dirk > > On 15 Sep 2022, at 21:20, Johan Vos wrote: > > > > On Wed, Sep 14, 2022 at 12:19 PM Dirk Lemmermann > wrote: > >> Hi, >> >> >> FlexGanttFX used to make this work via bidirectional bindings of the >> properties of the vertical scrollbars of both VirtualFlows. With the latest >> fixes to the VirtualFlow the assumption that two identically populated >> VirtualFlows would provide identical values to the ScrollBar properties is >> no longer true. The attempt to bind the ?position? property also failed and >> a work-around that Johan provided also has not been successful, yet (a >> customer of mine is still evaluating it). >> > > I don't know what work-around you refer to, but I often point to public > methods in VirtualFlow that, when properly combined, allow many usecases. I > sometimes see code where the information about the positioning of elements > in the VirtualFlow is obtained via the position of the scrollbar thumb, > which seems a really odd way to get this info (and especially unreliable as > the relation with the real positioning of cells is unspecified). There are > other methods on VirtualFlow that imho are better suited for > getting/setting information. > What I want to avoid is that we have 2 API's that almost achieve the same. > Hence, before considering a new method or property, I think we should make > sure that there is currently no existing (documented) way to achieve it. I > am pretty sure there are cases that can not be solved with the existing set > of API's, and those cases are exactly what I'm looking for. > > - Johan > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Oct 28 17:07:06 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Oct 2022 17:07:06 GMT Subject: RFR: 8295962: Reference to State in Task.java is ambiguous when building with JDK 19 In-Reply-To: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> References: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> Message-ID: <7VkfCvJSrZhzoDCTxCHJDGliUwKjM-WvZM3w7ZPmFvE=.81f1a506-7f1e-4afb-9ba6-e69f9329af80@github.com> On Wed, 26 Oct 2022 22:38:15 GMT, Kevin Rushforth wrote: > This PR replaces all occurrences of `State` with `Worker.State` in `javafx.concurrent.Task`. > > The `javafx.concurrent.Task` class implements `javafx.concurrent.Worker` and extends `java.util.concurrent.FutureTask`, which in turn implements `java.util.concurrent.Future`. > > `Worker` has a nested `State` enum, which is used in the implementing `Task` class without being qualified -- since `Task` is a `Worker`, we can just say `State` instead of `Worker.State`. > > [JDK-8277090](https://bugs.openjdk.org/browse/JDK-8277090) added a nested `State` enum to the `java.util.concurrent.Future` interface in JDK 19, so an unqualified reference to `State` from the `Task` class is now ambiguous when using JDK 19 to build. The javadoc task fails with an error (and the only reason the javac task doesn't is that we use `--release 17`). > > With this fix, a local build and test using JDK 19 passes. see 9 errors @kevinrushforth I am getting 9 errors: Description Resource Location The type State is ambiguous AbstractTask.java line 62 The type State is ambiguous TaskShim.java line 52 The type Task.State is ambiguous TaskCancelTest.java line 60 The type Task.State is ambiguous TaskCancelTest.java line 72 The type Task.State is ambiguous TaskCancelTest.java line 93 The type Task.State is ambiguous TaskCancelTest.java line 108 The type Task.State is ambiguous TaskCancelTest.java line 120 The type Task.State is ambiguous TaskCancelTest.java line 139 The type Task.State is ambiguous TaskSimpleTest.java line 68 ------------- Changes requested by angorya (Author). PR: https://git.openjdk.org/jfx/pull/933 From kcr at openjdk.org Fri Oct 28 17:48:33 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Oct 2022 17:48:33 GMT Subject: RFR: 8295962: Reference to State in Task.java is ambiguous when building with JDK 19 In-Reply-To: <7VkfCvJSrZhzoDCTxCHJDGliUwKjM-WvZM3w7ZPmFvE=.81f1a506-7f1e-4afb-9ba6-e69f9329af80@github.com> References: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> <7VkfCvJSrZhzoDCTxCHJDGliUwKjM-WvZM3w7ZPmFvE=.81f1a506-7f1e-4afb-9ba6-e69f9329af80@github.com> Message-ID: On Fri, 28 Oct 2022 17:03:48 GMT, Andy Goryachev wrote: > @kevinrushforth I am getting 9 errors: Thanks for reporting this, I'll fix them. I think I know why I missed them when I did my test run. ------------- PR: https://git.openjdk.org/jfx/pull/933 From kcr at openjdk.org Fri Oct 28 18:03:39 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Oct 2022 18:03:39 GMT Subject: RFR: 8295962: Reference to State in Task.java is ambiguous when building with JDK 19 In-Reply-To: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> References: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> Message-ID: On Wed, 26 Oct 2022 22:38:15 GMT, Kevin Rushforth wrote: > This PR replaces all occurrences of `State` with `Worker.State` in `javafx.concurrent.Task`. > > The `javafx.concurrent.Task` class implements `javafx.concurrent.Worker` and extends `java.util.concurrent.FutureTask`, which in turn implements `java.util.concurrent.Future`. > > `Worker` has a nested `State` enum, which is used in the implementing `Task` class without being qualified -- since `Task` is a `Worker`, we can just say `State` instead of `Worker.State`. > > [JDK-8277090](https://bugs.openjdk.org/browse/JDK-8277090) added a nested `State` enum to the `java.util.concurrent.Future` interface in JDK 19, so an unqualified reference to `State` from the `Task` class is now ambiguous when using JDK 19 to build. The javadoc task fails with an error (and the only reason the javac task doesn't is that we use `--release 17`). > > With this fix, a local build and test using JDK 19 passes. The reason I didn't catch these is that `gradle test` passes when using JDK 19, for the same reason that "gradle sdk" does: we compile classes for all modules except `javafx.swing` and the system tests with `--release 17`. When building the javadocs and when building `javafx.swing` and the system tests, we (necessarily) use `-source 17 -target 17` instead of `--release 17`. I'll bet your Eclipse test run does the same (or maybe doesn't specificy anything relating the target release). If I temporarily modify my build to use `-source 17 -target 17` for all modules, I also get errors. Conversely, if you add `--release 17` to your Eclipse options, you won't see the error. I'll still fix those tests to make it more future proof. ------------- PR: https://git.openjdk.org/jfx/pull/933 From kcr at openjdk.org Fri Oct 28 18:44:24 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Oct 2022 18:44:24 GMT Subject: RFR: 8295962: Reference to State in Task.java is ambiguous when building with JDK 19 [v2] In-Reply-To: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> References: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> Message-ID: > This PR replaces all occurrences of `State` with `Worker.State` in `javafx.concurrent.Task`. > > The `javafx.concurrent.Task` class implements `javafx.concurrent.Worker` and extends `java.util.concurrent.FutureTask`, which in turn implements `java.util.concurrent.Future`. > > `Worker` has a nested `State` enum, which is used in the implementing `Task` class without being qualified -- since `Task` is a `Worker`, we can just say `State` instead of `Worker.State`. > > [JDK-8277090](https://bugs.openjdk.org/browse/JDK-8277090) added a nested `State` enum to the `java.util.concurrent.Future` interface in JDK 19, so an unqualified reference to `State` from the `Task` class is now ambiguous when using JDK 19 to build. The javadoc task fails with an error (and the only reason the javac task doesn't is that we use `--release 17`). > > With this fix, a local build and test using JDK 19 passes. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Fix unit tests to use Worker.State rather than Task.State ------------- Changes: - all: https://git.openjdk.org/jfx/pull/933/files - new: https://git.openjdk.org/jfx/pull/933/files/cfaee2a5..bd46ce12 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=933&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=933&range=00-01 Stats: 12 lines in 4 files changed: 2 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/933.diff Fetch: git fetch https://git.openjdk.org/jfx pull/933/head:pull/933 PR: https://git.openjdk.org/jfx/pull/933 From angorya at openjdk.org Fri Oct 28 18:50:31 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Oct 2022 18:50:31 GMT Subject: RFR: 8295962: Reference to State in Task.java is ambiguous when building with JDK 19 [v2] In-Reply-To: References: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> Message-ID: On Fri, 28 Oct 2022 18:44:24 GMT, Kevin Rushforth wrote: >> This PR replaces all occurrences of `State` with `Worker.State` in `javafx.concurrent.Task`. >> >> The `javafx.concurrent.Task` class implements `javafx.concurrent.Worker` and extends `java.util.concurrent.FutureTask`, which in turn implements `java.util.concurrent.Future`. >> >> `Worker` has a nested `State` enum, which is used in the implementing `Task` class without being qualified -- since `Task` is a `Worker`, we can just say `State` instead of `Worker.State`. >> >> [JDK-8277090](https://bugs.openjdk.org/browse/JDK-8277090) added a nested `State` enum to the `java.util.concurrent.Future` interface in JDK 19, so an unqualified reference to `State` from the `Task` class is now ambiguous when using JDK 19 to build. The javadoc task fails with an error (and the only reason the javac task doesn't is that we use `--release 17`). >> >> With this fix, a local build and test using JDK 19 passes. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Fix unit tests to use Worker.State rather than Task.State please update copyright year in modified tests :-) ------------- Changes requested by angorya (Author). PR: https://git.openjdk.org/jfx/pull/933 From kcr at openjdk.org Fri Oct 28 19:32:33 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Oct 2022 19:32:33 GMT Subject: RFR: 8295962: Reference to State in Task.java is ambiguous when building with JDK 19 [v2] In-Reply-To: References: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> Message-ID: On Fri, 28 Oct 2022 18:46:17 GMT, Andy Goryachev wrote: > please update copyright year in modified tests :-) Sure. I generally don't manually update the copyright date (we run a script for that), but since I already did it for `Task.java`, I'll update it for the tests, too. ------------- PR: https://git.openjdk.org/jfx/pull/933 From kcr at openjdk.org Fri Oct 28 19:41:35 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Oct 2022 19:41:35 GMT Subject: RFR: 8295962: Reference to State in Task.java is ambiguous when building with JDK 19 [v3] In-Reply-To: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> References: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> Message-ID: > This PR replaces all occurrences of `State` with `Worker.State` in `javafx.concurrent.Task`. > > The `javafx.concurrent.Task` class implements `javafx.concurrent.Worker` and extends `java.util.concurrent.FutureTask`, which in turn implements `java.util.concurrent.Future`. > > `Worker` has a nested `State` enum, which is used in the implementing `Task` class without being qualified -- since `Task` is a `Worker`, we can just say `State` instead of `Worker.State`. > > [JDK-8277090](https://bugs.openjdk.org/browse/JDK-8277090) added a nested `State` enum to the `java.util.concurrent.Future` interface in JDK 19, so an unqualified reference to `State` from the `Task` class is now ambiguous when using JDK 19 to build. The javadoc task fails with an error (and the only reason the javac task doesn't is that we use `--release 17`). > > With this fix, a local build and test using JDK 19 passes. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: update copyright years ------------- Changes: - all: https://git.openjdk.org/jfx/pull/933/files - new: https://git.openjdk.org/jfx/pull/933/files/bd46ce12..81d50463 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=933&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=933&range=01-02 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/933.diff Fetch: git fetch https://git.openjdk.org/jfx pull/933/head:pull/933 PR: https://git.openjdk.org/jfx/pull/933 From angorya at openjdk.org Fri Oct 28 19:47:25 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Oct 2022 19:47:25 GMT Subject: RFR: 8295962: Reference to State in Task.java is ambiguous when building with JDK 19 [v3] In-Reply-To: References: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> Message-ID: On Fri, 28 Oct 2022 19:41:35 GMT, Kevin Rushforth wrote: >> This PR replaces all occurrences of `State` with `Worker.State` in `javafx.concurrent.Task`. >> >> The `javafx.concurrent.Task` class implements `javafx.concurrent.Worker` and extends `java.util.concurrent.FutureTask`, which in turn implements `java.util.concurrent.Future`. >> >> `Worker` has a nested `State` enum, which is used in the implementing `Task` class without being qualified -- since `Task` is a `Worker`, we can just say `State` instead of `Worker.State`. >> >> [JDK-8277090](https://bugs.openjdk.org/browse/JDK-8277090) added a nested `State` enum to the `java.util.concurrent.Future` interface in JDK 19, so an unqualified reference to `State` from the `Task` class is now ambiguous when using JDK 19 to build. The javadoc task fails with an error (and the only reason the javac task doesn't is that we use `--release 17`). >> >> With this fix, a local build and test using JDK 19 passes. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > update copyright years looks good in eclipse with jdk-19 ------------- Marked as reviewed by angorya (Author). PR: https://git.openjdk.org/jfx/pull/933 From angorya at openjdk.org Fri Oct 28 20:02:41 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Oct 2022 20:02:41 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v6] In-Reply-To: References: <3ENx-4GXr9i0N08c2eeDPzOOEDhJVGG5RWgHg4t_S9w=.e65f9e55-b2e1-4cd5-936b-85442cdbacff@github.com> Message-ID: On Thu, 27 Oct 2022 17:17:40 GMT, Kevin Rushforth 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 20 additional commits since the last revision: >> >> - 8294809: map change listener >> - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper >> - 8294809: generics >> - 8294809: is alive >> - Revert "8294809: removed weak listeners support" >> >> This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. >> - 8294809: removed weak listeners support >> - 8294809: use weak reference correctly this time >> - 8294809: tests >> - 8294809: remove >> - 8294809: change listener with callback >> - ... and 10 more: https://git.openjdk.org/jfx/compare/a4fc7a68...7a1fa625 > > modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 241: > >> 239: */ >> 240: // TODO I would like to deprecate and remove these methods, and replace them by listenerHelper().add**() >> 241: protected final void registerChangeListener(ObservableValue observable, Consumer> operation) { > > I don't think we want to deprecate this. It is part of the public API, so there would need to be a compelling reason to deprecate it. we can keep it, eventually replacing the implementation with ListenerHelper, see [JDK-8296076](https://bugs.openjdk.org/browse/JDK-8296076) ------------- PR: https://git.openjdk.org/jfx/pull/908 From angorya at openjdk.org Fri Oct 28 20:04:47 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Oct 2022 20:04:47 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v6] In-Reply-To: References: <3ENx-4GXr9i0N08c2eeDPzOOEDhJVGG5RWgHg4t_S9w=.e65f9e55-b2e1-4cd5-936b-85442cdbacff@github.com> Message-ID: On Thu, 27 Oct 2022 17:15:55 GMT, Kevin Rushforth 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 20 additional commits since the last revision: >> >> - 8294809: map change listener >> - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper >> - 8294809: generics >> - 8294809: is alive >> - Revert "8294809: removed weak listeners support" >> >> This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. >> - 8294809: removed weak listeners support >> - 8294809: use weak reference correctly this time >> - 8294809: tests >> - 8294809: remove >> - 8294809: change listener with callback >> - ... and 10 more: https://git.openjdk.org/jfx/compare/943ef2e9...7a1fa625 > > modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 222: > >> 220: * @since 20 >> 221: */ >> 222: protected ListenerHelper listenerHelper() { > > This would make it part of the public API, so you will need to find some other way to do this without adding anything to the public API surface. I *do* want this as public API. I can change the code to use an accessor, but it gets really ugly: ListenerHelper.get(PaginationSkin.this).addListChangeListener(getSkinnable().getStyleClass(), (ch) -> { Besides, what's the harm of adding a [better] public API? I do want ListenerHelper to be public anyway. ------------- PR: https://git.openjdk.org/jfx/pull/908 From angorya at openjdk.org Fri Oct 28 20:10:53 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Oct 2022 20:10:53 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v7] In-Reply-To: References: Message-ID: > Introduction > > There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class). > > This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance > https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java > > Proposal > > It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which: > > - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc. > - keeps track of the listeners and the corresponding ObservableValues > - provides a single disconnect() method to remove all the listeners in one go. > - optionally, it should be possible to add a lambda (Runnable) to a group of properties > - optionally, there should be a boolean flag to fire the lambda immediately > - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method > > Make it Public Later > > Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later. > > Where It Will Be Useful > > [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin" > and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler. > > https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft > > https://github.com/openjdk/jfx/pull/914 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8294809: no public api ------------- Changes: - all: https://git.openjdk.org/jfx/pull/908/files - new: https://git.openjdk.org/jfx/pull/908/files/7a1fa625..e78ed6db Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=05-06 Stats: 86 lines in 3 files changed: 66 ins; 8 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/908.diff Fetch: git fetch https://git.openjdk.org/jfx pull/908/head:pull/908 PR: https://git.openjdk.org/jfx/pull/908 From stuart.marks at oracle.com Fri Oct 28 21:56:23 2022 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 28 Oct 2022 14:56:23 -0700 Subject: [External] : Re: JDK-8091393: Observable collections for ObservableMap views In-Reply-To: References: <732c2991-b2e2-0048-e86d-b894fd95640c@bestsolution.at> <2cc3e30a-2b92-a78d-8b9d-f7f1a2aba155@gmail.com> Message-ID: Hi, I'm impressed you found that compatibility report. :-) The most severe compatibility issues indeed occur if the keySet(), values(), and entrySet() methods are overridden to have a covariant return type. Issues will arise with subclasses that already override any of those methods, either with the return types from Map, or with covariant overrides of their own. It's true that bridge methods will be generated if this is done, and they take care of the most common compatibility issues. However, there is a compatibility matrix to be explored. My compatibility analysis considered old-binary, recompiled-source, and modified-source cases for both a library that has an at-risk subclass as well as an application that uses that library subclass. Some startling things emerged. What pushed me over the edge to decide against covariant overrides (in this part of the Sequenced Collections JEP) was that the behavior of a class could change silently upon recompilation, even if the source code wasn't changed. Aside from this issue, there's a more fundamental semantic issue with the object design. If I have some ObservableMap implementation, presumably it provides a keySet() implementation that's not observable. If ObservableMap is changed to have the covariant overrides, this effectively imposes a new requirement that existing implementations cannot possibly fulfill. Sure, you could tinker things around so that things appear to work in some cases, but the semantics of doing this are highly questionable. Now JavaFX could decide go ahead with this anyway, for a couple reasons. One might be, JavaFX doesn't care as much as the JDK about compatibility. It's (mostly) a different project, and it might have different compatibility constraints. You folks need to decide that. A second reason might be because there are vanishingly few or zero implementations of ObservableMap "in the wild," so any incompatibility would not cause any actual problems. This is difficult, but it's possible to get some information by doing source code searches. (Unfortunately there appear to be several libraries out there that have something called "ObservableMap" which will complicate the analysis.) The alternative is to add observableKeySet/Values/EntrySet() default methods instead of covariant overrides. This is safer, but it does add some clutter to the API. s'marks On 10/26/22 1:24 PM, Nir Lisker wrote: > I'm CC'ing Stuart Marks who has recently dealt with a similar issue when working > on Sequenced Collections [1], and wrote a compatibility report [2] that?includes > an item?about covariant overrides ("Covariant Overrides of `SequencedMap` View > Collection Methods"), which is similar to what is discussed here. I contacted him > off list to get his insights into the risks involved here. > > To recap, ObservableMap inherits keySet(), entrySet() and values() from Map, which > return the standard Set and Collection interfaces. ObservableMap should provide > ObservableSet and perhaps the not-yet-existing ObservableCollection. There are 2 > options here: one is to add additional default methods to ObservableMap that > return observable collection, the second is to override the methods inherited from > Map and change the return value. The latter has some backwards compatibility > issues. It comes down to implementations of ObservableMap in the wild. I have yet > to see any, personally. JavaFX does not itself expose any of its implementations, > as ObservableMaps are obtained through FXCollections static methods. > > I'd like to continue this discussion about the API side. I have already had some > advances on the implementation. > > [1] https://openjdk.org/jeps/431 > [2] https://bugs.openjdk.org/browse/JDK-8266572 > > On Tue, May 31, 2022 at 12:02 AM Nir Lisker wrote: > > Then?maybe a solution would be around adding new methods like > observableKeySet(). These will need to be default methods, and the > implementation could test if keySet() already returns an ObservableSet, in > which case it returns it, and if not it wraps the Set in an > ObservableSetWrapper or something like that. > > On Mon, May 30, 2022 at 11:50 AM John Hendrikx wrote: > > Sorry, I misunderstood, I missed that the methods weren't already > defined in ObservableMap, so no existing signature is changed. > > --John > > On 30/05/2022 09:39, Tom Schindl wrote: > > Hi, > > > > Well the binary compat IMHO is not a problem. If your subtype > > overwrites the return type of a method the compiler will inserts a > > bridge method: > > > > Take this example > > > > package bla; > > > > import java.util.ArrayList; > > import java.util.Collection; > > import java.util.List; > > > > public class Test { > > ????public interface IB { > > ??????? public Collection get(); > > ????} > > > > ????public interface I extends IB { > > ??????? public List get(); > > ????} > > > > ????public class C implements I { > > ??????? public ArrayList get() { > > ??????????? return new ArrayList(); > > ??????? } > > ????} > > } > > > > if you look at C with javap you'll notice > > > > Compiled from "Test.java" > > public class bla.Test$C implements bla.Test$I { > > ? final bla.Test this$0; > > ? public bla.Test$C(bla.Test); > > ? public java.util.ArrayList get(); > > ? public java.util.Collection get(); > > ? public java.util.List get(); > > } > > > > > > The problem is more that if someone directly implemented ObservableMap > > him/her self that it won't compile anymore. So it is a source > > incompatible change. > > > > Tom > > > > Am 30.05.22 um 08:58 schrieb John Hendrikx: > >> It's not binary compatible, as changing the return type results in a > >> new method that compiled code won't be able to find. > >> > >> See also "change result type (including void)" here: > >> > https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interfaces_-_API_methods > > > >> > >> > >> --John > >> > >> On 30/05/2022 03:22, Nir Lisker wrote: > >>> Hi, > >>> > >>> Picking up an old issue, JDK-8091393 [1], I went ahead and looked at > >>> the > >>> work needed to implement it. > >>> > >>> keySet() and entrySet() can both be made to return ObservableSet rather > >>> easily. values() will probably require an ObservableCollection type. > >>> > >>> Before discussing these details, my question is: is it backwards > >>> compatible > >>> to require that these? methods now return a more refined type? I > >>> think that > >>> it will break implementations of ObservableMap out in the wild if it > >>> overrides these methods in Map. What is the assessment here? > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8091393 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Oct 28 23:14:48 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Oct 2022 23:14:48 GMT Subject: RFR: 8290844: Add Skin.install() method [v18] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 15:42:05 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290844: spelling The doc changes look good to me, except for one thing highlighted below. modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 75: > 73: > 74: /** > 75: * Called once when {@link Skin} is set, or after the I think the "or" is wrong here. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Fri Oct 28 23:14:49 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Oct 2022 23:14:49 GMT Subject: RFR: 8290844: Add Skin.install() method [v18] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 22:58:00 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8290844: spelling > > modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 75: > >> 73: >> 74: /** >> 75: * Called once when {@link Skin} is set, or after the > > I think the "or" is wrong here. Called once when {@link Skin} is *initially* set, or after the... ? ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Fri Oct 28 23:46:31 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Oct 2022 23:46:31 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v2] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 06:42:21 GMT, Johan Vos wrote: >> The root problem is actually broader than stated in the JBS issue. This PR now translates screencoordinates from absolute coordinates into coordinates that take the platformScale into account. >> The whole process is complicated by the fact that throughout our code, we use e.g. `x` and `y` without clearly stating if those are absolute, logical, screen or rendering coordinates. >> I believe the most consistent approach is to have the different entry points (e.g. a Glass Window or a JFXPanel) to deal with platformScale before passing screen coordinates. This is already done in the Glass approach, and this PR does the same in JFXPanel. That means some code is duplicated, but since this is only about 12 lines, and said code lives in 2 different modules, I think it's not worth the hassle of moving that into e.g. the base module. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > address reviewer comments > Fix detection on screen, based on awtScale factors I think this looks basically correct, although I did leave a couple questions / comments inline. I'll test it next week. modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 387: > 385: private Dimension2D convertSwingToFxPixel(GraphicsConfiguration g, float wx, float wy) { > 386: float newx, newy; > 387: Screen screen = findScreen(getGraphicsConfiguration()); Did you mean to use the passed in graphics config, `g`? If not, you might remove the `g` parameter, since it is otherwise unused. modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 400: > 398: float py = screen.getPlatformY(); > 399: newx = sx + (wx - px) * awtScaleX / pScaleX; > 400: newy = sy + (wy - py) * awtScaleY / pScaleY; `px` and `py` are already (scaled) "FX" coordinates, so I'm not sure AWT scale should be applied to that. I might be missing something here. ------------- PR: https://git.openjdk.org/jfx/pull/924 From kcr at openjdk.org Fri Oct 28 23:46:31 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Oct 2022 23:46:31 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v2] In-Reply-To: References: <6E9g4Pg7kY2-APS31PUXCrxPS9da9_8BHdmsyusd_vE=.55ea53e4-1f6c-47a5-bfae-0f0a01ef8395@github.com> Message-ID: On Fri, 28 Oct 2022 16:23:10 GMT, Kevin Rushforth wrote: >> No, what I meant is this: >> >> System.out.println("(int)-1.9999=" + (int)-1.9999 + " (int)Math.round(-1.9999)=" + (int)(Math.round(-1.9999))); >> prints >> (int)-1.9999=-1 (int)Math.round(-1.9999)=-2 >> >> >> i.e. typecast to int is equivalent to Math.ceil for negative values and Math.floor for positive. We probably should use Math.round(). >> >> This code should be better tested on Windows with >> a) second monitor positioned to the left of the main one, making its coordinates negative >> b) using fractional HiDPI scaling which is only available on Windows it seems >> >> And yes, I did not see Dimension2D - we probably should remove confusion and use Point2D (why does it have more overhead?) > > Depending on the desired result, we use `Math.floor`, `Math.ceil`, or `Math.round` -- it's important to pick the right one. > > But yes, using one of those is (almost always) better than just casting to `(int)` if the value might be negative. I think in this case, `Math.floor()` is what you want. I wonder, though, whether it needs to be converted to an `int` at all? It looks like everywhere it is used, it can be kept as a double. Btw, I almost wrote a comment asking a question as to whether you were using the values of x, y, width, and height correctly, because I got confused that you were using a Dimension to hold an x,y point. If you decide to keep it as a Dimension, I might suggest adding a clarifying comment. ------------- PR: https://git.openjdk.org/jfx/pull/924 From kcr at openjdk.org Sat Oct 29 00:10:31 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 29 Oct 2022 00:10:31 GMT Subject: RFR: 8290844: Add Skin.install() method [v18] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 23:11:52 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 75: >> >>> 73: >>> 74: /** >>> 75: * Called once when {@link Skin} is set, or after the >> >> I think the "or" is wrong here. > > Called once when {@link Skin} is *initially* set, or after the... ? I would just remove the "or". It's correct without it, and less wordy. ------------- PR: https://git.openjdk.org/jfx/pull/845 From mik3hall at gmail.com Sat Oct 29 03:00:40 2022 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 28 Oct 2022 22:00:40 -0500 Subject: SceneBuilder OS/X DMG's Message-ID: Probably off-topic to this list but maybe someone else is somewhat curious about this as well. I noticed a slight error in jpackage dmg builds. The Applications folder icon shows as a path - /Applications - instead of just the file name - Applications. I also noticed that the SceneBuilder dmg?s show this. I had looked at something similar sometime ago. Thought it was a bug, turned out to be my error if I remember right (something other than the /Applications). Looking again at what I have from then one thing that occurred to me was that it would fairly simple to customize the dmg background image as in? http://mikehall.pairserver.com/SceneBuilder-1.0.dmg Doing it for SceneBuilder seemed like it could be interesting. It might make a jpackage enhancement request to allow this, but you might not want to overload the CLI command with too much platform specific. What I use to create the dmg is based on what jpackage appears to do, or at least did back then? http://mikehall.pairserver.com/dmgsetup.dmg From a directory containing the files you would do ./dmgsetup.sh The current version has AppleScript that I think is supposed to actually give the localized version of the Applications file name. For me it simply, correctly, shows as Applications. I would be curious to know if anyone who has a localized version of this file name tries it that it correctly shows the file name for them. I?m not sure if anyone ever does this or would want to. But possibly even jpackage does, I don?t know. To undo this you would need to change in DMGSetup.scpt? set DEPLOY_APPLICATION_NAME to displayed name of (path to applications folder) -- i18n name make new alias file at POSIX file DEPLOY_VOLUME_URL to POSIX file DEPLOY_INSTALL_LOCATION with properties {name:DEPLOY_APPLICATION_NAME} To simply make new alias file at POSIX file DEPLOY_VOLUME_URL to POSIX file DEPLOY_INSTALL_LOCATION with properties {name:?Applications?} For jpackage the upper case variables are programmatically substituted, I set them as AppleScript variables. If you want to simply correct the /Applications but use the same jpackage background image I include that - background_dmg.tiff You would need to change set DEPLOY_BG_FILE to cwd & "/background.png? To set DEPLOY_BG_FILE to cwd & ?/background_dmg.tiff? Script Editor in the Utilities folder would probably be best for script changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Mon Oct 31 16:42:34 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 31 Oct 2022 16:42:34 GMT Subject: RFR: 8290844: Add Skin.install() method [v19] In-Reply-To: References: Message-ID: > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290844: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/845/files - new: https://git.openjdk.org/jfx/pull/845/files/de347231..627ae3c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=18 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=17-18 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/845.diff Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845 PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Mon Oct 31 16:42:34 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 31 Oct 2022 16:42:34 GMT Subject: RFR: 8290844: Add Skin.install() method [v18] In-Reply-To: References: Message-ID: On Sat, 29 Oct 2022 00:06:38 GMT, Kevin Rushforth wrote: >> Called once when {@link Skin} is *initially* set, or after the... ? > > I would just remove the "or". It's correct without it, and less wordy. Thank you @kevinrushforth for suggesting an alternative (offline). ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Mon Oct 31 16:45:51 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 31 Oct 2022 16:45:51 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v8] In-Reply-To: References: Message-ID: > Introduction > > There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class). > > This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance > https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java > > Proposal > > It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which: > > - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc. > - keeps track of the listeners and the corresponding ObservableValues > - provides a single disconnect() method to remove all the listeners in one go. > - optionally, it should be possible to add a lambda (Runnable) to a group of properties > - optionally, there should be a boolean flag to fire the lambda immediately > - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method > > Make it Public Later > > Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later. > > Where It Will Be Useful > > [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin" > and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler. > > https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft > > https://github.com/openjdk/jfx/pull/914 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8294809: whitespace ------------- Changes: - all: https://git.openjdk.org/jfx/pull/908/files - new: https://git.openjdk.org/jfx/pull/908/files/e78ed6db..e0e0aabb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/908.diff Fetch: git fetch https://git.openjdk.org/jfx pull/908/head:pull/908 PR: https://git.openjdk.org/jfx/pull/908 From kcr at openjdk.org Mon Oct 31 16:50:40 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 31 Oct 2022 16:50:40 GMT Subject: RFR: 8290844: Add Skin.install() method [v19] In-Reply-To: References: Message-ID: On Mon, 31 Oct 2022 16:42:34 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290844: review comments All looks good to me. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/845 From prr at openjdk.org Mon Oct 31 21:37:28 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 31 Oct 2022 21:37:28 GMT Subject: RFR: 8295327: JavaFX - IllegalArgumentException when printing with margins equal to 0 Message-ID: If floating point error caused a small negative value in the conversions needed from ISO to US measurements, then this will cause the IAE reported. The code doing the rounding should not have used Math.abs() ------------- Commit messages: - 8295327 Changes: https://git.openjdk.org/jfx/pull/934/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=934&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295327 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/934.diff Fetch: git fetch https://git.openjdk.org/jfx pull/934/head:pull/934 PR: https://git.openjdk.org/jfx/pull/934