From duke at openjdk.java.net Tue Mar 1 02:12:20 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Tue, 1 Mar 2022 02:12:20 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v6] In-Reply-To: References: <2UjlkEsmOJ_IiYMWbdQJAbUpknJSQwUA0NBv_JXLhhw=.48437588-79ac-466d-80aa-a641e60dde7d@github.com> Message-ID: On Mon, 28 Feb 2022 13:58:03 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Add Review Changes > > modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindow.cpp line 851: > >> 849: >> 850: // FIXME: We should consider supporting access/modification to local storage >> 851: // after calling window.close(). See . > > The change of moving this block back here looks good. You can delete the obsolete comment now, right? agree > modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 142: > >> 140: }); >> 141: } >> 142: } > > Minor: can you restore the newline at the end of this file? done ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Tue Mar 1 02:12:24 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Tue, 1 Mar 2022 02:12:24 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v5] In-Reply-To: References: Message-ID: <8SMdFfZ_V6VsVCkV9Lay5Q35f89EGPRQU-mqOfGKA1U=.fcddb2a0-5862-4201-8185-9ca99ec539a4@github.com> On Mon, 28 Feb 2022 14:53:39 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Add Review Changes > > modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 55: > >> 53: >> 54: private static final File LOCAL_STORAGE_DIR = new File("LocalStorageDir"); >> 55: private static final File PRE_LOCKED = new File("zoo_local_storage"); > >> LOCAL_STORAGE_DIR is used by web engine , to store local data in this case > > Yes, `LOCAL_STORAGE_DIR` is needed. I only meant that `PRE_LOCKED` was unused. GitHub decided to highlight both lines. done ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Tue Mar 1 02:42:54 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Tue, 1 Mar 2022 02:42:54 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v7] In-Reply-To: References: Message-ID: > Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. > Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) > "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Clean up test and fix ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/703/files - new: https://git.openjdk.java.net/jfx/pull/703/files/f320a013..8ba34a5d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=05-06 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/703/head:pull/703 PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Tue Mar 1 03:09:21 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Tue, 1 Mar 2022 03:09:21 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v5] In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 15:10:27 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> New chnages for line test > > tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 57: > >> 55: private static final CountDownLatch launchLatch = new CountDownLatch(1); >> 56: private static final int LINE_THICKNESS = 20; >> 57: private static final int SKIP_TEXT_BOUNDARY = 32; > > What does this constant represent? LINE_THICKNESS is thickness that is also in html test code. SKIP_TEXT_BOUNDARY is used to skip boundary at the end of line. ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Tue Mar 1 03:24:58 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Tue, 1 Mar 2022 03:24:58 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v5] In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 15:12:37 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> New chnages for line test > > tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 168: > >> 166: int width = (int)webView.getEngine().executeScript("document.getElementsByTagName('div')[0].getBoundingClientRect().width"); >> 167: >> 168: int line_start_x = start_x; > > You might want to add a small amount (`DELTA`?) to avoid sampling at the edge. In test html , the margin and padding is 0 px. it would be ok to add DELTA, done > tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 173: > >> 171: String line_color = "rgba(0,0,0,255)"; // color of line >> 172: System.out.println(line_end_x); >> 173: System.out.println(line_start_y); > > Once you are done debugging the test, you can remove these print statements. ok, > tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 177: > >> 175: for (int x = line_start_x; x < line_end_x; x++) { >> 176: String color = colorToString(pr.getColor(x, line_start_y)); >> 177: assertEquals(color, line_color); > > The arguments are backwards (the expected value goes first). done ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Tue Mar 1 03:24:57 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Tue, 1 Mar 2022 03:24:57 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v6] In-Reply-To: References: Message-ID: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: PR review changes applied ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/731/files - new: https://git.openjdk.java.net/jfx/pull/731/files/29916450..5ab81018 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=731&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=731&range=04-05 Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/731.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/731/head:pull/731 PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Tue Mar 1 06:12:59 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Tue, 1 Mar 2022 06:12:59 GMT Subject: RFR: 8282093: LineChart path incorrect when outside lower bound [v2] In-Reply-To: References: Message-ID: > This regression was caused in PR #667 in which I didn't take into account the lower bounds. I have added more tests and one manual test along with the fix. The manual test can be used to identify any future issues with paths outside lower and upper bounds easily. Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: Improve layout in manual test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/744/files - new: https://git.openjdk.java.net/jfx/pull/744/files/ebc31fe1..bc0149f9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=744&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=744&range=00-01 Stats: 23 lines in 1 file changed: 15 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/744.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/744/head:pull/744 PR: https://git.openjdk.java.net/jfx/pull/744 From duke at openjdk.java.net Tue Mar 1 06:19:04 2022 From: duke at openjdk.java.net (Hima Bindu Meda) Date: Tue, 1 Mar 2022 06:19:04 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down [v4] In-Reply-To: References: Message-ID: > Basically, buttons property is a mask which represents the button/buttons clicked on the mouse. > It is observed that event.buttons property is set to 0 when there is mouse press or drag event.This behaviour is observed only with javafx webView.Other browsers set the buttons property to 1, when there is mouse press or drag. > The issue happens because the buttons property is not updated in the framework. > Added implementation to update and propagate the buttons property from javafx platform to native webkit.Added a robot test case for the same. > Performed sanity testing with the added implementation and the buttons property is compliant with the specification mentioned in https://w3c.github.io/pointerevents/#the-buttons-property. Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: add stage show event listener ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/742/files - new: https://git.openjdk.java.net/jfx/pull/742/files/84b7184f..b3f4d9a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=742&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=742&range=02-03 Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/742.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/742/head:pull/742 PR: https://git.openjdk.java.net/jfx/pull/742 From duke at openjdk.java.net Tue Mar 1 07:03:16 2022 From: duke at openjdk.java.net (Hima Bindu Meda) Date: Tue, 1 Mar 2022 07:03:16 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down [v3] In-Reply-To: References: <1VlHBWzNOkmW8mn-aMTlD2QG1ChyY1VnOT45_qZkikE=.98296e33-99d5-4cf2-8698-ec5eb0f5dc17@github.com> Message-ID: On Mon, 28 Feb 2022 09:06:30 GMT, Ambarish Rapte wrote: >> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: >> >> Use ESC key so that the popup, if any, disappears > > tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 113: > >> 111: String URL = this.getClass().getResource("pointerEvent.html").toString(); >> 112: webEngine.load( URL); >> 113: webView.getEngine().getLoadWorker().stateProperty().addListener((ov, o, n) -> { > > The listener ideally should be added before calling `load()`. (before line 111) done ------------- PR: https://git.openjdk.java.net/jfx/pull/742 From arapte at openjdk.java.net Tue Mar 1 09:12:15 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 1 Mar 2022 09:12:15 GMT Subject: [jfx11u] RFR: 8278980: Update WebKit to 613.1 In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 16:46:36 GMT, Kevin Rushforth wrote: > Nearly clean backport to `jfx11u` (the only conflict was in the copyright years in one of the unit tests). I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. Verified that the backport is clean. and there was no diff except copyright year. ------------- PR: https://git.openjdk.java.net/jfx11u/pull/77 From arapte at openjdk.java.net Tue Mar 1 09:45:15 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 1 Mar 2022 09:45:15 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down [v4] In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 06:19:04 GMT, Hima Bindu Meda wrote: >> Basically, buttons property is a mask which represents the button/buttons clicked on the mouse. >> It is observed that event.buttons property is set to 0 when there is mouse press or drag event.This behaviour is observed only with javafx webView.Other browsers set the buttons property to 1, when there is mouse press or drag. >> The issue happens because the buttons property is not updated in the framework. >> Added implementation to update and propagate the buttons property from javafx platform to native webkit.Added a robot test case for the same. >> Performed sanity testing with the added implementation and the buttons property is compliant with the specification mentioned in https://w3c.github.io/pointerevents/#the-buttons-property. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > add stage show event listener Looks good to me, verified on Windows and Mac. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/742 From arapte at openjdk.java.net Tue Mar 1 13:13:11 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 1 Mar 2022 13:13:11 GMT Subject: [jfx11u] RFR: 8265399: Update to Visual Studio 2019 version 16.9.3 In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 16:07:10 GMT, Kevin Rushforth wrote: > Update `jfx11u` to the same version of VS2019 (16.9.3) that is used in mainline jfx. I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/76 From arapte at openjdk.java.net Tue Mar 1 14:45:13 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 1 Mar 2022 14:45:13 GMT Subject: [jfx11u] RFR: 8278980: Update WebKit to 613.1 In-Reply-To: References: Message-ID: <9RF951NLcGPxLBynWYTUqGMytkkylUxMi0gxKUonKGk=.98762897-cf87-4889-9211-d452f90e0309@github.com> On Mon, 28 Feb 2022 16:46:36 GMT, Kevin Rushforth wrote: > Nearly clean backport to `jfx11u` (the only conflict was in the copyright years in one of the unit tests). I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/77 From kcr at openjdk.java.net Tue Mar 1 15:00:17 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 1 Mar 2022 15:00:17 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down [v4] In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 06:19:04 GMT, Hima Bindu Meda wrote: >> Basically, buttons property is a mask which represents the button/buttons clicked on the mouse. >> It is observed that event.buttons property is set to 0 when there is mouse press or drag event.This behaviour is observed only with javafx webView.Other browsers set the buttons property to 1, when there is mouse press or drag. >> The issue happens because the buttons property is not updated in the framework. >> Added implementation to update and propagate the buttons property from javafx platform to native webkit.Added a robot test case for the same. >> Performed sanity testing with the added implementation and the buttons property is compliant with the specification mentioned in https://w3c.github.io/pointerevents/#the-buttons-property. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > add stage show event listener Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/742 From duke at openjdk.java.net Tue Mar 1 16:04:12 2022 From: duke at openjdk.java.net (Hima Bindu Meda) Date: Tue, 1 Mar 2022 16:04:12 GMT Subject: Integrated: 8278759 : PointerEvent: buttons property set to 0 when mouse down In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 18:46:21 GMT, Hima Bindu Meda wrote: > Basically, buttons property is a mask which represents the button/buttons clicked on the mouse. > It is observed that event.buttons property is set to 0 when there is mouse press or drag event.This behaviour is observed only with javafx webView.Other browsers set the buttons property to 1, when there is mouse press or drag. > The issue happens because the buttons property is not updated in the framework. > Added implementation to update and propagate the buttons property from javafx platform to native webkit.Added a robot test case for the same. > Performed sanity testing with the added implementation and the buttons property is compliant with the specification mentioned in https://w3c.github.io/pointerevents/#the-buttons-property. This pull request has now been integrated. Changeset: 2e8a4a5e Author: Hima Bindu Meda Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/2e8a4a5e97bb88a5807ae5fe075b98e1d54a4ca0 Stats: 302 lines in 8 files changed: 293 ins; 1 del; 8 mod 8278759: PointerEvent: buttons property set to 0 when mouse down Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/742 From arapte at openjdk.java.net Tue Mar 1 16:58:12 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 1 Mar 2022 16:58:12 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v7] In-Reply-To: References: Message-ID: <8oyi3sae627__Ck773Bn9es7C4VGnSIt2TL6W5UpF-E=.94bb23d7-3405-4019-8e96-0434df691c38@github.com> On Tue, 1 Mar 2022 02:42:54 GMT, Jay Bhaskar wrote: >> Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. >> Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) >> "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Clean up test and fix The fix looks good, suggesting a minor change in test and a change in `DOMWindow.cpp` The JavaFX specific changes in the shared code should be enclosed inside `#if PLATFORM(JAVA)` macro. modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindow.cpp line 850: > 848: return Exception { SecurityError }; > 849: > 850: if (m_localStorage) Let's enclose this change in `#if PLATFORM(JAVA)` macro. It makes easy to identify Java platform specific changes and handle merging when updating WebKit. modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 49: > 47: import javafx.concurrent.Worker; > 48: import javafx.scene.web.WebView; > 49: import javafx.scene.web.WebEngine; Several import statements can be removed. Only below imports are sufficient to run the test, others can be removed. import static org.junit.Assert.assertEquals; import static org.junit.Assert.assertTrue; import static org.junit.Assert.assertNotNull; import org.junit.AfterClass; import org.junit.Test; import java.io.File; import java.io.IOException; import javafx.scene.web.WebView; import javafx.scene.web.WebEngine; ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/703 From kcr at openjdk.java.net Thu Mar 3 01:21:12 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Mar 2022 01:21:12 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v6] In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 03:24:57 GMT, Jay Bhaskar wrote: >> Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. >> Solution: Do not add thickness to the y position of end point of line. >> Start Point(x,y) ----------End Point(x + width, 0) > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > PR review changes applied The test fails for me on both Mac and Windows because the scene is too small. It looks like the earlier changes you had made (or were in the process of making) got lost. See below. When I eliminate the setting of the size on the stage and construct the scene with a size of `150,100` it works on both platforms. tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 108: > 106: Platform.runLater(() -> { > 107: webView = new WebView(); > 108: Scene scene = new Scene(webView); It looks like you lost the earlier changes we had discussed. You should set the size here to _at least_ `150,100`. ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From kcr at openjdk.java.net Thu Mar 3 01:21:13 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Mar 2022 01:21:13 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v3] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 02:41:13 GMT, Jay Bhaskar wrote: >> tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 75: >> >>> 73: this.primaryStage = primaryStage; >>> 74: this.primaryStage.setWidth(80); >>> 75: this.primaryStage.setHeight(60); >> >> Minor: Since you set the size of the Scene later on, you don't need to set it here. > > This would be remain same , i would not set size later It looks like you lost the earlier changes we had discussed. You should not set the size here (and certainly not to this small of a value). ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From kcr at openjdk.java.net Thu Mar 3 15:48:06 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Mar 2022 15:48:06 GMT Subject: [jfx11u] RFR: 8265399: Update to Visual Studio 2019 version 16.9.3 In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 16:07:10 GMT, Kevin Rushforth wrote: > Update `jfx11u` to the same version of VS2019 (16.9.3) that is used in mainline jfx. I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. Pending a second reviewer. @tiainen Have you had a chance to do a test build of jfx11u with VS 2019? ------------- PR: https://git.openjdk.java.net/jfx11u/pull/76 From jbhaskar at openjdk.java.net Thu Mar 3 17:08:49 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Thu, 3 Mar 2022 17:08:49 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v8] In-Reply-To: References: Message-ID: > Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. > Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) > "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Restore original , and new changes wrapped with define JAVA ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/703/files - new: https://git.openjdk.java.net/jfx/pull/703/files/8ba34a5d..1b4d7751 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=06-07 Stats: 27 lines in 2 files changed: 13 ins; 11 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/703/head:pull/703 PR: https://git.openjdk.java.net/jfx/pull/703 From jbhaskar at openjdk.java.net Thu Mar 3 17:08:52 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Thu, 3 Mar 2022 17:08:52 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v7] In-Reply-To: <8oyi3sae627__Ck773Bn9es7C4VGnSIt2TL6W5UpF-E=.94bb23d7-3405-4019-8e96-0434df691c38@github.com> References: <8oyi3sae627__Ck773Bn9es7C4VGnSIt2TL6W5UpF-E=.94bb23d7-3405-4019-8e96-0434df691c38@github.com> Message-ID: On Tue, 1 Mar 2022 10:00:58 GMT, Ambarish Rapte wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Clean up test and fix > > modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindow.cpp line 850: > >> 848: return Exception { SecurityError }; >> 849: >> 850: if (m_localStorage) > > Let's enclose this change in `#if PLATFORM(JAVA)` macro. It makes easy to identify Java platform specific changes and handle merging when updating WebKit. done > modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 49: > >> 47: import javafx.concurrent.Worker; >> 48: import javafx.scene.web.WebView; >> 49: import javafx.scene.web.WebEngine; > > Several import statements can be removed. Only below imports are sufficient to run the test, others can be removed. > > import static org.junit.Assert.assertEquals; > import static org.junit.Assert.assertTrue; > import static org.junit.Assert.assertNotNull; > import org.junit.AfterClass; > import org.junit.Test; > > import java.io.File; > import java.io.IOException; > > import javafx.scene.web.WebView; > import javafx.scene.web.WebEngine; done ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From jbhaskar at openjdk.java.net Fri Mar 4 02:48:54 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Fri, 4 Mar 2022 02:48:54 GMT Subject: RFR: 8269115: WebView paste event contains old data [v6] In-Reply-To: References: Message-ID: > Issue: The DataObject uses m_availMimeTypes as Vector of strings, and appending mime types in pasteboard operation like setPlainText, Hence it will append duplicate mime types in m_availMimeTypes , in this case the length clipboardData.types would be wrong, and duplicates data would be copied to clipboard target. > Solution: Use ListHashSet data Structure instead of Vector for m_availMimeTypes. Jay Bhaskar has updated the pull request incrementally with five additional commits since the last revision: - added manual test - Add new Test case for copy and paste clipboard - Add new Test case for copy and paste clipboard - new test case - new test case ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/729/files - new: https://git.openjdk.java.net/jfx/pull/729/files/aa75ea4e..2b1c9eef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=729&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=729&range=04-05 Stats: 230 lines in 3 files changed: 204 ins; 16 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/729.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/729/head:pull/729 PR: https://git.openjdk.java.net/jfx/pull/729 From jbhaskar at openjdk.java.net Fri Mar 4 02:50:24 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Fri, 4 Mar 2022 02:50:24 GMT Subject: RFR: 8269115: WebView paste event contains old data [v7] In-Reply-To: References: Message-ID: > Issue: The DataObject uses m_availMimeTypes as Vector of strings, and appending mime types in pasteboard operation like setPlainText, Hence it will append duplicate mime types in m_availMimeTypes , in this case the length clipboardData.types would be wrong, and duplicates data would be copied to clipboard target. > Solution: Use ListHashSet data Structure instead of Vector for m_availMimeTypes. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: removed automated test HTMLClipBoardTest.java, as manual test added ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/729/files - new: https://git.openjdk.java.net/jfx/pull/729/files/2b1c9eef..382decf6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=729&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=729&range=05-06 Stats: 97 lines in 1 file changed: 0 ins; 97 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/729.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/729/head:pull/729 PR: https://git.openjdk.java.net/jfx/pull/729 From jbhaskar at openjdk.java.net Fri Mar 4 03:29:33 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Fri, 4 Mar 2022 03:29:33 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v7] In-Reply-To: References: Message-ID: <8PsP6Xv2mLGm_ZK7it7OSuHQTq5JIotUDqQFLa3d2tg=.38f48df3-cb07-4e0e-b325-06d9187eb8cf@github.com> > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) Jay Bhaskar has updated the pull request incrementally with two additional commits since the last revision: - test needs width and height , during creattion of webview - test needs width and height , during creattion of webview ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/731/files - new: https://git.openjdk.java.net/jfx/pull/731/files/5ab81018..355c798b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=731&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=731&range=05-06 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/731.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/731/head:pull/731 PR: https://git.openjdk.java.net/jfx/pull/731 From sykora at openjdk.java.net Fri Mar 4 13:47:09 2022 From: sykora at openjdk.java.net (Joeri Sykora) Date: Fri, 4 Mar 2022 13:47:09 GMT Subject: [jfx11u] RFR: 8265399: Update to Visual Studio 2019 version 16.9.3 In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 16:07:10 GMT, Kevin Rushforth wrote: > Update `jfx11u` to the same version of VS2019 (16.9.3) that is used in mainline jfx. I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. Build and tests ran successfully. ------------- Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx11u/pull/76 From kcr at openjdk.java.net Fri Mar 4 14:03:14 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Mar 2022 14:03:14 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v7] In-Reply-To: <8PsP6Xv2mLGm_ZK7it7OSuHQTq5JIotUDqQFLa3d2tg=.38f48df3-cb07-4e0e-b325-06d9187eb8cf@github.com> References: <8PsP6Xv2mLGm_ZK7it7OSuHQTq5JIotUDqQFLa3d2tg=.38f48df3-cb07-4e0e-b325-06d9187eb8cf@github.com> Message-ID: On Fri, 4 Mar 2022 03:29:33 GMT, Jay Bhaskar wrote: >> Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. >> Solution: Do not add thickness to the y position of end point of line. >> Start Point(x,y) ----------End Point(x + width, 0) > > Jay Bhaskar has updated the pull request incrementally with two additional commits since the last revision: > > - test needs width and height , during creattion of webview > - test needs width and height , during creattion of webview Looks great. I confirm that the updated test fails without the fix and passes with the fix on both macOS and Windows. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/731 From kcr at openjdk.java.net Fri Mar 4 14:06:15 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Mar 2022 14:06:15 GMT Subject: [jfx11u] Integrated: 8265399: Update to Visual Studio 2019 version 16.9.3 In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 16:07:10 GMT, Kevin Rushforth wrote: > Update `jfx11u` to the same version of VS2019 (16.9.3) that is used in mainline jfx. I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. This pull request has now been integrated. Changeset: 6c3a4827 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/6c3a48276d6db19f607d3cffe8e01616ae5c1aa5 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8265399: Update to Visual Studio 2019 version 16.9.3 Reviewed-by: arapte, sykora Backport-of: 7ec132c91f17437c187043c693780f0b0be173af ------------- PR: https://git.openjdk.java.net/jfx11u/pull/76 From kcr at openjdk.java.net Fri Mar 4 14:09:24 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Mar 2022 14:09:24 GMT Subject: [jfx11u] Integrated: 8278980: Update WebKit to 613.1 In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 16:46:36 GMT, Kevin Rushforth wrote: > Nearly clean backport to `jfx11u` (the only conflict was in the copyright years in one of the unit tests). I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. This pull request has now been integrated. Changeset: 1057d01d Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/1057d01d1c7d3f5edd86976aa21fdec7eb9c7b82 Stats: 412962 lines in 6737 files changed: 231442 ins; 135635 del; 45885 mod 8278980: Update WebKit to 613.1 Reviewed-by: arapte Backport-of: 6f28d912024495278c4c35ab054bc2aab480b3e4 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/77 From kcr at openjdk.java.net Fri Mar 4 14:25:37 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Mar 2022 14:25:37 GMT Subject: [jfx11u] Integrated: 8281459: WebKit 613.1 build broken on M1 Message-ID: Clean backport to `jfx11u`. I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. ------------- Commit messages: - 8281459: WebKit 613.1 build broken on M1 Changes: https://git.openjdk.java.net/jfx11u/pull/78/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=78&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281459 Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/78.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/78/head:pull/78 PR: https://git.openjdk.java.net/jfx11u/pull/78 From kcr at openjdk.java.net Fri Mar 4 14:25:37 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Mar 2022 14:25:37 GMT Subject: [jfx11u] Integrated: 8281459: WebKit 613.1 build broken on M1 In-Reply-To: References: Message-ID: <6CKABEA0NnqgVyIDkdiuAg42LxafSjiR9B7odRNkZdY=.949bc731-f357-4c6a-9a1c-32986e41e6da@github.com> On Fri, 4 Mar 2022 14:16:14 GMT, Kevin Rushforth wrote: > Clean backport to `jfx11u`. I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. This pull request has now been integrated. Changeset: 429f4181 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/429f4181092c6089f5851e77420cd7fc5471a5af Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod 8281459: WebKit 613.1 build broken on M1 Backport-of: cdebc6cbafb579148b4addee44d307bd9739454b ------------- PR: https://git.openjdk.java.net/jfx11u/pull/78 From kcr at openjdk.java.net Fri Mar 4 14:37:33 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Mar 2022 14:37:33 GMT Subject: [jfx11u] Integrated: 8281711: Cherry-pick WebKit 613.1 stabilization fixes Message-ID: Clean backport to `jfx11u`. I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. ------------- Commit messages: - 8281711: Cherry-pick WebKit 613.1 stabilization fixes Changes: https://git.openjdk.java.net/jfx11u/pull/79/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=79&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281711 Stats: 1218 lines in 127 files changed: 767 ins; 169 del; 282 mod Patch: https://git.openjdk.java.net/jfx11u/pull/79.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/79/head:pull/79 PR: https://git.openjdk.java.net/jfx11u/pull/79 From kcr at openjdk.java.net Fri Mar 4 14:37:35 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Mar 2022 14:37:35 GMT Subject: [jfx11u] Integrated: 8281711: Cherry-pick WebKit 613.1 stabilization fixes In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 14:27:25 GMT, Kevin Rushforth wrote: > Clean backport to `jfx11u`. I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. This pull request has now been integrated. Changeset: eda64804 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/eda64804abc53977bb354b37704799c067b0ebc0 Stats: 1218 lines in 127 files changed: 767 ins; 169 del; 282 mod 8281711: Cherry-pick WebKit 613.1 stabilization fixes Stabilization fixes from WebKitGTK 2.34.5 Backport-of: 418d3437923fed0a298c48b54214af069e3bb3bd ------------- PR: https://git.openjdk.java.net/jfx11u/pull/79 From kcr at openjdk.java.net Fri Mar 4 14:52:35 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Mar 2022 14:52:35 GMT Subject: [jfx11u] Integrated: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) Message-ID: Clean backport to `jfx11u`. I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. ------------- Commit messages: - 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) Changes: https://git.openjdk.java.net/jfx11u/pull/80/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=80&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282099 Stats: 186 lines in 11 files changed: 116 ins; 33 del; 37 mod Patch: https://git.openjdk.java.net/jfx11u/pull/80.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/80/head:pull/80 PR: https://git.openjdk.java.net/jfx11u/pull/80 From kcr at openjdk.java.net Fri Mar 4 14:52:36 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Mar 2022 14:52:36 GMT Subject: [jfx11u] Integrated: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 14:40:49 GMT, Kevin Rushforth wrote: > Clean backport to `jfx11u`. I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. This pull request has now been integrated. Changeset: 90a0ae22 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/90a0ae222c13c1c8019d3096535fb955bc752fec Stats: 186 lines in 11 files changed: 116 ins; 33 del; 37 mod 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) Backport-of: 6f201f7a02dba14328d183e7d0db5dede4416ce4 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/80 From kcr at openjdk.java.net Fri Mar 4 15:09:15 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Mar 2022 15:09:15 GMT Subject: RFR: 8269115: WebView paste event contains old data [v7] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 02:50:24 GMT, Jay Bhaskar wrote: >> Issue: The DataObject uses m_availMimeTypes as Vector of strings, and appending mime types in pasteboard operation like setPlainText, Hence it will append duplicate mime types in m_availMimeTypes , in this case the length clipboardData.types would be wrong, and duplicates data would be copied to clipboard target. >> Solution: Use ListHashSet data Structure instead of Vector for m_availMimeTypes. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > removed automated test HTMLClipBoardTest.java, as manual test added The new manual test looks good. It fails without the fix and passes with the fix. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/729 From kcr at openjdk.java.net Fri Mar 4 15:16:18 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Mar 2022 15:16:18 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v8] In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 17:08:49 GMT, Jay Bhaskar wrote: >> Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. >> Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) >> "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Restore original , and new changes wrapped with define JAVA I recommend also putting the following restored code under `#if !PLATFORM(JAVA)`: // FIXME: We should consider supporting access/modification to local storage // after calling window.close(). See . if (!page || !page->isClosing()) { if (m_localStorage) return m_localStorage.get(); } The rest looks good. ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From jbhaskar at openjdk.java.net Fri Mar 4 16:55:48 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Fri, 4 Mar 2022 16:55:48 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v9] In-Reply-To: References: Message-ID: > Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. > Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) > "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Added review change JAVA ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/703/files - new: https://git.openjdk.java.net/jfx/pull/703/files/1b4d7751..613cc00f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=07-08 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/703/head:pull/703 PR: https://git.openjdk.java.net/jfx/pull/703 From jbhaskar at openjdk.java.net Fri Mar 4 16:55:50 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Fri, 4 Mar 2022 16:55:50 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v8] In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 17:08:49 GMT, Jay Bhaskar wrote: >> Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. >> Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) >> "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Restore original , and new changes wrapped with define JAVA Added #if !PLATFORM(JAVA) // FIXME: We should consider supporting access/modification to local storage // after calling window.close(). See . if (!page || !page->isClosing()) { if (m_localStorage) return m_localStorage.get(); } #endif ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From kcr at openjdk.java.net Fri Mar 4 17:35:08 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Mar 2022 17:35:08 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v9] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 16:55:48 GMT, Jay Bhaskar wrote: >> Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. >> Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) >> "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Added review change JAVA Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From arapte at openjdk.java.net Sat Mar 5 04:31:16 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sat, 5 Mar 2022 04:31:16 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v9] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 16:55:48 GMT, Jay Bhaskar wrote: >> Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. >> Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) >> "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Added review change JAVA Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From alexsch at openjdk.java.net Sat Mar 5 14:05:21 2022 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Sat, 5 Mar 2022 14:05:21 GMT Subject: RFR: 8282702: Button is pressed one more time on Raspberry Pi with Touchscreen Message-ID: <1b30B6AM6PdGMU2V85qarKOY-WyoiFmULJcGRA8J5Og=.33914bbd-b041-46ed-a522-dc6235ecd68d@github.com> Tapping on a button and next tapping on another place on the screen leads that the button is pressed twice on a Raspberry Pi with Touchscreen. For example, run the [JFXButtonExample](https://bugs.openjdk.java.net/secure/attachment/98181/JFXButtonExample.java) app and first tap on the button in the left bottom side of the screen and second tap on the center of the screen. This is a log of the state from LinuxStatefulMultiTouchProcessor.processEvents() method when `System.out.printf("state: %s%n", state);` code is added before the line: https://github.com/openjdk/jfx/blob/2e8a4a5e97bb88a5807ae5fe075b98e1d54a4ca0/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LinuxStatefulMultiTouchProcessor.java#L140 state: TouchState[1,TouchState.Point[id=91,x=257,y=419]] state: TouchState[1,TouchState.Point[id=91,x=257,y=420]] state: TouchState[0] Hello World! state: TouchState[2,TouchState.Point[id=91,x=257,y=419],TouchState.Point[id=92,x=410,y=265]] state: TouchState[2,TouchState.Point[id=91,x=257,y=419],TouchState.Point[id=92,x=409,y=267]] state: TouchState[2,TouchState.Point[id=91,x=257,y=419],TouchState.Point[id=92,x=408,y=286]] state: TouchState[0] Hello World! The TouchState contains only button coordinates (x=257,y=419) for the first tap on the button. The TouchState contains both the button coordinates (x=257,y=419) and coordinates of the center of screen (x=408,y=286) for the second tap on the center of the screen. This happens because when LinuxStatefulMultiTouchProcessor.processEvents() pushes the state with current touches to the pipeline the LookaheadTouchFilter saves the current state and copies the previous saved state to the current state. https://github.com/openjdk/jfx/blob/2e8a4a5e97bb88a5807ae5fe075b98e1d54a4ca0/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LookaheadTouchFilter.java#L74 That leads that the already deleted touch state (which contains the button coordinate) is restored. The proposed solution is to put the copy of the touch state to the pipeline . Printing the touch state after the fix shows the log: state: TouchState[1,TouchState.Point[id=65,x=267,y=423]] state: TouchState[1,TouchState.Point[id=65,x=269,y=425]] state: TouchState[0] Hello World! state: TouchState[1,TouchState.Point[id=66,x=414,y=243]] state: TouchState[1,TouchState.Point[id=66,x=414,y=238]] state: TouchState[0] The TouchState does not contains the button coordinates for the second tap. ------------- Commit messages: - 8282702: Button is pressed one more time on Raspberry Pi with Touchscreen Changes: https://git.openjdk.java.net/jfx/pull/746/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=746&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282702 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/746.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/746/head:pull/746 PR: https://git.openjdk.java.net/jfx/pull/746 From jbhaskar at openjdk.java.net Sat Mar 5 14:45:12 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Sat, 5 Mar 2022 14:45:12 GMT Subject: Integrated: 8255940: localStorage is null after window.close() In-Reply-To: References: Message-ID: On Mon, 27 Dec 2021 09:31:08 GMT, Jay Bhaskar wrote: > Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. > Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) > "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." This pull request has now been integrated. Changeset: 5112be95 Author: Jay Bhaskar Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/5112be957be70dd6521e6fb6ee64e669c148729c Stats: 168 lines in 4 files changed: 167 ins; 0 del; 1 mod 8255940: localStorage is null after window.close() Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From kcr at openjdk.java.net Sat Mar 5 15:45:06 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Mar 2022 15:45:06 GMT Subject: RFR: 8282702: Button is pressed one more time on Raspberry Pi with Touchscreen In-Reply-To: <1b30B6AM6PdGMU2V85qarKOY-WyoiFmULJcGRA8J5Og=.33914bbd-b041-46ed-a522-dc6235ecd68d@github.com> References: <1b30B6AM6PdGMU2V85qarKOY-WyoiFmULJcGRA8J5Og=.33914bbd-b041-46ed-a522-dc6235ecd68d@github.com> Message-ID: On Sat, 5 Mar 2022 13:58:54 GMT, Alexander Scherbatiy wrote: > Tapping on a button and next tapping on another place on the screen leads that the button is pressed twice on a Raspberry Pi with Touchscreen. > > For example, run the [JFXButtonExample](https://bugs.openjdk.java.net/secure/attachment/98181/JFXButtonExample.java) > app and first tap on the button in the left bottom side of the screen and second tap on the center of the screen. > > This is a log of the state from LinuxStatefulMultiTouchProcessor.processEvents() method when `System.out.printf("state: %s%n", state);` code is added before the line: > https://github.com/openjdk/jfx/blob/2e8a4a5e97bb88a5807ae5fe075b98e1d54a4ca0/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LinuxStatefulMultiTouchProcessor.java#L140 > > state: TouchState[1,TouchState.Point[id=91,x=257,y=419]] > state: TouchState[1,TouchState.Point[id=91,x=257,y=420]] > state: TouchState[0] > Hello World! > state: TouchState[2,TouchState.Point[id=91,x=257,y=419],TouchState.Point[id=92,x=410,y=265]] > state: TouchState[2,TouchState.Point[id=91,x=257,y=419],TouchState.Point[id=92,x=409,y=267]] > state: TouchState[2,TouchState.Point[id=91,x=257,y=419],TouchState.Point[id=92,x=408,y=286]] > state: TouchState[0] > Hello World! > > The TouchState contains only button coordinates (x=257,y=419) for the first tap on the button. > The TouchState contains both the button coordinates (x=257,y=419) and coordinates of the center of screen (x=408,y=286) for the second tap on the center of the screen. > > This happens because when LinuxStatefulMultiTouchProcessor.processEvents() pushes the state with current touches to the pipeline the LookaheadTouchFilter saves the current state and copies the previous saved state to the current state. > https://github.com/openjdk/jfx/blob/2e8a4a5e97bb88a5807ae5fe075b98e1d54a4ca0/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LookaheadTouchFilter.java#L74 > > That leads that the already deleted touch state (which contains the button coordinate) is restored. > > The proposed solution is to put the copy of the touch state to the pipeline . > > Printing the touch state after the fix shows the log: > > state: TouchState[1,TouchState.Point[id=65,x=267,y=423]] > state: TouchState[1,TouchState.Point[id=65,x=269,y=425]] > state: TouchState[0] > Hello World! > state: TouchState[1,TouchState.Point[id=66,x=414,y=243]] > state: TouchState[1,TouchState.Point[id=66,x=414,y=238]] > state: TouchState[0] > > The TouchState does not contains the button coordinates for the second tap. The fix looks OK to me. Since it is in Monocle, maybe @johanvos can review it? ------------- PR: https://git.openjdk.java.net/jfx/pull/746 From kcr at openjdk.java.net Sat Mar 5 15:46:13 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Mar 2022 15:46:13 GMT Subject: RFR: 8282100: Missed top/left bouncing for ScrollPane on Raspberry Pi with Touchscreen In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 15:21:49 GMT, Alexander Scherbatiy wrote: > There is the bouncing when scrolling a node on a ScrollPane to the right/bottom (the node on the scroll pane is scrolled further than its width/height so the background is visible and then automatically is scrolled back to the node bounds) on Raspberry Pi with Touchscreen. > There is no bouncing when node is scrolled to the left/top. > > The fix updates ScrollPaneSkin.updatePosX()/updatePosY() methods to not discard out of the range top/left minX/Y values in case the touch is supported. @AlexanderScherbatiy This is ready for you to integrate. ------------- PR: https://git.openjdk.java.net/jfx/pull/736 From alexsch at openjdk.java.net Sat Mar 5 15:59:24 2022 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Sat, 5 Mar 2022 15:59:24 GMT Subject: RFR: 8282703: Axis is not cached in the LinuxTouchTransform class Message-ID: An axis is not cached in the LinuxTouchTransform class. To reproduce the issue I added `System.out.printf("initTransform: axis: %d, index: %d%n", axis, index);` log to the LinuxTouchTransform.initTransform() method: https://github.com/openjdk/jfx/blob/5112be957be70dd6521e6fb6ee64e669c148729c/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LinuxTouchTransform.java#L117 run the [JFXButtonExample](https://bugs.openjdk.java.net/secure/attachment/98181/JFXButtonExample.java) sample and tapped the touch screen on a Raspberry Pi with Touchscreen. The result was initTransform: axis: 47, index: 0 initTransform: axis: 57, index: 0 initTransform: axis: 53, index: 0 initTransform: axis: 54, index: 0 initTransform: axis: 0, index: 0 initTransform: axis: 1, index: 0 initTransform: axis: 53, index: 0 initTransform: axis: 54, index: 0 initTransform: axis: 0, index: 0 initTransform: axis: 1, index: 0 initTransform: axis: 53, index: 0 initTransform: axis: 54, index: 0 initTransform: axis: 0, index: 0 initTransform: axis: 1, index: 0 The initTransform() is called several times for axis 0,1,47,53,54 and index is always set to zero. The straight forward fix is to store the given axis in the axes array: "axes[index] = axis". This is the first commit for the current fix. Using this fix the output with printf from initTransform() method looks like: initTransform: axis: 47, index: 0 initTransform: axis: 57, index: 1 initTransform: axis: 53, index: 2 initTransform: axis: 54, index: 4 initTransform: axis: 1, index: 5 Now all axes are printed only once and the index value is different for each axes. However, the minimum/maximum values are retrieved and cached for ABS_X/Y and ABS_MT_POSITION_X/Y axes after the fist tap on the screen. The second commit improves this moving the ABS_X/Y and ABS_MT_POSITION_X/Y axes initialization into the LinuxTouchTransform constructor. Now the touch logs look like: // LinuxTouchTransform constructor // device: /dev/input/mouse0 initTransform: axis: 0, index: 0 initTransform: axis: 1, index: 1 initTransform: axis: 53, index: 2 initTransform: axis: 54, index: 3 // LinuxTouchTransform constructor // device: /dev/input/event2 initTransform: axis: 0, index: 0 initTransform: axis: 1, index: 1 initTransform: axis: 53, index: 2 initTransform: axis: 54, index: 3 // the first tap initTransform: axis: 57, index: 4 initTransform: axis: 47, index: 5 The ABS_X/Y and ABS_MT_POSITION_X/Y axes and corresponding minimum/maximum values are initialized in the constructor. The other axes which stores only default values in translates and scalars arrays are initialized during touch events. ------------- Commit messages: - Preinitialize ABS_X/Y and ABS_MT_POSITION_X/Y transforms in LinuxTouchTransform class - 8282703: Axis is not cached in the LinuxTouchTransform class Changes: https://git.openjdk.java.net/jfx/pull/747/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=747&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282703 Stats: 31 lines in 1 file changed: 23 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/747.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/747/head:pull/747 PR: https://git.openjdk.java.net/jfx/pull/747 From arapte at openjdk.java.net Sat Mar 5 18:24:02 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sat, 5 Mar 2022 18:24:02 GMT Subject: RFR: 8269115: WebView paste event contains old data [v7] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 02:50:24 GMT, Jay Bhaskar wrote: >> Issue: The DataObject uses m_availMimeTypes as Vector of strings, and appending mime types in pasteboard operation like setPlainText, Hence it will append duplicate mime types in m_availMimeTypes , in this case the length clipboardData.types would be wrong, and duplicates data would be copied to clipboard target. >> Solution: Use ListHashSet data Structure instead of Vector for m_availMimeTypes. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > removed automated test HTMLClipBoardTest.java, as manual test added looks good to me too. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/729 From kcr at openjdk.java.net Sat Mar 5 19:26:00 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Mar 2022 19:26:00 GMT Subject: RFR: 8280840: Update libFFI to 3.4.2 [v2] In-Reply-To: References: Message-ID: <1FgHjNfqJDMViihH1Asv1DYQjo6dQhXkZ9ewW-Z6Yq8=.1c93ae23-e4d5-45fd-ba9d-cce4e1c8c797@github.com> On Thu, 24 Feb 2022 03:07:57 GMT, Alexander Matveev wrote: >> LibFFI updated to 3.4.2. No additional changes to our code, libffi code or build system were required. Tested on all platforms. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8280840: Update libFFI to 3.4.2 [v3] Looks good. Pending a second reviewer. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/738 From neacsu.cristianstefan at gmail.com Mon Mar 7 00:52:34 2022 From: neacsu.cristianstefan at gmail.com (Neacsu Cristian) Date: Mon, 7 Mar 2022 02:52:34 +0200 Subject: Bug: ComboBox dropdown list of combobox is not taking Scale Transformation in consideration Message-ID: Hello, I am using ComboBoxes all over the place in my application. Until now, my application was in full-screen mode. Now due to the request of clients to create the possibility to move it around on multiple screen, I created the option to move it on dual screens and so on. To achieve different resolution I am using the Scale transformation and add it to the main node, in order to scale everything. Everything is working properly, but the drop down list is taking the width of the combo box unscaled (and if resolution differs from the one that was initiated, the drop down list width will differ from the combobox itself). Is it a legit bug? Thank you in advance, Cristian-Stefan From jbhaskar at openjdk.java.net Mon Mar 7 08:52:09 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Mon, 7 Mar 2022 08:52:09 GMT Subject: Integrated: 8269115: WebView paste event contains old data In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 11:13:20 GMT, Jay Bhaskar wrote: > Issue: The DataObject uses m_availMimeTypes as Vector of strings, and appending mime types in pasteboard operation like setPlainText, Hence it will append duplicate mime types in m_availMimeTypes , in this case the length clipboardData.types would be wrong, and duplicates data would be copied to clipboard target. > Solution: Use ListHashSet data Structure instead of Vector for m_availMimeTypes. This pull request has now been integrated. Changeset: 2338821b Author: Jay Bhaskar Committer: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/2338821bdbb7db929a89aa89903271dcff333a5c Stats: 120 lines in 3 files changed: 108 ins; 3 del; 9 mod 8269115: WebView paste event contains old data Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/729 From jbhaskar at openjdk.java.net Mon Mar 7 09:28:52 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Mon, 7 Mar 2022 09:28:52 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v8] In-Reply-To: References: Message-ID: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: formating for drawline ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/731/files - new: https://git.openjdk.java.net/jfx/pull/731/files/355c798b..e7d39427 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=731&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=731&range=06-07 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/731.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/731/head:pull/731 PR: https://git.openjdk.java.net/jfx/pull/731 From arapte at openjdk.java.net Mon Mar 7 10:17:57 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 7 Mar 2022 10:17:57 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v8] In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 09:28:52 GMT, Jay Bhaskar wrote: >> Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. >> Solution: Do not add thickness to the y position of end point of line. >> Start Point(x,y) ----------End Point(x + width, 0) > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > formating for drawline Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From sykora at openjdk.java.net Mon Mar 7 11:06:17 2022 From: sykora at openjdk.java.net (Joeri Sykora) Date: Mon, 7 Mar 2022 11:06:17 GMT Subject: RFR: 8280840: Update libFFI to 3.4.2 [v2] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 03:07:57 GMT, Alexander Matveev wrote: >> LibFFI updated to 3.4.2. No additional changes to our code, libffi code or build system were required. Tested on all platforms. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8280840: Update libFFI to 3.4.2 [v3] Built and tested. ------------- Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/738 From kcr at openjdk.java.net Mon Mar 7 15:09:14 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Mar 2022 15:09:14 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v8] In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 09:28:52 GMT, Jay Bhaskar wrote: >> Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. >> Solution: Do not add thickness to the y position of end point of line. >> Start Point(x,y) ----------End Point(x + width, 0) > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > formating for drawline Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From jbhaskar at openjdk.java.net Mon Mar 7 15:27:08 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Mon, 7 Mar 2022 15:27:08 GMT Subject: Integrated: 8280020: Underline and line-through not straight in WebView In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 11:36:38 GMT, Jay Bhaskar wrote: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) This pull request has now been integrated. Changeset: 263db3df Author: Jay Bhaskar Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/263db3df5fdf9e0f6955be6ae58173aa589e55fe Stats: 192 lines in 2 files changed: 182 ins; 2 del; 8 mod 8280020: Underline and line-through not straight in WebView Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From kevin.rushforth at oracle.com Mon Mar 7 16:20:39 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 7 Mar 2022 08:20:39 -0800 Subject: Bug: ComboBox dropdown list of combobox is not taking Scale Transformation in consideration In-Reply-To: References: Message-ID: This sounds like JDK-8088757 [1], "Scale of control does not cross to popup in popup-based controls". Yes, it does seems like a legitimate bug to me. Fixing it might result in a surprising behavior change for some existing applications, given how long this behavior has been in place (the bug in question was filed 10 years ago), but that's not a good enough reason to avoid fixing the bug. As usual, it will come down to priorities. If someone has time to fix this, it will make it a lot more likely for it to be fixed. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8088757 On 3/6/2022 4:52 PM, Neacsu Cristian wrote: > Hello, > > I am using ComboBoxes all over the place in my application. > Until now, my application was in full-screen mode. Now due to the request > of clients to create the possibility to move it around on multiple screen, > I created the option to move it on dual screens and so on. To achieve > different resolution I am using the Scale transformation and add it to the > main node, in order to scale everything. > Everything is working properly, but the drop down list is taking the width > of the combo box unscaled (and if resolution differs from the one that was > initiated, the drop down list width will differ from the combobox itself). > Is it a legit bug? > > Thank you in advance, > Cristian-Stefan From duke at openjdk.java.net Mon Mar 7 17:23:19 2022 From: duke at openjdk.java.net (Andreas =?UTF-8?B?TcO8bGxlcg==?=) Date: Mon, 7 Mar 2022 17:23:19 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v9] In-Reply-To: References: Message-ID: <5eAX3M2G_2TmlUMWliV7MhXwG3PWeHAJrp9aTpjeNfI=.573a1158-ff91-4baf-b35f-a3d9075195b3@github.com> On Fri, 4 Mar 2022 16:55:48 GMT, Jay Bhaskar wrote: >> Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. >> Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) >> "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Added review change JAVA Thanks, the fix is working great for me. And, sorry, this is probably the wrong channel for this, but will this fix be considered to be backported (11/17)? I could not figure out how to properly request that, if I could do that at all. ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From kcr at openjdk.java.net Mon Mar 7 18:03:10 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Mar 2022 18:03:10 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v9] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 16:55:48 GMT, Jay Bhaskar wrote: >> Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. >> Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) >> "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Added review change JAVA Yes, it will be backported to both 17 and 11, since we always try to keep the native WebKit code in sync across release families. It's getting pretty late for the April release (11.0.15 and 17.0.3), so it might need to wait until July. We'll see. ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From alexsch at openjdk.java.net Mon Mar 7 18:40:06 2022 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Mon, 7 Mar 2022 18:40:06 GMT Subject: Integrated: 8282100: Missed top/left bouncing for ScrollPane on Raspberry Pi with Touchscreen In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 15:21:49 GMT, Alexander Scherbatiy wrote: > There is the bouncing when scrolling a node on a ScrollPane to the right/bottom (the node on the scroll pane is scrolled further than its width/height so the background is visible and then automatically is scrolled back to the node bounds) on Raspberry Pi with Touchscreen. > There is no bouncing when node is scrolled to the left/top. > > The fix updates ScrollPaneSkin.updatePosX()/updatePosY() methods to not discard out of the range top/left minX/Y values in case the touch is supported. This pull request has now been integrated. Changeset: ae419d77 Author: Alexander Scherbatiy Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/ae419d7780bef540b95d3376817d708e6508ecca Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod 8282100: Missed top/left bouncing for ScrollPane on Raspberry Pi with Touchscreen Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/736 From kcr at openjdk.java.net Tue Mar 8 01:37:21 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Mar 2022 01:37:21 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v9] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 23:57:09 GMT, Thiago Milczarek Sayao wrote: >> Found the problem thru this path: >> >> **WindowStage.java** >> >> final void handleFocusDisabled() { >> if (activeWindows.isEmpty()) { >> return; >> } >> WindowStage window = activeWindows.get(activeWindows.size() - 1); >> window.setIconified(false); >> window.requestToFront(); >> window.requestFocus(); >> } >> >> >> **glass_window.cpp** >> >> void WindowContextBase::process_focus(GdkEventFocus* event) { >> ... >> >> if (jwindow) { >> if (!event->in || isEnabled()) { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, >> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); >> CHECK_JNI_EXCEPTION(mainEnv) >> } else { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); >> CHECK_JNI_EXCEPTION(mainEnv) >> } >> } >> } >> >> >> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). >> >> The docs states: >> >> /** >> * Enables or disables the window. >> * >> * A disabled window is unfocusable by definition. >> * Also, key or mouse events aren't generated for disabled windows. >> * >> * When a user tries to activate a disabled window, or the window gets >> * accidentally brought to the top of the stacking order, the window >> * generates the FOCUS_DISABLED window event. A Glass client should react >> * to this event and bring the currently active modal blocker of the >> * disabled window to top by calling blocker's minimize(false), toFront(), >> * and requestFocus() methods. It may also 'blink' the blocker window to >> * further attract user's attention. >> * >> ..... >> >> >> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. >> >> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Capture event serial on process_key This fix looks good. The test program for this bug reliably works now, and I verified that it doesn't reintroduce [JDK-8240640](https://bugs.openjdk.java.net/browse/JDK-8240640) or [JDK-8227366](https://bugs.openjdk.java.net/browse/JDK-8227366) ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/598 From almatvee at openjdk.java.net Tue Mar 8 01:39:06 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 8 Mar 2022 01:39:06 GMT Subject: Integrated: 8280840: Update libFFI to 3.4.2 In-Reply-To: References: Message-ID: On Sat, 19 Feb 2022 07:45:43 GMT, Alexander Matveev wrote: > LibFFI updated to 3.4.2. No additional changes to our code, libffi code or build system were required. Tested on all platforms. This pull request has now been integrated. Changeset: 1beb3235 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/1beb3235223452929ec951ee18dd30a5345307cf Stats: 3475 lines in 34 files changed: 927 ins; 38 del; 2510 mod 8280840: Update libFFI to 3.4.2 Reviewed-by: kcr, sykora ------------- PR: https://git.openjdk.java.net/jfx/pull/738 From arapte at openjdk.java.net Tue Mar 8 13:40:16 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 8 Mar 2022 13:40:16 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v9] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 23:57:09 GMT, Thiago Milczarek Sayao wrote: >> Found the problem thru this path: >> >> **WindowStage.java** >> >> final void handleFocusDisabled() { >> if (activeWindows.isEmpty()) { >> return; >> } >> WindowStage window = activeWindows.get(activeWindows.size() - 1); >> window.setIconified(false); >> window.requestToFront(); >> window.requestFocus(); >> } >> >> >> **glass_window.cpp** >> >> void WindowContextBase::process_focus(GdkEventFocus* event) { >> ... >> >> if (jwindow) { >> if (!event->in || isEnabled()) { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, >> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); >> CHECK_JNI_EXCEPTION(mainEnv) >> } else { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); >> CHECK_JNI_EXCEPTION(mainEnv) >> } >> } >> } >> >> >> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). >> >> The docs states: >> >> /** >> * Enables or disables the window. >> * >> * A disabled window is unfocusable by definition. >> * Also, key or mouse events aren't generated for disabled windows. >> * >> * When a user tries to activate a disabled window, or the window gets >> * accidentally brought to the top of the stacking order, the window >> * generates the FOCUS_DISABLED window event. A Glass client should react >> * to this event and bring the currently active modal blocker of the >> * disabled window to top by calling blocker's minimize(false), toFront(), >> * and requestFocus() methods. It may also 'blink' the blocker window to >> * further attract user's attention. >> * >> ..... >> >> >> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. >> >> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Capture event serial on process_key The fix itself looks good. though I have a query. I did not observe any mis-behaviour, so please check if the suggested change is required or not. modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 780: > 778: } > 779: > 780: event_serial = 0; should we use GDK_CURRENT_TIME instead of 0 ? GDK_CURRENT_TIME is defined also as 0 and represent current time. modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1390: > 1388: // prevents activeWindows on WindowStage.java to be out of order which may cause the FOCUS_DISABLED event > 1389: // to bring up the wrong window (it brings up the last which will not be the real "last" if out of order). > 1390: gtk_window_present_with_time(GTK_WINDOW(gtk_widget), event_serial); `event_serial` is not reset after use. I could observe that a stale value of `event_serial` gets reused several times. Steps to observe the behavior: 1. Print event_serial in this method 2. Run the sample program attached to JBS. 3. Press the "Click Me!" button 4. Answer YES on the Alert 5. Three stages should be visible on the screen. 6. Relocate such that all stages are visible 7. Click on 'This should be on Top' Stage 8. Click on "This is a stage with no owner' stage. 9. Click on StageTest icon in Taskbar. Keep repeating this step. The stage gains and looses focus and the same event_serial gets printed on terminal. => It does not look harmful behavior wise. But can observe that `event_serial` gets reused. Screenshot: Screenshot 2022-03-08 at 6 53 46 PM Will it be good idea to reset it to 0/GDK_CURRENT_TIME and use something like, if (event_serial == GDK_CURRENT_TIME) { gtk_window_present(GTK_WINDOW(gtk_widget)); } else { gtk_window_present_with_time(GTK_WINDOW(gtk_widget), event_serial); event_serial = GDK_CURRENT_TIME; } OR gtk_window_present_with_time(GTK_WINDOW(gtk_widget), event_serial); event_serial = GDK_CURRENT_TIME; ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From martin at martinfox.com Tue Mar 8 18:42:30 2022 From: martin at martinfox.com (M Fox) Date: Tue, 8 Mar 2022 10:42:30 -0800 Subject: Bug: ComboBox dropdown list of combobox is not taking Scale Transformation in consideration In-Reply-To: References: Message-ID: <69D4C9DA-880B-46B8-A9C7-C88C9F6E0BB7@martinfox.com> Out of curiosity I decided to take a look at this bug. I?m a Java and JavaFX newbie so take this all with a massive grain of salt. It?s not at all clear how to take the control's cumulative transform and create a transform to apply to the popup. Even isolating the scale is tricky if a rotation was applied somewhere along the Node chain. If JavaFX tried to do this itself I suspect defining the behavior would be way more difficult than implementing it. It?s possible for a client to do this directly for some controls including ComboBoxes. Create a subclass of the ComboBox skin (the base class would be ComboBoxListViewSkin) and override it?s getPopupContent() method to retrieve the Node from super and apply whatever transforms you want. Then create a subclass of ComboBox and override it?s createDefaultSkin() method to return an instance of your custom skin. This approach also works for ColorPickers and DatePickers. I couldn?t see any way of applying it to ChoiceBoxes, internally they use ContextMenus and don?t expose them in any way. I think that would be an easy problem to solve. MenuBars are too deep for me. public class CustomComboBoxSkin extends ComboBoxListViewSkin { public CustomComboBoxSkin(ComboBox comboBox) { super(comboBox); } @Override public Node getPopupContent() { Node result = super.getPopupContent(); result.getTransforms().setAll(new Scale(0.5, 0.5, 0.0, 0.0)); return result; } } public class CustomComboBox extends ComboBox { @Override protected Skin createDefaultSkin() { return new CustomComboBoxSkin<>(this); } } > On Mar 7, 2022, at 8:20 AM, Kevin Rushforth wrote: > > This sounds like JDK-8088757 [1], "Scale of control does not cross to popup in popup-based controls". Yes, it does seems like a legitimate bug to me. Fixing it might result in a surprising behavior change for some existing applications, given how long this behavior has been in place (the bug in question was filed 10 years ago), but that's not a good enough reason to avoid fixing the bug. As usual, it will come down to priorities. If someone has time to fix this, it will make it a lot more likely for it to be fixed. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8088757 > > On 3/6/2022 4:52 PM, Neacsu Cristian wrote: >> Hello, >> >> I am using ComboBoxes all over the place in my application. >> Until now, my application was in full-screen mode. Now due to the request >> of clients to create the possibility to move it around on multiple screen, >> I created the option to move it on dual screens and so on. To achieve >> different resolution I am using the Scale transformation and add it to the >> main node, in order to scale everything. >> Everything is working properly, but the drop down list is taking the width >> of the combo box unscaled (and if resolution differs from the one that was >> initiated, the drop down list width will differ from the combobox itself). >> Is it a legit bug? >> >> Thank you in advance, >> Cristian-Stefan > From tsayao at openjdk.java.net Tue Mar 8 20:32:53 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 8 Mar 2022 20:32:53 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v10] In-Reply-To: References: Message-ID: <9qptJl8AlWNDb6Usyn9kcx_GJ5QYFvoSdnK6KPdCZOo=.9cdb587f-2c02-4421-9b65-44a81a98ba04@github.com> > Found the problem thru this path: > > **WindowStage.java** > > final void handleFocusDisabled() { > if (activeWindows.isEmpty()) { > return; > } > WindowStage window = activeWindows.get(activeWindows.size() - 1); > window.setIconified(false); > window.requestToFront(); > window.requestFocus(); > } > > > **glass_window.cpp** > > void WindowContextBase::process_focus(GdkEventFocus* event) { > ... > > if (jwindow) { > if (!event->in || isEnabled()) { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, > event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); > CHECK_JNI_EXCEPTION(mainEnv) > } else { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); > CHECK_JNI_EXCEPTION(mainEnv) > } > } > } > > > So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). > > The docs states: > > /** > * Enables or disables the window. > * > * A disabled window is unfocusable by definition. > * Also, key or mouse events aren't generated for disabled windows. > * > * When a user tries to activate a disabled window, or the window gets > * accidentally brought to the top of the stacking order, the window > * generates the FOCUS_DISABLED window event. A Glass client should react > * to this event and bring the currently active modal blocker of the > * disabled window to top by calling blocker's minimize(false), toFront(), > * and requestFocus() methods. It may also 'blink' the blocker window to > * further attract user's attention. > * > ..... > > > So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. > > The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Review adjustments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/598/files - new: https://git.openjdk.java.net/jfx/pull/598/files/ee8ab1e2..42157fec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=08-09 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/598.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598 PR: https://git.openjdk.java.net/jfx/pull/598 From tsayao at openjdk.java.net Tue Mar 8 20:32:54 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 8 Mar 2022 20:32:54 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v9] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 13:12:03 GMT, Ambarish Rapte wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Capture event serial on process_key > > modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 780: > >> 778: } >> 779: >> 780: event_serial = 0; > > should we use GDK_CURRENT_TIME instead of 0 ? > GDK_CURRENT_TIME is defined also as 0 and represent current time. GDK_CURRENT_TIME is always 0, but it looks better. Changed it. > modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1390: > >> 1388: // prevents activeWindows on WindowStage.java to be out of order which may cause the FOCUS_DISABLED event >> 1389: // to bring up the wrong window (it brings up the last which will not be the real "last" if out of order). >> 1390: gtk_window_present_with_time(GTK_WINDOW(gtk_widget), event_serial); > > `event_serial` is not reset after use. I could observe that a stale value of `event_serial` gets reused several times. > Steps to observe the behavior: > 1. Print event_serial in this method > 2. Run the sample program attached to JBS. > 3. Press the "Click Me!" button > 4. Answer YES on the Alert > 5. Three stages should be visible on the screen. > 6. Relocate such that all stages are visible > 7. Click on 'This should be on Top' Stage > 8. Click on "This is a stage with no owner' stage. > 9. Click on StageTest icon in Taskbar. Keep repeating this step. The stage gains and looses focus and the same event_serial gets printed on terminal. > => It does not look harmful behavior wise. But can observe that `event_serial` gets reused. > Screenshot: > Screenshot 2022-03-08 at 6 53 46 PM > > > > Will it be good idea to reset it to 0/GDK_CURRENT_TIME and use something like, > > > if (event_serial == GDK_CURRENT_TIME) { > gtk_window_present(GTK_WINDOW(gtk_widget)); > } else { > gtk_window_present_with_time(GTK_WINDOW(gtk_widget), event_serial); > event_serial = GDK_CURRENT_TIME; > } > > > OR > > > gtk_window_present_with_time(GTK_WINDOW(gtk_widget), event_serial); > event_serial = GDK_CURRENT_TIME; You're right, it can avoid other possible errors. ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From nlisker at openjdk.java.net Tue Mar 8 21:23:13 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 8 Mar 2022 21:23:13 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v8] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Thu, 27 Jan 2022 21:49:07 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix wrong test values The tests look good. I'm happy with the coverage and added one comment about a missing case. My own sanity checks also work as I expect. Will approve when these are addressed as I have already reviewed the API and implementation. modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 42: > 40: > 41: import javafx.beans.property.ObjectProperty; > 42: import javafx.beans.property.SimpleObjectProperty; Unused imports modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 58: > 56: @Nested > 57: class WithNull { > 58: @Test Maybe some line separation between the classes is helpful. Same for other places in this class. modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 356: > 354: } > 355: } > 356: // TODO test for when something is flatMapped to null in getValue call Is this still relevant? I think that you tested it in line 407 `shouldIgnoreFlatMapsToNull`. What I would like to see is a test when `left`, `right` or `unknown`'s value is set to `null`. What I see is `property`'s value being set to `null`, or the reference of one of the above being set to `null`, but not the value itself. Only when you compose `orElse` on `flatMap` this case is tested (line 604). Is this what you meant? modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 363: > 361: private StringProperty right = new SimpleStringProperty("RIGHT"); > 362: private StringProperty unknown = new SimpleStringProperty("UNKNOWN"); > 363: private ObservableValue observableValue = property.flatMap(v -> "Left".equals(v) ? left : "Right".equals(v) ? right : unknown); Maybe break this line since it's too long. I think that 120 characters is the maximum length. modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 379: > 377: @Test > 378: void shouldReturnPropertyValuesWithOperationApplied() { > 379: assertEquals("UNKNOWN", observableValue.getValue()); // initially it is not left or right, so unknown Maybe these comments should be in the `String message` argument? I don't mind either way. modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 457: > 455: right = null; > 456: > 457: property.set("Right"); Isn't `unknown = null;` enough like you did previously? It doesn't really matter, just for consistency. modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 648: > 646: > 647: /** > 648: * Ensures nothing has been observed. "Ensures nothing has been observed since the last check" or something like that because the values get cleared. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From kcr at openjdk.java.net Tue Mar 8 23:16:13 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Mar 2022 23:16:13 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v10] In-Reply-To: <9qptJl8AlWNDb6Usyn9kcx_GJ5QYFvoSdnK6KPdCZOo=.9cdb587f-2c02-4421-9b65-44a81a98ba04@github.com> References: <9qptJl8AlWNDb6Usyn9kcx_GJ5QYFvoSdnK6KPdCZOo=.9cdb587f-2c02-4421-9b65-44a81a98ba04@github.com> Message-ID: On Tue, 8 Mar 2022 20:32:53 GMT, Thiago Milczarek Sayao wrote: >> Found the problem thru this path: >> >> **WindowStage.java** >> >> final void handleFocusDisabled() { >> if (activeWindows.isEmpty()) { >> return; >> } >> WindowStage window = activeWindows.get(activeWindows.size() - 1); >> window.setIconified(false); >> window.requestToFront(); >> window.requestFocus(); >> } >> >> >> **glass_window.cpp** >> >> void WindowContextBase::process_focus(GdkEventFocus* event) { >> ... >> >> if (jwindow) { >> if (!event->in || isEnabled()) { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, >> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); >> CHECK_JNI_EXCEPTION(mainEnv) >> } else { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); >> CHECK_JNI_EXCEPTION(mainEnv) >> } >> } >> } >> >> >> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). >> >> The docs states: >> >> /** >> * Enables or disables the window. >> * >> * A disabled window is unfocusable by definition. >> * Also, key or mouse events aren't generated for disabled windows. >> * >> * When a user tries to activate a disabled window, or the window gets >> * accidentally brought to the top of the stacking order, the window >> * generates the FOCUS_DISABLED window event. A Glass client should react >> * to this event and bring the currently active modal blocker of the >> * disabled window to top by calling blocker's minimize(false), toFront(), >> * and requestFocus() methods. It may also 'blink' the blocker window to >> * further attract user's attention. >> * >> ..... >> >> >> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. >> >> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Review adjustments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From kcr at openjdk.java.net Tue Mar 8 23:58:13 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Mar 2022 23:58:13 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 11:24:48 GMT, Alexander Matveev wrote: > - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. > - Added support for elementary AAC streams without any container for audio only streams. > - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. > - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. All my testing looks good. I spot checked the new code, and it looks good as well. I left a couple questions for you, but I'll approved it as is. modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/HLSConnectionHolder.java line 406: > 404: mediaFileIndex = 0; > 405: } > 406: } catch (Exception e) { Do you need to catch exceptions here? Or would just doing a try / finally be sufficient? If you do intend to catch all exceptions here, should some logging or error handling be done if an exceptions occurs? modules/javafx.media/src/main/native/gstreamer/plugins/dshowwrapper/dshowwrapper.cpp line 1954: > 1952: } > 1953: > 1954: if (decoder->pDecoder != NULL && decoder->pGraph != NULL) Can `decoder->pDecoder` be non-null and `decoder->pGraph` be null? If so, then the decoder wouldn't be released. Does it need to be? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/726 From arapte at openjdk.java.net Wed Mar 9 04:12:02 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 9 Mar 2022 04:12:02 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v10] In-Reply-To: <9qptJl8AlWNDb6Usyn9kcx_GJ5QYFvoSdnK6KPdCZOo=.9cdb587f-2c02-4421-9b65-44a81a98ba04@github.com> References: <9qptJl8AlWNDb6Usyn9kcx_GJ5QYFvoSdnK6KPdCZOo=.9cdb587f-2c02-4421-9b65-44a81a98ba04@github.com> Message-ID: <9FC_8VMnxwNe5iMiJyhNM1kKSbX8X4PalPiDiUC83d0=.979d6324-8b42-4a21-98ac-dd31a82c7670@github.com> On Tue, 8 Mar 2022 20:32:53 GMT, Thiago Milczarek Sayao wrote: >> Found the problem thru this path: >> >> **WindowStage.java** >> >> final void handleFocusDisabled() { >> if (activeWindows.isEmpty()) { >> return; >> } >> WindowStage window = activeWindows.get(activeWindows.size() - 1); >> window.setIconified(false); >> window.requestToFront(); >> window.requestFocus(); >> } >> >> >> **glass_window.cpp** >> >> void WindowContextBase::process_focus(GdkEventFocus* event) { >> ... >> >> if (jwindow) { >> if (!event->in || isEnabled()) { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, >> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); >> CHECK_JNI_EXCEPTION(mainEnv) >> } else { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); >> CHECK_JNI_EXCEPTION(mainEnv) >> } >> } >> } >> >> >> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). >> >> The docs states: >> >> /** >> * Enables or disables the window. >> * >> * A disabled window is unfocusable by definition. >> * Also, key or mouse events aren't generated for disabled windows. >> * >> * When a user tries to activate a disabled window, or the window gets >> * accidentally brought to the top of the stacking order, the window >> * generates the FOCUS_DISABLED window event. A Glass client should react >> * to this event and bring the currently active modal blocker of the >> * disabled window to top by calling blocker's minimize(false), toFront(), >> * and requestFocus() methods. It may also 'blink' the blocker window to >> * further attract user's attention. >> * >> ..... >> >> >> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. >> >> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Review adjustments Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From almatvee at openjdk.java.net Wed Mar 9 05:10:15 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 9 Mar 2022 05:10:15 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming In-Reply-To: References: Message-ID: On Sat, 26 Feb 2022 00:30:10 GMT, Kevin Rushforth wrote: >> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. >> - Added support for elementary AAC streams without any container for audio only streams. >> - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. >> - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. > > modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/HLSConnectionHolder.java line 406: > >> 404: mediaFileIndex = 0; >> 405: } >> 406: } catch (Exception e) { > > Do you need to catch exceptions here? Or would just doing a try / finally be sufficient? If you do intend to catch all exceptions here, should some logging or error handling be done if an exceptions occurs? No. Removed. ------------- PR: https://git.openjdk.java.net/jfx/pull/726 From almatvee at openjdk.java.net Wed Mar 9 05:20:00 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 9 Mar 2022 05:20:00 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v2] In-Reply-To: References: Message-ID: > - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. > - Added support for elementary AAC streams without any container for audio only streams. > - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. > - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v2] ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/726/files - new: https://git.openjdk.java.net/jfx/pull/726/files/01720c79..08ce8569 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=726&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=726&range=00-01 Stats: 11 lines in 2 files changed: 3 ins; 7 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/726.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/726/head:pull/726 PR: https://git.openjdk.java.net/jfx/pull/726 From almatvee at openjdk.java.net Wed Mar 9 05:20:01 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 9 Mar 2022 05:20:01 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 23:50:57 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v2] > > modules/javafx.media/src/main/native/gstreamer/plugins/dshowwrapper/dshowwrapper.cpp line 1954: > >> 1952: } >> 1953: >> 1954: if (decoder->pDecoder != NULL && decoder->pGraph != NULL) > > Can `decoder->pDecoder` be non-null and `decoder->pGraph` be null? If so, then the decoder wouldn't be released. Does it need to be? Unlikely. I changed it to check for `if (decoder->pGraph == NULL)` at beginning of function and return `FALSE` if it happens, since we cannot swap decoder if graph is not initialized. Not sure if it can happen, so this check is more for just in case. Yes, we need to release decoder and re-create it during format change. I tried all possible ways to change format dynamically and nothing worked. Only complete recreation of decoder instance worked. ------------- PR: https://git.openjdk.java.net/jfx/pull/726 From jhendrikx at openjdk.java.net Wed Mar 9 07:43:41 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 9 Mar 2022 07:43:41 GMT Subject: RFR: 8281723: Spinner with split horizontal arrows and a border places right arrow incorrectly Message-ID: I added a test case for `SpinnerSkin` that checks the arrow positioning. While adding the tests I discovered more problems with the positioning aside from the one mentioned in the JBS ticket. 1) Vertical split arrow placement also forgot to take the padding into account while placing the decrement arrow button -- I've taken the liberty to fix that problem as well in the same PR. 2) When arrows are placed next to each other either on the right or left, the arrow widths are not normalized to be the width of the widest arrow. All other placements will normalize either the width or height, except for these two. Specifically, when the arrows are **split** on the left and right they **are** normalized to the same width. For point 2, here is the problem illustrated with actual widths on left and layout result on right: [ <----- ] [ -> ] [ spinner ] --> [ <----- ] [ -> ] [ spinner ] [ spinner ] [ <----- ] [ -> ] --> [ spinner ] [ <----- ] [ -> ] While for split horizontal it does normalize the width to that of the widest arrow, and so layout becomes: [ <----- ] [ spinner ] [ -> ] --> [ <----- ] [ spinner ] [ -> ] While I'm here I could fix this as well, and adjust the test case to match. ------------- Commit messages: - 8281723: Fix arrow placement errors in SpinnerSkin Changes: https://git.openjdk.java.net/jfx/pull/748/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=748&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281723 Stats: 146 lines in 2 files changed: 144 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/748.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/748/head:pull/748 PR: https://git.openjdk.java.net/jfx/pull/748 From jhendrikx at openjdk.java.net Wed Mar 9 07:48:53 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 9 Mar 2022 07:48:53 GMT Subject: RFR: 8281723: Spinner with split horizontal arrows and a border places right arrow incorrectly [v2] In-Reply-To: References: Message-ID: > I added a test case for `SpinnerSkin` that checks the arrow positioning. > > While adding the tests I discovered more problems with the positioning aside from the one mentioned in the JBS ticket. > > 1) Vertical split arrow placement also forgot to take the padding into account while placing the decrement arrow button -- I've taken the liberty to fix that problem as well in the same PR. > > 2) When arrows are placed next to each other either on the right or left, the arrow widths are not normalized to be the width of the widest arrow. All other placements will normalize either the width or height, except for these two. Specifically, when the arrows are **split** on the left and right they **are** normalized to the same width. > > For point 2, here is the problem illustrated with actual widths on left and layout result on right: > > [ <----- ] [ -> ] [ spinner ] --> [ <----- ] [ -> ] [ spinner ] > [ spinner ] [ <----- ] [ -> ] --> [ spinner ] [ <----- ] [ -> ] > > While for split horizontal it does normalize the width to that of the widest arrow, and so layout becomes: > > [ <----- ] [ spinner ] [ -> ] --> [ <----- ] [ spinner ] [ -> ] > > While I'm here I could fix this as well, and adjust the test case to match. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/748/files - new: https://git.openjdk.java.net/jfx/pull/748/files/8c7059e0..9bb77d56 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=748&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=748&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/748.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/748/head:pull/748 PR: https://git.openjdk.java.net/jfx/pull/748 From tsayao at openjdk.java.net Wed Mar 9 14:19:11 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 9 Mar 2022 14:19:11 GMT Subject: Integrated: 8271054: [REDO] Wrong stage gets focused after modal stage creation In-Reply-To: References: Message-ID: <9Z8YoA1RrTDctBO6t_I6ZB3kWBE68v1hSKCsyAedwh0=.4e428dba-962b-45f4-9853-d8b36ed6df3a@github.com> On Thu, 5 Aug 2021 23:38:06 GMT, Thiago Milczarek Sayao wrote: > Found the problem thru this path: > > **WindowStage.java** > > final void handleFocusDisabled() { > if (activeWindows.isEmpty()) { > return; > } > WindowStage window = activeWindows.get(activeWindows.size() - 1); > window.setIconified(false); > window.requestToFront(); > window.requestFocus(); > } > > > **glass_window.cpp** > > void WindowContextBase::process_focus(GdkEventFocus* event) { > ... > > if (jwindow) { > if (!event->in || isEnabled()) { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, > event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); > CHECK_JNI_EXCEPTION(mainEnv) > } else { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); > CHECK_JNI_EXCEPTION(mainEnv) > } > } > } > > > So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). > > The docs states: > > /** > * Enables or disables the window. > * > * A disabled window is unfocusable by definition. > * Also, key or mouse events aren't generated for disabled windows. > * > * When a user tries to activate a disabled window, or the window gets > * accidentally brought to the top of the stacking order, the window > * generates the FOCUS_DISABLED window event. A Glass client should react > * to this event and bring the currently active modal blocker of the > * disabled window to top by calling blocker's minimize(false), toFront(), > * and requestFocus() methods. It may also 'blink' the blocker window to > * further attract user's attention. > * > ..... > > > So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. > > The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. This pull request has now been integrated. Changeset: c6069d68 Author: Thiago Milczarek Sayao URL: https://git.openjdk.java.net/jfx/commit/c6069d6845df4b90cca226e2b3dff49e3b48d8ac Stats: 23 lines in 2 files changed: 22 ins; 0 del; 1 mod 8271054: [REDO] Wrong stage gets focused after modal stage creation Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From kcr at openjdk.java.net Wed Mar 9 16:04:16 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 9 Mar 2022 16:04:16 GMT Subject: RFR: 8230231: font-family not updated in HTMLEditor [v3] In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 14:56:11 GMT, Hadzic Samir wrote: >> Fix for https://github.com/javafxports/openjdk-jfx/issues/573 >> >> Issue on JBS bug tracking : https://bugs.openjdk.java.net/browse/JDK-8230231 >> >> Fix: Check for quote when updating the font-family comboBox. >> >> A new font is added as a resource for the test. This font is same as modules/javafx.web/src/main/native/Tools/DumpRenderTree/fonts/WebKitWeightWatcher100.ttf > > Hadzic Samir has updated the pull request incrementally with one additional commit since the last revision: > > Add a unit test @jaybhaskar Can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/12 From alexsch at openjdk.java.net Wed Mar 9 18:26:16 2022 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Wed, 9 Mar 2022 18:26:16 GMT Subject: RFR: 8282886: Mouse event is generated outside of node on Raspberry Pi with Touchscreen Message-ID: Tapping on a circle in the center of the screen sometimes generates mouse click events outside the circle with x coordinates set to zero. To reproduce the issue run the [JFXCircle](https://bugs.openjdk.java.net/secure/attachment/98241/JFXCircle.java) sample. It has a circle in the center of the screen and a large rectangle under the circle which covers the whole screen. Tap quickly 10 times on the circle. The output is: circle mouse pressed [416.000000, 199.000000]: 1 circle mouse pressed [416.000000, 199.000000]: 2 circle mouse pressed [419.000000, 196.000000]: 3 circle mouse pressed [416.000000, 188.000000]: 4 circle mouse pressed [419.000000, 190.000000]: 5 rectangle mouse pressed [0.000000, 188.000000] circle mouse pressed [422.000000, 185.000000]: 6 circle mouse pressed [418.000000, 191.000000]: 7 circle mouse pressed [417.000000, 187.000000]: 8 circle mouse pressed [420.000000, 185.000000]: 9 circle mouse pressed [416.000000, 187.000000]: 10 circle mouse pressed [417.000000, 192.000000]: 11 circle mouse pressed [420.000000, 188.000000]: 12 One mouse event is reported by the rectangle with zero x coordinate. The issue occurs when one of ABS_MT_POSITION_X or Y position is not reported. For example, the output from `evtest /dev/input/event2` Event: time 1646845728.905383, -------------- SYN_REPORT ------------ Event: time 1646845728.935382, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 1308 Event: time 1646845728.935382, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 449 Event: time 1646845728.935382, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 240 Event: time 1646845728.935382, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1 Event: time 1646845728.935382, type 3 (EV_ABS), code 0 (ABS_X), value 449 Event: time 1646845728.935382, type 3 (EV_ABS), code 1 (ABS_Y), value 240 Event: time 1646845728.935382, -------------- SYN_REPORT ------------ Event: time 1646845729.025363, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 242 Event: time 1646845729.025363, type 3 (EV_ABS), code 1 (ABS_Y), value 242 Event: time 1646845729.025363, -------------- SYN_REPORT ------------ Event: time 1646845729.055379, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1 Event: time 1646845729.055379, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0 Event: time 1646845729.055379, -------------- SYN_REPORT ------------ The first SYN_REPORT reports ABS_MT_POSITION_X/Y [449, 240] coordinates. The second SYN_REPORT reports only ABS_MT_POSITION_Y value 242 and the ABS_MT_POSITION_X becomes undefined. As a result, the LinuxStatefulMultiTouchProcessor.updatePoint(x, y) method does not set the p.x value and it is left as zero. https://github.com/openjdk/jfx/blob/c6069d6845df4b90cca226e2b3dff49e3b48d8ac/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LinuxStatefulMultiTouchProcessor.java#L161 The fix checks if ABS_MT_POSITION_X/Y value is undefined to use the previous ABS_MT_POSITION_X/Y value for the current slot. The first commit queries ABS_MT_SLOT maximum value to store slot IDs in an array. The second commit stores ABS_MT_POSITION_X/Y values in slotToX/Y values and uses them for current undefined values. ------------- Commit messages: - Use previous x/y values in case the current x/y values are undefined - Use ABS_MT_SLOT maximum value to store slots ids in array Changes: https://git.openjdk.java.net/jfx/pull/749/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=749&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282886 Stats: 26 lines in 1 file changed: 10 ins; 5 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/749.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/749/head:pull/749 PR: https://git.openjdk.java.net/jfx/pull/749 From kcr at openjdk.java.net Wed Mar 9 19:36:57 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 9 Mar 2022 19:36:57 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v2] In-Reply-To: References: Message-ID: <8CzRq04445FXcJbgkkRZGfygKzKkifVkAokVjwoR7kw=.e9dca3f0-01e4-4acc-b368-beca6da0eb7c@github.com> On Wed, 9 Mar 2022 05:20:00 GMT, Alexander Matveev wrote: >> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. >> - Added support for elementary AAC streams without any container for audio only streams. >> - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. >> - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v2] Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/726 From jhendrikx at openjdk.java.net Thu Mar 10 05:36:49 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 10 Mar 2022 05:36:49 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v8] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Tue, 8 Mar 2022 21:10:46 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix wrong test values > > modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 356: > >> 354: } >> 355: } >> 356: // TODO test for when something is flatMapped to null in getValue call > > Is this still relevant? I think that you tested it in line 407 `shouldIgnoreFlatMapsToNull`. > > What I would like to see is a test when `left`, `right` or `unknown`'s value is set to `null`. What I see is `property`'s value being set to `null`, or the reference of one of the above being set to `null`, but not the value itself. Only when you compose `orElse` on `flatMap` this case is tested (line 604). > Is this what you meant? I left that TODO in by accident after my clean up of the test case, I added the case then. I've however also added one more case that you described above: @Test void shouldObserveNullWhenFlatMappedPropertyIsSetToNull() { property.set("Right"); assertObserved("RIGHT"); property.set(null); assertObserved((String)null); } > modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 457: > >> 455: right = null; >> 456: >> 457: property.set("Right"); > > Isn't `unknown = null;` enough like you did previously? It doesn't really matter, just for consistency. Just trying to be thorough on testing all the `null` cases ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Thu Mar 10 05:44:35 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 10 Mar 2022 05:44:35 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v9] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Process review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/675/files - new: https://git.openjdk.java.net/jfx/pull/675/files/30733ccb..29dc2af7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=07-08 Stats: 18 lines in 1 file changed: 14 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/675/head:pull/675 PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Thu Mar 10 05:44:36 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 10 Mar 2022 05:44:36 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v8] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Tue, 8 Mar 2022 20:57:53 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix wrong test values > > modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 379: > >> 377: @Test >> 378: void shouldReturnPropertyValuesWithOperationApplied() { >> 379: assertEquals("UNKNOWN", observableValue.getValue()); // initially it is not left or right, so unknown > > Maybe these comments should be in the `String message` argument? I don't mind either way. I've left these as is, I don't find the messages in asserts particularly useful unless they describe which parameters are used when the assert is used in a parameterized test or a loop. I added the comments more to help readers of the code what the thought process was behind the test, not so much to describe the error. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From julien.dehaudt at st.com Thu Mar 10 07:44:05 2022 From: julien.dehaudt at st.com (Julien DEHAUDT) Date: Thu, 10 Mar 2022 07:44:05 +0000 Subject: Missing vcruntime140_1.dll Message-ID: Hello, This thread is a follow-up of existing issue on Adoptium GitHub, see https://github.com/adoptium/adoptium-support/issues/307. In short we are in a dead end with integrating OpenJFX in OpenJDK 11 for Windows x86 platforms. We get OpenJFX jmods from Gluon and OpenJDK from Adoptium. x86 jmods are only available with JavaFX LTS 17, while using this version with OpenJDK 11 results in "java.lang.UnsatisfiedLinkError: C:\****\jre\bin\glass.dll: Can't find dependent libraries" because of missing library on the system (vcruntime140_1.dll). I'm wondering if a "simple" backport of https://bugs.openjdk.java.net/browse/JDK-8242468 to OpenJDK 11 wouldn't be enough to make it working. If so, is there a graceful volunteer ? Thanks and Regards, Julien From julien.dehaudt at st.com Thu Mar 10 07:56:17 2022 From: julien.dehaudt at st.com (Julien DEHAUDT) Date: Thu, 10 Mar 2022 07:56:17 +0000 Subject: Missing vcruntime140_1.dll In-Reply-To: References: Message-ID: Replying myself thanks to this list archives. The issue looks closely related to this discussion: https://mail.openjdk.java.net/pipermail/openjfx-dev/2022-March/033687.html Recently resolved: https://bugs.openjdk.java.net/browse/JDK-8282655 /Julien -----Original Message----- From: openjfx-dev On Behalf Of Julien DEHAUDT Sent: jeudi 10 mars 2022 08:44 To: openjfx-dev at openjdk.java.net Subject: Missing vcruntime140_1.dll Hello, This thread is a follow-up of existing issue on Adoptium GitHub, see https://github.com/adoptium/adoptium-support/issues/307. In short we are in a dead end with integrating OpenJFX in OpenJDK 11 for Windows x86 platforms. We get OpenJFX jmods from Gluon and OpenJDK from Adoptium. x86 jmods are only available with JavaFX LTS 17, while using this version with OpenJDK 11 results in "java.lang.UnsatisfiedLinkError: C:\****\jre\bin\glass.dll: Can't find dependent libraries" because of missing library on the system (vcruntime140_1.dll). I'm wondering if a "simple" backport of https://bugs.openjdk.java.net/browse/JDK-8242468 to OpenJDK 11 wouldn't be enough to make it working. If so, is there a graceful volunteer ? Thanks and Regards, Julien From julien.dehaudt at st.com Thu Mar 10 09:40:11 2022 From: julien.dehaudt at st.com (Julien DEHAUDT) Date: Thu, 10 Mar 2022 09:40:11 +0000 Subject: Missing vcruntime140_1.dll In-Reply-To: References: Message-ID: Damn... I screwed up... please ignore my last message. I read to fast and thought the fix was in openjdk11.0.15... Instead I'd propose back again: I'm wondering if a "simple" backport of https://bugs.openjdk.java.net/browse/JDK-8242468 to OpenJDK 11 wouldn't be enough to make it working. If so, is there a graceful volunteer ? /Julien -----Original Message----- From: openjfx-dev On Behalf Of Julien DEHAUDT Sent: jeudi 10 mars 2022 08:56 To: openjfx-dev at openjdk.java.net Subject: RE: Missing vcruntime140_1.dll Replying myself thanks to this list archives. The issue looks closely related to this discussion: https://mail.openjdk.java.net/pipermail/openjfx-dev/2022-March/033687.html Recently resolved: https://bugs.openjdk.java.net/browse/JDK-8282655 /Julien -----Original Message----- From: openjfx-dev On Behalf Of Julien DEHAUDT Sent: jeudi 10 mars 2022 08:44 To: openjfx-dev at openjdk.java.net Subject: Missing vcruntime140_1.dll Hello, This thread is a follow-up of existing issue on Adoptium GitHub, see https://github.com/adoptium/adoptium-support/issues/307. In short we are in a dead end with integrating OpenJFX in OpenJDK 11 for Windows x86 platforms. We get OpenJFX jmods from Gluon and OpenJDK from Adoptium. x86 jmods are only available with JavaFX LTS 17, while using this version with OpenJDK 11 results in "java.lang.UnsatisfiedLinkError: C:\****\jre\bin\glass.dll: Can't find dependent libraries" because of missing library on the system (vcruntime140_1.dll). I'm wondering if a "simple" backport of https://bugs.openjdk.java.net/browse/JDK-8242468 to OpenJDK 11 wouldn't be enough to make it working. If so, is there a graceful volunteer ? Thanks and Regards, Julien From zjx001202 at gmail.com Thu Mar 10 11:50:53 2022 From: zjx001202 at gmail.com (Glavo) Date: Thu, 10 Mar 2022 19:50:53 +0800 Subject: Feature request: System tray support Message-ID: This feature has been requested by users a decade ago (JDK-8092115), but so far there seems to be no progress. Now, to support the system tray, we need to use AWT. Frustratingly, this not only makes the program load and initialize more code, but it also hinders the generation of native-images for JavaFX applications. So I implore you to put system tray support in JavaFX on the agenda. From nlisker at openjdk.java.net Thu Mar 10 14:34:15 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 10 Mar 2022 14:34:15 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v9] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Thu, 10 Mar 2022 05:44:35 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Process review comments Looks very good. I left a few minor optional comments after doing a quick re-review of everything. You can wait until the other reviews with these if you want. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 211: > 209: * .orElse(false); > 210: * > 211: * // Assuming the listView is currently shown to the user then: Comma before "then" modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 57: > 55: @Nested > 56: class WithNull { > 57: @Test New line modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 79: > 77: @Nested > 78: class When_getValue_Called { > 79: @Test New line modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 289: > 287: @Nested > 288: class When_getValue_Called { > 289: @Test New line modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 351: > 349: @Nested > 350: class WithNull { > 351: @Test New line modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 377: > 375: @Nested > 376: class When_getValue_Called { > 377: @Test New line ------------- Marked as reviewed by nlisker (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/675 From nlisker at openjdk.java.net Thu Mar 10 14:34:18 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 10 Mar 2022 14:34:18 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v8] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Tue, 8 Mar 2022 21:03:12 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix wrong test values > > modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 648: > >> 646: >> 647: /** >> 648: * Ensures nothing has been observed. > > "Ensures nothing has been observed since the last check" or something like that because the values get cleared. Do you think it's not necessary? ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From kevin.rushforth at oracle.com Thu Mar 10 15:23:30 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 10 Mar 2022 07:23:30 -0800 Subject: Missing vcruntime140_1.dll In-Reply-To: References: Message-ID: <25e9d0e6-f9fd-b714-7967-57e31c88edd7@oracle.com> This was recently fixed by https://bugs.openjdk.java.net/browse/JDK-8281089 -- Kevin On 3/9/2022 11:44 PM, Julien DEHAUDT wrote: > Hello, > > This thread is a follow-up of existing issue on Adoptium GitHub, see https://github.com/adoptium/adoptium-support/issues/307. > > In short we are in a dead end with integrating OpenJFX in OpenJDK 11 for Windows x86 platforms. We get OpenJFX jmods from Gluon and OpenJDK from Adoptium. > x86 jmods are only available with JavaFX LTS 17, while using this version with OpenJDK 11 results in "java.lang.UnsatisfiedLinkError: C:\****\jre\bin\glass.dll: Can't find dependent libraries" because of missing library on the system (vcruntime140_1.dll). > > I'm wondering if a "simple" backport of https://bugs.openjdk.java.net/browse/JDK-8242468 to OpenJDK 11 wouldn't be enough to make it working. > If so, is there a graceful volunteer ? > > Thanks and Regards, > Julien From kevin.rushforth at oracle.com Thu Mar 10 15:33:08 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 10 Mar 2022 07:33:08 -0800 Subject: Missing vcruntime140_1.dll In-Reply-To: References: Message-ID: No, as mentioned in my recent reply (which was done after you sent this), the bug and ultimate solution was in JavaFX. See JDK-8281089 [1]. I also refer you to PR #734 [2] where this was discussed in detail. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8281089 [2] https://git.openjdk.java.net/jfx/pull/734 On 3/10/2022 1:40 AM, Julien DEHAUDT wrote: > Damn... I screwed up... please ignore my last message. > I read to fast and thought the fix was in openjdk11.0.15... > > Instead I'd propose back again: > I'm wondering if a "simple" backport of https://bugs.openjdk.java.net/browse/JDK-8242468 to OpenJDK 11 wouldn't be enough to make it working. > If so, is there a graceful volunteer ? > > /Julien > > -----Original Message----- > From: openjfx-dev On Behalf Of Julien DEHAUDT > Sent: jeudi 10 mars 2022 08:56 > To: openjfx-dev at openjdk.java.net > Subject: RE: Missing vcruntime140_1.dll > > Replying myself thanks to this list archives. > > The issue looks closely related to this discussion: https://mail.openjdk.java.net/pipermail/openjfx-dev/2022-March/033687.html > Recently resolved: https://bugs.openjdk.java.net/browse/JDK-8282655 > > /Julien > > -----Original Message----- > From: openjfx-dev On Behalf Of Julien DEHAUDT > Sent: jeudi 10 mars 2022 08:44 > To: openjfx-dev at openjdk.java.net > Subject: Missing vcruntime140_1.dll > > Hello, > > This thread is a follow-up of existing issue on Adoptium GitHub, see https://github.com/adoptium/adoptium-support/issues/307. > > In short we are in a dead end with integrating OpenJFX in OpenJDK 11 for Windows x86 platforms. We get OpenJFX jmods from Gluon and OpenJDK from Adoptium. > x86 jmods are only available with JavaFX LTS 17, while using this version with OpenJDK 11 results in "java.lang.UnsatisfiedLinkError: C:\****\jre\bin\glass.dll: Can't find dependent libraries" because of missing library on the system (vcruntime140_1.dll). > > I'm wondering if a "simple" backport of https://bugs.openjdk.java.net/browse/JDK-8242468 to OpenJDK 11 wouldn't be enough to make it working. > If so, is there a graceful volunteer ? > > Thanks and Regards, > Julien From jhendrikx at openjdk.java.net Thu Mar 10 17:49:38 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 10 Mar 2022 17:49:38 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v10] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Process review comments (2) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/675/files - new: https://git.openjdk.java.net/jfx/pull/675/files/29dc2af7..8f9bf897 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=08-09 Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/675/head:pull/675 PR: https://git.openjdk.java.net/jfx/pull/675 From julien.dehaudt at st.com Thu Mar 10 20:15:12 2022 From: julien.dehaudt at st.com (Julien DEHAUDT) Date: Thu, 10 Mar 2022 20:15:12 +0000 Subject: Missing vcruntime140_1.dll In-Reply-To: <25e9d0e6-f9fd-b714-7967-57e31c88edd7@oracle.com> References: <25e9d0e6-f9fd-b714-7967-57e31c88edd7@oracle.com> Message-ID: Great, thanks for the pointer Kevin! Looking forward for next JavaFX version. /Julien ST Restricted -----Original Message----- From: openjfx-dev On Behalf Of Kevin Rushforth Sent: jeudi 10 mars 2022 16:24 To: openjfx-dev at openjdk.java.net Subject: Re: Missing vcruntime140_1.dll This was recently fixed by https://bugs.openjdk.java.net/browse/JDK-8281089 -- Kevin On 3/9/2022 11:44 PM, Julien DEHAUDT wrote: > Hello, > > This thread is a follow-up of existing issue on Adoptium GitHub, see https://github.com/adoptium/adoptium-support/issues/307. > > In short we are in a dead end with integrating OpenJFX in OpenJDK 11 for Windows x86 platforms. We get OpenJFX jmods from Gluon and OpenJDK from Adoptium. > x86 jmods are only available with JavaFX LTS 17, while using this version with OpenJDK 11 results in "java.lang.UnsatisfiedLinkError: C:\****\jre\bin\glass.dll: Can't find dependent libraries" because of missing library on the system (vcruntime140_1.dll). > > I'm wondering if a "simple" backport of https://bugs.openjdk.java.net/browse/JDK-8242468 to OpenJDK 11 wouldn't be enough to make it working. > If so, is there a graceful volunteer ? > > Thanks and Regards, > Julien From nlisker at openjdk.java.net Thu Mar 10 22:09:04 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 10 Mar 2022 22:09:04 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v10] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Thu, 10 Mar 2022 17:49:38 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Process review comments (2) Re-approving ------------- Marked as reviewed by nlisker (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/675 From almatvee at openjdk.java.net Fri Mar 11 03:08:24 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 11 Mar 2022 03:08:24 GMT Subject: RFR: 8282054: Mediaplayer not working with HTTP Live Stream link with query parameter appended with file extension m3u8 Message-ID: - Problem was that our code which checks if URI ends with file extension was not considering that URI can have query parameters. Fixed by checking URI path, instead of actual URI. - Also, creation of HLS Connection holder was missing checking for mimetype, since we do support URI without extensions as long as they provide correct mimetype. - Added #EXTM3U to file signature check in case if extension and mimetype checks failed to determine stream type. All playlists of HLS based on spec should start with #EXTM3U. For some reason this particular stream has mimetype of "audio/x-mpegurl" and it is not mimetype from spec. Based on spec it should be "audio/mpegurl". Thus check for signature was added in case if URI does not use extension and has unsupported mimetype. Note: audio will not work on Windows and Linux for stream provided in this bug report due to provided example uses separate audio stream via EXT-X-MEDIA tag and it is not supported. I filed separate issue for this. ------------- Commit messages: - 8282054: Mediaplayer not working with HTTP Live Stream link with query parameter appended with file extension m3u8 Changes: https://git.openjdk.java.net/jfx/pull/750/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=750&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282054 Stats: 65 lines in 2 files changed: 27 ins; 3 del; 35 mod Patch: https://git.openjdk.java.net/jfx/pull/750.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/750/head:pull/750 PR: https://git.openjdk.java.net/jfx/pull/750 From jhendrikx at openjdk.java.net Fri Mar 11 06:02:51 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 11 Mar 2022 06:02:51 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v8] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Thu, 10 Mar 2022 14:21:15 GMT, Nir Lisker wrote: >> modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 648: >> >>> 646: >>> 647: /** >>> 648: * Ensures nothing has been observed. >> >> "Ensures nothing has been observed since the last check" or something like that because the values get cleared. > > Do you think it's not necessary? I missed this one during staging, added it the 2nd time. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From aghaisas at openjdk.java.net Fri Mar 11 11:02:57 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 11 Mar 2022 11:02:57 GMT Subject: RFR: 8282093: LineChart path incorrect when outside lower bound [v2] In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 06:12:59 GMT, Abhinay Agarwal wrote: >> This regression was caused in PR #667 in which I didn't take into account the lower bounds. I have added more tests and one manual test along with the fix. The manual test can be used to identify any future issues with paths outside lower and upper bounds easily. > > Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: > > Improve layout in manual test Thanks for fixing this regression. Changes look good. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/744 From duke at openjdk.java.net Fri Mar 11 15:23:54 2022 From: duke at openjdk.java.net (chilliger) Date: Fri, 11 Mar 2022 15:23:54 GMT Subject: RFR: 8282703: Axis is not cached in the LinuxTouchTransform class In-Reply-To: References: Message-ID: <4nzRhSXhXqg2IsefLpbCB48_M_wEsQo-7wPHI_z2d7U=.ccb58359-6b7a-4fdb-85dc-ae6ea0f4c82f@github.com> On Sat, 5 Mar 2022 15:53:52 GMT, Alexander Scherbatiy wrote: > An axis is not cached in the LinuxTouchTransform class. > > To reproduce the issue I added `System.out.printf("initTransform: axis: %d, index: %d%n", axis, index);` log to the LinuxTouchTransform.initTransform() method: > https://github.com/openjdk/jfx/blob/5112be957be70dd6521e6fb6ee64e669c148729c/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LinuxTouchTransform.java#L117 > run the [JFXButtonExample](https://bugs.openjdk.java.net/secure/attachment/98181/JFXButtonExample.java) sample and tapped the touch screen on a Raspberry Pi with Touchscreen. > > The result was > > initTransform: axis: 47, index: 0 > initTransform: axis: 57, index: 0 > initTransform: axis: 53, index: 0 > initTransform: axis: 54, index: 0 > initTransform: axis: 0, index: 0 > initTransform: axis: 1, index: 0 > initTransform: axis: 53, index: 0 > initTransform: axis: 54, index: 0 > initTransform: axis: 0, index: 0 > initTransform: axis: 1, index: 0 > initTransform: axis: 53, index: 0 > initTransform: axis: 54, index: 0 > initTransform: axis: 0, index: 0 > initTransform: axis: 1, index: 0 > > The initTransform() is called several times for axis 0,1,47,53,54 and index is always set to zero. > > The straight forward fix is to store the given axis in the axes array: "axes[index] = axis". This is the first commit for the current fix. > Using this fix the output with printf from initTransform() method looks like: > > initTransform: axis: 47, index: 0 > initTransform: axis: 57, index: 1 > initTransform: axis: 53, index: 2 > initTransform: axis: 54, index: 4 > initTransform: axis: 1, index: 5 > > Now all axes are printed only once and the index value is different for each axes. > > However, the minimum/maximum values are retrieved and cached for ABS_X/Y and ABS_MT_POSITION_X/Y axes after the fist tap on the screen. > The second commit improves this moving the ABS_X/Y and ABS_MT_POSITION_X/Y axes initialization into the LinuxTouchTransform constructor. > > Now the touch logs look like: > > // LinuxTouchTransform constructor > // device: /dev/input/mouse0 > initTransform: axis: 0, index: 0 > initTransform: axis: 1, index: 1 > initTransform: axis: 53, index: 2 > initTransform: axis: 54, index: 3 > > // LinuxTouchTransform constructor > // device: /dev/input/event2 > initTransform: axis: 0, index: 0 > initTransform: axis: 1, index: 1 > initTransform: axis: 53, index: 2 > initTransform: axis: 54, index: 3 > > // the first tap > initTransform: axis: 57, index: 4 > initTransform: axis: 47, index: 5 > > > The ABS_X/Y and ABS_MT_POSITION_X/Y axes and corresponding minimum/maximum values are initialized in the constructor. The other axes which stores only default values in translates and scalars arrays are initialized during touch events. @AlexanderScherbatiy Did I miss something? Is touch now support with GTK? I thought the implementation is missing for GTK: https://github.com/openjdk/jfx/pull/457 ------------- PR: https://git.openjdk.java.net/jfx/pull/747 From kcr at openjdk.java.net Fri Mar 11 15:29:55 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Mar 2022 15:29:55 GMT Subject: RFR: 8282703: Axis is not cached in the LinuxTouchTransform class In-Reply-To: <4nzRhSXhXqg2IsefLpbCB48_M_wEsQo-7wPHI_z2d7U=.ccb58359-6b7a-4fdb-85dc-ae6ea0f4c82f@github.com> References: <4nzRhSXhXqg2IsefLpbCB48_M_wEsQo-7wPHI_z2d7U=.ccb58359-6b7a-4fdb-85dc-ae6ea0f4c82f@github.com> Message-ID: On Fri, 11 Mar 2022 15:20:17 GMT, chilliger wrote: > Did I miss something? Is touch now support with GTK? I thought the implementation is missing for GTK This PR is for Monocle, which is not used for desktop Linux (it's for embedded systems like Raspberry Pi). ------------- PR: https://git.openjdk.java.net/jfx/pull/747 From mstrauss at openjdk.java.net Sat Mar 12 05:02:14 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 12 Mar 2022 05:02:14 GMT Subject: RFR: 8283063: Optimize Observable{List/Set/Map}Wrapper.retainAll/removeAll Message-ID: `Observable{List/Set/Map}Wrapper.retainAll/removeAll` can be optimized for some edge cases. 1. `removeAll(c)`: This is a no-op if 'c' is empty. For `ObservableListWrapper`, returning early skips an object allocation. For `ObservableSetWrapper` and `ObservableMapWrapper`, returning early prevents an enumeration of the entire collection. 2. `retainAll(c)`: This is a no-op if the backing collection is empty, or equivalent to `clear()` if `c` is empty. I've added some tests to verify the optimized behavior for each of the three classes. ------------- Commit messages: - Optimize removeAll/retainAll for Observable{List/Set/Map}Wrapper - Failing test Changes: https://git.openjdk.java.net/jfx/pull/751/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=751&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283063 Stats: 293 lines in 6 files changed: 290 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/751.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/751/head:pull/751 PR: https://git.openjdk.java.net/jfx/pull/751 From duke at openjdk.java.net Sat Mar 12 10:28:02 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Sat, 12 Mar 2022 10:28:02 GMT Subject: RFR: 8282766: Create release notes for JavaFX 18 Message-ID: Add release notes for JavaFX 18 to the repository ------------- Commit messages: - Create release notes for JavaFX 18 Changes: https://git.openjdk.java.net/jfx/pull/752/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=752&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282766 Stats: 110 lines in 1 file changed: 110 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/752.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/752/head:pull/752 PR: https://git.openjdk.java.net/jfx/pull/752 From kcr at openjdk.java.net Sat Mar 12 13:57:47 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Mar 2022 13:57:47 GMT Subject: RFR: 8282766: Create release notes for JavaFX 18 In-Reply-To: References: Message-ID: <_9E_tWhPyev01-G3B_kLvPkZwZ0al0-5BRH5Gzkt38A=.fca82e90-2a40-421b-aa93-f64e6b7922ca@github.com> On Sat, 12 Mar 2022 10:18:07 GMT, Abhinay Agarwal wrote: > Add release notes for JavaFX 18 to the repository Looks good other than one typo: Enhancement --> Enhancements doc-files/release-notes-18.md line 18: > 16: See [JDK-8273089](https://bugs.openjdk.java.net/browse/JDK-8273089) for more information. > 17: > 18: ## List of Enhancement That should be "Enhancements" (plural). ------------- PR: https://git.openjdk.java.net/jfx/pull/752 From kcr at openjdk.java.net Sat Mar 12 14:11:46 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Mar 2022 14:11:46 GMT Subject: RFR: 8282093: LineChart path incorrect when outside lower bound [v2] In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 06:12:59 GMT, Abhinay Agarwal wrote: >> This regression was caused in PR #667 in which I didn't take into account the lower bounds. I have added more tests and one manual test along with the fix. The manual test can be used to identify any future issues with paths outside lower and upper bounds easily. > > Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: > > Improve layout in manual test This doesn't need a second reviewer. ------------- PR: https://git.openjdk.java.net/jfx/pull/744 From kcr at openjdk.java.net Sat Mar 12 14:20:48 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Mar 2022 14:20:48 GMT Subject: RFR: 8282766: Create release notes for JavaFX 18 In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 10:18:07 GMT, Abhinay Agarwal wrote: > Add release notes for JavaFX 18 to the repository I see that this is targeted to the `master` branch. It should be targeted to `jfx18`. Since your branch is based on `master` you will need to rebase your branch and force-push before changing the target of the PR to `jfx18`. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/752 From john.hendrikx at gmail.com Sat Mar 12 14:56:45 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 12 Mar 2022 15:56:45 +0100 Subject: Tough issue with Text not drawn correctly, any experts that can take a look? Message-ID: TLDR: Skip to the Github link below. So, I've run into an issue where a Label with wrap text set to true is only showing the first character of the text "as Kristoff (voice)" while all other kinds of texts show up correct (there's 100's of examples that all work, but only found one so far that doesn't work).? The label is placed in a VBox together with an Image and another wrap text Label. Now, there is something really odd going on.? These VBox are placed in a 3x3 Grid, and basically all of the labels used are displayed correctly.? The Grid is fixed size, but the VBox content is rather flexible, and Labels that have a large amount of text should be wrapped and cause the Image in the VBox to become smaller to make space. If I set the text of all these labels to a fixed value "as Kristoff (voice)" then ALL of them render incorrectly, only showing "a".? When I change the text to include a space behind the last character, then ALL of them render correctly.? In fact, any kind of change I do (like adding a "-" infront of this text) fixes the display problem.? So I suspect the issue has to do with the exact width of the text (126.0 in my case). If I select the grid cell or move the cursor, the rendering immediately becomes correct for the cells involved, but all other cells keep showing just the "a".? If I hack LabeledSkinBase and remove the clip it generates if text doesn't fit, I can see that the ACTUAL content of the label is "a" and on the next line is "s Kristoff (voice)".? If I highlight the background of this label, I can see a box that would exactly fit the full text (and the box is only one line high), but it just isn't drawning it -- it only draws the "a" in the exact center of this box... It seems to know that the box should be that size to fit the label, but the text wasn't redrawn. Now, because this layout is relatively complicated, with two reflowing labels and an Image that can "sacrifice" space if the labels demand more, I suspect JavaFX is doing multiple passes to get it correct -- debugging output does confirm that it does several attempts to get to the final size for this label (it starts with a width of 12.66 and a huge height wrapping on every character, then goes to 51x40 orso before settling on 126.0x18). After a couple of hours debugging this and adding debug prints everywhere I started to suspect it was just not refreshing the Text or PrismTextLayout when it should; there is a LOT of caching and partial invalidation logic going on in these classes, most of which I just disabled during my search. Finally I came to a piece of code in Text which is invalidating the text when `wrappingWidth` changes.? Changing only a single line there fixes my problem, but I'm unable to explain why.? I'm hoping someone can take a look at this code and say whether or not this change is indeed correct and the old code was incorrect... A link to Github to the code involved: https://github.com/openjdk/jfx/blob/c6069d6845df4b90cca226e2b3dff49e3b48d8ac/modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java#L669-L687 In this code there is a call to `needsTextLayout`.? Changing that to `needsFullTextLayout` fixes my issue. The difference between `needsTextLayout` and `needsFullTextLayout` seems to be a call to TextLayout#setContent where the text and font is set. If anyone knows this code that could help, or perhaps say if this change makes sense or not that would be helpful. I can be available for a call or whatever to give more details. I would love to "fix" this in JavaFX via PR, but as I don't know how to test for this issue nor even how to describe it ("In super rare cases a wrappable label which in the end doesn't need wrapping only displays a single character"?) I'm unsure how I should file it to get a fix accepted :) --John From duke at openjdk.java.net Sun Mar 13 10:07:26 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Sun, 13 Mar 2022 10:07:26 GMT Subject: [jfx18] RFR: 8282766: Create release notes for JavaFX 18 [v2] In-Reply-To: References: Message-ID: > Add release notes for JavaFX 18 to the repository Abhinay Agarwal has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - s/Enhancement/Enhancements - Create release notes for JavaFX 18 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/752/files - new: https://git.openjdk.java.net/jfx/pull/752/files/e1457420..d5fdfce5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=752&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=752&range=00-01 Stats: 442154 lines in 6858 files changed: 139291 ins; 246279 del; 56584 mod Patch: https://git.openjdk.java.net/jfx/pull/752.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/752/head:pull/752 PR: https://git.openjdk.java.net/jfx/pull/752 From alexander.scherbatiy at bell-sw.com Mon Mar 14 09:05:06 2022 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Mon, 14 Mar 2022 12:05:06 +0300 Subject: Scrolling a rotated ScrollPane Message-ID: <46f5a53f-ddd0-5df3-7681-af34d0f9fb18@bell-sw.com> Hello, There is a JavaFX Application [1] which has a rotated border which contains a ScrollPane. When the scroll pane is scrolled vertically by a mouse or by a touch pad the scrollpane itself is scrolled horizontally. What I see from the code the ScrollEvent constructor recomputes x and y coordinates (actually the pickResult) in the GestureEvent superclass [2] but leaves deltaX/Y? as is [3]. Should deltaX/Y (and totalDeltaX/Y and may be textDeltaX/Y ) values be recomputed in the similar way as x/y [4]? It looks like it requires to compute and pass PickResult? for deltaX/Y to ScrollEvent as well. [1] http://cr.openjdk.java.net/~alexsch/samples/javafx/events/RotatedScrollPaneExample.java [2] https://github.com/openjdk/jfx/blob/c6069d6845df4b90cca226e2b3dff49e3b48d8ac/modules/javafx.graphics/src/main/java/javafx/scene/input/GestureEvent.java#L120 [3] https://github.com/openjdk/jfx/blob/c6069d6845df4b90cca226e2b3dff49e3b48d8ac/modules/javafx.graphics/src/main/java/javafx/scene/input/ScrollEvent.java#L155 [4] https://github.com/openjdk/jfx/blob/c6069d6845df4b90cca226e2b3dff49e3b48d8ac/modules/javafx.graphics/src/main/java/javafx/scene/Scene.java#L2693 Thanks, Alexander. From kcr at openjdk.java.net Mon Mar 14 13:34:57 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Mar 2022 13:34:57 GMT Subject: [jfx18] RFR: 8282766: Create release notes for JavaFX 18 [v2] In-Reply-To: References: Message-ID: On Sun, 13 Mar 2022 10:07:26 GMT, Abhinay Agarwal wrote: >> Add release notes for JavaFX 18 to the repository > > Abhinay Agarwal has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - s/Enhancement/Enhancements > - Create release notes for JavaFX 18 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/752 From duke at openjdk.java.net Mon Mar 14 14:07:55 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Mon, 14 Mar 2022 14:07:55 GMT Subject: Integrated: 8282093: LineChart path incorrect when outside lower bound In-Reply-To: References: Message-ID: <39bD4TzSFXjW4rtWXNQtX3braGAwLEghwfZWKT2glRU=.38daf9bb-7e1d-4c2d-b438-486ced2fff32@github.com> On Mon, 28 Feb 2022 18:25:09 GMT, Abhinay Agarwal wrote: > This regression was caused in PR #667 in which I didn't take into account the lower bounds. I have added more tests and one manual test along with the fix. The manual test can be used to identify any future issues with paths outside lower and upper bounds easily. This pull request has now been integrated. Changeset: d28f3d78 Author: Abhinay Agarwal Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/d28f3d781a125eae7e89956ff8e37fc7b94646c2 Stats: 523 lines in 4 files changed: 500 ins; 0 del; 23 mod 8282093: LineChart path incorrect when outside lower bound Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/744 From jpereda at openjdk.java.net Mon Mar 14 14:55:10 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 14 Mar 2022 14:55:10 GMT Subject: RFR: 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem Message-ID: <78Wj3WTkQSJYaYO9nJVBnwtmYl1Dd0_XT8DUAwo0Hfs=.342a937b-4915-4d0d-aa43-5a818547cd5f@github.com> This PR fixes JDK-[8193442](https://bugs.openjdk.java.net/browse/JDK-8193442), but also [JDK-8187596](https://bugs.openjdk.java.net/browse/JDK-8187596), and verifies that the tests mentioned in [JDK-8088157](https://bugs.openjdk.java.net/browse/JDK-8088157) are working (with a minor fix). When removing an item that is below the selected item from TreeTableView or TreeView controls the selection and/or focus was wrongly changed in some occasions, because a shift in the selection was applied. This PR adds a method to ControlUtils to get the index of the sibling that is selected/focused or contains the descendant item with the current selection/focus. This index is required to compare properly if the selected/focus item is above or below the item that was removed, by comparing the indices of siblings. Tests have been added to TreeViewTest and TreeTableViewTest based on the existing tests on JDK-8193442 and JDK-8187596. The four tests fail without this PR, pass with it. In the process, I noticed that the ignored tests referred from JDK-8088157 were already passing, after removing some obsolete asserts, even without this PR. ------------- Commit messages: - Don't shift selection/focus if item is below removed element Changes: https://git.openjdk.java.net/jfx/pull/753/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=753&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8193442 Stats: 193 lines in 5 files changed: 175 ins; 12 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/753.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/753/head:pull/753 PR: https://git.openjdk.java.net/jfx/pull/753 From duke at openjdk.java.net Mon Mar 14 17:01:56 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Mon, 14 Mar 2022 17:01:56 GMT Subject: [jfx18] RFR: 8282766: Create release notes for JavaFX 18 [v2] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 13:31:34 GMT, Kevin Rushforth wrote: >> Abhinay Agarwal has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: >> >> - s/Enhancement/Enhancements >> - Create release notes for JavaFX 18 > > Marked as reviewed by kcr (Lead). @kevinrushforth Before I integrate the PR, can you have a look at [my comment on the issue](https://bugs.openjdk.java.net/browse/JDK-8282766?focusedCommentId=14482267&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14482267)? ------------- PR: https://git.openjdk.java.net/jfx/pull/752 From kcr at openjdk.java.net Mon Mar 14 17:11:50 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Mar 2022 17:11:50 GMT Subject: [jfx18] RFR: 8282766: Create release notes for JavaFX 18 [v2] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 13:31:34 GMT, Kevin Rushforth wrote: >> Abhinay Agarwal has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: >> >> - s/Enhancement/Enhancements >> - Create release notes for JavaFX 18 > > Marked as reviewed by kcr (Lead). > @kevinrushforth Before I integrate the PR, can you have a look at [my comment on the issue](https://bugs.openjdk.java.net/browse/JDK-8282766?focusedCommentId=14482267&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14482267)? Oh, I had missed your question.. Yes, those three issues were intentionally added to the JBS filter. Even though they are `noreg-build` issues, they touch on behaviors that are visible to developers. ------------- PR: https://git.openjdk.java.net/jfx/pull/752 From tsayao at openjdk.java.net Mon Mar 14 17:58:55 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 14 Mar 2022 17:58:55 GMT Subject: [jfx18] RFR: 8282766: Create release notes for JavaFX 18 [v2] In-Reply-To: References: Message-ID: On Sun, 13 Mar 2022 10:07:26 GMT, Abhinay Agarwal wrote: >> Add release notes for JavaFX 18 to the repository > > Abhinay Agarwal has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - s/Enhancement/Enhancements > - Create release notes for JavaFX 18 doc-files/release-notes-18.md line 105: > 103: [JDK-8274929](https://bugs.openjdk.java.net/browse/JDK-8274929)|Crash while reading specific clipboard content|window-toolkit > 104: [JDK-8275723](https://bugs.openjdk.java.net/browse/JDK-8275723)|Crash on macOS 12 in GlassRunnable::dealloc|window-toolkit > 105: [REDO] Wrong stage gets focused after modal stage creation https://bugs.openjdk.java.net/browse/JDK-8271054 ? ------------- PR: https://git.openjdk.java.net/jfx/pull/752 From kcr at openjdk.java.net Mon Mar 14 18:22:00 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Mar 2022 18:22:00 GMT Subject: [jfx18] RFR: 8282766: Create release notes for JavaFX 18 [v2] In-Reply-To: References: Message-ID: <5l1gtk7EqcXtnRlIFIBy2gxzNt8S1kfvDcCc_rOeRw4=.cad272a1-3c35-482f-9e71-0d7af0a874c4@github.com> On Mon, 14 Mar 2022 17:55:45 GMT, Thiago Milczarek Sayao wrote: >> Abhinay Agarwal has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - s/Enhancement/Enhancements >> - Create release notes for JavaFX 18 > > doc-files/release-notes-18.md line 105: > >> 103: [JDK-8274929](https://bugs.openjdk.java.net/browse/JDK-8274929)|Crash while reading specific clipboard content|window-toolkit >> 104: [JDK-8275723](https://bugs.openjdk.java.net/browse/JDK-8275723)|Crash on macOS 12 in GlassRunnable::dealloc|window-toolkit >> 105: > > [REDO] Wrong stage gets focused after modal stage creation https://bugs.openjdk.java.net/browse/JDK-8271054 ? No, that fix is in 19. These release notes are for 18. ------------- PR: https://git.openjdk.java.net/jfx/pull/752 From tsayao at openjdk.java.net Mon Mar 14 18:31:03 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 14 Mar 2022 18:31:03 GMT Subject: [jfx18] RFR: 8282766: Create release notes for JavaFX 18 [v2] In-Reply-To: <5l1gtk7EqcXtnRlIFIBy2gxzNt8S1kfvDcCc_rOeRw4=.cad272a1-3c35-482f-9e71-0d7af0a874c4@github.com> References: <5l1gtk7EqcXtnRlIFIBy2gxzNt8S1kfvDcCc_rOeRw4=.cad272a1-3c35-482f-9e71-0d7af0a874c4@github.com> Message-ID: On Mon, 14 Mar 2022 18:18:38 GMT, Kevin Rushforth wrote: >> doc-files/release-notes-18.md line 105: >> >>> 103: [JDK-8274929](https://bugs.openjdk.java.net/browse/JDK-8274929)|Crash while reading specific clipboard content|window-toolkit >>> 104: [JDK-8275723](https://bugs.openjdk.java.net/browse/JDK-8275723)|Crash on macOS 12 in GlassRunnable::dealloc|window-toolkit >>> 105: >> >> [REDO] Wrong stage gets focused after modal stage creation https://bugs.openjdk.java.net/browse/JDK-8271054 ? > > No, that fix is in 19. These release notes are for 18. Sorry, my mistake. ------------- PR: https://git.openjdk.java.net/jfx/pull/752 From jvos at openjdk.java.net Mon Mar 14 18:37:52 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 14 Mar 2022 18:37:52 GMT Subject: [jfx18] RFR: 8282766: Create release notes for JavaFX 18 [v2] In-Reply-To: References: Message-ID: On Sun, 13 Mar 2022 10:07:26 GMT, Abhinay Agarwal wrote: >> Add release notes for JavaFX 18 to the repository > > Abhinay Agarwal has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - s/Enhancement/Enhancements > - Create release notes for JavaFX 18 Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/752 From duke at openjdk.java.net Mon Mar 14 19:49:50 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Mon, 14 Mar 2022 19:49:50 GMT Subject: [jfx18] RFR: 8282766: Create release notes for JavaFX 18 [v2] In-Reply-To: References: Message-ID: <0AbtqHGqla0SHCRUzcOM_fGTHBMxP8K308tsniYhCSQ=.cd61b19e-13b6-4308-9bb2-5702d1622a08@github.com> On Mon, 14 Mar 2022 17:08:32 GMT, Kevin Rushforth wrote: >> Marked as reviewed by kcr (Lead). > >> @kevinrushforth Before I integrate the PR, can you have a look at [my comment on the issue](https://bugs.openjdk.java.net/browse/JDK-8282766?focusedCommentId=14482267&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14482267)? > > Oh, I had missed your question.. Yes, those three issues were intentionally added to the JBS filter. Even though they are `noreg-build` issues, they touch on behaviors that are visible to developers. @kevinrushforth What about the "noreg-doc" and "test_sprint" issues in the filter? ------------- PR: https://git.openjdk.java.net/jfx/pull/752 From kcr at openjdk.java.net Mon Mar 14 20:45:49 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Mar 2022 20:45:49 GMT Subject: [jfx18] RFR: 8282766: Create release notes for JavaFX 18 [v2] In-Reply-To: <0AbtqHGqla0SHCRUzcOM_fGTHBMxP8K308tsniYhCSQ=.cd61b19e-13b6-4308-9bb2-5702d1622a08@github.com> References: <0AbtqHGqla0SHCRUzcOM_fGTHBMxP8K308tsniYhCSQ=.cd61b19e-13b6-4308-9bb2-5702d1622a08@github.com> Message-ID: On Mon, 14 Mar 2022 19:46:18 GMT, Abhinay Agarwal wrote: >>> @kevinrushforth Before I integrate the PR, can you have a look at [my comment on the issue](https://bugs.openjdk.java.net/browse/JDK-8282766?focusedCommentId=14482267&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14482267)? >> >> Oh, I had missed your question.. Yes, those three issues were intentionally added to the JBS filter. Even though they are `noreg-build` issues, they touch on behaviors that are visible to developers. > > @kevinrushforth What about the "noreg-doc" and "test_sprint" issues in the filter? > > For example: > > * https://bugs.openjdk.java.net/browse/JDK-8271085 > * https://bugs.openjdk.java.net/browse/JDK-8271090 @abhinayagarwal I would expect the `noreg-doc` fixes to be included if they touch user-visible documentation. I see the two you mentioned in the filter I provided, although I don't see them in this PR. As for `test_sprint`, the filter doesn't consider that label. If they are test bugs then they should have `testbug` and/or `noreg-self` and be excluded as a result. ------------- PR: https://git.openjdk.java.net/jfx/pull/752 From kcr at openjdk.java.net Mon Mar 14 20:45:49 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Mar 2022 20:45:49 GMT Subject: [jfx18] RFR: 8282766: Create release notes for JavaFX 18 [v2] In-Reply-To: References: Message-ID: <2pyJ3B4CP-pVUrod_N2dWsOHutNIKpIBpk0tLUc6-_w=.d44025cb-6ea5-4579-be2e-7efcc7de4227@github.com> On Sun, 13 Mar 2022 10:07:26 GMT, Abhinay Agarwal wrote: >> Add release notes for JavaFX 18 to the repository > > Abhinay Agarwal has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - s/Enhancement/Enhancements > - Create release notes for JavaFX 18 However, the two you mentioned are sort of borderline as to whether you want to include them or not. I would be just as happy excluding them. ------------- PR: https://git.openjdk.java.net/jfx/pull/752 From duke at openjdk.java.net Tue Mar 15 03:47:51 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Tue, 15 Mar 2022 03:47:51 GMT Subject: [jfx18] RFR: 8282766: Create release notes for JavaFX 18 [v2] In-Reply-To: References: Message-ID: On Sun, 13 Mar 2022 10:07:26 GMT, Abhinay Agarwal wrote: >> Add release notes for JavaFX 18 to the repository > > Abhinay Agarwal has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - s/Enhancement/Enhancements > - Create release notes for JavaFX 18 There are 7 such issues. I created a [filter](https://bugs.openjdk.java.net/browse/JDK-8279345?filter=42366) to make it easy for you to have a look at them. I use a script to create the release notes which skips `noreg-doc` labelled issues. For future reference, it would be good to know if we want to keep these in the release notes. ------------- PR: https://git.openjdk.java.net/jfx/pull/752 From duke at openjdk.java.net Tue Mar 15 07:45:45 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Tue, 15 Mar 2022 07:45:45 GMT Subject: [jfx18] Integrated: 8282766: Create release notes for JavaFX 18 In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 10:18:07 GMT, Abhinay Agarwal wrote: > Add release notes for JavaFX 18 to the repository This pull request has now been integrated. Changeset: df43d2bd Author: Abhinay Agarwal Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/df43d2bdff884f6ea2f2c1f908504260db04e423 Stats: 110 lines in 1 file changed: 110 ins; 0 del; 0 mod 8282766: Create release notes for JavaFX 18 Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/752 From duke at openjdk.java.net Tue Mar 15 18:15:55 2022 From: duke at openjdk.java.net (Mike Hearn) Date: Tue, 15 Mar 2022 18:15:55 GMT Subject: RFR: 8236689: macOS 10.15 Catalina: LCD text renders badly In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 23:59:40 GMT, Phil Race wrote: > On an external (non-retina) monitor JavaFX LCD text on macOS is painful on the eyes. > Retina diminishes it rather than cures it. > > The problem is a mix of a couple of things > 1) CoreText no longer generates LCD glyphs (except perhaps if you change some system settings at your own risk) > 2) Prism's LCD shader assumes it got LCD glyphs and makes sub-pixel positioning adjustments that turn greyscale > glyphs into multi-coloured glyphs that weren't meant to be ... > > The fix here is to just disable LCD by default on macOS as is already done (eg) on iOS > This ripples through to make everything use grey scale even if you asked for the LCD (which you can't have) > It also means if you REALLY want it (and perhaps are tweaking those magical settings) you can have it back > by just specifying -Dprism.lcdtext=on > > Also it means the pieces of support for this on macos are still there if Apple ever bring it back (unlikely). > Not that much code would be removed anyway .. a fair amount of it is needed for Windows and Linux. I can't comment on the JBS bug, but I'm not sure this is actually fixed. I upgraded to JavaFX 18 and the bug is still there. Setting `-Dprism.lcdtext=off` fixes it. I'm not sure why, because the change to do this by default seems simple enough. ------------- PR: https://git.openjdk.java.net/jfx/pull/642 From kcr at openjdk.java.net Tue Mar 15 18:56:03 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Mar 2022 18:56:03 GMT Subject: RFR: 8283183: Skip failing PredefinedMeshManagerTest tests Message-ID: We continue to get intermittent test failures in `PredefinedMeshManagerTest` due to an OOM error. See the GitHub Actions run for [PR 753](https://github.com/openjdk/jfx/pull/753/checks?check_run_id=5559141397) for a recent failure. This test failure is tracked by [JDK-8282449](https://bugs.openjdk.java.net/browse/JDK-8282449). Until that test bug is fixed, I propose to skip the two test methods, `cylinderCacheTest` and `sphereCacheTest`, that allocate large meshes and are prone to OOM errors. ------------- Commit messages: - 8283183: Skip failing PredefinedMeshManagerTest tests Changes: https://git.openjdk.java.net/jfx/pull/754/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=754&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283183 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/754.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/754/head:pull/754 PR: https://git.openjdk.java.net/jfx/pull/754 From kcr at openjdk.java.net Tue Mar 15 19:00:50 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Mar 2022 19:00:50 GMT Subject: RFR: 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem In-Reply-To: <78Wj3WTkQSJYaYO9nJVBnwtmYl1Dd0_XT8DUAwo0Hfs=.342a937b-4915-4d0d-aa43-5a818547cd5f@github.com> References: <78Wj3WTkQSJYaYO9nJVBnwtmYl1Dd0_XT8DUAwo0Hfs=.342a937b-4915-4d0d-aa43-5a818547cd5f@github.com> Message-ID: On Mon, 14 Mar 2022 14:49:41 GMT, Jose Pereda wrote: > This PR fixes JDK-[8193442](https://bugs.openjdk.java.net/browse/JDK-8193442), but also [JDK-8187596](https://bugs.openjdk.java.net/browse/JDK-8187596), and verifies that the tests mentioned in [JDK-8088157](https://bugs.openjdk.java.net/browse/JDK-8088157) are working (with a minor fix). > > When removing an item that is below the selected item from TreeTableView or TreeView controls the selection and/or focus was wrongly changed in some occasions, because a shift in the selection was applied. > > This PR adds a method to ControlUtils to get the index of the sibling that is selected/focused or contains the descendant item with the current selection/focus. > > This index is required to compare properly if the selected/focus item is above or below the item that was removed, by comparing the indices of siblings. > > Tests have been added to TreeViewTest and TreeTableViewTest based on the existing tests on JDK-8193442 and JDK-8187596. The four tests fail without this PR, pass with it. > > In the process, I noticed that the ignored tests referred from JDK-8088157 were already passing, after removing some obsolete asserts, even without this PR. The GHA test failure on macOS was due to [JDK-8282449](https://bugs.openjdk.java.net/browse/JDK-8282449) and not anything in this PR. I filed a new bug to skip the failing tests until that bug can be fixed. See PR #754. ------------- PR: https://git.openjdk.java.net/jfx/pull/753 From jvos at openjdk.java.net Tue Mar 15 19:09:47 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 15 Mar 2022 19:09:47 GMT Subject: RFR: 8283183: Skip failing PredefinedMeshManagerTest tests In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 18:50:15 GMT, Kevin Rushforth wrote: > We continue to get intermittent test failures in `PredefinedMeshManagerTest` due to an OOM error. See the GitHub Actions run for [PR 753](https://github.com/openjdk/jfx/pull/753/checks?check_run_id=5559141397) for a recent failure. This test failure is tracked by [JDK-8282449](https://bugs.openjdk.java.net/browse/JDK-8282449). Until that test bug is fixed, I propose to skip the two test methods, `cylinderCacheTest` and `sphereCacheTest`, that allocate large meshes and are prone to OOM errors. I am ok with ignoring these tests. Since these tests will typically throw an OOM exception on shared CI systems, it might be good to make the ignore conditionally -- but I'm ok with ignoring them in general as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/754 From kcr at openjdk.java.net Tue Mar 15 22:50:49 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Mar 2022 22:50:49 GMT Subject: RFR: Merge jfx18 Message-ID: Final merge of `jfx18` into `master`. ------------- Commit messages: - Merge jfx18 - 8282766: Create release notes for JavaFX 18 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jfx/pull/755/files Stats: 110 lines in 1 file changed: 110 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/755.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/755/head:pull/755 PR: https://git.openjdk.java.net/jfx/pull/755 From kcr at openjdk.java.net Tue Mar 15 23:22:34 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Mar 2022 23:22:34 GMT Subject: RFR: Merge jfx18 [v2] In-Reply-To: References: Message-ID: > Final merge of `jfx18` into `master`. Kevin Rushforth 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 32 additional commits since the last revision: - Merge jfx18 - 8282093: LineChart path incorrect when outside lower bound Reviewed-by: aghaisas - 8271054: [REDO] Wrong stage gets focused after modal stage creation Reviewed-by: kcr, arapte - 8280840: Update libFFI to 3.4.2 Reviewed-by: kcr, sykora - 8282100: Missed top/left bouncing for ScrollPane on Raspberry Pi with Touchscreen Reviewed-by: aghaisas - 8280020: Underline and line-through not straight in WebView Reviewed-by: kcr, arapte - 8269115: WebView paste event contains old data Reviewed-by: arapte, kcr - 8255940: localStorage is null after window.close() Reviewed-by: kcr, arapte - 8278759: PointerEvent: buttons property set to 0 when mouse down Reviewed-by: kcr, arapte - 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start Reviewed-by: arapte, sykora - ... and 22 more: https://git.openjdk.java.net/jfx/compare/abb2b138...fe8dcbd1 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/755/files - new: https://git.openjdk.java.net/jfx/pull/755/files/fe8dcbd1..fe8dcbd1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=755&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=755&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/755.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/755/head:pull/755 PR: https://git.openjdk.java.net/jfx/pull/755 From kcr at openjdk.java.net Tue Mar 15 23:22:35 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Mar 2022 23:22:35 GMT Subject: Integrated: Merge jfx18 In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 22:41:14 GMT, Kevin Rushforth wrote: > Final merge of `jfx18` into `master`. This pull request has now been integrated. Changeset: 4afc8afc Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/4afc8afc42cb0afedd1b8d3d7b6ef0030603ba9f Stats: 110 lines in 1 file changed: 110 ins; 0 del; 0 mod Merge ------------- PR: https://git.openjdk.java.net/jfx/pull/755 From kevin.rushforth at oracle.com Tue Mar 15 23:51:09 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 Mar 2022 16:51:09 -0700 Subject: Odd Skara webrev email [was: Re: RFR: Merge jfx18 [v2]] Message-ID: <81b61c89-78c4-b4fa-834d-977149297629@oracle.com> In case anyone noticed, the following email was sent by Skara with a webrev that it generated, and a long and incorrect list of commits. As you can see from the PR itself, there was really only a single commit as part of this merge. I filed https://bugs.openjdk.java.net/browse/SKARA-1376 to track what looks like a Skara PR bot bug. -- Kevin On 3/15/2022 4:22 PM, Kevin Rushforth wrote: >> Final merge of `jfx18` into `master`. > Kevin Rushforth 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 32 additional commits since the last revision: > > - Merge jfx18 > - 8282093: LineChart path incorrect when outside lower bound > > Reviewed-by: aghaisas > - 8271054: [REDO] Wrong stage gets focused after modal stage creation > > Reviewed-by: kcr, arapte > - 8280840: Update libFFI to 3.4.2 > > Reviewed-by: kcr, sykora > - 8282100: Missed top/left bouncing for ScrollPane on Raspberry Pi with Touchscreen > > Reviewed-by: aghaisas > - 8280020: Underline and line-through not straight in WebView > > Reviewed-by: kcr, arapte > - 8269115: WebView paste event contains old data > > Reviewed-by: arapte, kcr > - 8255940: localStorage is null after window.close() > > Reviewed-by: kcr, arapte > - 8278759: PointerEvent: buttons property set to 0 when mouse down > > Reviewed-by: kcr, arapte > - 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start > > Reviewed-by: arapte, sykora > - ... and 22 more: https://git.openjdk.java.net/jfx/compare/abb2b138...fe8dcbd1 > > ------------- > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/755/files > - new: https://git.openjdk.java.net/jfx/pull/755/files/fe8dcbd1..fe8dcbd1 > > Webrevs: > - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=755&range=01 > - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=755&range=00-01 > > Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod > Patch: https://git.openjdk.java.net/jfx/pull/755.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/755/head:pull/755 > > PR: https://git.openjdk.java.net/jfx/pull/755 From A.Anafinow at tms-bonn.de Wed Mar 16 07:53:06 2022 From: A.Anafinow at tms-bonn.de (Anafinow, Andrej) Date: Wed, 16 Mar 2022 07:53:06 +0000 Subject: Fix for gestures and multitouch on linux Message-ID: <7a9ebf0803b649d889b4aa820402bc3d@tms-bonn.de> Hello, we have a problem with multitouch and gestures on Linux and JavaFx17. This is also described here: https://bugs.openjdk.java.net/browse/JDK-8090954 The sample project "GestureEventsExample" at https://docs.oracle.com/javafx/2/events/gestures.htm does not work either. We looked at the code and fixed the problem. See our commit at https://github.com/tms-bonn/jfx. With these changes, the above example works. The following touch and multi-touch functions were tested: Rotate, Zoom, Scroll and LongPress. Our current problem was actually about controlling the Openlayers map in a WebView with gestures on a touch monitor. All the above functions work without any problems. We would like to ask the community to take a look at our changes and maybe test them Regards, Andrej From peterz at openjdk.java.net Wed Mar 16 08:01:14 2022 From: peterz at openjdk.java.net (Peter Zhelezniakov) Date: Wed, 16 Mar 2022 08:01:14 GMT Subject: RFR: 8283246: WebKit fails to build on Linux Message-ID: The file `wtf/linux/MemoryPressureLinux.cpp` was renamed `wtf/unix/MemoryPressureUnix.cpp` in https://trac.webkit.org/changeset/261428 . In the openjfx workspace, both files are present. I'm removing the old file. ------------- Commit messages: - 8283246: WebKit fails to build on Linux Changes: https://git.openjdk.java.net/jfx/pull/756/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=756&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283246 Stats: 142 lines in 2 files changed: 1 ins; 141 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/756.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/756/head:pull/756 PR: https://git.openjdk.java.net/jfx/pull/756 From rlichten at openjdk.java.net Wed Mar 16 08:27:15 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 16 Mar 2022 08:27:15 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling Message-ID: This fix respects a row factory, if present. It will put the cell that is used to measure the column width as child below the row. In that way the row's style will be used. ------------- Commit messages: - 8251480: TableColumnHeader: calc of cell width must respect row styling Changes: https://git.openjdk.java.net/jfx/pull/757/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=757&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251480 Stats: 38 lines in 2 files changed: 34 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/757.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/757/head:pull/757 PR: https://git.openjdk.java.net/jfx/pull/757 From mhanl at openjdk.java.net Wed Mar 16 11:48:49 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 16 Mar 2022 11:48:49 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 08:20:59 GMT, Robert Lichtenberger wrote: > This fix respects a row factory, if present. > It will put the cell that is used to measure the column width as child below the row. > In that way the row's style will be used. Might make sense to also adjust the TreeTableView sizing implementation? ------------- PR: https://git.openjdk.java.net/jfx/pull/757 From kcr at openjdk.java.net Wed Mar 16 12:57:57 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Mar 2022 12:57:57 GMT Subject: RFR: 8283246: WebKit fails to build on Linux In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 07:54:57 GMT, Peter Zhelezniakov wrote: > The file `wtf/linux/MemoryPressureLinux.cpp` was renamed `wtf/unix/MemoryPressureUnix.cpp` in https://trac.webkit.org/changeset/261428 . In the openjfx workspace, both files are present. I'm removing the old file. Thanks for the PR to fix this? As I noted in the JBS issue, [JDK-8283246](https://bugs.openjdk.java.net/browse/JDK-8283246) is a duplicate of [JDK-8270867](https://bugs.openjdk.java.net/browse/JDK-8270867) . Can you modify the title of this PR to the following? 8270867: Debug build of WebKit 613.1 fails on Linux @jaybhaskar Can you also review this? I'll run both a debug and normal CI build to test this. ------------- PR: https://git.openjdk.java.net/jfx/pull/756 From rlichten at openjdk.java.net Wed Mar 16 13:04:56 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 16 Mar 2022 13:04:56 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 11:46:07 GMT, Marius Hanl wrote: > Might make sense to also adjust the TreeTableView sizing implementation? Yes I think that may be a good idea. True to the idea of specific, narrow commits I've not integrated this into this PR but would be willing to open a new issue / produce a separate PR for TreeTableView. ------------- PR: https://git.openjdk.java.net/jfx/pull/757 From jbhaskar at openjdk.java.net Wed Mar 16 13:58:49 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Wed, 16 Mar 2022 13:58:49 GMT Subject: RFR: 8270867: Debug build of WebKit 613.1 fails on Linux In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 07:54:57 GMT, Peter Zhelezniakov wrote: > The file `wtf/linux/MemoryPressureLinux.cpp` was renamed `wtf/unix/MemoryPressureUnix.cpp` in https://trac.webkit.org/changeset/261428 . In the openjfx workspace, both files are present. I'm removing the old file. The patch https://trac.webkit.org/changeset/261428 committed in May 8, 2020. it is older than a recent patch https://bugs.webkit.org/attachment.cgi?id=443979&action=prettypatch But i remember , the error for this file [MemoryPressureHandlerLinux.cpp] was at if (ReliefLogger::loggingEnabled() && isUnderMemoryPressure()) LOG(MemoryPressure, "System is no longer under memory pressure."); The variable isUnderMemoryPressure was giving error. saying right variable m_underMemoryPressure instead of isUnderMemoryPressure Error: [jfx/modules/javafx.web/src/main/native/Source/WTF/wtf/linux/MemoryPressureHandlerLinux.cpp:39:28: error: 'LogMemoryPressure' was not declared in this scope; did you mean 'isUnderMemoryPressure'? ] There was anothe issue with the build, as below [JavaScriptCore/Scripts/resolve-asm-file-conflicts.rb](http://rejfx.us.oracle.com:8080/job/jfx-submit/label=lin-ol7-x64/ws/jfx/rt/modules/javafx.web/build/linux/Debug/JavaScriptCore/Scripts/resolve-asm-file-conflicts.rb)>:99:in `parse': undefined method `/' for This was removed by updating rub version. ------------- PR: https://git.openjdk.java.net/jfx/pull/756 From kcr at openjdk.java.net Wed Mar 16 15:00:59 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Mar 2022 15:00:59 GMT Subject: RFR: 8283183: Skip failing PredefinedMeshManagerTest tests In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 18:50:15 GMT, Kevin Rushforth wrote: > We continue to get intermittent test failures in `PredefinedMeshManagerTest` due to an OOM error. See the GitHub Actions run for [PR 753](https://github.com/openjdk/jfx/pull/753/checks?check_run_id=5559141397) for a recent failure. This test failure is tracked by [JDK-8282449](https://bugs.openjdk.java.net/browse/JDK-8282449). Until that test bug is fixed, I propose to skip the two test methods, `cylinderCacheTest` and `sphereCacheTest`, that allocate large meshes and are prone to OOM errors. I can't think of a good way to just skip the test on a CI system. Also, this could fail on a developer system that is either overloaded or under-provisioned (e.g., a VM with a minimal configuration). ------------- PR: https://git.openjdk.java.net/jfx/pull/754 From kcr at openjdk.java.net Wed Mar 16 15:13:50 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Mar 2022 15:13:50 GMT Subject: RFR: 8270867: Debug build of WebKit 613.1 fails on Linux In-Reply-To: References: Message-ID: <2hMeatlRxH7D0GmFA_oP9GEN9Adxgax5ZiCAWP8UNxg=.457fcca1-795b-4723-a630-906b166ed008@github.com> On Wed, 16 Mar 2022 07:54:57 GMT, Peter Zhelezniakov wrote: > The file `wtf/linux/MemoryPressureLinux.cpp` was renamed `wtf/unix/MemoryPressureUnix.cpp` in https://trac.webkit.org/changeset/261428 . In the openjfx workspace, both files are present. I'm removing the old file. There are two issues (which suggests that I should have filed a new bug when we updated to WebKit 613.1). The new one that this PR fixes, and the one we originally ran into in WebKit 612.1, possibly relating to the version of Ruby. I can confirm that this PR by Peter solves the problem caused by the leftover `MemoryPressureHandlerLinux`. On our CI build system I still see the problem we initially ran into back in 612.1 in `resolve-asm-file-conflicts.rb`: Scanning dependencies of target LowLevelInterpreterLib [ 26%] Building CXX object Source/JavaScriptCore/CMakeFiles/LowLevelInterpreterLib.dir/llint/LowLevelInterpreter.cpp.o modules/javafx.web/build/linux/Debug/JavaScriptCore/Scripts/resolve-asm-file-conflicts.rb:99:in `parse': undefined method `/' for # (NoMethodError) from modules/javafx.web/build/linux/Debug/JavaScriptCore/Scripts/resolve-asm-file-conflicts.rb:149:in `test' from modules/javafx.web/build/linux/Debug/JavaScriptCore/Scripts/resolve-asm-file-conflicts.rb:237:in `block in selftest' from modules/javafx.web/build/linux/Debug/JavaScriptCore/Scripts/resolve-asm-file-conflicts.rb:236:in `each' from modules/javafx.web/build/linux/Debug/JavaScriptCore/Scripts/resolve-asm-file-conflicts.rb:236:in `selftest' from modules/javafx.web/build/linux/Debug/JavaScriptCore/Scripts/resolve-asm-file-conflicts.rb:430:in `
' Error running cmd: pid 12750 exit 1 gmake[2]: *** [Source/JavaScriptCore/CMakeFiles/LowLevelInterpreterLib.dir/llint/LowLevelInterpreter.cpp.o] Error 1 gmake[1]: *** [Source/JavaScriptCore/CMakeFiles/LowLevelInterpreterLib.dir/all] Error 2 gmake: *** [all] Error 2 We might want to take this fix to remove the leftover file, and then file a new one for the original problem, since that one hits older systems with older version of Ruby. @jaybhaskar what do you think? ------------- PR: https://git.openjdk.java.net/jfx/pull/756 From jbhaskar at openjdk.java.net Wed Mar 16 15:34:54 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Wed, 16 Mar 2022 15:34:54 GMT Subject: RFR: 8270867: Debug build of WebKit 613.1 fails on Linux In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 07:54:57 GMT, Peter Zhelezniakov wrote: > The file `wtf/linux/MemoryPressureLinux.cpp` was renamed `wtf/unix/MemoryPressureUnix.cpp` in https://trac.webkit.org/changeset/261428 . In the openjfx workspace, both files are present. I'm removing the old file. Yes , The PR looks good. We can file new bug for ruby version related issue. ------------- PR: https://git.openjdk.java.net/jfx/pull/756 From kcr at openjdk.java.net Wed Mar 16 18:02:59 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Mar 2022 18:02:59 GMT Subject: RFR: 8270867: Debug build of WebKit 613.1 fails on Linux In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 07:54:57 GMT, Peter Zhelezniakov wrote: > The file `wtf/linux/MemoryPressureLinux.cpp` was renamed `wtf/unix/MemoryPressureUnix.cpp` in https://trac.webkit.org/changeset/261428 . In the openjfx workspace, both files are present. I'm removing the old file. I was able to do a local debug build using `-PCONF=DebugNative` on my Linux system using this patch. I also confirmed that a production build still works fine on our CI build system. Btw, I filed [JDK-8283273](https://bugs.openjdk.java.net/browse/JDK-8283273) as a follow-up bug to track the problem of nor being able to do a debug build on Linux with an older version of Ruby. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/756 From jvos at openjdk.java.net Wed Mar 16 19:03:53 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 16 Mar 2022 19:03:53 GMT Subject: RFR: 8283183: Skip failing PredefinedMeshManagerTest tests In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 18:50:15 GMT, Kevin Rushforth wrote: > We continue to get intermittent test failures in `PredefinedMeshManagerTest` due to an OOM error. See the GitHub Actions run for [PR 753](https://github.com/openjdk/jfx/pull/753/checks?check_run_id=5559141397) for a recent failure. This test failure is tracked by [JDK-8282449](https://bugs.openjdk.java.net/browse/JDK-8282449). Until that test bug is fixed, I propose to skip the two test methods, `cylinderCacheTest` and `sphereCacheTest`, that allocate large meshes and are prone to OOM errors. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/754 From jhendrikx at openjdk.java.net Wed Mar 16 20:32:52 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 16 Mar 2022 20:32:52 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v10] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Thu, 10 Mar 2022 17:49:38 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Process review comments (2) @mstr2 Could you perhaps review this PR as well? ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From kcr at openjdk.java.net Wed Mar 16 20:41:56 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Mar 2022 20:41:56 GMT Subject: Integrated: 8283183: Skip failing PredefinedMeshManagerTest tests In-Reply-To: References: Message-ID: <4Qsvv6TQJtNuKratyQWUuFV9BWrf1-3MTIoRoc1i7N0=.57487072-3d19-4341-ad97-2ace91567d83@github.com> On Tue, 15 Mar 2022 18:50:15 GMT, Kevin Rushforth wrote: > We continue to get intermittent test failures in `PredefinedMeshManagerTest` due to an OOM error. See the GitHub Actions run for [PR 753](https://github.com/openjdk/jfx/pull/753/checks?check_run_id=5559141397) for a recent failure. This test failure is tracked by [JDK-8282449](https://bugs.openjdk.java.net/browse/JDK-8282449). Until that test bug is fixed, I propose to skip the two test methods, `cylinderCacheTest` and `sphereCacheTest`, that allocate large meshes and are prone to OOM errors. This pull request has now been integrated. Changeset: ff75917c Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/ff75917c1be200f8eeba49304eadc67842068df3 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8283183: Skip failing PredefinedMeshManagerTest tests Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/754 From jbhaskar at openjdk.java.net Thu Mar 17 02:30:43 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Thu, 17 Mar 2022 02:30:43 GMT Subject: RFR: 8270867: Debug build of WebKit 613.1 fails on Linux In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 07:54:57 GMT, Peter Zhelezniakov wrote: > The file `wtf/linux/MemoryPressureLinux.cpp` was renamed `wtf/unix/MemoryPressureUnix.cpp` in https://trac.webkit.org/changeset/261428 . In the openjfx workspace, both files are present. I'm removing the old file. Since there are two equivalent files for same purpose , it looks good to remove older one. ------------- Marked as reviewed by jbhaskar (Author). PR: https://git.openjdk.java.net/jfx/pull/756 From peterz at openjdk.java.net Thu Mar 17 07:44:39 2022 From: peterz at openjdk.java.net (Peter Zhelezniakov) Date: Thu, 17 Mar 2022 07:44:39 GMT Subject: Integrated: 8270867: Debug build of WebKit 613.1 fails on Linux In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 07:54:57 GMT, Peter Zhelezniakov wrote: > The file `wtf/linux/MemoryPressureLinux.cpp` was renamed `wtf/unix/MemoryPressureUnix.cpp` in https://trac.webkit.org/changeset/261428 . In the openjfx workspace, both files are present. I'm removing the old file. This pull request has now been integrated. Changeset: eb7fa5dd Author: Peter Zhelezniakov URL: https://git.openjdk.java.net/jfx/commit/eb7fa5dd1c0911bca15576060691d884d29895a1 Stats: 142 lines in 2 files changed: 1 ins; 141 del; 0 mod 8270867: Debug build of WebKit 613.1 fails on Linux Reviewed-by: kcr, jbhaskar ------------- PR: https://git.openjdk.java.net/jfx/pull/756 From michaelstrau2 at gmail.com Thu Mar 17 20:01:07 2022 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 17 Mar 2022 21:01:07 +0100 Subject: Promote addEventHandler/removeEventHandler to EventTarget interface Message-ID: I'm working on an application that uses the JavaFX event system extensively, and I'm finding it quite hard to use common code for event handler registrations. The problem is that the `EventTarget` interface contains no addEventHandler/removeEventHandler methods, and as a consequence of that, code that uses `EventTarget` ends up requiring lots of brittle instanceof tests to call these methods on all the different implementations of `EventTarget`. There are three buckets of `EventTarget` implementations: 1) Implementations that declare the following methods: void addEventHandler(EventType, EventHandler); void removeEventHandler(EventType, EventHandler); void addEventFilter(EventType, EventHandler); void removeEventFilter(EventType, EventHandler); --> Node, Scene, Window, Transform, Task, Service 2) Implementations that declare the following methods: void addEventHandler(EventType, EventHandler); void removeEventHandler(EventType, EventHandler); --> MenuItem, TreeItem, TableColumnBase (Note that the EventHandler argument ist parameterized as EventHandler, not EventHandler as in the first set of methods.) 3) Implementations that don't declare any methods to add or remove event handlers: --> Dialog, Tab I think the situation can be improved by promoting the bucket 1 methods to the `EventTarget` interface, so they can be used consistently across all implementations of `EventTarget`. This works seamlessly for bucket 1 and bucket 3 implementations. With bucket 2, there's the problem that, inconsistently, the EventHandler argument is not a lower-bounded wildcard. Unfortunately, a method with an EventHandler parameter cannot implement an interface method that expects EventHandler. However, since the erasure of the method remains the same, changing the method signature would technically be a binary-compatible change. Do you think this is a useful improvement? From jvos at openjdk.java.net Thu Mar 17 21:08:14 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 17 Mar 2022 21:08:14 GMT Subject: [jfx11u] RFR: 8203463: [Accessibility, Narrator] NPE in TableView Message-ID: Reviewed-by: kcr ------------- Commit messages: - 8203463: [Accessibility, Narrator] NPE in TableView Changes: https://git.openjdk.java.net/jfx11u/pull/81/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=81&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8203463 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/81/head:pull/81 PR: https://git.openjdk.java.net/jfx11u/pull/81 From jvos at openjdk.java.net Thu Mar 17 21:09:16 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 17 Mar 2022 21:09:16 GMT Subject: [jfx11u] RFR: 8197991: Selecting many items in a TableView is very slow Message-ID: Co-authored-by: Naohiro Yoshimoto Reviewed-by: kcr, aghaisas ------------- Commit messages: - 8197991: Selecting many items in a TableView is very slow Changes: https://git.openjdk.java.net/jfx11u/pull/82/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=82&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8197991 Stats: 403 lines in 5 files changed: 357 ins; 40 del; 6 mod Patch: https://git.openjdk.java.net/jfx11u/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/82/head:pull/82 PR: https://git.openjdk.java.net/jfx11u/pull/82 From mhanl at openjdk.java.net Thu Mar 17 21:16:05 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 17 Mar 2022 21:16:05 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections Message-ID: This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. I also added tests which will succeed before and after to verify that nothing got broken by this change. Also I made a benchmark test. Results: Old: `ListBenchmark.init thrpt 25 722,842 ? 26,930 ops/s` New: `ListBenchmark.init thrpt 25 29262,274 ? 2088,712 ops/s`
Benchmark code import javafx.collections.FXCollections; import javafx.collections.ObservableList; import org.openjdk.jmh.annotations.Benchmark; import org.openjdk.jmh.annotations.Scope; import org.openjdk.jmh.annotations.Setup; import org.openjdk.jmh.annotations.State; import org.openjdk.jmh.annotations.TearDown; import java.util.ArrayList; import java.util.List; @State(Scope.Benchmark) public class ListBenchmark { List strings; @Setup public void setup() { strings = new ArrayList<>(); for(int i = 0; i< 100000;i++) { strings.add("abc: " + i); } } @TearDown public void tearDown() { strings = null; } @Benchmark public ObservableList init() { return FXCollections.observableArrayList(strings); } }
------------- Commit messages: - 8283346: Optimized observable array list creation Changes: https://git.openjdk.java.net/jfx/pull/758/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=758&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283346 Stats: 47 lines in 2 files changed: 41 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/758.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/758/head:pull/758 PR: https://git.openjdk.java.net/jfx/pull/758 From almatvee at openjdk.java.net Fri Mar 18 02:20:11 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 18 Mar 2022 02:20:11 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] In-Reply-To: References: Message-ID: > - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. > - Added support for elementary AAC streams without any container for audio only streams. > - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. > - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/726/files - new: https://git.openjdk.java.net/jfx/pull/726/files/08ce8569..49b6b2e4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=726&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=726&range=01-02 Stats: 84 lines in 5 files changed: 51 ins; 17 del; 16 mod Patch: https://git.openjdk.java.net/jfx/pull/726.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/726/head:pull/726 PR: https://git.openjdk.java.net/jfx/pull/726 From almatvee at openjdk.java.net Fri Mar 18 03:12:37 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 18 Mar 2022 03:12:37 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] In-Reply-To: References: Message-ID: <7vVgMsUpgiaOZ6vjDpRtPbzCH6NEY3dBsnikkEW-1p8=.8d44d3dc-2fa2-4b41-96e6-636af580b104@github.com> On Fri, 18 Mar 2022 02:20:11 GMT, Alexander Matveev wrote: >> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. >> - Added support for elementary AAC streams without any container for audio only streams. >> - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. >> - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] Fixed several issues found during additional testing: - sendHeader was true by default which caused sending first and second segment together for MP2TS and MP3/AAC elementary streams. This variable should be true only for fragmented MP4. - Removed G_SIGNAL_NO_RECURSE flag from javasource signals. From GLib doc "G_SIGNAL_NO_RECURSE - Signals being emitted for an object while currently being in emission for this very object will not be emitted recursively, but instead cause the first emission to be restarted." Basically it caused skipping data segments since in some cases loadNextSegment() was called twice. We do use signal mechanism from separate thread when reading duration. This issue is intermittent. All GStreamer provided elements do not use G_SIGNAL_NO_RECURSE flag, so not sure why javasource was using it. - Fixed duration calculation. We should not count duration of header, since header does not contain any data. - Added code which will adjust PTS during rendering to start with 0, otherwise (after duration fix) we will drop frames with PTS > duration. Note: In fMP4 HLS streams PTS starts with N and goes upto duration + N. Our rendering code expects start with 0 and stop at duration. - Minor code cleanup and removal of unnecessary "if (segment.start != 0)" check in hlsprogressbuffer. ------------- PR: https://git.openjdk.java.net/jfx/pull/726 From mstrauss at openjdk.java.net Fri Mar 18 07:05:43 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 18 Mar 2022 07:05:43 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v10] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Thu, 10 Mar 2022 17:49:38 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Process review comments (2) The code looks good. I've left some inline comments. modules/javafx.base/src/main/java/com/sun/javafx/binding/Subscription.java line 40: > 38: * > 39: * For example:

> 40: *

Subscription s = property.subscribe(System.out::println)
I believe our recommended pattern for example code is:
{@code
    ...
}
modules/javafx.base/src/main/java/com/sun/javafx/binding/Subscription.java line 67: > 65: */ > 66: default Subscription and(Subscription other) { > 67: Objects.requireNonNull(other); This exception could be documented with `@throws NullPointerException if {@code other} is null` modules/javafx.base/src/main/java/javafx/beans/value/FlatMappedBinding.java line 68: > 66: }; > 67: } > 68: } Several files are missing newlines after the last closing brace. Do we enforce this? Also, if there's a newline after the first line of a class declaration, shouldn't there also be a newline before the last closing brace? modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 146: > 144: * Creates an {@code ObservableValue} that holds the result of applying a > 145: * mapping on this {@code ObservableValue}'s value. The result is updated > 146: * when this {@code ObservableValue}'s value changes. If this value is I think a lot of the new documentation in this class sacrifices understandability for precision in trying to deal with the difference between "this ObservableValue" and "this ObservableValue's value". However, my feeling is that that's not helping users who are trying to understand the purpose of the new APIs. What do you think about a simplified version like this: `Creates a new {@ObservableValue} that applies a mapping function to this {@code ObservableValue}. The result is updated when this {@code ObservableValue} changes.` Sure, it's not literally mapping _this ObservableValue instance_, but would this language really confuse readers more that the precise language? Another option might be to combine both: `Creates a new {@ObservableValue} that applies a mapping function to this {@code ObservableValue}. More precisely, it creates a new {@code ObservableValue} that holds the result of applying a mapping function to the value of this {@code ObservableValue}.` modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 151: > 149: *

> 150: * For example, mapping a string to an upper case string: > 151: *


{@code
    ...
}
modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 153: > 151: *
> 152:      * var text = new SimpleStringProperty("abcd");
> 153:      * ObservableValue<String> upperCase = text.map(String::toUpperCase);

Escaping `<` and `>` is not necessary if the code block is wrapped in `{@code}`

modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 180:

> 178:      * 
> 179:      * var text = new SimpleStringProperty("abcd");
> 180:      * ObservableValue<String> upperCase = text.map(String::toUpperCase).orElse("");

Escaping `<` and `>` is not necessary within

{@code
    ...
}
modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 197: > 195: /** > 196: * Creates an {@code ObservableValue} that holds the value of an {@code ObservableValue} > 197: * resulting from applying a mapping on this {@code ObservableValue}'s value. The result While technically correct, I think the first sentence should focus more on the purpose of this method. How about something like this: `Creates a new {@code ObservableValue} that holds the value of a nested {@code ObservableValue} by applying a mapping function to extract the nested {@code ObservableValue}.` That's not as precise, but it makes the purpose much more clear. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 206: > 204: * that is part of a {@code Window} that is currently shown on screen: > 205: *
> 206:      * ObservableValue<Boolean> isShowing = listView.sceneProperty()

Escaping `<` and `>` is not necessary within

{@code
    ...
}
modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 227: > 225: * the showing of that window, will update the boolean value {@code isShowing}. > 226: *

> 227: * This method is preferred over {@link javafx.beans.binding.Bindings Bindings#select} methods This links to the `Bindings` class instead of a `select` method. Shouldn't it link directly to one of the relevant methods? modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 685: > 683: * before adding it. > 684: * > 685: * @param observableValue You can probably remove `@param` if there's no further documentation. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jvos at openjdk.java.net Fri Mar 18 07:47:53 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 18 Mar 2022 07:47:53 GMT Subject: [jfx17u] RFR: 8203463: [Accessibility, Narrator] NPE in TableView Message-ID: Reviewed-by: kcr ------------- Commit messages: - 8203463: [Accessibility, Narrator] NPE in TableView Changes: https://git.openjdk.java.net/jfx17u/pull/38/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=38&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8203463 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/38.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/38/head:pull/38 PR: https://git.openjdk.java.net/jfx17u/pull/38 From jvos at openjdk.java.net Fri Mar 18 07:48:37 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 18 Mar 2022 07:48:37 GMT Subject: [jfx11u] Integrated: 8203463: [Accessibility, Narrator] NPE in TableView In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 20:56:32 GMT, Johan Vos wrote: > Reviewed-by: kcr This pull request has now been integrated. Changeset: bf32dd8a Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/bf32dd8a52876b0c0a53e9f73d64b0a986829626 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8203463: [Accessibility, Narrator] NPE in TableView Backport-of: c705bd493931d88650542be5466d6add359f45b9 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/81 From jvos at openjdk.java.net Fri Mar 18 07:49:43 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 18 Mar 2022 07:49:43 GMT Subject: [jfx11u] Integrated: 8197991: Selecting many items in a TableView is very slow In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 21:01:51 GMT, Johan Vos wrote: > Co-authored-by: Naohiro Yoshimoto > Reviewed-by: kcr, aghaisas This pull request has now been integrated. Changeset: 1c3d9666 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/1c3d9666884b6689d7b982a8541c692468512bf0 Stats: 403 lines in 5 files changed: 357 ins; 40 del; 6 mod 8197991: Selecting many items in a TableView is very slow Backport-of: 8c4f966b163f68c517574e38c394b9349551ad08 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/82 From jvos at openjdk.java.net Fri Mar 18 07:50:13 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 18 Mar 2022 07:50:13 GMT Subject: [jfx17u] RFR: 8197991: Selecting many items in a TableView is very slow Message-ID: Co-authored-by: Naohiro Yoshimoto Reviewed-by: kcr, aghaisas ------------- Commit messages: - 8197991: Selecting many items in a TableView is very slow Changes: https://git.openjdk.java.net/jfx17u/pull/39/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=39&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8197991 Stats: 403 lines in 5 files changed: 357 ins; 40 del; 6 mod Patch: https://git.openjdk.java.net/jfx17u/pull/39.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/39/head:pull/39 PR: https://git.openjdk.java.net/jfx17u/pull/39 From jvos at openjdk.java.net Fri Mar 18 07:52:44 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 18 Mar 2022 07:52:44 GMT Subject: [jfx17u] Integrated: 8203463: [Accessibility, Narrator] NPE in TableView In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 07:42:11 GMT, Johan Vos wrote: > Reviewed-by: kcr This pull request has now been integrated. Changeset: 53d443bf Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/53d443bffa34c971c7c6192649caa9aba2acb5f5 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8203463: [Accessibility, Narrator] NPE in TableView Backport-of: c705bd493931d88650542be5466d6add359f45b9 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/38 From jvos at openjdk.java.net Fri Mar 18 07:56:45 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 18 Mar 2022 07:56:45 GMT Subject: [jfx17u] Integrated: 8197991: Selecting many items in a TableView is very slow In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 07:42:37 GMT, Johan Vos wrote: > Co-authored-by: Naohiro Yoshimoto > Reviewed-by: kcr, aghaisas This pull request has now been integrated. Changeset: 4af7ee97 Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/4af7ee97f37cb18b3433afc3b128b10d3401f29c Stats: 403 lines in 5 files changed: 357 ins; 40 del; 6 mod 8197991: Selecting many items in a TableView is very slow Backport-of: 8c4f966b163f68c517574e38c394b9349551ad08 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/39 From daniel.peintner at gmail.com Fri Mar 18 08:43:49 2022 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Fri, 18 Mar 2022 09:43:49 +0100 Subject: Question about fatal JavaFX crashes Message-ID: Hello, I take the liberty to ask on the email reflector if there are other people with similar problems. Since updating my application to JavaFX18 I get random fatal crashes. Unfortunately it is not predictable but after some time the app crashes with "EXCEPTION_ACCESS_VIOLATION". The hs_error_pidX reports the following. --------------- T H R E A D --------------- Current thread (0x0000016be9c9b410): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=3068, stack(0x000000393e800000,0x000000393e900000)] Current CompileTask: C2:10515286 18185 4 javafx.scene.control.TableView$5::onChanged (1049 bytes) Am I the only one seeing this? I am not sure if this relates to changing JavaFX 17 to 18 or whether it makes it just more likely. It seems to be related to "javafx.scene.control.TableView$5::onChanged" since all crashes show this line. Having said that, I cannot provide a test-case since it happens all of a sudden and sometimes after hours using the application. I am open to any feedback or input on how to proceed best. Thanks! -- Daniel From john.hendrikx at gmail.com Fri Mar 18 09:10:52 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 18 Mar 2022 10:10:52 +0100 Subject: Question about fatal JavaFX crashes In-Reply-To: References: Message-ID: <4a030502-5ae0-5c96-0c75-3399d82fd351@gmail.com> I haven't seen this one; the code in TableView in onChanged hasn't had any updates 6 years. I have my doubts this is a JavaFX problem as it seems the Compiler is crashing here in a piece of native code.? It's possible this problem is only occuring on systems where the compiler decides it needs to compile (or recompile) this method, so at a minimum you'd need to make use of TableView in a way to hits that code path often enough to trigger compilation. Oracle provides some documentation on how to deal with what looks like a compiler bug, please read here: https://docs.oracle.com/en/java/javase/17/troubleshoot/troubleshoot-system-crashes.html Further, I think you should report this problem with as much details as possible on bugs.openjdk.java.net -- you can look for similar bugs to see what kind of detail and settings would be helpful to debug this. Other things you could try to solve it yourself: - Run a different Java version - Try switching to a different GC - Use different VM options (are you using anything special?) - Anything else that is not often used, non-standard or experimental, try going to a more common setup --John On 18/03/2022 09:43, Daniel Peintner wrote: > Hello, > > I take the liberty to ask on the email reflector if there are other people > with similar problems. > > Since updating my application to JavaFX18 I get random fatal crashes. > Unfortunately it is not predictable but after some time the app crashes > with "EXCEPTION_ACCESS_VIOLATION". > > The hs_error_pidX reports the following. > > > --------------- T H R E A D --------------- > > Current thread (0x0000016be9c9b410): JavaThread "C2 CompilerThread0" > daemon [_thread_in_native, id=3068, > stack(0x000000393e800000,0x000000393e900000)] > > Current CompileTask: > C2:10515286 18185 4 javafx.scene.control.TableView$5::onChanged > (1049 bytes) > > > Am I the only one seeing this? > I am not sure if this relates to changing JavaFX 17 to 18 or whether it > makes it just more likely. > > It seems to be related to "javafx.scene.control.TableView$5::onChanged" > since all crashes show this line. > > Having said that, I cannot provide a test-case since it happens all of a > sudden and sometimes after hours using the application. > > I am open to any feedback or input on how to proceed best. > > Thanks! > > -- Daniel From jhendrikx at openjdk.java.net Fri Mar 18 10:32:36 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 18 Mar 2022 10:32:36 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v11] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: - Reword flat map docs a bit and fixed a link - Add missing javadoc tags - Clean up docs in Subscription - Fix code blocks - Add line feed at last line where it was missing ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/675/files - new: https://git.openjdk.java.net/jfx/pull/675/files/8f9bf897..6a5358d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=09-10 Stats: 39 lines in 7 files changed: 11 ins; 0 del; 28 mod Patch: https://git.openjdk.java.net/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/675/head:pull/675 PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Fri Mar 18 10:32:39 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 18 Mar 2022 10:32:39 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v10] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Thu, 17 Mar 2022 20:09:23 GMT, Michael Strau? wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Process review comments (2) > > modules/javafx.base/src/main/java/com/sun/javafx/binding/Subscription.java line 40: > >> 38: * >> 39: * For example:

>> 40: *

Subscription s = property.subscribe(System.out::println)
> > I believe our recommended pattern for example code is: > >
{@code
>     ...
> }
Fixed this everywhere. > modules/javafx.base/src/main/java/com/sun/javafx/binding/Subscription.java line 67: > >> 65: */ >> 66: default Subscription and(Subscription other) { >> 67: Objects.requireNonNull(other); > > This exception could be documented with `@throws NullPointerException if {@code other} is null` I've updated the docs a bit -- it hasn't received much attention because this is not going to be API for now > modules/javafx.base/src/main/java/javafx/beans/value/FlatMappedBinding.java line 68: > >> 66: }; >> 67: } >> 68: } > > Several files are missing newlines after the last closing brace. Do we enforce this? > > Also, if there's a newline after the first line of a class declaration, shouldn't there also be a newline before the last closing brace? Let me add those new lines at the end of files (everywhere) as Github is also flagging it with an ugly red marker. I tend to unconsciously remove them myself on longer files as it looks weird in editors to have an unused line at the bottom. As for the newline before the last closing brace, that doesn't seem to be done a lot in the current code base. I've added those newlines at the top as it seems fairly consistent in the code base, although I'm not a fan as I use empty lines only to separate things when there is no clear separation already (like an opening brace). > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 146: > >> 144: * Creates an {@code ObservableValue} that holds the result of applying a >> 145: * mapping on this {@code ObservableValue}'s value. The result is updated >> 146: * when this {@code ObservableValue}'s value changes. If this value is > > I think a lot of the new documentation in this class sacrifices understandability for precision in trying to deal with the difference between "this ObservableValue" and "this ObservableValue's value". > > However, my feeling is that that's not helping users who are trying to understand the purpose of the new APIs. > What do you think about a simplified version like this: > `Creates a new {@ObservableValue} that applies a mapping function to this {@code ObservableValue}. The result is updated when this {@code ObservableValue} changes.` > > Sure, it's not literally mapping _this ObservableValue instance_, but would this language really confuse readers more that the precise language? > > Another option might be to combine both: > `Creates a new {@ObservableValue} that applies a mapping function to this {@code ObservableValue}. More precisely, it creates a new {@code ObservableValue} that holds the result of applying a mapping function to the value of this {@code ObservableValue}.` Yeah, agreed, it is a bit annoying to have to deal with the fact that these classes are wrappers around an actual value and having to refer to them as such to be "precise". I'm willing to make another pass at all of these to change the wording. What do you think @nlisker ? > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 153: > >> 151: *
>> 152:      * var text = new SimpleStringProperty("abcd");
>> 153:      * ObservableValue<String> upperCase = text.map(String::toUpperCase);
> 
> Escaping `<` and `>` is not necessary if the code block is wrapped in `{@code}`

Also fixed everywhere

> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 197:
> 
>> 195:     /**
>> 196:      * Creates an {@code ObservableValue} that holds the value of an {@code ObservableValue}
>> 197:      * resulting from applying a mapping on this {@code ObservableValue}'s value. The result
> 
> While technically correct, I think the first sentence should focus more on the purpose of this method.
> 
> How about something like this:
> `Creates a new {@code ObservableValue} that holds the value of a nested {@code ObservableValue} by applying a mapping function to extract the nested {@code ObservableValue}.`
> 
> That's not as precise, but it makes the purpose much more clear.

I've changed this to use your wording as I think it does read much better.

Perhaps also possible:

      Creates a new {@code ObservableValue} that holds the value of a nested {@code ObservableValue} supplied
      by the given mapping function.

?

> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 227:
> 
>> 225:      * the showing of that window, will update the boolean value {@code isShowing}.
>> 226:      * 

>> 227: * This method is preferred over {@link javafx.beans.binding.Bindings Bindings#select} methods > > This links to the `Bindings` class instead of a `select` method. Shouldn't it link directly to one of the relevant methods? I changed this, it now links to the correct spot (for me) > modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 685: > >> 683: * before adding it. >> 684: * >> 685: * @param observableValue > > You can probably remove `@param` if there's no further documentation. I've fixed these javadoc comments. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From tschindl at openjdk.java.net Fri Mar 18 11:15:45 2022 From: tschindl at openjdk.java.net (Tom Schindl) Date: Fri, 18 Mar 2022 11:15:45 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v11] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Fri, 18 Mar 2022 10:32:36 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: > > - Reword flat map docs a bit and fixed a link > - Add missing javadoc tags > - Clean up docs in Subscription > - Fix code blocks > - Add line feed at last line where it was missing modules/javafx.base/src/main/java/com/sun/javafx/binding/Subscription.java line 57: > 55: * Cancels this subscription. > 56: */ > 57: void unsubscribe(); to me `unsubscribe` feels not natural, I'm not unsubscribing a `Subscription` but I'm eg disposing it, hence to me `dispose` would feel better but I'm not a native speaker. Another pattern I see often is that I store a subscription in a field and recreate it under certain conditions: private Subscription mySubscription; void refresh() { if( this.mySubscription != null ) { this.mySubscription.dispos(); } this.mySubscription = .... } if Subscription would provide ```java static void dispose(Subscription subscription) { if( subscription != null ) { subscription.dispose(); } } this would safe the user a null-check. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From nlisker at openjdk.java.net Fri Mar 18 13:57:45 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 18 Mar 2022 13:57:45 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v10] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <6QhZI7MDP8RV7IkdJBWBntdGDnCxkQq6C5ymAX6K1mY=.13c1a1db-aec2-4432-8f8d-4dfb0bcf7b73@github.com> On Fri, 18 Mar 2022 09:48:39 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/com/sun/javafx/binding/Subscription.java line 67: >> >>> 65: */ >>> 66: default Subscription and(Subscription other) { >>> 67: Objects.requireNonNull(other); >> >> This exception could be documented with `@throws NullPointerException if {@code other} is null` > > I've updated the docs a bit -- it hasn't received much attention because this is not going to be API for now Yes, in "phase 2" when this class is made public there will be a proper docs review. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From nlisker at openjdk.java.net Fri Mar 18 14:01:39 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 18 Mar 2022 14:01:39 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v10] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Fri, 18 Mar 2022 09:32:18 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/javafx/beans/value/FlatMappedBinding.java line 68: >> >>> 66: }; >>> 67: } >>> 68: } >> >> Several files are missing newlines after the last closing brace. Do we enforce this? >> >> Also, if there's a newline after the first line of a class declaration, shouldn't there also be a newline before the last closing brace? > > Let me add those new lines at the end of files (everywhere) as Github is also flagging it with an ugly red marker. I tend to unconsciously remove them myself on longer files as it looks weird in editors to have an unused line at the bottom. > > As for the newline before the last closing brace, that doesn't seem to be done a lot in the current code base. I've added those newlines at the top as it seems fairly consistent in the code base, although I'm not a fan as I use empty lines only to separate things when there is no clear separation already (like an opening brace). I don't think jcheck checks for newlines anywhere. Usually the style that I see is a newline after the definition of the class and at the end of the file (sometimes), but not before the last closing brace. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From daniel.peintner at gmail.com Fri Mar 18 14:08:17 2022 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Fri, 18 Mar 2022 15:08:17 +0100 Subject: Question about fatal JavaFX crashes In-Reply-To: <4a030502-5ae0-5c96-0c75-3399d82fd351@gmail.com> References: <4a030502-5ae0-5c96-0c75-3399d82fd351@gmail.com> Message-ID: Hi John, all, Thanks for your detailed reply. I submitted a bug report with detailed information. - Run a different Java version > I tried different versions and vendors with the same result. * OpenJDK 17.0.1 * Zulu 17.0.2 * I wanted to check also JDK18-ea but gradle does not yet support it > - Try switching to a different GC > - Use different VM options (are you using anything special?) > - Anything else that is not often used, non-standard or experimental, > try going to a more common setup > I use no specific setting, all is default. I have been reading that the -client flag might help in some cases but unfortunately this flag is no longer taken into account for 64bit JVMS. Thanks, -- Daniel > > --John > > On 18/03/2022 09:43, Daniel Peintner wrote: > > Hello, > > > > I take the liberty to ask on the email reflector if there are other > people > > with similar problems. > > > > Since updating my application to JavaFX18 I get random fatal crashes. > > Unfortunately it is not predictable but after some time the app crashes > > with "EXCEPTION_ACCESS_VIOLATION". > > > > The hs_error_pidX reports the following. > > > > > > --------------- T H R E A D --------------- > > > > Current thread (0x0000016be9c9b410): JavaThread "C2 CompilerThread0" > > daemon [_thread_in_native, id=3068, > > stack(0x000000393e800000,0x000000393e900000)] > > > > Current CompileTask: > > C2:10515286 18185 4 > javafx.scene.control.TableView$5::onChanged > > (1049 bytes) > > > > > > Am I the only one seeing this? > > I am not sure if this relates to changing JavaFX 17 to 18 or whether it > > makes it just more likely. > > > > It seems to be related to "javafx.scene.control.TableView$5::onChanged" > > since all crashes show this line. > > > > Having said that, I cannot provide a test-case since it happens all of a > > sudden and sometimes after hours using the application. > > > > I am open to any feedback or input on how to proceed best. > > > > Thanks! > > > > -- Daniel > From philip.race at oracle.com Fri Mar 18 17:25:29 2022 From: philip.race at oracle.com (Philip Race) Date: Fri, 18 Mar 2022 10:25:29 -0700 Subject: Question about fatal JavaFX crashes In-Reply-To: References: <4a030502-5ae0-5c96-0c75-3399d82fd351@gmail.com> Message-ID: <702711db-f8da-ba75-55ba-f6f1c53de46a@oracle.com> I think it is probable that this is a hotspot VM problem in the C2 JIT compiler code. I've moved your bug report to hotspot : https://bugs.openjdk.java.net/browse/JDK-8283386 The interesting question isn't about which version of FX used to work. It is what was the last working version of the JDK. It looks a bit like a JDK 17 bug from the evidence so far so if you were running FX 17 on JDK 17 GA you maybe have picked up a later update release? of JDK 17 along with FX 18 ?? Regardless this doesn't look like an FX bug. But unless you can actually provide a test case, or, by luck the hotspot folks recognise the issue, I don't know what can/will happen. -phil. On 3/18/22 7:08 AM, Daniel Peintner wrote: > Hi John, all, > > Thanks for your detailed reply. > I submitted a bug report with detailed information. > > - Run a different Java version > I tried different versions and vendors with the same result. > * OpenJDK 17.0.1 > * Zulu 17.0.2 > * I wanted to check also JDK18-ea but gradle does not yet support it > > >> - Try switching to a different GC >> - Use different VM options (are you using anything special?) >> - Anything else that is not often used, non-standard or experimental, >> try going to a more common setup >> > I use no specific setting, all is default. > I have been reading that the -client flag might help in some cases but > unfortunately this flag is no longer taken into account for 64bit JVMS. > > Thanks, > > -- Daniel > > > > >> --John >> >> On 18/03/2022 09:43, Daniel Peintner wrote: >>> Hello, >>> >>> I take the liberty to ask on the email reflector if there are other >> people >>> with similar problems. >>> >>> Since updating my application to JavaFX18 I get random fatal crashes. >>> Unfortunately it is not predictable but after some time the app crashes >>> with "EXCEPTION_ACCESS_VIOLATION". >>> >>> The hs_error_pidX reports the following. >>> >>> >>> --------------- T H R E A D --------------- >>> >>> Current thread (0x0000016be9c9b410): JavaThread "C2 CompilerThread0" >>> daemon [_thread_in_native, id=3068, >>> stack(0x000000393e800000,0x000000393e900000)] >>> >>> Current CompileTask: >>> C2:10515286 18185 4 >> javafx.scene.control.TableView$5::onChanged >>> (1049 bytes) >>> >>> >>> Am I the only one seeing this? >>> I am not sure if this relates to changing JavaFX 17 to 18 or whether it >>> makes it just more likely. >>> >>> It seems to be related to "javafx.scene.control.TableView$5::onChanged" >>> since all crashes show this line. >>> >>> Having said that, I cannot provide a test-case since it happens all of a >>> sudden and sometimes after hours using the application. >>> >>> I am open to any feedback or input on how to proceed best. >>> >>> Thanks! >>> >>> -- Daniel From kevin.rushforth at oracle.com Fri Mar 18 17:37:16 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 18 Mar 2022 10:37:16 -0700 Subject: Question about fatal JavaFX crashes In-Reply-To: <702711db-f8da-ba75-55ba-f6f1c53de46a@oracle.com> References: <4a030502-5ae0-5c96-0c75-3399d82fd351@gmail.com> <702711db-f8da-ba75-55ba-f6f1c53de46a@oracle.com> Message-ID: Thanks, Phil. That was my take as well. I don't see how this can be a JavaFX bug given where it is crashing. FWIW, I haven't ever seen anything like this. -- Kevin On 3/18/2022 10:25 AM, Philip Race wrote: > I think it is probable that this is a hotspot VM problem in the C2 JIT > compiler code. > > I've moved your bug report to hotspot : > https://bugs.openjdk.java.net/browse/JDK-8283386 > The interesting question isn't about which version of FX used to work. > It is what was the last working version of the JDK. > It looks a bit like a JDK 17 bug from the evidence so far so if > you were running FX 17 on JDK 17 GA you maybe have picked up a later > update release? of JDK 17 along with FX 18 ?? > > Regardless this doesn't look like an FX bug. > But unless you can actually provide a test case, or, by luck the > hotspot folks recognise the issue, > I don't know what can/will happen. > > -phil. > > On 3/18/22 7:08 AM, Daniel Peintner wrote: >> Hi John, all, >> >> Thanks for your detailed reply. >> I submitted a bug report with detailed information. >> >> - Run a different Java version >> I tried different versions and vendors with the same result. >> * OpenJDK 17.0.1 >> * Zulu 17.0.2 >> * I wanted to check also JDK18-ea but gradle does not yet support it >> >> >>> - Try switching to a different GC >>> - Use different VM options (are you using anything special?) >>> - Anything else that is not often used, non-standard or experimental, >>> try going to a more common setup >>> >> I use no specific setting, all is default. >> I have been reading that the -client flag might help in some cases but >> unfortunately this flag is no longer taken into account for 64bit JVMS. >> >> Thanks, >> >> -- Daniel >> >> >> >> >>> --John >>> >>> On 18/03/2022 09:43, Daniel Peintner wrote: >>>> Hello, >>>> >>>> I take the liberty to ask on the email reflector if there are other >>> people >>>> with similar problems. >>>> >>>> Since updating my application to JavaFX18 I get random fatal crashes. >>>> Unfortunately it is not predictable but after some time the app >>>> crashes >>>> with "EXCEPTION_ACCESS_VIOLATION". >>>> >>>> The hs_error_pidX reports the following. >>>> >>>> >>>> ---------------? T H R E A D? --------------- >>>> >>>> Current thread (0x0000016be9c9b410):? JavaThread "C2 CompilerThread0" >>>> daemon [_thread_in_native, id=3068, >>>> stack(0x000000393e800000,0x000000393e900000)] >>>> >>>> Current CompileTask: >>>> C2:10515286 18185?????? 4 >>> ? javafx.scene.control.TableView$5::onChanged >>>> (1049 bytes) >>>> >>>> >>>> Am I the only one seeing this? >>>> I am not sure if this relates to changing JavaFX 17 to 18 or >>>> whether it >>>> makes it just more likely. >>>> >>>> It seems to be related to >>>> "javafx.scene.control.TableView$5::onChanged" >>>> since all crashes show this line. >>>> >>>> Having said that, I cannot provide a test-case since it happens all >>>> of a >>>> sudden and sometimes after hours using the application. >>>> >>>> I am open to any feedback or input on how to proceed best. >>>> >>>> Thanks! >>>> >>>> -- Daniel > From philip.race at oracle.com Fri Mar 18 17:55:00 2022 From: philip.race at oracle.com (Philip Race) Date: Fri, 18 Mar 2022 10:55:00 -0700 Subject: Question about fatal JavaFX crashes In-Reply-To: References: <4a030502-5ae0-5c96-0c75-3399d82fd351@gmail.com> <702711db-f8da-ba75-55ba-f6f1c53de46a@oracle.com> Message-ID: <3ab2cd84-a32d-905e-be47-d72df7a99099@oracle.com> I have at least seen? JIT compiler crashes like this in other unrelated cases .. in theory you can use an option like -XX:CompileCommand=exclude,javafx/scene/control/TableView$5::onChanged although I am very unsure about the syntax for the last part of it especially with what looks like some anonymous method or lambda expression. I can almost guarantee that my example is wrong. Excluding the whole of TableView might be easier to specify but will slow you down a lot. -phil. On 3/18/22 10:37 AM, Kevin Rushforth wrote: > Thanks, Phil. That was my take as well. I don't see how this can be a > JavaFX bug given where it is crashing. FWIW, I haven't ever seen > anything like this. > > -- Kevin > > > On 3/18/2022 10:25 AM, Philip Race wrote: >> I think it is probable that this is a hotspot VM problem in the C2 >> JIT compiler code. >> >> I've moved your bug report to hotspot : >> https://bugs.openjdk.java.net/browse/JDK-8283386 >> The interesting question isn't about which version of FX used to work. >> It is what was the last working version of the JDK. >> It looks a bit like a JDK 17 bug from the evidence so far so if >> you were running FX 17 on JDK 17 GA you maybe have picked up a later >> update release? of JDK 17 along with FX 18 ?? >> >> Regardless this doesn't look like an FX bug. >> But unless you can actually provide a test case, or, by luck the >> hotspot folks recognise the issue, >> I don't know what can/will happen. >> >> -phil. >> >> On 3/18/22 7:08 AM, Daniel Peintner wrote: >>> Hi John, all, >>> >>> Thanks for your detailed reply. >>> I submitted a bug report with detailed information. >>> >>> - Run a different Java version >>> I tried different versions and vendors with the same result. >>> * OpenJDK 17.0.1 >>> * Zulu 17.0.2 >>> * I wanted to check also JDK18-ea but gradle does not yet support it >>> >>> >>>> - Try switching to a different GC >>>> - Use different VM options (are you using anything special?) >>>> - Anything else that is not often used, non-standard or experimental, >>>> try going to a more common setup >>>> >>> I use no specific setting, all is default. >>> I have been reading that the -client flag might help in some cases but >>> unfortunately this flag is no longer taken into account for 64bit JVMS. >>> >>> Thanks, >>> >>> -- Daniel >>> >>> >>> >>> >>>> --John >>>> >>>> On 18/03/2022 09:43, Daniel Peintner wrote: >>>>> Hello, >>>>> >>>>> I take the liberty to ask on the email reflector if there are other >>>> people >>>>> with similar problems. >>>>> >>>>> Since updating my application to JavaFX18 I get random fatal crashes. >>>>> Unfortunately it is not predictable but after some time the app >>>>> crashes >>>>> with "EXCEPTION_ACCESS_VIOLATION". >>>>> >>>>> The hs_error_pidX reports the following. >>>>> >>>>> >>>>> ---------------? T H R E A D? --------------- >>>>> >>>>> Current thread (0x0000016be9c9b410):? JavaThread "C2 CompilerThread0" >>>>> daemon [_thread_in_native, id=3068, >>>>> stack(0x000000393e800000,0x000000393e900000)] >>>>> >>>>> Current CompileTask: >>>>> C2:10515286 18185?????? 4 >>>> ? javafx.scene.control.TableView$5::onChanged >>>>> (1049 bytes) >>>>> >>>>> >>>>> Am I the only one seeing this? >>>>> I am not sure if this relates to changing JavaFX 17 to 18 or >>>>> whether it >>>>> makes it just more likely. >>>>> >>>>> It seems to be related to >>>>> "javafx.scene.control.TableView$5::onChanged" >>>>> since all crashes show this line. >>>>> >>>>> Having said that, I cannot provide a test-case since it happens >>>>> all of a >>>>> sudden and sometimes after hours using the application. >>>>> >>>>> I am open to any feedback or input on how to proceed best. >>>>> >>>>> Thanks! >>>>> >>>>> -- Daniel >> > From mariushanl at web.de Fri Mar 18 20:47:59 2022 From: mariushanl at web.de (Marius Hanl) Date: Fri, 18 Mar 2022 21:47:59 +0100 Subject: Aw: Re: ArrayIndexOutOfBoundsException when disconnecting screen In-Reply-To: <6a09f4fa-3b05-21a3-d14e-66f8a8a0a463@oracle.com> References: <6a09f4fa-3b05-21a3-d14e-66f8a8a0a463@oracle.com> Message-ID: Sorry for the delay. I tested a bit around, unfortunately this bug doesn't happen all the time. It looks like it can also happen when disconnecting just one screen. I have filed a ticket: https://bugs.openjdk.java.net/browse/JDK-8283401 Also one time the JVM crashed, leaving a hs_err_pid file, which I attached as well. -- Marius Gesendet: Mittwoch, 23. Februar 2022 um 23:54 Uhr Von: "Kevin Rushforth" An: "Marius Hanl" , "openjfx-dev" Betreff: Re: ArrayIndexOutOfBoundsException when disconnecting screen I spent a fair bit of time simulating and testing the D3DERR_DEVICEREMOVED cases for RDP disconnect to fix JDK-8239589 [1], but detaching a screen, which will change the number of active adapters, is a somewhat different case (I'm not sure how easy it would be to simulate it). It's very likely that it isn't handled in a robust manner. Do you know whether you need to disconnect 2 screens to reproduce this, or would disconnecting a single external monitor cause it? Based on the stack trace, it looks like the D3DResourceFactory array has been recreated with the reduced number of adapters (1), but the old screen is still being used by the instance of PPSRenderer. Can you file a bug with the stack trace, and as much information about how to reproduce it as you can. -- Kevin [1] [1]https://bugs.openjdk.java.net/browse/JDK-8239589 On 2/23/2022 3:35 AM, Marius Hanl wrote: > I get an ArrayIndexOutOfBoundsException sometimes when I disconnect my > screen(s). > Setup: I have a laptop with a docking station attached. The docking > station is connected to two screen, so when I disconnect it 2 screen > will be 'lost'. > > The following stacktrace is visible and the application is completely > black and unresponsive: > java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for > length 1 > at > com.sun.prism.d3d.D3DPipeline.getD3DResourceFactory(D3DPipeline.java:21 > 7) > at > com.sun.prism.d3d.D3DPipeline.getResourceFactory(D3DPipeline.java:284) > at > com.sun.scenario.effect.impl.prism.ps.PPSRenderer.validate(PPSRenderer. > java:101) > at > com.sun.scenario.effect.impl.prism.ps.PPSRenderer.getCompatibleImage(PP > SRenderer.java:221) > at > com.sun.scenario.effect.impl.prism.ps.PPSRenderer.getCompatibleImage(PP > SRenderer.java:67) > at > com.sun.scenario.effect.Effect.getCompatibleImage(Effect.java:479) > at > com.sun.javafx.sg.prism.NodeEffectInput.getImageDataForBoundedNode(Node > EffectInput.java:228) > at > com.sun.javafx.sg.prism.NodeEffectInput.filter(NodeEffectInput.java:131 > ) > at > com.sun.scenario.effect.FilterEffect.filter(FilterEffect.java:185) > at com.sun.scenario.effect.Offset.filter(Offset.java:160) > at com.sun.scenario.effect.Merge.filter(Merge.java:148) > at > com.sun.scenario.effect.DelegateEffect.filter(DelegateEffect.java:70) > at > com.sun.scenario.effect.impl.prism.PrEffectHelper.render(PrEffectHelper > .java:166) > at > com.sun.javafx.sg.prism.EffectFilter.render(EffectFilter.java:61) > at com.sun.javafx.sg.prism.NGNode.renderEffect(NGNode.java:2384) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2069) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at > com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > ... ( a lot of doRender(..), renderContent(..) calls... ) > at > com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > at > com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > at > com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java: > 92) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors > .java:515) > at > java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureT > ask.java:305) > at > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java) > at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolE > xecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPool > Executor.java:628) > at > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumR > enderer.java:126) > at java.base/java.lang.Thread.run(Thread.java:829) > > ----------------------------------------------------------------------- > ------------------------------------------------------- > > Now my question: > A naive fix would be an array check here but does someone has more > information about the code here? > And more interesting: Is there a way to write tests for this? Maybe > with simulating/faking screens and then 'faking' a screen disconnect? > > -- Marius References 1. https://bugs.openjdk.java.net/browse/JDK-8239589 From duke at openjdk.java.net Fri Mar 18 21:31:39 2022 From: duke at openjdk.java.net (yosbits) Date: Fri, 18 Mar 2022 21:31:39 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 21:10:14 GMT, Marius Hanl wrote: > This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. > > I also added tests which will succeed before and after to verify that nothing got broken by this change. > Also I made a benchmark test. Results: > > | Benchmark | Mode| Cnt | Score | Error | Units > | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | > | ListBenchmark OLD | thrpt | 25 | 722,842 | ? 26,93 | ops/s > | ListBenchmark NEW | thrpt | 25 | 29262,274 | ? 2088,712 | ops/s > >

Benchmark code > > > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import org.openjdk.jmh.annotations.Benchmark; > import org.openjdk.jmh.annotations.Scope; > import org.openjdk.jmh.annotations.Setup; > import org.openjdk.jmh.annotations.State; > import org.openjdk.jmh.annotations.TearDown; > > import java.util.ArrayList; > import java.util.List; > > @State(Scope.Benchmark) > public class ListBenchmark { > > List strings; > > @Setup > public void setup() { > strings = new ArrayList<>(); > for(int i = 0; i< 100000;i++) { > strings.add("abc: " + i); > } > } > > @TearDown > public void tearDown() { > strings = null; > } > > @Benchmark > public ObservableList init() { > return FXCollections.observableArrayList(strings); > } > } > > >
This PR appears to have two internal behavior changes. A. Initial collection size (PR owner's description) B. By adding the item directly to the backingList Avoiding beginChange () --doAdd () --endChange () ``` java @Override protected void doAdd (int index, E element) { if (elementObserver! = null) elementObserver.attachListener (element); backingList.add (index, element); } Looking at the following code, it seems that there is no problem because attachListener () is called in the constructor. We will need to make sure that the current unit tests cover B's changes. ObservableListWrapper.java ``` java public ObservableListWrapper(List list) { backingList = list; elementObserver = null; } public ObservableListWrapper(List list, Callback extractor) { backingList = list; this.elementObserver = new ElementObserver(extractor, new Callback() { @Override public InvalidationListener call(final E e) { return new InvalidationListener() { @Override public void invalidated(Observable observable) { beginChange(); int i = 0; final int size = size(); for (; i < size; ++i) { if (get(i) == e) { nextUpdate(i); } } endChange(); } }; } }, this); final int sz = backingList.size(); for (int i = 0; i < sz; ++i) { elementObserver.attachListener(backingList.get(i)); } } ------------- PR: https://git.openjdk.java.net/jfx/pull/758 From john.hendrikx at gmail.com Fri Mar 18 21:52:55 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 18 Mar 2022 22:52:55 +0100 Subject: Promote addEventHandler/removeEventHandler to EventTarget interface In-Reply-To: References: Message-ID: <05b7dfbc-32bd-c288-0bc2-bf8cf3077551@gmail.com> On 17/03/2022 21:01, Michael Strau? wrote: > I'm working on an application that uses the JavaFX event system > extensively, and I'm finding it quite hard to use common code for > event handler registrations. > > The problem is that the `EventTarget` interface contains no > addEventHandler/removeEventHandler methods, and as a consequence of > that, code that uses `EventTarget` ends up requiring lots of brittle > instanceof tests to call these methods on all the different > implementations of `EventTarget`. > > There are three buckets of `EventTarget` implementations: > > 1) Implementations that declare the following methods: > void addEventHandler(EventType, > EventHandler); > void removeEventHandler(EventType, > EventHandler); > void addEventFilter(EventType, EventHandler super T>); > void removeEventFilter(EventType, > EventHandler); > --> Node, Scene, Window, Transform, Task, Service > > 2) Implementations that declare the following methods: > void addEventHandler(EventType, EventHandler); > void removeEventHandler(EventType, EventHandler); > --> MenuItem, TreeItem, TableColumnBase > > (Note that the EventHandler argument ist parameterized as > EventHandler, not EventHandler as in the first set of > methods.) > > 3) Implementations that don't declare any methods to add or remove > event handlers: > --> Dialog, Tab > > I think the situation can be improved by promoting the bucket 1 > methods to the `EventTarget` interface, so they can be used > consistently across all implementations of `EventTarget`. > > This works seamlessly for bucket 1 and bucket 3 implementations. I think it would make good sense that they also have the EventHandler/Filters methods for consistency.? If they're targets for Events, then you should be able to add handlers or filters for them. > With bucket 2, there's the problem that, inconsistently, the > EventHandler argument is not a lower-bounded wildcard. > Unfortunately, a method with an EventHandler parameter cannot > implement an interface method that expects EventHandler. > > However, since the erasure of the method remains the same, changing > the method signature would technically be a binary-compatible change. They also forward directly to the internal EventHandlerManager which does accept EventHandler.? This seems like an oversight when those implementations were added to MenuItem, TreeItem and TableColumnBase. > Do you think this is a useful improvement? I think that all the implementations should definitely be consistent; Dialog and Tab probably should have the means to add EventHandlers and EventFilters; and MenuItem, TreeItem, TableColumnBase could do with the EventFilter variants. If they're going to be consistent, might as well add these methods to the EventTarget interface to enforce this for any future EventTarget implementations. EventTarget is already public API, and so there might be 3rd party implementations.? This means that the methods added to the EventTarget interface must be default methods. It would be super if these default implementations would just work out of the box, but that would require exposing the internal class EventHandlerManager (and adding a `getEventHandlerManager` to the `EventTarget` interface).? If that's not realistic, then initially the default implementations would have to throw UnsupportedOperationException. --John From swpalmer at gmail.com Fri Mar 18 22:07:41 2022 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 18 Mar 2022 18:07:41 -0400 Subject: Question about fatal JavaFX crashes In-Reply-To: <3ab2cd84-a32d-905e-be47-d72df7a99099@oracle.com> References: <3ab2cd84-a32d-905e-be47-d72df7a99099@oracle.com> Message-ID: <1CB8A4C6-EC35-4D87-9ACA-C85C92F54CC6@gmail.com> I wonder, could you do the opposite and force compilation to trigger the bug more consistently? Scott > On Mar 18, 2022, at 2:03 PM, Philip Race wrote: > > ?I have at least seen JIT compiler crashes like this in other unrelated cases .. > > in theory you can use an option like > > -XX:CompileCommand=exclude,javafx/scene/control/TableView$5::onChanged > > although I am very unsure about the syntax for the last part of it especially with what looks like > some anonymous method or lambda expression. I can almost guarantee that my example is wrong. > > Excluding the whole of TableView might be easier to specify but will slow you down a lot. > > -phil. > > >> On 3/18/22 10:37 AM, Kevin Rushforth wrote: >> Thanks, Phil. That was my take as well. I don't see how this can be a JavaFX bug given where it is crashing. FWIW, I haven't ever seen anything like this. >> >> -- Kevin >> >> >>> On 3/18/2022 10:25 AM, Philip Race wrote: >>> I think it is probable that this is a hotspot VM problem in the C2 JIT compiler code. >>> >>> I've moved your bug report to hotspot : https://bugs.openjdk.java.net/browse/JDK-8283386 >>> The interesting question isn't about which version of FX used to work. >>> It is what was the last working version of the JDK. >>> It looks a bit like a JDK 17 bug from the evidence so far so if >>> you were running FX 17 on JDK 17 GA you maybe have picked up a later update release of JDK 17 along with FX 18 ?? >>> >>> Regardless this doesn't look like an FX bug. >>> But unless you can actually provide a test case, or, by luck the hotspot folks recognise the issue, >>> I don't know what can/will happen. >>> >>> -phil. >>> >>> On 3/18/22 7:08 AM, Daniel Peintner wrote: >>>> Hi John, all, >>>> >>>> Thanks for your detailed reply. >>>> I submitted a bug report with detailed information. >>>> >>>> - Run a different Java version >>>> I tried different versions and vendors with the same result. >>>> * OpenJDK 17.0.1 >>>> * Zulu 17.0.2 >>>> * I wanted to check also JDK18-ea but gradle does not yet support it >>>> >>>> >>>>> - Try switching to a different GC >>>>> - Use different VM options (are you using anything special?) >>>>> - Anything else that is not often used, non-standard or experimental, >>>>> try going to a more common setup >>>>> >>>> I use no specific setting, all is default. >>>> I have been reading that the -client flag might help in some cases but >>>> unfortunately this flag is no longer taken into account for 64bit JVMS. >>>> >>>> Thanks, >>>> >>>> -- Daniel >>>> >>>> >>>> >>>> >>>>> --John >>>>> >>>>> On 18/03/2022 09:43, Daniel Peintner wrote: >>>>>> Hello, >>>>>> >>>>>> I take the liberty to ask on the email reflector if there are other >>>>> people >>>>>> with similar problems. >>>>>> >>>>>> Since updating my application to JavaFX18 I get random fatal crashes. >>>>>> Unfortunately it is not predictable but after some time the app crashes >>>>>> with "EXCEPTION_ACCESS_VIOLATION". >>>>>> >>>>>> The hs_error_pidX reports the following. >>>>>> >>>>>> >>>>>> --------------- T H R E A D --------------- >>>>>> >>>>>> Current thread (0x0000016be9c9b410): JavaThread "C2 CompilerThread0" >>>>>> daemon [_thread_in_native, id=3068, >>>>>> stack(0x000000393e800000,0x000000393e900000)] >>>>>> >>>>>> Current CompileTask: >>>>>> C2:10515286 18185 4 >>>>> javafx.scene.control.TableView$5::onChanged >>>>>> (1049 bytes) >>>>>> >>>>>> >>>>>> Am I the only one seeing this? >>>>>> I am not sure if this relates to changing JavaFX 17 to 18 or whether it >>>>>> makes it just more likely. >>>>>> >>>>>> It seems to be related to "javafx.scene.control.TableView$5::onChanged" >>>>>> since all crashes show this line. >>>>>> >>>>>> Having said that, I cannot provide a test-case since it happens all of a >>>>>> sudden and sometimes after hours using the application. >>>>>> >>>>>> I am open to any feedback or input on how to proceed best. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -- Daniel >>> >> > From mstrauss at openjdk.java.net Fri Mar 18 23:58:35 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 18 Mar 2022 23:58:35 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v10] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Fri, 18 Mar 2022 10:17:01 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 197: >> >>> 195: /** >>> 196: * Creates an {@code ObservableValue} that holds the value of an {@code ObservableValue} >>> 197: * resulting from applying a mapping on this {@code ObservableValue}'s value. The result >> >> While technically correct, I think the first sentence should focus more on the purpose of this method. >> >> How about something like this: >> `Creates a new {@code ObservableValue} that holds the value of a nested {@code ObservableValue} by applying a mapping function to extract the nested {@code ObservableValue}.` >> >> That's not as precise, but it makes the purpose much more clear. > > I've changed this to use your wording as I think it does read much better. > > Perhaps also possible: > > Creates a new {@code ObservableValue} that holds the value of a nested {@code ObservableValue} supplied > by the given mapping function. > > ? Both seem fine, I don't have any preference over one or the other. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From duke at openjdk.java.net Sat Mar 19 00:15:31 2022 From: duke at openjdk.java.net (yosbits) Date: Sat, 19 Mar 2022 00:15:31 GMT Subject: RFR: 8283063: Optimize Observable{List/Set/Map}Wrapper.retainAll/removeAll In-Reply-To: References: Message-ID: <4PuRvMPNjgKClaiWjgS1uHXLMDvzuaznPss2iX0J5xo=.f4f5d807-17c8-4b4f-ac22-64fce9671422@github.com> On Sat, 12 Mar 2022 04:57:37 GMT, Michael Strau? wrote: > `Observable{List/Set/Map}Wrapper.retainAll/removeAll` can be optimized for some edge cases. > > 1. `removeAll(c)`: > This is a no-op if 'c' is empty. > For `ObservableListWrapper`, returning early skips an object allocation. For `ObservableSetWrapper` and `ObservableMapWrapper`, returning early prevents an enumeration of the entire collection. > > 2. `retainAll(c)`: > This is a no-op if the backing collection is empty, or equivalent to `clear()` if `c` is empty. > > I've added some tests to verify the optimized behavior for each of the three classes. This is an equivalent change that partially includes the fix I proposed in #305. It is good to apply it to Map / Set. ------------- PR: https://git.openjdk.java.net/jfx/pull/751 From mstrauss at openjdk.java.net Sat Mar 19 00:31:39 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 19 Mar 2022 00:31:39 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections In-Reply-To: References: Message-ID: <8okQTQWW9P8CZNB_qJAUIRXYcGj4sinldAF8NnhK_YI=.797f2a12-347c-4bf3-848b-bc160bad22e7@github.com> On Thu, 17 Mar 2022 21:10:14 GMT, Marius Hanl wrote: > This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. > > I also added tests which will succeed before and after to verify that nothing got broken by this change. > Also I made a benchmark test. Results: > > | Benchmark | Mode| Cnt | Score | Error | Units > | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | > | ListBenchmark OLD | thrpt | 25 | 722,842 | ? 26,93 | ops/s > | ListBenchmark NEW | thrpt | 25 | 29262,274 | ? 2088,712 | ops/s > >
Benchmark code > > > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import org.openjdk.jmh.annotations.Benchmark; > import org.openjdk.jmh.annotations.Scope; > import org.openjdk.jmh.annotations.Setup; > import org.openjdk.jmh.annotations.State; > import org.openjdk.jmh.annotations.TearDown; > > import java.util.ArrayList; > import java.util.List; > > @State(Scope.Benchmark) > public class ListBenchmark { > > List strings; > > @Setup > public void setup() { > strings = new ArrayList<>(); > for(int i = 0; i< 100000;i++) { > strings.add("abc: " + i); > } > } > > @TearDown > public void tearDown() { > strings = null; > } > > @Benchmark > public ObservableList init() { > return FXCollections.observableArrayList(strings); > } > } > > >
The following pieces of code should be identical: var list = FXCollections.observableArrayList(); list.addAll(source); var list = FXCollections.observableList(new ArrayList<>(source)); Any observable difference in behavior would be unspecified. When it comes to `modCount`, that's an internal field of `AbstractList`. `FXCollections.observableArrayList()` and `FXCollections.observableList(...)` are not the right place to test this. ------------- PR: https://git.openjdk.java.net/jfx/pull/758 From mhanl at openjdk.java.net Sat Mar 19 10:05:33 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Sat, 19 Mar 2022 10:05:33 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 21:28:33 GMT, yosbits wrote: > * I don't know what the modCount property is used for, but is it okay if the modified code has different values? This is fine as the mod count is only there to detect concurrent modifications. I recommend to read the `modCount` javadoc, its is very well written. And as @mstr2 also wrote, it is also an internal field (for the above mentioned purpose). ------------- PR: https://git.openjdk.java.net/jfx/pull/758 From mhanl at openjdk.java.net Sat Mar 19 10:47:59 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Sat, 19 Mar 2022 10:47:59 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v2] In-Reply-To: References: Message-ID: <_nJLBVxqPmJpJPb7c-Qf4FOjE774IPeDle0c_aK20P4=.31ef7452-118c-46d7-9a1e-c8459c18fa17@github.com> > This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. > > I also added tests which will succeed before and after to verify that nothing got broken by this change. > Also I made a benchmark test. Results: > > | Benchmark | Mode| Cnt | Score | Error | Units > | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | > | ListBenchmark OLD | thrpt | 25 | 722,842 | ? 26,93 | ops/s > | ListBenchmark NEW | thrpt | 25 | 29262,274 | ? 2088,712 | ops/s > >
Benchmark code > > > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import org.openjdk.jmh.annotations.Benchmark; > import org.openjdk.jmh.annotations.Scope; > import org.openjdk.jmh.annotations.Setup; > import org.openjdk.jmh.annotations.State; > import org.openjdk.jmh.annotations.TearDown; > > import java.util.ArrayList; > import java.util.List; > > @State(Scope.Benchmark) > public class ListBenchmark { > > List strings; > > @Setup > public void setup() { > strings = new ArrayList<>(); > for(int i = 0; i< 100000;i++) { > strings.add("abc: " + i); > } > } > > @TearDown > public void tearDown() { > strings = null; > } > > @Benchmark > public ObservableList init() { > return FXCollections.observableArrayList(strings); > } > } > > >
Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8283346: Better test name ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/758/files - new: https://git.openjdk.java.net/jfx/pull/758/files/30262a55..241962a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=758&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=758&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/758.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/758/head:pull/758 PR: https://git.openjdk.java.net/jfx/pull/758 From kcr at openjdk.java.net Sat Mar 19 16:01:29 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 19 Mar 2022 16:01:29 GMT Subject: RFR: 8236689: macOS 10.15 Catalina: LCD text renders badly In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 18:13:15 GMT, Mike Hearn wrote: >> On an external (non-retina) monitor JavaFX LCD text on macOS is painful on the eyes. >> Retina diminishes it rather than cures it. >> >> The problem is a mix of a couple of things >> 1) CoreText no longer generates LCD glyphs (except perhaps if you change some system settings at your own risk) >> 2) Prism's LCD shader assumes it got LCD glyphs and makes sub-pixel positioning adjustments that turn greyscale >> glyphs into multi-coloured glyphs that weren't meant to be ... >> >> The fix here is to just disable LCD by default on macOS as is already done (eg) on iOS >> This ripples through to make everything use grey scale even if you asked for the LCD (which you can't have) >> It also means if you REALLY want it (and perhaps are tweaking those magical settings) you can have it back >> by just specifying -Dprism.lcdtext=on >> >> Also it means the pieces of support for this on macos are still there if Apple ever bring it back (unlikely). >> Not that much code would be removed anyway .. a fair amount of it is needed for Windows and Linux. > > I can't comment on the JBS bug, but I'm not sure this is actually fixed. I upgraded to JavaFX 18 and the bug is still there. Setting `-Dprism.lcdtext=off` fixes it. I'm not sure why, because the change to do this by default seems simple enough. @mikehearn I downloaded the JavaFX 18 GA bundle and can confirm that LCD text is disabled by default on macOS as per this fix. You might want to double-check the JavaFX version by printing out the "javafx.version" system property. ------------- PR: https://git.openjdk.java.net/jfx/pull/642 From mhanl at openjdk.java.net Sat Mar 19 18:19:01 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Sat, 19 Mar 2022 18:19:01 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v3] In-Reply-To: References: Message-ID: > This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. > > I also added tests which will succeed before and after to verify that nothing got broken by this change. > Also I made a benchmark test. Results: > > | Benchmark | Mode| Cnt | Score | Error | Units > | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | > | ListBenchmark OLD | thrpt | 25 | 722,842 | ? 26,93 | ops/s > | ListBenchmark NEW | thrpt | 25 | 29262,274 | ? 2088,712 | ops/s > >
Benchmark code > > > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import org.openjdk.jmh.annotations.Benchmark; > import org.openjdk.jmh.annotations.Scope; > import org.openjdk.jmh.annotations.Setup; > import org.openjdk.jmh.annotations.State; > import org.openjdk.jmh.annotations.TearDown; > > import java.util.ArrayList; > import java.util.List; > > @State(Scope.Benchmark) > public class ListBenchmark { > > List strings; > > @Setup > public void setup() { > strings = new ArrayList<>(); > for(int i = 0; i< 100000;i++) { > strings.add("abc: " + i); > } > } > > @TearDown > public void tearDown() { > strings = null; > } > > @Benchmark > public ObservableList init() { > return FXCollections.observableArrayList(strings); > } > } > > >
Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8283346: Improved test name ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/758/files - new: https://git.openjdk.java.net/jfx/pull/758/files/241962a3..a92e9a01 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=758&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=758&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/758.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/758/head:pull/758 PR: https://git.openjdk.java.net/jfx/pull/758 From nlisker at openjdk.java.net Sun Mar 20 03:12:44 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 20 Mar 2022 03:12:44 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v10] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Fri, 18 Mar 2022 23:55:36 GMT, Michael Strau? wrote: >> I've changed this to use your wording as I think it does read much better. >> >> Perhaps also possible: >> >> Creates a new {@code ObservableValue} that holds the value of a nested {@code ObservableValue} supplied >> by the given mapping function. >> >> ? > > Both seem fine, I don't have any preference over one or the other. I struggled with finding a good description here [previously](https://github.com/openjdk/jfx/pull/675#discussion_r777801130). I think that mstr2 gave a good approach. What we can do if we want to have "the best of both worlds" is to write something in this form: . More precisely, I would offer something like this based on your suggestions: Creates a new {@code ObservableValue} that holds the value of a nested {@code ObservableValue} supplied by the given mapping function. The result is updated when either this or the nested {@code ObservableValue} changes. If either this or the nested value is {@code null}, the resulting value is {@code null} (no mapping is applied if this value is {@code null}). More precisely, the created {@code ObservableValue} holds the value of an {@code ObservableValue} resulting from applying a mapping on this {@code ObservableValue}'s value. I'm honestly not sure the "More precisely" part is even needed at his point. Up to you. The `@return` description can be changed accordingly with the simplified explanation if you think it's clearer. You can also specify a `@throws` NPE if the mapping function parameter is `null` instead of writing "cannot be null", like mstr2 suggested in another place if you like this pattern. By the way, if we change "Creates an..." to "Creates a new..." we should change it in the other methods. I don't think there's a difference. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From nlisker at openjdk.java.net Sun Mar 20 03:31:36 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 20 Mar 2022 03:31:36 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v10] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Fri, 18 Mar 2022 09:55:30 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 146: >> >>> 144: * Creates an {@code ObservableValue} that holds the result of applying a >>> 145: * mapping on this {@code ObservableValue}'s value. The result is updated >>> 146: * when this {@code ObservableValue}'s value changes. If this value is >> >> I think a lot of the new documentation in this class sacrifices understandability for precision in trying to deal with the difference between "this ObservableValue" and "this ObservableValue's value". >> >> However, my feeling is that that's not helping users who are trying to understand the purpose of the new APIs. >> What do you think about a simplified version like this: >> `Creates a new {@ObservableValue} that applies a mapping function to this {@code ObservableValue}. The result is updated when this {@code ObservableValue} changes.` >> >> Sure, it's not literally mapping _this ObservableValue instance_, but would this language really confuse readers more that the precise language? >> >> Another option might be to combine both: >> `Creates a new {@ObservableValue} that applies a mapping function to this {@code ObservableValue}. More precisely, it creates a new {@code ObservableValue} that holds the result of applying a mapping function to the value of this {@code ObservableValue}.` > > Yeah, agreed, it is a bit annoying to have to deal with the fact that these classes are wrappers around an actual value and having to refer to them as such to be "precise". I'm willing to make another pass at all of these to change the wording. What do you think @nlisker ? I read this comment after what I wrote about `flatMap`, so mstr2 also had the idea of "More precisely", which is good :) I would suggested something similar to what I did there: Creates a new {@code ObservableValue} that holds the value supplied by the given mapping function. The result is updated when this {@code ObservableValue} changes. If this value is {@code null}... More precisely, the created {@code ObservableValue} holds the result of applying a mapping on this {@code ObservableValue}'s value. Same comments about `@return` and `@throws` NPE as I had for `flatMap`. `orElse` will also becomes something like Creates a new {@code ObservableValue} that holds this value, or the given value if it is {@code null}. The result is updated when this {@code ObservableValue} changes. More precisely, the created {@code ObservableValue} holds this {@code ObservableValue}'s value, or the given value if it is {@code null}. Also not sure if the "More precisely" description is needed here. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Mon Mar 21 08:51:43 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 21 Mar 2022 08:51:43 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v12] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Update API docs for ObservableValue - Used wording from java.util.stream.Stream and java.util.Optional - Replaced "Creates a new" with "Returns an" to allow for flexibility (potentially we could return the same instance for the same calls); this also how Stream starts descriptions - Added @throws NullPointerException in the style of java.util.Optional - Used "the" instead of "a" or "an" when describing parameters (same as Optional) - Removed references to {@code Function}, neither Optional or Stream mention the interface explicitely ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/675/files - new: https://git.openjdk.java.net/jfx/pull/675/files/6a5358d7..cb01f114 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=10-11 Stats: 26 lines in 1 file changed: 2 ins; 1 del; 23 mod Patch: https://git.openjdk.java.net/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/675/head:pull/675 PR: https://git.openjdk.java.net/jfx/pull/675 From mstrauss at openjdk.java.net Mon Mar 21 08:51:43 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 21 Mar 2022 08:51:43 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v10] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <8fseYWpIlYZjC4ZUYoRLTbwFFORZZmnOBEqWO17P9pk=.b7c802fb-122d-4e7e-833b-23b02351d142@github.com> On Sun, 20 Mar 2022 03:28:01 GMT, Nir Lisker wrote: >> Yeah, agreed, it is a bit annoying to have to deal with the fact that these classes are wrappers around an actual value and having to refer to them as such to be "precise". I'm willing to make another pass at all of these to change the wording. What do you think @nlisker ? > > I read this comment after what I wrote about `flatMap`, so mstr2 also had the idea of "More precisely", which is good :) > > I would suggested something similar to what I did there: > > > Creates a new {@code ObservableValue} that holds the value supplied by the given mapping function. The result > is updated when this {@code ObservableValue} changes. > If this value is {@code null}... > More precisely, the created {@code ObservableValue} holds the result of applying a mapping on this > {@code ObservableValue}'s value. > > > Same comments about `@return` and `@throws` NPE as I had for `flatMap`. > > `orElse` will also becomes something like > > > Creates a new {@code ObservableValue} that holds this value, or the given value if it is {@code null}. The > result is updated when this {@code ObservableValue} changes. > More precisely, the created {@code ObservableValue} holds this {@code ObservableValue}'s value, or > the given value if it is {@code null}. > > > Also not sure if the "More precisely" description is needed here. I think I've arrived at the conclusing that the "more precisely" description is basically rehashing the semantics of `ObservableValue` over and over again. It should be clear for a reader who is familiar with ObservableValue that we're not suggesting that somehow the given ObservableValue _instance_ is stored in the new ObservableValue. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Mon Mar 21 08:59:34 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 21 Mar 2022 08:59:34 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v13] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <2vDciL-NbVzwJw6GKdXWLkx4l8ITs52aK9vShQhBL0g=.b19d64c2-79b1-401a-994d-3894bd4b8da2@github.com> > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Small wording change in API of ObservableValue after proof reading ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/675/files - new: https://git.openjdk.java.net/jfx/pull/675/files/cb01f114..e09186ca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=11-12 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/675/head:pull/675 PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Mon Mar 21 09:04:47 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 21 Mar 2022 09:04:47 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v10] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Sun, 20 Mar 2022 03:28:01 GMT, Nir Lisker wrote: >> Yeah, agreed, it is a bit annoying to have to deal with the fact that these classes are wrappers around an actual value and having to refer to them as such to be "precise". I'm willing to make another pass at all of these to change the wording. What do you think @nlisker ? > > I read this comment after what I wrote about `flatMap`, so mstr2 also had the idea of "More precisely", which is good :) > > I would suggested something similar to what I did there: > > > Creates a new {@code ObservableValue} that holds the value supplied by the given mapping function. The result > is updated when this {@code ObservableValue} changes. > If this value is {@code null}... > More precisely, the created {@code ObservableValue} holds the result of applying a mapping on this > {@code ObservableValue}'s value. > > > Same comments about `@return` and `@throws` NPE as I had for `flatMap`. > > `orElse` will also becomes something like > > > Creates a new {@code ObservableValue} that holds this value, or the given value if it is {@code null}. The > result is updated when this {@code ObservableValue} changes. > More precisely, the created {@code ObservableValue} holds this {@code ObservableValue}'s value, or > the given value if it is {@code null}. > > > Also not sure if the "More precisely" description is needed here. @nlisker @mstr2 I've done another pass, using all the suggestions, and also by looking closely at how things are worded in the documentation for Optional and Stream. This resulted in a few additional changes. I've left out the "more precisely" parts as I think we all agree it adds little extra value. Please have another look. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Mon Mar 21 09:07:41 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 21 Mar 2022 09:07:41 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v10] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Mon, 21 Mar 2022 09:01:01 GMT, John Hendrikx wrote: >> I read this comment after what I wrote about `flatMap`, so mstr2 also had the idea of "More precisely", which is good :) >> >> I would suggested something similar to what I did there: >> >> >> Creates a new {@code ObservableValue} that holds the value supplied by the given mapping function. The result >> is updated when this {@code ObservableValue} changes. >> If this value is {@code null}... >> More precisely, the created {@code ObservableValue} holds the result of applying a mapping on this >> {@code ObservableValue}'s value. >> >> >> Same comments about `@return` and `@throws` NPE as I had for `flatMap`. >> >> `orElse` will also becomes something like >> >> >> Creates a new {@code ObservableValue} that holds this value, or the given value if it is {@code null}. The >> result is updated when this {@code ObservableValue} changes. >> More precisely, the created {@code ObservableValue} holds this {@code ObservableValue}'s value, or >> the given value if it is {@code null}. >> >> >> Also not sure if the "More precisely" description is needed here. > > @nlisker @mstr2 I've done another pass, using all the suggestions, and also by looking closely at how things are worded in the documentation for Optional and Stream. This resulted in a few additional changes. I've left out the "more precisely" parts as I think we all agree it adds little extra value. Please have another look. I've changed the wording also to `Returns an` instead of `Creates an` or `Creates a new` -- I think we don't need to guarantee a new instance is always returned, just an instance that works as described (potentially cached or re-used). Stream and Optional word this similar. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Mon Mar 21 10:08:53 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 21 Mar 2022 10:08:53 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v11] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Fri, 18 Mar 2022 11:12:55 GMT, Tom Schindl wrote: >> John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: >> >> - Reword flat map docs a bit and fixed a link >> - Add missing javadoc tags >> - Clean up docs in Subscription >> - Fix code blocks >> - Add line feed at last line where it was missing > > modules/javafx.base/src/main/java/com/sun/javafx/binding/Subscription.java line 57: > >> 55: * Cancels this subscription. >> 56: */ >> 57: void unsubscribe(); > > to me `unsubscribe` feels not natural, I'm not unsubscribing a `Subscription` but I'm eg disposing it, hence to me `dispose` would feel better but I'm not a native speaker. > > Another pattern I see often is that I store a subscription in a field and recreate it under certain conditions: > > > private Subscription mySubscription; > > void refresh() { > if( this.mySubscription != null ) { > this.mySubscription.dispos(); > } > this.mySubscription = .... > } > > > if Subscription would provide > > ```java > static void dispose(Subscription subscription) { > if( subscription != null ) { > subscription.dispose(); > } > } > > > this would safe the user a null-check. This API is not going to be public for now, so we still have some time to work out the details. Another option would be to use `cancel` instead of `unsubscribe` or `dispose` (an internal class in the JDK uses `cancel`, reactfx uses `unsubcribe`). Subscription.dispose(subscription); I'm not sure how I feel about a helper method like that to do a `null` check; I feel that `null` checks are the callers responsibility (in almost all situations). It is also not really OO, it feels like `void *x = malloc(1000)` and `free(x)` instead of getting an object and calling `free` on the object. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Mon Mar 21 10:08:54 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 21 Mar 2022 10:08:54 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v10] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Sun, 20 Mar 2022 03:08:59 GMT, Nir Lisker wrote: >> Both seem fine, I don't have any preference over one or the other. > > I struggled with finding a good description here [previously](https://github.com/openjdk/jfx/pull/675#discussion_r777801130). I think that mstr2 gave a good approach. What we can do if we want to have "the best of both worlds" is to write something in this form: > > . More precisely, > > > I would offer something like this based on your suggestions: > > > Creates a new {@code ObservableValue} that holds the value of a nested {@code ObservableValue} supplied by the > given mapping function. The result is updated when either this or the nested {@code ObservableValue} changes. > If either this or the nested value is {@code null}, the resulting value is {@code null} (no mapping is applied if > this value is {@code null}). > More precisely, the created {@code ObservableValue} holds the value of an {@code ObservableValue} resulting > from applying a mapping on this {@code ObservableValue}'s value. > > I'm honestly not sure the "More precisely" part is even needed at his point. Up to you. > > The `@return` description can be changed accordingly with the simplified explanation if you think it's clearer. > > You can also specify a `@throws` NPE if the mapping function parameter is `null` instead of writing "cannot be null", like mstr2 suggested in another place if you like this pattern. > > By the way, if we change "Creates an..." to "Creates a new..." we should change it in the other methods. I don't think there's a difference. Resolving this one as we have this discussion elsewhere as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From mstrauss at openjdk.java.net Mon Mar 21 15:29:51 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 21 Mar 2022 15:29:51 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v13] In-Reply-To: <2vDciL-NbVzwJw6GKdXWLkx4l8ITs52aK9vShQhBL0g=.b19d64c2-79b1-401a-994d-3894bd4b8da2@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <2vDciL-NbVzwJw6GKdXWLkx4l8ITs52aK9vShQhBL0g=.b19d64c2-79b1-401a-994d-3894bd4b8da2@github.com> Message-ID: <0rZS-zDIl5rWi6CvR0iRYMaDiiP-YjbmlnZkeIosuDU=.29704035-0c32-416f-80e9-30005ecec9db@github.com> On Mon, 21 Mar 2022 08:59:34 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Small wording change in API of ObservableValue after proof reading Marked as reviewed by mstrauss (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From nlisker at openjdk.java.net Mon Mar 21 21:52:44 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 21 Mar 2022 21:52:44 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v13] In-Reply-To: <2vDciL-NbVzwJw6GKdXWLkx4l8ITs52aK9vShQhBL0g=.b19d64c2-79b1-401a-994d-3894bd4b8da2@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <2vDciL-NbVzwJw6GKdXWLkx4l8ITs52aK9vShQhBL0g=.b19d64c2-79b1-401a-994d-3894bd4b8da2@github.com> Message-ID: On Mon, 21 Mar 2022 08:59:34 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Small wording change in API of ObservableValue after proof reading modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 164: > 162: * @param mapper the mapping function to apply to a value, cannot be {@code null} > 163: * @return an {@code ObservableValue} that holds the result of applying the given > 164: * mapping function on its value, or {@code null} when it I think "on this value", not "on its value", no? ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From duke at openjdk.java.net Tue Mar 22 02:24:40 2022 From: duke at openjdk.java.net (yosbits) Date: Tue, 22 Mar 2022 02:24:40 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v13] In-Reply-To: <2vDciL-NbVzwJw6GKdXWLkx4l8ITs52aK9vShQhBL0g=.b19d64c2-79b1-401a-994d-3894bd4b8da2@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <2vDciL-NbVzwJw6GKdXWLkx4l8ITs52aK9vShQhBL0g=.b19d64c2-79b1-401a-994d-3894bd4b8da2@github.com> Message-ID: On Mon, 21 Mar 2022 08:59:34 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Small wording change in API of ObservableValue after proof reading I don't think the introduction effect explanation about Null Safe is accurate. Wouldn't using Optional solve this? ``` java void mapNestedValue() { // Standard JavaFX: label.textProperty().bind(Bindings.createStringBinding( () -> employee.get() == null ? "" : employee.get().getCompany() == null ? "" : employee.get().getCompany().getName(), employee )); // Standard JavaFX + Optional: label.textProperty().bind(Bindings.createStringBinding( Optinal.ofNullable(employee.get()) .map(Employee::getCompany) .map(Company::getName) .orElse(""), employee )); // Fluent: no need to handle nulls everywhere label.textProperty().bind( employee.map(Employee::getCompany) .map(Company::getName) .orElse("")) ); } Translated with www.DeepL.com/Translator (free version) ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Tue Mar 22 07:46:40 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Tue, 22 Mar 2022 07:46:40 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v14] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix wording ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/675/files - new: https://git.openjdk.java.net/jfx/pull/675/files/e09186ca..e2703e6b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/675/head:pull/675 PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Tue Mar 22 07:46:40 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Tue, 22 Mar 2022 07:46:40 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v13] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <2vDciL-NbVzwJw6GKdXWLkx4l8ITs52aK9vShQhBL0g=.b19d64c2-79b1-401a-994d-3894bd4b8da2@github.com> Message-ID: On Mon, 21 Mar 2022 21:49:33 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Small wording change in API of ObservableValue after proof reading > > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 164: > >> 162: * @param mapper the mapping function to apply to a value, cannot be {@code null} >> 163: * @return an {@code ObservableValue} that holds the result of applying the given >> 164: * mapping function on its value, or {@code null} when it > > I think "on this value", not "on its value", no? Yes, I fixed it. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Tue Mar 22 07:49:38 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Tue, 22 Mar 2022 07:49:38 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v13] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <2vDciL-NbVzwJw6GKdXWLkx4l8ITs52aK9vShQhBL0g=.b19d64c2-79b1-401a-994d-3894bd4b8da2@github.com> Message-ID: On Tue, 22 Mar 2022 02:21:05 GMT, yosbits wrote: > I think you are incorrect about the Null Safe explanation. Wouldn't using Optional solve this? I'm not sure what you are trying to say, the fluent bindings offered by this API are null safe. Using standard JavaFX you have to do additional work to deal with `null`. You are correct that you can use `Optional` to deal with `null`, but that's still additional work. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From arapte at openjdk.java.net Tue Mar 22 08:35:44 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 22 Mar 2022 08:35:44 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 02:20:11 GMT, Alexander Matveev wrote: >> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. >> - Added support for elementary AAC streams without any container for audio only streams. >> - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. >> - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/726 From jvos at openjdk.java.net Tue Mar 22 08:47:42 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 22 Mar 2022 08:47:42 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v2] In-Reply-To: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: > When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Add the option to shift all cells down in case the current calculations would lead to empty cells at the end of the view, while there are available cells before the beginning of the view. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/712/files - new: https://git.openjdk.java.net/jfx/pull/712/files/d1ab8afb..05935373 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=712&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=712&range=00-01 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712 From jvos at openjdk.java.net Tue Mar 22 08:57:40 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 22 Mar 2022 08:57:40 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] In-Reply-To: References: Message-ID: <8bPA4s_1MMsQZ3J4BWhOYT6SOiwcV9Cf997Kc40GSII=.62d5ec85-d42e-4519-ba62-78f68301816f@github.com> On Fri, 18 Mar 2022 02:20:11 GMT, Alexander Matveev wrote: >> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. >> - Added support for elementary AAC streams without any container for audio only streams. >> - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. >> - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] This looks really great. I'm doing a few more tests before approving, but I don't expect issues. I wonder if we can add some simple resources that allow testing the different protocols on different platforms? ------------- PR: https://git.openjdk.java.net/jfx/pull/726 From duke at openjdk.java.net Tue Mar 22 12:41:42 2022 From: duke at openjdk.java.net (yosbits) Date: Tue, 22 Mar 2022 12:41:42 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v14] In-Reply-To: <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> Message-ID: <8uSJmRppsPe1k8cFF32QA79OJnRwDQwbvmaRVONKqvw=.0f7436fb-9bd0-40f8-90b2-1ccb80544c9c@github.com> On Tue, 22 Mar 2022 07:46:40 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix wording This PR will take on multiple responsibilities, and will be a major step forward for the existing basic JavaFX class, ObservableValue. The balance between implementation complexity and convenience seems to be a point of contention. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Tue Mar 22 14:26:52 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Tue, 22 Mar 2022 14:26:52 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v14] In-Reply-To: <8uSJmRppsPe1k8cFF32QA79OJnRwDQwbvmaRVONKqvw=.0f7436fb-9bd0-40f8-90b2-1ccb80544c9c@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> <8uSJmRppsPe1k8cFF32QA79OJnRwDQwbvmaRVONKqvw=.0f7436fb-9bd0-40f8-90b2-1ccb80544c9c@github.com> Message-ID: On Tue, 22 Mar 2022 12:38:43 GMT, yosbits wrote: > This PR is considered a design change that delegates multiple responsibilities to the basic JavaFX class ObservableValue. The balance between implementation complexity and convenience seems to be a point of contention. If you could do a review and voice your concerns, I'd be happy to see if they can be addressed. I would also like to point out that it is an addition to the current API and does not affect any of the current ways of using JavaFX. In that regard it is like Streams and Optional, something you can choose not to use. I'm just not entirely sure what you want to say with your earlier example. If we remove null safety, then the example: label.textProperty().bind( employee.map(Employee::getCompany) .map(Company::getName) .orElse("") ); Would then be forced to become something like (or the `Optional` equivalent): label.textProperty().bind( employee.map(e -> e == null ? null : e.getCompany()) .map(c -> c == null ? "" : c.getName()) ); As JavaFX object properties can often be `null` and are `null` by default, this is a pretty easy way to get an NPE which I think would make sense to avoid. Also I'm unsure what you mean by implementation complexity, I think it is far less complex than some pieces of code I've seen in the JavaFX codebase (View classes, Layout code, Label reflow calculations) and I think is much better separated and structured than any of those. If you could point out any problems perhaps we can still address them. Excluding test code the change is really rather minimal, perhaps 200-300 actual lines of code. The most tricky part is perhaps the lazy binding aspect, but that's also the part that will offer the most convenience for users as there is no more need to rely on unpredictable weak bindings (a GC will not clean up bindings unexpectedly). ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From rlichten at openjdk.java.net Tue Mar 22 14:48:59 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Tue, 22 Mar 2022 14:48:59 GMT Subject: RFR: 8283509: Invisible menus can lead to IndexOutOfBoundsException Message-ID: findSibling adapted to only use visible menus when calculating the index. ------------- Commit messages: - 8283509: Invisible menus can lead to IndexOutOfBoundsException Changes: https://git.openjdk.java.net/jfx/pull/759/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=759&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283509 Stats: 33 lines in 2 files changed: 22 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/759.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/759/head:pull/759 PR: https://git.openjdk.java.net/jfx/pull/759 From duke at openjdk.java.net Tue Mar 22 17:09:51 2022 From: duke at openjdk.java.net (yosbits) Date: Tue, 22 Mar 2022 17:09:51 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v14] In-Reply-To: <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> Message-ID: On Tue, 22 Mar 2022 07:46:40 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix wording The reason I think the Null Safe explanation is incorrect is because In the interest of fairness, I feel it would be better to have an example of using the Optional API when comparing the existing way of writing to the new way of writing PR. I am not denying that PR's new code is simpler and easier to read. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From nlisker at openjdk.java.net Tue Mar 22 18:01:58 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 22 Mar 2022 18:01:58 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v14] In-Reply-To: <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> Message-ID: On Tue, 22 Mar 2022 07:46:40 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix wording Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From nlisker at openjdk.java.net Tue Mar 22 19:24:48 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 22 Mar 2022 19:24:48 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Thu, 18 Nov 2021 21:38:28 GMT, Kevin Rushforth wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > This will need an API review followed by an implementation review. @kevinrushforth This needs one more reviewer, it can be anyone, but I assume you want to review it. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From kcr at openjdk.java.net Tue Mar 22 20:20:54 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Mar 2022 20:20:54 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v14] In-Reply-To: <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> Message-ID: On Tue, 22 Mar 2022 07:46:40 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix wording Yes, I definitely want to be one of the reviewers. I'll need to review the CSR in any case. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Tue Mar 22 21:26:43 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Tue, 22 Mar 2022 21:26:43 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v14] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> Message-ID: <9LZCjiWl43UEPrGMDG4bDkc7bttaHIWNkePzWNChHic=.7d008abd-3d77-4f0b-9b31-0556f99e83ff@github.com> On Tue, 22 Mar 2022 17:06:12 GMT, yosbits wrote: > The reason I think the Null Safe explanation is incorrect is because In the interest of fairness, I feel it would be better to have an example of using the Optional API when comparing the existing way of writing to the new way of writing PR. No problem, I've added it -- I really wasn't attempting to make it look worse than it is, that's just how I would have written it I guess. They're also not going to be part of the documentation, just something I wrote up to introduce the PR. I sometimes do the trick with `Optional.ofNullable` as well. > I am not denying that PR's new code is simpler and easier to read. :) ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From michaelstrau2 at gmail.com Wed Mar 23 06:16:46 2022 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 23 Mar 2022 07:16:46 +0100 Subject: Promote addEventHandler/removeEventHandler to EventTarget interface In-Reply-To: <05b7dfbc-32bd-c288-0bc2-bf8cf3077551@gmail.com> References: <05b7dfbc-32bd-c288-0bc2-bf8cf3077551@gmail.com> Message-ID: I think defaulting to UnsupportedOperationException is a good choice. This shouldn't break existing usages of 3rd party implementations, since they wouldn't be calling those APIs anyway. On Fri, Mar 18, 2022 at 10:55 PM John Hendrikx wrote: > > [...] > EventTarget is already public API, and so there might be 3rd party > implementations. This means that the methods added to the EventTarget > interface must be default methods. It would be super if these default > implementations would just work out of the box, but that would require > exposing the internal class EventHandlerManager (and adding a > `getEventHandlerManager` to the `EventTarget` interface). If that's not > realistic, then initially the default implementations would have to > throw UnsupportedOperationException. > > --John > From jvos at openjdk.java.net Wed Mar 23 07:39:40 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 23 Mar 2022 07:39:40 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 02:20:11 GMT, Alexander Matveev wrote: >> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. >> - Added support for elementary AAC streams without any container for audio only streams. >> - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. >> - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/726 From mhanl at openjdk.java.net Wed Mar 23 08:24:40 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 23 Mar 2022 08:24:40 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling In-Reply-To: References: Message-ID: <9P_tyGj23Lk5yr6y-QLIbpQU3BxzuOk54VJItMYI-8g=.de86f0fc-5092-4749-a6e7-a0c0ffa3dc62@github.com> On Wed, 16 Mar 2022 08:20:59 GMT, Robert Lichtenberger wrote: > This fix respects a row factory, if present. > It will put the cell that is used to measure the column width as child below the row. > In that way the row's style will be used. The approach looks good. I left some comments and questions modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 650: > 648: } > 649: Callback, TableRow> rowFactory = tv.getRowFactory(); > 650: TableRow tableRow = rowFactory != null ? rowFactory.call(tv) : new TableRow<>(); When there is no row factory, we probably should just return like in line 632-633? modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 653: > 651: tableSkin.getChildren().add(tableRow); > 652: tableRow.applyCss(); > 653: ((SkinBase) tableRow.getSkin()).getChildren().add(cell); I don't think this is a safe cast. Instead, you probably should do an `instanceof SkinBase` check before modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 667: > 665: if ((cell.getText() != null && !cell.getText().isEmpty()) || cell.getGraphic() != null) { > 666: tableRow.applyCss(); > 667: cell.applyCss(); Just wondering: Is `cell.applyCss();` still needed here? modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 259: > 257: /** > 258: * @test > 259: * @bug 8251480 Row style must affect the required column width This annotations are not needed, although they do not hurt (just a note) ------------- Changes requested by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/757 From mhanl at openjdk.java.net Wed Mar 23 09:16:36 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 23 Mar 2022 09:16:36 GMT Subject: RFR: 8281723: Spinner with split horizontal arrows and a border places right arrow incorrectly [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 07:48:53 GMT, John Hendrikx wrote: >> I added a test case for `SpinnerSkin` that checks the arrow positioning. >> >> While adding the tests I discovered more problems with the positioning aside from the one mentioned in the JBS ticket. >> >> 1) Vertical split arrow placement also forgot to take the padding into account while placing the decrement arrow button -- I've taken the liberty to fix that problem as well in the same PR. >> >> 2) When arrows are placed next to each other either on the right or left, the arrow widths are not normalized to be the width of the widest arrow. All other placements will normalize either the width or height, except for these two. Specifically, when the arrows are **split** on the left and right they **are** normalized to the same width. >> >> For point 2, here is the problem illustrated with actual widths on left and layout result on right: >> >> [ <----- ] [ -> ] [ spinner ] --> [ <----- ] [ -> ] [ spinner ] >> [ spinner ] [ <----- ] [ -> ] --> [ spinner ] [ <----- ] [ -> ] >> >> While for split horizontal it does normalize the width to that of the widest arrow, and so layout becomes: >> >> [ <----- ] [ spinner ] [ -> ] --> [ <----- ] [ spinner ] [ -> ] >> >> While I'm here I could fix this as well, and adjust the test case to match. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Fix + Tests look good to me ------------- Marked as reviewed by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/748 From kcr at openjdk.java.net Wed Mar 23 12:20:41 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 23 Mar 2022 12:20:41 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 02:20:11 GMT, Alexander Matveev wrote: >> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. >> - Added support for elementary AAC streams without any container for audio only streams. >> - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. >> - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/726 From kcr at openjdk.java.net Wed Mar 23 12:20:41 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 23 Mar 2022 12:20:41 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] In-Reply-To: <8bPA4s_1MMsQZ3J4BWhOYT6SOiwcV9Cf997Kc40GSII=.62d5ec85-d42e-4519-ba62-78f68301816f@github.com> References: <8bPA4s_1MMsQZ3J4BWhOYT6SOiwcV9Cf997Kc40GSII=.62d5ec85-d42e-4519-ba62-78f68301816f@github.com> Message-ID: On Tue, 22 Mar 2022 08:54:45 GMT, Johan Vos wrote: > I wonder if we can add some simple resources that allow testing the different protocols on different platforms? I can't think of a good way to do that, especially for this feature, since it requires a web server. ------------- PR: https://git.openjdk.java.net/jfx/pull/726 From daniel.peintner at gmail.com Wed Mar 23 16:11:55 2022 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Wed, 23 Mar 2022 17:11:55 +0100 Subject: Question about fatal JavaFX crashes In-Reply-To: <1CB8A4C6-EC35-4D87-9ACA-C85C92F54CC6@gmail.com> References: <3ab2cd84-a32d-905e-be47-d72df7a99099@oracle.com> <1CB8A4C6-EC35-4D87-9ACA-C85C92F54CC6@gmail.com> Message-ID: All, Thank you very much for all the comments/suggestions. I have been learning a lot about JVM C2 compilation the last couple of days. BTW, in the meanwhile a similar bug has been reported with Debian Linux and has been added to https://bugs.openjdk.java.net/browse/JDK-828338 . I would like to briefly summarize what my solution is for the time being. Since in my case stability is *much* more important than speed I used a rather radical approach to prohibit C2 to do any *aggressive* optimization. -XX:+TieredCompilation (enable C1) -XX:TieredStopAtLevel=1 (disable C2) It seems somewhat similar to the out-dated "-client" option. The application didn't really feel any slower. However, that certainly depends heavily on the use case. Note: I very much look forward to the day the GraalVM compiler gets the default. Hope this might be useful for others. Thanks, -- Daniel On Fri, Mar 18, 2022 at 11:10 PM Scott Palmer wrote: > I wonder, could you do the opposite and force compilation to trigger the > bug more consistently? > > Scott > > > On Mar 18, 2022, at 2:03 PM, Philip Race wrote: > > > > ?I have at least seen JIT compiler crashes like this in other unrelated > cases .. > > > > in theory you can use an option like > > > > -XX:CompileCommand=exclude,javafx/scene/control/TableView$5::onChanged > > > > although I am very unsure about the syntax for the last part of it > especially with what looks like > > some anonymous method or lambda expression. I can almost guarantee that > my example is wrong. > > > > Excluding the whole of TableView might be easier to specify but will > slow you down a lot. > > > > -phil. > > > > > >> On 3/18/22 10:37 AM, Kevin Rushforth wrote: > >> Thanks, Phil. That was my take as well. I don't see how this can be a > JavaFX bug given where it is crashing. FWIW, I haven't ever seen anything > like this. > >> > >> -- Kevin > >> > >> > >>> On 3/18/2022 10:25 AM, Philip Race wrote: > >>> I think it is probable that this is a hotspot VM problem in the C2 JIT > compiler code. > >>> > >>> I've moved your bug report to hotspot : > https://bugs.openjdk.java.net/browse/JDK-8283386 > >>> The interesting question isn't about which version of FX used to work. > >>> It is what was the last working version of the JDK. > >>> It looks a bit like a JDK 17 bug from the evidence so far so if > >>> you were running FX 17 on JDK 17 GA you maybe have picked up a later > update release of JDK 17 along with FX 18 ?? > >>> > >>> Regardless this doesn't look like an FX bug. > >>> But unless you can actually provide a test case, or, by luck the > hotspot folks recognise the issue, > >>> I don't know what can/will happen. > >>> > >>> -phil. > >>> > >>> On 3/18/22 7:08 AM, Daniel Peintner wrote: > >>>> Hi John, all, > >>>> > >>>> Thanks for your detailed reply. > >>>> I submitted a bug report with detailed information. > >>>> > >>>> - Run a different Java version > >>>> I tried different versions and vendors with the same result. > >>>> * OpenJDK 17.0.1 > >>>> * Zulu 17.0.2 > >>>> * I wanted to check also JDK18-ea but gradle does not yet support it > >>>> > >>>> > >>>>> - Try switching to a different GC > >>>>> - Use different VM options (are you using anything special?) > >>>>> - Anything else that is not often used, non-standard or experimental, > >>>>> try going to a more common setup > >>>>> > >>>> I use no specific setting, all is default. > >>>> I have been reading that the -client flag might help in some cases but > >>>> unfortunately this flag is no longer taken into account for 64bit > JVMS. > >>>> > >>>> Thanks, > >>>> > >>>> -- Daniel > >>>> > >>>> > >>>> > >>>> > >>>>> --John > >>>>> > >>>>> On 18/03/2022 09:43, Daniel Peintner wrote: > >>>>>> Hello, > >>>>>> > >>>>>> I take the liberty to ask on the email reflector if there are other > >>>>> people > >>>>>> with similar problems. > >>>>>> > >>>>>> Since updating my application to JavaFX18 I get random fatal > crashes. > >>>>>> Unfortunately it is not predictable but after some time the app > crashes > >>>>>> with "EXCEPTION_ACCESS_VIOLATION". > >>>>>> > >>>>>> The hs_error_pidX reports the following. > >>>>>> > >>>>>> > >>>>>> --------------- T H R E A D --------------- > >>>>>> > >>>>>> Current thread (0x0000016be9c9b410): JavaThread "C2 > CompilerThread0" > >>>>>> daemon [_thread_in_native, id=3068, > >>>>>> stack(0x000000393e800000,0x000000393e900000)] > >>>>>> > >>>>>> Current CompileTask: > >>>>>> C2:10515286 18185 4 > >>>>> javafx.scene.control.TableView$5::onChanged > >>>>>> (1049 bytes) > >>>>>> > >>>>>> > >>>>>> Am I the only one seeing this? > >>>>>> I am not sure if this relates to changing JavaFX 17 to 18 or > whether it > >>>>>> makes it just more likely. > >>>>>> > >>>>>> It seems to be related to > "javafx.scene.control.TableView$5::onChanged" > >>>>>> since all crashes show this line. > >>>>>> > >>>>>> Having said that, I cannot provide a test-case since it happens all > of a > >>>>>> sudden and sometimes after hours using the application. > >>>>>> > >>>>>> I am open to any feedback or input on how to proceed best. > >>>>>> > >>>>>> Thanks! > >>>>>> > >>>>>> -- Daniel > >>> > >> > > > From almatvee at openjdk.java.net Wed Mar 23 20:47:56 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 23 Mar 2022 20:47:56 GMT Subject: Integrated: 8277309: Add support for H.265/HEVC to HTTP Live Streaming In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 11:24:48 GMT, Alexander Matveev wrote: > - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. > - Added support for elementary AAC streams without any container for audio only streams. > - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. > - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. This pull request has now been integrated. Changeset: 424aebae Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/424aebae8f28d0c75caa3281a3e5d6a7ede86a8a Stats: 2690 lines in 29 files changed: 2384 ins; 137 del; 169 mod 8277309: Add support for H.265/HEVC to HTTP Live Streaming Reviewed-by: kcr, arapte, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/726 From swpalmer at gmail.com Thu Mar 24 03:01:50 2022 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 23 Mar 2022 23:01:50 -0400 Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] In-Reply-To: References: <8bPA4s_1MMsQZ3J4BWhOYT6SOiwcV9Cf997Kc40GSII=.62d5ec85-d42e-4519-ba62-78f68301816f@github.com> Message-ID: <65983B2D-0B58-478D-8DA3-8167AA35ABAA@gmail.com> On Mar 23, 2022, at 8:20 AM, Kevin Rushforth wrote: > > On Tue, 22 Mar 2022 08:54:45 GMT, Johan Vos wrote: > >> I wonder if we can add some simple resources that allow testing the different protocols on different platforms? > > I can't think of a good way to do that, especially for this feature, since it requires a web server. Just wondering why that?s an issue, specifically for HLS. Java?s built-in web server, the old one at com.sun.net.httpserver.HttpServer (i.e. it wouldn?t need JDK 18), would work fine. E.g. something not much more complicated than: int port = 8888; Path testFilesRoot = Paths.get("media"); HttpServer server = HttpServer.create(new InetSocketAddress(port), 0); server.createContext("/hls", new HttpHandler() { @Override public void handle(HttpExchange exchange) throws IOException { Path path = Paths.get(exchange.getRequestURI().getPath()).getFileName(); boolean isPlaylist = path.endsWith(".m3u8"); boolean isTS = path.endsWith(".ts"); Path assetPath = testFilesRoot.resolve(path); byte[] data = Files.readAllBytes(assetPath); exchange.getResponseHeaders().add("Content-Type", isPlaylist ? "application/x-mpegURL" : isTS ? "video/MP2T" : "video/mp4"); exchange.sendResponseHeaders(200, data.length); OutputStream os = exchange.getResponseBody(); os.write(data); os.close(); } }); server.start(); The content would all be short static test files, easily fitting in the byte array. You could grab something from a public domain source (just edit the paths in the .m3u8 files as needed) Cheers, Scott From rlichten at openjdk.java.net Thu Mar 24 05:01:07 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 24 Mar 2022 05:01:07 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling In-Reply-To: <9P_tyGj23Lk5yr6y-QLIbpQU3BxzuOk54VJItMYI-8g=.de86f0fc-5092-4749-a6e7-a0c0ffa3dc62@github.com> References: <9P_tyGj23Lk5yr6y-QLIbpQU3BxzuOk54VJItMYI-8g=.de86f0fc-5092-4749-a6e7-a0c0ffa3dc62@github.com> Message-ID: On Wed, 23 Mar 2022 08:19:41 GMT, Marius Hanl wrote: >> This fix respects a row factory, if present. >> It will put the cell that is used to measure the column width as child below the row. >> In that way the row's style will be used. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 650: > >> 648: } >> 649: Callback, TableRow> rowFactory = tv.getRowFactory(); >> 650: TableRow tableRow = rowFactory != null ? rowFactory.call(tv) : new TableRow<>(); > > When there is no row factory, we probably should just return like in line 632-633? Unlike cell factory, which always has to be present, the row factory is optional and in fact most tables will not have a row factory. If we return in that case, the algorithm will no longer work for these tables. Compare with `javafx.scene.control.skin.TableViewSkin.createCell()`. ------------- PR: https://git.openjdk.java.net/jfx/pull/757 From rlichten at openjdk.java.net Thu Mar 24 05:10:58 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 24 Mar 2022 05:10:58 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling In-Reply-To: <9P_tyGj23Lk5yr6y-QLIbpQU3BxzuOk54VJItMYI-8g=.de86f0fc-5092-4749-a6e7-a0c0ffa3dc62@github.com> References: <9P_tyGj23Lk5yr6y-QLIbpQU3BxzuOk54VJItMYI-8g=.de86f0fc-5092-4749-a6e7-a0c0ffa3dc62@github.com> Message-ID: <78p019qbxpkA7lSS5fm9X30j-20dwV1mheTa7HgsUmo=.ca4714cf-7f18-4a4d-82f7-82d46d4f318e@github.com> On Wed, 23 Mar 2022 08:17:38 GMT, Marius Hanl wrote: >> This fix respects a row factory, if present. >> It will put the cell that is used to measure the column width as child below the row. >> In that way the row's style will be used. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 653: > >> 651: tableSkin.getChildren().add(tableRow); >> 652: tableRow.applyCss(); >> 653: ((SkinBase) tableRow.getSkin()).getChildren().add(cell); > > I don't think this is a safe cast. Instead, you probably should do an `instanceof SkinBase` check before You're right. A tablerow may have been created that returns a custom skin which is not necessarily derived from SkinBase. However, since we do not have a getChildren() method in such a custom skin we will be unable to proceed. We could now abandon altogether (another return) but that mean that resizeColumnToFitContent no longer works at all in the presence of custom rows. So I think the best solution in that case would be to ignore the rowFactory and use a default `new TableRow<>` again to preserve at least the old behaviour in such cases. I'll try and improve the patch. ------------- PR: https://git.openjdk.java.net/jfx/pull/757 From rlichten at openjdk.java.net Thu Mar 24 05:34:07 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 24 Mar 2022 05:34:07 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling In-Reply-To: <9P_tyGj23Lk5yr6y-QLIbpQU3BxzuOk54VJItMYI-8g=.de86f0fc-5092-4749-a6e7-a0c0ffa3dc62@github.com> References: <9P_tyGj23Lk5yr6y-QLIbpQU3BxzuOk54VJItMYI-8g=.de86f0fc-5092-4749-a6e7-a0c0ffa3dc62@github.com> Message-ID: On Wed, 23 Mar 2022 08:15:47 GMT, Marius Hanl wrote: >> This fix respects a row factory, if present. >> It will put the cell that is used to measure the column width as child below the row. >> In that way the row's style will be used. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 667: > >> 665: if ((cell.getText() != null && !cell.getText().isEmpty()) || cell.getGraphic() != null) { >> 666: tableRow.applyCss(); >> 667: cell.applyCss(); > > Just wondering: Is `cell.applyCss();` still needed here? Right, this is no longer needed. I'll remove it. ------------- PR: https://git.openjdk.java.net/jfx/pull/757 From rlichten at openjdk.java.net Thu Mar 24 06:14:42 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 24 Mar 2022 06:14:42 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling [v2] In-Reply-To: References: Message-ID: <1JgmHbMwKpo3XzZcstu_AQT1Bk79y18RX26BR8d5ulQ=.08c710f0-3aae-495a-9c64-e56cd2625e77@github.com> > This fix respects a row factory, if present. > It will put the cell that is used to measure the column width as child below the row. > In that way the row's style will be used. Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: 8251480: TableColumnHeader: calc of cell width must respect row styling Old behaviour restored for table rows with custom skins. Unnecessary call to cell.applyCss() removed. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/757/files - new: https://git.openjdk.java.net/jfx/pull/757/files/08851726..af582570 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=757&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=757&range=00-01 Stats: 74 lines in 2 files changed: 65 ins; 6 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/757.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/757/head:pull/757 PR: https://git.openjdk.java.net/jfx/pull/757 From aghaisas at openjdk.java.net Thu Mar 24 07:13:51 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 24 Mar 2022 07:13:51 GMT Subject: RFR: 8281723: Spinner with split horizontal arrows and a border places right arrow incorrectly [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 07:48:53 GMT, John Hendrikx wrote: >> I added a test case for `SpinnerSkin` that checks the arrow positioning. >> >> While adding the tests I discovered more problems with the positioning aside from the one mentioned in the JBS ticket. >> >> 1) Vertical split arrow placement also forgot to take the padding into account while placing the decrement arrow button -- I've taken the liberty to fix that problem as well in the same PR. >> >> 2) When arrows are placed next to each other either on the right or left, the arrow widths are not normalized to be the width of the widest arrow. All other placements will normalize either the width or height, except for these two. Specifically, when the arrows are **split** on the left and right they **are** normalized to the same width. >> >> For point 2, here is the problem illustrated with actual widths on left and layout result on right: >> >> [ <----- ] [ -> ] [ spinner ] --> [ <----- ] [ -> ] [ spinner ] >> [ spinner ] [ <----- ] [ -> ] --> [ spinner ] [ <----- ] [ -> ] >> >> While for split horizontal it does normalize the width to that of the widest arrow, and so layout becomes: >> >> [ <----- ] [ spinner ] [ -> ] --> [ <----- ] [ spinner ] [ -> ] >> >> While I'm here I could fix this as well, and adjust the test case to match. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year The fix looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/748 From jvos at openjdk.java.net Thu Mar 24 10:06:34 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 24 Mar 2022 10:06:34 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v3] In-Reply-To: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: > When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Add test to check if there are no empty cells at the end of a List in case there are enough leading cells available. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/712/files - new: https://git.openjdk.java.net/jfx/pull/712/files/05935373..a931ba75 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=712&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=712&range=01-02 Stats: 35 lines in 1 file changed: 35 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712 From jvos at openjdk.java.net Thu Mar 24 10:06:35 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 24 Mar 2022 10:06:35 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v2] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: On Tue, 22 Mar 2022 08:47:42 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Add the option to shift all cells down in case the current calculations would lead to empty cells at the end of the view, > while there are available cells before the beginning of the view. There was a problem in ListView, in which cells are shifted down in case there are empty cells being rendered while there are leading cells available. I also added a testcase for this that fails before and succeeds after. ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From kcr at openjdk.java.net Thu Mar 24 12:25:51 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Mar 2022 12:25:51 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 02:20:11 GMT, Alexander Matveev wrote: >> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. >> - Added support for elementary AAC streams without any container for audio only streams. >> - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. >> - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] Interesting idea. Btw, we don't have any media tests at all in our repo at present, so there is a more basic issue that would need to be solved. We could file an RFE, but there are some challenges in doing anything that is useful enough to justify the effort. ------------- PR: https://git.openjdk.java.net/jfx/pull/726 From kcr at openjdk.java.net Fri Mar 25 12:22:13 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Mar 2022 12:22:13 GMT Subject: RFR: 8283517: Update boot JDK to 18 Message-ID: JDK 18 has been released, so we should update the default boot JDK used to build JavaFX to JDK 18. This will not affect the minimum boot JDK version. I have confirmed that gradle 7.3 works with JDK 18, so we don't need to update gradle at this time. I have done a full set of tests on all three platforms. ------------- Commit messages: - 8283517: Update boot JDK to 18 Changes: https://git.openjdk.java.net/jfx/pull/760/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=760&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283517 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/760.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/760/head:pull/760 PR: https://git.openjdk.java.net/jfx/pull/760 From kcr at openjdk.java.net Fri Mar 25 12:26:12 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Mar 2022 12:26:12 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux Message-ID: This patch updates the compiler to gcc 10.3 on Linux, in order to match JDK 17 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). I ran a full build and test, including media and WebKit. ------------- Commit messages: - 8283402: Update to gcc 11.2 on Linux Changes: https://git.openjdk.java.net/jfx/pull/761/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=761&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283402 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/761.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/761/head:pull/761 PR: https://git.openjdk.java.net/jfx/pull/761 From kcr at openjdk.java.net Fri Mar 25 12:34:55 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Mar 2022 12:34:55 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux In-Reply-To: References: Message-ID: <3OW97-UmsNExcXfRT0g2ENSXAHMS5ryUaMuhp5CqGOE=.66978ec6-8757-4b57-8955-a961ca4dac9b@github.com> On Fri, 25 Mar 2022 12:19:10 GMT, Kevin Rushforth wrote: > This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK 17 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). > > I ran a full build and test, including media and WebKit. > This patch updates the compiler to gcc 10.3 Copy/paste error. That should be 11.2 (I updated the Description). ------------- PR: https://git.openjdk.java.net/jfx/pull/761 From kcr at openjdk.java.net Fri Mar 25 16:30:05 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Mar 2022 16:30:05 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v3] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: <2GwIXxxLw9VG_s2vTawYLiIVkHpeoo1_LjRHDIqwhWM=.98d4301f-c0fb-411d-9740-8ada34c873dd@github.com> On Thu, 24 Mar 2022 10:06:34 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Add test to check if there are no empty cells at the end of a List in case there are enough leading cells available. It looks like there are some failing unit tests now. ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From duke at openjdk.java.net Fri Mar 25 18:35:08 2022 From: duke at openjdk.java.net (Glavo) Date: Fri, 25 Mar 2022 18:35:08 GMT Subject: RFR: 8280369: native library cache should be platform/arch specific Message-ID: Currently, OpenJFX extracts the native library into a local folder and loads it when it is not part of the JRE. Now we have a notable problem with the fact that a platform may actually run programs of multiple CPU architectures. Most commonly, 32-bit x86 applications can be executed on Windows AMD64. In addition to this, ARM machines may also execute AMD64 programs by transpiling. For OpenJFX of different architectures on the same system, their native libraries have the same file name, but their contents are different. Since they will try to unpack the native library into the same folder, this will cause file conflicts. A practical example is when I run the same JavaFX application with both 32-bit and 64-bit Java on a Windows AMD64 platform, and the application that starts later crashes because it cannot unzip the native libraries: Crash logs (The length exceeds the GitHub limit): https://paste.ubuntu.com/p/NZBK3pNrh7/ Here I avoid the problem by adding `os.arch` to the cache path. I ran the tests on Ubuntu 20.04 after the modification and no tests were broken. ------------- Commit messages: - Cache native libraries with architecture-dependent paths Changes: https://git.openjdk.java.net/jfx/pull/762/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=762&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280369 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/762.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/762/head:pull/762 PR: https://git.openjdk.java.net/jfx/pull/762 From kcr at openjdk.java.net Fri Mar 25 20:57:55 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Mar 2022 20:57:55 GMT Subject: RFR: 8280369: native library cache should be platform/arch specific In-Reply-To: References: Message-ID: <5ycYH5hcPkD5y4e3tfUw0RHjxrbob39aIon4l4ZPppk=.46baa128-f68d-42c3-9c8e-81701056835a@github.com> On Fri, 25 Mar 2022 18:12:23 GMT, Glavo wrote: > Currently, OpenJFX extracts the native library into a local folder and loads it when it is not part of the JRE. > > Now we have a notable problem with the fact that a platform may actually run programs of multiple CPU architectures. > > Most commonly, 32-bit x86 applications can be executed on Windows AMD64. In addition to this, ARM machines may also execute AMD64 programs by transpiling. > > For OpenJFX of different architectures on the same system, their native libraries have the same file name, but their contents are different. Since they will try to unpack the native library into the same folder, this will cause file conflicts. > > A practical example is when I run the same JavaFX application with both 32-bit and 64-bit Java on a Windows AMD64 platform, and the application that starts later crashes because it cannot unzip the native libraries: > > Crash logs (The length exceeds the GitHub limit): https://paste.ubuntu.com/p/NZBK3pNrh7/ > > Here I avoid the problem by adding `os.arch` to the cache path. > > I ran the tests on Ubuntu 20.04 after the modification and no tests were broken. This looks fine to me, but @johanvos or @tiainen will want to test it. ------------- PR: https://git.openjdk.java.net/jfx/pull/762 From perini.davide at dpsoftware.org Sun Mar 27 14:07:53 2022 From: perini.davide at dpsoftware.org (Davide Perini) Date: Sun, 27 Mar 2022 16:07:53 +0200 Subject: Is it wise to use JavaFX 18 with JDK 17? Message-ID: Hi all, is it wise to use JavaFX 18 with JDK 17? Is there any particular reasons why not to use a "newer JavaFX" version with an "older JDK"? Where can I see what are the supported JDK for the JavaFX version I'm running? Thank you! Davide From zjx001202 at gmail.com Sun Mar 27 15:00:12 2022 From: zjx001202 at gmail.com (Glavo) Date: Sun, 27 Mar 2022 23:00:12 +0800 Subject: Is it wise to use JavaFX 18 with JDK 17? In-Reply-To: References: Message-ID: Currently, all separately distributed OpenJFX are Java 11 compatible. I don't think there is a strong correlation between the Java version and the OpenJFX version, it's always better to use a newer OpenJFX. On Sun, Mar 27, 2022 at 10:08 PM Davide Perini wrote: > Hi all, > is it wise to use JavaFX 18 with JDK 17? > > Is there any particular reasons why not to use a "newer JavaFX" version > with an "older JDK"? > > Where can I see what are the supported JDK for the JavaFX version I'm > running? > > Thank you! > Davide > From mhanl at openjdk.java.net Mon Mar 28 09:22:49 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Mon, 28 Mar 2022 09:22:49 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling [v2] In-Reply-To: References: <9P_tyGj23Lk5yr6y-QLIbpQU3BxzuOk54VJItMYI-8g=.de86f0fc-5092-4749-a6e7-a0c0ffa3dc62@github.com> Message-ID: On Thu, 24 Mar 2022 04:57:27 GMT, Robert Lichtenberger wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 650: >> >>> 648: } >>> 649: Callback, TableRow> rowFactory = tv.getRowFactory(); >>> 650: TableRow tableRow = rowFactory != null ? rowFactory.call(tv) : new TableRow<>(); >> >> When there is no row factory, we probably should just return like in line 632-633? > > Unlike cell factory, which always has to be present, the row factory is optional and in fact most tables will not have a row factory. If we return in that case, the algorithm will no longer work for these tables. > Compare with `javafx.scene.control.skin.TableViewSkin.createCell()`. You are right, thanks. ------------- PR: https://git.openjdk.java.net/jfx/pull/757 From kevin.rushforth at oracle.com Mon Mar 28 12:37:41 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 28 Mar 2022 05:37:41 -0700 Subject: Is it wise to use JavaFX 18 with JDK 17? In-Reply-To: References: Message-ID: Given that JavaFX is unbundled, and that JavaFX N released at or slightly before the JDK N, you can always use JavaFX N with JDK N-1 or later. We haven't bumped the minimum JDK version needed to run JavaFX for quite some time, which as noted, remains at JDK 11. I expect we will change the minimum to JDK 17 at some point in the not-too-distant future, in order to take advantage of JDK features added between JDK 12 and JDK 17. As for how to know which version of JDK a particular version of JavaFX runs on, check out the release notes for that release. Here is the one for JavaFX 18: https://github.com/openjdk/jfx/tree/jfx18/doc-files/release-notes-18.md In the Introduction you will see "JavaFX 18 requires JDK 11 or later." -- Kevin On 3/27/2022 8:00 AM, Glavo wrote: > Currently, all separately distributed OpenJFX are Java 11 compatible. > > I don't think there is a strong correlation between the Java version and > the OpenJFX version, it's always better to use a newer OpenJFX. > > On Sun, Mar 27, 2022 at 10:08 PM Davide Perini > wrote: > >> Hi all, >> is it wise to use JavaFX 18 with JDK 17? >> >> Is there any particular reasons why not to use a "newer JavaFX" version >> with an "older JDK"? >> >> Where can I see what are the supported JDK for the JavaFX version I'm >> running? >> >> Thank you! >> Davide >> From arapte at openjdk.java.net Mon Mar 28 13:29:55 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 28 Mar 2022 13:29:55 GMT Subject: RFR: 8283517: Update boot JDK to 18 In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 12:16:18 GMT, Kevin Rushforth wrote: > JDK 18 has been released, so we should update the default boot JDK used to build JavaFX to JDK 18. This will not affect the minimum boot JDK version. I have confirmed that gradle 7.3 works with JDK 18, so we don't need to update gradle at this time. > > I have done a full set of tests on all three platforms. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/760 From arapte at openjdk.java.net Mon Mar 28 13:57:56 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 28 Mar 2022 13:57:56 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 12:19:10 GMT, Kevin Rushforth wrote: > This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK 17 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). > > I ran a full build and test, including media and WebKit. I shall do a test build and update. ------------- PR: https://git.openjdk.java.net/jfx/pull/761 From jvos at openjdk.java.net Tue Mar 29 09:14:00 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 29 Mar 2022 09:14:00 GMT Subject: RFR: 8280369: native library cache should be platform/arch specific In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 18:12:23 GMT, Glavo wrote: > Currently, OpenJFX extracts the native library into a local folder and loads it when it is not part of the JRE. > > Now we have a notable problem with the fact that a platform may actually run programs of multiple CPU architectures. > > Most commonly, 32-bit x86 applications can be executed on Windows AMD64. In addition to this, ARM machines may also execute AMD64 programs by transpiling. > > For OpenJFX of different architectures on the same system, their native libraries have the same file name, but their contents are different. Since they will try to unpack the native library into the same folder, this will cause file conflicts. > > A practical example is when I run the same JavaFX application with both 32-bit and 64-bit Java on a Windows AMD64 platform, and the application that starts later crashes because it cannot unzip the native libraries: > > Crash logs (The length exceeds the GitHub limit): https://paste.ubuntu.com/p/NZBK3pNrh7/ > > Here I avoid the problem by adding `os.arch` to the cache path. > > I ran the tests on Ubuntu 20.04 after the modification and no tests were broken. This looks good, and I can't see possible regression (e.g. issues with non-existing parent directories, or files that have the same name as the directory that will be created by this PR). It is indeed very useful given the increase in potential architectures. I'm doing a few more automatic tests before approving. ------------- PR: https://git.openjdk.java.net/jfx/pull/762 From aghaisas at openjdk.java.net Tue Mar 29 09:26:54 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 29 Mar 2022 09:26:54 GMT Subject: RFR: 8283509: Invisible menus can lead to IndexOutOfBoundsException In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 14:42:07 GMT, Robert Lichtenberger wrote: > findSibling adapted to only use visible menus when calculating the > index. Have you considered keeping the same while loop in findSibling() method and skipping invisible Menus in it? This is to avoid creating and traversing a new list. ------------- PR: https://git.openjdk.java.net/jfx/pull/759 From jvos at openjdk.java.net Tue Mar 29 09:45:50 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 29 Mar 2022 09:45:50 GMT Subject: RFR: 8280369: native library cache should be platform/arch specific In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 18:12:23 GMT, Glavo wrote: > Currently, OpenJFX extracts the native library into a local folder and loads it when it is not part of the JRE. > > Now we have a notable problem with the fact that a platform may actually run programs of multiple CPU architectures. > > Most commonly, 32-bit x86 applications can be executed on Windows AMD64. In addition to this, ARM machines may also execute AMD64 programs by transpiling. > > For OpenJFX of different architectures on the same system, their native libraries have the same file name, but their contents are different. Since they will try to unpack the native library into the same folder, this will cause file conflicts. > > A practical example is when I run the same JavaFX application with both 32-bit and 64-bit Java on a Windows AMD64 platform, and the application that starts later crashes because it cannot unzip the native libraries: > > Crash logs (The length exceeds the GitHub limit): https://paste.ubuntu.com/p/NZBK3pNrh7/ > > Here I avoid the problem by adding `os.arch` to the cache path. > > I ran the tests on Ubuntu 20.04 after the modification and no tests were broken. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/762 From jvos at openjdk.java.net Tue Mar 29 09:45:54 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 29 Mar 2022 09:45:54 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 12:19:10 GMT, Kevin Rushforth wrote: > This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK 17 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). > > I ran a full build and test, including media and WebKit. .github/workflows/submit.yml line 86: > 84: set -x > 85: sudo apt-get update > 86: sudo apt-get install libgl1-mesa-dev libx11-dev libxxf86vm-dev libxt-dev pkg-config libgtk2.0-dev libgtk-3-dev libxtst-dev gcc-11 g++-11 Did this install 11.2? The CI is using Focal, and afaik there is no gcc-11.2 for focal? ------------- PR: https://git.openjdk.java.net/jfx/pull/761 From jvos at openjdk.java.net Tue Mar 29 09:46:55 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 29 Mar 2022 09:46:55 GMT Subject: RFR: 8283517: Update boot JDK to 18 In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 12:16:18 GMT, Kevin Rushforth wrote: > JDK 18 has been released, so we should update the default boot JDK used to build JavaFX to JDK 18. This will not affect the minimum boot JDK version. I have confirmed that gradle 7.3 works with JDK 18, so we don't need to update gradle at this time. > > I have done a full set of tests on all three platforms. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/760 From kcr at openjdk.java.net Tue Mar 29 11:54:09 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Mar 2022 11:54:09 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 09:42:38 GMT, Johan Vos wrote: >> This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK 17 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). >> >> I ran a full build and test, including media and WebKit. > > .github/workflows/submit.yml line 86: > >> 84: set -x >> 85: sudo apt-get update >> 86: sudo apt-get install libgl1-mesa-dev libx11-dev libxxf86vm-dev libxt-dev pkg-config libgtk2.0-dev libgtk-3-dev libxtst-dev gcc-11 g++-11 > > Did this install 11.2? The CI is using Focal, and afaik there is no gcc-11.2 for focal? No, it will use whatever the latest is for GitHub actions. There doesn't seem to be an 11.2 package for GHA. It should be sufficient for most testing, but highlights one of the limitations of relying on GitHub Actions for anything more than a sanity test. ------------- PR: https://git.openjdk.java.net/jfx/pull/761 From kcr at openjdk.java.net Tue Mar 29 11:54:09 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Mar 2022 11:54:09 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 11:49:14 GMT, Kevin Rushforth wrote: >> .github/workflows/submit.yml line 86: >> >>> 84: set -x >>> 85: sudo apt-get update >>> 86: sudo apt-get install libgl1-mesa-dev libx11-dev libxxf86vm-dev libxt-dev pkg-config libgtk2.0-dev libgtk-3-dev libxtst-dev gcc-11 g++-11 >> >> Did this install 11.2? The CI is using Focal, and afaik there is no gcc-11.2 for focal? > > No, it will use whatever the latest is for GitHub actions. There doesn't seem to be an 11.2 package for GHA. It should be sufficient for most testing, but highlights one of the limitations of relying on GitHub Actions for anything more than a sanity test. (based on the printout I see in the log files, the current version of gcc 1.x available on the GHA Linux nodes is 11.1) ------------- PR: https://git.openjdk.java.net/jfx/pull/761 From kcr at openjdk.java.net Tue Mar 29 11:56:56 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Mar 2022 11:56:56 GMT Subject: Integrated: 8283517: Update boot JDK to 18 In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 12:16:18 GMT, Kevin Rushforth wrote: > JDK 18 has been released, so we should update the default boot JDK used to build JavaFX to JDK 18. This will not affect the minimum boot JDK version. I have confirmed that gradle 7.3 works with JDK 18, so we don't need to update gradle at this time. > > I have done a full set of tests on all three platforms. This pull request has now been integrated. Changeset: d1fb3d3d Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/d1fb3d3d022112b4a61e44530e206146edeb74b6 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod 8283517: Update boot JDK to 18 Reviewed-by: arapte, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/760 From rlichten at openjdk.java.net Tue Mar 29 12:14:46 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Tue, 29 Mar 2022 12:14:46 GMT Subject: RFR: 8283509: Invisible menus can lead to IndexOutOfBoundsException In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 09:23:24 GMT, Ajit Ghaisas wrote: > Have you considered keeping the same while loop in findSibling() method and skipping invisible Menus in it? This is to avoid creating and traversing a new list. This would not give the correct result. findSibling must return the index in the list of **visible** menus, since this is what setFocusedMenuIndex() really expects. If we only skip invisible menus we will possibly return an index that is out of bounds, which is exactly what this bug is about. ------------- PR: https://git.openjdk.java.net/jfx/pull/759 From duke at openjdk.java.net Tue Mar 29 12:43:49 2022 From: duke at openjdk.java.net (Glavo) Date: Tue, 29 Mar 2022 12:43:49 GMT Subject: Integrated: 8280369: native library cache should be platform/arch specific In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 18:12:23 GMT, Glavo wrote: > Currently, OpenJFX extracts the native library into a local folder and loads it when it is not part of the JRE. > > Now we have a notable problem with the fact that a platform may actually run programs of multiple CPU architectures. > > Most commonly, 32-bit x86 applications can be executed on Windows AMD64. In addition to this, ARM machines may also execute AMD64 programs by transpiling. > > For OpenJFX of different architectures on the same system, their native libraries have the same file name, but their contents are different. Since they will try to unpack the native library into the same folder, this will cause file conflicts. > > A practical example is when I run the same JavaFX application with both 32-bit and 64-bit Java on a Windows AMD64 platform, and the application that starts later crashes because it cannot unzip the native libraries: > > Crash logs (The length exceeds the GitHub limit): https://paste.ubuntu.com/p/NZBK3pNrh7/ > > Here I avoid the problem by adding `os.arch` to the cache path. > > I ran the tests on Ubuntu 20.04 after the modification and no tests were broken. This pull request has now been integrated. Changeset: a0db4730 Author: Glavo Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/a0db473043167d546973e8293e3f208cb1f59f12 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod 8280369: native library cache should be platform/arch specific Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/762 From jvos at openjdk.java.net Tue Mar 29 12:44:58 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 29 Mar 2022 12:44:58 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 11:50:32 GMT, Kevin Rushforth wrote: >> No, it will use whatever the latest is for GitHub actions. There doesn't seem to be an 11.2 package for GHA. It should be sufficient for most testing, but highlights one of the limitations of relying on GitHub Actions for anything more than a sanity test. > > (based on the printout I see in the log files, the current version of gcc 1.x available on the GHA Linux nodes is 11.1) 11.1 is what I'm using on 18.04 and 20.04 as well. I wonder if that is good enough, or are there particular reasons why you want to update to 11.2 ? ------------- PR: https://git.openjdk.java.net/jfx/pull/761 From kcr at openjdk.java.net Tue Mar 29 12:49:52 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Mar 2022 12:49:52 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 12:19:10 GMT, Kevin Rushforth wrote: > This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK 17 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). > > I ran a full build and test, including media and WebKit. > are there particular reasons why you want to update to 11.2 ? Updating to gcc 11.2 matches JDK 19 -- [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). ------------- PR: https://git.openjdk.java.net/jfx/pull/761 From zjx001202 at gmail.com Tue Mar 29 15:50:12 2022 From: zjx001202 at gmail.com (Glavo) Date: Tue, 29 Mar 2022 23:50:12 +0800 Subject: TextField in the main window steals the focus of the Windows emoji keyboard of another TextField in Popup Message-ID: When using MaterialFX, I encountered such a problem: When the focus of a window is on a TextField, another TextField in a Popup that pops up on this window cannot use the Windows emoji keyboard or IME for input. In this case, all input from the windows emoji keyboard or IME will go into the TextField of the main window, but the clipboard and direct keyboard input work fine. I found a minimal reproducer: import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.TextField; import javafx.scene.layout.VBox; import javafx.stage.Popup; import javafx.stage.Stage; public class JFXTest extends Application { @Override public void start(Stage primaryStage) throws Exception { var root = new VBox(new TextField()); primaryStage.setScene(new Scene(root, 100, 100)); primaryStage.show(); Popup popup = new Popup(); popup.getContent().add(new TextField()); popup.show(primaryStage, 0.0, 0.0); } public static void main(String[] args) { Application.launch(JFXTest.class, args); } } Running this program will open a window with a TextField and another TextField will pop up in the upper left corner of the screen. Use the `Windows logo key + . (period)` on the keyboard to open the emoji keyboard ( https://support.microsoft.com/en-us/windows/windows-10-keyboard-tips-and-tricks-588e0b72-0fff-6d3f-aeee-6e5116097942 ), and enter any emoji with emoji keyboard in the TextField in the upper left corner of the screen, then the entered emoji will appear in the TextField in the main window. This problem breaks the `MFXFilterComboBox` of MaterialFX, preventing it from working with the emoji keyboard or IME. Can anyone keep an eye on it? If possible, I'm asking anyone to help me open an issue in JBS, thanks a lot. From mhanl at openjdk.java.net Tue Mar 29 20:43:54 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 29 Mar 2022 20:43:54 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling [v2] In-Reply-To: <1JgmHbMwKpo3XzZcstu_AQT1Bk79y18RX26BR8d5ulQ=.08c710f0-3aae-495a-9c64-e56cd2625e77@github.com> References: <1JgmHbMwKpo3XzZcstu_AQT1Bk79y18RX26BR8d5ulQ=.08c710f0-3aae-495a-9c64-e56cd2625e77@github.com> Message-ID: On Thu, 24 Mar 2022 06:14:42 GMT, Robert Lichtenberger wrote: >> This fix respects a row factory, if present. >> It will put the cell that is used to measure the column width as child below the row. >> In that way the row's style will be used. > > Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: > > 8251480: TableColumnHeader: calc of cell width must respect row styling > > Old behaviour restored for table rows with custom skins. > Unnecessary call to cell.applyCss() removed. Just commented some minor things. But overall it looks good. I did some manual tests as well and can confirm that this works. :) ![image](https://user-images.githubusercontent.com/66004280/160703014-addf1297-082b-453c-9ba9-d9cec90ff0d2.png) modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 715: > 713: tableRow = createMeasureRow(tv, tableSkin, null); > 714: } > 715: assert tableRow.getSkin() instanceof SkinBase; Not sure if there is some convention about code asserts, maybe some else can tell. At least I never saw one in a PR here. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 276: > 274: } > 275: > 276: private TableRow createSmallRow(TableView tableView) { Minor: Move this method to the other row method below? modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 295: > 293: private TableRow createCustomRow(TableView tableView) { > 294: TableRow row = new TableRow<>() { > 295: protected javafx.scene.control.Skin createDefaultSkin() { Very minor: `javafx.scene.control.` is not needed ------------- Marked as reviewed by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/757 From aghaisas at openjdk.java.net Wed Mar 30 04:51:45 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 30 Mar 2022 04:51:45 GMT Subject: RFR: 8283509: Invisible menus can lead to IndexOutOfBoundsException In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 12:11:54 GMT, Robert Lichtenberger wrote: > > Have you considered keeping the same while loop in findSibling() method and skipping invisible Menus in it? This is to avoid creating and traversing a new list. > > This would not give the correct result. findSibling must return the index in the list of **visible** menus, since this is what setFocusedMenuIndex() really expects. If we only skip invisible menus we will possibly return an index that is out of bounds, which is exactly what this bug is about. OK. Thanks for the explanation. The fix and the test looks good. Only one minor correction needed is in comment. `// Traverse all menus in menubar to find nextIndex` should be `// Traverse all visible menus in menubar to find nextIndex` ------------- PR: https://git.openjdk.java.net/jfx/pull/759 From rlichten at openjdk.java.net Wed Mar 30 10:57:48 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 30 Mar 2022 10:57:48 GMT Subject: RFR: 8283509: Invisible menus can lead to IndexOutOfBoundsException [v2] In-Reply-To: References: Message-ID: > findSibling adapted to only use visible menus when calculating the > index. Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: 8251480: TableColumnHeader: calc of cell width must respect row styling Comment improved. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/759/files - new: https://git.openjdk.java.net/jfx/pull/759/files/2198d6bf..6d511a3f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=759&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=759&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/759.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/759/head:pull/759 PR: https://git.openjdk.java.net/jfx/pull/759 From rlichten at openjdk.java.net Wed Mar 30 10:57:48 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 30 Mar 2022 10:57:48 GMT Subject: RFR: 8283509: Invisible menus can lead to IndexOutOfBoundsException In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 04:48:30 GMT, Ajit Ghaisas wrote: > > Only one minor correction needed is in comment. Right. Just pushed a correction. ------------- PR: https://git.openjdk.java.net/jfx/pull/759 From rlichten at openjdk.java.net Wed Mar 30 11:02:43 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 30 Mar 2022 11:02:43 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling [v3] In-Reply-To: References: Message-ID: > This fix respects a row factory, if present. > It will put the cell that is used to measure the column width as child below the row. > In that way the row's style will be used. Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: 8251480: TableColumnHeader: calc of cell width must respect row styling Test readability improved. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/757/files - new: https://git.openjdk.java.net/jfx/pull/757/files/af582570..960e5012 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=757&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=757&range=01-02 Stats: 13 lines in 1 file changed: 6 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/757.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/757/head:pull/757 PR: https://git.openjdk.java.net/jfx/pull/757 From rlichten at openjdk.java.net Wed Mar 30 11:02:44 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 30 Mar 2022 11:02:44 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling [v2] In-Reply-To: References: <1JgmHbMwKpo3XzZcstu_AQT1Bk79y18RX26BR8d5ulQ=.08c710f0-3aae-495a-9c64-e56cd2625e77@github.com> Message-ID: On Tue, 29 Mar 2022 20:35:10 GMT, Marius Hanl wrote: >> Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: >> >> 8251480: TableColumnHeader: calc of cell width must respect row styling >> >> Old behaviour restored for table rows with custom skins. >> Unnecessary call to cell.applyCss() removed. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 715: > >> 713: tableRow = createMeasureRow(tv, tableSkin, null); >> 714: } >> 715: assert tableRow.getSkin() instanceof SkinBase; > > Not sure if there is some convention about code asserts, maybe some else can tell. At least I never saw one in a PR here. I found assertions in various other parts of the code (e.g. `javafx.scene.control.skin.VirtualFlow`) so I assumed this is ok. > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 276: > >> 274: } >> 275: >> 276: private TableRow createSmallRow(TableView tableView) { > > Minor: Move this method to the other row method below? You're right. I'll move the method. > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 295: > >> 293: private TableRow createCustomRow(TableView tableView) { >> 294: TableRow row = new TableRow<>() { >> 295: protected javafx.scene.control.Skin createDefaultSkin() { > > Very minor: `javafx.scene.control.` is not needed You're right. I'll remove this. ------------- PR: https://git.openjdk.java.net/jfx/pull/757 From arapte at openjdk.java.net Wed Mar 30 11:14:44 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 30 Mar 2022 11:14:44 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 12:19:10 GMT, Kevin Rushforth wrote: > This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK 17 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). > > I ran a full build and test, including media and WebKit. Build on Ubuntu 20.04 looked fine to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/761 From aghaisas at openjdk.java.net Wed Mar 30 11:18:02 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 30 Mar 2022 11:18:02 GMT Subject: RFR: 8283509: Invisible menus can lead to IndexOutOfBoundsException [v2] In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 10:57:48 GMT, Robert Lichtenberger wrote: >> findSibling adapted to only use visible menus when calculating the >> index. > > Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: > > 8251480: TableColumnHeader: calc of cell width must respect row styling > > Comment improved. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/759 From kcr at openjdk.java.net Wed Mar 30 11:59:46 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 30 Mar 2022 11:59:46 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 12:19:10 GMT, Kevin Rushforth wrote: > This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK 17 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). > > I ran a full build and test, including media and WebKit. Given that the gcc 11.2 compiler isn't available for the latest Ubuntu LTS, 20.04, it seems worth putting this on hold for a bit. I have moved it to Draft. ------------- PR: https://git.openjdk.java.net/jfx/pull/761 From kcr at openjdk.java.net Wed Mar 30 12:13:47 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 30 Mar 2022 12:13:47 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling [v2] In-Reply-To: References: <1JgmHbMwKpo3XzZcstu_AQT1Bk79y18RX26BR8d5ulQ=.08c710f0-3aae-495a-9c64-e56cd2625e77@github.com> Message-ID: On Wed, 30 Mar 2022 10:57:38 GMT, Robert Lichtenberger wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 715: >> >>> 713: tableRow = createMeasureRow(tv, tableSkin, null); >>> 714: } >>> 715: assert tableRow.getSkin() instanceof SkinBase; >> >> Not sure if there is some convention about code asserts, maybe some else can tell. At least I never saw one in a PR here. > > I found assertions in various other parts of the code (e.g. `javafx.scene.control.skin.VirtualFlow`) so I assumed this is ok. Some old code has assertions, but library code should not use them. Please delete them from any new / modified code. ------------- PR: https://git.openjdk.java.net/jfx/pull/757 From rlichten at openjdk.java.net Wed Mar 30 12:22:24 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 30 Mar 2022 12:22:24 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling [v2] In-Reply-To: References: <1JgmHbMwKpo3XzZcstu_AQT1Bk79y18RX26BR8d5ulQ=.08c710f0-3aae-495a-9c64-e56cd2625e77@github.com> Message-ID: On Wed, 30 Mar 2022 12:10:19 GMT, Kevin Rushforth wrote: >> I found assertions in various other parts of the code (e.g. `javafx.scene.control.skin.VirtualFlow`) so I assumed this is ok. > > Some old code has assertions, but library code should not use them. Please delete them from any new / modified code. Deleted the assertion. ------------- PR: https://git.openjdk.java.net/jfx/pull/757 From rlichten at openjdk.java.net Wed Mar 30 12:22:23 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 30 Mar 2022 12:22:23 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling [v4] In-Reply-To: References: Message-ID: > This fix respects a row factory, if present. > It will put the cell that is used to measure the column width as child below the row. > In that way the row's style will be used. Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: 8251480: TableColumnHeader: calc of cell width must respect row styling Assertion removed. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/757/files - new: https://git.openjdk.java.net/jfx/pull/757/files/960e5012..f463ab09 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=757&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=757&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/757.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/757/head:pull/757 PR: https://git.openjdk.java.net/jfx/pull/757 From kcr at openjdk.java.net Wed Mar 30 12:28:47 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 30 Mar 2022 12:28:47 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling [v4] In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 12:22:23 GMT, Robert Lichtenberger wrote: >> This fix respects a row factory, if present. >> It will put the cell that is used to measure the column width as child below the row. >> In that way the row's style will be used. > > Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: > > 8251480: TableColumnHeader: calc of cell width must respect row styling > > Assertion removed. In looking at the fix, I'd like two reviewers. ------------- PR: https://git.openjdk.java.net/jfx/pull/757 From rlichten at openjdk.java.net Wed Mar 30 13:09:42 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 30 Mar 2022 13:09:42 GMT Subject: Integrated: 8283509: Invisible menus can lead to IndexOutOfBoundsException In-Reply-To: References: Message-ID: <6JwGTfyQTA5ypWQdkgnxX6yPqHT3WC2oxPB9nTBhFdk=.b5c12ac1-9a96-43a7-a067-1c81a1ab15d5@github.com> On Tue, 22 Mar 2022 14:42:07 GMT, Robert Lichtenberger wrote: > findSibling adapted to only use visible menus when calculating the > index. This pull request has now been integrated. Changeset: cff84e24 Author: Robert Lichtenberger Committer: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/cff84e24b2de83a57163462fe275ab067034766c Stats: 34 lines in 2 files changed: 22 ins; 4 del; 8 mod 8283509: Invisible menus can lead to IndexOutOfBoundsException Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/759 From jvos at openjdk.java.net Wed Mar 30 13:27:40 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 30 Mar 2022 13:27:40 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: > When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Don't shift cells if we are already showing the lowest index cell. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/712/files - new: https://git.openjdk.java.net/jfx/pull/712/files/a931ba75..2b1b4bdc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=712&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=712&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712 From jvos at openjdk.java.net Wed Mar 30 13:30:44 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 30 Mar 2022 13:30:44 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v3] In-Reply-To: <2GwIXxxLw9VG_s2vTawYLiIVkHpeoo1_LjRHDIqwhWM=.98d4301f-c0fb-411d-9740-8ada34c873dd@github.com> References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> <2GwIXxxLw9VG_s2vTawYLiIVkHpeoo1_LjRHDIqwhWM=.98d4301f-c0fb-411d-9740-8ada34c873dd@github.com> Message-ID: On Fri, 25 Mar 2022 16:26:34 GMT, Kevin Rushforth wrote: > It looks like there are some failing unit tests now. I fixed them. ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From thiago.sayao at gmail.com Wed Mar 30 19:23:01 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 30 Mar 2022 16:23:01 -0300 Subject: Self built openjfx 17.0.2 Message-ID: Hi, Does the "jfx17" branch contain the latest javafx 17.0.2 code ? https://github.com/openjdk/jfx/tree/jfx17 Also, I have built jmods of this branch with "gradlew jmodLinux" and the resulting jmods are quite bigger comparing to the released ones. I guess it's some debug symbols or something. Should I add any argument? I want the 17.0.2 with one applied extra patch. Thanks. -- Thiago From kevin.rushforth at oracle.com Wed Mar 30 20:02:01 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 30 Mar 2022 13:02:01 -0700 Subject: Self built openjfx 17.0.2 In-Reply-To: References: Message-ID: <3fc8d37d-b32a-b080-3061-050f91977545@oracle.com> No. What you want is the jfx17u repo. https://github.com/openjdk/jfx17u/tree/master If you look at the tags you will see 17.0.2+3 is the latest (GA) sources. -- Kevin On 3/30/2022 12:23 PM, Thiago Milczarek Say?o wrote: > Hi, > > Does the "jfx17" branch contain the latest javafx 17.0.2 code ? > https://github.com/openjdk/jfx/tree/jfx17 > > Also, I have built jmods of this branch with "gradlew jmodLinux" and the > resulting jmods are quite bigger comparing to the released ones. > > I guess it's some debug symbols or something. Should I add any argument? > > I want the 17.0.2 with one applied extra patch. > > > Thanks. > -- Thiago From mhanl at openjdk.java.net Wed Mar 30 20:40:58 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 30 Mar 2022 20:40:58 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling [v4] In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 12:22:23 GMT, Robert Lichtenberger wrote: >> This fix respects a row factory, if present. >> It will put the cell that is used to measure the column width as child below the row. >> In that way the row's style will be used. > > Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: > > 8251480: TableColumnHeader: calc of cell width must respect row styling > > Assertion removed. Looks good to me. ------------- Marked as reviewed by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/757