From fastegal at openjdk.java.net Thu Oct 1 11:25:33 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 1 Oct 2020 11:25:33 GMT Subject: RFR: 8090110: Very bad TextArea of performance in a language environment that uses the Chinese character (KANJI) In-Reply-To: References: <86UJqGYdrlV361I2fsisdWWMz3Gls4Ma0FznzUOU8WM=.e80d9ae2-7d96-4c5f-9ca7-851f2a04075c@github.com> <5BDq3WXflNNJ8C_gRTWqrmeSi_28kLvdxNnLhPr5LlY=.b473d1c1-3536-427a-a4e6-0e9c1e75d7e7@github.com> <-KM7qbZC2OCmEGlSd4sHXd9munDFd5i0in4x1kUX_rA=.c5dd4371-3bc5-47ee-95ce-19d9b641c7e4@github.com> Message-ID: On Tue, 29 Sep 2020 15:29:48 GMT, yosbits wrote: > > > I understand that some people want support for the **new features** of Skin Swiching. Assuming that you are joking ;) Just in case you are not and for the record: skinnable.setSkin(skin) skin.dispose() are public api without any notion of being optional - making the implementation of TextAreaSkin misbehaving big style. That said: verified that the fix improves performance of the example immensely. So I think it should be integrated asap, ignoring the big heap of mess already there. Nevertheless, it should - be implemented in a way to not add to the pile of dirt: instead of adding the changeListeners manually, add them via skin api (which will remove them automatically in dispose). That's possible if they are added once in the life-time of the skin, which seems to be the case, or not? - add tests: - unit tests to ensure that changing properties that effect the clip actually are adjusting it - system? test to verify the performance gain ------------- PR: https://git.openjdk.java.net/jfx/pull/307 From kcr at openjdk.java.net Thu Oct 1 15:02:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Oct 2020 15:02:11 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v12] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Fri, 11 Sep 2020 09:22:00 GMT, Ambarish Rapte wrote: >> The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. >> This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several >> `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. >> Fix: >> 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. >> 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to >> `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. >> Change unrelated to fix: >> `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup >> is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code >> from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed >> for the fix. But this seems to be dead code. Verification: >> Added new unit tests to verify the change. >> Also verified that the behavior ListView behaves same before and after this change. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Review: update Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From kcr at openjdk.java.net Thu Oct 1 17:32:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Oct 2020 17:32:04 GMT Subject: RFR: 8244297: memory leak test utility [v4] In-Reply-To: <2-4P8pUbsWMYD2cYtyraM1Kw1VAQJjw4Bhg-B1YMhlw=.09cf1de1-f281-4c49-9ae0-53f1c24599dd@github.com> References: <2-4P8pUbsWMYD2cYtyraM1Kw1VAQJjw4Bhg-B1YMhlw=.09cf1de1-f281-4c49-9ae0-53f1c24599dd@github.com> Message-ID: On Wed, 30 Sep 2020 12:36:50 GMT, Kevin Rushforth wrote: >> I've fixed the wrong imports. It would be great if Travis could check whether all systemTests are compiling. > > Thanks, we'll review it now. > > Btw, we don't plan to hook up Travis, but instead will be looking at GitHub actions now that the `jdk` project is using > them successfully. It looks like you are missing an import statement in one of the tests: > Task :systemTests:compileTestJava ...\jfx\tests\system\src\test\java\test\javafx\scene\InitialNodesMemoryLeakTest.java:88: error: cannot find symbol JMemoryBuddy.assertCollectable("groupWRef"); ^ symbol: variable JMemoryBuddy location: class InitialNodesMemoryLeakTest Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 1 error You can run the following locally on your system once you have fixed this to verify that there are no others. gradle --continue -PFULL_TEST=true test ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From github.com+7517141+yososs at openjdk.java.net Thu Oct 1 18:03:01 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Thu, 1 Oct 2020 18:03:01 GMT Subject: RFR: 8090110: Very bad TextArea of performance in a language environment that uses the Chinese character (KANJI) In-Reply-To: References: <86UJqGYdrlV361I2fsisdWWMz3Gls4Ma0FznzUOU8WM=.e80d9ae2-7d96-4c5f-9ca7-851f2a04075c@github.com> <5BDq3WXflNNJ8C_gRTWqrmeSi_28kLvdxNnLhPr5LlY=.b473d1c1-3536-427a-a4e6-0e9c1e75d7e7@github.com> <-KM7qbZC2OCmEGlSd4sHXd9munDFd5i0in4x1kUX_rA=.c5dd4371-3bc5-47ee-95ce-19d9b641c7e4@github.com> Message-ID: On Thu, 1 Oct 2020 11:23:03 GMT, Jeanette Winzenburg wrote: >> I understand that some people want support for the **new features** of Skin Swiching. > >> >> >> I understand that some people want support for the **new features** of Skin Swiching. > > Assuming that you are joking ;) Just in case you are not and for the record: > > skinnable.setSkin(skin) > skin.dispose() > > are public api without any notion of being optional - making the implementation of TextAreaSkin misbehaving big style. > > That said: verified that the fix improves performance of the example immensely. So I think it should be integrated > asap, ignoring the big heap of mess already there. > Nevertheless, it should > > - be implemented in a way to not add to the pile of dirt: instead of adding the changeListeners manually, add them via > skin api (which will remove them automatically in dispose). That's possible if they are added once in the life-time of > the skin, which seems to be the case, or not? > - add tests: > - unit tests to ensure that changing properties that effect the clip actually are adjusting it > - system? test to verify the performance gain I think testing of the internal structure of Control should be minimal; I think testing for context, such as CSS classes, is necessary. In particular, I don't think we are at a stage where we are dealing with the internal structure of TextArea in a fixed way, so we will need to determine the Next Step. ------------- PR: https://git.openjdk.java.net/jfx/pull/307 From arapte at openjdk.java.net Fri Oct 2 03:09:05 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 2 Oct 2020 03:09:05 GMT Subject: Integrated: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing In-Reply-To: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Sat, 11 Apr 2020 09:53:46 GMT, Ambarish Rapte wrote: > The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. > This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several > `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. > Fix: > 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. > 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to > `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. > Change unrelated to fix: > `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup > is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code > from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed > for the fix. But this seems to be dead code. Verification: > Added new unit tests to verify the change. > Also verified that the behavior ListView behaves same before and after this change. This pull request has now been integrated. Changeset: 77a183e7 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/77a183e7 Stats: 431 lines in 6 files changed: 371 ins; 49 del; 11 mod 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing Reviewed-by: kcr, fastegal ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From fastegal at openjdk.java.net Fri Oct 2 12:12:47 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 2 Oct 2020 12:12:47 GMT Subject: RFR: 8253597: TreeTableView: must select leaf row on click into indentation region Message-ID: .. but doesn't reliably (see report for details). Fixed in TreeTableCellBehavior to check for visibility of the disclosureNode. Added test that failed before and passes after, along with a couple of sanity tests. Also added an alternative mouseEvent creation path into MouseEventFirer (and test) to work-around [JDK-8253769](https://bugs.openjdk.java.net/browse/JDK-8253769) ------------- Commit messages: - 8253597: TreeTableView: must select leaf row on click into indentation Changes: https://git.openjdk.java.net/jfx/pull/313/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=313&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253597 Stats: 702 lines in 4 files changed: 696 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/313.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/313/head:pull/313 PR: https://git.openjdk.java.net/jfx/pull/313 From kcr at openjdk.java.net Fri Oct 2 14:52:39 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 2 Oct 2020 14:52:39 GMT Subject: RFR: 8253597: TreeTableView: must select leaf row on click into indentation region In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 12:08:52 GMT, Jeanette Winzenburg wrote: > .. but doesn't reliably (see report for details). Fixed in TreeTableCellBehavior to check for visibility of the > disclosureNode. > Added test that failed before and passes after, along with a couple of sanity tests. > > Also added an alternative mouseEvent creation path into MouseEventFirer (and test) to work-around > [JDK-8253769](https://bugs.openjdk.java.net/browse/JDK-8253769) @aghaisas can you review this? A single reviewer should be sufficient, but if you think it needs a second reviewer, go ahead and indicate that. ------------- PR: https://git.openjdk.java.net/jfx/pull/313 From kcr at openjdk.java.net Fri Oct 2 15:41:35 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 2 Oct 2020 15:41:35 GMT Subject: RFR: 8253634: TreeCell/Skin: misbehavior on switching skin In-Reply-To: <9d4VS8CCZTJ-8dosR1FEWkS1gi870X_aIu29GW6xJbo=.f0d842db-67ff-493a-9ae8-a91412d2bba9@github.com> References: <9d4VS8CCZTJ-8dosR1FEWkS1gi870X_aIu29GW6xJbo=.f0d842db-67ff-493a-9ae8-a91412d2bba9@github.com> Message-ID: On Fri, 25 Sep 2020 11:10:20 GMT, Jeanette Winzenburg wrote: > TreeCellSkin installs listeners to the TreeView/fixedCellSize that introduce a memory leak, NPE on replacing the > treeView and incorrect update of internal state. > Fixed by removing the listeners (and the internal state had been copied from treeView on change) and access of listView > state when needed. > Added tests that failed before and pass after the fix, plus a sanity test to guarantee same (correct) behavior > before/after. > Issue and fix is basically the same as for ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745) @arapte I think a single reviewer should be sufficient, but if you think it needs a second reviewer, go ahead and indicate that. ------------- PR: https://git.openjdk.java.net/jfx/pull/309 From kcr at openjdk.java.net Fri Oct 2 16:29:45 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 2 Oct 2020 16:29:45 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 07:35:49 GMT, yosbits wrote: >> https://bugs.openjdk.java.net/browse/JDK-8253086 >> >> ObservableListWrapper.java >> * public boolean removeAll(Collection c) >> * public boolean retainAll(Collection c) >> >> These two methods use BitSet, but it doesn't make sense. >> By rewriting to the equivalent behavior that does not use BitSet, it is possible to reduce the CPU load in a wide range >> of use cases. >> The test is done with the following command. >> >> * gradle base: test >> * gradle controls: test > > yosbits has refreshed the contents of this pull request, and previous commits have been removed. The incremental views > will show differences compared to the previous content of the PR. The fix looks good to me. I left a few comments on the test, but it looks like a great start. modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java line 203: > 201: boolean retained = false; > 202: beginChange(); > 203: for (int i = size()-1; i>=0; i--) { Please fix the spacing. Per our coding guidelines, this should be: for (int i = size() - 1; i >= 0; i--) { modules/javafx.base/src/test/java/test/com/sun/javafx/collections/ObservableListWrapperTest.java line 38: > 36: import java.util.Arrays; > 37: import java.util.Collection; > 38: import java.util.Collections; Can you sort the imports? modules/javafx.base/src/test/java/test/com/sun/javafx/collections/ObservableListWrapperTest.java line 110: > 108: assertTrue(list.retainAll(Collections.EMPTY_SET)); > 109: assertEquals(0, list.size()); > 110: } Can you add a test for `retainAll` (in a separate test method) that removes multiple elements in a single call? Something like the following: * set list to `(1, 2, 3, 4, 5)` * remove `(2, 4)` * verify that the list equals `(1, 3, 5)` * remove `(1, 5)` * verify that the list equals `(3)` Similarly, a test for `retainAll` that removes multiple elements in a single call? * set list to `(1, 2, 3, 4, 5)` * retain `(1, 3, 5)` * verify that the list equals `(1, 3, 5)` * retain `(3)` * verify that the list equals `(3)` modules/javafx.base/src/test/java/test/com/sun/javafx/collections/ObservableListWrapperTest.java line 78: > 76: assertEquals(3, list.size()); > 77: assertTrue(list.removeAll(1)); > 78: assertEquals(2, list.size()); Can you add a check that the correct element was removed (i.e., check that the list equals `(2, 3)`)? ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From kcr at openjdk.java.net Fri Oct 2 16:29:47 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 2 Oct 2020 16:29:47 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: Message-ID: <6Y6MJeDT7ivvVswJ6zhDapayIfAMVkCv74cFERDXpZM=.a8ceedff-738a-454b-9162-f557886e0db4@github.com> On Tue, 22 Sep 2020 01:58:48 GMT, yosbits wrote: >> digging a bit: the BitSet was introduced with https://bugs.openjdk.java.net/browse/JDK-8093144 to solve some problem >> with selectionModels - don't know whether those still hold (there had been extensive changes to selection since then). > > Thank you for searching for the origin of this strange code. However, as far as I read the comments, my intuition seems > to be correct. I looked at the fix for [JDK-8093144](https://bugs.openjdk.java.net/browse/JDK-8093144), and the reason BitSet was introduced was to ensure that the elements are removed from this List in reverse order (prior to that fix, they were removed in forward order with the loop index being messed up). This patch preserves the correct behavior, and just looks to be a better fix for that earlier problem. I do recommend running the failing test case from [JDK-8093144](https://bugs.openjdk.java.net/browse/JDK-8093144) to verify no regressions, but it looks like a good and safe fix to me. @yososs I marked this discussion thread as unresolved mainly to make this comment, but also because you didn't fix the spacing suggested by @nlisker -- please do that. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From kcr at openjdk.java.net Fri Oct 2 16:34:40 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 2 Oct 2020 16:34:40 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 16:27:09 GMT, Kevin Rushforth wrote: >> yosbits has refreshed the contents of this pull request, and previous commits have been removed. The incremental views >> will show differences compared to the previous content of the PR. > > The fix looks good to me. I left a few comments on the test, but it looks like a great start. One meta-comment: > @yososs yososs force-pushed the yososs:8253086_Optimization_of_removeAll_and_retainAll_of_ObservableListWrapper branch > ... As indicated in the [CONTRIBUTING guidelines](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#submitting-your-changes-via-a-pull-request), please don't force-push to your branch. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From nlisker at openjdk.java.net Fri Oct 2 17:18:39 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 2 Oct 2020 17:18:39 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: <6Y6MJeDT7ivvVswJ6zhDapayIfAMVkCv74cFERDXpZM=.a8ceedff-738a-454b-9162-f557886e0db4@github.com> References: <6Y6MJeDT7ivvVswJ6zhDapayIfAMVkCv74cFERDXpZM=.a8ceedff-738a-454b-9162-f557886e0db4@github.com> Message-ID: On Fri, 2 Oct 2020 16:01:20 GMT, Kevin Rushforth wrote: > the reason BitSet was introduced was to ensure that the elements are removed from this List in reverse order (prior to > that fix, they were removed in forward order with the loop index being messed up). But why do they need to be removed in reverse order to begin with? The super implementation does forward removal, or just use `removeIf`. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From kcr at openjdk.java.net Fri Oct 2 18:22:38 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 2 Oct 2020 18:22:38 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <6Y6MJeDT7ivvVswJ6zhDapayIfAMVkCv74cFERDXpZM=.a8ceedff-738a-454b-9162-f557886e0db4@github.com> Message-ID: On Fri, 2 Oct 2020 17:16:03 GMT, Nir Lisker wrote: >> I looked at the fix for [JDK-8093144](https://bugs.openjdk.java.net/browse/JDK-8093144), and the reason BitSet was >> introduced was to ensure that the elements are removed from this List in reverse order (prior to that fix, they were >> removed in forward order with the loop index being messed up). This patch preserves the correct behavior, and just >> looks to be a better fix for that earlier problem. I do recommend running the failing test case from >> [JDK-8093144](https://bugs.openjdk.java.net/browse/JDK-8093144) to verify no regressions, but it looks like a good and >> safe fix to me. @yososs I marked this discussion thread as unresolved mainly to make this comment, but also because >> you didn't fix the spacing suggested by @nlisker -- please do that. > >> the reason BitSet was introduced was to ensure that the elements are removed from this List in reverse order (prior to >> that fix, they were removed in forward order with the loop index being messed up). > > But why do they need to be removed in reverse order to begin with? The super implementation does forward removal, or > just use `removeIf`. It might not matter any more (presuming that it was done correctly), but it seems safer to leave the logic as-is to match the existing behavior. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+12369767+lorenzpahl at openjdk.java.net Fri Oct 2 18:57:37 2020 From: github.com+12369767+lorenzpahl at openjdk.java.net (Lorenz Pahl) Date: Fri, 2 Oct 2020 18:57:37 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v3] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 18:57:16 GMT, Kevin Rushforth wrote: >> This PR updates the `CONTRIBUTING.md` guide to address the following: >> >> 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing >> list as the first step. 2. Add a link to the mailing list in the section regarding contributing bug fixes. >> 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this >> 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this >> when the PR is integrated. 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate >> 6. Update the note regarding which JDK(s) to use. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review coments CONTRIBUTING.md line 198: > 196: * Avoid making changes that are unrelated to the bug you are fixing. This includes fixing minor errors such as > warnings, spacing / indentation, spelling errors, etc, in code that you aren't otherwise modifying as part of your fix. > 197: * Disable “auto-format on save” to prevent your IDE from making unnecessary formatting changes. This > makes reviews much harder as it generates unnecessary diffs. If your IDE supports formatting only modified chunks, that > is fine to do. 198: * Wildcard imports – for example, `import java.util.*;` – are forbidden and may cause > the build to fail. Please attempt to configure your IDE so it doesn't genearte wildcard imports. An exception to this > rule is that wildcard static imports in test classes are allowed, for example, `import static org.junit.Assert.*;`. There is a small spelling error: "genearte". ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Fri Oct 2 19:09:39 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 2 Oct 2020 19:09:39 GMT Subject: RFR: 8252236: TabPane: must keep header of selected tab visible [v3] In-Reply-To: <-FzegWDvMUdN-s7ZDofsPTG6-uHPdh3xqSvzTMkyt7o=.cc1a3ca5-c86e-46f2-9f08-5893c0b150a3@github.com> References: <-FzegWDvMUdN-s7ZDofsPTG6-uHPdh3xqSvzTMkyt7o=.cc1a3ca5-c86e-46f2-9f08-5893c0b150a3@github.com> Message-ID: On Thu, 24 Sep 2020 13:10:41 GMT, Jeanette Winzenburg wrote: >> the issue is that the header of the selected tab is not always visible (or kept visible, see report for details) >> >> - initially >> - after changing side >> - after resizing stage/tabPane >> - after modifying the list of tabs >> >> Fixed in TabPaneSkin to notify its TabHeaderArea (== collaborator that is responsible for layout the tabs) whenever its >> scroll might need an update. >> Added tests that fail before and pass after the fix. >> >> Note that there still are issues while/after dragging, which are separated into >> [JDK-8253352](https://bugs.openjdk.java.net/browse/JDK-8253352) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > removed empty else-block and added code comment The fix looks good. Thanks for the additional, well-documented tests! ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/300 From fastegal at openjdk.java.net Sat Oct 3 09:33:36 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 3 Oct 2020 09:33:36 GMT Subject: Integrated: 8252236: TabPane: must keep header of selected tab visible In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 12:03:34 GMT, Jeanette Winzenburg wrote: > the issue is that the header of the selected tab is not always visible (or kept visible, see report for details) > > - initially > - after changing side > - after resizing stage/tabPane > - after modifying the list of tabs > > Fixed in TabPaneSkin to notify its TabHeaderArea (== collaborator that is responsible for layout the tabs) whenever its > scroll might need an update. > Added tests that fail before and pass after the fix. > > Note that there still are issues while/after dragging, which are separated into > [JDK-8253352](https://bugs.openjdk.java.net/browse/JDK-8253352) This pull request has now been integrated. Changeset: 5b42b642 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/5b42b642 Stats: 521 lines in 3 files changed: 511 ins; 4 del; 6 mod 8252236: TabPane: must keep header of selected tab visible Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/300 From fastegal at openjdk.java.net Sat Oct 3 11:30:37 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 3 Oct 2020 11:30:37 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 16:23:23 GMT, Kevin Rushforth wrote: >> yosbits has refreshed the contents of this pull request, and previous commits have been removed. The incremental views >> will show differences compared to the previous content of the PR. > > modules/javafx.base/src/test/java/test/com/sun/javafx/collections/ObservableListWrapperTest.java line 110: > >> 108: assertTrue(list.retainAll(Collections.EMPTY_SET)); >> 109: assertEquals(0, list.size()); >> 110: } > > Can you add a test for `retainAll` (in a separate test method) that removes multiple elements in a single call? > Something like the following: > * set list to `(1, 2, 3, 4, 5)` > * remove `(2, 4)` > * verify that the list equals `(1, 3, 5)` > * remove `(1, 5)` > * verify that the list equals `(3)` > > Similarly, a test for `retainAll` that removes multiple elements in a single call? > > * set list to `(1, 2, 3, 4, 5)` > * retain `(1, 3, 5)` > * verify that the list equals `(1, 3, 5)` > * retain `(3)` > * verify that the list equals `(3)` wondering why a new test? All concrete implementations are tested in the parameterized (on the implementations) ObservableListTest - would suggest to add to it what's not yet done (there are several around removeAll, a bit scarce on retainAll). Also would be easier to include notification testing (by following the example of the available tests) which should be done as well as the state testing (don't expect much trouble, though). ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From fastegal at openjdk.java.net Sat Oct 3 11:30:37 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 3 Oct 2020 11:30:37 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <6Y6MJeDT7ivvVswJ6zhDapayIfAMVkCv74cFERDXpZM=.a8ceedff-738a-454b-9162-f557886e0db4@github.com> Message-ID: On Fri, 2 Oct 2020 18:20:18 GMT, Kevin Rushforth wrote: >>> the reason BitSet was introduced was to ensure that the elements are removed from this List in reverse order (prior to >>> that fix, they were removed in forward order with the loop index being messed up). >> >> But why do they need to be removed in reverse order to begin with? The super implementation does forward removal, or >> just use `removeIf`. > > It might not matter any more (presuming that it was done correctly), but it seems safer to leave the logic as-is to > match the existing behavior. the problem was (and still is) in MultipleSelectionModelBase: selectedItems = new SelectedItemsReadOnlyObservableList(selectedIndices, () -> getItemCount()) { @Override protected T getModelItem(int index) { return MultipleSelectionModelBase.this.getModelItem(index); } }; meaning that the selectedItems change during the removal of items (that's plain wrong!) which shows when removing the items from the start: // removeAll before fix of for (int i = 0; i < size(); ++i) { if (c.contains(get(i))) { remove(i); --i; modified = true; } } doing so is basically valid (note the decremented i). Just the selectedItems look into the underlying model, so **c** is changing during the removal which is a no-go. Returning to the old (pre [JDK-8093144](https://bugs.openjdk.java.net/browse/JDK-8093144)) still makes the tests against it fail (ListViewTest.test_rt35857 f.i.). Still wondering why the detour over the BitSet was choosen as fix (vs. the more natural remove-from-last). The listView test is passing for the bitSet and for the back-to-front approach. Can we imagine a context where the broken selectedItems impl would add wreckage to the latter? ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From kcr at openjdk.java.net Sat Oct 3 14:35:36 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 3 Oct 2020 14:35:36 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: Message-ID: On Sat, 3 Oct 2020 10:09:40 GMT, Jeanette Winzenburg wrote: >> modules/javafx.base/src/test/java/test/com/sun/javafx/collections/ObservableListWrapperTest.java line 110: >> >>> 108: assertTrue(list.retainAll(Collections.EMPTY_SET)); >>> 109: assertEquals(0, list.size()); >>> 110: } >> >> Can you add a test for `retainAll` (in a separate test method) that removes multiple elements in a single call? >> Something like the following: >> * set list to `(1, 2, 3, 4, 5)` >> * remove `(2, 4)` >> * verify that the list equals `(1, 3, 5)` >> * remove `(1, 5)` >> * verify that the list equals `(3)` >> >> Similarly, a test for `retainAll` that removes multiple elements in a single call? >> >> * set list to `(1, 2, 3, 4, 5)` >> * retain `(1, 3, 5)` >> * verify that the list equals `(1, 3, 5)` >> * retain `(3)` >> * verify that the list equals `(3)` > > wondering why a new test? All concrete implementations are tested in the parameterized (on the implementations) > ObservableListTest - would suggest to add to it what's not yet done (there are several around removeAll, a bit scarce > on retainAll). Also would be easier to include notification testing (by following the example of the available tests) > which should be done as well as the state testing (don't expect much trouble, though). That's a good suggestion. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From fkirmaier at openjdk.java.net Sat Oct 3 16:00:48 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sat, 3 Oct 2020 16:00:48 GMT Subject: RFR: 8244297: memory leak test utility [v6] In-Reply-To: References: Message-ID: > It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 > > I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. > > It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. > I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very > stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but > the tests with JMemoryBuddy are basically always correct. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8244297 Fixed unit-test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/204/files - new: https://git.openjdk.java.net/jfx/pull/204/files/adc870cf..6a861e43 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=204&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=204&range=04-05 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/204.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/204/head:pull/204 PR: https://git.openjdk.java.net/jfx/pull/204 From fkirmaier at openjdk.java.net Sat Oct 3 16:21:40 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sat, 3 Oct 2020 16:21:40 GMT Subject: RFR: 8244297: memory leak test utility [v4] In-Reply-To: References: <2-4P8pUbsWMYD2cYtyraM1Kw1VAQJjw4Bhg-B1YMhlw=.09cf1de1-f281-4c49-9ae0-53f1c24599dd@github.com> Message-ID: On Thu, 1 Oct 2020 17:29:34 GMT, Kevin Rushforth wrote: >> Thanks, we'll review it now. >> >> Btw, we don't plan to hook up Travis, but instead will be looking at GitHub actions now that the `jdk` project is using >> them successfully. > > It looks like you are missing an import statement in one of the tests: > >> Task :systemTests:compileTestJava > ...\jfx\tests\system\src\test\java\test\javafx\scene\InitialNodesMemoryLeakTest.java:88: error: cannot find symbol > JMemoryBuddy.assertCollectable("groupWRef"); > ^ > symbol: variable JMemoryBuddy > location: class InitialNodesMemoryLeakTest > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > 1 error > > You can run the following locally on your system once you have fixed this to verify that there are no others. > > gradle --continue -PFULL_TEST=true test `./gradlew --continue -PFULL_TEST=true test` Seems to be very unstable on my machine (Mac). It produces various errors, which are not related to my changes, which makes it basically useless in my environment. I've checked the 4 changed tests with the following commands: `./gradlew --continue -PFULL_TEST=true controls:test` ` ./gradlew --continue -PFULL_TEST=true systemTest:test --tests "*VirtualFlowMemoryLeakTest*"` `./gradlew --continue -PFULL_TEST=true systemTest:test --tests "*ProgressIndicatorLeakTest*"` `./gradlew --continue -PFULL_TEST=true systemTest:test --tests "*InitialNode*" ` They all compile now and are green. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From github.com+7517141+yososs at openjdk.java.net Sun Oct 4 05:50:35 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Sun, 4 Oct 2020 05:50:35 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 16:29:56 GMT, Kevin Rushforth wrote: >> The fix looks good to me. I left a few comments on the test, but it looks like a great start. > > One meta-comment: > >> @yososs yososs force-pushed the yososs:8253086_Optimization_of_removeAll_and_retainAll_of_ObservableListWrapper branch >> ... > > As indicated in the [CONTRIBUTING > guidelines](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#submitting-your-changes-via-a-pull-request), > please don't force-push to your branch. I understand that your testing requirements are higher than when this tested class was implemented. The fix will be pushed in the next few days. I hope I can check the coding style (including spaces) with the gradle task before git push. Let me know if there is a way to make jcheck work on my device. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From fastegal at openjdk.java.net Sun Oct 4 09:26:35 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sun, 4 Oct 2020 09:26:35 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <6Y6MJeDT7ivvVswJ6zhDapayIfAMVkCv74cFERDXpZM=.a8ceedff-738a-454b-9162-f557886e0db4@github.com> Message-ID: <43kECsA18C2b-Hy9rptZuhQYrxuXpOwVfjWy0DwaVvA=.22cb8220-9225-401a-96db-729da45c7b60@github.com> On Sat, 3 Oct 2020 11:13:28 GMT, Jeanette Winzenburg wrote: > The listView test is passing for the bitSet and for the back-to-front approach. Can we imagine a context where the > broken selectedItems impl would add wreckage to the latter? To answer my own question: yes. A failing test with the back-to-front approach (the existing test in ListViewTest modified in having the last item selected) @Test public void test_rt35857Back() { ObservableList fxList = FXCollections.observableArrayList("A", "B", "C"); final ListView listView = new ListView(fxList); listView.getSelectionModel().select(2); ObservableList selectedItems = listView.getSelectionModel().getSelectedItems(); assertEquals(1, selectedItems.size()); assertEquals("C", selectedItems.get(0)); listView.getItems().removeAll(selectedItems); assertEquals(2, fxList.size()); assertEquals("A", fxList.get(0)); assertEquals("B", fxList.get(1)); } Feels like coming nearer to the why of the BitSet approach: it guards against the scenario where changing the current list implicitly changes the list given as parameter - in that case, it's unsafe to query the parameter list while removing items (c.contains simply reports nonsense). This may happen whenever the parameter list does some kind of live lookup into the current list (such as f.i. SelectedItemsReadOnlyObservableList) - which is not as evil as I thought yesterday (did it myself in custom selectionModels ;) The BitSet solves it by a two-pass approach: first collect all items to remove/retain without (that is keep the parameter list in a valid state, allowing to safely access it), then do the removal without further accessing the (then invalid) parameter list. The fix at that time was a deliberate decision by the designer of the collections, so the context when it happens was deemed a valid use-case. Looks like we should **not** revert it. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From ajoseph at openjdk.java.net Mon Oct 5 07:12:40 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 5 Oct 2020 07:12:40 GMT Subject: RFR: 8253696: WebEngine refuses to load local "file:///" CSS stylesheets when using JDK 15 Message-ID: <916eD15crXE2JD07BTIrBOEORV2rQal8fqSmOhnmHlo=.0df77a8c-6413-4b89-967d-38893b56b981@github.com> Issue: In JDK15, [URLConnection](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/net/www/URLConnection.java) class overrode the getHeaderFields() methods to return properties, which previously returned an empty map from its super class. Fix: Extract headers only when it's a HttpURLConnection, otherwise return an empty String. ------------- Commit messages: - Update copyright year - Add unit test - WebEngine refuses to load local "file:///" CSS stylesheets when using JDK 15 Changes: https://git.openjdk.java.net/jfx/pull/314/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=314&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253696 Stats: 24 lines in 3 files changed: 15 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/314.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/314/head:pull/314 PR: https://git.openjdk.java.net/jfx/pull/314 From fastegal at openjdk.java.net Mon Oct 5 11:50:35 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 5 Oct 2020 11:50:35 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v3] In-Reply-To: References: Message-ID: On Sat, 19 Sep 2020 15:54:57 GMT, Kevin Rushforth wrote: >> I think that "Contributing to the OpenJFX codebase" should be renamed to something related to a style guide. Then split >> the testing part to its own subsection. >> Also, I still find it confusing that "New features / API additions" is not under the code contribution section. There >> seems to be 2 main sections: reporting bugs / requesting features - these don't involve code, just talk; then there is >> contributing code, which covers the process for setup, submissions of bugs fixes, submission of features/API, style, >> and testing (in some order). Wouldn't this be a better flow? > > Yes, I do think the flow could be better. I'll need to put this on hold for a while, but when I get back to it, I'll > look at your suggestions and see if I can come up with something that will improve the flow. > Btw, the thinking behind putting the "New features / API additions" sections at the end (sort of like an appendix) is > that I didn't want it to get in the way of the "here's how you sumbit and review a PR" for bug fixes, which is the more > common case. I don't think it achieves that in its current form. not sure whether it belongs here, or whether or not it's obviously implied but: I would like to see a bit of clarification on testing of contributions. Right now the sentence might be interpreted to be about running available tests: > Test your changes > Run the test suite to make sure that nothing is broken. > add something like: - For most code changes, new tests covering those changes are mandatory. ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From dubaut at gmail.com Mon Oct 5 14:27:15 2020 From: dubaut at gmail.com (Hannes H.) Date: Mon, 5 Oct 2020 16:27:15 +0200 Subject: Permanently fall-back to software rendering Message-ID: Good afternoon, since I do not see that JDK-8154847 will be fixed any time soon I would like to know if there is a way to permanently fall-back to software rendering on all environments. BR, Hannes From johan.vos at gluonhq.com Mon Oct 5 14:41:43 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 5 Oct 2020 16:41:43 +0200 Subject: Permanently fall-back to software rendering In-Reply-To: References: Message-ID: Do you mean having sw-rendering as the first option? That could be done with -Dprism.order=sw - Johan On Mon, Oct 5, 2020 at 4:28 PM Hannes H. wrote: > Good afternoon, > > since I do not see that JDK-8154847 will be fixed any time soon I would > like to know if there is a way to permanently fall-back to software > rendering on all environments. > > BR, > Hannes > From kcr at openjdk.java.net Mon Oct 5 19:25:40 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 5 Oct 2020 19:25:40 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: <43kECsA18C2b-Hy9rptZuhQYrxuXpOwVfjWy0DwaVvA=.22cb8220-9225-401a-96db-729da45c7b60@github.com> References: <6Y6MJeDT7ivvVswJ6zhDapayIfAMVkCv74cFERDXpZM=.a8ceedff-738a-454b-9162-f557886e0db4@github.com> <43kECsA18C2b-Hy9rptZuhQYrxuXpOwVfjWy0DwaVvA=.22cb8220-9225-401a-96db-729da45c7b60@github.com> Message-ID: On Sun, 4 Oct 2020 09:24:16 GMT, Jeanette Winzenburg wrote: >> the problem was (and still is) in MultipleSelectionModelBase: >> >> selectedItems = new SelectedItemsReadOnlyObservableList(selectedIndices, () -> getItemCount()) { >> @Override protected T getModelItem(int index) { >> return MultipleSelectionModelBase.this.getModelItem(index); >> } >> }; >> >> meaning that the selectedItems change during the removal of items (that's plain wrong!) which shows when removing the >> items from the start: >> >> // removeAll before fix of >> for (int i = 0; i < size(); ++i) { >> if (c.contains(get(i))) { >> remove(i); >> --i; >> modified = true; >> } >> } >> >> doing so is basically valid (note the decremented i). Just the selectedItems look into the underlying model, so **c** >> is changing during the removal which is a no-go. >> Returning to the old (pre [JDK-8093144](https://bugs.openjdk.java.net/browse/JDK-8093144)) still makes the tests >> against it fail (ListViewTest.test_rt35857 f.i.). >> Still wondering why the detour over the BitSet was choosen as fix (vs. the more natural remove-from-last). The listView >> test is passing for the bitSet and for the back-to-front approach. Can we imagine a context where the broken >> selectedItems impl would add wreckage to the latter? > >> The listView test is passing for the bitSet and for the back-to-front approach. Can we imagine a context where the >> broken selectedItems impl would add wreckage to the latter? > > To answer my own question: yes. A failing test with the back-to-front approach (the existing test in ListViewTest > modified in having the last item selected) > @Test public void test_rt35857Back() { > ObservableList fxList = FXCollections.observableArrayList("A", "B", "C"); > final ListView listView = new ListView(fxList); > > listView.getSelectionModel().select(2); > > ObservableList selectedItems = > listView.getSelectionModel().getSelectedItems(); > assertEquals(1, selectedItems.size()); > assertEquals("C", selectedItems.get(0)); > > listView.getItems().removeAll(selectedItems); > assertEquals(2, fxList.size()); > assertEquals("A", fxList.get(0)); > assertEquals("B", fxList.get(1)); > } > > Feels like coming nearer to the why of the BitSet approach: it guards against the scenario where changing the current > list implicitly changes the list given as parameter - in that case, it's unsafe to query the parameter list while > removing items (c.contains simply reports nonsense). This may happen whenever the parameter list does some kind of > live lookup into the current list (such as f.i. SelectedItemsReadOnlyObservableList) - which is not as evil as I > thought yesterday (did it myself in custom selectionModels ;) The BitSet solves it by a two-pass approach: first > collect all items to remove/retain without (that is keep the parameter list in a valid state, allowing to safely access > it), then do the removal without further accessing the (then invalid) parameter list. The fix at that time was a > deliberate decision by the designer of the collections, so the context when it happens was deemed a valid use-case. > Looks like we should **not** revert it. Nice catch! So now it's clear that the current approach was adopted because the source list itself can change as a result of removing an element from the target list in some cases, such as the one you pointed out above. I filed [JDK-8254040](https://bugs.openjdk.java.net/browse/JDK-8254040) to add the test case you listed above so we avoid a possible future regression. So a two-pass algorithm is still needed: the first one to collect the elements to be removed, the second to actually remove them. While it isn't necessary to use a BitSet to collect the indexes to be removed, that does seems a reasonable approach. Unless there is a good reason to change it to some other two-pass algorithm, it's probably best to leave it as-is, in which case this PR and the associated JBS issue can be withdrawn. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From kcr at openjdk.java.net Mon Oct 5 19:52:42 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 5 Oct 2020 19:52:42 GMT Subject: RFR: 8253696: WebEngine refuses to load local "file:///" CSS stylesheets when using JDK 15 In-Reply-To: <916eD15crXE2JD07BTIrBOEORV2rQal8fqSmOhnmHlo=.0df77a8c-6413-4b89-967d-38893b56b981@github.com> References: <916eD15crXE2JD07BTIrBOEORV2rQal8fqSmOhnmHlo=.0df77a8c-6413-4b89-967d-38893b56b981@github.com> Message-ID: On Mon, 5 Oct 2020 07:08:33 GMT, Arun Joseph wrote: > Issue: In JDK15, > [URLConnection](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/net/www/URLConnection.java) > class overrode the getHeaderFields() methods to return properties, which previously returned an empty map from its > super class. Fix: Extract headers only when it's a HttpURLConnection, otherwise return an empty String. Looks good. I think a single reviewer is sufficient, unless you want another pair of eyes on it. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/314 From ajoseph at openjdk.java.net Tue Oct 6 03:38:36 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 6 Oct 2020 03:38:36 GMT Subject: Integrated: 8253696: WebEngine refuses to load local "file:///" CSS stylesheets when using JDK 15 In-Reply-To: <916eD15crXE2JD07BTIrBOEORV2rQal8fqSmOhnmHlo=.0df77a8c-6413-4b89-967d-38893b56b981@github.com> References: <916eD15crXE2JD07BTIrBOEORV2rQal8fqSmOhnmHlo=.0df77a8c-6413-4b89-967d-38893b56b981@github.com> Message-ID: <31uTJYR17AoehbowYgT6Die9z00UYtSn2Z0cEQrhqe4=.be7f11be-5354-4243-a37a-ab50191030bd@github.com> On Mon, 5 Oct 2020 07:08:33 GMT, Arun Joseph wrote: > Issue: In JDK15, > [URLConnection](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/net/www/URLConnection.java) > class overrode the getHeaderFields() methods to return properties, which previously returned an empty map from its > super class. Fix: Extract headers only when it's a HttpURLConnection, otherwise return an empty String. This pull request has now been integrated. Changeset: 15e52d8f Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/15e52d8f Stats: 24 lines in 3 files changed: 15 ins; 0 del; 9 mod 8253696: WebEngine refuses to load local "file:///" CSS stylesheets when using JDK 15 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/314 From arapte at openjdk.java.net Tue Oct 6 09:52:37 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 6 Oct 2020 09:52:37 GMT Subject: RFR: 8252192: Update to Visual Studio 2019 version 16.7.2 In-Reply-To: References: Message-ID: <_v-LnpRudvRYfzZVkIr_7TdFYX7c59AhRUwKtIQmPnI=.b047ba7d-bdda-471f-9f0c-5beafbcbbf44@github.com> On Tue, 29 Sep 2020 23:38:39 GMT, Kevin Rushforth wrote: > This patch updates the compiler to Visual Studio 2019 version 16.7.2 on Windows, in order to match JDK 16 -- see > [JDK-8253615](https://bugs.openjdk.java.net/browse/JDK-8253615). > I ran a full build and test, including media and WebKit. Build and sanity test looks good on my machine. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/312 From arapte at openjdk.java.net Tue Oct 6 09:55:40 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 6 Oct 2020 09:55:40 GMT Subject: RFR: 8252191: Update to gcc 10.2 on Linux In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 23:34:55 GMT, Kevin Rushforth wrote: > This patch updates the compiler to gcc 10.2 on Linux, in order to match JDK 16 -- see > [JDK-8253616](https://bugs.openjdk.java.net/browse/JDK-8253616). > I ran a full build and test, including media and WebKit. Build and sanity test looks good on my machine. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/311 From jvos at openjdk.java.net Tue Oct 6 10:50:41 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 6 Oct 2020 10:50:41 GMT Subject: RFR: 8252191: Update to gcc 10.2 on Linux In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 09:52:34 GMT, Ambarish Rapte wrote: > Build and sanity test looks good on my machine. What OS are you using? (I'm running a test on Ubuntu 18.04) ------------- PR: https://git.openjdk.java.net/jfx/pull/311 From kcr at openjdk.java.net Tue Oct 6 12:56:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Oct 2020 12:56:04 GMT Subject: RFR: 8252191: Update to gcc 10.2 on Linux In-Reply-To: References: Message-ID: <_aHvlLJ4xtB19Oyd7is-LyJHKglLubBBSdTiJ7tRaMQ=.8f38e4f7-f346-47fa-a7a6-e346e23a3d01@github.com> On Tue, 6 Oct 2020 10:47:47 GMT, Johan Vos wrote: >> Build and sanity test looks good on my machine. > >> Build and sanity test looks good on my machine. > > What OS are you using? (I'm running a test on Ubuntu 18.04) I've run tests on Ubuntu 16.04, Ubuntu 20.04, and Oracle Linux 7. ------------- PR: https://git.openjdk.java.net/jfx/pull/311 From jvos at openjdk.java.net Tue Oct 6 13:02:06 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 6 Oct 2020 13:02:06 GMT Subject: RFR: 8252191: Update to gcc 10.2 on Linux In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 23:34:55 GMT, Kevin Rushforth wrote: > This patch updates the compiler to gcc 10.2 on Linux, in order to match JDK 16 -- see > [JDK-8253616](https://bugs.openjdk.java.net/browse/JDK-8253616). > I ran a full build and test, including media and WebKit. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/311 From jvos at openjdk.java.net Tue Oct 6 13:02:07 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 6 Oct 2020 13:02:07 GMT Subject: RFR: 8252191: Update to gcc 10.2 on Linux In-Reply-To: <_aHvlLJ4xtB19Oyd7is-LyJHKglLubBBSdTiJ7tRaMQ=.8f38e4f7-f346-47fa-a7a6-e346e23a3d01@github.com> References: <_aHvlLJ4xtB19Oyd7is-LyJHKglLubBBSdTiJ7tRaMQ=.8f38e4f7-f346-47fa-a7a6-e346e23a3d01@github.com> Message-ID: On Tue, 6 Oct 2020 12:53:34 GMT, Kevin Rushforth wrote: >>> Build and sanity test looks good on my machine. >> >> What OS are you using? (I'm running a test on Ubuntu 18.04) > > I've run tests on Ubuntu 16.04, Ubuntu 20.04, and Oracle Linux 7. I confirm it works on Ubuntu 18.04 ------------- PR: https://git.openjdk.java.net/jfx/pull/311 From arapte at openjdk.java.net Tue Oct 6 13:17:10 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 6 Oct 2020 13:17:10 GMT Subject: RFR: 8252191: Update to gcc 10.2 on Linux In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 12:59:39 GMT, Johan Vos wrote: >> This patch updates the compiler to gcc 10.2 on Linux, in order to match JDK 16 -- see >> [JDK-8253616](https://bugs.openjdk.java.net/browse/JDK-8253616). >> I ran a full build and test, including media and WebKit. > > Marked as reviewed by jvos (Reviewer). > What OS are you using? (I'm running a test on Ubuntu 18.04) I also have 18.04. ------------- PR: https://git.openjdk.java.net/jfx/pull/311 From kcr at openjdk.java.net Tue Oct 6 13:52:03 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Oct 2020 13:52:03 GMT Subject: Integrated: 8252191: Update to gcc 10.2 on Linux In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 23:34:55 GMT, Kevin Rushforth wrote: > This patch updates the compiler to gcc 10.2 on Linux, in order to match JDK 16 -- see > [JDK-8253616](https://bugs.openjdk.java.net/browse/JDK-8253616). > I ran a full build and test, including media and WebKit. This pull request has now been integrated. Changeset: 1c485a3c Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/1c485a3c Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8252191: Update to gcc 10.2 on Linux Reviewed-by: arapte, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/311 From kcr at openjdk.java.net Tue Oct 6 14:00:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Oct 2020 14:00:11 GMT Subject: RFR: 8252192: Update to Visual Studio 2019 version 16.7.2 [v2] In-Reply-To: References: Message-ID: > This patch updates the compiler to Visual Studio 2019 version 16.7.2 on Windows, in order to match JDK 16 -- see > [JDK-8253615](https://bugs.openjdk.java.net/browse/JDK-8253615). > I ran a full build and test, including media and WebKit. Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into 8252192-vs2019-16.7.2 - 8252192: Update to Visual Studio 2019 version 16.7.2 ------------- Changes: https://git.openjdk.java.net/jfx/pull/312/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=312&range=01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/312.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/312/head:pull/312 PR: https://git.openjdk.java.net/jfx/pull/312 From kcr at openjdk.java.net Tue Oct 6 14:00:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Oct 2020 14:00:11 GMT Subject: RFR: 8252192: Update to Visual Studio 2019 version 16.7.2 [v2] In-Reply-To: <_v-LnpRudvRYfzZVkIr_7TdFYX7c59AhRUwKtIQmPnI=.b047ba7d-bdda-471f-9f0c-5beafbcbbf44@github.com> References: <_v-LnpRudvRYfzZVkIr_7TdFYX7c59AhRUwKtIQmPnI=.b047ba7d-bdda-471f-9f0c-5beafbcbbf44@github.com> Message-ID: <1RkEuLLQmvwrhERpba6smQvbyXg79z2NIWxRD3k2p2A=.480f34b9-5c99-4dca-91d9-cb12a4039454@github.com> On Tue, 6 Oct 2020 09:50:26 GMT, Ambarish Rapte wrote: >> Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains two commits: >> - Merge branch 'master' into 8252192-vs2019-16.7.2 >> - 8252192: Update to Visual Studio 2019 version 16.7.2 > > Build and sanity test looks good on my machine(Edit: Win10). I just merged `master` in order to fix a trivial (and expected) merge conflict following the integration of the gcc 10.2 update. ------------- PR: https://git.openjdk.java.net/jfx/pull/312 From jvos at openjdk.java.net Tue Oct 6 15:18:04 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 6 Oct 2020 15:18:04 GMT Subject: RFR: 8252192: Update to Visual Studio 2019 version 16.7.2 [v2] In-Reply-To: <1RkEuLLQmvwrhERpba6smQvbyXg79z2NIWxRD3k2p2A=.480f34b9-5c99-4dca-91d9-cb12a4039454@github.com> References: <_v-LnpRudvRYfzZVkIr_7TdFYX7c59AhRUwKtIQmPnI=.b047ba7d-bdda-471f-9f0c-5beafbcbbf44@github.com> <1RkEuLLQmvwrhERpba6smQvbyXg79z2NIWxRD3k2p2A=.480f34b9-5c99-4dca-91d9-cb12a4039454@github.com> Message-ID: On Tue, 6 Oct 2020 13:54:44 GMT, Kevin Rushforth wrote: >> Build and sanity test looks good on my machine(Edit: Win10). > > I just merged `master` in order to fix a trivial (and expected) merge conflict following the integration of the gcc > 10.2 update. @tiainen can you build this on our farm? ------------- PR: https://git.openjdk.java.net/jfx/pull/312 From sykora at openjdk.java.net Tue Oct 6 16:38:06 2020 From: sykora at openjdk.java.net (Joeri Sykora) Date: Tue, 6 Oct 2020 16:38:06 GMT Subject: RFR: 8252192: Update to Visual Studio 2019 version 16.7.2 [v2] In-Reply-To: References: <_v-LnpRudvRYfzZVkIr_7TdFYX7c59AhRUwKtIQmPnI=.b047ba7d-bdda-471f-9f0c-5beafbcbbf44@github.com> <1RkEuLLQmvwrhERpba6smQvbyXg79z2NIWxRD3k2p2A=.480f34b9-5c99-4dca-91d9-cb12a4039454@github.com> Message-ID: <9Ui0f57oMvUNae-QAgDhO_9njSoZZ8uRbUMyNIf_cT8=.42b98b66-5e85-4e05-a457-c77744e2daac@github.com> On Tue, 6 Oct 2020 15:15:51 GMT, Johan Vos wrote: >> I just merged `master` in order to fix a trivial (and expected) merge conflict following the integration of the gcc >> 10.2 update. > > @tiainen can you build this on our farm? Yes, I'll run a build against an updated Visual Studio 2019. ------------- PR: https://git.openjdk.java.net/jfx/pull/312 From kcr at openjdk.java.net Tue Oct 6 16:39:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Oct 2020 16:39:11 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: Message-ID: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> On Tue, 22 Sep 2020 07:35:49 GMT, yosbits wrote: >> https://bugs.openjdk.java.net/browse/JDK-8253086 >> >> ObservableListWrapper.java >> * public boolean removeAll(Collection c) >> * public boolean retainAll(Collection c) >> >> These two methods use BitSet, but it doesn't make sense. >> By rewriting to the equivalent behavior that does not use BitSet, it is possible to reduce the CPU load in a wide range >> of use cases. >> The test is done with the following command. >> >> * gradle base: test >> * gradle controls: test > > yosbits has refreshed the contents of this pull request, and previous commits have been removed. The incremental views > will show differences compared to the previous content of the PR. As mentioned in a reply to a comment by @kleopatra , this fix will cause a regression in behavior, and cannot be integrated in its current form. A two-pass algorithm is still needed: the first pass collects the elements to be removed, the second pass actually removes them. While it isn't necessary to use a BitSet to collect the indexes to be removed, that does seems a reasonable approach. Unless there is a good reason to change it to some other two-pass algorithm, it's probably best to leave it as-is, in which case this PR and the associated JBS issue can be withdrawn. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/305 From nlisker at openjdk.java.net Tue Oct 6 17:13:04 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 6 Oct 2020 17:13:04 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <6Y6MJeDT7ivvVswJ6zhDapayIfAMVkCv74cFERDXpZM=.a8ceedff-738a-454b-9162-f557886e0db4@github.com> <43kECsA18C2b-Hy9rptZuhQYrxuXpOwVfjWy0DwaVvA=.22cb8220-9225-401a-96db-729da45c7b60@github.com> Message-ID: On Mon, 5 Oct 2020 19:22:41 GMT, Kevin Rushforth wrote: >>> The listView test is passing for the bitSet and for the back-to-front approach. Can we imagine a context where the >>> broken selectedItems impl would add wreckage to the latter? >> >> To answer my own question: yes. A failing test with the back-to-front approach (the existing test in ListViewTest >> modified in having the last item selected) >> @Test public void test_rt35857Back() { >> ObservableList fxList = FXCollections.observableArrayList("A", "B", "C"); >> final ListView listView = new ListView(fxList); >> >> listView.getSelectionModel().select(2); >> >> ObservableList selectedItems = >> listView.getSelectionModel().getSelectedItems(); >> assertEquals(1, selectedItems.size()); >> assertEquals("C", selectedItems.get(0)); >> >> listView.getItems().removeAll(selectedItems); >> assertEquals(2, fxList.size()); >> assertEquals("A", fxList.get(0)); >> assertEquals("B", fxList.get(1)); >> } >> >> Feels like coming nearer to the why of the BitSet approach: it guards against the scenario where changing the current >> list implicitly changes the list given as parameter - in that case, it's unsafe to query the parameter list while >> removing items (c.contains simply reports nonsense). This may happen whenever the parameter list does some kind of >> live lookup into the current list (such as f.i. SelectedItemsReadOnlyObservableList) - which is not as evil as I >> thought yesterday (did it myself in custom selectionModels ;) The BitSet solves it by a two-pass approach: first >> collect all items to remove/retain without (that is keep the parameter list in a valid state, allowing to safely access >> it), then do the removal without further accessing the (then invalid) parameter list. The fix at that time was a >> deliberate decision by the designer of the collections, so the context when it happens was deemed a valid use-case. >> Looks like we should **not** revert it. > > Nice catch! So now it's clear that the current approach was adopted because the source list itself can change as a > result of removing an element from the target list in some cases, such as the one you pointed out above. I filed > [JDK-8254040](https://bugs.openjdk.java.net/browse/JDK-8254040) to add the test case you listed above so we avoid a > possible future regression. So a two-pass algorithm is still needed: the first one to collect the elements to be > removed, the second to actually remove them. While it isn't necessary to use a BitSet to collect the indexes to be > removed, that does seems a reasonable approach. Unless there is a good reason to change it to some other two-pass > algorithm, it's probably best to leave it as-is, in which case this PR and the associated JBS issue can be withdrawn. @kleopatra Thanks for the investigation. I had a feeling there is a practical reason and not a lack of skill :) If there is no way to do removal simultaneously then we indeed need to keep the 2-pass approach. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From sykora at openjdk.java.net Tue Oct 6 20:24:08 2020 From: sykora at openjdk.java.net (Joeri Sykora) Date: Tue, 6 Oct 2020 20:24:08 GMT Subject: RFR: 8252192: Update to Visual Studio 2019 version 16.7.2 [v2] In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 14:00:11 GMT, Kevin Rushforth wrote: >> This patch updates the compiler to Visual Studio 2019 version 16.7.2 on Windows, in order to match JDK 16 -- see >> [JDK-8253615](https://bugs.openjdk.java.net/browse/JDK-8253615). >> I ran a full build and test, including media and WebKit. > > Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains two commits: > - Merge branch 'master' into 8252192-vs2019-16.7.2 > - 8252192: Update to Visual Studio 2019 version 16.7.2 Build and sanity test completed successfully. ------------- Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/312 From jvos at openjdk.java.net Tue Oct 6 21:11:05 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 6 Oct 2020 21:11:05 GMT Subject: RFR: 8252192: Update to Visual Studio 2019 version 16.7.2 [v2] In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 14:00:11 GMT, Kevin Rushforth wrote: >> This patch updates the compiler to Visual Studio 2019 version 16.7.2 on Windows, in order to match JDK 16 -- see >> [JDK-8253615](https://bugs.openjdk.java.net/browse/JDK-8253615). >> I ran a full build and test, including media and WebKit. > > Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains two commits: > - Merge branch 'master' into 8252192-vs2019-16.7.2 > - 8252192: Update to Visual Studio 2019 version 16.7.2 Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/312 From github.com+7517141+yososs at openjdk.java.net Wed Oct 7 08:10:10 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Wed, 7 Oct 2020 08:10:10 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> Message-ID: On Tue, 6 Oct 2020 16:36:44 GMT, Kevin Rushforth wrote: >> yosbits has refreshed the contents of this pull request, and previous commits have been removed. The incremental views >> will show differences compared to the previous content of the PR. > > As mentioned in a reply to a comment by @kleopatra , this fix will cause a regression in behavior, and cannot be > integrated in its current form. > A two-pass algorithm is still needed: the first pass collects the elements to be removed, the second pass actually > removes them. While it isn't necessary to use a BitSet to collect the indexes to be removed, that does seems a > reasonable approach. Unless there is a good reason to change it to some other two-pass algorithm, it's probably best to > leave it as-is, in which case this PR and the associated JBS issue can be withdrawn. The error occurs as specified in getSelectedItems(). It seems to be correct to write the following `listView.getItems().removeAll(new HashSet<>(selectedItems)) ` It could be interpreted that the intention was to mitigate the side effects associated with the getSelectedItems() specification. The use of BitSet should be avoided when the list is large, as it is not a sparse implementation and therefore wastes a lot of memory. For example, when removing the last item in the list. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From arapte at openjdk.java.net Wed Oct 7 09:28:06 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 7 Oct 2020 09:28:06 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification [v4] In-Reply-To: <0UXvqSHXhA9KxweOoUbiLLgk_M919soTNP_O3-1qPyI=.e82aa5ac-919a-4e73-8d42-681f6e676541@github.com> References: <0UXvqSHXhA9KxweOoUbiLLgk_M919soTNP_O3-1qPyI=.e82aa5ac-919a-4e73-8d42-681f6e676541@github.com> Message-ID: On Sat, 26 Sep 2020 16:04:16 GMT, Leon Linhart wrote: >> Hi, this PR fixes [JDK-8251946](https://bugs.openjdk.java.net/browse/JDK-8251946) computing whether the list was >> actually modified instead of just returning `true`. The list was modified if 1. it was not empty (modified by calling >> `#clear()`), or if 2. it was modified as result of the `#addAll()` call. >> >> If you want any test coverage for this please let me know. >> >> I reported the issue a couple of days ago via web formula and waited for the confirmation to open this PR but now I see >> that @kevinrushforth (sorry for pinging) is already assigned to the JBS issue. I'm not too familiar with how you handle >> JBS issues or more specifically whether assigning is used to indicate that the issue is in the assignee's "domain", or >> that the assignee is already working on it. In the latter case, please feel free to close this PR. (My OCA submission >> is still pending anyway.) > > Leon Linhart has updated the pull request incrementally with one additional commit since the last revision: > > Test return value of setAll on an empty list Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/284 From fastegal at openjdk.java.net Wed Oct 7 09:41:04 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 7 Oct 2020 09:41:04 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> Message-ID: <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> On Wed, 7 Oct 2020 08:07:52 GMT, yosbits wrote: > > > The error occurs as specified in getSelectedItems(). no, both spec and implementation (at least as far as its relation to this issue) is correct. > It seems to be correct to write the following > > `listView.getItems().removeAll(new HashSet<>(selectedItems)) ` > > (or ArrayList) > asking client code to adopt to changes in the framework is not an option > It could be interpreted that the intention was to mitigate the side effects associated with the getSelectedItems() > specification. no side-effects, nothing mitigated, : it's a deliberate, full-fledged support of source lists that change on removing items from the target list > The use of BitSet should be avoided when the list is large, as it is not a sparse implementation and therefore wastes a > lot of memory. For example, when removing the last item in the list. > `BitSet bs = new BitSet(c.size()); ` > The previous change was an incorrect initialization size for BitSet. feel free to suggest another (working without requiring changes to client code) two-pass approach in remove/retainAll. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From tschindl at openjdk.java.net Wed Oct 7 10:42:15 2020 From: tschindl at openjdk.java.net (Tom Schindl) Date: Wed, 7 Oct 2020 10:42:15 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> Message-ID: On Wed, 7 Oct 2020 09:38:40 GMT, Jeanette Winzenburg wrote: >> The error occurs as specified in getSelectedItems(). It seems to be correct to write the following >> >> `listView.getItems().removeAll(new HashSet<>(selectedItems)) >> ` >> >> (or ArrayList) >> >> It could be interpreted that the intention was to mitigate the side effects associated with the getSelectedItems() >> specification. >> The use of BitSet should be avoided when the list is large, as it is not a sparse implementation and therefore wastes a >> lot of memory. For example, when removing the last item in the list. >> `BitSet bs = new BitSet(c.size()); >> ` >> The previous change was an incorrect initialization size for BitSet. > >> >> >> The error occurs as specified in getSelectedItems(). > > no, both spec and implementation (at least as far as its relation to this issue) is correct. > >> It seems to be correct to write the following >> >> `listView.getItems().removeAll(new HashSet<>(selectedItems)) ` >> >> (or ArrayList) >> > > asking client code to adopt to changes in the framework is not an option > >> It could be interpreted that the intention was to mitigate the side effects associated with the getSelectedItems() >> specification. > > no side-effects, nothing mitigated, : it's a deliberate, full-fledged support of source lists that change on removing > items from the target list >> The use of BitSet should be avoided when the list is large, as it is not a sparse implementation and therefore wastes a >> lot of memory. For example, when removing the last item in the list. >> `BitSet bs = new BitSet(c.size()); ` >> The previous change was an incorrect initialization size for BitSet. > > feel free to suggest another (working without requiring changes to client code) two-pass approach in remove/retainAll. did anyone look into Java-Collection-Frameworks (ArrayList and friends or Eclipse-Collections) how they handle this situation effeciently? ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From fastegal at openjdk.java.net Wed Oct 7 11:15:09 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 7 Oct 2020 11:15:09 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> Message-ID: On Wed, 7 Oct 2020 10:39:02 GMT, Tom Schindl wrote: > > > did anyone look into Java-Collection-Frameworks (ArrayList and friends or Eclipse-Collections) how they handle this > situation effeciently? not me - but good idea, provided they support modifications to the source list while removing. BTW, just noticed that Tree/Table/View never had the issue that was fixed with introducing the two-pass approach, can't nail why not - they are using the same selectedItems (from MultipleSelectionModelBase), any ideas? ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From fastegal at openjdk.java.net Wed Oct 7 11:33:08 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 7 Oct 2020 11:33:08 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> Message-ID: <8RPQPZ5DKF4l1AKAjtDeIfbVchuQGzxQP4I9ewOeezE=.0c3d5c61-1acf-4923-bc48-3999ad78b829@github.com> On Wed, 7 Oct 2020 11:12:43 GMT, Jeanette Winzenburg wrote: > BTW, just noticed that Tree/Table/View never had the issue that was fixed with introducing the two-pass approach, can't > nail why not - they are using the same selectedItems (from MultipleSelectionModelBase), any ideas? because it's not a live-lookup: TreeView keeps some cache of exposed treeItems - that's to where the getModelItem() in selectedItems is delegated to - which is updated on receiving a listChange, that is not during the modification. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+7517141+yososs at openjdk.java.net Wed Oct 7 11:42:11 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Wed, 7 Oct 2020 11:42:11 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: <8RPQPZ5DKF4l1AKAjtDeIfbVchuQGzxQP4I9ewOeezE=.0c3d5c61-1acf-4923-bc48-3999ad78b829@github.com> References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> <8RPQPZ5DKF4l1AKAjtDeIfbVchuQGzxQP4I9ewOeezE=.0c3d5c61-1acf-4923-bc48-3999ad78b829@github.com> Message-ID: On Wed, 7 Oct 2020 11:30:16 GMT, Jeanette Winzenburg wrote: >>> >>> >>> did anyone look into Java-Collection-Frameworks (ArrayList and friends or Eclipse-Collections) how they handle this >>> situation effeciently? >> >> not me - but good idea, provided they support modifications to the source list while removing. >> >> BTW, just noticed that Tree/Table/View never had the issue that was fixed with introducing the two-pass approach, can't >> nail why not - they are using the same selectedItems (from MultipleSelectionModelBase), any ideas? > >> BTW, just noticed that Tree/Table/View never had the issue that was fixed with introducing the two-pass approach, can't >> nail why not - they are using the same selectedItems (from MultipleSelectionModelBase), any ideas? > > because it's not a live-lookup: TreeView keeps some cache of exposed treeItems - that's to where the getModelItem() in > selectedItems is delegated to - which is updated on receiving a listChange, that is not during the modification. I'm preparing a change that won't break compatibility, so stay tuned. The test seems to need to be added. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From fastegal at openjdk.java.net Wed Oct 7 12:09:14 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 7 Oct 2020 12:09:14 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> <8RPQPZ5DKF4l1AKAjtDeIfbVchuQGzxQP4I9ewOeezE=.0c3d5c61-1acf-4923-bc48-3999ad78b829@github.com> Message-ID: On Wed, 7 Oct 2020 11:39:29 GMT, yosbits wrote: > > > I'm preparing a change that won't break compatibility, so stay tuned. > The test seems to need to be added. sounds good :) Note, that I'm working on [JDK-8254040](https://bugs.openjdk.java.net/browse/JDK-8254040) which will add regression tests that your change will have to pass (turned out that f.i. FilteredList also relies on the two-pass approach). Until you are done, you might consider changing the state of this to Draft. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+370894+ebresie at openjdk.java.net Wed Oct 7 12:14:10 2020 From: github.com+370894+ebresie at openjdk.java.net (Eric Bresie) Date: Wed, 7 Oct 2020 12:14:10 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> <8RPQPZ5DKF4l1AKAjtDeIfbVchuQGzxQP4I9ewOeezE=.0c3d5c61-1acf-4923-bc48-3999ad78b829@github.com> Message-ID: On Wed, 7 Oct 2020 12:06:09 GMT, Jeanette Winzenburg wrote: >> I'm preparing a change that won't break compatibility, so stay tuned. >> The test seems to need to be added. > >> >> >> I'm preparing a change that won't break compatibility, so stay tuned. >> The test seems to need to be added. > > sounds good :) Note, that I'm working on [JDK-8254040](https://bugs.openjdk.java.net/browse/JDK-8254040) which will add > regression tests that your change will have to pass (turned out that f.i. FilteredList also relies on the two-pass > approach). Until you are done, you might consider changing the state of this to Draft. Hopefully not looking in the wrong version but: (1) When dealing with BitSets previously, maybe this was by design butI didn?t see any usage of BitSet?s ?clear()? to remove items from the BitSet. Although given move to remove it may be moot now. (2) If no longer using the BitSet, may want to remove the import for this (3) In context, usage of HashSet was suggested. I don?t believe HashSet is thread safe. If using it, may want to consider ConcurrentHashSet. Although not sure if this is more efficient either. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+4029915+themrmilchmann at openjdk.java.net Wed Oct 7 12:51:12 2020 From: github.com+4029915+themrmilchmann at openjdk.java.net (Leon Linhart) Date: Wed, 7 Oct 2020 12:51:12 GMT Subject: Integrated: 8251946: ObservableList.setAll does not conform to specification In-Reply-To: References: Message-ID: On Tue, 18 Aug 2020 19:50:55 GMT, Leon Linhart wrote: > Hi, this PR fixes [JDK-8251946](https://bugs.openjdk.java.net/browse/JDK-8251946) computing whether the list was > actually modified instead of just returning `true`. The list was modified if 1. it was not empty (modified by calling > `#clear()`), or if 2. it was modified as result of the `#addAll()` call. > > If you want any test coverage for this please let me know. > > I reported the issue a couple of days ago via web formula and waited for the confirmation to open this PR but now I see > that @kevinrushforth (sorry for pinging) is already assigned to the JBS issue. I'm not too familiar with how you handle > JBS issues or more specifically whether assigning is used to indicate that the issue is in the assignee's "domain", or > that the assignee is already working on it. In the latter case, please feel free to close this PR. (My OCA submission > is still pending anyway.) This pull request has now been integrated. Changeset: 78570225 Author: Leon Linhart Committer: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/78570225 Stats: 28 lines in 3 files changed: 25 ins; 2 del; 1 mod 8251946: ObservableList.setAll does not conform to specification Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/284 From arapte at openjdk.java.net Wed Oct 7 12:57:18 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 7 Oct 2020 12:57:18 GMT Subject: RFR: 8252192: Update to Visual Studio 2019 version 16.7.2 [v2] In-Reply-To: References: Message-ID: <3Msr7G8Qp-H1b1qCUMjeGAWojoaSBiBdYDepx4O4SGs=.75eaf25d-75cc-476f-aa95-4ed649283f06@github.com> On Tue, 6 Oct 2020 14:00:11 GMT, Kevin Rushforth wrote: >> This patch updates the compiler to Visual Studio 2019 version 16.7.2 on Windows, in order to match JDK 16 -- see >> [JDK-8253615](https://bugs.openjdk.java.net/browse/JDK-8253615). >> I ran a full build and test, including media and WebKit. > > Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains two commits: > - Merge branch 'master' into 8252192-vs2019-16.7.2 > - 8252192: Update to Visual Studio 2019 version 16.7.2 Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/312 From kcr at openjdk.java.net Wed Oct 7 13:09:10 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 7 Oct 2020 13:09:10 GMT Subject: Integrated: 8252192: Update to Visual Studio 2019 version 16.7.2 In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 23:38:39 GMT, Kevin Rushforth wrote: > This patch updates the compiler to Visual Studio 2019 version 16.7.2 on Windows, in order to match JDK 16 -- see > [JDK-8253615](https://bugs.openjdk.java.net/browse/JDK-8253615). > I ran a full build and test, including media and WebKit. This pull request has now been integrated. Changeset: 184f12c8 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/184f12c8 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8252192: Update to Visual Studio 2019 version 16.7.2 Reviewed-by: arapte, sykora, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/312 From github.com+7517141+yososs at openjdk.java.net Wed Oct 7 14:28:15 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Wed, 7 Oct 2020 14:28:15 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> <8RPQPZ5DKF4l1AKAjtDeIfbVchuQGzxQP4I9ewOeezE=.0c3d5c61-1acf-4923-bc48-3999ad78b829@github.com> Message-ID: <97c408eWbFu-K_ZFbonKB_ex33oEgoo6IvOmAa_Bz5A=.a89956b6-be86-41ee-aded-1710ca099b5a@github.com> On Wed, 7 Oct 2020 12:11:12 GMT, Eric Bresie wrote: >>> >>> >>> I'm preparing a change that won't break compatibility, so stay tuned. >>> The test seems to need to be added. >> >> sounds good :) Note, that I'm working on [JDK-8254040](https://bugs.openjdk.java.net/browse/JDK-8254040) which will add >> regression tests that your change will have to pass (turned out that f.i. FilteredList also relies on the two-pass >> approach). Until you are done, you might consider changing the state of this to Draft. > > Hopefully not looking in the wrong version but: > (1) When dealing with BitSets previously, maybe this was by design butI didn?t see any usage of BitSet?s > ?clear()? to remove items from the BitSet. Although given move to remove it may be moot now. (2) If no longer > using the BitSet, may want to remove the import for this (3) In context, usage of HashSet was suggested. I don?t > believe HashSet is thread safe. If using it, may want to consider ConcurrentHashSet. Although not sure if this is > more efficient either. I plan to push changes that remain compatible, respecting the judgment of the project leader, but I would like to point out the following: There seems to be a problem with the reproduction code as follows. * If there are duplicate items, the unselected parts will also be deleted. * Using selectIndices () is more advantageous in terms of performance than selectedItems (). Therefore, this context should normally be avoided, Seems like less important compatibility. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+7517141+yososs at openjdk.java.net Wed Oct 7 18:37:09 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Wed, 7 Oct 2020 18:37:09 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: <97c408eWbFu-K_ZFbonKB_ex33oEgoo6IvOmAa_Bz5A=.a89956b6-be86-41ee-aded-1710ca099b5a@github.com> References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> <8RPQPZ5DKF4l1AKAjtDeIfbVchuQGzxQP4I9ewOeezE=.0c3d5c61-1acf-4923-bc48-3999ad78b829@github.com> <97c408eWbFu-K_ZFbonKB_ex33oEgoo6IvOmAa_Bz5A=.a89956b6-be86-41ee-aded-1710ca099b5a@github.com> Message-ID: On Wed, 7 Oct 2020 14:24:36 GMT, yosbits wrote: >> Hopefully not looking in the wrong version but: >> (1) When dealing with BitSets previously, maybe this was by design butI didn?t see any usage of BitSet?s >> ?clear()? to remove items from the BitSet. Although given move to remove it may be moot now. (2) If no longer >> using the BitSet, may want to remove the import for this (3) In context, usage of HashSet was suggested. I don?t >> believe HashSet is thread safe. If using it, may want to consider ConcurrentHashSet. Although not sure if this is >> more efficient either. > > I plan to push changes that remain compatible, respecting the judgment of the project leader, but I would like to point > out the following: > There seems to be a problem with the reproduction code as follows. > > * If there are duplicate items, the unselected parts will also be deleted. > * Using getSelectedIndices() is more advantageous in terms of performance than getSelectedItems (). > > Therefore, this context should normally be avoided, > Seems like less important compatibility. The next implementation will probably have a good balance between space and time. Currently being tested. Performance can be further improved by using ArrayList and int []. Java @Override public boolean removeAll(Collection c) { // Throw NullPointerException if c is null if (c.isEmpty() || this.isEmpty()) { return false; } List runLengths = new java.util.ArrayList<>(); { int run = 0; boolean flag = true; for (int i=size()-1; i>=0; i--) { if (c.contains(get(i))==flag) { run++; } else { runLengths.add(run); run = 1; flag = !flag; } } if (run>0 && flag) { runLengths.add(run); } } boolean flag = true; boolean removed = false; if(runLengths.size()>0) { beginChange(); int cur = size()-1; for (int run:runLengths) { if(flag) { for(int to=cur-run; cur > to; cur--) { remove(cur); removed = true; } }else { cur -= run; } flag = !flag; } endChange(); return removed; } return false; } @Override public boolean retainAll(Collection c) { // Throw NullPointerException if c is null if (c.isEmpty()) { boolean retained = !this.isEmpty(); if (retained) { clear(); } return retained; } if (this.isEmpty()) { return false; } List runLengths = new java.util.ArrayList<>(); { int run = 0; boolean flag = false; for (int i=size()-1; i>=0; i--) { if (c.contains(get(i))!=flag) { run++; } else { runLengths.add(run); run = 1; flag = !flag; } } if (run>0 && flag) { runLengths.add(run); } } boolean flag = false; boolean removed = false; if (runLengths.size()>0) { beginChange(); int cur = size()-1; for (int run:runLengths) { if(flag) { for(int to=cur-run; cur > to; cur--) { remove(cur); removed = true; } }else { cur -= run; } flag = !flag; } endChange(); return removed; } return false; } I'm planning to push it in a few days. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+7517141+yososs at openjdk.java.net Thu Oct 8 06:52:56 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Thu, 8 Oct 2020 06:52:56 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v5] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8253086 > > ObservableListWrapper.java > * public boolean removeAll(Collection c) > * public boolean retainAll(Collection c) > > These two methods use BitSet, but it doesn't make sense. > By rewriting to the equivalent behavior that does not use BitSet, it is possible to reduce the CPU load in a wide range > of use cases. > The test is done with the following command. > > * gradle base: test > * gradle controls: test yosbits has updated the pull request incrementally with one additional commit since the last revision: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/305/files - new: https://git.openjdk.java.net/jfx/pull/305/files/8b319c6d..93aeda88 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=305&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=305&range=03-04 Stats: 146 lines in 3 files changed: 96 ins; 9 del; 41 mod Patch: https://git.openjdk.java.net/jfx/pull/305.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/305/head:pull/305 PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+7517141+yososs at openjdk.java.net Thu Oct 8 06:53:09 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Thu, 8 Oct 2020 06:53:09 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> <8RPQPZ5DKF4l1AKAjtDeIfbVchuQGzxQP4I9ewOeezE=.0c3d5c61-1acf-4923-bc48-3999ad78b829@github.com> <97c408eWbFu-K_ZFbonKB_ex33oEgoo6IvOmAa_Bz5A=.a89956b6-be86-41ee-aded-1710ca099b5a@github.com> Message-ID: On Wed, 7 Oct 2020 18:34:23 GMT, yosbits wrote: >> I plan to push changes that remain compatible, respecting the judgment of the project leader, but I would like to point >> out the following: >> There seems to be a problem with the reproduction code as follows. >> >> * If there are duplicate items, the unselected parts will also be deleted. >> * Using getSelectedIndices() is more advantageous in terms of performance than getSelectedItems (). >> >> Therefore, this context should normally be avoided, >> Seems like less important compatibility. > > **The next implementation will probably have a good balance between space and time.** > Unless you do something like delete the even or odd indexes > The space efficiency is very high. > > Currently being tested. > > Java > @Override > public boolean removeAll(Collection c) { > // Throw NullPointerException if c is null > if (c.isEmpty() || this.isEmpty()) { > return false; > } > List runLengths = new java.util.ArrayList<>(); > { > int run = 0; > boolean flag = true; > for (int i=size()-1; i>=0; i--) { > if (c.contains(get(i))==flag) { > run++; > } else { > runLengths.add(run); > run = 1; > flag = !flag; > } > } > if (run>0 && flag) { > runLengths.add(run); > } > } > boolean flag = true; > boolean removed = false; > if(runLengths.size()>0) { > beginChange(); > int cur = size()-1; > for (int run:runLengths) { > if(flag) { > for(int to=cur-run; cur > to; cur--) { > remove(cur); > removed = true; > } > }else { > cur -= run; > } > flag = !flag; > } > endChange(); > return removed; > } > return false; > } > This implementation is more efficient by using an int [] array instead of an ArrayList. > > I'm planning to push it in a few days. It seems that many people are interested, so I pushed the change. I don't understand how to proceed with the review on Github correctly, so if I have anything to do, please comment. java for(int to=cur-run; cur > to; cur--) { remove(cur); } removed = true; This can be moved out of the loop and will be included in the next change. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From arapte at openjdk.java.net Thu Oct 8 07:59:48 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 8 Oct 2020 07:59:48 GMT Subject: RFR: 8244297: memory leak test utility [v5] In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 11:46:24 GMT, Florian Kirmaier wrote: >> It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 >> >> I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. >> >> It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. >> I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very >> stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but >> the tests with JMemoryBuddy are basically always correct. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8244297 > Fixing some wrong imports I have reviewed only in perspective of Java coding guidelines. I still have to review the functionality. Most of the comments are minor like variable name change and typos. I would recommend you to please go through all of the code to find and fix any other corrections related to Coding guidelines. modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 299: > 297: } > 298: > 299: } Please add an empty line at the end of file. modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 95: > 93: int counter = stepsLeft; > 94: > 95: if(weakReference.get() != null) { It requires a space after `if`, `for`, `while` statements to adhere to Java Coding guidelines. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/204 From arapte at openjdk.java.net Thu Oct 8 07:59:55 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 8 Oct 2020 07:59:55 GMT Subject: RFR: 8244297: memory leak test utility [v6] In-Reply-To: References: Message-ID: <4Yzd4sm7fdBWVb6_5DOrIsJRTcsof6fxgrKiYQOf_iA=.b291ffa5-f876-4a8c-a5bb-736fd8c2b14d@github.com> On Sat, 3 Oct 2020 16:00:48 GMT, Florian Kirmaier wrote: >> It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 >> >> I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. >> >> It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. >> I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very >> stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but >> the tests with JMemoryBuddy are basically always correct. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8244297 > Fixed unit-test modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 104: > 102: try { > 103: Thread.sleep(sleepTime); > 104: } catch (InterruptedException e) {} Ideally the exception should never occur, but in case it does then I think the test should be marked as failed. modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 132: > 130: * Checks whether the content of the WeakReference can not be collected. > 131: * @param weakReference The WeakReference to check. > 132: * @return Returns true, when the provided WeakReference can be collected. needs typo correction: can not be collected modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 152: > 150: f.accept(new MemoryTestAPI() { > 151: public void assertCollectable(Object ref) { > 152: if(ref == null) throw new NullPointerException(); `Object.requireNonNull()` method would be more suitable choice for null check. modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 47: > 45: > 46: private static int steps = 10; > 47: private static int overallTime = 1000; `overallTime` can be named as `totalDuration` or `testDuration` modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 48: > 46: private static int steps = 10; > 47: private static int overallTime = 1000; > 48: private static int sleepTime = overallTime / steps; `sleepTime` -> `sleepDuration` modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 52: > 50: private static int garbageAmount = 999999; > 51: private static String MX_BEAN_PROXY_TYPE = "com.sun.management:type=HotSpotDiagnostic"; > 52: private static String outputFolderString = "."; I am not sure of the directory that we use to save any runtime artifacts, but there must be one common directory that we should use here also. modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 56: > 54: static { > 55: outputFolderString = System.getProperty("jmemorybuddy.output","."); > 56: overallTime = Integer.parseInt(System.getProperty("jmemorybuddy.checktime","1000")); `sleepTime` should also be recomputed here based on `overallTime` modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 51: > 49: private static boolean createHeapdump = false; > 50: private static int garbageAmount = 999999; > 51: private static String MX_BEAN_PROXY_TYPE = "com.sun.management:type=HotSpotDiagnostic"; `MX_BEAN_PROXY_TYPE` is not constant, so it should not be all capital letters but should be named just like other variables. modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 88: > 86: * @return Returns true, when the provided WeakReference can be collected. > 87: */ > 88: public static boolean checkCollectable(WeakReference weakReference) { I would prefer a name like `checkIfCollected` or `checkIfGCed` modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 84: > 82: > 83: /** > 84: * Checks whether the content of the WeakReference can be collected. -> Checks whether the content of the WeakReference **is** collected. modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 113: > 111: if(weakReference.get() == null && counter < steps / 3) { > 112: int percentageUsed = (int) ((steps - counter) / steps * 100); > 113: System.out.println("Warning test seems to be unstable. time used: " + percentageUsed + "%"); Seems like candidate for `System.err.` modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 79: > 77: AssertCollectable assertCollectable = new AssertCollectable(weakReference); > 78: createHeapDump(); > 79: throw new AssertionError("Content of WeakReference was not collected. content: " + weakReference.get()); Can be replaced with `assertNull` modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 255: > 253: > 254: static class AssertCollectable { > 255: WeakReference assertCollectable; There is method, class member variable and class itself with the same name `assertCollectable`. I think they should be named differently, like for instance, 1. Class `AssertCollectable` can be named as `CollectableReferernce` or `ReferenceToBeGC` 2. The member variable `assertCollectable` can be named as just `weakRef` or `reference`. 3. The method `assertCollectable` can be named as `checkIfGCed` or `checkIfCollected` Similar change for `AssertNotCollectable` ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From github.com+370894+ebresie at openjdk.java.net Thu Oct 8 11:33:42 2020 From: github.com+370894+ebresie at openjdk.java.net (Eric Bresie) Date: Thu, 8 Oct 2020 11:33:42 GMT Subject: RFR: 8252192: Update to Visual Studio 2019 version 16.7.2 [v2] In-Reply-To: <3Msr7G8Qp-H1b1qCUMjeGAWojoaSBiBdYDepx4O4SGs=.75eaf25d-75cc-476f-aa95-4ed649283f06@github.com> References: <3Msr7G8Qp-H1b1qCUMjeGAWojoaSBiBdYDepx4O4SGs=.75eaf25d-75cc-476f-aa95-4ed649283f06@github.com> Message-ID: <1xE-4rDw5zd_t2uiBskIx7f0eiSJZt0U6ThBAr6v6h0=.e3ebd028-9b12-4195-8c6c-b010329c5a94@github.com> On Wed, 7 Oct 2020 12:54:20 GMT, Ambarish Rapte wrote: >> Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains two commits: >> - Merge branch 'master' into 8252192-vs2019-16.7.2 >> - 8252192: Update to Visual Studio 2019 version 16.7.2 > > Marked as reviewed by arapte (Reviewer). Does the [documentation](https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX) need updating to reflect the change? ------------- PR: https://git.openjdk.java.net/jfx/pull/312 From github.com+370894+ebresie at openjdk.java.net Thu Oct 8 11:37:45 2020 From: github.com+370894+ebresie at openjdk.java.net (Eric Bresie) Date: Thu, 8 Oct 2020 11:37:45 GMT Subject: RFR: 8252191: Update to gcc 10.2 on Linux In-Reply-To: References: Message-ID: <3MVctsGiWWocfHPI2yWouAme9OqWpH1rWKhXx5TQDic=.7c539ba2-1ebe-4450-b86a-2167705e8bb5@github.com> On Tue, 6 Oct 2020 13:14:05 GMT, Ambarish Rapte wrote: >> Marked as reviewed by jvos (Reviewer). > >> What OS are you using? (I'm running a test on Ubuntu 18.04) > > I also have 18.04. Does the [documentation](https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX) need updating to reflect the change? ------------- PR: https://git.openjdk.java.net/jfx/pull/311 From kcr at openjdk.java.net Thu Oct 8 12:46:46 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 8 Oct 2020 12:46:46 GMT Subject: RFR: 8252192: Update to Visual Studio 2019 version 16.7.2 [v2] In-Reply-To: <1xE-4rDw5zd_t2uiBskIx7f0eiSJZt0U6ThBAr6v6h0=.e3ebd028-9b12-4195-8c6c-b010329c5a94@github.com> References: <3Msr7G8Qp-H1b1qCUMjeGAWojoaSBiBdYDepx4O4SGs=.75eaf25d-75cc-476f-aa95-4ed649283f06@github.com> <1xE-4rDw5zd_t2uiBskIx7f0eiSJZt0U6ThBAr6v6h0=.e3ebd028-9b12-4195-8c6c-b010329c5a94@github.com> Message-ID: On Thu, 8 Oct 2020 11:31:21 GMT, Eric Bresie wrote: >> Marked as reviewed by arapte (Reviewer). > > Does the [documentation](https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX) need updating to reflect the > change? Not directly as a result of this PR, since we don't list the particular version of VS 2019 in our docs. However, it does remind me that the [Building OpenJFX](https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX) Wiki page needs updating -- it's out of date since it still mentions VS 2017. I'll fix that. ------------- PR: https://git.openjdk.java.net/jfx/pull/312 From kcr at openjdk.java.net Thu Oct 8 12:48:46 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 8 Oct 2020 12:48:46 GMT Subject: RFR: 8252191: Update to gcc 10.2 on Linux In-Reply-To: <3MVctsGiWWocfHPI2yWouAme9OqWpH1rWKhXx5TQDic=.7c539ba2-1ebe-4450-b86a-2167705e8bb5@github.com> References: <3MVctsGiWWocfHPI2yWouAme9OqWpH1rWKhXx5TQDic=.7c539ba2-1ebe-4450-b86a-2167705e8bb5@github.com> Message-ID: On Thu, 8 Oct 2020 11:35:15 GMT, Eric Bresie wrote: >>> What OS are you using? (I'm running a test on Ubuntu 18.04) >> >> I also have 18.04. > > Does the [documentation](https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX) need updating to reflect the > change? The Wiki doesn't specify the version of gcc (it probably should, though). ------------- PR: https://git.openjdk.java.net/jfx/pull/311 From fastegal at swingempire.de Thu Oct 8 14:12:46 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 08 Oct 2020 16:12:46 +0200 Subject: gradle: how to run tests of all projects? Message-ID: <20201008161246.Horde.q3e9WTSNsMaIzuef_W6qHw1@webmail.df.eu> With ./gradlew test I expect that tests of all projects are run (and think I have seen that expected behavior, but who knows ;), at least those projects with changes that might effect the tests. Since today (?), it looks like it stops after running base tests if there's a failure in any of the base tests. Without that failure, it moves on to controls tests. Anything changed, or my expectation wrong, or anything else? -- Jeanette From kevin.rushforth at oracle.com Thu Oct 8 14:28:29 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 8 Oct 2020 07:28:29 -0700 Subject: gradle: how to run tests of all projects? In-Reply-To: <20201008161246.Horde.q3e9WTSNsMaIzuef_W6qHw1@webmail.df.eu> References: <20201008161246.Horde.q3e9WTSNsMaIzuef_W6qHw1@webmail.df.eu> Message-ID: <38eadcae-a90c-7071-7007-a9f0cf3caa4f@oracle.com> "gradlew test" is sufficient to run the headless tests (e.g., the ones in base, graphics, controls, etc). To run the headful tests, there are two additional gradle options: -PFULL_TEST=true -PUSE_ROBOT=true The first enables headless tests (which are in the systemTests project). The second additionally enables the Robot-based tests. The Robot tests are likely to fail unless you make sure not to touch your system and disable your screen saver (or set the timeout to long enough that it doesn't start during the tests). -- Kevin On 10/8/2020 7:12 AM, Jeanette Winzenburg wrote: > > With > > ?? ./gradlew test > > I expect that tests of all projects are run (and think I have seen > that expected behavior, but who knows ;), at least those projects with > changes that might effect the tests. > > Since today (?), it looks like it stops after running base tests if > there's a failure in any of the base tests. Without that failure, it > moves on to controls tests. > > Anything changed, or my expectation wrong, or anything else? > > -- Jeanette > From kevin.rushforth at oracle.com Thu Oct 8 14:29:44 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 8 Oct 2020 07:29:44 -0700 Subject: gradle: how to run tests of all projects? In-Reply-To: <38eadcae-a90c-7071-7007-a9f0cf3caa4f@oracle.com> References: <20201008161246.Horde.q3e9WTSNsMaIzuef_W6qHw1@webmail.df.eu> <38eadcae-a90c-7071-7007-a9f0cf3caa4f@oracle.com> Message-ID: <1497e63d-6699-ff17-1b75-fa29801d04d9@oracle.com> > The first enables headless tests (which are in the systemTests project) s/headless/headful/ -- Kevin On 10/8/2020 7:28 AM, Kevin Rushforth wrote: > "gradlew test" is sufficient to run the headless tests (e.g., the ones > in base, graphics, controls, etc). To run the headful tests, there are > two additional gradle options: > > -PFULL_TEST=true > -PUSE_ROBOT=true > > The first enables headless tests (which are in the systemTests > project). The second additionally enables the Robot-based tests. The > Robot tests are likely to fail unless you make sure not to touch your > system and disable your screen saver (or set the timeout to long > enough that it doesn't start during the tests). > > -- Kevin > > > On 10/8/2020 7:12 AM, Jeanette Winzenburg wrote: >> >> With >> >> ?? ./gradlew test >> >> I expect that tests of all projects are run (and think I have seen >> that expected behavior, but who knows ;), at least those projects >> with changes that might effect the tests. >> >> Since today (?), it looks like it stops after running base tests if >> there's a failure in any of the base tests. Without that failure, it >> moves on to controls tests. >> >> Anything changed, or my expectation wrong, or anything else? >> >> -- Jeanette >> > From fastegal at swingempire.de Thu Oct 8 14:42:15 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 08 Oct 2020 16:42:15 +0200 Subject: gradle: how to run tests of all projects? In-Reply-To: <38eadcae-a90c-7071-7007-a9f0cf3caa4f@oracle.com> References: <20201008161246.Horde.q3e9WTSNsMaIzuef_W6qHw1@webmail.df.eu> <38eadcae-a90c-7071-7007-a9f0cf3caa4f@oracle.com> Message-ID: <20201008164215.Horde.UAipKp0X_nlz4zVRH9EkIA1@webmail.df.eu> thanks for the quick answer :) Sounds like I wasn't clear enough, though (did mean unit tests): what I'm puzzled about is that the unit tests of a dependent project (f.i. controls) is _not_ run if the base has test failures. -- Jeanette Zitat von Kevin Rushforth : > "gradlew test" is sufficient to run the headless tests (e.g., the > ones in base, graphics, controls, etc). To run the headful tests, > there are two additional gradle options: > > -PFULL_TEST=true > -PUSE_ROBOT=true > > The first enables headless tests (which are in the systemTests > project). The second additionally enables the Robot-based tests. The > Robot tests are likely to fail unless you make sure not to touch > your system and disable your screen saver (or set the timeout to > long enough that it doesn't start during the tests). > > -- Kevin > > > On 10/8/2020 7:12 AM, Jeanette Winzenburg wrote: >> >> With >> >> ?? ./gradlew test >> >> I expect that tests of all projects are run (and think I have seen >> that expected behavior, but who knows ;), at least those projects >> with changes that might effect the tests. >> >> Since today (?), it looks like it stops after running base tests if >> there's a failure in any of the base tests. Without that failure, >> it moves on to controls tests. >> >> Anything changed, or my expectation wrong, or anything else? >> >> -- Jeanette >> From kevin.rushforth at oracle.com Thu Oct 8 15:14:46 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 8 Oct 2020 08:14:46 -0700 Subject: gradle: how to run tests of all projects? In-Reply-To: <20201008164215.Horde.UAipKp0X_nlz4zVRH9EkIA1@webmail.df.eu> References: <20201008161246.Horde.q3e9WTSNsMaIzuef_W6qHw1@webmail.df.eu> <38eadcae-a90c-7071-7007-a9f0cf3caa4f@oracle.com> <20201008164215.Horde.UAipKp0X_nlz4zVRH9EkIA1@webmail.df.eu> Message-ID: <3e606392-8d8e-e187-d265-58f99dd1b6f3@oracle.com> I see. In that case, the following will run follow-on tests: gradlew --continue test That's what I usually do for a full test run. -- Kevin On 10/8/2020 7:42 AM, Jeanette Winzenburg wrote: > > thanks for the quick answer :) > > Sounds like I wasn't clear enough, though (did mean unit tests): what > I'm puzzled about is that the unit tests of a dependent project (f.i. > controls) is _not_ run if the base has test failures. > > -- Jeanette > > Zitat von Kevin Rushforth : > >> "gradlew test" is sufficient to run the headless tests (e.g., the >> ones in base, graphics, controls, etc). To run the headful tests, >> there are two additional gradle options: >> >> -PFULL_TEST=true >> -PUSE_ROBOT=true >> >> The first enables headless tests (which are in the systemTests >> project). The second additionally enables the Robot-based tests. The >> Robot tests are likely to fail unless you make sure not to touch your >> system and disable your screen saver (or set the timeout to long >> enough that it doesn't start during the tests). >> >> -- Kevin >> >> >> On 10/8/2020 7:12 AM, Jeanette Winzenburg wrote: >>> >>> With >>> >>> ?? ./gradlew test >>> >>> I expect that tests of all projects are run (and think I have seen >>> that expected behavior, but who knows ;), at least those projects >>> with changes that might effect the tests. >>> >>> Since today (?), it looks like it stops after running base tests if >>> there's a failure in any of the base tests. Without that failure, it >>> moves on to controls tests. >>> >>> Anything changed, or my expectation wrong, or anything else? >>> >>> -- Jeanette >>> > > > From fastegal at swingempire.de Thu Oct 8 15:29:00 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 08 Oct 2020 17:29:00 +0200 Subject: gradle: how to run tests of all projects? In-Reply-To: <3e606392-8d8e-e187-d265-58f99dd1b6f3@oracle.com> References: <20201008161246.Horde.q3e9WTSNsMaIzuef_W6qHw1@webmail.df.eu> <38eadcae-a90c-7071-7007-a9f0cf3caa4f@oracle.com> <20201008164215.Horde.UAipKp0X_nlz4zVRH9EkIA1@webmail.df.eu> <3e606392-8d8e-e187-d265-58f99dd1b6f3@oracle.com> Message-ID: <20201008172900.Horde.24x5Mtu4qv1ea4OHAtJdGQ1@webmail.df.eu> ahh .. yeah, that's working, thanks :) Except that now it continues with web testing as first, and I don't know how to exclude that, something like gradlew --continue test -x :web:test just stops again after the base failure .. But don't bother - it's the end of the working day and I need some rest, will try again tomorrow (or simply run them one-by-one) -- Thanks again, Jeanette Zitat von Kevin Rushforth : > I see. In that case, the following will run follow-on tests: > > gradlew --continue test > > That's what I usually do for a full test run. > > -- Kevin > > > On 10/8/2020 7:42 AM, Jeanette Winzenburg wrote: >> >> thanks for the quick answer :) >> >> Sounds like I wasn't clear enough, though (did mean unit tests): >> what I'm puzzled about is that the unit tests of a dependent >> project (f.i. controls) is _not_ run if the base has test failures. >> >> -- Jeanette >> >> Zitat von Kevin Rushforth : >> >>> "gradlew test" is sufficient to run the headless tests (e.g., the >>> ones in base, graphics, controls, etc). To run the headful tests, >>> there are two additional gradle options: >>> >>> -PFULL_TEST=true >>> -PUSE_ROBOT=true >>> >>> The first enables headless tests (which are in the systemTests >>> project). The second additionally enables the Robot-based tests. >>> The Robot tests are likely to fail unless you make sure not to >>> touch your system and disable your screen saver (or set the >>> timeout to long enough that it doesn't start during the tests). >>> >>> -- Kevin >>> >>> >>> On 10/8/2020 7:12 AM, Jeanette Winzenburg wrote: >>>> >>>> With >>>> >>>> ?? ./gradlew test >>>> >>>> I expect that tests of all projects are run (and think I have >>>> seen that expected behavior, but who knows ;), at least those >>>> projects with changes that might effect the tests. >>>> >>>> Since today (?), it looks like it stops after running base tests >>>> if there's a failure in any of the base tests. Without that >>>> failure, it moves on to controls tests. >>>> >>>> Anything changed, or my expectation wrong, or anything else? >>>> >>>> -- Jeanette >>>> >> >> >> From github.com+10960818+schmidor at openjdk.java.net Thu Oct 8 16:15:24 2020 From: github.com+10960818+schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Thu, 8 Oct 2020 16:15:24 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop Message-ID: When connecting via Remote Desktop to a Windows 10 machine ans starting a JavaFX application, the D3D pipeline is used successfully. After closing the the Remote Desktop session and reconnecting, the D3D requests fail with an D3DERR_DEVICEREMOVED HResult, and the application contents are not rendered anymore. Reinitializing the whole pipeline fixes that. ------------- Commit messages: - Fix whitespace error - 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop Changes: https://git.openjdk.java.net/jfx/pull/315/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=315&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8239589 Stats: 21 lines in 4 files changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/315.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/315/head:pull/315 PR: https://git.openjdk.java.net/jfx/pull/315 From kcr at openjdk.java.net Thu Oct 8 16:16:22 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 8 Oct 2020 16:16:22 GMT Subject: RFR: 8254255: Remove obsolete .hgignore file Message-ID: <0sJVg3u6rtbCt0VJH2vBZ_o3tJT0vXpn-WRu_CNXiLc=.2cda5ba2-7781-4504-9ded-61ad6d67507c@github.com> Simple patch to remove the obsolete `.hgignore` file. ------------- Commit messages: - 8254255: Remove obsolete .hgignore file Changes: https://git.openjdk.java.net/jfx/pull/316/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=316&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254255 Stats: 73 lines in 1 file changed: 0 ins; 73 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/316.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/316/head:pull/316 PR: https://git.openjdk.java.net/jfx/pull/316 From kcr at openjdk.java.net Thu Oct 8 16:22:20 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 8 Oct 2020 16:22:20 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 16:07:08 GMT, Oliver Schmidtmer wrote: > When connecting via Remote Desktop to a Windows 10 machine ans starting a JavaFX application, the D3D pipeline is used > successfully. After closing the the Remote Desktop session and reconnecting, the D3D requests fail with an > D3DERR_DEVICEREMOVED HResult, and the application contents are not rendered anymore. Reinitializing the whole pipeline > fixes that. This will need a fair bit of testing. I'm not certain that we always want to recreate the factory when the device is lost, but we can evaluate that during the review. ------------- PR: https://git.openjdk.java.net/jfx/pull/315 From github.com+10960818+schmidor at openjdk.java.net Thu Oct 8 16:36:19 2020 From: github.com+10960818+schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Thu, 8 Oct 2020 16:36:19 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: References: Message-ID: <9C1p4mWMNYAPwFRCwRLX2VGsMH4k3rkZd4ZVhxjw8NA=.d32adb57-173c-4b4e-85e0-c2d5db3d0954@github.com> On Thu, 8 Oct 2020 16:19:52 GMT, Kevin Rushforth wrote: >> When connecting via Remote Desktop to a Windows 10 machine ans starting a JavaFX application, the D3D pipeline is used >> successfully. After closing the the Remote Desktop session and reconnecting, the D3D requests fail with an >> D3DERR_DEVICEREMOVED HResult, and the application contents are not rendered anymore. Reinitializing the whole pipeline >> fixes that. > > This will need a fair bit of testing. I'm not certain that we always want to recreate the factory when the device is > lost, but we can evaluate that during the review. The full recreation of the pipeline is only done when D3DERR_DEVICEREMOVED is occurring. On other causes of why the device is not ready, only the factory reference in the painter is cleared. ------------- PR: https://git.openjdk.java.net/jfx/pull/315 From jvos at openjdk.java.net Thu Oct 8 17:26:17 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 8 Oct 2020 17:26:17 GMT Subject: RFR: 8254255: Remove obsolete .hgignore file In-Reply-To: <0sJVg3u6rtbCt0VJH2vBZ_o3tJT0vXpn-WRu_CNXiLc=.2cda5ba2-7781-4504-9ded-61ad6d67507c@github.com> References: <0sJVg3u6rtbCt0VJH2vBZ_o3tJT0vXpn-WRu_CNXiLc=.2cda5ba2-7781-4504-9ded-61ad6d67507c@github.com> Message-ID: On Thu, 8 Oct 2020 16:11:46 GMT, Kevin Rushforth wrote: > Simple patch to remove the obsolete `.hgignore` file. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/316 From kcr at openjdk.java.net Thu Oct 8 20:09:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 8 Oct 2020 20:09:18 GMT Subject: Integrated: 8254255: Remove obsolete .hgignore file In-Reply-To: <0sJVg3u6rtbCt0VJH2vBZ_o3tJT0vXpn-WRu_CNXiLc=.2cda5ba2-7781-4504-9ded-61ad6d67507c@github.com> References: <0sJVg3u6rtbCt0VJH2vBZ_o3tJT0vXpn-WRu_CNXiLc=.2cda5ba2-7781-4504-9ded-61ad6d67507c@github.com> Message-ID: On Thu, 8 Oct 2020 16:11:46 GMT, Kevin Rushforth wrote: > Simple patch to remove the obsolete `.hgignore` file. This pull request has now been integrated. Changeset: a56ba63b Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/a56ba63b Stats: 73 lines in 1 file changed: 0 ins; 73 del; 0 mod 8254255: Remove obsolete .hgignore file Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/316 From kcr at openjdk.java.net Thu Oct 8 23:54:27 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 8 Oct 2020 23:54:27 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v14] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 02:46:31 GMT, Nir Lisker wrote: >> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Change range after clamping The public API and implementation looks good. I left a few inline comments. I'll review the CSR in parallel with your fixing the few things I noted. modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGPointLight.java line 118: > 116: } > 117: } > 118: } Add newline here. modules/javafx.graphics/src/main/native-prism-d3d/D3DLight.cc line 49: > 47: attenuation[1] = 0; > 48: attenuation[2] = 0; > 49: maxRange = 0; Same comment as in `NGShape3D` about using infinity here, although if this value is always set from the Java side, then this native default might not matter. modules/javafx.graphics/src/main/native-prism-d3d/D3DLight.cc line 64: > 62: } > 63: > 64: /*void D3DLight::setRange(float r) { Remove this unused function? modules/javafx.graphics/src/main/native-prism-es2/GLContext.c line 2128: > 2126: meshViewInfo->pointLightAttenuation[1] = 0; > 2127: meshViewInfo->pointLightAttenuation[2] = 0; > 2128: meshViewInfo->pointLightMaxRange = 0; Same comment as `D3DLight.cc` about the default value. tests/system/src/test/java/test/javafx/scene/lighting3D/PointLightAttenuationTest.java line 51: > 49: public class PointLightAttenuationTest { > 50: > 51: private static final double DELTA = 1d/255; // smallest color resolution This test fails on my MacBook Pro system. Our other robot-based tests use a higher tolerance because of various problems we run into trying to look for exact values. I recommend a tolerance of `10d/255`, which will still catch whether or not attenuation is used. tests/system/src/test/java/test/javafx/scene/lighting3D/PointLightAttenuationTest.java line 105: > 103: double attenBlueDiag = snapshot.getPixelReader().getColor(SAMPLE_DIST, 0).getBlue(); > 104: assertEquals("Wrong color value", nonAttenBlueCenter * attnCenter, attenBlueCenter, DELTA); > 105: assertEquals("Wrong color value", nonAttenBlueDiag * attnDiag, attenBlueDiag, DELTA); This test looks good. Maybe you could also add a test of quadratic attenuation and max range? ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Thu Oct 8 23:54:27 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 8 Oct 2020 23:54:27 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: On Fri, 7 Aug 2020 22:30:39 GMT, Kevin Rushforth wrote: >> The only impact this has is that the range will be maximal instead of 0. When these reach the shader, they will run the >> lighting computation as opposed to skipping it. I'm not sure if this will have any performance impact though. > > In that case, it seems like a generally useful optimization (not just at initialization) to send down `maxRange` as 0 > whenever `ca`, `la`, and `qa` are all at their default values. Actually, my above comment is wrong. A `maxRange` of 0 will effectively disable the lighting, even in the case whether the other three values are 1, 0, 0. So `maxRange` should be set to `Float.POSITIVE_INFINITY` (or else just use the default constants). ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Fri Oct 9 00:00:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Oct 2020 00:00:25 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v14] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 02:46:31 GMT, Nir Lisker wrote: >> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Change range after clamping tests/system/src/test/java/test/javafx/scene/lighting3D/PointLightAttenuationTest.java line 65: > 63: > 64: @BeforeClass > 65: public static void initFX() throws Exception { One more thing I forgot to mention. You will need to skip the test if 3D is not supported using `assumeTrue`. See [TriangleMeshValidationTest.java#L64](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/robot/test3d/TriangleMeshValidationTest.java#L64). ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Fri Oct 9 01:04:23 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 9 Oct 2020 01:04:23 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: <8ybmNQH_LM-aUzH9S8ALrkm-W02p-1Re6SMrlT-uXWo=.5b57051d-8d47-4500-95ea-8ee3d6bff888@github.com> On Thu, 8 Oct 2020 22:08:16 GMT, Kevin Rushforth wrote: >> In that case, it seems like a generally useful optimization (not just at initialization) to send down `maxRange` as 0 >> whenever `ca`, `la`, and `qa` are all at their default values. > > Actually, my above comment is wrong. A `maxRange` of 0 will effectively disable the lighting, even in the case whether > the other three values are 1, 0, 0. So `maxRange` should be set to `Float.POSITIVE_INFINITY` (or else just use the > default constants). These lights are fillers for the native lights array in the case where the user set less than 3 lights, they are not supposed to do anything, and their color is black. A range of 0 will guarantee that the computation in the shader will be skipped. In a WIP that I have locally I have removed the "3 lights constraint" altogether, so this part will change in that proposed patch anyway. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Fri Oct 9 01:09:20 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Oct 2020 01:09:20 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> <8RPQPZ5DKF4l1AKAjtDeIfbVchuQGzxQP4I9ewOeezE=.0c3d5c61-1acf-4923-bc48-3999ad78b829@github.com> <97c408eWbFu-K_ZFbonKB_ex33oEgoo6IvOmAa_Bz5A=.a89956b6-be86-41ee-aded-1710ca099b5a@github.com> Message-ID: On Wed, 7 Oct 2020 21:14:14 GMT, yosbits wrote: >> **The next implementation will probably have a good balance between space and time.** >> Unless you do something like delete the even or odd indexes >> The space efficiency is very high. >> >> Currently being tested. >> >> Java >> @Override >> public boolean removeAll(Collection c) { >> // Throw NullPointerException if c is null >> if (c.isEmpty() || this.isEmpty()) { >> return false; >> } >> List runLengths = new java.util.ArrayList<>(); >> { >> int run = 0; >> boolean flag = true; >> for (int i=size()-1; i>=0; i--) { >> if (c.contains(get(i))==flag) { >> run++; >> } else { >> runLengths.add(run); >> run = 1; >> flag = !flag; >> } >> } >> if (run>0 && flag) { >> runLengths.add(run); >> } >> } >> boolean flag = true; >> boolean removed = false; >> if(runLengths.size()>0) { >> beginChange(); >> int cur = size()-1; >> for (int run:runLengths) { >> if(flag) { >> for(int to=cur-run; cur > to; cur--) { >> remove(cur); >> removed = true; >> } >> }else { >> cur -= run; >> } >> flag = !flag; >> } >> endChange(); >> return removed; >> } >> return false; >> } >> This implementation is more efficient by using an int [] array instead of an ArrayList. >> >> I'm planning to push it in a few days. > > It seems that many people are interested, so I pushed the change. > I don't understand how to proceed with the review on Github correctly, so if I have anything to do, please comment. > > java > for(int to=cur-run; cur > to; cur--) { > remove(cur); > } > removed = true; > > > > This can be moved out of the loop and will be included in the next change. Before I review the actual proposed change, I have a pair of related high-level questions that I should have asked at the beginning of this review. 1. What is the expected performance gain, and under what conditions would you see the gain? 2. Do you have a program that demonstrates / measures the performance gain? It doesn't need to be something that would be suitable for including as part of the PR, but we will need some test program that shows enough of a performance gain to justify making this change. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From nlisker at openjdk.java.net Fri Oct 9 01:32:25 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 9 Oct 2020 01:32:25 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v14] In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 22:20:17 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Change range after clamping > > modules/javafx.graphics/src/main/native-prism-d3d/D3DLight.cc line 49: > >> 47: attenuation[1] = 0; >> 48: attenuation[2] = 0; >> 49: maxRange = 0; > > Same comment as in `NGShape3D` about using infinity here, although if this value is always set from the Java side, then > this native default might not matter. Yes, these values are always overridden. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Fri Oct 9 01:42:27 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 9 Oct 2020 01:42:27 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v14] In-Reply-To: References: Message-ID: <_5uOiOEd-dMxe-mAXrTnRvASqp6vhACuyCLJdZEv-KY=.247bb6f2-95c6-4287-b7bd-0eae6a54c57d@github.com> On Thu, 8 Oct 2020 22:21:06 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Change range after clamping > > modules/javafx.graphics/src/main/native-prism-d3d/D3DLight.cc line 64: > >> 62: } >> 63: >> 64: /*void D3DLight::setRange(float r) { > > Remove this unused function? I forgot to mention this point. These setter functions for color and position (and range) are never used since whenever there is a change in the java side the whole array and lights are recreated instead of being adjusted for the change. I'm not familiar enough with the memory model of JNI, but it seems expensive to re-render everything on every change (I think that the mesh is also recreated every time in the native code). Is this the way it's supposed to work? ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Fri Oct 9 04:53:36 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 9 Oct 2020 04:53:36 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v15] In-Reply-To: References: Message-ID: > CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/43/files - new: https://git.openjdk.java.net/jfx/pull/43/files/21f91dd7..e1fdf8e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=43&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=43&range=13-14 Stats: 36 lines in 3 files changed: 25 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/43/head:pull/43 PR: https://git.openjdk.java.net/jfx/pull/43 From github.com+7517141+yososs at openjdk.java.net Fri Oct 9 05:34:17 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 9 Oct 2020 05:34:17 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> <8RPQPZ5DKF4l1AKAjtDeIfbVchuQGzxQP4I9ewOeezE=.0c3d5c61-1acf-4923-bc48-3999ad78b829@github.com> <97c408eWbFu-K_ZFbonKB_ex33oEgoo6IvOmAa_Bz5A=.a89956b6-be86-41ee-aded-1710ca099b5a@github.com> Message-ID: On Fri, 9 Oct 2020 01:06:54 GMT, Kevin Rushforth wrote: >> It seems that many people are interested, so I pushed the change. >> I don't understand how to proceed with the review on Github correctly, so if I have anything to do, please comment. >> >> java >> for(int to=cur-run; cur > to; cur--) { >> remove(cur); >> } >> removed = true; >> >> >> >> This can be moved out of the loop and will be included in the next change. > > Before I review the actual proposed change, I have a pair of related high-level questions that I should have asked at > the beginning of this review. > 1. What is the expected performance gain, and under what conditions would you see the gain? > 2. Do you have a program that demonstrates / measures the performance gain? > > It doesn't need to be something that would be suitable for including as part of the PR, but we will need some test > program that shows enough of a performance gain to justify making this change. The performance improvements of the first change were self-evident, but I agree that the current changes need to be explained. BitSet Features * When using BitSet, memory usage (N/8) is wasted in the case of removing the last one in the list. This is often caused by user actions. PR Features * The proposal records the run length of the flag, so the memory usage can be kept small in the case of consecutive deletion indexes. The worst case is the case where the deletion indexes are not contiguous, which results in 4*N memory consumption, but this happens very rarely. It's also the same as the memory usage of getSelectedIndices(). (Memory usage is further improved by setting it to int[]). * Also, the delete loop is less CPU intensive and faster than BitSet's flag scan. I will attach a test, but you'll have to wait until my next leisure time. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From kcr at openjdk.java.net Fri Oct 9 11:59:23 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Oct 2020 11:59:23 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v14] In-Reply-To: <_5uOiOEd-dMxe-mAXrTnRvASqp6vhACuyCLJdZEv-KY=.247bb6f2-95c6-4287-b7bd-0eae6a54c57d@github.com> References: <_5uOiOEd-dMxe-mAXrTnRvASqp6vhACuyCLJdZEv-KY=.247bb6f2-95c6-4287-b7bd-0eae6a54c57d@github.com> Message-ID: On Fri, 9 Oct 2020 01:39:23 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/native-prism-d3d/D3DLight.cc line 64: >> >>> 62: } >>> 63: >>> 64: /*void D3DLight::setRange(float r) { >> >> Remove this unused function? > > I forgot to mention this point. These setter functions for color and position (and range) are never used since whenever > there is a change in the java side the whole array and lights are recreated instead of being adjusted for the change. > I'm not familiar enough with the memory model of JNI, but it seems expensive to re-render everything on every change (I > think that the mesh is also recreated every time in the native code). Is this the way it's supposed to work? If the lights array is being recreated on a change, there might be a small savings to be had to reuse the existing array (it would need to be updated only during the sync while the renderer is idle). If the mesh is always being recreated, there may be an opportunity for an even bigger savings, presuming that only the mesh data changed (and not the index values in the faces array). This could be a future optimization, but we would need something to quantify the possible savings. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Fri Oct 9 12:37:20 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Oct 2020 12:37:20 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v15] In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 04:53:36 GMT, Nir Lisker wrote: >> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments tests/system/src/test/java/test/javafx/scene/lighting3D/PointLightAttenuationTest.java line 135: > 133: @AfterClass > 134: public static void teardown() { > 135: Platform.runLater(() -> { I forgot to mention that the `@AfterClass` method is still run even if the call to `assumeTrue` in the `@BeforeClass` method causes the test to be skipped. You will need to repeat the check (or set a flag in `initFX` and check that flag) here and skip the cleanup if the initialization was skipped (using an `if` check, not repeating the `assumeTrue`). Otherwise the exception that is thrown here will cause the test to fail. You can test this by forcing the SW pipeline. I did it like this: _JAVA_OPTIONS="-Dprism.order=sw" gradle --info -PFULL_TEST=true :systemTests:test --tests PointLightAttenuationTest ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kevin.rushforth at oracle.com Fri Oct 9 13:15:11 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 9 Oct 2020 06:15:11 -0700 Subject: gradle: how to run tests of all projects? In-Reply-To: <20201008172900.Horde.24x5Mtu4qv1ea4OHAtJdGQ1@webmail.df.eu> References: <20201008161246.Horde.q3e9WTSNsMaIzuef_W6qHw1@webmail.df.eu> <38eadcae-a90c-7071-7007-a9f0cf3caa4f@oracle.com> <20201008164215.Horde.UAipKp0X_nlz4zVRH9EkIA1@webmail.df.eu> <3e606392-8d8e-e187-d265-58f99dd1b6f3@oracle.com> <20201008172900.Horde.24x5Mtu4qv1ea4OHAtJdGQ1@webmail.df.eu> Message-ID: I just tested it and it works fine for me. Are you sure the reason it didn't run the tests in the other projects (graphics, etc) was because they had been run successfully earlier and thus the tests were "up-to-date"? If you want to force the tests to rerun even if nothing has changed, you need to also specify the "cleanTest" target: gradle --continue cleanTest test -x :web:test -- Kevin On 10/8/2020 8:29 AM, Jeanette Winzenburg wrote: > > ahh .. yeah, that's working, thanks :) Except that now it continues > with web testing as first, and I don't know how to exclude that, > something like > > ??? gradlew --continue test -x :web:test > > just stops again after the base failure .. > > But don't bother - it's the end of the working day and I need some > rest, will try again tomorrow (or simply run them one-by-one) > > -- Thanks again, Jeanette > > > > Zitat von Kevin Rushforth : > >> I see. In that case, the following will run follow-on tests: >> >> gradlew --continue test >> >> That's what I usually do for a full test run. >> >> -- Kevin >> >> >> On 10/8/2020 7:42 AM, Jeanette Winzenburg wrote: >>> >>> thanks for the quick answer :) >>> >>> Sounds like I wasn't clear enough, though (did mean unit tests): >>> what I'm puzzled about is that the unit tests of a dependent project >>> (f.i. controls) is _not_ run if the base has test failures. >>> >>> -- Jeanette >>> >>> Zitat von Kevin Rushforth : >>> >>>> "gradlew test" is sufficient to run the headless tests (e.g., the >>>> ones in base, graphics, controls, etc). To run the headful tests, >>>> there are two additional gradle options: >>>> >>>> -PFULL_TEST=true >>>> -PUSE_ROBOT=true >>>> >>>> The first enables headless tests (which are in the systemTests >>>> project). The second additionally enables the Robot-based tests. >>>> The Robot tests are likely to fail unless you make sure not to >>>> touch your system and disable your screen saver (or set the timeout >>>> to long enough that it doesn't start during the tests). >>>> >>>> -- Kevin >>>> >>>> >>>> On 10/8/2020 7:12 AM, Jeanette Winzenburg wrote: >>>>> >>>>> With >>>>> >>>>> ?? ./gradlew test >>>>> >>>>> I expect that tests of all projects are run (and think I have seen >>>>> that expected behavior, but who knows ;), at least those projects >>>>> with changes that might effect the tests. >>>>> >>>>> Since today (?), it looks like it stops after running base tests >>>>> if there's a failure in any of the base tests. Without that >>>>> failure, it moves on to controls tests. >>>>> >>>>> Anything changed, or my expectation wrong, or anything else? >>>>> >>>>> -- Jeanette >>>>> >>> >>> >>> > > > From kevin.rushforth at oracle.com Fri Oct 9 13:21:28 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 9 Oct 2020 06:21:28 -0700 Subject: Proposed schedule for JavaFX 16 Message-ID: <497c89d3-2e83-2bf5-75a4-43691c51e114@oracle.com> Here is the proposed schedule for JavaFX 16. RDP1: Jan 7, 2021 (aka ?feature freeze?) RDP2: Jan 28, 2021 Freeze: Feb 18, 2021 GA: March 9, 2021 We plan to fork a jfx16 stabilization branch at RDP1. The GA date is expected to be one week ahead of JDK 16, matching what we did for 15. As was done for the previous release, the start of RDP1, the start of RDP2, and the code freeze will be 16:00 UTC on the respective dates. Please let Johan or me know if you have any questions. -- Kevin From kcr at openjdk.java.net Fri Oct 9 13:40:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Oct 2020 13:40:09 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> <8RPQPZ5DKF4l1AKAjtDeIfbVchuQGzxQP4I9ewOeezE=.0c3d5c61-1acf-4923-bc48-3999ad78b829@github.com> <97c408eWbFu-K_ZFbonKB_ex33oEgoo6IvOmAa_Bz5A=.a89956b6-be86-41ee-aded-1710ca099b5a@github.com> Message-ID: On Fri, 9 Oct 2020 05:31:54 GMT, yosbits wrote: >> Before I review the actual proposed change, I have a pair of related high-level questions that I should have asked at >> the beginning of this review. >> 1. What is the expected performance gain, and under what conditions would you see the gain? >> 2. Do you have a program that demonstrates / measures the performance gain? >> >> It doesn't need to be something that would be suitable for including as part of the PR, but we will need some test >> program that shows enough of a performance gain to justify making this change. > > The performance improvements of the first change were self-evident, but > I agree that the current changes need to be explained. > > BitSet Features > * When using BitSet, memory usage (N/8) is wasted in the case of removing the last one in the list. This is often caused > by user actions. > > PR Features > * The proposal records the run length of the flag, so the memory usage can be kept small in the case of consecutive > deletion indexes. The worst case is the case where the deletion indexes are not contiguous, which results in 4*N memory > consumption, but this happens very rarely. It's also the same as the memory usage of getSelectedIndices(). (Memory > usage is further improved by setting it to int[]). > * Also, the delete loop is less CPU intensive and faster than BitSet's flag scan. > > I will attach a test, but you'll have to wait until my next leisure time. I understand that this will improve the performance of this method in some cases (but not all as you correctly point out), but what I really meant by my questions was: When does this matter to an application's overall performance and what is the performance gain you would expect to see? As a general rule, we do not make this sort of performance optimization without a compelling reason. Improving the performance of a method is not by itself compelling unless there is a demonstrable (not theoretical) improvement to applications. I look forward to seeing the test program that shows the performance problem with the current implementation and allows us to measure the improvement with your proposed patch. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From nlisker at openjdk.java.net Fri Oct 9 14:59:17 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 9 Oct 2020 14:59:17 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v15] In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 12:34:08 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed review comments > > tests/system/src/test/java/test/javafx/scene/lighting3D/PointLightAttenuationTest.java line 135: > >> 133: @AfterClass >> 134: public static void teardown() { >> 135: Platform.runLater(() -> { > > I forgot to mention that the `@AfterClass` method is still run even if the call to `assumeTrue` in the `@BeforeClass` > method causes the test to be skipped. You will need to repeat the check (or set a flag in `initFX` and check that flag) > here and skip the cleanup if the initialization was skipped (using an `if` check, not repeating the `assumeTrue`). > Otherwise the exception that is thrown here will cause the test to fail. You can test this by forcing the SW pipeline. > I did it like this: _JAVA_OPTIONS="-Dprism.order=sw" gradle --info -PFULL_TEST=true :systemTests:test --tests > PointLightAttenuationTest The test fails even with this addition. I found that I need to use `@Before` to run the check, and then I don't need the ones in `@BeforeClass` and `@AfterClass`, should I keep those? ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From fastegal at swingempire.de Fri Oct 9 15:38:28 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 09 Oct 2020 17:38:28 +0200 Subject: gradle: how to run tests of all projects? In-Reply-To: References: <20201008161246.Horde.q3e9WTSNsMaIzuef_W6qHw1@webmail.df.eu> <38eadcae-a90c-7071-7007-a9f0cf3caa4f@oracle.com> <20201008164215.Horde.UAipKp0X_nlz4zVRH9EkIA1@webmail.df.eu> <3e606392-8d8e-e187-d265-58f99dd1b6f3@oracle.com> <20201008172900.Horde.24x5Mtu4qv1ea4OHAtJdGQ1@webmail.df.eu> Message-ID: <20201009173828.Horde.CsZz9D_Ss_WX3jjMLFjoow2@webmail.df.eu> Zitat von Kevin Rushforth : > I just tested it and it works fine for me. Are you sure the reason > it didn't run the tests in the other projects (graphics, etc) was > because they had been run successfully earlier and thus the tests > were "up-to-date"? hmm .. not entirely certain: here's the scenario - working on those regression tests for ObservableList - have tests in both base and controls the fail before the fix to the old issue 8093144, all tests pass after the fix - in ObservableListWrapper, I have a both versions (chosen by a static toggle pre/fix) - compile with fix - run gradle --continue test -x :web:test - all are passing - toggle the switch to use the prefix implementation (now I expect test failures in base and control) - run the gradle cmd above - testing stops after tests in base failed So there were no code changes in controls and the tests formerly passed - but the change in base should mark the control test as requiring re-run or not? > If you want to force the tests to rerun even if nothing has changed, > you need to also specify the "cleanTest" target: > > gradle --continue cleanTest test -x :web:test > yeah, that's working, thanks :) That option is fine, so don't need understanding the upper part -- it just itches > -- Kevin > > On 10/8/2020 8:29 AM, Jeanette Winzenburg wrote: >> >> ahh .. yeah, that's working, thanks :) Except that now it continues >> with web testing as first, and I don't know how to exclude that, >> something like >> >> ??? gradlew --continue test -x :web:test >> >> just stops again after the base failure .. >> >> But don't bother - it's the end of the working day and I need some >> rest, will try again tomorrow (or simply run them one-by-one) >> >> -- Thanks again, Jeanette >> >> >> >> Zitat von Kevin Rushforth : >> >>> I see. In that case, the following will run follow-on tests: >>> >>> gradlew --continue test >>> >>> That's what I usually do for a full test run. >>> >>> -- Kevin >>> >>> >>> On 10/8/2020 7:42 AM, Jeanette Winzenburg wrote: >>>> >>>> thanks for the quick answer :) >>>> >>>> Sounds like I wasn't clear enough, though (did mean unit tests): >>>> what I'm puzzled about is that the unit tests of a dependent >>>> project (f.i. controls) is _not_ run if the base has test failures. >>>> >>>> -- Jeanette >>>> >>>> Zitat von Kevin Rushforth : >>>> >>>>> "gradlew test" is sufficient to run the headless tests (e.g., >>>>> the ones in base, graphics, controls, etc). To run the headful >>>>> tests, there are two additional gradle options: >>>>> >>>>> -PFULL_TEST=true >>>>> -PUSE_ROBOT=true >>>>> >>>>> The first enables headless tests (which are in the systemTests >>>>> project). The second additionally enables the Robot-based tests. >>>>> The Robot tests are likely to fail unless you make sure not to >>>>> touch your system and disable your screen saver (or set the >>>>> timeout to long enough that it doesn't start during the tests). >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 10/8/2020 7:12 AM, Jeanette Winzenburg wrote: >>>>>> >>>>>> With >>>>>> >>>>>> ?? ./gradlew test >>>>>> >>>>>> I expect that tests of all projects are run (and think I have >>>>>> seen that expected behavior, but who knows ;), at least those >>>>>> projects with changes that might effect the tests. >>>>>> >>>>>> Since today (?), it looks like it stops after running base >>>>>> tests if there's a failure in any of the base tests. Without >>>>>> that failure, it moves on to controls tests. >>>>>> >>>>>> Anything changed, or my expectation wrong, or anything else? >>>>>> >>>>>> -- Jeanette >>>>>> >>>> >>>> >>>> >> >> >> From kcr at openjdk.java.net Fri Oct 9 16:22:19 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Oct 2020 16:22:19 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v15] In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 14:55:36 GMT, Nir Lisker wrote: >> tests/system/src/test/java/test/javafx/scene/lighting3D/PointLightAttenuationTest.java line 135: >> >>> 133: @AfterClass >>> 134: public static void teardown() { >>> 135: Platform.runLater(() -> { >> >> I forgot to mention that the `@AfterClass` method is still run even if the call to `assumeTrue` in the `@BeforeClass` >> method causes the test to be skipped. You will need to repeat the check (or set a flag in `initFX` and check that flag) >> here and skip the cleanup if the initialization was skipped (using an `if` check, not repeating the `assumeTrue`). >> Otherwise the exception that is thrown here will cause the test to fail. You can test this by forcing the SW pipeline. >> I did it like this: _JAVA_OPTIONS="-Dprism.order=sw" gradle --info -PFULL_TEST=true :systemTests:test --tests >> PointLightAttenuationTest > > The test fails even with this addition. I found that I need to use `@Before` to run the check, and then I don't need > the ones in `@BeforeClass` and `@AfterClass`, should I keep those? Putting the `assumeTrue` in an `@Before` method seems best. I checked and it's what all of the other 3D tests do. There is no need to test for this in the `@BeforeClass` and `@AferClass` methods. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Fri Oct 9 16:33:28 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 9 Oct 2020 16:33:28 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v16] In-Reply-To: References: Message-ID: > CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Fixed test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/43/files - new: https://git.openjdk.java.net/jfx/pull/43/files/e1fdf8e2..475e1bd2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=43&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=43&range=14-15 Stats: 7 lines in 1 file changed: 6 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/43/head:pull/43 PR: https://git.openjdk.java.net/jfx/pull/43 From github.com+7517141+yososs at openjdk.java.net Fri Oct 9 16:54:16 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 9 Oct 2020 16:54:16 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> <8RPQPZ5DKF4l1AKAjtDeIfbVchuQGzxQP4I9ewOeezE=.0c3d5c61-1acf-4923-bc48-3999ad78b829@github.com> <97c408eWbFu-K_ZFbonKB_ex33oEgoo6IvOmAa_Bz5A=.a89956b6-be86-41ee-aded-1710ca099b5a@github.com> Message-ID: On Fri, 9 Oct 2020 13:37:57 GMT, Kevin Rushforth wrote: >> The performance improvements of the first change were self-evident, but >> I agree that the current changes need to be explained. >> >> BitSet Features >> * When using BitSet, memory usage (N/8) is wasted in the case of removing the last one in the list. This is often caused >> by user actions. >> >> PR Features >> * The proposal records the run length of the flag, so the memory usage can be kept small in the case of consecutive >> deletion indexes. The worst case is the case where the deletion indexes are not contiguous, which results in 4*N memory >> consumption, but this happens very rarely. It's also the same as the memory usage of getSelectedIndices(). (Memory >> usage is further improved by setting it to int[]). >> * Also, the delete loop is less CPU intensive and faster than BitSet's flag scan. >> >> I will attach a test, but you'll have to wait until my next leisure time. > > I understand that this will improve the performance of this method in some cases (but not all as you correctly point > out), but what I really meant by my questions was: When does this matter to an application's overall performance and > what is the performance gain you would expect to see? As a general rule, we do not make this sort of performance > optimization without a compelling reason. Improving the performance of a method is not by itself compelling unless > there is a demonstrable (not theoretical) improvement to applications. I look forward to seeing the test program that > shows the performance problem with the current implementation and allows us to measure the improvement with your > proposed patch. ### Improved space efficiency * The BitSet approach has a problem where the last delete index determines the size of the internal BitSet array; the Run-Length approach eliminates this memory waste. * The Run-Lengths approach has its drawbacks, but the worst case can be avoided by switching to the BitSet approach when the array is expanded. * **The BitSet approach (original source) has the wrong initial size.** The exact initialization size can be determined by evaluating from the end of the index. As a result, the expansion of the internal array can be suppressed and unnecessary memory copy does not occur. Therefore, there is still room for optimization in the BitSet approach. * The worst case of the BitSet approach is likely to occur, and the worst case of the Run-Length approach is unlikely. Because the worst case of the BitSet approach happens at least one, but Run-Length requires N / 2 deletions. * The point at which the space efficiency of Run-Length and BitSet switches can be determined during the execution of the Run-Length approach. #### Memory consumption to remove the last item in the list. **The BitSet approach** ceil(N/64)*8 * 12,504 B for 100,000 items * 1,256 B for 10,000 items * 1,28 B for 1000 items * 16 B in 100 items **Run-Lengths Approach** For consecutive indexes, regardless of N 4 * 4 = 16 B 4 * (N +1) in the worst case * The Run-Lengths approach has its drawbacks, but the worst case can be avoided by switching to the BitSet approach at the time of array expansion (hybrid approach). ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+7517141+yososs at openjdk.java.net Fri Oct 9 17:50:15 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 9 Oct 2020 17:50:15 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> <8RPQPZ5DKF4l1AKAjtDeIfbVchuQGzxQP4I9ewOeezE=.0c3d5c61-1acf-4923-bc48-3999ad78b829@github.com> <97c408eWbFu-K_ZFbonKB_ex33oEgoo6IvOmAa_Bz5A=.a89956b6-be86-41ee-aded-1710ca099b5a@github.com> Message-ID: On Fri, 9 Oct 2020 16:51:05 GMT, yosbits wrote: >> I understand that this will improve the performance of this method in some cases (but not all as you correctly point >> out), but what I really meant by my questions was: When does this matter to an application's overall performance and >> what is the performance gain you would expect to see? As a general rule, we do not make this sort of performance >> optimization without a compelling reason. Improving the performance of a method is not by itself compelling unless >> there is a demonstrable (not theoretical) improvement to applications. I look forward to seeing the test program that >> shows the performance problem with the current implementation and allows us to measure the improvement with your >> proposed patch. > > ### Improved space efficiency > > * The BitSet approach has a problem where the last delete index determines the size of the internal BitSet array; the > Run-Length approach eliminates this memory waste. > > * The Run-Lengths approach has its drawbacks, but the worst case can be avoided by switching to the BitSet approach when > the array is expanded. > > * **The BitSet approach (original source) has the wrong initial size.** The exact initialization size can be determined by > evaluating from the end of the index. As a result, the expansion of the internal array can be suppressed and > unnecessary memory copy does not occur. Therefore, there is still room for optimization in the BitSet approach. > > * The worst case of the BitSet approach is likely to occur, and the worst case of the Run-Length approach is unlikely. > Because the worst case of the BitSet approach happens at least one, but Run-Length requires N / 2 deletions. > > * The point at which the space efficiency of Run-Length and BitSet switches can be determined during the execution of the > Run-Length approach. > > #### Memory consumption to remove the last item in the list. > > **The BitSet approach** > > ceil(N/64)*8 > > * 12,504 B for 100,000 items > * 1,256 B for 10,000 items > * 1,28 B for 1000 items > * 16 B in 100 items > > **Run-Lengths Approach** > For consecutive indexes, regardless of N > > 4 * 4 > = 16 B > > 4 * (N +1) in the worst case > > * The Run-Lengths approach has its drawbacks, but the worst case can be avoided by switching to the BitSet approach at > the time of array expansion (hybrid approach). @kevinrushforth To show an improvement in time efficiency, the We need to fix the other high-priority hotspots first. I have determined that the current proposed change in the Run-Length approach needs a lot of time to be accepted. I will change my approach. I will switch to an approach that focuses solely on fixing the BitSet initialization size issue. The previous post explains. @Override public boolean removeAll(Collection c) { beginChange(); BitSet bs = new BitSet(c.size()); * new BitSet(c.size()) Don't you notice this mistake? ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From kcr at openjdk.java.net Fri Oct 9 18:15:13 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Oct 2020 18:15:13 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v16] In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 16:33:28 GMT, Nir Lisker wrote: >> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test tests/performance/3DLighting/attenuation/LightingSample.java line 72: > 70: sphere.setOnAction(e -> switchTo(environment.createSphere((int) subdivisionSlider.getValue()))); > 71: > 72: var quadSlider = new Slider(500, 10_000, 1000); I was doing some final testing, and ran this on a few different systems. I think the min and max values are too large (especially the min value). I recommend something more like min=100 and max=5000. tests/performance/3DLighting/attenuation/LightingSample.java line 62: > 60: environment.setStyle("-fx-background-color: teal"); > 61: > 62: var subdivisionSlider = new Slider(10, 200, 60); I might recommend setting the max value of the slider to something like 1000, since even on a slow system, it runs quite nicely at that tessellation. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Fri Oct 9 19:46:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Oct 2020 19:46:15 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v16] In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 16:33:28 GMT, Nir Lisker wrote: >> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test I think this is ready to go in once it gets a second reviewer and once the CSR is approved. I left two very minor comments on the test. I don't mind whether you fix them now or as a follow-up. Marked as reviewed by kcr (Lead). ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Fri Oct 9 22:19:13 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Oct 2020 22:19:13 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v6] In-Reply-To: References: Message-ID: On Mon, 24 Aug 2020 07:48:27 GMT, Arun Joseph wrote: >> fillPath() and fillRect() functions in >> [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) >> use Image::drawPattern() for applying patterns as fill. But drawPattern() doesn't use patternTransform argument as >> ImagePattern doesn't have the same attribute. So, the final image won't be transformed. > > Arun Joseph has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year > - Minor refactoring This looks good to me with one suggestion and one request for a clarifying comment. modules/javafx.graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java line 742: > 740: } > 741: > 742: g2d.fill(tmpAT.createTransformedShape(shape)); Maybe move the `fill` call inside the try/catch so it won't draw anything if the transform is non-invertible? That matches what `drawMappedTextureRaw` does. modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 790: > 788: Affine3D at = new Affine3D(); > 789: at.translate(phase.getX(), phase.getY()); > 790: at.concatenate(m[0], -m[1], m[4], -m[2], m[3], m[5]); Can you explain why the matrix is transformed in this way (specifically the negation of elements 1 and 2)? A code comment would be helpful since it is non-obvious. ------------- PR: https://git.openjdk.java.net/jfx/pull/190 From kcr at openjdk.java.net Fri Oct 9 23:02:08 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Oct 2020 23:02:08 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> <8RPQPZ5DKF4l1AKAjtDeIfbVchuQGzxQP4I9ewOeezE=.0c3d5c61-1acf-4923-bc48-3999ad78b829@github.com> <97c408eWbFu-K_ZFbonKB_ex33oEgoo6IvOmAa_Bz5A=.a89956b6-be86-41ee-aded-1710ca099b5a@github.com> Message-ID: On Fri, 9 Oct 2020 17:47:31 GMT, yosbits wrote: > * new BitSet(c.size()) > > Don't you notice this mistake? It certainly isn't an exact size, and probably not a very good guess in many cases (e.g., a small number of objects where one near the end is chosen), but it is at least a lower limit on the memory you need. So I take it you propose to allocate the BitSet the first time you need it, while looping in the reverse order of this array list? That will work, at the (fairly minor) expense of having to do a null check in the loop (or the added complexity of an initial loop that runs until you find one and a second loop from that point to the end). I'm still not convinced that this is worth the effort, at least not without a test case showing some gain that we can measure. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From kcr at openjdk.java.net Fri Oct 9 23:20:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Oct 2020 23:20:07 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: <9C1p4mWMNYAPwFRCwRLX2VGsMH4k3rkZd4ZVhxjw8NA=.d32adb57-173c-4b4e-85e0-c2d5db3d0954@github.com> References: <9C1p4mWMNYAPwFRCwRLX2VGsMH4k3rkZd4ZVhxjw8NA=.d32adb57-173c-4b4e-85e0-c2d5db3d0954@github.com> Message-ID: On Thu, 8 Oct 2020 16:33:55 GMT, Oliver Schmidtmer wrote: > The full recreation of the pipeline is only done when D3DERR_DEVICEREMOVED is occurring I see that now. That part is fine then. Another concern is that this would be the first time we have recreated a GraphicsPipeline -- they are effectively singletons today. This could have unexpected side effects and would need to be very carefully reviewed and tested. Have you considered an alternative where you retain the GraphicsPipeline, but recreate the native device? ------------- PR: https://git.openjdk.java.net/jfx/pull/315 From kcr at openjdk.java.net Fri Oct 9 23:52:06 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Oct 2020 23:52:06 GMT Subject: RFR: 8178297: TableView scrolls slightly when adding new elements [v2] In-Reply-To: References: <_ip0Z6pUqZ5_FA0f1bsX3HgO4zQBf2krfIiAEGJaIhc=.47d6d48e-94ef-4ae5-a909-626f5e72c804@github.com> Message-ID: On Wed, 23 Sep 2020 10:26:12 GMT, Jose Pereda wrote: >> This PR fixes an issue that happens when adding new items to a `TableView` or any other control that uses >> `VirtualFlow`, if the scroll position is not 0: the virtual flow is slightly shifted down. >> For instance, let's say that a cell has a layoutY of -10.0. After adding a new item to the table, during the layout >> pass the new value is initially modified to -9.999999999999996 (`VirtualFlow::adjustByPixelAmount`) , and then, after >> calling `VirtualFlow::positionCell` (that uses `snapSizeY(position)`) the layoutY is modified to -9.5, causing an >> undesired positive shift of 0.5 pixels. `Region` has different snap methods: `snapSizeX/Y` are used to snap node >> dimension values, like width or height, by ceiling to the nearest pixel (which explains the -9.5 value), while >> `snapSpaceX/Y` are used to snap position values like insets, by rounding to the nearest pixel (this will give the >> expected -10.0). Therefore, this PR modifies `VirtualFlow::positionCell` to use the `snapSpaceX/Y` methods, since >> these are being used to set the layout of the cell and not its size. Test: A unity test has been included. It >> simulates the case of adding new items to the virtual flow after an initial scroll. It currently fails after adding a >> few items, and it passes with the changes of this PR. > > Jose Pereda has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains three commits: > - Merge master > - Add test to verify the cell position remains constant when new cells are added to the virtualFlow. > - Use correct snap method to set cell layout Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/297 From github.com+7517141+yososs at openjdk.java.net Sat Oct 10 15:12:08 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Sat, 10 Oct 2020 15:12:08 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: <-gk6XTd1Wc6Bc7WWkzCEJBvSoyfH5NzJ7fIDDYEskwc=.53251372-ba18-44bf-a7e6-f11cd4ae5e72@github.com> <34_m93ootvrT5tEEUsU63kgRxlD2KeQlOYFpml7lyfA=.bd43b620-ab99-4c89-9924-4c75f5e7cb6a@github.com> <8RPQPZ5DKF4l1AKAjtDeIfbVchuQGzxQP4I9ewOeezE=.0c3d5c61-1acf-4923-bc48-3999ad78b829@github.com> <97c408eWbFu-K_ZFbonKB_ex33oEgoo6IvOmAa_Bz5A=.a89956b6-be86-41ee-aded-1710ca099b5a@github.com> Message-ID: <-lSMOR6EnDWYRhkCxdSyb9n7qWoyNFdwfW4MtmoChn0=.f0eac4f4-121a-40cf-8aab-929c42593891@github.com> On Fri, 9 Oct 2020 22:59:37 GMT, Kevin Rushforth wrote: >> @kevinrushforth >> >> To show an improvement in time efficiency, the >> We need to fix the other high-priority hotspots first. I have determined that the current proposed change in the >> Run-Length approach needs a lot of time to be accepted. I will change my approach. >> I will switch to an approach that focuses solely on fixing the BitSet initialization size issue. The previous post >> explains. >> @Override >> public boolean removeAll(Collection c) { >> beginChange(); >> BitSet bs = new BitSet(c.size()); >> >> * new BitSet(c.size()) >> >> Don't you notice this mistake? > >> * new BitSet(c.size()) >> >> Don't you notice this mistake? > > It certainly isn't an exact size, and probably not a very good guess in many cases (e.g., a small number of objects > where one near the end is chosen), but it is at least a lower limit on the memory you need. > So I take it you propose to allocate the BitSet the first time you need it, while looping in the reverse order of this > array list? That will work, at the (fairly minor) expense of having to do a null check in the loop (or the added > complexity of an initial loop that runs until you find one and a second loop from that point to the end). I'm still > not convinced that this is worth the effort, at least not without a test case showing some gain that we can measure. Here's an improvement on BitSet: java private boolean remove(Collection c, boolean isRemoveAll) { BitSet bs = null; // find last index final int max = size(); int i; for (i = max - 1; i >= 0; i--) { if (c.contains(get(i)) == isRemoveAll) { bs = new BitSet(i); bs.set(i--); break; } } final boolean removed = bs != null; beginChange(); if (removed) { for (; i >= 0; i--) { if (c.contains(get(i)) == isRemoveAll) { bs.set(i); } } int cur = max; while ((cur = bs.previousSetBit(cur - 1)) >= 0) { remove(cur); } } endChange(); return removed; } Extreme test cases that show the most improvement. Java for (; olist.size() > 0;) { olist.removeAll(olist.get(olist.size() - 1)); } Here's an improvement on Run-Lengths: java private boolean remove(Collection c, boolean isRemoveAll) { int[] runLength = new int[4]; int size = 0; final int n = size(); { int run = 0; boolean flag = isRemoveAll; for (int i = n - 1; i >= 0; i--) { if (c.contains(get(i)) == flag) { run++; } else { if (runLength.length <= size) { runLength = Arrays.copyOf(runLength, Math.min(runLength.length << 1, n + 1)); } runLength[size++] = run; run = 1; flag = !flag; } } if (run > 0 && flag == isRemoveAll) { if (runLength.length <= size) { runLength = Arrays.copyOf(runLength, Math.min(runLength.length << 1, n + 1)); } runLength[size++] = run; } } boolean flag = true; boolean removed = false; beginChange(); int cur = n - 1; for (int i = 0; i < size; i++) { final int run = runLength[i]; if (flag) { removed = run > 0; for (int to = cur - run; cur > to; cur--) { remove(cur); } } else { cur -= run; } flag = !flag; } endChange(); return removed; } ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From ajoseph at openjdk.java.net Mon Oct 12 03:11:18 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 12 Oct 2020 03:11:18 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v7] In-Reply-To: References: Message-ID: > fillPath() and fillRect() functions in > [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) > use Image::drawPattern() for applying patterns as fill. But drawPattern() doesn't use patternTransform argument as > ImagePattern doesn't have the same attribute. So, the final image won't be transformed. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Fix incorrect concat param order ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/190/files - new: https://git.openjdk.java.net/jfx/pull/190/files/4241c502..abb4787a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=190&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=190&range=05-06 Stats: 4 lines in 2 files changed: 1 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/190/head:pull/190 PR: https://git.openjdk.java.net/jfx/pull/190 From ajoseph at openjdk.java.net Mon Oct 12 03:11:19 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 12 Oct 2020 03:11:19 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v6] In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 21:48:40 GMT, Kevin Rushforth wrote: >> Arun Joseph has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update copyright year >> - Minor refactoring > > modules/javafx.graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java line 742: > >> 740: } >> 741: >> 742: g2d.fill(tmpAT.createTransformedShape(shape)); > > Maybe move the `fill` call inside the try/catch so it won't draw anything if the transform is non-invertible? That > matches what `drawMappedTextureRaw` does. Moved `g2d.fill` into try/catch block. ------------- PR: https://git.openjdk.java.net/jfx/pull/190 From ajoseph at openjdk.java.net Mon Oct 12 03:26:10 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 12 Oct 2020 03:26:10 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v6] In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 22:14:15 GMT, Kevin Rushforth wrote: >> Arun Joseph has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update copyright year >> - Minor refactoring > > modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 790: > >> 788: Affine3D at = new Affine3D(); >> 789: at.translate(phase.getX(), phase.getY()); >> 790: at.concatenate(m[0], -m[1], m[4], -m[2], m[3], m[5]); > > Can you explain why the matrix is transformed in this way (specifically the negation of elements 1 and 2)? A code > comment would be helpful since it is non-obvious. Instead of negation, it should have been at the opposite positions. I have fixed this in the latest commit. The arg list order for [`concatenate`](https://github.com/openjdk/jfx/blob/a56ba63bef9b33c4ad5cc9e05ae5bdb0ee480a3f/modules/javafx.graphics/src/main/java/com/sun/javafx/geom/transform/AffineBase.java#L2849) is different compared to the constructor of Affine2D. ------------- PR: https://git.openjdk.java.net/jfx/pull/190 From aghaisas at openjdk.java.net Mon Oct 12 03:38:11 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 12 Oct 2020 03:38:11 GMT Subject: RFR: 8178297: TableView scrolls slightly when adding new elements [v2] In-Reply-To: References: <_ip0Z6pUqZ5_FA0f1bsX3HgO4zQBf2krfIiAEGJaIhc=.47d6d48e-94ef-4ae5-a909-626f5e72c804@github.com> Message-ID: On Wed, 23 Sep 2020 10:26:12 GMT, Jose Pereda wrote: >> This PR fixes an issue that happens when adding new items to a `TableView` or any other control that uses >> `VirtualFlow`, if the scroll position is not 0: the virtual flow is slightly shifted down. >> For instance, let's say that a cell has a layoutY of -10.0. After adding a new item to the table, during the layout >> pass the new value is initially modified to -9.999999999999996 (`VirtualFlow::adjustByPixelAmount`) , and then, after >> calling `VirtualFlow::positionCell` (that uses `snapSizeY(position)`) the layoutY is modified to -9.5, causing an >> undesired positive shift of 0.5 pixels. `Region` has different snap methods: `snapSizeX/Y` are used to snap node >> dimension values, like width or height, by ceiling to the nearest pixel (which explains the -9.5 value), while >> `snapSpaceX/Y` are used to snap position values like insets, by rounding to the nearest pixel (this will give the >> expected -10.0). Therefore, this PR modifies `VirtualFlow::positionCell` to use the `snapSpaceX/Y` methods, since >> these are being used to set the layout of the cell and not its size. Test: A unity test has been included. It >> simulates the case of adding new items to the virtual flow after an initial scroll. It currently fails after adding a >> few items, and it passes with the changes of this PR. > > Jose Pereda has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains three commits: > - Merge master > - Add test to verify the cell position remains constant when new cells are added to the virtualFlow. > - Use correct snap method to set cell layout Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/297 From jpereda at openjdk.java.net Mon Oct 12 08:25:08 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 12 Oct 2020 08:25:08 GMT Subject: Integrated: 8178297: TableView scrolls slightly when adding new elements In-Reply-To: <_ip0Z6pUqZ5_FA0f1bsX3HgO4zQBf2krfIiAEGJaIhc=.47d6d48e-94ef-4ae5-a909-626f5e72c804@github.com> References: <_ip0Z6pUqZ5_FA0f1bsX3HgO4zQBf2krfIiAEGJaIhc=.47d6d48e-94ef-4ae5-a909-626f5e72c804@github.com> Message-ID: On Mon, 7 Sep 2020 17:54:31 GMT, Jose Pereda wrote: > This PR fixes an issue that happens when adding new items to a `TableView` or any other control that uses > `VirtualFlow`, if the scroll position is not 0: the virtual flow is slightly shifted down. > For instance, let's say that a cell has a layoutY of -10.0. After adding a new item to the table, during the layout > pass the new value is initially modified to -9.999999999999996 (`VirtualFlow::adjustByPixelAmount`) , and then, after > calling `VirtualFlow::positionCell` (that uses `snapSizeY(position)`) the layoutY is modified to -9.5, causing an > undesired positive shift of 0.5 pixels. `Region` has different snap methods: `snapSizeX/Y` are used to snap node > dimension values, like width or height, by ceiling to the nearest pixel (which explains the -9.5 value), while > `snapSpaceX/Y` are used to snap position values like insets, by rounding to the nearest pixel (this will give the > expected -10.0). Therefore, this PR modifies `VirtualFlow::positionCell` to use the `snapSpaceX/Y` methods, since > these are being used to set the layout of the cell and not its size. Test: A unity test has been included. It > simulates the case of adding new items to the virtual flow after an initial scroll. It currently fails after adding a > few items, and it passes with the changes of this PR. This pull request has now been integrated. Changeset: 205e4b95 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/205e4b95 Stats: 24 lines in 2 files changed: 22 ins; 0 del; 2 mod 8178297: TableView scrolls slightly when adding new elements Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/297 From aghaisas at openjdk.java.net Mon Oct 12 10:08:09 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 12 Oct 2020 10:08:09 GMT Subject: RFR: 8253597: TreeTableView: must select leaf row on click into indentation region In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 12:08:52 GMT, Jeanette Winzenburg wrote: > .. but doesn't reliably (see report for details). Fixed in TreeTableCellBehavior to check for visibility of the > disclosureNode. > Added test that failed before and passes after, along with a couple of sanity tests. > > Also added an alternative mouseEvent creation path into MouseEventFirer (and test) to work-around > [JDK-8253769](https://bugs.openjdk.java.net/browse/JDK-8253769) Looks good. I spotted a typo. modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/MouseEventFirer.java line 259: > 257: * Fires a mouseEvent with the given configuration options onto the target. > 258: * Hot-fix for JDK-8253769. > 259: * The mouseEvent is created such that coordiate transformation constraints seem to be respected. coordiate --> coordinate ------------- PR: https://git.openjdk.java.net/jfx/pull/313 From fastegal at openjdk.java.net Mon Oct 12 13:26:22 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 12 Oct 2020 13:26:22 GMT Subject: RFR: 8253597: TreeTableView: must select leaf row on click into indentation region [v2] In-Reply-To: References: Message-ID: > .. but doesn't reliably (see report for details). Fixed in TreeTableCellBehavior to check for visibility of the > disclosureNode. > Added test that failed before and passes after, along with a couple of sanity tests. > > Also added an alternative mouseEvent creation path into MouseEventFirer (and test) to work-around > [JDK-8253769](https://bugs.openjdk.java.net/browse/JDK-8253769) Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: fixed typo ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/313/files - new: https://git.openjdk.java.net/jfx/pull/313/files/0fe1ca48..d06812eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=313&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=313&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/313.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/313/head:pull/313 PR: https://git.openjdk.java.net/jfx/pull/313 From fastegal at openjdk.java.net Mon Oct 12 13:26:25 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 12 Oct 2020 13:26:25 GMT Subject: RFR: 8253597: TreeTableView: must select leaf row on click into indentation region [v2] In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 09:23:47 GMT, Ajit Ghaisas wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed typo > > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/MouseEventFirer.java line 259: > >> 257: * Fires a mouseEvent with the given configuration options onto the target. >> 258: * Hot-fix for JDK-8253769. >> 259: * The mouseEvent is created such that coordiate transformation constraints seem to be respected. > > coordiate --> coordinate thanks for spotting it - there's always at least one ;) Fixed. ------------- PR: https://git.openjdk.java.net/jfx/pull/313 From aghaisas at openjdk.java.net Mon Oct 12 13:35:10 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 12 Oct 2020 13:35:10 GMT Subject: RFR: 8253597: TreeTableView: must select leaf row on click into indentation region [v2] In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 13:26:22 GMT, Jeanette Winzenburg wrote: >> .. but doesn't reliably (see report for details). Fixed in TreeTableCellBehavior to check for visibility of the >> disclosureNode. >> Added test that failed before and passes after, along with a couple of sanity tests. >> >> Also added an alternative mouseEvent creation path into MouseEventFirer (and test) to work-around >> [JDK-8253769](https://bugs.openjdk.java.net/browse/JDK-8253769) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > fixed typo Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/313 From kcr at openjdk.java.net Mon Oct 12 13:45:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 12 Oct 2020 13:45:14 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v6] In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 03:23:29 GMT, Arun Joseph wrote: >> modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 790: >> >>> 788: Affine3D at = new Affine3D(); >>> 789: at.translate(phase.getX(), phase.getY()); >>> 790: at.concatenate(m[0], -m[1], m[4], -m[2], m[3], m[5]); >> >> Can you explain why the matrix is transformed in this way (specifically the negation of elements 1 and 2)? A code >> comment would be helpful since it is non-obvious. > > Instead of negation, it should have been at the opposite positions. I have fixed this in the latest commit. The arg > list order for > [`concatenate`](https://github.com/openjdk/jfx/blob/a56ba63bef9b33c4ad5cc9e05ae5bdb0ee480a3f/modules/javafx.graphics/src/main/java/com/sun/javafx/geom/transform/AffineBase.java#L2849) > is different compared to the constructor of Affine2D. With your latest change, the call looks like what I would expect now. I suspect a shear transform would have been broken before this last fix, but I didn't try it. ------------- PR: https://git.openjdk.java.net/jfx/pull/190 From kcr at openjdk.java.net Mon Oct 12 13:48:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 12 Oct 2020 13:48:14 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v7] In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 03:11:18 GMT, Arun Joseph wrote: >> fillPath() and fillRect() functions in >> [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) >> use Image::drawPattern() for applying patterns as fill. But drawPattern() doesn't use patternTransform argument as >> ImagePattern doesn't have the same attribute. So, the final image won't be transformed. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Fix incorrect concat param order Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/190 From kcr at openjdk.java.net Mon Oct 12 13:51:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 12 Oct 2020 13:51:11 GMT Subject: RFR: 8223375: Remove Netbeans specific files from the source code repository In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 18:18:09 GMT, Kevin Rushforth wrote: >> As discussed in [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-July/027049.html) on >> openjfx-dev I propose to remove the old netbeans-specific files from the source repository. They were originally done >> for NetBeans 8 / FX 8,. They sort of worked (but not well) with FX 9 (still using NB 8), but no longer work at all. The >> gradle support in the latest Apache NetBeans 12 is already pretty good, with a couple bugs that they need to fix. There >> is no longer a reason to host these old netbeans project files in our repo. > > I'll leave this for a few days even if someone approves it sooner, in case there are any concerns raised. Is there any NetBeans user who wants to review or comment on this? If not, I'll ask @arapte to review it later this week so I can integrate it. ------------- PR: https://git.openjdk.java.net/jfx/pull/302 From ajoseph at openjdk.java.net Mon Oct 12 13:54:09 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 12 Oct 2020 13:54:09 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v6] In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 13:42:08 GMT, Kevin Rushforth wrote: >> Instead of negation, it should have been at the opposite positions. I have fixed this in the latest commit. The arg >> list order for >> [`concatenate`](https://github.com/openjdk/jfx/blob/a56ba63bef9b33c4ad5cc9e05ae5bdb0ee480a3f/modules/javafx.graphics/src/main/java/com/sun/javafx/geom/transform/AffineBase.java#L2849) >> is different compared to the constructor of Affine2D. > > With your latest change, the call looks like what I would expect now. I suspect a shear transform would have been > broken before this last fix, but I didn't try it. Yes, shear transforms were broken before this commit. Now, all transforms works as expected. ------------- PR: https://git.openjdk.java.net/jfx/pull/190 From fastegal at openjdk.java.net Mon Oct 12 14:54:09 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 12 Oct 2020 14:54:09 GMT Subject: Integrated: 8253597: TreeTableView: must select leaf row on click into indentation region In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 12:08:52 GMT, Jeanette Winzenburg wrote: > .. but doesn't reliably (see report for details). Fixed in TreeTableCellBehavior to check for visibility of the > disclosureNode. > Added test that failed before and passes after, along with a couple of sanity tests. > > Also added an alternative mouseEvent creation path into MouseEventFirer (and test) to work-around > [JDK-8253769](https://bugs.openjdk.java.net/browse/JDK-8253769) This pull request has now been integrated. Changeset: 00f5b7c2 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/00f5b7c2 Stats: 702 lines in 4 files changed: 696 ins; 0 del; 6 mod 8253597: TreeTableView: must select leaf row on click into indentation region Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/313 From arapte at openjdk.java.net Mon Oct 12 19:42:15 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 12 Oct 2020 19:42:15 GMT Subject: RFR: 8253935: [testbug] ComboBoxTest.testEditorKeyInputsWhenPopupIsShowing fails on Mac, Linux Message-ID: The test fails on Mac and Linux. Cause of failure: - Linux: Unlike Windows, on Linux CTRL + Arrow keys move the caret to end/beginning of current word and not to beginning/end of next word. - Mac: On Mac correct keys to traverse through words is ALT + Arrow and not CTRL + Arrow. And like on Linux, ALT + Arrow keys move the caret to end/beginning of current word and not to beginning/end of next word. Fix is to use correct keys and asserts according to platform. ------------- Commit messages: - test fix Changes: https://git.openjdk.java.net/jfx/pull/317/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=317&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253935 Stats: 42 lines in 1 file changed: 20 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/jfx/pull/317.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/317/head:pull/317 PR: https://git.openjdk.java.net/jfx/pull/317 From kcr at openjdk.java.net Mon Oct 12 20:19:10 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 12 Oct 2020 20:19:10 GMT Subject: RFR: 8253935: [testbug] ComboBoxTest.testEditorKeyInputsWhenPopupIsShowing fails on Mac, Linux In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 19:37:41 GMT, Ambarish Rapte wrote: > The test fails on Mac and Linux. > Cause of failure: > - Linux: Unlike Windows, on Linux CTRL + Arrow keys move the caret to end/beginning of current word and not to > beginning/end of next word. > - Mac: On Mac correct keys to traverse through words is ALT + Arrow and not CTRL + Arrow. And like on Linux, ALT + Arrow > keys move the caret to end/beginning of current word and not to beginning/end of next word. > > Fix is to use correct keys and asserts according to platform. The test changes look good, and pass for me on all three platforms. I left a couple suggestions for you to consider. modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 1394: > 1392: // Test CTRL + RIGHT key > 1393: keyboard.doKeyPress(KeyCode.RIGHT, KeyModifier.getShortcutKey()); > 1394: } Do you think it's worth adding another method to `KeyModifier` to encapsulate getting either ALT (on Mac) or the shortcut-key (on Windows or Linux)? That will minimize the number of places that you need to check the platform. modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 1400: > 1398: } else { > 1399: assertEquals(3, cb.getEditor().getCaretPosition()); > 1400: } Similarly, you might want to compute the index up front with a single platform check, and then you can use that index, both in the assert statements and to grab the expected selected text (using a substring call). ------------- PR: https://git.openjdk.java.net/jfx/pull/317 From daniel.peintner at gmail.com Tue Oct 13 12:19:31 2020 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Tue, 13 Oct 2020 14:19:31 +0200 Subject: TableView Future/Enhancements Message-ID: All, I would like to ask some questions (and provide feedback) w.r.t. the current TableView control in JavaFX. If this is not the *right* place to ask such questions please let me know and I apologize. The desire of a table (spreadsheet) control is to be editable and usable also with the keyboard. Moreover if using it with a mouse a focus loss is also mostly likely seen as a commit by a user (and not a revert as it is now) Some of the afore mentioned points are not (yet) realized and people seem to be aware of the issue (see [1]). I am not sure if there is work planned w.r.t. JDK-8089514 given that the work seems stalled... Attached is an EditableTableCell application that supports some of the desired features (but far not all). It uses some very dirty hacks to achieve for example editing and walking through a table (I tend to say some (all?) features should be built-in already). With this email I would like to 1. Raise the question whether future work is planned in the area of TableView (e.g., TableView2 that used to be part of ControlsFX but I think belongs to the core TableView) 2. Show some use cases people might have in mind when using a table control. The attached example allows one to - walk through a table when in editing mode (up/down with cursor, left/right with tabs) e.g., double click in upper left corner and walk on with tab key - (optionally) register a callable that adds a *new* row if end is reached - skip some columns that are not editable (like pulldown boxes) Missing features - better F2 edit support - use the keyboard also with combo boxes or other cell controls Please let me know whether there is interest in having such capabilities in the built-in TableView control and how I can help. I am open for suggestions. (i.e. I think JDK-8089514 could be solved at least for TableView. Not sure though about the other mentioned controls were I don't have the big picture) Sorry again for the lengthy email and any feedback is welcome! Thanks, -- Daniel [1] https://bugs.openjdk.java.net/browse/JDK-8089514 ############################# import javafx.application.Application; import javafx.application.Platform; import javafx.beans.property.ObjectProperty; import javafx.beans.property.SimpleObjectProperty; import javafx.beans.property.SimpleStringProperty; import javafx.beans.property.StringProperty; import javafx.collections.FXCollections; import javafx.collections.ObservableList; import javafx.collections.transformation.SortedList; import javafx.concurrent.Task; import javafx.event.Event; import javafx.scene.Scene; import javafx.scene.control.*; import javafx.scene.input.KeyCode; import javafx.scene.input.KeyEvent; import javafx.stage.Stage; import javafx.util.Pair; import javafx.util.StringConverter; import javafx.util.converter.DefaultStringConverter; import javafx.util.converter.IntegerStringConverter; import java.io.File; import java.io.IOException; import java.nio.file.Files; import java.nio.file.Paths; import java.util.ArrayList; import java.util.List; import java.util.concurrent.Callable; public class EditableTableCellApplication extends Application { public class EditableTableCell extends TableCell { public final Object NOT_TRAVERSABLE = new Object(); // Text field for editing // TODO: allow this to be a pluggable control final TextField textField = new TextField(); // converter for converting the text in the text field to the user type, and vice-versa final StringConverter converter; // callable to create new row final Callable callableOnRowEnd; public EditableTableCell(StringConverter converter) { this(converter, false); } public EditableTableCell(StringConverter converter, boolean traverseEditableCell) { this(converter, traverseEditableCell, null); } public EditableTableCell(StringConverter converter, boolean traverseEditableCell, Callable callableOnRowEnd) { this.converter = converter; this.callableOnRowEnd = callableOnRowEnd; itemProperty().addListener((obx, oldItem, newItem) -> { if (newItem == null) { setText(null); } else { setText(converter.toString(newItem)); } }); setGraphic(textField); setContentDisplay(ContentDisplay.TEXT_ONLY); textField.setOnAction(evt -> commitEdit(this.converter.fromString(textField.getText()))); textField.focusedProperty().addListener((obs, wasFocused, isNowFocused) -> { if (!isNowFocused) { commitEdit(this.converter.fromString(textField.getText())); } }); textField.addEventFilter(KeyEvent.KEY_PRESSED, event -> { if (event.getCode() == KeyCode.ESCAPE) { textField.setText(converter.toString(getItem())); cancelEdit(); event.consume(); } else if ((!event.isShiftDown() && event.getCode() == KeyCode.TAB)) { event.consume(); getTableView().getSelectionModel().selectRightCell(); if (traverseEditableCell) { Pair, Boolean> pairTcEnd = getNextVisibleColumn(true); if (pairTcEnd.getValue() != null && pairTcEnd.getValue()) { // reached end -> new line TableColumn tc0 = getFirstTraversableColumn(); if (tc0 != null) { //noinspection ConstantConditions moveRowDown(tc0, event, traverseEditableCell); } } else { // move right in row makeCellEditable(getTableRow().getIndex(), getTableView(), pairTcEnd.getKey()); } } } else if ((event.isShiftDown() && event.getCode() == KeyCode.TAB)) { if (traverseEditableCell) { Pair, Boolean> pairTcEnd = getNextVisibleColumn(false); if (pairTcEnd.getValue() != null && pairTcEnd.getValue()) { // reached end -> new line TableColumn tcLast = getLastTraversableColumn(); if (tcLast != null) { //noinspection ConstantConditions moveRowUp(tcLast, event, traverseEditableCell); } } else { // move left in row makeCellEditable(getTableRow().getIndex(), getTableView(), pairTcEnd.getKey()); } } } else if (event.getCode() == KeyCode.UP) { moveRowUp(getTableColumn(), event, traverseEditableCell); } else if (event.getCode() == KeyCode.DOWN) { moveRowDown(getTableColumn(), event, traverseEditableCell); } }); } // set the text of the text field and display the graphic @Override public void startEdit() { if (!editableProperty().get()) { return; } super.startEdit(); textField.setText(converter.toString(getItem())); setContentDisplay(ContentDisplay.GRAPHIC_ONLY); textField.requestFocus(); } // revert to text display @Override public void cancelEdit() { super.cancelEdit(); setContentDisplay(ContentDisplay.TEXT_ONLY); } // commits the edit. Update property if possible and revert to text display @Override public void commitEdit(T item) { // This block is necessary to support commit on losing focus, because the baked-in mechanism // sets our editing state to false before we can intercept the loss of focus. // The default commitEdit(...) method simply fails if we are not editing... if (!isEditing() && item != null && !item.equals(getItem())) { TableView table = getTableView(); if (table != null) { TableColumn column = getTableColumn(); TableColumn.CellEditEvent event = new TableColumn.CellEditEvent<>(table, new TablePosition<>(table, getIndex(), column), TableColumn.editCommitEvent(), item); Event.fireEvent(column, event); } } super.commitEdit(item); setContentDisplay(ContentDisplay.TEXT_ONLY); } private void makeCellEditable(int row2, TableView tw, TableColumn tc) { if (tc != null) { // HACK, JavaFX BUG!!! Task task = new Task() { @Override protected Void call() throws Exception { Thread.sleep(10); Platform.runLater(() -> { if (row2 >= 0 && row2 < tw.getItems().size()) { tw.getSelectionModel().clearAndSelect(row2, tc); tw.edit(row2, tc); } }); return null; } }; Thread th = new Thread(task); th.start(); } } private TableColumn getFirstTraversableColumn() { for (TableColumn tc : getTableView().getColumns()) { if (isTraversable(tc)) { return tc; } } return null; } private TableColumn getLastTraversableColumn() { for (int i = getTableView().getColumns().size() - 1; i >= 0; i--) { TableColumn tc = getTableView().getColumns().get(i); if (isTraversable(tc)) { return tc; } } return null; } private void moveRowDown(TableColumn tc, Event event, boolean traverseEditableCell) { int row2 = getTableRow().getIndex() + 1; //noinspection StatementWithEmptyBody if (row2 < getTableView().getItems().size()) { // still ok --> normal select } else { // expand rows if (callableOnRowEnd != null) { try { callableOnRowEnd.call(); } catch (Exception e) { e.printStackTrace(); } } } // select getTableView().getSelectionModel().clearAndSelect(row2, tc); commitEdit(converter.fromString(textField.getText())); // needed (otherwise data lost) event.consume(); if (traverseEditableCell) { makeCellEditable(row2, getTableView(), tc); } } private void moveRowUp(TableColumn tc, Event event, boolean traverseEditableCell) { int row2 = getTableRow().getIndex() - 1; // select getTableView().getSelectionModel().clearAndSelect(row2, tc); commitEdit(converter.fromString(textField.getText())); // needed (otherwise data lost) event.consume(); if (traverseEditableCell) { makeCellEditable(row2, getTableView(), tc); } } private Pair, Boolean> getNextVisibleColumn(boolean forward) { List> columns = new ArrayList<>(); for (TableColumn column : getTableView().getColumns()) { columns.addAll(getLeaves(column)); } int nextIndex = columns.indexOf(getTableColumn()); TableColumn tc; boolean reachedEdge = false; do { if (forward) { nextIndex++; if (nextIndex > columns.size() - 1) { nextIndex = columns.size() - 1; reachedEdge = true; } } else { nextIndex--; if (nextIndex < 0) { nextIndex = 0; reachedEdge = true; } } tc = columns.get(nextIndex); } while (!tc.isVisible() && !reachedEdge); return new Pair<>(tc, reachedEdge); } private List> getLeaves( TableColumn root) { List> columns = new ArrayList<>(); if (root.getColumns().isEmpty()) { // We only want the leaves that are editable / traversable if (isTraversable(root)) { columns.add(root); } } else { for (TableColumn column : root.getColumns()) { columns.addAll(getLeaves(column)); } } return columns; } private boolean isTraversable(TableColumn tc) { if (tc != null) { return (tc.isEditable() && tc.getUserData() != NOT_TRAVERSABLE); } return false; } } public class Person { final StringProperty firstName; final StringProperty lastName; final ObjectProperty age; public Person() { this.firstName = new SimpleStringProperty(); this.lastName = new SimpleStringProperty(); this.age = new SimpleObjectProperty<>(); } public Person(String firstName, String lastName, int age) { this(); this.firstName.set(firstName); this.lastName.set(lastName); this.age.set(age); } public StringProperty firstNameProperty() { return this.firstName; } public StringProperty lastNameProperty() { return this.lastName; } public ObjectProperty ageProperty() { return this.age; } } class CallableAdd implements Callable { @Override public Void call() { detailData.add(new Person()); return null; } } // The table's data ObservableList detailData = FXCollections.observableArrayList(); @Override public void start(Stage primaryStage) throws IOException { TableView tableView = new TableView<>(); tableView.setEditable(true); // without the following cell selection setting SHIFT+TAB does not work tableView.getSelectionModel().setCellSelectionEnabled(true); boolean traversable = true; CallableAdd callableAdd = new CallableAdd(); // remove empty row highlighting to better illustrate that *new* rows are added by tabbing through File f = File.createTempFile("style", ".css"); Files.write(Paths.get(f.getPath()), ".table-row-cell:empty {-fx-background-color: white;} .table-row-cell:empty .table-cell {-fx-border-width: 0px;}".getBytes()); tableView.getStylesheets().add("file:///" + f.getAbsolutePath().replace("\\", "/")); TableColumn columnFirstName = new TableColumn<>("First Name"); columnFirstName.setCellValueFactory(param -> param.getValue().firstNameProperty()); columnFirstName.setCellFactory(column -> new EditableTableCell<>(new DefaultStringConverter(), traversable, callableAdd)); columnFirstName.setEditable(true); TableColumn columnLastName = new TableColumn<>("Last Name"); columnLastName.setCellValueFactory(param -> param.getValue().lastNameProperty()); columnLastName.setCellFactory(column -> new EditableTableCell<>(new DefaultStringConverter(), traversable, callableAdd)); columnLastName.setEditable(true); TableColumn columnAge = new TableColumn<>("Age"); columnAge.setCellValueFactory(param -> param.getValue().ageProperty()); columnAge.setCellFactory(column -> new EditableTableCell<>(new IntegerStringConverter(), traversable, callableAdd)); columnAge.setEditable(true); tableView.getColumns().addAll(columnFirstName, columnLastName, columnAge); SortedList sortedData = new SortedList<>(detailData); tableView.setItems(sortedData); detailData.add(new Person("John", "Doe", 25)); detailData.add(new Person("Jane", "Deer", 30)); // create and show scene Scene scene = new Scene(tableView, 600, 400); primaryStage.setTitle("Editable TableCell Application"); primaryStage.setScene(scene); primaryStage.show(); } public static void main(String[] args) { launch(args); } } From arapte at openjdk.java.net Tue Oct 13 13:00:15 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 13 Oct 2020 13:00:15 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin Message-ID: `TabPaneSkin` installs some listeners that are not removed when `TabPaneSkin` is changed. The fix converts listeners to WeakListeners and also removes them on dispose. There is a NPE check change needed in `isHosrizontal()`. Without this check it causes NPE if pulse is in progress while TabPaneSkin is getting disposed. `SkinMemoryLeakTest` already had a test which only needed to be enabled. Test fails before and passes after this change. ------------- Commit messages: - 8242621: TabPane: Memory leak when switching skin Changes: https://git.openjdk.java.net/jfx/pull/318/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=318&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242621 Stats: 61 lines in 2 files changed: 43 ins; 10 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/318.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/318/head:pull/318 PR: https://git.openjdk.java.net/jfx/pull/318 From fastegal at openjdk.java.net Tue Oct 13 13:21:18 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 13 Oct 2020 13:21:18 GMT Subject: RFR: 8254040: [testbug] Need additional regressions tests for ObservableList removeAll / retainAll Message-ID: issue is about missing regressions tests for [JDK-8093144](https://bugs.openjdk.java.net/browse/JDK-8093144) added tests for implementations of ObservableList that might be effected (FilteredList, selectedItems in ListView and friends) - see bug report for details. Happily, the tests are passing with the current code base :) To see them failing requires to replace the methods with invalid implementations (the bug report has a snippet that can be c&p'ed to replace the correct version) ------------- Commit messages: - 8254040: [testbug] Need additional regressions tests for ObservableList Changes: https://git.openjdk.java.net/jfx/pull/319/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=319&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254040 Stats: 253 lines in 6 files changed: 253 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/319.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/319/head:pull/319 PR: https://git.openjdk.java.net/jfx/pull/319 From fastegal at openjdk.java.net Tue Oct 13 15:06:14 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 13 Oct 2020 15:06:14 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 12:56:10 GMT, Ambarish Rapte wrote: > `TabPaneSkin` installs some listeners that are not removed when `TabPaneSkin` is changed. > The fix converts listeners to WeakListeners and also removes them on dispose. > > There is a NPE check change needed in `isHosrizontal()`. Without this check it causes NPE if pulse is in progress while > TabPaneSkin is getting disposed. > `SkinMemoryLeakTest` already had a test which only needed to be enabled. > Test fails before and passes after this change. no review yet, just a couple of quick comments from my experience on recent cleanup of skins: - if NPE checks seem to be necessary, they always indicate an illegal state: whatever a method is doing, it must not access the skin after dispose. Usually it's the caller of the method that's misbehaving, it simply must not happen. It's worth digging why _exactly_ that's happening and if/how it can be solved without guarding against the null - while the overall memory test is already done, we still must test every single skin against side-effects (f.i. of listeners not doing any "late" update due to not being yet removed - the NPE above could well be such a case). Have a look at SkinCleanupTest for examples - when changing listener wiring, it's often a good idea to test that they are still doing there job (if not yet covered in the available tests) yeah, you don't get away with not writing tests *good-humored-grinning ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From github.com+10960818+schmidor at openjdk.java.net Tue Oct 13 16:25:11 2020 From: github.com+10960818+schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Tue, 13 Oct 2020 16:25:11 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: References: <9C1p4mWMNYAPwFRCwRLX2VGsMH4k3rkZd4ZVhxjw8NA=.d32adb57-173c-4b4e-85e0-c2d5db3d0954@github.com> Message-ID: On Fri, 9 Oct 2020 23:17:27 GMT, Kevin Rushforth wrote: >> The full recreation of the pipeline is only done when D3DERR_DEVICEREMOVED is occurring. On other causes of why the >> device is not ready, only the factory reference in the painter is cleared. > >> The full recreation of the pipeline is only done when D3DERR_DEVICEREMOVED is occurring > > I see that now. That part is fine then. > > Another concern is that this would be the first time we have recreated a GraphicsPipeline -- they are effectively > singletons today. This could have unexpected side effects and would need to be very carefully reviewed and tested. > Have you considered an alternative where you retain the GraphicsPipeline, but recreate the native device? I hope I understood your intend. I've tried to replace the recreation of the GraphicsPipeline-Instance by only calling the native parts. Unfortunately that doesn't seem to work at all. Probably I'm missing some updates. public boolean reinit() { if (d3dEnabled) { if (creator != Thread.currentThread()) { throw new IllegalStateException( "This operation is not permitted on the current thread [" + Thread.currentThread().getName() + "]"); } notifyAllResourcesReleased(); nDispose(); for (int i = 0; i != factories.length; ++i) { factories[i] = null; } nInit(PrismSettings.class); factories = new D3DResourceFactory[nGetAdapterCount()]; } return d3dEnabled; } ------------- PR: https://git.openjdk.java.net/jfx/pull/315 From github.com+10960818+schmidor at openjdk.java.net Tue Oct 13 16:44:11 2020 From: github.com+10960818+schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Tue, 13 Oct 2020 16:44:11 GMT Subject: RFR: [WIP] 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: References: <9C1p4mWMNYAPwFRCwRLX2VGsMH4k3rkZd4ZVhxjw8NA=.d32adb57-173c-4b4e-85e0-c2d5db3d0954@github.com> Message-ID: On Tue, 13 Oct 2020 16:22:36 GMT, Oliver Schmidtmer wrote: >>> The full recreation of the pipeline is only done when D3DERR_DEVICEREMOVED is occurring >> >> I see that now. That part is fine then. >> >> Another concern is that this would be the first time we have recreated a GraphicsPipeline -- they are effectively >> singletons today. This could have unexpected side effects and would need to be very carefully reviewed and tested. >> Have you considered an alternative where you retain the GraphicsPipeline, but recreate the native device? > > I hope I understood your intend. I've tried to replace the recreation of the GraphicsPipeline-Instance by only calling > the native parts. Unfortunately that doesn't seem to work at all. Probably I'm missing some updates. > public boolean reinit() { > if (d3dEnabled) { > if (creator != Thread.currentThread()) { > throw new IllegalStateException( > "This operation is not permitted on the current thread [" > + Thread.currentThread().getName() + "]"); > } > notifyAllResourcesReleased(); > nDispose(); > for (int i = 0; i != factories.length; ++i) { > factories[i] = null; > } > nInit(PrismSettings.class); > factories = new D3DResourceFactory[nGetAdapterCount()]; > } > return d3dEnabled; > } On a side note, not all resources seem to be freed / recreated on pipeline disposal. There are some error outputs, and some parts in a webview are only rendered after interactions. So it is probably better to mark this as WIP. I would be happy if you have some advice for me. java.lang.IllegalStateException: unmanaged resource freed from pool D3D Vram Pool at com.sun.prism.impl.BaseResourcePool.resourceFreed(BaseResourcePool.java:463) at com.sun.prism.impl.ManagedResource.dispose(ManagedResource.java:127) at com.sun.prism.impl.BaseTexture.dispose(BaseTexture.java:297) at com.sun.scenario.effect.impl.prism.ps.PPSDrawable.flush(PPSDrawable.java:69) at com.sun.scenario.effect.impl.ImagePool.dispose(ImagePool.java:267) at com.sun.scenario.effect.impl.Renderer.getRenderer(Renderer.java:367) at com.sun.scenario.effect.Effect.getCompatibleImage(Effect.java:479) at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Layer.(WCGraphicsPrismContext.java:1369) at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$ClipLayer.(WCGraphicsPrismContext.java:1440) at com.sun.javafx.webkit.prism.WCGraphicsPrismContext.setClip(WCGraphicsPrismContext.java:328) at com.sun.webkit.graphics.GraphicsDecoder.decode(GraphicsDecoder.java:225) at com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.java:92) at com.sun.webkit.WebPage.paint2GC(WebPage.java:736) at com.sun.webkit.WebPage.paint(WebPage.java:703) at com.sun.javafx.sg.prism.web.NGWebView.renderContent(NGWebView.java:95) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) 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) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) at com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:143) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) at java.base/java.lang.Thread.run(Thread.java:832) ------------- PR: https://git.openjdk.java.net/jfx/pull/315 From arapte at openjdk.java.net Tue Oct 13 17:11:19 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 13 Oct 2020 17:11:19 GMT Subject: RFR: 8253935: [testbug] ComboBoxTest.testEditorKeyInputsWhenPopupIsShowing fails on Mac, Linux [v2] In-Reply-To: References: Message-ID: > The test fails on Mac and Linux. > Cause of failure: > - Linux: Unlike Windows, on Linux CTRL + Arrow keys move the caret to end/beginning of current word and not to > beginning/end of next word. > - Mac: On Mac correct keys to traverse through words is ALT + Arrow and not CTRL + Arrow. And like on Linux, ALT + Arrow > keys move the caret to end/beginning of current word and not to beginning/end of next word. > > Fix is to use correct keys and asserts according to platform. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: review update ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/317/files - new: https://git.openjdk.java.net/jfx/pull/317/files/da40fe41..7347a4dd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=317&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=317&range=00-01 Stats: 33 lines in 2 files changed: 7 ins; 18 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/317.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/317/head:pull/317 PR: https://git.openjdk.java.net/jfx/pull/317 From arapte at openjdk.java.net Tue Oct 13 17:28:23 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 13 Oct 2020 17:28:23 GMT Subject: RFR: 8253935: [testbug] ComboBoxTest.testEditorKeyInputsWhenPopupIsShowing fails on Mac, Linux [v3] In-Reply-To: References: Message-ID: > The test fails on Mac and Linux. > Cause of failure: > - Linux: Unlike Windows, on Linux CTRL + Arrow keys move the caret to end/beginning of current word and not to > beginning/end of next word. > - Mac: On Mac correct keys to traverse through words is ALT + Arrow and not CTRL + Arrow. And like on Linux, ALT + Arrow > keys move the caret to end/beginning of current word and not to beginning/end of next word. > > Fix is to use correct keys and asserts according to platform. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: use getShourtcutKey() ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/317/files - new: https://git.openjdk.java.net/jfx/pull/317/files/7347a4dd..2ca7e1e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=317&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=317&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/317.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/317/head:pull/317 PR: https://git.openjdk.java.net/jfx/pull/317 From arapte at openjdk.java.net Tue Oct 13 17:28:25 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 13 Oct 2020 17:28:25 GMT Subject: RFR: 8253935: [testbug] ComboBoxTest.testEditorKeyInputsWhenPopupIsShowing fails on Mac, Linux [v3] In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 19:51:37 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> use getShourtcutKey() > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 1394: > >> 1392: // Test CTRL + RIGHT key >> 1393: keyboard.doKeyPress(KeyCode.RIGHT, KeyModifier.getShortcutKey()); >> 1394: } > > Do you think it's worth adding another method to `KeyModifier` to encapsulate getting either ALT (on Mac) or the > shortcut-key (on Windows or Linux)? That will minimize the number of places that you need to check the platform. That seems better, added `getWordTraversalKey()` method to `KeyModifier`. > modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 1400: > >> 1398: } else { >> 1399: assertEquals(3, cb.getEditor().getCaretPosition()); >> 1400: } > > Similarly, you might want to compute the index up front with a single platform check, and then you can use that index, > both in the assert statements and to grab the expected selected text (using a substring call). Changed both the asserts as you mentioned. ------------- PR: https://git.openjdk.java.net/jfx/pull/317 From kcr at openjdk.java.net Tue Oct 13 23:59:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 13 Oct 2020 23:59:07 GMT Subject: RFR: 8253935: [testbug] ComboBoxTest.testEditorKeyInputsWhenPopupIsShowing fails on Mac, Linux [v3] In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 17:28:23 GMT, Ambarish Rapte wrote: >> The test fails on Mac and Linux. >> Cause of failure: >> - Linux: Unlike Windows, on Linux CTRL + Arrow keys move the caret to end/beginning of current word and not to >> beginning/end of next word. >> - Mac: On Mac correct keys to traverse through words is ALT + Arrow and not CTRL + Arrow. And like on Linux, ALT + Arrow >> keys move the caret to end/beginning of current word and not to beginning/end of next word. >> >> Fix is to use correct keys and asserts according to platform. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > use getShourtcutKey() Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/317 From arapte at openjdk.java.net Wed Oct 14 05:22:08 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 14 Oct 2020 05:22:08 GMT Subject: Integrated: 8253935: [testbug] ComboBoxTest.testEditorKeyInputsWhenPopupIsShowing fails on Mac, Linux In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 19:37:41 GMT, Ambarish Rapte wrote: > The test fails on Mac and Linux. > Cause of failure: > - Linux: Unlike Windows, on Linux CTRL + Arrow keys move the caret to end/beginning of current word and not to > beginning/end of next word. > - Mac: On Mac correct keys to traverse through words is ALT + Arrow and not CTRL + Arrow. And like on Linux, ALT + Arrow > keys move the caret to end/beginning of current word and not to beginning/end of next word. > > Fix is to use correct keys and asserts according to platform. This pull request has now been integrated. Changeset: eaabfc5e Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/eaabfc5e Stats: 32 lines in 2 files changed: 9 ins; 0 del; 23 mod 8253935: [testbug] ComboBoxTest.testEditorKeyInputsWhenPopupIsShowing fails on Mac, Linux Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/317 From fastegal at openjdk.java.net Wed Oct 14 10:38:15 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 14 Oct 2020 10:38:15 GMT Subject: RFR: 8246202: ChoiceBoxSkin: misbehavior on switching skin, part 2 Message-ID: issue is a listener in ChoiceBoxSkin that wasn't removed (forgotten in my first cleanup ;) Removed, un-ignored test that failed/passed before/after the fix ------------- Commit messages: - 8246202: ChoiceBoxSkin: misbehavior on switching skin, part 2 Changes: https://git.openjdk.java.net/jfx/pull/320/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=320&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246202 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/320.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/320/head:pull/320 PR: https://git.openjdk.java.net/jfx/pull/320 From kcr at openjdk.java.net Wed Oct 14 12:12:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 14 Oct 2020 12:12:15 GMT Subject: RFR: 8246202: ChoiceBoxSkin: misbehavior on switching skin, part 2 In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 10:34:54 GMT, Jeanette Winzenburg wrote: > issue is a listener in ChoiceBoxSkin that wasn't removed (forgotten in my first cleanup ;) > > Removed, un-ignored test that failed/passed before/after the fix modules/javafx.controls/src/main/java/javafx/scene/control/skin/ChoiceBoxSkin.java line 209: > 207: /** {@inheritDoc} */ > 208: @Override public void dispose() { > 209: if (getSkinnable() == null) return; This will short-circuit the rest of the method, including the call to `super.dispose()`, if `getSkinnable()` is null. Are there any cases where this might miss some needed cleanup? ------------- PR: https://git.openjdk.java.net/jfx/pull/320 From kcr at openjdk.java.net Wed Oct 14 12:41:06 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 14 Oct 2020 12:41:06 GMT Subject: RFR: 8254040: [testbug] Need additional regressions tests for ObservableList removeAll / retainAll In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 13:15:10 GMT, Jeanette Winzenburg wrote: > issue is about missing regressions tests for [JDK-8093144](https://bugs.openjdk.java.net/browse/JDK-8093144) > > added tests for implementations of ObservableList that might be effected (FilteredList, selectedItems in ListView and > friends) - see bug report for details. Happily, the tests are passing with the current code base :) To see them failing > requires to replace the methods with invalid implementations (the bug report has a snippet that can be c&p'ed to > replace the correct version) Looks great. Thanks for the additional tests. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/319 From fastegal at openjdk.java.net Wed Oct 14 14:19:13 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 14 Oct 2020 14:19:13 GMT Subject: RFR: 8246202: ChoiceBoxSkin: misbehavior on switching skin, part 2 In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 12:08:59 GMT, Kevin Rushforth wrote: >> issue is a listener in ChoiceBoxSkin that wasn't removed (forgotten in my first cleanup ;) >> >> Removed, un-ignored test that failed/passed before/after the fix > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ChoiceBoxSkin.java line 209: > >> 207: /** {@inheritDoc} */ >> 208: @Override public void dispose() { >> 209: if (getSkinnable() == null) return; > > This will short-circuit the rest of the method, including the call to `super.dispose()`, if `getSkinnable()` is null. > Are there any cases where this might miss some needed cleanup? that's intentional - the usual pattern to make dispose cope with repeated calls (something we learned in [JDK-8244112](https://bugs.openjdk.java.net/browse/JDK-8244112): the ony valid path to having skinnable null is a previous call to dispose (which is allowed by client code) in which we already did all clean-up. ------------- PR: https://git.openjdk.java.net/jfx/pull/320 From fastegal at openjdk.java.net Wed Oct 14 14:22:10 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 14 Oct 2020 14:22:10 GMT Subject: Integrated: 8254040: [testbug] Need additional regressions tests for ObservableList removeAll / retainAll In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 13:15:10 GMT, Jeanette Winzenburg wrote: > issue is about missing regressions tests for [JDK-8093144](https://bugs.openjdk.java.net/browse/JDK-8093144) > > added tests for implementations of ObservableList that might be effected (FilteredList, selectedItems in ListView and > friends) - see bug report for details. Happily, the tests are passing with the current code base :) To see them failing > requires to replace the methods with invalid implementations (the bug report has a snippet that can be c&p'ed to > replace the correct version) This pull request has now been integrated. Changeset: eb626aa1 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/eb626aa1 Stats: 253 lines in 6 files changed: 253 ins; 0 del; 0 mod 8254040: [testbug] Need additional regressions tests for ObservableList removeAll / retainAll Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/319 From aghaisas at openjdk.java.net Wed Oct 14 14:46:12 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 14 Oct 2020 14:46:12 GMT Subject: RFR: 8246202: ChoiceBoxSkin: misbehavior on switching skin, part 2 In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 10:34:54 GMT, Jeanette Winzenburg wrote: > issue is a listener in ChoiceBoxSkin that wasn't removed (forgotten in my first cleanup ;) > > Removed, un-ignored test that failed/passed before/after the fix modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 114: > 112: > 113: /** > 114: * FIXME: Left-over from ChoiceBox fix. along with @Ignore, we need to get rid of this FIXME comment as well :) ------------- PR: https://git.openjdk.java.net/jfx/pull/320 From fastegal at openjdk.java.net Wed Oct 14 14:46:16 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 14 Oct 2020 14:46:16 GMT Subject: RFR: 8246202: ChoiceBoxSkin: misbehavior on switching skin, part 2 In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 14:42:42 GMT, Ajit Ghaisas wrote: >> issue is a listener in ChoiceBoxSkin that wasn't removed (forgotten in my first cleanup ;) >> >> Removed, un-ignored test that failed/passed before/after the fix > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 114: > >> 112: >> 113: /** >> 114: * FIXME: Left-over from ChoiceBox fix. > > along with @Ignore, we need to get rid of this FIXME comment as well :) darn oversight .. thanks for spotting it :) ------------- PR: https://git.openjdk.java.net/jfx/pull/320 From fastegal at openjdk.java.net Wed Oct 14 14:50:23 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 14 Oct 2020 14:50:23 GMT Subject: RFR: 8246202: ChoiceBoxSkin: misbehavior on switching skin, part 2 [v2] In-Reply-To: References: Message-ID: <04eBtNM65ZLRNEq8euEDMVq0flFuNWCk16l7s2PCrsM=.e5413fab-c8f1-4de8-ac49-29d4891edbfd@github.com> > issue is a listener in ChoiceBoxSkin that wasn't removed (forgotten in my first cleanup ;) > > Removed, un-ignored test that failed/passed before/after the fix Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: removed outdated fixme ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/320/files - new: https://git.openjdk.java.net/jfx/pull/320/files/72f6e1a6..06c194d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=320&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=320&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/320.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/320/head:pull/320 PR: https://git.openjdk.java.net/jfx/pull/320 From kcr at openjdk.java.net Wed Oct 14 15:51:10 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 14 Oct 2020 15:51:10 GMT Subject: RFR: 8246202: ChoiceBoxSkin: misbehavior on switching skin, part 2 [v2] In-Reply-To: <04eBtNM65ZLRNEq8euEDMVq0flFuNWCk16l7s2PCrsM=.e5413fab-c8f1-4de8-ac49-29d4891edbfd@github.com> References: <04eBtNM65ZLRNEq8euEDMVq0flFuNWCk16l7s2PCrsM=.e5413fab-c8f1-4de8-ac49-29d4891edbfd@github.com> Message-ID: On Wed, 14 Oct 2020 14:50:23 GMT, Jeanette Winzenburg wrote: >> issue is a listener in ChoiceBoxSkin that wasn't removed (forgotten in my first cleanup ;) >> >> Removed, un-ignored test that failed/passed before/after the fix > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > removed outdated fixme Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/320 From aghaisas at openjdk.java.net Thu Oct 15 04:16:12 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 15 Oct 2020 04:16:12 GMT Subject: RFR: 8246202: ChoiceBoxSkin: misbehavior on switching skin, part 2 [v2] In-Reply-To: <04eBtNM65ZLRNEq8euEDMVq0flFuNWCk16l7s2PCrsM=.e5413fab-c8f1-4de8-ac49-29d4891edbfd@github.com> References: <04eBtNM65ZLRNEq8euEDMVq0flFuNWCk16l7s2PCrsM=.e5413fab-c8f1-4de8-ac49-29d4891edbfd@github.com> Message-ID: On Wed, 14 Oct 2020 14:50:23 GMT, Jeanette Winzenburg wrote: >> issue is a listener in ChoiceBoxSkin that wasn't removed (forgotten in my first cleanup ;) >> >> Removed, un-ignored test that failed/passed before/after the fix > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > removed outdated fixme Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/320 From fastegal at openjdk.java.net Thu Oct 15 08:46:11 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 15 Oct 2020 08:46:11 GMT Subject: Integrated: 8246202: ChoiceBoxSkin: misbehavior on switching skin, part 2 In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 10:34:54 GMT, Jeanette Winzenburg wrote: > issue is a listener in ChoiceBoxSkin that wasn't removed (forgotten in my first cleanup ;) > > Removed, un-ignored test that failed/passed before/after the fix This pull request has now been integrated. Changeset: e856a58f Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/e856a58f Stats: 6 lines in 2 files changed: 3 ins; 1 del; 2 mod 8246202: ChoiceBoxSkin: misbehavior on switching skin, part 2 Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/320 From kcr at openjdk.java.net Thu Oct 15 23:32:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 15 Oct 2020 23:32:15 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 12:56:10 GMT, Ambarish Rapte wrote: > `TabPaneSkin` installs some listeners that are not removed when `TabPaneSkin` is changed. > The fix converts listeners to WeakListeners and also removes them on dispose. > > There is a NPE check change needed in `isHosrizontal()`. Without this check it causes NPE if pulse is in progress while > TabPaneSkin is getting disposed. > `SkinMemoryLeakTest` already had a test which only needed to be enabled. > Test fails before and passes after this change. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 274: > 272: getSkinnable().getTabs().removeListener(weakTabsListener); > 273: > 274: getChildren().remove(tabHeaderArea); As mentioned offline, can you check whether removing `tabHeaderArea` is necessary? modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 716: > 714: > 715: private boolean isHorizontal() { > 716: Side tabPosition = getSkinnable() != null ? getSkinnable().getSide() : Side.TOP; I agree with @kleopatra This null check suggests that someone (a listener perhaps?) is calling into the skin after it has been disposed. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 1226: > 1224: > 1225: void removeListeners() { > 1226: for(Node child : headersRegion.getChildren()) { Minor: space after the `for` ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From jvos at openjdk.java.net Fri Oct 16 10:44:12 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 16 Oct 2020 10:44:12 GMT Subject: RFR: 8254605: repaint on Android broken Message-ID: <7hzb7Bje_JwY6C3N65xC3BCIRj1A0tA9chJiPLw35dI=.8fc69226-8be3-4a06-a577-cb8fd4ae4260@github.com> Don't check on windows visiblity when requesting focus. For a new window, the call to requestFocus is done before the visibility is set to true. Fix for JDK-8254605 ------------- Commit messages: - Don't check on windows visiblity when requesting focus. Changes: https://git.openjdk.java.net/jfx/pull/322/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=322&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254605 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/322.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/322/head:pull/322 PR: https://git.openjdk.java.net/jfx/pull/322 From nlisker at gmail.com Fri Oct 16 11:59:11 2020 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 16 Oct 2020 14:59:11 +0300 Subject: Default value of Spinner editable property Message-ID: Hi, Spinner's editable property seems to have conflicting initial values. isEditable() returns true on an uninitialized property, but initializing it sets its default to false: private BooleanProperty editable; public final void setEditable(boolean value) { editableProperty().set(value); } public final boolean isEditable() { return editable == null ? true : editable.get(); // <---- true } public final BooleanProperty editableProperty() { if (editable == null) { editable = new SimpleBooleanProperty(this, "editable", false); // <---- false } return editable; } Seeme like a bug. What is the correct default? - Nir From nlisker at gmail.com Fri Oct 16 12:06:53 2020 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 16 Oct 2020 15:06:53 +0300 Subject: Default value of Spinner editable property In-Reply-To: References: Message-ID: I noticed now that the class docs specify that the default is false. Should isEditable() be changed to return false on a null property? On Fri, Oct 16, 2020 at 2:59 PM Nir Lisker wrote: > Hi, > > Spinner's editable property seems to have conflicting initial values. > isEditable() returns true on an uninitialized property, but initializing it > sets its default to false: > > private BooleanProperty editable; > public final void setEditable(boolean value) { > editableProperty().set(value); > } > public final boolean isEditable() { > return editable == null ? true : editable.get(); // <---- true > } > public final BooleanProperty editableProperty() { > if (editable == null) { > editable = new SimpleBooleanProperty(this, "editable", false); > // <---- false > } > return editable; > } > > Seeme like a bug. What is the correct default? > > - Nir > From jvos at openjdk.java.net Fri Oct 16 12:34:05 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 16 Oct 2020 12:34:05 GMT Subject: RFR: 8254605: repaint on Android broken In-Reply-To: <7hzb7Bje_JwY6C3N65xC3BCIRj1A0tA9chJiPLw35dI=.8fc69226-8be3-4a06-a577-cb8fd4ae4260@github.com> References: <7hzb7Bje_JwY6C3N65xC3BCIRj1A0tA9chJiPLw35dI=.8fc69226-8be3-4a06-a577-cb8fd4ae4260@github.com> Message-ID: On Fri, 16 Oct 2020 10:39:09 GMT, Johan Vos wrote: > Don't check on windows visiblity when requesting focus. > For a new window, the call to requestFocus is done before the visibility is set to true. > Fix for JDK-8254605 @arapte and @kevinrushforth Since you reviewed https://github.com/openjdk/jfx/pull/153 can you review this? I think the change in #153 does not check on "closed stages" but on "windows that are not visible yet" which is not the same. Therefore, this PR would revert #153 as it introduces regression. ------------- PR: https://git.openjdk.java.net/jfx/pull/322 From fkirmaier at openjdk.java.net Fri Oct 16 14:12:14 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 16 Oct 2020 14:12:14 GMT Subject: RFR: 8244297: memory leak test utility [v6] In-Reply-To: <4Yzd4sm7fdBWVb6_5DOrIsJRTcsof6fxgrKiYQOf_iA=.b291ffa5-f876-4a8c-a5bb-736fd8c2b14d@github.com> References: <4Yzd4sm7fdBWVb6_5DOrIsJRTcsof6fxgrKiYQOf_iA=.b291ffa5-f876-4a8c-a5bb-736fd8c2b14d@github.com> Message-ID: <6ckTsBx3CRWv0855pSFN5pE1z9OqmmZhR4MjH2oc7Fs=.ada59fd2-8fd9-434e-8ebb-693ab236051c@github.com> On Thu, 8 Oct 2020 07:47:33 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8244297 >> Fixed unit-test > > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 79: > >> 77: AssertCollectable assertCollectable = new AssertCollectable(weakReference); >> 78: createHeapDump(); >> 79: throw new AssertionError("Content of WeakReference was not collected. content: " + weakReference.get()); > > Can be replaced with `assertNull` It's more like the opposite. assertNotNull. But the checks are also more complicated than the standard check because it's combined with some GC-magic. > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 84: > >> 82: >> 83: /** >> 84: * Checks whether the content of the WeakReference can be collected. > > -> Checks whether the content of the WeakReference **is** collected. That's not true. At the moment of method-call, the variable might not be collected. It doesen't check whether it's collected, it checks whether it is "collectable". > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 88: > >> 86: * @return Returns true, when the provided WeakReference can be collected. >> 87: */ >> 88: public static boolean checkCollectable(WeakReference weakReference) { > > I would prefer a name like `checkIfCollected` or `checkIfGCed` That's not true. see one of the other comments. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From fkirmaier at openjdk.java.net Fri Oct 16 14:16:15 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 16 Oct 2020 14:16:15 GMT Subject: RFR: 8244297: memory leak test utility [v6] In-Reply-To: <4Yzd4sm7fdBWVb6_5DOrIsJRTcsof6fxgrKiYQOf_iA=.b291ffa5-f876-4a8c-a5bb-736fd8c2b14d@github.com> References: <4Yzd4sm7fdBWVb6_5DOrIsJRTcsof6fxgrKiYQOf_iA=.b291ffa5-f876-4a8c-a5bb-736fd8c2b14d@github.com> Message-ID: On Thu, 8 Oct 2020 07:50:02 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8244297 >> Fixed unit-test > > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 255: > >> 253: >> 254: static class AssertCollectable { >> 255: WeakReference assertCollectable; > > There is method, class member variable and class itself with the same name `assertCollectable`. > I think they should be named differently, like for instance, > 1. Class `AssertCollectable` can be named as `CollectableReferernce` or `ReferenceToBeGC` > 2. The member variable `assertCollectable` can be named as just `weakRef` or `reference`. > 3. The method `assertCollectable` can be named as `checkIfGCed` or `checkIfCollected` > > Similar change for `AssertNotCollectable` 1.) Main purpose of the class is being easy searchable in tools like VisualVM. CollectableReference isn't correct, because we don't know whether it's collectable. That's what we are checking. 2.) true, but the old name has the benefit to be easier recognizable in tools like VisualVM. 3.) See other comments on the same topic. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From fkirmaier at openjdk.java.net Fri Oct 16 15:12:11 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 16 Oct 2020 15:12:11 GMT Subject: RFR: 8244297: memory leak test utility [v5] In-Reply-To: References: Message-ID: <3msnHFopco5jeuBS_9IDr4PAHVGkBCacIYG1MJ8yqYM=.f060b331-bc8b-4f76-b83c-5835c0d72b74@github.com> On Thu, 8 Oct 2020 07:57:17 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8244297 >> Fixing some wrong imports > > I have reviewed only in perspective of Java coding guidelines. I still have to review the functionality. > Most of the comments are minor like variable name change and typos. I would recommend you to please go through all of > the code to find and fix any other corrections related to Coding guidelines. Thank you for the feedback. I will integrate some of them into JMemoryBuddy! (and update the PR to reflect these changes) To check whether the Library is working properly, you can check the existing unit-tests and Travis builds in the original repository: https://github.com/Sandec/JMemoryBuddy I've copied the code of the original project because adding it as a dependency is not allowed. I don't want to make changes in the copy, except for changes in the default configuration. But I don't want to maintain two versions of the Library, so I don't plan to confirm all coding guidelines of the JFX-project inside of JMemoryBuddy. I think that's the way how other Libraries are also handled, like the C-Code which is used for the WebView. Otherwise, it would be bad for maintenance. I hope that's ok, otherwise, I will have to cancel the PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From arapte at openjdk.java.net Fri Oct 16 18:30:09 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 16 Oct 2020 18:30:09 GMT Subject: RFR: 8223375: Remove Netbeans specific files from the source code repository In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 18:17:30 GMT, Kevin Rushforth wrote: > As discussed in [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-July/027049.html) on > openjfx-dev I propose to remove the old netbeans-specific files from the source repository. They were originally done > for NetBeans 8 / FX 8,. They sort of worked (but not well) with FX 9 (still using NB 8), but no longer work at all. The > gradle support in the latest Apache NetBeans 12 is already pretty good, with a couple bugs that they need to fix. There > is no longer a reason to host these old netbeans project files in our repo. Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/302 From kcr at openjdk.java.net Fri Oct 16 20:23:05 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Oct 2020 20:23:05 GMT Subject: Integrated: 8223375: Remove Netbeans specific files from the source code repository In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 18:17:30 GMT, Kevin Rushforth wrote: > As discussed in [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-July/027049.html) on > openjfx-dev I propose to remove the old netbeans-specific files from the source repository. They were originally done > for NetBeans 8 / FX 8,. They sort of worked (but not well) with FX 9 (still using NB 8), but no longer work at all. The > gradle support in the latest Apache NetBeans 12 is already pretty good, with a couple bugs that they need to fix. There > is no longer a reason to host these old netbeans project files in our repo. This pull request has now been integrated. Changeset: 31fce21f Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/31fce21f Stats: 32535 lines in 155 files changed: 0 ins; 32535 del; 0 mod 8223375: Remove Netbeans specific files from the source code repository Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/302 From kcr at openjdk.java.net Fri Oct 16 23:10:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Oct 2020 23:10:15 GMT Subject: RFR: 8254605: repaint on Android broken In-Reply-To: References: <7hzb7Bje_JwY6C3N65xC3BCIRj1A0tA9chJiPLw35dI=.8fc69226-8be3-4a06-a577-cb8fd4ae4260@github.com> Message-ID: On Fri, 16 Oct 2020 12:31:31 GMT, Johan Vos wrote: >> Don't check on windows visiblity when requesting focus. >> For a new window, the call to requestFocus is done before the visibility is set to true. >> Fix for JDK-8254605 > > @arapte and @kevinrushforth Since you reviewed https://github.com/openjdk/jfx/pull/153 can you review this? > I think the change in #153 does not check on "closed stages" but on "windows that are not visible yet" which is not the > same. Therefore, this PR would revert #153 as it introduces regression. Reverting the fix for [JDK-8241840](https://bugs.openjdk.java.net/browse/JDK-8241840) does seem the best way to address this, since the current failure is much more serious that the memory leak was. Two comments: 1. Can you file a new bug to redo the fix for [JDK-8241840](https://bugs.openjdk.java.net/browse/JDK-8241840) with a summary like: [REDO] Memoryleak: Closed focused Stages are not collected with Monocle Indicate that the original fix is being reverted, so will need to be redone. Link the new bug to both this bug and to [JDK-8241840](https://bugs.openjdk.java.net/browse/JDK-8241840). 2. Unsurprisingly, this backout fix causes one of the newly added unit tests to fail: $ gradle ... test.javafx.stage.FocusedWindowMonocleTest > testClosedFocusedStageLeak FAILED junit.framework.AssertionFailedError: Expected: but was: javafx.stage.Stage at 22ff86f5 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertNull(Assert.java:233) at junit.framework.Assert.assertNull(Assert.java:226) at test.javafx.stage.FocusedWindowTestBase.assertCollectable(FocusedWindowTestBase.java:101) at test.javafx.stage.FocusedWindowTestBase.testClosedFocusedStageLeakBase(FocusedWindowTestBase.java:85) at test.javafx.stage.FocusedWindowMonocleTest.testClosedFocusedStageLeak(FocusedWindowMonocleTest.java:47) Can you update your PR to ignore this test with `@Ignore("JDK-nnnnnnn")` using the newly filed "REDO" bug as the bug ID? ------------- PR: https://git.openjdk.java.net/jfx/pull/322 From kcr at openjdk.java.net Sat Oct 17 13:13:08 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 17 Oct 2020 13:13:08 GMT Subject: RFR: 8244297: memory leak test utility [v6] In-Reply-To: <6ckTsBx3CRWv0855pSFN5pE1z9OqmmZhR4MjH2oc7Fs=.ada59fd2-8fd9-434e-8ebb-693ab236051c@github.com> References: <4Yzd4sm7fdBWVb6_5DOrIsJRTcsof6fxgrKiYQOf_iA=.b291ffa5-f876-4a8c-a5bb-736fd8c2b14d@github.com> <6ckTsBx3CRWv0855pSFN5pE1z9OqmmZhR4MjH2oc7Fs=.ada59fd2-8fd9-434e-8ebb-693ab236051c@github.com> Message-ID: On Fri, 16 Oct 2020 14:08:53 GMT, Florian Kirmaier wrote: >> modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 84: >> >>> 82: >>> 83: /** >>> 84: * Checks whether the content of the WeakReference can be collected. >> >> -> Checks whether the content of the WeakReference **is** collected. > > That's not true. At the moment of method-call, the variable might not be collected. > It doesen't check whether it's collected, it checks whether it is "collectable". Agreed that "can be collected" is technically more accurate (meaning that "collectable" is a reasonable choice for the name). Once an object is weakly reachable all `WeakReference`s are cleared and the object can be finalized. The actual finalization might happen later. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From kcr at openjdk.java.net Sat Oct 17 14:07:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 17 Oct 2020 14:07:17 GMT Subject: RFR: 8244297: memory leak test utility [v6] In-Reply-To: References: Message-ID: On Sat, 3 Oct 2020 16:00:48 GMT, Florian Kirmaier wrote: >> It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 >> >> I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. >> >> It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. >> I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very >> stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but >> the tests with JMemoryBuddy are basically always correct. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8244297 > Fixed unit-test This is looking quite good now. I really like how it simplifies the tests that you modified to use it. I'll run the tests next week after you update the PR. > I don't plan to confirm all coding guidelines of the JFX-project inside of JMemoryBuddy. Which ones in particular? I would think that the white space guidelines should be easy to adopt, although since this is a "downstream" implementation, we can relax this a bit. The only spacing issue I see in the code that really stands out to me is the missing space after conditional and loop operators (a favorite saying of mine is that "`if` is not a method"). I note that while different coding style guides vary on many points, all of the ones I have looked at recommend a space separating these operators from the opening paren. Do you think it would cause you problems to adopt this in the upstream code? I'm not really concerned about the naming of non-public variables: as long as the existing names aren't confusing (which I don't think they are), you can take our suggestions as just that -- suggestions that you can adopt or not. modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 42: > 40: > 41: /** > 42: * Checkout https://github.com/Sandec/JMemoryBuddy for more > documentation. Can you add 1 or 2 sentences before this pointer describing (at a high level) the purpose of this class? modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 235: > 233: } > 234: > 235: public static interface MemoryTestAPI { Can you add a (short) class javadoc comment? One thing to document is how and whether users of the API should implement it. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From kcr at openjdk.java.net Sat Oct 17 14:07:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 17 Oct 2020 14:07:18 GMT Subject: RFR: 8244297: memory leak test utility [v6] In-Reply-To: References: Message-ID: <2xCEe181jfxbaEklJwb--wYgDUdn559gj6hjDmCssPQ=.a7f9a260-a8f7-45d5-986d-32181f6e9313@github.com> On Sat, 17 Oct 2020 14:02:39 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8244297 >> Fixed unit-test > > This is looking quite good now. I really like how it simplifies the tests that you modified to use it. I'll run the > tests next week after you update the PR. >> I don't plan to confirm all coding guidelines of the JFX-project inside of JMemoryBuddy. > > Which ones in particular? I would think that the white space guidelines should be easy to adopt, although since this is > a "downstream" implementation, we can relax this a bit. The only spacing issue I see in the code that really stands out > to me is the missing space after conditional and loop operators (a favorite saying of mine is that "`if` is not a > method"). I note that while different coding style guides vary on many points, all of the ones I have looked at > recommend a space separating these operators from the opening paren. Do you think it would cause you problems to adopt > this in the upstream code? I'm not really concerned about the naming of non-public variables: as long as the existing > names aren't confusing (which I don't think they are), you can take our suggestions as just that -- suggestions that > you can adopt or not. One more thing: I don't know if you noticed this from the Skara bot: > JDK-8244297: Provide utility for testing for memory leaks ?? Title mismatch between PR and JBS. You will need to update the PR title to match the JBS issue title. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From kcr at openjdk.java.net Sat Oct 17 14:07:19 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 17 Oct 2020 14:07:19 GMT Subject: RFR: 8244297: memory leak test utility [v6] In-Reply-To: <4Yzd4sm7fdBWVb6_5DOrIsJRTcsof6fxgrKiYQOf_iA=.b291ffa5-f876-4a8c-a5bb-736fd8c2b14d@github.com> References: <4Yzd4sm7fdBWVb6_5DOrIsJRTcsof6fxgrKiYQOf_iA=.b291ffa5-f876-4a8c-a5bb-736fd8c2b14d@github.com> Message-ID: On Thu, 8 Oct 2020 06:46:21 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8244297 >> Fixed unit-test > > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 52: > >> 50: private static int garbageAmount = 999999; >> 51: private static String MX_BEAN_PROXY_TYPE = "com.sun.management:type=HotSpotDiagnostic"; >> 52: private static String outputFolderString = "."; > > I am not sure of the directory that we use to save any runtime artifacts, but there must be one common directory that > we should use here also. As long as this is somewhere under the `build/` dir of the project in question, it is OK. If not, then the default needs to be change. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From kevin.rushforth at oracle.com Sat Oct 17 14:21:13 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 17 Oct 2020 07:21:13 -0700 Subject: Default value of Spinner editable property In-Reply-To: References: Message-ID: <93becccc-cbf8-31b5-7e17-7487422f2c40@oracle.com> Yes, this looks like a bug. Would you mind filing it? We could add an "@defaultValue false" to the property docs as well. The class docs do indicate false (as you noted), but the property docs are silent on the default value. It looks like the only reason it hasn't caused problems for us is that the Spinner constructor calls editableProperty() which initializes the editable field (so the incorrect default value is not used). Still, it would be good to fix this, since it is a bug waiting to happen if that initialization were to ever change. -- Kevin On 10/16/2020 5:06 AM, Nir Lisker wrote: > I noticed now that the class docs specify that the default is false. > Should isEditable() be changed to return false on a null property? > > On Fri, Oct 16, 2020 at 2:59 PM Nir Lisker wrote: > >> Hi, >> >> Spinner's editable property seems to have conflicting initial values. >> isEditable() returns true on an uninitialized property, but initializing it >> sets its default to false: >> >> private BooleanProperty editable; >> public final void setEditable(boolean value) { >> editableProperty().set(value); >> } >> public final boolean isEditable() { >> return editable == null ? true : editable.get(); // <---- true >> } >> public final BooleanProperty editableProperty() { >> if (editable == null) { >> editable = new SimpleBooleanProperty(this, "editable", false); >> // <---- false >> } >> return editable; >> } >> >> Seeme like a bug. What is the correct default? >> >> - Nir >> From jvos at openjdk.java.net Sat Oct 17 17:42:22 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 17 Oct 2020 17:42:22 GMT Subject: RFR: 8254605: repaint on Android broken [v2] In-Reply-To: <7hzb7Bje_JwY6C3N65xC3BCIRj1A0tA9chJiPLw35dI=.8fc69226-8be3-4a06-a577-cb8fd4ae4260@github.com> References: <7hzb7Bje_JwY6C3N65xC3BCIRj1A0tA9chJiPLw35dI=.8fc69226-8be3-4a06-a577-cb8fd4ae4260@github.com> Message-ID: > Don't check on windows visiblity when requesting focus. > For a new window, the call to requestFocus is done before the visibility is set to true. > Fix for JDK-8254605 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Process review comments: Ignore test and link to REDO issue ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/322/files - new: https://git.openjdk.java.net/jfx/pull/322/files/45e983aa..de562c17 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=322&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=322&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/322.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/322/head:pull/322 PR: https://git.openjdk.java.net/jfx/pull/322 From nlisker at gmail.com Sun Oct 18 11:34:49 2020 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 18 Oct 2020 14:34:49 +0300 Subject: Default value of Spinner editable property In-Reply-To: <93becccc-cbf8-31b5-7e17-7487422f2c40@oracle.com> References: <93becccc-cbf8-31b5-7e17-7487422f2c40@oracle.com> Message-ID: I created https://github.com/openjdk/jfx/pull/323. On Sat, Oct 17, 2020 at 5:21 PM Kevin Rushforth wrote: > Yes, this looks like a bug. Would you mind filing it? We could add an > "@defaultValue false" to the property docs as well. The class docs do > indicate false (as you noted), but the property docs are silent on the > default value. > > It looks like the only reason it hasn't caused problems for us is that > the Spinner constructor calls editableProperty() which initializes the > editable field (so the incorrect default value is not used). Still, it > would be good to fix this, since it is a bug waiting to happen if that > initialization were to ever change. > > -- Kevin > > > On 10/16/2020 5:06 AM, Nir Lisker wrote: > > I noticed now that the class docs specify that the default is false. > > Should isEditable() be changed to return false on a null property? > > > > On Fri, Oct 16, 2020 at 2:59 PM Nir Lisker wrote: > > > >> Hi, > >> > >> Spinner's editable property seems to have conflicting initial values. > >> isEditable() returns true on an uninitialized property, but > initializing it > >> sets its default to false: > >> > >> private BooleanProperty editable; > >> public final void setEditable(boolean value) { > >> editableProperty().set(value); > >> } > >> public final boolean isEditable() { > >> return editable == null ? true : editable.get(); // <---- true > >> } > >> public final BooleanProperty editableProperty() { > >> if (editable == null) { > >> editable = new SimpleBooleanProperty(this, "editable", > false); > >> // <---- false > >> } > >> return editable; > >> } > >> > >> Seeme like a bug. What is the correct default? > >> > >> - Nir > >> > > From nlisker at openjdk.java.net Sun Oct 18 11:35:14 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 18 Oct 2020 11:35:14 GMT Subject: RFR: 8254964: Fix default values in Spinner class Message-ID: Added 2 `@defaultValue` and fixed the incorrect default for `editable`. Also corrected a typo that doesn't show anyway in the docs. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jfx/pull/323/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=323&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254964 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/323.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/323/head:pull/323 PR: https://git.openjdk.java.net/jfx/pull/323 From abhinay_agarwal at live.com Mon Oct 19 06:49:20 2020 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Mon, 19 Oct 2020 06:49:20 +0000 Subject: Move EventHandlerManager to public API Message-ID: Hi, Classes which extends Node have access to the protected method `setEventHandler`[1]. It makes it exceptional easy to register a user-defined onXXX event handler. However, for custom EventTarget which do not extend Node, it becomes cumbersome as JavaFX expects us to create a whole new EventDispatcher to register custom event handlers/filters on these targets. JavaFX already has a number of implementation for EventDispatcher in the `com.sun` package. The most basic of which are BasicEventDispatcher and EventHandlerManager. The later seems to have all the necessary public methods to make it easier to create new EventTargets. Unless there is a good reason which I am missing, JavaFX should provide a basic implementation of EventDispatcher to make it easier for developers to create custom EventTarget. FYR, ControlsFX has 3 classes which implement EventTarget directly: 1. AutoCompletionBinding [2] 2. GridBase [3] 3. SpreadsheetCellBase [4] Regards, Abhinay [1] https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/Node.java#L8776 [2] https://github.com/controlsfx/controlsfx/blob/jfx-13/controlsfx/src/main/java/org/controlsfx/control/textfield/AutoCompletionBinding.java [3] https://github.com/controlsfx/controlsfx/blob/jfx-13/controlsfx/src/main/java/org/controlsfx/control/spreadsheet/GridBase.java [4] https://github.com/controlsfx/controlsfx/blob/jfx-13/controlsfx/src/main/java/org/controlsfx/control/spreadsheet/SpreadsheetCellBase.java From andrea.vacondio at gmail.com Mon Oct 19 08:11:35 2020 From: andrea.vacondio at gmail.com (Andrea Vacondio) Date: Mon, 19 Oct 2020 10:11:35 +0200 Subject: Case insensitive ExtensionFilter Message-ID: Hi, I would like to suggest to add a way to make an ExtenstionFilter case insensitive. On Linux systems, which are case sensitive, the filter is also case sensitive but if I'm creating a *.something filter, I'm likely referring to any case combination (something, SOMETHING, SoMenThing etc). I know I can add all possible combinations to the extensions list but that's quite cumbersome. As an example the Swing provided javax.swing.filechooser.FileNameExtensionFilter is case insensitive. Thanks Andrea From kcr at openjdk.java.net Mon Oct 19 13:08:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 19 Oct 2020 13:08:18 GMT Subject: RFR: 8254605: repaint on Android broken [v2] In-Reply-To: References: <7hzb7Bje_JwY6C3N65xC3BCIRj1A0tA9chJiPLw35dI=.8fc69226-8be3-4a06-a577-cb8fd4ae4260@github.com> Message-ID: On Sat, 17 Oct 2020 17:42:22 GMT, Johan Vos wrote: >> Don't check on windows visiblity when requesting focus. >> For a new window, the call to requestFocus is done before the visibility is set to true. >> Fix for JDK-8254605 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Process review comments: > Ignore test and link to REDO issue Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/322 From ajoseph at openjdk.java.net Mon Oct 19 17:32:14 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 19 Oct 2020 17:32:14 GMT Subject: RFR: 8254049: Update WebView to public suffix list 2020-04-24 Message-ID: We should use the public_suffix_list.dat file in the JDK instead. Reading the public_suffix_list.dat file is modified to be similar to [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). If the file is not present, `isPublicSuffix()` returns `false`, which is similar to how WebKit ignores the public suffix check when it is disabled. Test: Run PublicSuffixesTest.java ------------- Commit messages: - 8254049: Update WebView to public suffix list 2020-04-24 Changes: https://git.openjdk.java.net/jfx/pull/324/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=324&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254049 Stats: 5325 lines in 3 files changed: 55 ins; 5216 del; 54 mod Patch: https://git.openjdk.java.net/jfx/pull/324.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/324/head:pull/324 PR: https://git.openjdk.java.net/jfx/pull/324 From ajoseph at openjdk.java.net Mon Oct 19 17:32:16 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 19 Oct 2020 17:32:16 GMT Subject: RFR: 8254049: Update WebView to public suffix list 2020-04-24 In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 04:29:13 GMT, Arun Joseph wrote: > We should use the public_suffix_list.dat file in the JDK instead. Reading the public_suffix_list.dat file is modified > to be similar to > [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). > If the file is not present, `isPublicSuffix()` returns `false`, which is similar to how WebKit ignores the public > suffix check when it is disabled. Test: Run PublicSuffixesTest.java modules/javafx.web/src/test/java/test/com/sun/webkit/network/PublicSuffixesTest.java line 72: > 70: @Test > 71: public void testWildcardRule() { > 72: test("mm", true); Had to modify the test as the rule for `*.ar` domain changed. ------------- PR: https://git.openjdk.java.net/jfx/pull/324 From arapte at openjdk.java.net Mon Oct 19 17:56:15 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 19 Oct 2020 17:56:15 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v16] In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 16:33:28 GMT, Nir Lisker wrote: >> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test Looks good to me. There seems to be an existing issue with PointLight. It is reported here [JDK-8255015](https://bugs.openjdk.java.net/browse/JDK-8255015) ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Mon Oct 19 17:59:20 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 19 Oct 2020 17:59:20 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v16] In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 18:11:14 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed test > > tests/performance/3DLighting/attenuation/LightingSample.java line 62: > >> 60: environment.setStyle("-fx-background-color: teal"); >> 61: >> 62: var subdivisionSlider = new Slider(10, 200, 60); > > I might recommend setting the max value of the slider to something like 1000, since even on a slow system, it runs > quite nicely at that tessellation. I forgot to reply to this and the other comment. Since we're going to implement more light types, this small test app is going to be updated anyway, so I will change the values then. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Mon Oct 19 18:06:22 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 19 Oct 2020 18:06:22 GMT Subject: Integrated: 8217472: Add attenuation for PointLight In-Reply-To: References: Message-ID: On Sun, 17 Nov 2019 04:15:34 GMT, Nir Lisker wrote: > CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 This pull request has now been integrated. Changeset: aab26d93 Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/aab26d93 Stats: 1223 lines in 33 files changed: 1115 ins; 13 del; 95 mod 8217472: Add attenuation for PointLight Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From arapte at openjdk.java.net Mon Oct 19 18:29:15 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 19 Oct 2020 18:29:15 GMT Subject: RFR: 8254605: repaint on Android broken [v2] In-Reply-To: References: <7hzb7Bje_JwY6C3N65xC3BCIRj1A0tA9chJiPLw35dI=.8fc69226-8be3-4a06-a577-cb8fd4ae4260@github.com> Message-ID: <43FrinhVkaKg8hqaxNruPVHKliQh4SOdyqgFzLeiI7U=.26f8a1d3-c601-41d2-a306-5c935c703f07@github.com> On Mon, 19 Oct 2020 13:05:50 GMT, Kevin Rushforth wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Process review comments: >> Ignore test and link to REDO issue > > Marked as reviewed by kcr (Lead). Reverting #153 seems right, I don't have any specific comments. Please go ahead and merge the change. ------------- PR: https://git.openjdk.java.net/jfx/pull/322 From jvos at openjdk.java.net Mon Oct 19 18:43:07 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 19 Oct 2020 18:43:07 GMT Subject: Integrated: 8254605: repaint on Android broken In-Reply-To: <7hzb7Bje_JwY6C3N65xC3BCIRj1A0tA9chJiPLw35dI=.8fc69226-8be3-4a06-a577-cb8fd4ae4260@github.com> References: <7hzb7Bje_JwY6C3N65xC3BCIRj1A0tA9chJiPLw35dI=.8fc69226-8be3-4a06-a577-cb8fd4ae4260@github.com> Message-ID: On Fri, 16 Oct 2020 10:39:09 GMT, Johan Vos wrote: > Don't check on windows visiblity when requesting focus. > For a new window, the call to requestFocus is done before the visibility is set to true. > Fix for JDK-8254605 This pull request has now been integrated. Changeset: 01ba6e1e Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/01ba6e1e Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod 8254605: repaint on Android broken Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/322 From jvos at openjdk.java.net Tue Oct 20 08:18:15 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 20 Oct 2020 08:18:15 GMT Subject: [jfx15] RFR: 8255042: Change JavaFX release version in jfx15 branch to 15.0.1 Message-ID: <3Q90s0crDvKrJvorlBzf7Jx134fY5qTtMhlXjQwfvWk=.e76e2a1f-a7f7-4196-b3c9-da22cfc9cc4b@github.com> Increase release version to 15.0.1 Fix for JDK-8255042 ------------- Commit messages: - Increase release version to 15.0.1 Changes: https://git.openjdk.java.net/jfx/pull/325/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=325&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255042 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/325.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/325/head:pull/325 PR: https://git.openjdk.java.net/jfx/pull/325 From fkirmaier at openjdk.java.net Tue Oct 20 09:27:08 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 20 Oct 2020 09:27:08 GMT Subject: RFR: 8254605: repaint on Android broken [v2] In-Reply-To: <43FrinhVkaKg8hqaxNruPVHKliQh4SOdyqgFzLeiI7U=.26f8a1d3-c601-41d2-a306-5c935c703f07@github.com> References: <7hzb7Bje_JwY6C3N65xC3BCIRj1A0tA9chJiPLw35dI=.8fc69226-8be3-4a06-a577-cb8fd4ae4260@github.com> <43FrinhVkaKg8hqaxNruPVHKliQh4SOdyqgFzLeiI7U=.26f8a1d3-c601-41d2-a306-5c935c703f07@github.com> Message-ID: On Mon, 19 Oct 2020 18:26:43 GMT, Ambarish Rapte wrote: >> Marked as reviewed by kcr (Lead). > > Reverting #153 seems right, I don't have any specific comments. Please go ahead and merge the change. @johanvos @jperedadnr A unit-test would be great, otherwise, it would be very hard to fix the memory-leak again. Is this reproducible outside of the android setup, when calling repaintFromNative explicitly? Imo the importance of the memoryleak-fix is a bit underestimated because it's a requirement to test for correct memory-behavior. The only reason reverting it doesn't break all kinds of tests is that no one is testing for memory leaks. ------------- PR: https://git.openjdk.java.net/jfx/pull/322 From perini.davide at dpsoftware.org Tue Oct 20 10:28:08 2020 From: perini.davide at dpsoftware.org (Davide Perini) Date: Tue, 20 Oct 2020 12:28:08 +0200 Subject: Can't load fxml on Macos Message-ID: <3c9e3105-932d-12ce-b003-2dc6d6fa01e8@dpsoftware.org> Hi all, this code works well on both Windows and Linux running Java 15 on JavaFX 15. FXMLLoader fxmlLoader =new FXMLLoader(GUIManager.class.getResource( fxml + Constants.FXML)); return fxmlLoader.load(); It doesn't work on Macos returning a nullpointer exception. Any idea? Why Macos is always the black sheep? Thanks Davide From kcr at openjdk.java.net Tue Oct 20 12:20:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 20 Oct 2020 12:20:14 GMT Subject: [jfx15] RFR: 8255042: Change JavaFX release version in jfx15 branch to 15.0.1 In-Reply-To: <3Q90s0crDvKrJvorlBzf7Jx134fY5qTtMhlXjQwfvWk=.e76e2a1f-a7f7-4196-b3c9-da22cfc9cc4b@github.com> References: <3Q90s0crDvKrJvorlBzf7Jx134fY5qTtMhlXjQwfvWk=.e76e2a1f-a7f7-4196-b3c9-da22cfc9cc4b@github.com> Message-ID: On Tue, 20 Oct 2020 08:12:41 GMT, Johan Vos wrote: > Increase release version to 15.0.1 > Fix for JDK-8255042 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/325 From aghaisas at openjdk.java.net Tue Oct 20 12:24:24 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 20 Oct 2020 12:24:24 GMT Subject: RFR: 8255002: Many javafx.controls unit tests have incorrect name containing impl_* Message-ID: It is a test cleanup work. Issue : Many unit tests in javafx.controls module have incorrect naming that use text "impl_" in names and comments. The test code correctly avoids using impl_* methods (as they were removed in JDK 9), but test names still have "impl_" in them. Fix : These tests are renamed by replacing impl_* with appropriate css method. ------------- Commit messages: - JDK-8255002 - rename tests Changes: https://git.openjdk.java.net/jfx/pull/326/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=326&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255002 Stats: 139 lines in 20 files changed: 0 ins; 0 del; 139 mod Patch: https://git.openjdk.java.net/jfx/pull/326.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/326/head:pull/326 PR: https://git.openjdk.java.net/jfx/pull/326 From tom.schindl at bestsolution.at Tue Oct 20 12:31:00 2020 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 20 Oct 2020 14:31:00 +0200 Subject: Can't load fxml on Macos In-Reply-To: <3c9e3105-932d-12ce-b003-2dc6d6fa01e8@dpsoftware.org> References: <3c9e3105-932d-12ce-b003-2dc6d6fa01e8@dpsoftware.org> Message-ID: Well, you don't give a enough information (no stacktrace, no context, ...). If you have reproducable code please share it (with the current information provided I highly doubt this is an issue in Java/JavaFX). Tom Am 20.10.20 um 12:28 schrieb Davide Perini: > Hi all, > this code works well on both Windows and Linux running Java 15 on JavaFX > 15. > > FXMLLoader fxmlLoader =new FXMLLoader(GUIManager.class.getResource( fxml > + Constants.FXML)); return fxmlLoader.load(); > > > It doesn't work on Macos returning a nullpointer exception. > > Any idea? Why Macos is always the black sheep? > > Thanks > Davide From jvos at openjdk.java.net Tue Oct 20 12:50:07 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 20 Oct 2020 12:50:07 GMT Subject: [jfx15] Integrated: 8255042: Change JavaFX release version in jfx15 branch to 15.0.1 In-Reply-To: <3Q90s0crDvKrJvorlBzf7Jx134fY5qTtMhlXjQwfvWk=.e76e2a1f-a7f7-4196-b3c9-da22cfc9cc4b@github.com> References: <3Q90s0crDvKrJvorlBzf7Jx134fY5qTtMhlXjQwfvWk=.e76e2a1f-a7f7-4196-b3c9-da22cfc9cc4b@github.com> Message-ID: On Tue, 20 Oct 2020 08:12:41 GMT, Johan Vos wrote: > Increase release version to 15.0.1 > Fix for JDK-8255042 This pull request has now been integrated. Changeset: 86ff5dea Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/86ff5dea Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8255042: Change JavaFX release version in jfx15 branch to 15.0.1 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/325 From dlemmermann at gmail.com Tue Oct 20 13:54:09 2020 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Tue, 20 Oct 2020 15:54:09 +0200 Subject: Can't load fxml on Macos In-Reply-To: <3c9e3105-932d-12ce-b003-2dc6d6fa01e8@dpsoftware.org> References: <3c9e3105-932d-12ce-b003-2dc6d6fa01e8@dpsoftware.org> Message-ID: I worked with JavaFX on MacOS since 2013 and except for issues related to font rendering I never got the impression that MacOS is the black sheep. I also happen to know that many of the developers that are working on JavaFX use MacOS. Dirk > On Oct 20, 2020, at 12:28 PM, Davide Perini wrote: > > Hi all, > this code works well on both Windows and Linux running Java 15 on JavaFX 15. > > FXMLLoader fxmlLoader =new FXMLLoader(GUIManager.class.getResource( fxml + Constants.FXML)); return fxmlLoader.load(); > > > It doesn't work on Macos returning a nullpointer exception. > > Any idea? Why Macos is always the black sheep? > > Thanks > Davide From perini.davide at dpsoftware.org Tue Oct 20 13:56:52 2020 From: perini.davide at dpsoftware.org (Davide Perini) Date: Tue, 20 Oct 2020 15:56:52 +0200 Subject: Can't load fxml on Macos In-Reply-To: References: <3c9e3105-932d-12ce-b003-2dc6d6fa01e8@dpsoftware.org> Message-ID: I'm creating my binary file using JPackage but I don't signed the binary. can this be the problem. why a simple line like this FXMLLoader fxmlLoader =new FXMLLoader(GUIManager.class.getResource( fxml + Constants.FXML)); return null if it works on WIndows and Linux? Thanks Davide Il 20/10/2020 15:54, Dirk Lemmermann ha scritto: > I worked with JavaFX on MacOS since 2013 and except for issues related to font rendering I never got the impression that MacOS is the black sheep. I also happen to know that many of the developers that are working on JavaFX use MacOS. > > Dirk > >> On Oct 20, 2020, at 12:28 PM, Davide Perini wrote: >> >> Hi all, >> this code works well on both Windows and Linux running Java 15 on JavaFX 15. >> >> FXMLLoader fxmlLoader =new FXMLLoader(GUIManager.class.getResource( fxml + Constants.FXML)); return fxmlLoader.load(); >> >> >> It doesn't work on Macos returning a nullpointer exception. >> >> Any idea? Why Macos is always the black sheep? >> >> Thanks >> Davide From mik3hall at gmail.com Tue Oct 20 14:07:13 2020 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 20 Oct 2020 09:07:13 -0500 Subject: Can't load fxml on Macos In-Reply-To: References: <3c9e3105-932d-12ce-b003-2dc6d6fa01e8@dpsoftware.org> Message-ID: > On Oct 20, 2020, at 8:56 AM, Davide Perini wrote: > > GUIManager.class.getResource Not finding it? Not sure why that would be different OS X though. Recently moved a (non-jfx) project to Eclipse and had to change class.getResourceAsStream to ClassLoader.getResourceAsStream. Because couldn?t figure out how to bundle the resource with the packaged class in Eclipse. Are the jars the same? If you jar -tvf is the resource where you expect to find it? From kevin.rushforth at oracle.com Tue Oct 20 16:05:41 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 20 Oct 2020 09:05:41 -0700 Subject: RFR: Request to sync October 2020 CPU changes into jfx Message-ID: Johan and Ambarish, I request approval to sync changes from to the just-released October 2020 CPU release into the 'master' branch of the 'jfx' repo. Here is the aggregate set of changes for the fixes: https://github.com/kevinrushforth/jfx/compare/01ba6e1e41...cpu-2010-sync NOTE: Since this is an integration of already-reviewed fixes into the master branch of the jfx repo, I will push it directly rather than via a pull request. -- Kevin From johan.vos at gluonhq.com Tue Oct 20 16:19:10 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 20 Oct 2020 18:19:10 +0200 Subject: RFR: Request to sync October 2020 CPU changes into jfx In-Reply-To: References: Message-ID: Approved. On Tue, Oct 20, 2020 at 6:07 PM Kevin Rushforth wrote: > Johan and Ambarish, > > I request approval to sync changes from to the just-released October > 2020 CPU release into the 'master' branch of the 'jfx' repo. Here is the > aggregate set of changes for the fixes: > > https://github.com/kevinrushforth/jfx/compare/01ba6e1e41...cpu-2010-sync > > NOTE: Since this is an integration of already-reviewed fixes into the > master branch of the jfx repo, I will push it directly rather than via a > pull request. > > -- Kevin > > From kevin.rushforth at oracle.com Tue Oct 20 16:44:37 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 20 Oct 2020 09:44:37 -0700 Subject: [11][15] RFR: Request to backport October 2020 CPU changes Message-ID: <29d0fb14-e4d6-e8a9-8fb3-94d4305b0190@oracle.com> Hi Johan, I request approval to backport the changes from the just-released October 2020 CPU to 11-dev (for 11.0.9) and the jfx15 branch of jfx (for 15.0.1). https://cr.openjdk.java.net/~kcr/cpu-2010-sync/11-dev/webrev/ https://github.com/kevinrushforth/jfx/compare/4b75750...15-cpu-2010-sync Each is a straight backport (patch applies cleanly) of the one FX fix that went into the October CPU. NOTE: For the 15.0.1 backport, since this is an integration of already-reviewed fixes into the jfx repo, I will push it directly into the jfx15 branch rather than via a pull request. The 11.0.9 backport will be pushed to the HG 11-dev repo. Thanks. -- Kevin From ambarish.rapte at oracle.com Tue Oct 20 17:14:28 2020 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Tue, 20 Oct 2020 10:14:28 -0700 (PDT) Subject: RFR: Request to sync October 2020 CPU changes into jfx In-Reply-To: References: Message-ID: <46a1b0d5-5d7a-44b2-8c23-a27c9cb62a08@default> Looks good to me, +1. -----Original Message----- From: Kevin Rushforth Sent: Tuesday, October 20, 2020 9:36 PM To: Johan Vos ; Ambarish Rapte ; openjfx-dev at openjdk.java.net Subject: RFR: Request to sync October 2020 CPU changes into jfx Johan and Ambarish, I request approval to sync changes from to the just-released October 2020 CPU release into the 'master' branch of the 'jfx' repo. Here is the aggregate set of changes for the fixes: https://github.com/kevinrushforth/jfx/compare/01ba6e1e41...cpu-2010-sync NOTE: Since this is an integration of already-reviewed fixes into the master branch of the jfx repo, I will push it directly rather than via a pull request. -- Kevin From johan.vos at gluonhq.com Tue Oct 20 17:20:20 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 20 Oct 2020 19:20:20 +0200 Subject: [11][15] RFR: Request to backport October 2020 CPU changes In-Reply-To: <29d0fb14-e4d6-e8a9-8fb3-94d4305b0190@oracle.com> References: <29d0fb14-e4d6-e8a9-8fb3-94d4305b0190@oracle.com> Message-ID: Approved. On Tue, Oct 20, 2020 at 6:46 PM Kevin Rushforth wrote: > Hi Johan, > > I request approval to backport the changes from the just-released > October 2020 CPU to 11-dev (for 11.0.9) and the jfx15 branch of jfx (for > 15.0.1). > > https://cr.openjdk.java.net/~kcr/cpu-2010-sync/11-dev/webrev/ > https://github.com/kevinrushforth/jfx/compare/4b75750...15-cpu-2010-sync > > Each is a straight backport (patch applies cleanly) of the one FX fix > that went into the October CPU. > > NOTE: For the 15.0.1 backport, since this is an integration of > already-reviewed fixes into the jfx repo, I will push it directly into > the jfx15 branch rather than via a pull request. The 11.0.9 backport > will be pushed to the HG 11-dev repo. > > Thanks. > > -- Kevin > > From kcr at openjdk.java.net Tue Oct 20 21:44:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 20 Oct 2020 21:44:11 GMT Subject: RFR: 8254964: Fix default values in Spinner class In-Reply-To: References: Message-ID: On Sun, 18 Oct 2020 11:30:47 GMT, Nir Lisker wrote: > Added 2 `@defaultValue` and fixed the incorrect default for `editable`. Also corrected a typo that doesn't show anyway > in the docs. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/323 From nlisker at openjdk.java.net Tue Oct 20 22:14:09 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 20 Oct 2020 22:14:09 GMT Subject: Integrated: 8254964: Fix default values in Spinner class In-Reply-To: References: Message-ID: On Sun, 18 Oct 2020 11:30:47 GMT, Nir Lisker wrote: > Added 2 `@defaultValue` and fixed the incorrect default for `editable`. Also corrected a typo that doesn't show anyway > in the docs. This pull request has now been integrated. Changeset: a3699381 Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/a3699381 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod 8254964: Fix default values in Spinner class Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/323 From fthevenet at openjdk.java.net Wed Oct 21 07:04:06 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 21 Oct 2020 07:04:06 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> Message-ID: On Fri, 25 Sep 2020 09:32:46 GMT, Frederic Thevenet wrote: >> The visual representation corresponds with digits, so there can be tests that check if the numbers are what we expect >> them to be. It's good that this is not windows-only, so that it can be tackled on linux as well. But what is not clear >> to me: does this require a physical HiDPI screen, or is setting the scale factor manually good enough to reproduce the >> bug? > >> >> >> The visual representation corresponds with digits, so there can be tests that check if the numbers are what we expect >> them to be. It's good that this is not windows-only, so that it can be tackled on linux as well. But what is not clear >> to me: does this require a physical HiDPI screen, or is setting the scale factor manually good enough to reproduce the >> bug? > > The issue will appear consistently as long as the conditions I listed are met, regardless of the actual number of > pixels the physical screen can display. For instance you'll see the problem, if you apply a 125% scaling on 1080p > screen (a common configuration on 13'' laptops). Also, it will occur regardless of whether the scaling is applied at > the OS level and picked up by javafx or if it is only set for a single application using the `glass.xxx.uiScale` > property. Hello, Did anyone get a chance to look into this? Thanks! ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From mp at jugs.org Tue Oct 20 12:12:48 2020 From: mp at jugs.org (Michael Paus) Date: Tue, 20 Oct 2020 14:12:48 +0200 Subject: Can't load fxml on Macos In-Reply-To: <3c9e3105-932d-12ce-b003-2dc6d6fa01e8@dpsoftware.org> References: <3c9e3105-932d-12ce-b003-2dc6d6fa01e8@dpsoftware.org> Message-ID: With so little information nobody will be able to answer your question and I am pretty sure that not macOS is the black sheep here. Such questions are also better posted on Stackoverflow and not here on the OpenJFX development mailing list. Michael Am 20.10.20 um 12:28 schrieb Davide Perini: > Hi all, > this code works well on both Windows and Linux running Java 15 on > JavaFX 15. > > FXMLLoader fxmlLoader =new FXMLLoader(GUIManager.class.getResource( > fxml + Constants.FXML)); return fxmlLoader.load(); > > > It doesn't work on Macos returning a nullpointer exception. > > Any idea? Why Macos is always the black sheep? > > Thanks > Davide From arapte at openjdk.java.net Wed Oct 21 10:08:51 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 21 Oct 2020 10:08:51 GMT Subject: RFR: 8255002: Many javafx.controls unit tests have incorrect name containing impl_* In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 12:18:10 GMT, Ajit Ghaisas wrote: > It is a test cleanup work. > > Issue : > Many unit tests in javafx.controls module have incorrect naming that use text "impl_" in names and comments. > The test code correctly avoids using impl_* methods (as they were removed in JDK 9), but test names still have "impl_" in them. > > Fix : > These tests are renamed by replacing impl_* with appropriate css method. I found two other instances where impl_ methods are referred. 1. A comment in file:MiscellaneousTests.java Line#65, refers to `Scene#impl_initPeer()`. I think now it should `Scene#initPeer()`. 2. A commented test in File VirtualFlowTest.java Line#852 refers to `cell.impl_getCSSFlags()`. All the instances are commented. Please take a look if these were missed. I don't have any preference on handling these, so I leave it to you. modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlTest.java line 73: > 71: * - (2nd order) CssMetaData_isSettable returns true for thing in their default state > 72: * - (2nd order) CssMetaData_isSettable returns false for things manually specified > 73: * - (3rd order) impl_cssKeys includes all the public properties I could not find a match for `impl_cssKeys`. Should it be considered in this fix ? either find a match and correct this comment or remove if it does not exist anymore. I don't have strong preference on this, I leave it to you. ------------- PR: https://git.openjdk.java.net/jfx/pull/326 From aghaisas at openjdk.java.net Wed Oct 21 11:54:24 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 21 Oct 2020 11:54:24 GMT Subject: RFR: 8255002: Many javafx.controls unit tests have incorrect name containing impl_* [v2] In-Reply-To: References: Message-ID: > It is a test cleanup work. > > Issue : > Many unit tests in javafx.controls module have incorrect naming that use text "impl_" in names and comments. > The test code correctly avoids using impl_* methods (as they were removed in JDK 9), but test names still have "impl_" in them. > > Fix : > These tests are renamed by replacing impl_* with appropriate css method. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: JDK-8255002 - review fixes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/326/files - new: https://git.openjdk.java.net/jfx/pull/326/files/18c35fa9..9e6849b1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=326&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=326&range=00-01 Stats: 17 lines in 3 files changed: 0 ins; 15 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/326.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/326/head:pull/326 PR: https://git.openjdk.java.net/jfx/pull/326 From aghaisas at openjdk.java.net Wed Oct 21 11:54:25 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 21 Oct 2020 11:54:25 GMT Subject: RFR: 8255002: Many javafx.controls unit tests have incorrect name containing impl_* [v2] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 08:23:25 GMT, Ambarish Rapte wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8255002 - review fixes > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlTest.java line 73: > >> 71: * - (2nd order) CssMetaData_isSettable returns true for thing in their default state >> 72: * - (2nd order) CssMetaData_isSettable returns false for things manually specified >> 73: * - (3rd order) impl_cssKeys includes all the public properties > > I could not find a match for `impl_cssKeys`. Should it be considered in this fix ? either find a match and correct this comment or remove if it does not exist anymore. I don't have strong preference on this, I leave it to you. I was in two minds whether to clean up these 3 commented references to "impl_". Now, I have corrected two commented references where I could find the closest equivalents and deleted the third commented reference. ------------- PR: https://git.openjdk.java.net/jfx/pull/326 From kcr at openjdk.java.net Wed Oct 21 12:38:13 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 21 Oct 2020 12:38:13 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> Message-ID: <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> On Wed, 21 Oct 2020 07:01:46 GMT, Frederic Thevenet wrote: >>> >>> >>> The visual representation corresponds with digits, so there can be tests that check if the numbers are what we expect them to be. >>> It's good that this is not windows-only, so that it can be tackled on linux as well. But what is not clear to me: does this require a physical HiDPI screen, or is setting the scale factor manually good enough to reproduce the bug? >> >> The issue will appear consistently as long as the conditions I listed are met, regardless of the actual number of pixels the physical screen can display. >> For instance you'll see the problem, if you apply a 125% scaling on 1080p screen (a common configuration on 13'' laptops). >> Also, it will occur regardless of whether the scaling is applied at the OS level and picked up by javafx or if it is only set for a single application using the `glass.xxx.uiScale` property. > > Hello, > Did anyone get a chance to look into this? > Thanks! Not yet. I took a quick look, and this is helpful in pointing out where the problem is, but I don't know whether it is the right solution to simply round the transform values when rendering the cache to the screen. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From ajoseph at openjdk.java.net Wed Oct 21 17:34:17 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 21 Oct 2020 17:34:17 GMT Subject: RFR: 8252596: [TESTBUG] WebPageShim::paint is not thread-safe Message-ID: Issue: Tests using `WebPageShim::paint` fails around 1/10 times. Fix: Execute `WebPageShim::paint` in the render thread using `PrismInvoker`. Ran tests over 100 times, no failures. Used the initial unit test in the PR for [JDK-8202990](https://bugs.openjdk.java.net/browse/JDK-8202990). ------------- Commit messages: - 8252596: [TESTBUG] WebPageShim::paint is not thread-safe Changes: https://git.openjdk.java.net/jfx/pull/327/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=327&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252596 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/327.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/327/head:pull/327 PR: https://git.openjdk.java.net/jfx/pull/327 From ebresie at gmail.com Thu Oct 22 01:35:40 2020 From: ebresie at gmail.com (Eric Bresie) Date: Wed, 21 Oct 2020 20:35:40 -0500 Subject: Can't load fxml on Macos In-Reply-To: e38163d1-da61-e59f-5bed-712d7a3e6f44@dpsoftware.org References: 3c9e3105-932d-12ce-b003-2dc6d6fa01e8@dpsoftware.org E137ADF4-337D-47A3-97BA-C2FC5CC37B57@gmail.com E137ADF4-337D-47A3-97BA-C2FC5CC37B57@gmail.com Message-ID: What is fxml set to? Could maybe be a ?classpath? type issue where it?s looking on the classpath and can?t find it. Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) > On October 20, 2020 at 8:56:52 AM CDT, Davide Perini wrote: > I'm creating my binary file using JPackage but I don't signed the binary. > can this be the problem. > > why a simple line like this > > FXMLLoader fxmlLoader =new FXMLLoader(GUIManager.class.getResource( fxml + Constants.FXML)); > > return null if it works on WIndows and Linux? > > Thanks > Davide > > > > > > Il 20/10/2020 15:54, Dirk Lemmermann ha scritto: > > I worked with JavaFX on MacOS since 2013 and except for issues related to font rendering I never got the impression that MacOS is the black sheep. I also happen to know that many of the developers that are working on JavaFX use MacOS. > > > > Dirk > > > > > On Oct 20, 2020, at 12:28 PM, Davide Perini wrote: > > > > > > Hi all, > > > this code works well on both Windows and Linux running Java 15 on JavaFX 15. > > > > > > FXMLLoader fxmlLoader =new FXMLLoader(GUIManager.class.getResource( fxml + Constants.FXML)); return fxmlLoader.load(); > > > > > > > > > It doesn't work on Macos returning a nullpointer exception. > > > > > > Any idea? Why Macos is always the black sheep? > > > > > > Thanks > > > Davide > From arapte at openjdk.java.net Thu Oct 22 06:26:09 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 22 Oct 2020 06:26:09 GMT Subject: RFR: 8255002: Many javafx.controls unit tests have incorrect name containing impl_* [v2] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 11:54:24 GMT, Ajit Ghaisas wrote: >> It is a test cleanup work. >> >> Issue : >> Many unit tests in javafx.controls module have incorrect naming that use text "impl_" in names and comments. >> The test code correctly avoids using impl_* methods (as they were removed in JDK 9), but test names still have "impl_" in them. >> >> Fix : >> These tests are renamed by replacing impl_* with appropriate css method. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8255002 - review fixes Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/326 From aghaisas at openjdk.java.net Thu Oct 22 06:40:08 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 22 Oct 2020 06:40:08 GMT Subject: Integrated: 8255002: Many javafx.controls unit tests have incorrect name containing impl_* In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 12:18:10 GMT, Ajit Ghaisas wrote: > It is a test cleanup work. > > Issue : > Many unit tests in javafx.controls module have incorrect naming that use text "impl_" in names and comments. > The test code correctly avoids using impl_* methods (as they were removed in JDK 9), but test names still have "impl_" in them. > > Fix : > These tests are renamed by replacing impl_* with appropriate css method. This pull request has now been integrated. Changeset: ae1fb61a Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/ae1fb61a Stats: 156 lines in 22 files changed: 0 ins; 15 del; 141 mod 8255002: Many javafx.controls unit tests have incorrect name containing impl_* Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/326 From kcr at openjdk.java.net Thu Oct 22 11:49:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 22 Oct 2020 11:49:17 GMT Subject: RFR: 8254013: gradle test should run all test classes even if they don't end with "Test" Message-ID: The test targets in `build.gradle` are set up to run only classes whose name ends with exactly `Test`. A test class named `RunMyTest.java` will be run, but a test called `CheckSomething.java` will not be. This was done because gradle's built-in scanner for test classes was buggy in earlier versions of gradle. It seems to have been fixed in the gradle 3.x time frame from what I can tell. The current approach leads to two problems. The first is that gradle will try to execute all classes named `XxxxxTest.java` whether or not it should. Attempting to execute utility classes without test methods (meaning without at least one method annotated with `@Test`) or `abstract` classes (whether or not there are any test methods) will fail. The second is that a test class that isn't named `XxxxxTest.java` will not be run, even if it contains `@Test` methods. This can (and has) lead to tests being skipped when they should be run. The solution is to enable gradle's built-in scanning for test classes which works exactly like you would expect it to: it runs any concrete class that has at least one `@Test` method or whose parent class has such a method. This means that a class with no test methods that subclasses an abstract class with `@Test` methods will be run correctly. I ran a full test on all three platforms. The following test classes which were formerly not run are now run: modules/javafx.base: test.javafx.collections.ObservableListWithExtractor : 52 tests modules/javafx.base: test.javafx.event.EventSerializationEventExists 0 tests (*) modules/javafx.controls:. test.javafx.scene.control.MiscellaneousTests : 3 tests tests/system: test.com.sun.javafx.application.SwingNoExit : 1 test They pass on all three platforms. (*) - There is only one test in this class and it is currently `@Ignore`d ------------- Commit messages: - 8254013: gradle test should run all test classes even if they don't end with "Test" Changes: https://git.openjdk.java.net/jfx/pull/329/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=329&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254013 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/329.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/329/head:pull/329 PR: https://git.openjdk.java.net/jfx/pull/329 From arapte at openjdk.java.net Thu Oct 22 11:50:21 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 22 Oct 2020 11:50:21 GMT Subject: RFR: 8254100: FX: Update copyright year in docs, readme files to 2021 Message-ID: Copyright year in these 3 docs needs to be updated to 2021. ------------- Commit messages: - doc copyright 2021 Changes: https://git.openjdk.java.net/jfx/pull/330/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=330&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254100 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/330.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/330/head:pull/330 PR: https://git.openjdk.java.net/jfx/pull/330 From arapte at openjdk.java.net Thu Oct 22 11:50:21 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 22 Oct 2020 11:50:21 GMT Subject: RFR: 8254100: FX: Update copyright year in docs, readme files to 2021 In-Reply-To: References: Message-ID: <6i4mUtdu0l82hboXBK1twMT3vjwqubsQLSbiMIhIVog=.c1e2322a-bf1f-4392-bbf6-c75e91471417@github.com> On Thu, 22 Oct 2020 11:45:23 GMT, Ambarish Rapte wrote: > Copyright year in these 3 docs needs to be updated to 2021. reviewer: @kevinrushforth ------------- PR: https://git.openjdk.java.net/jfx/pull/330 From kcr at openjdk.java.net Thu Oct 22 11:59:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 22 Oct 2020 11:59:14 GMT Subject: RFR: 8254100: FX: Update copyright year in docs, readme files to 2021 In-Reply-To: References: Message-ID: <1P_37jcyqq3J7a4DHCO3FlzOww5JFsYlmdhouZQcFU8=.37c3b9b1-7b44-489b-a1e2-c48e685112e9@github.com> On Thu, 22 Oct 2020 11:45:23 GMT, Ambarish Rapte wrote: > Copyright year in these 3 docs needs to be updated to 2021. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/330 From arapte at openjdk.java.net Thu Oct 22 11:59:14 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 22 Oct 2020 11:59:14 GMT Subject: Integrated: 8254100: FX: Update copyright year in docs, readme files to 2021 In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 11:45:23 GMT, Ambarish Rapte wrote: > Copyright year in these 3 docs needs to be updated to 2021. This pull request has now been integrated. Changeset: 16b697c9 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/16b697c9 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8254100: FX: Update copyright year in docs, readme files to 2021 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/330 From aghaisas at openjdk.java.net Thu Oct 22 12:21:18 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 22 Oct 2020 12:21:18 GMT Subject: RFR: 8255241: [TestBug] Re-enable few ignored tests in javafx.controls module that pass with latest code Message-ID: <9fWHrDV9u2S3HzAzliSGNEZdmeB2e8rtGJH_m_UxKPo=.ac4d934d-7e38-49fb-9d72-4f8cfae7d120@github.com> Some of the ignored unit tests in javafx.controls module pass with latest code. This bug is to address - - removal of ignored tag - fixing the test if fix is minor ------------- Commit messages: - remove-whitespace - JDK-8255241-fix Changes: https://git.openjdk.java.net/jfx/pull/331/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=331&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255241 Stats: 37 lines in 10 files changed: 5 ins; 21 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/331.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/331/head:pull/331 PR: https://git.openjdk.java.net/jfx/pull/331 From pbansal at openjdk.java.net Thu Oct 22 12:36:15 2020 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 22 Oct 2020 12:36:15 GMT Subject: RFR: 8247494: Test failure in ImageRaceTest on some systems Message-ID: The test test.com.sun.javafx.image.impl.ImageRaceTest is fails intermittently in linux This is caused by use of Thread.yield. Thread.yield is used to tell pause the current thread for some time. It gives a hint to thread scheduler that the current thread should pause and other threads with same or higher priority should execute. But it is a hint only and can be ignored. so the current thread may very well continue to operate. This causes the test to fail on some slow machines. Better approach in this scenario would be to use Thread.sleep to make the thread for some time for some event. ------------- Commit messages: - 8247494: Test failure in ImageRaceTest on some systems Changes: https://git.openjdk.java.net/jfx/pull/332/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=332&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247494 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/332.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/332/head:pull/332 PR: https://git.openjdk.java.net/jfx/pull/332 From fastegal at openjdk.java.net Thu Oct 22 12:51:12 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 22 Oct 2020 12:51:12 GMT Subject: RFR: 8254100: FX: Update copyright year in docs, readme files to 2021 In-Reply-To: <1P_37jcyqq3J7a4DHCO3FlzOww5JFsYlmdhouZQcFU8=.37c3b9b1-7b44-489b-a1e2-c48e685112e9@github.com> References: <1P_37jcyqq3J7a4DHCO3FlzOww5JFsYlmdhouZQcFU8=.37c3b9b1-7b44-489b-a1e2-c48e685112e9@github.com> Message-ID: On Thu, 22 Oct 2020 11:53:35 GMT, Kevin Rushforth wrote: >> Copyright year in these 3 docs needs to be updated to 2021. > > Marked as reviewed by kcr (Lead). just curious - why 2021? back to the future or do we already prepare for the next release? ------------- PR: https://git.openjdk.java.net/jfx/pull/330 From kcr at openjdk.java.net Thu Oct 22 13:01:10 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 22 Oct 2020 13:01:10 GMT Subject: RFR: 8254100: FX: Update copyright year in docs, readme files to 2021 In-Reply-To: References: <1P_37jcyqq3J7a4DHCO3FlzOww5JFsYlmdhouZQcFU8=.37c3b9b1-7b44-489b-a1e2-c48e685112e9@github.com> Message-ID: On Thu, 22 Oct 2020 12:48:07 GMT, Jeanette Winzenburg wrote: >> Marked as reviewed by kcr (Lead). > > just curious - why 2021? back to the future or do we already prepare for the next release? The latter. JavaFX 16 will ship in March 2021. Note that this doesn't touch the "last modified" year in the copyright license header of those files, but rather the copyright year that will appear in the API docs when running `gradle javadoc`. We did the same thing last October, updating the copyright year for docs to 2020. See [JDK-8232522](https://bugs.openjdk.java.net/browse/JDK-8232522). ------------- PR: https://git.openjdk.java.net/jfx/pull/330 From kcr at openjdk.java.net Thu Oct 22 13:32:10 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 22 Oct 2020 13:32:10 GMT Subject: RFR: 8252596: [TESTBUG] WebPageShim::paint is not thread-safe In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 17:30:36 GMT, Arun Joseph wrote: > Issue: Tests using `WebPageShim::paint` fails around 1/10 times. > > Fix: Execute `WebPageShim::paint` in the render thread using `PrismInvoker`. Ran tests over 100 times, no failures. > > Used the initial unit test in the PR for [JDK-8202990](https://bugs.openjdk.java.net/browse/JDK-8202990). Looks good. I can confirm that it fixes the problem for me. On my machine the original test from [JDK-8202990](https://bugs.openjdk.java.net/browse/JDK-8202990) fails quite often without this fix. I was able to run 100 iterations of the test with no failure with your fix. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/327 From fastegal at openjdk.java.net Thu Oct 22 14:11:09 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 22 Oct 2020 14:11:09 GMT Subject: RFR: 8254100: FX: Update copyright year in docs, readme files to 2021 In-Reply-To: References: <1P_37jcyqq3J7a4DHCO3FlzOww5JFsYlmdhouZQcFU8=.37c3b9b1-7b44-489b-a1e2-c48e685112e9@github.com> Message-ID: <0HO30a1uT8zPEyl_zvl306s5vOIUecZz6Kpdn95Q02g=.9b664a5e-cb9b-4d63-ae2d-7e6938bc7f92@github.com> On Thu, 22 Oct 2020 12:58:09 GMT, Kevin Rushforth wrote: >> just curious - why 2021? back to the future or do we already prepare for the next release? > > The latter. JavaFX 16 will ship in March 2021. Note that this doesn't touch the "last modified" year in the copyright license header of those files, but rather the copyright year that will appear in the API docs when running `gradle javadoc`. We did the same thing last October, updating the copyright year for docs to 2020. See [JDK-8232522](https://bugs.openjdk.java.net/browse/JDK-8232522). thanks :) ------------- PR: https://git.openjdk.java.net/jfx/pull/330 From kcr at openjdk.java.net Thu Oct 22 14:57:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 22 Oct 2020 14:57:09 GMT Subject: RFR: 8247494: Test failure in ImageRaceTest on some systems In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 12:29:51 GMT, Pankaj Bansal wrote: > The test test.com.sun.javafx.image.impl.ImageRaceTest is fails intermittently in linux > > This is caused by use of Thread.yield. Thread.yield is used to pause the current thread for some time. It gives a hint to thread scheduler that the current thread should pause and other threads with same or higher priority should execute. But it is a hint only and can be ignored. so the current thread may very well continue to operate. This causes the test to fail on some slow machines. > > Better approach in this scenario would be to use Thread.sleep to make the thread wait for some time for some event. On my Oracle Linux 7.7 VM, the current test fails always. With your fix I ran 100 iterations of the test with 0 failures. +1 ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/332 From kcr at openjdk.java.net Thu Oct 22 15:40:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 22 Oct 2020 15:40:11 GMT Subject: RFR: 8255241: [TestBug] Re-enable few ignored tests in javafx.controls module that pass with latest code In-Reply-To: <9fWHrDV9u2S3HzAzliSGNEZdmeB2e8rtGJH_m_UxKPo=.ac4d934d-7e38-49fb-9d72-4f8cfae7d120@github.com> References: <9fWHrDV9u2S3HzAzliSGNEZdmeB2e8rtGJH_m_UxKPo=.ac4d934d-7e38-49fb-9d72-4f8cfae7d120@github.com> Message-ID: <6K-xCdARPmKJnPptjR0ysj6PM7LG-VsUH6ein9x05o8=.17205a62-b405-468b-8b6e-6ad838a14b09@github.com> On Thu, 22 Oct 2020 12:13:11 GMT, Ajit Ghaisas wrote: > Some of the ignored unit tests in javafx.controls module pass with latest code. > This bug is to address - > - removal of ignored tag > - fixing the test if fix is minor It works for me on Windows. Have you run it on more than one platform? I left one suggestion for you regarding the constants in TableColumnShim. modules/javafx.controls/src/shims/java/javafx/scene/control/TableColumnShim.java line 34: > 32: > 33: // NOTE: These constants are direct copy of TableColumnBase > 34: public static final double DEFAULT_WIDTH = 80.0F; Can you define these to reference those constants rather than copying them, like this? public static final double DEFAULT_WIDTH = TableColumnBase.DEFAULT_WIDTH ; If so, you can remove the comments about needing to keep them in sync. modules/javafx.controls/src/main/java/javafx/scene/control/TableColumnBase.java line 121: > 119: > 120: // NOTE: If these numbers change, update the copy of this value in > 121: // TableColumnHeader and in TableColumnShim I think you can revert this change. ------------- PR: https://git.openjdk.java.net/jfx/pull/331 From pbansal at openjdk.java.net Thu Oct 22 17:42:14 2020 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 22 Oct 2020 17:42:14 GMT Subject: Integrated: 8247494: Test failure in ImageRaceTest on some systems In-Reply-To: References: Message-ID: <0p9tF2fmCtj0x0fn4sShOJXp7ypwl6fnaclF9duTDXA=.36ecbf00-ec08-44f7-b117-8879f9eb6a4b@github.com> On Thu, 22 Oct 2020 12:29:51 GMT, Pankaj Bansal wrote: > The test test.com.sun.javafx.image.impl.ImageRaceTest is fails intermittently in linux > > This is caused by use of Thread.yield. Thread.yield is used to pause the current thread for some time. It gives a hint to thread scheduler that the current thread should pause and other threads with same or higher priority should execute. But it is a hint only and can be ignored. so the current thread may very well continue to operate. This causes the test to fail on some slow machines. > > Better approach in this scenario would be to use Thread.sleep to make the thread wait for some time for some event. This pull request has now been integrated. Changeset: a5a71d11 Author: Pankaj Bansal Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/a5a71d11 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod 8247494: Test failure in ImageRaceTest on some systems Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/332 From aghaisas at openjdk.java.net Thu Oct 22 17:48:25 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 22 Oct 2020 17:48:25 GMT Subject: RFR: 8255241: [TestBug] Re-enable few ignored tests in javafx.controls module that pass with latest code [v2] In-Reply-To: <9fWHrDV9u2S3HzAzliSGNEZdmeB2e8rtGJH_m_UxKPo=.ac4d934d-7e38-49fb-9d72-4f8cfae7d120@github.com> References: <9fWHrDV9u2S3HzAzliSGNEZdmeB2e8rtGJH_m_UxKPo=.ac4d934d-7e38-49fb-9d72-4f8cfae7d120@github.com> Message-ID: > Some of the ignored unit tests in javafx.controls module pass with latest code. > This bug is to address - > - removal of ignored tag > - fixing the test if fix is minor Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: review-fixes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/331/files - new: https://git.openjdk.java.net/jfx/pull/331/files/2dfafb6c..43d85d15 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=331&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=331&range=00-01 Stats: 7 lines in 2 files changed: 0 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/331.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/331/head:pull/331 PR: https://git.openjdk.java.net/jfx/pull/331 From aghaisas at openjdk.java.net Thu Oct 22 17:48:25 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 22 Oct 2020 17:48:25 GMT Subject: RFR: 8255241: [TestBug] Re-enable few ignored tests in javafx.controls module that pass with latest code [v2] In-Reply-To: <6K-xCdARPmKJnPptjR0ysj6PM7LG-VsUH6ein9x05o8=.17205a62-b405-468b-8b6e-6ad838a14b09@github.com> References: <9fWHrDV9u2S3HzAzliSGNEZdmeB2e8rtGJH_m_UxKPo=.ac4d934d-7e38-49fb-9d72-4f8cfae7d120@github.com> <6K-xCdARPmKJnPptjR0ysj6PM7LG-VsUH6ein9x05o8=.17205a62-b405-468b-8b6e-6ad838a14b09@github.com> Message-ID: On Thu, 22 Oct 2020 15:37:38 GMT, Kevin Rushforth wrote: > It works for me on Windows. Have you run it on more than one platform? I have run it on macOS and Windows. > I left one suggestion for you regarding the constants in TableColumnShim. Thanks for this. That's a cleaner way instead of copying constants. I will make this change soon. ------------- PR: https://git.openjdk.java.net/jfx/pull/331 From ajoseph at openjdk.java.net Thu Oct 22 18:12:07 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 22 Oct 2020 18:12:07 GMT Subject: Integrated: 8252596: [TESTBUG] WebPageShim::paint is not thread-safe In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 17:30:36 GMT, Arun Joseph wrote: > Issue: Tests using `WebPageShim::paint` fails around 1/10 times. > > Fix: Execute `WebPageShim::paint` in the render thread using `PrismInvoker`. Ran tests over 100 times, no failures. > > Used the initial unit test in the PR for [JDK-8202990](https://bugs.openjdk.java.net/browse/JDK-8202990). This pull request has now been integrated. Changeset: 4e5f0e6b Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/4e5f0e6b Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8252596: [TESTBUG] WebPageShim::paint is not thread-safe Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/327 From fkirmaier at openjdk.java.net Thu Oct 22 19:29:27 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 22 Oct 2020 19:29:27 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v7] In-Reply-To: References: Message-ID: <-orfaGhif_W5VXQ3yBzz26WskoRuF_hLQ2oNsyeN79c=.49df2bb4-8064-4dc2-9930-52c4f07cfbaa@github.com> > It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 > > I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. > > It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. > I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but the tests with JMemoryBuddy are basically always correct. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8244297 Updated JMemoryBuddy based on codereview. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/204/files - new: https://git.openjdk.java.net/jfx/pull/204/files/6a861e43..427170b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=204&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=204&range=05-06 Stats: 36 lines in 1 file changed: 18 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jfx/pull/204.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/204/head:pull/204 PR: https://git.openjdk.java.net/jfx/pull/204 From fkirmaier at openjdk.java.net Thu Oct 22 19:29:28 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 22 Oct 2020 19:29:28 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v5] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 08:54:02 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8244297 >> Fixing some wrong imports > > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 299: > >> 297: } >> 298: >> 299: } > > Please add an empty line at the end of file. done > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 95: > >> 93: int counter = stepsLeft; >> 94: >> 95: if(weakReference.get() != null) { > > It requires a space after `if`, `for`, `while` statements to adhere to Java Coding guidelines. done ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From fkirmaier at openjdk.java.net Thu Oct 22 19:29:30 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 22 Oct 2020 19:29:30 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v6] In-Reply-To: <4Yzd4sm7fdBWVb6_5DOrIsJRTcsof6fxgrKiYQOf_iA=.b291ffa5-f876-4a8c-a5bb-736fd8c2b14d@github.com> References: <4Yzd4sm7fdBWVb6_5DOrIsJRTcsof6fxgrKiYQOf_iA=.b291ffa5-f876-4a8c-a5bb-736fd8c2b14d@github.com> Message-ID: On Wed, 7 Oct 2020 12:09:15 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8244297 >> Fixed unit-test > > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 132: > >> 130: * Checks whether the content of the WeakReference can not be collected. >> 131: * @param weakReference The WeakReference to check. >> 132: * @return Returns true, when the provided WeakReference can be collected. > > needs typo correction: can not be collected done > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 152: > >> 150: f.accept(new MemoryTestAPI() { >> 151: public void assertCollectable(Object ref) { >> 152: if(ref == null) throw new NullPointerException(); > > `Object.requireNonNull()` method would be more suitable choice for null check. done > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 113: > >> 111: if(weakReference.get() == null && counter < steps / 3) { >> 112: int percentageUsed = (int) ((steps - counter) / steps * 100); >> 113: System.out.println("Warning test seems to be unstable. time used: " + percentageUsed + "%"); > > Seems like candidate for `System.err.` That might be true, but honestly, I'm using System.err so rarely (never) that I have a better feeling avoiding it altogether and eliminating the chance for rare cornercases. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From fkirmaier at openjdk.java.net Thu Oct 22 19:29:32 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 22 Oct 2020 19:29:32 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v6] In-Reply-To: References: Message-ID: On Sat, 17 Oct 2020 13:43:41 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8244297 >> Fixed unit-test > > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 42: > >> 40: >> 41: /** >> 42: * Checkout https://github.com/Sandec/JMemoryBuddy for more documentation. > > Can you add 1 or 2 sentences before this pointer describing (at a high level) the purpose of this class? done > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 235: > >> 233: } >> 234: >> 235: public static interface MemoryTestAPI { > > Can you add a (short) class javadoc comment? One thing to document is how and whether users of the API should implement it. done ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From fkirmaier at openjdk.java.net Thu Oct 22 19:29:31 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 22 Oct 2020 19:29:31 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v6] In-Reply-To: References: <4Yzd4sm7fdBWVb6_5DOrIsJRTcsof6fxgrKiYQOf_iA=.b291ffa5-f876-4a8c-a5bb-736fd8c2b14d@github.com> Message-ID: On Sat, 17 Oct 2020 13:22:35 GMT, Kevin Rushforth wrote: >> modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 52: >> >>> 50: private static int garbageAmount = 999999; >>> 51: private static String MX_BEAN_PROXY_TYPE = "com.sun.management:type=HotSpotDiagnostic"; >>> 52: private static String outputFolderString = "."; >> >> I am not sure of the directory that we use to save any runtime artifacts, but there must be one common directory that we should use here also. > > As long as this is somewhere under the `build/` dir of the project in question, it is OK. If not, then the default needs to be change. The newest version is checking for either a target or build folder, which usually depends on the build system. So it should be fine now. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From fkirmaier at openjdk.java.net Thu Oct 22 19:37:24 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 22 Oct 2020 19:37:24 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v8] In-Reply-To: References: Message-ID: > It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 > > I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. > > It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. > I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but the tests with JMemoryBuddy are basically always correct. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8244297 Updated JMemoryBuddy based on codereview. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/204/files - new: https://git.openjdk.java.net/jfx/pull/204/files/427170b8..3f731951 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=204&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=204&range=06-07 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/204.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/204/head:pull/204 PR: https://git.openjdk.java.net/jfx/pull/204 From fkirmaier at openjdk.java.net Thu Oct 22 19:50:23 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 22 Oct 2020 19:50:23 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v9] In-Reply-To: References: Message-ID: > It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 > > I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. > > It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. > I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but the tests with JMemoryBuddy are basically always correct. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8244297 Updated JMemoryBuddy based on codereview. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/204/files - new: https://git.openjdk.java.net/jfx/pull/204/files/3f731951..913622b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=204&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=204&range=07-08 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/204.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/204/head:pull/204 PR: https://git.openjdk.java.net/jfx/pull/204 From fkirmaier at openjdk.java.net Thu Oct 22 19:50:25 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 22 Oct 2020 19:50:25 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v6] In-Reply-To: <4Yzd4sm7fdBWVb6_5DOrIsJRTcsof6fxgrKiYQOf_iA=.b291ffa5-f876-4a8c-a5bb-736fd8c2b14d@github.com> References: <4Yzd4sm7fdBWVb6_5DOrIsJRTcsof6fxgrKiYQOf_iA=.b291ffa5-f876-4a8c-a5bb-736fd8c2b14d@github.com> Message-ID: On Thu, 8 Oct 2020 06:57:31 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8244297 >> Fixed unit-test > > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 56: > >> 54: static { >> 55: outputFolderString = System.getProperty("jmemorybuddy.output","."); >> 56: overallTime = Integer.parseInt(System.getProperty("jmemorybuddy.checktime","1000")); > > `sleepTime` should also be recomputed here based on `overallTime` done > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 51: > >> 49: private static boolean createHeapdump = false; >> 50: private static int garbageAmount = 999999; >> 51: private static String MX_BEAN_PROXY_TYPE = "com.sun.management:type=HotSpotDiagnostic"; > > `MX_BEAN_PROXY_TYPE` is not constant, so it should not be all capital letters but should be named just like other variables. done > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 47: > >> 45: >> 46: private static int steps = 10; >> 47: private static int overallTime = 1000; > > `overallTime` can be named as `totalDuration` or `testDuration` done ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From fkirmaier at openjdk.java.net Thu Oct 22 20:03:11 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 22 Oct 2020 20:03:11 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v6] In-Reply-To: <2xCEe181jfxbaEklJwb--wYgDUdn559gj6hjDmCssPQ=.a7f9a260-a8f7-45d5-986d-32181f6e9313@github.com> References: <2xCEe181jfxbaEklJwb--wYgDUdn559gj6hjDmCssPQ=.a7f9a260-a8f7-45d5-986d-32181f6e9313@github.com> Message-ID: <28pHuI_FycC0wEFb0sVwx7e7X4GQKYHqJcjPT8wsK2M=.2b67a66d-f187-4b8a-ae1e-08bb86683a67@github.com> On Sat, 17 Oct 2020 14:04:54 GMT, Kevin Rushforth wrote: >> This is looking quite good now. I really like how it simplifies the tests that you modified to use it. I'll run the tests next week after you update the PR. >> >>> I don't plan to confirm all coding guidelines of the JFX-project inside of JMemoryBuddy. >> >> Which ones in particular? I would think that the white space guidelines should be easy to adopt, although since this is a "downstream" implementation, we can relax this a bit. The only spacing issue I see in the code that really stands out to me is the missing space after conditional and loop operators (a favorite saying of mine is that "`if` is not a method"). I note that while different coding style guides vary on many points, all of the ones I have looked at recommend a space separating these operators from the opening paren. Do you think it would cause you problems to adopt this in the upstream code? >> >> I'm not really concerned about the naming of non-public variables: as long as the existing names aren't confusing (which I don't think they are), you can take our suggestions as just that -- suggestions that you can adopt or not. > > One more thing: I don't know if you noticed this from the Skara bot: > >> JDK-8244297: Provide utility for testing for memory leaks ?? Title mismatch between PR and JBS. > > You will need to update the PR title to match the JBS issue title. First, thank you both for all your comments! I integrated most of the suggested changes into the class and I will commit them back to the original project when the PR is closed. I've adopted the whitespace after if, and integrated most of the suggested changes (but not all)! The title should be correct now. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From jvos at openjdk.java.net Thu Oct 22 20:44:15 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 22 Oct 2020 20:44:15 GMT Subject: [jfx15] RFR: 8255272: Create release notes for JavaFX 15.0.1 Message-ID: releasenotes for JavaFX 15.0.1 ------------- Commit messages: - Add security fixes - Create release notes for JavaFX 15.0.1 Changes: https://git.openjdk.java.net/jfx/pull/335/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=335&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255272 Stats: 21 lines in 1 file changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/335.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/335/head:pull/335 PR: https://git.openjdk.java.net/jfx/pull/335 From kcr at openjdk.java.net Thu Oct 22 20:49:10 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 22 Oct 2020 20:49:10 GMT Subject: [jfx15] RFR: 8255272: Create release notes for JavaFX 15.0.1 In-Reply-To: References: Message-ID: <1mYaVF-7TXL7ben91f3Ax8JTe47gZ0hPayKh5T4nopc=.c8346c57-81b7-40c8-807e-f5563bd0f243@github.com> On Thu, 22 Oct 2020 20:36:40 GMT, Johan Vos wrote: > releasenotes for JavaFX 15.0.1 doc-files/release-notes-15.0.1.md line 16: > 14: [JDK-8255064](https://bugs.openjdk.java.net/browse/JDK-8255064) | Cherry pick GTK WebKit 2.28.4 changes | web > 15: [JDK-8255063](https://bugs.openjdk.java.net/browse/JDK-8255063) | Cherry pick GTK WebKit 2.28.3 changes | web > 16: [JDK-8255062](https://bugs.openjdk.java.net/browse/JDK-8255062) | Update to 610.1 version of WebKit | web These are the JBS IDs of the backport records. We normally use the main bug ID everywhere. The rest looks fine. ------------- PR: https://git.openjdk.java.net/jfx/pull/335 From pbansal at openjdk.java.net Fri Oct 23 06:53:51 2020 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Fri, 23 Oct 2020 06:53:51 GMT Subject: RFR: 8213573: MouseLocationOnScreenTest fails intermittently Message-ID: The test test.robot.javafx.scene.MouseLocationOnScreenTest fails intermittently on Windows and Mac system though it fails on Windows more often than Mac. The test uses robot to move the mouse at different positions on screen using mouseMove and then validates the mouse coordinates by robot.getMouseX/Y. If the coordinates returned from Robot.getMouseX/Y are same as mouse coordinates passed to Robot.mouseMove, the test passes, else the test fails. The issue here is that there is no wait/delay between the calls to mouseMove and getMouseX/Y. When Robot.mouseMove is used to move mouse to a coordinate, robot in turn sends the event to native system. When Robot.getMouseX/Y is called to get the current mouse coordinates, robot again uses native functions to get the mouse location. In current test, it is possible that the Robot.mouseMove is called with particular x,y coordinates and which in turn has send the events to native. As there is no delay/wait after calling Robot.mouseMove, When the Robot.getMouseX/Y is called, it is possible that the earlier event sent to native has not been processed yet. So the mouse has not been moved and Robot.getMouseX/Y may return older mouse coordinates. This results in the test to fail. In short, the Robot.mouseMove is an asynchronous call, so it should be used in same way. A follow up bug will be filled to update the specification to reflect this. The test is assuming it to be synchronous and results in intermittent failures. The fix is to add small delay after calling Robot.mouseMove. Along with this, now as the test will take more time, so the timeout time for test is increased to 120s. Also, I have divided the calls to edge(...) among more Util.runAndWait calls as there is a timeout limit for Util.runAndWait which is set to 10s. I tested this on Windows 10, Ubuntu 18.04, Ubuntu 20.04, Oracle Linux 8.2, Mac 10.13. For me this test is passing in less than 50 seconds on all platforms. Following command can be used to run the test gradle --continue --info -PFULL_TEST=true -PUSE_ROBOT=true :systemTest:cleanTest :systemTests:test --tests test.robot.javafx.scene.MouseLocationOnScreenTest ------------- Commit messages: - 1. Making the delay as 1 sec instead of 2 sec as it seems to pass on all systems. 2. Increasing the total test time to 2 minutes 3. Made chances so that each call to Util.runAndWait has only one edge checked. This should allow 10 sec for one edge, which should be enough on slower machines too. - 8213573: MouseLocationOnScreenTest fails intermittently Changes: https://git.openjdk.java.net/jfx/pull/333/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=333&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8213573 Stats: 27 lines in 1 file changed: 26 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/333.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/333/head:pull/333 PR: https://git.openjdk.java.net/jfx/pull/333 From jvos at openjdk.java.net Fri Oct 23 07:13:46 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 23 Oct 2020 07:13:46 GMT Subject: [jfx15] RFR: 8255272: Create release notes for JavaFX 15.0.1 [v2] In-Reply-To: References: Message-ID: > releasenotes for JavaFX 15.0.1 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Refer to original backport issues ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/335/files - new: https://git.openjdk.java.net/jfx/pull/335/files/2ff5e46f..d374a896 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=335&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=335&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/335.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/335/head:pull/335 PR: https://git.openjdk.java.net/jfx/pull/335 From jvos at openjdk.java.net Fri Oct 23 07:13:47 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 23 Oct 2020 07:13:47 GMT Subject: [jfx15] RFR: 8255272: Create release notes for JavaFX 15.0.1 [v2] In-Reply-To: <1mYaVF-7TXL7ben91f3Ax8JTe47gZ0hPayKh5T4nopc=.c8346c57-81b7-40c8-807e-f5563bd0f243@github.com> References: <1mYaVF-7TXL7ben91f3Ax8JTe47gZ0hPayKh5T4nopc=.c8346c57-81b7-40c8-807e-f5563bd0f243@github.com> Message-ID: On Thu, 22 Oct 2020 20:46:04 GMT, Kevin Rushforth wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Refer to original backport issues > > doc-files/release-notes-15.0.1.md line 16: > >> 14: [JDK-8255064](https://bugs.openjdk.java.net/browse/JDK-8255064) | Cherry pick GTK WebKit 2.28.4 changes | web >> 15: [JDK-8255063](https://bugs.openjdk.java.net/browse/JDK-8255063) | Cherry pick GTK WebKit 2.28.3 changes | web >> 16: [JDK-8255062](https://bugs.openjdk.java.net/browse/JDK-8255062) | Update to 610.1 version of WebKit | web > > These are the JBS IDs of the backport records. We normally use the main bug ID everywhere. The rest looks fine. That is fixed now. ------------- PR: https://git.openjdk.java.net/jfx/pull/335 From jpereda at openjdk.java.net Fri Oct 23 08:36:44 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 23 Oct 2020 08:36:44 GMT Subject: RFR: 8199592: Control labels truncated at certain DPI scaling levels Message-ID: As discussed in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an already snapped value (either intentionally or by mistake), the result should be the same, otherwise we'll be jumping unnecessary from a valid pixel to another pixel. This PR provides a fix to `snapSizeXX` methods used in `Region`, which ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value before ceiling, to ensure snapping a snapped value gives the same value. A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 different UI scales is provided. For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. Only for 1.75 and the random 1.374562997 value fails (the test fails for around 2% of the values with 1.75 and around 10% with 1.374562997). With the proposed fix, it doesn't fail at all. ------------- Commit messages: - Subtract epsilon to scaled value before ceiling, to ensure snapping a snapped value gives the same value. Include test Changes: https://git.openjdk.java.net/jfx/pull/336/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=336&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8199592 Stats: 35 lines in 2 files changed: 34 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/336.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/336/head:pull/336 PR: https://git.openjdk.java.net/jfx/pull/336 From kcr at openjdk.java.net Fri Oct 23 11:18:35 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 23 Oct 2020 11:18:35 GMT Subject: [jfx15] RFR: 8255272: Create release notes for JavaFX 15.0.1 [v2] In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 07:13:46 GMT, Johan Vos wrote: >> releasenotes for JavaFX 15.0.1 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Refer to original backport issues Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/335 From kcr at openjdk.java.net Fri Oct 23 11:31:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 23 Oct 2020 11:31:32 GMT Subject: RFR: 8255241: [TestBug] Re-enable few ignored tests in javafx.controls module that pass with latest code [v2] In-Reply-To: References: <9fWHrDV9u2S3HzAzliSGNEZdmeB2e8rtGJH_m_UxKPo=.ac4d934d-7e38-49fb-9d72-4f8cfae7d120@github.com> Message-ID: <31NZsBaMZdWpx3vpoEgxNhQkd_HJg7mv8tHd8alJfbE=.2e0bc8b9-7db3-45fc-8e00-2d78e454b5c8@github.com> On Thu, 22 Oct 2020 17:48:25 GMT, Ajit Ghaisas wrote: >> Some of the ignored unit tests in javafx.controls module pass with latest code. >> This bug is to address - >> - removal of ignored tag >> - fixing the test if fix is minor > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > review-fixes Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/331 From aghaisas at openjdk.java.net Fri Oct 23 11:41:45 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 23 Oct 2020 11:41:45 GMT Subject: RFR: 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException Message-ID: This is a test fix. Root cause: - For ButtonTest - Incorrect use of MouseEventFirer - which puts Button on to the stage and shows it before firing mouse event - For ComboBoxTest - adding ComboBox to a Stage, not showing the Stage but trying to show the ComboBox Fix : - For ButtonTest - Moved MouseEventFirer usage from test class to the 2 tests that need it - For ComboBoxTest - Started using StageLoader (which adds comboBox to the stage and shows it) instead of separate Scene and Stage creation. I have attached the logs captured before and after this fix to the JBS. ------------- Commit messages: - 8255337-fix-test-log-exceptions Changes: https://git.openjdk.java.net/jfx/pull/337/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=337&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255337 Stats: 50 lines in 2 files changed: 21 ins; 18 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/337.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/337/head:pull/337 PR: https://git.openjdk.java.net/jfx/pull/337 From aghaisas at openjdk.java.net Fri Oct 23 11:45:35 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 23 Oct 2020 11:45:35 GMT Subject: Integrated: 8255241: [TestBug] Re-enable few ignored tests in javafx.controls module that pass with latest code In-Reply-To: <9fWHrDV9u2S3HzAzliSGNEZdmeB2e8rtGJH_m_UxKPo=.ac4d934d-7e38-49fb-9d72-4f8cfae7d120@github.com> References: <9fWHrDV9u2S3HzAzliSGNEZdmeB2e8rtGJH_m_UxKPo=.ac4d934d-7e38-49fb-9d72-4f8cfae7d120@github.com> Message-ID: On Thu, 22 Oct 2020 12:13:11 GMT, Ajit Ghaisas wrote: > Some of the ignored unit tests in javafx.controls module pass with latest code. > This bug is to address - > - removal of ignored tag > - fixing the test if fix is minor This pull request has now been integrated. Changeset: 243b1a50 Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/243b1a50 Stats: 34 lines in 9 files changed: 2 ins; 21 del; 11 mod 8255241: [TestBug] Re-enable few ignored tests in javafx.controls module that pass with latest code Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/331 From jvos at openjdk.java.net Fri Oct 23 12:21:32 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 23 Oct 2020 12:21:32 GMT Subject: [jfx15] Integrated: 8255272: Create release notes for JavaFX 15.0.1 In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 20:36:40 GMT, Johan Vos wrote: > releasenotes for JavaFX 15.0.1 This pull request has now been integrated. Changeset: f4c348fe Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/f4c348fe Stats: 22 lines in 1 file changed: 22 ins; 0 del; 0 mod 8255272: Create release notes for JavaFX 15.0.1 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/335 From kcr at openjdk.java.net Fri Oct 23 13:40:37 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 23 Oct 2020 13:40:37 GMT Subject: RFR: 8213573: MouseLocationOnScreenTest fails intermittently In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 14:22:32 GMT, Pankaj Bansal wrote: > The test test.robot.javafx.scene.MouseLocationOnScreenTest fails intermittently on Windows and Mac system though it fails on Windows more often than Mac. > > The test uses robot to move the mouse at different positions on screen using mouseMove and then validates the mouse coordinates by robot.getMouseX/Y. If the coordinates returned from Robot.getMouseX/Y are same as mouse coordinates passed to Robot.mouseMove, the test passes, else the test fails. > > The issue here is that there is no wait/delay between the calls to mouseMove and getMouseX/Y. When Robot.mouseMove is used to move mouse to a coordinate, robot in turn sends the event to native system. When Robot.getMouseX/Y is called to get the current mouse coordinates, robot again uses native functions to get the mouse location. In current test, it is possible that the Robot.mouseMove is called with particular x,y coordinates and which in turn has send the events to native. As there is no delay/wait after calling Robot.mouseMove, When the Robot.getMouseX/Y is called, it is possible that the earlier event sent to native has not been processed yet. So the mouse has not been moved and Robot.getMouseX/Y may return older mouse coordinates. This results in the test to fail. > > In short, the Robot.mouseMove is an asynchronous call, so it should be used in same way. A follow up bug will be filled to update the specification to reflect this. The test is assuming it to be synchronous and results in intermittent failures. > > The fix is to add small delay after calling Robot.mouseMove. Along with this, now as the test will take more time, so the timeout time for test is increased to 120s. Also, I have divided the calls to edge(...) among more Util.runAndWait calls as there is a timeout limit for Util.runAndWait which is set to 10s. > > I tested this on Windows 10, Ubuntu 18.04, Ubuntu 20.04, Oracle Linux 8.2, Mac 10.13. For me this test is passing in less than 50 seconds on all platforms. Following command can be used to run the test > gradle --continue --info -PFULL_TEST=true -PUSE_ROBOT=true :systemTest:cleanTest :systemTests:test --tests test.robot.javafx.scene.MouseLocationOnScreenTest The fix looks good to me with a couple minor comments. I ran it on the following systems: * Windows 10 * macOS 10.15.7 * macOS 11 beta9 * Ubuntu 16.04 * Ubuntu 20.04 (VM on Win 10 host) * Oracle Linux 7.7 (VM on Win 10 host) The updated test passed on all systems. On the slowest system, the test took about 45 seconds for most runs and was always under 50 seconds. tests/system/src/test/java/test/robot/javafx/scene/MouseLocationOnScreenTest.java line 138: > 136: for (int y = y1; y <= y2; y++) { > 137: robot.mouseMove(x, y); > 138: delay(delayTime); Minor: you can use `Util.sleep` here instead of creating your own method. tests/system/src/test/java/test/robot/javafx/scene/MouseLocationOnScreenTest.java line 166: > 164: Thread.sleep(time); > 165: } catch (InterruptedException e) { > 166: Minor: there is an extra blank line here, although if you use `Util.sleep` instead you can remove this method entirely. tests/system/src/test/java/test/robot/javafx/scene/MouseLocationOnScreenTest.java line 46: > 44: static CountDownLatch startupLatch; > 45: static Robot robot; > 46: private static int delayTime = 1; Minor: typically such constants are all upper case with words separated by `_`. ------------- PR: https://git.openjdk.java.net/jfx/pull/333 From pbansal at openjdk.java.net Fri Oct 23 13:57:46 2020 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Fri, 23 Oct 2020 13:57:46 GMT Subject: RFR: 8213573: MouseLocationOnScreenTest fails intermittently [v2] In-Reply-To: References: Message-ID: > The test test.robot.javafx.scene.MouseLocationOnScreenTest fails intermittently on Windows and Mac system though it fails on Windows more often than Mac. > > The test uses robot to move the mouse at different positions on screen using mouseMove and then validates the mouse coordinates by robot.getMouseX/Y. If the coordinates returned from Robot.getMouseX/Y are same as mouse coordinates passed to Robot.mouseMove, the test passes, else the test fails. > > The issue here is that there is no wait/delay between the calls to mouseMove and getMouseX/Y. When Robot.mouseMove is used to move mouse to a coordinate, robot in turn sends the event to native system. When Robot.getMouseX/Y is called to get the current mouse coordinates, robot again uses native functions to get the mouse location. In current test, it is possible that the Robot.mouseMove is called with particular x,y coordinates and which in turn has send the events to native. As there is no delay/wait after calling Robot.mouseMove, When the Robot.getMouseX/Y is called, it is possible that the earlier event sent to native has not been processed yet. So the mouse has not been moved and Robot.getMouseX/Y may return older mouse coordinates. This results in the test to fail. > > In short, the Robot.mouseMove is an asynchronous call, so it should be used in same way. A follow up bug will be filled to update the specification to reflect this. The test is assuming it to be synchronous and results in intermittent failures. > > The fix is to add small delay after calling Robot.mouseMove. Along with this, now as the test will take more time, so the timeout time for test is increased to 120s. Also, I have divided the calls to edge(...) among more Util.runAndWait calls as there is a timeout limit for Util.runAndWait which is set to 10s. > > I tested this on Windows 10, Ubuntu 18.04, Ubuntu 20.04, Oracle Linux 8.2, Mac 10.13. For me this test is passing in less than 50 seconds on all platforms. Following command can be used to run the test > gradle --continue --info -PFULL_TEST=true -PUSE_ROBOT=true :systemTest:cleanTest :systemTests:test --tests test.robot.javafx.scene.MouseLocationOnScreenTest Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision: Fixing review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/333/files - new: https://git.openjdk.java.net/jfx/pull/333/files/4992e528..adc62f56 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=333&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=333&range=00-01 Stats: 12 lines in 1 file changed: 0 ins; 8 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/333.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/333/head:pull/333 PR: https://git.openjdk.java.net/jfx/pull/333 From pbansal at openjdk.java.net Fri Oct 23 13:57:47 2020 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Fri, 23 Oct 2020 13:57:47 GMT Subject: RFR: 8213573: MouseLocationOnScreenTest fails intermittently [v2] In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 13:33:35 GMT, Kevin Rushforth wrote: >> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing review comments > > tests/system/src/test/java/test/robot/javafx/scene/MouseLocationOnScreenTest.java line 138: > >> 136: for (int y = y1; y <= y2; y++) { >> 137: robot.mouseMove(x, y); >> 138: delay(delayTime); > > Minor: you can use `Util.sleep` here instead of creating your own method. Fixed ------------- PR: https://git.openjdk.java.net/jfx/pull/333 From kcr at openjdk.java.net Fri Oct 23 14:05:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 23 Oct 2020 14:05:32 GMT Subject: RFR: 8213573: MouseLocationOnScreenTest fails intermittently [v2] In-Reply-To: References: Message-ID: <74WkIRh3LoGb7QgikAQadhdBseDEgHUBR5xioyKSp5k=.d43c080d-ac58-4f31-a83c-f59b08a3e13d@github.com> On Fri, 23 Oct 2020 13:57:46 GMT, Pankaj Bansal wrote: >> The test test.robot.javafx.scene.MouseLocationOnScreenTest fails intermittently on Windows and Mac system though it fails on Windows more often than Mac. >> >> The test uses robot to move the mouse at different positions on screen using mouseMove and then validates the mouse coordinates by robot.getMouseX/Y. If the coordinates returned from Robot.getMouseX/Y are same as mouse coordinates passed to Robot.mouseMove, the test passes, else the test fails. >> >> The issue here is that there is no wait/delay between the calls to mouseMove and getMouseX/Y. When Robot.mouseMove is used to move mouse to a coordinate, robot in turn sends the event to native system. When Robot.getMouseX/Y is called to get the current mouse coordinates, robot again uses native functions to get the mouse location. In current test, it is possible that the Robot.mouseMove is called with particular x,y coordinates and which in turn has send the events to native. As there is no delay/wait after calling Robot.mouseMove, When the Robot.getMouseX/Y is called, it is possible that the earlier event sent to native has not been processed yet. So the mouse has not been moved and Robot.getMouseX/Y may return older mouse coordinates. This results in the test to fail. >> >> In short, the Robot.mouseMove is an asynchronous call, so it should be used in same way. A follow up bug will be filled to update the specification to reflect this. The test is assuming it to be synchronous and results in intermittent failures. >> >> The fix is to add small delay after calling Robot.mouseMove. Along with this, now as the test will take more time, so the timeout time for test is increased to 120s. Also, I have divided the calls to edge(...) among more Util.runAndWait calls as there is a timeout limit for Util.runAndWait which is set to 10s. >> >> I tested this on Windows 10, Ubuntu 18.04, Ubuntu 20.04, Oracle Linux 8.2, Mac 10.13. For me this test is passing in less than 50 seconds on all platforms. Following command can be used to run the test >> gradle --continue --info -PFULL_TEST=true -PUSE_ROBOT=true :systemTest:cleanTest :systemTests:test --tests test.robot.javafx.scene.MouseLocationOnScreenTest > > Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision: > > Fixing review comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/333 From pbansal at openjdk.java.net Fri Oct 23 14:15:36 2020 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Fri, 23 Oct 2020 14:15:36 GMT Subject: Integrated: 8213573: MouseLocationOnScreenTest fails intermittently In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 14:22:32 GMT, Pankaj Bansal wrote: > The test test.robot.javafx.scene.MouseLocationOnScreenTest fails intermittently on Windows and Mac system though it fails on Windows more often than Mac. > > The test uses robot to move the mouse at different positions on screen using mouseMove and then validates the mouse coordinates by robot.getMouseX/Y. If the coordinates returned from Robot.getMouseX/Y are same as mouse coordinates passed to Robot.mouseMove, the test passes, else the test fails. > > The issue here is that there is no wait/delay between the calls to mouseMove and getMouseX/Y. When Robot.mouseMove is used to move mouse to a coordinate, robot in turn sends the event to native system. When Robot.getMouseX/Y is called to get the current mouse coordinates, robot again uses native functions to get the mouse location. In current test, it is possible that the Robot.mouseMove is called with particular x,y coordinates and which in turn has send the events to native. As there is no delay/wait after calling Robot.mouseMove, When the Robot.getMouseX/Y is called, it is possible that the earlier event sent to native has not been processed yet. So the mouse has not been moved and Robot.getMouseX/Y may return older mouse coordinates. This results in the test to fail. > > In short, the Robot.mouseMove is an asynchronous call, so it should be used in same way. A follow up bug will be filled to update the specification to reflect this. The test is assuming it to be synchronous and results in intermittent failures. > > The fix is to add small delay after calling Robot.mouseMove. Along with this, now as the test will take more time, so the timeout time for test is increased to 120s. Also, I have divided the calls to edge(...) among more Util.runAndWait calls as there is a timeout limit for Util.runAndWait which is set to 10s. > > I tested this on Windows 10, Ubuntu 18.04, Ubuntu 20.04, Oracle Linux 8.2, Mac 10.13. For me this test is passing in less than 50 seconds on all platforms. Following command can be used to run the test > gradle --continue --info -PFULL_TEST=true -PUSE_ROBOT=true :systemTest:cleanTest :systemTests:test --tests test.robot.javafx.scene.MouseLocationOnScreenTest This pull request has now been integrated. Changeset: 2c675557 Author: Pankaj Bansal Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/2c675557 Stats: 19 lines in 1 file changed: 18 ins; 0 del; 1 mod 8213573: MouseLocationOnScreenTest fails intermittently Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/333 From kevin.rushforth at oracle.com Fri Oct 23 14:38:19 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 23 Oct 2020 07:38:19 -0700 Subject: CFV: New OpenJFX Committer: Pankaj Bansal Message-ID: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> I hereby nominate Pankaj Bansal [1] to OpenJFX Committer. Pankaj is a member of Java client team at Oracle, who has contributed 11 commits [2] to OpenJFX. Votes are due by November 6, 2020. Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. Thanks. -- Kevin [1] https://openjdk.java.net/census#pbansal [2] https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Pankaj+Bansal%22&type=commits [3] http://openjdk.java.net/census#openjfx [4] http://openjdk.java.net/bylaws#lazy-consensus [5] http://openjdk.java.net/projects#project-committer From kevin.rushforth at oracle.com Fri Oct 23 14:40:28 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 23 Oct 2020 07:40:28 -0700 Subject: CFV: New OpenJFX Committer: Pankaj Bansal In-Reply-To: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> References: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> Message-ID: <81e66a94-3ba8-cce7-de8f-2db423bbb2ff@oracle.com> Vote: YES On 10/23/2020 7:38 AM, Kevin Rushforth wrote: > I hereby nominate Pankaj Bansal [1] to OpenJFX Committer. > From nlisker at gmail.com Fri Oct 23 14:47:22 2020 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 23 Oct 2020 17:47:22 +0300 Subject: CFV: New OpenJFX Committer: Pankaj Bansal In-Reply-To: <81e66a94-3ba8-cce7-de8f-2db423bbb2ff@oracle.com> References: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> <81e66a94-3ba8-cce7-de8f-2db423bbb2ff@oracle.com> Message-ID: Vote: YES On Fri, Oct 23, 2020 at 5:40 PM Kevin Rushforth wrote: > Vote: YES > > On 10/23/2020 7:38 AM, Kevin Rushforth wrote: > > I hereby nominate Pankaj Bansal [1] to OpenJFX Committer. > > > > From johan at lodgon.com Fri Oct 23 14:51:55 2020 From: johan at lodgon.com (Johan Vos) Date: Fri, 23 Oct 2020 16:51:55 +0200 Subject: CFV: New OpenJFX Committer: Pankaj Bansal In-Reply-To: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> References: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> Message-ID: Vote: YES Op vr 23 okt. 2020 om 16:39 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > I hereby nominate Pankaj Bansal [1] to OpenJFX Committer. > > Pankaj is a member of Java client team at Oracle, who has contributed 11 > commits [2] to OpenJFX. > > Votes are due by November 6, 2020. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [5]. > > Thanks. > > -- Kevin > > [1] https://openjdk.java.net/census#pbansal > > [2] > > https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Pankaj+Bansal%22&type=commits > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > > From philip.race at oracle.com Fri Oct 23 15:10:46 2020 From: philip.race at oracle.com (Philip Race) Date: Fri, 23 Oct 2020 08:10:46 -0700 Subject: CFV: New OpenJFX Committer: Pankaj Bansal In-Reply-To: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> References: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> Message-ID: <5F92F276.3080508@oracle.com> Vote: yes -phil. From fastegal at openjdk.java.net Fri Oct 23 15:50:37 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 23 Oct 2020 15:50:37 GMT Subject: RFR: 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException In-Reply-To: References: Message-ID: <8RGHmndopjRYkCjt3PFYfpCA0Qhy8yp0q4P3KNzHZY8=.ab19efa4-59cb-4304-bac6-c84067ad1493@github.com> On Fri, 23 Oct 2020 11:35:50 GMT, Ajit Ghaisas wrote: > This is a test fix. > > Root cause: > - For ButtonTest - Incorrect use of MouseEventFirer - which puts Button on to the stage and shows it before firing mouse event > - For ComboBoxTest - adding ComboBox to a Stage, not showing the Stage but trying to show the ComboBox > > > Fix : > - For ButtonTest - Moved MouseEventFirer usage from test class to the 2 tests that need it > - For ComboBoxTest - Started using StageLoader (which adds comboBox to the stage and shows it) instead of separate Scene and Stage creation. > > > I have attached the logs captured before and after this fix to the JBS. modules/javafx.controls/src/test/java/test/javafx/scene/control/ButtonTest.java line 425: > 423: > 424: mouse.dispose(); > 425: } just curious: do we have to dispose the mouseFirer? If so, that pattern isn't safe because it will not happen if the test fails. modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 658: > 656: StageLoader sl = new StageLoader(comboBox); > 657: > 658: good catch :) But wouldn't show the stage have the same effect? (It's just me having a personal dislike of stageloader :) modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 679: > 677: > 678: sl.dispose(); > 679: } just for completeness: same as mouse.dispose above :) ------------- PR: https://git.openjdk.java.net/jfx/pull/337 From fastegal at swingempire.de Fri Oct 23 15:51:29 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 23 Oct 2020 17:51:29 +0200 Subject: CFV: New OpenJFX Committer: Pankaj Bansal In-Reply-To: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> References: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> Message-ID: <20201023175129.Horde.abpu9wprG2GvXzUFYltDlA8@webmail.df.eu> Vote: YES Zitat von Kevin Rushforth : > I hereby nominate Pankaj Bansal [1] to OpenJFX Committer. > > Pankaj is a member of Java client team at Oracle, who has > contributed 11 commits [2] to OpenJFX. > > Votes are due by November 6, 2020. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a > project Committer is described in [5]. > > Thanks. > > -- Kevin > > [1] https://openjdk.java.net/census#pbansal > > [2] > https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Pankaj+Bansal%22&type=commits > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer From guru.hb at oracle.com Fri Oct 23 15:58:06 2020 From: guru.hb at oracle.com (Guru) Date: Fri, 23 Oct 2020 21:28:06 +0530 Subject: CFV: New OpenJFX Committer: Pankaj Bansal In-Reply-To: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> References: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> Message-ID: Vote: YES > On 23-Oct-2020, at 8:08 PM, Kevin Rushforth wrote: > > I hereby nominate Pankaj Bansal [1] to OpenJFX Committer. > > Pankaj is a member of Java client team at Oracle, who has contributed 11 commits [2] to OpenJFX. > > Votes are due by November 6, 2020. > > Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. > > Thanks. > > -- Kevin > > [1] https://openjdk.java.net/census#pbansal > > [2] https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Pankaj+Bansal%22&type=commits > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From arun.aj.joseph at oracle.com Fri Oct 23 15:59:01 2020 From: arun.aj.joseph at oracle.com (Arun Joseph) Date: Fri, 23 Oct 2020 21:29:01 +0530 Subject: CFV: New OpenJFX Committer: Pankaj Bansal In-Reply-To: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> References: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> Message-ID: Vote: YES > On 23-Oct-2020, at 8:08 PM, Kevin Rushforth wrote: > > I hereby nominate Pankaj Bansal [1] to OpenJFX Committer. > > Pankaj is a member of Java client team at Oracle, who has contributed 11 commits [2] to OpenJFX. > > Votes are due by November 6, 2020. > > Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. > > Thanks. > > -- Kevin > > [1] https://openjdk.java.net/census#pbansal > > [2] https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Pankaj+Bansal%22&type=commits > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From johan.vos at gluonhq.com Sat Oct 24 09:12:21 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 24 Oct 2020 11:12:21 +0200 Subject: Move EventHandlerManager to public API In-Reply-To: References: Message-ID: That sounds like a valid reason for opening more API's, similar to what we did with the VirtualFlow. I would love to hear the opinion from others -- preferably now on the mailing list instead of later in a PR/CSR. - Johan On Mon, Oct 19, 2020 at 8:49 AM Abhinay Agarwal wrote: > Hi, > > Classes which extends Node have access to the protected method > `setEventHandler`[1]. It makes it exceptional easy to register a > user-defined onXXX event handler. > > However, for custom EventTarget which do not extend Node, it becomes > cumbersome as JavaFX expects us to create a whole new EventDispatcher to > register custom event handlers/filters on these targets. JavaFX already has > a number of implementation for EventDispatcher in the `com.sun` package. > The most basic of which are BasicEventDispatcher and EventHandlerManager. > The later seems to have all the necessary public methods to make it easier > to create new EventTargets. > > Unless there is a good reason which I am missing, JavaFX should provide a > basic implementation of EventDispatcher to make it easier for developers to > create custom EventTarget. > > FYR, ControlsFX has 3 classes which implement EventTarget directly: > > 1. > > AutoCompletionBinding [2] > > > 2. > > GridBase [3] > > 3. > > SpreadsheetCellBase [4] > > Regards, > Abhinay > > [1] > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/Node.java#L8776 > [2] > https://github.com/controlsfx/controlsfx/blob/jfx-13/controlsfx/src/main/java/org/controlsfx/control/textfield/AutoCompletionBinding.java > [3] > https://github.com/controlsfx/controlsfx/blob/jfx-13/controlsfx/src/main/java/org/controlsfx/control/spreadsheet/GridBase.java > [4] > https://github.com/controlsfx/controlsfx/blob/jfx-13/controlsfx/src/main/java/org/controlsfx/control/spreadsheet/SpreadsheetCellBase.java > From kcr at openjdk.java.net Sat Oct 24 18:52:31 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 24 Oct 2020 18:52:31 GMT Subject: RFR: 8199592: Control labels truncated at certain DPI scaling levels In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 08:32:59 GMT, Jose Pereda wrote: > As discussed in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an already snapped value (either intentionally or by mistake), the result should be the same, otherwise we'll be jumping unnecessary from a valid pixel to another pixel. > > This PR provides a fix to `snapSizeXX` methods used in `Region`, which ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value before ceiling, to ensure snapping a snapped value gives the same value. > > A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 different UI scales is provided. > For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. Only for 1.75 and the random 1.374562997 value fails (the test fails for around 2% of the values with 1.75 and around 10% with 1.374562997). > With the proposed fix, it doesn't fail at all. The approach looks good. I'll review it early next week, and also ask @arapte to review. ------------- PR: https://git.openjdk.java.net/jfx/pull/336 From kcr at openjdk.java.net Sat Oct 24 19:00:37 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 24 Oct 2020 19:00:37 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v9] In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 19:50:23 GMT, Florian Kirmaier wrote: >> It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 >> >> I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. >> >> It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. >> I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but the tests with JMemoryBuddy are basically always correct. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8244297 > Updated JMemoryBuddy based on codereview. Just a quick note, since I don't have time to review it today. Thanks for making the changes. I see that you added the space after `if` (except in the new method you added), but not after `for` and `while`. I'll do more testing next week as part of my review. modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 70: > 68: > 69: if(folder1.exists()) return folder1.getAbsolutePath(); > 70: if(folder2.exists()) return folder2.getAbsolutePath(); Space after `if` (I see you corrected most of them elsewhere in the code, thanks). ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From fastegal at openjdk.java.net Sun Oct 25 11:17:31 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sun, 25 Oct 2020 11:17:31 GMT Subject: RFR: 8199592: Control labels truncated at certain DPI scaling levels In-Reply-To: References: Message-ID: On Sat, 24 Oct 2020 18:50:22 GMT, Kevin Rushforth wrote: >> As discussed in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an already snapped value (either intentionally or by mistake), the result should be the same, otherwise we'll be jumping unnecessary from a valid pixel to another pixel. >> >> This PR provides a fix to `snapSizeXX` methods used in `Region`, which ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value before ceiling, to ensure snapping a snapped value gives the same value. >> >> A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 different UI scales is provided. >> For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. Only for 1.75 and the random 1.374562997 value fails (the test fails for around 2% of the values with 1.75 and around 10% with 1.374562997). >> With the proposed fix, it doesn't fail at all. > > The approach looks good. I'll review it early next week, and also ask @arapte to review. curious: it this expected to fix the ellipsed checkBox texts? Can verify that the test fails/passes before/after the fix, but the example in the report looks still is eclipsed: same for 1.5, slightly better (in that only the first text is eclipsed compared to the first 3 without) for 1.75 scaling. What am I missing? ------------- PR: https://git.openjdk.java.net/jfx/pull/336 From fkirmaier at openjdk.java.net Sun Oct 25 13:24:44 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sun, 25 Oct 2020 13:24:44 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v10] In-Reply-To: References: Message-ID: > It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 > > I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. > > It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. > I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but the tests with JMemoryBuddy are basically always correct. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8244297 Added some more whitespaces based on review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/204/files - new: https://git.openjdk.java.net/jfx/pull/204/files/913622b9..91bda93f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=204&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=204&range=08-09 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/204.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/204/head:pull/204 PR: https://git.openjdk.java.net/jfx/pull/204 From fkirmaier at openjdk.java.net Sun Oct 25 13:24:45 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sun, 25 Oct 2020 13:24:45 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v9] In-Reply-To: References: Message-ID: On Sat, 24 Oct 2020 18:57:27 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8244297 >> Updated JMemoryBuddy based on codereview. > > Just a quick note, since I don't have time to review it today. Thanks for making the changes. I see that you added the space after `if` (except in the new method you added), but not after `for` and `while`. > > I'll do more testing next week as part of my review. Just added some more spaces! > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 70: > >> 68: >> 69: if(folder1.exists()) return folder1.getAbsolutePath(); >> 70: if(folder2.exists()) return folder2.getAbsolutePath(); > > Space after `if` (I see you corrected most of them elsewhere in the code, thanks). done ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From jpereda at openjdk.java.net Sun Oct 25 19:30:32 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Sun, 25 Oct 2020 19:30:32 GMT Subject: RFR: 8199592: Control labels truncated at certain DPI scaling levels In-Reply-To: References: Message-ID: On Sun, 25 Oct 2020 11:14:43 GMT, Jeanette Winzenburg wrote: >> The approach looks good. I'll review it early next week, and also ask @arapte to review. > > curious: it this expected to fix the ellipsed checkBox texts? Can verify that the test fails/passes before/after the fix, but the example in the report looks still is eclipsed: same for 1.5, slightly better (in that only the first text is eclipsed compared to the first 3 without) for 1.75 scaling. What am I missing? @kleopatra Thanks for checking. As discussed in the JBS issue, there is a call in `CheckBoxSkin::layoutChildren` that, probably by mistake, calls `snapSizeX` twice, and that gives different results when a different UI scale is used. This PR applies to the snapSizeXX methods, so it is guaranteed that `snapSizeXX(snapSizeXX(a)) == snapSizeXX(a)`. With the included test, _this_ issue should now be fixed. However, you are totally right, the CheckBox test from the JBS issue only works fine with this PR either if `Stage::sizeToScene` is called or if the Scene is created with a defined width, so we still have another issue laying around. Running the CheckBox test on Windows with 1.75% UI scale and without calling `sizeToScene`, produces this log of width and height values: Scene::resizeRootOnSceneSizeChange 256.0, 33.0 ... Scene::resizeRootOnSceneSizeChange 256.0, 33.0 ... // WindowEvent.RESIZE event UI scale 1.75 ... Scene::resizeRootOnSceneSizeChange 256.0, 33.14285659790039 Both values should be snapped, as these are generated with snap methods in HBox. However, this is not the case for height, as there are some conversions in between: This 33.14285659790039 value comes from an int (`View`: height = (int) (33.0 x 1.75) = 58) to float (`TKSceneListener`: h = 33.142857) to double (`Scene` width = 33.14285659790039). However, the proper snapped value should be 33.14285714285714. However, if we add a call to `stage.sizeToScene()`, then the log is: Scene::resizeRootOnSceneSizeChange 256.0, 33.0 ... Scene::resizeRootOnSceneSizeChange 256.0, 33.0 ... Scene::resizeRootOnSceneSizeChange 256.0, 33.14285659790039 ... Scene::resizeRootOnSceneSizeChange 257.1428571428571, 33.14285714285714 ... Scene::resizeRootOnSceneSizeChange 257.1428571428571, 33.14285714285714 ... both width and height have stable snapped values, and the checkbox layout is correct. Back to the 256.0 value of width, this value comes from margin (8.0 * 2) + controls width(54.0 * 4) + spacing (8.0 * 3), but the value 54.0 is not properly computed, as at this point the UI scale is still 1.0. Once the UI scale is set to 1.75 the checkBox width is 54.285714285714285, and the scene's width is 257.14285714285714. So the issue can be related to the UI scale value taken into account too late, and how this change doesn't trigger an update of the scene. Does it make sense to address this issue with the current PR? ------------- PR: https://git.openjdk.java.net/jfx/pull/336 From fastegal at openjdk.java.net Mon Oct 26 10:06:07 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 26 Oct 2020 10:06:07 GMT Subject: RFR: 8199592: Control labels truncated at certain DPI scaling levels In-Reply-To: References: Message-ID: On Sun, 25 Oct 2020 19:27:30 GMT, Jose Pereda wrote: >> curious: it this expected to fix the ellipsed checkBox texts? Can verify that the test fails/passes before/after the fix, but the example in the report looks still is eclipsed: same for 1.5, slightly better (in that only the first text is eclipsed compared to the first 3 without) for 1.75 scaling. What am I missing? > > @kleopatra Thanks for checking. > > As discussed in the JBS issue, there is a call in `CheckBoxSkin::layoutChildren` that, probably by mistake, calls `snapSizeX` twice, and that gives different results when a different UI scale is used. > > This PR applies to the snapSizeXX methods, so it is guaranteed that `snapSizeXX(snapSizeXX(a)) == snapSizeXX(a)`. With the included test, _this_ issue should now be fixed. > > However, you are totally right, the CheckBox test from the JBS issue only works fine with this PR either if `Stage::sizeToScene` is called or if the Scene is created with a defined width, so we still have another issue laying around. > > Running the CheckBox test on Windows with 1.75% UI scale and without calling `sizeToScene`, produces this log of width and height values: > > Scene::resizeRootOnSceneSizeChange 256.0, 33.0 > ... > Scene::resizeRootOnSceneSizeChange 256.0, 33.0 > ... > // WindowEvent.RESIZE event UI scale 1.75 > ... > Scene::resizeRootOnSceneSizeChange 256.0, 33.14285659790039 > > Both values should be snapped, as these are generated with snap methods in HBox. However, this is not the case for height, as there are some conversions in between: This 33.14285659790039 value comes from an int (`View`: height = (int) (33.0 x 1.75) = 58) to float (`TKSceneListener`: h = 33.142857) to double (`Scene` width = 33.14285659790039). However, the proper snapped value should be 33.14285714285714. > > However, if we add a call to `stage.sizeToScene()`, then the log is: > > Scene::resizeRootOnSceneSizeChange 256.0, 33.0 > ... > Scene::resizeRootOnSceneSizeChange 256.0, 33.0 > ... > Scene::resizeRootOnSceneSizeChange 256.0, 33.14285659790039 > ... > Scene::resizeRootOnSceneSizeChange 257.1428571428571, 33.14285714285714 > ... > Scene::resizeRootOnSceneSizeChange 257.1428571428571, 33.14285714285714 > ... > both width and height have stable snapped values, and the checkbox layout is correct. > > Back to the 256.0 value of width, this value comes from margin (8.0 * 2) + controls width(54.0 * 4) + spacing (8.0 * 3), but the value 54.0 is not properly computed, as at this point the UI scale is still 1.0. > Once the UI scale is set to 1.75 the checkBox width is 54.285714285714285, and the scene's width is 257.14285714285714. > > So the issue can be related to the UI scale value taken into account too late, and how this change doesn't trigger an update of the scene. > > Does it make sense to address this issue with the current PR? thanks for the additional info - good dig ?? As you noted, there are two issues: - the implementation of the scaled snaps to make them stable (against nested calls) BTW, any reason snappedXXInset are not scaled? - a timing/sequence issue with applying the scale So might separate them out in different issues, the first with a new one with this PR fixing it. Depends a bit on granularity of issues - personally, would prefer it, though, if only to make snapping issues more prominent. ------------- PR: https://git.openjdk.java.net/jfx/pull/336 From kcr at openjdk.java.net Mon Oct 26 16:58:31 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 26 Oct 2020 16:58:31 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo Message-ID: This is a proposed fix for [JDK-8254691](https://bugs.openjdk.java.net/browse/JDK-8254691) to enable GitHub actions for the jfx repo. It is similar in purpose to what was done for the jdk repo. Once this is integrated, and subsequently merged into your personal fork, a GitHub Actions workflow will run on every push to any branch in your personal fork except a production branch (so that syncing the upstream `master` or `jfx*` branch won't cause a build) or any branch whose name that starts with `WIP`. The workflow does a build and (headless) test run on all three platforms: Linux, macOS, and Windows. The build is done without building the native media or WebKit libraries. Web tests are excluded. Here is the job that resulted from the most recent push to the `8254691-github-actions` branch in my personal fork: https://github.com/kevinrushforth/jfx/actions/runs/329355746 The workflow checks out the sources for the branch, downloads the boot JDK, installs the needed software packages, and then runs two build steps, `gradlew all` followed by `gradlew test -x :web:test`. The Skara tooling will process the results of the GitHub actions run, and show them in the **Testing** section of a pull request, as you can see below. Follow-on work: 1. Get BOOT JDK parameters from `build.properties`. Currently the location of the bootJDK is hardcoded in the [`submit.yml`](https://github.com/kevinrushforth/jfx/blob/8254691-github-actions/.github/workflows/submit.yml) file. This should be obtained from build.properties; we might need to add a couple more properties. 2. Check the shasum of the downloaded bootJDK and enable caching of the JDK (in order to save download time). This requires step 1 to be done first. 3. Locate the Visual Studio compiler on Windows. The location and version of the Microsoft Visual Studio 2019 compiler is hard-coded which will break if and when the GitHub build farm updates their Windows system. This will require making our build itself a little smarter, possibly using `vswhere`. ------------- Commit messages: - Ignore additional branches; minor cleanup - WIP: 8254691: Enable GitHub actions for jfx repo Changes: https://git.openjdk.java.net/jfx/pull/338/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=338&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254691 Stats: 285 lines in 1 file changed: 285 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/338.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/338/head:pull/338 PR: https://git.openjdk.java.net/jfx/pull/338 From kcr at openjdk.java.net Mon Oct 26 16:58:31 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 26 Oct 2020 16:58:31 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo In-Reply-To: References: Message-ID: On Sat, 24 Oct 2020 14:41:08 GMT, Kevin Rushforth wrote: > This is a proposed fix for [JDK-8254691](https://bugs.openjdk.java.net/browse/JDK-8254691) to enable GitHub actions for the jfx repo. It is similar in purpose to what was done for the jdk repo. > > Once this is integrated, and subsequently merged into your personal fork, a GitHub Actions workflow will run on every push to any branch in your personal fork except a production branch (so that syncing the upstream `master` or `jfx*` branch won't cause a build) or any branch whose name that starts with `WIP`. > > The workflow does a build and (headless) test run on all three platforms: Linux, macOS, and Windows. The build is done without building the native media or WebKit libraries. Web tests are excluded. > > Here is the job that resulted from the most recent push to the `8254691-github-actions` branch in my personal fork: > > https://github.com/kevinrushforth/jfx/actions/runs/329355746 > > The workflow checks out the sources for the branch, downloads the boot JDK, installs the needed software packages, and then runs two build steps, `gradlew all` followed by `gradlew test -x :web:test`. > > The Skara tooling will process the results of the GitHub actions run, and show them in the **Testing** section of a pull request, as you can see below. > > Follow-on work: > > 1. Get BOOT JDK parameters from `build.properties`. Currently the location of the bootJDK is hardcoded in the [`submit.yml`](https://github.com/kevinrushforth/jfx/blob/8254691-github-actions/.github/workflows/submit.yml) file. This should be obtained from build.properties; we might need to add a couple more properties. > > 2. Check the shasum of the downloaded bootJDK and enable caching of the JDK (in order to save download time). This requires step 1 to be done first. > > 3. Locate the Visual Studio compiler on Windows. The location and version of the Microsoft Visual Studio 2019 compiler is hard-coded which will break if and when the GitHub build farm updates their Windows system. This will require making our build itself a little smarter, possibly using `vswhere`. @rwestberg I was pleasantly surprised to see the Skara bot add this: >? | Linux x64 | Windows x64 | macOS x64 > -- | -- | -- | -- > Build / test | ?? (1/1 passed) | ?? (1/1 passed) | ?? (1/1 passed) I was going to ask you what I needed to do so that you could generate this. I guess the short answer is that what I've already done is sufficient. Thanks! .github/workflows/submit.yml line 31: > 29: push: > 30: branches-ignore: > 31: - master Add `jfx[0-9]*` to this. Also consider adding `WIP.*`, `scratch.*`, and similar. ------------- PR: https://git.openjdk.java.net/jfx/pull/338 From jvos at openjdk.java.net Mon Oct 26 16:58:31 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 26 Oct 2020 16:58:31 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo In-Reply-To: References: Message-ID: On Sat, 24 Oct 2020 14:49:37 GMT, Kevin Rushforth wrote: >> This is a proposed fix for [JDK-8254691](https://bugs.openjdk.java.net/browse/JDK-8254691) to enable GitHub actions for the jfx repo. It is similar in purpose to what was done for the jdk repo. >> >> Once this is integrated, and subsequently merged into your personal fork, a GitHub Actions workflow will run on every push to any branch in your personal fork except a production branch (so that syncing the upstream `master` or `jfx*` branch won't cause a build) or any branch whose name that starts with `WIP`. >> >> The workflow does a build and (headless) test run on all three platforms: Linux, macOS, and Windows. The build is done without building the native media or WebKit libraries. Web tests are excluded. >> >> Here is the job that resulted from the most recent push to the `8254691-github-actions` branch in my personal fork: >> >> https://github.com/kevinrushforth/jfx/actions/runs/329355746 >> >> The workflow checks out the sources for the branch, downloads the boot JDK, installs the needed software packages, and then runs two build steps, `gradlew all` followed by `gradlew test -x :web:test`. >> >> The Skara tooling will process the results of the GitHub actions run, and show them in the **Testing** section of a pull request, as you can see below. >> >> Follow-on work: >> >> 1. Get BOOT JDK parameters from `build.properties`. Currently the location of the bootJDK is hardcoded in the [`submit.yml`](https://github.com/kevinrushforth/jfx/blob/8254691-github-actions/.github/workflows/submit.yml) file. This should be obtained from build.properties; we might need to add a couple more properties. >> >> 2. Check the shasum of the downloaded bootJDK and enable caching of the JDK (in order to save download time). This requires step 1 to be done first. >> >> 3. Locate the Visual Studio compiler on Windows. The location and version of the Microsoft Visual Studio 2019 compiler is hard-coded which will break if and when the GitHub build farm updates their Windows system. This will require making our build itself a little smarter, possibly using `vswhere`. > > @rwestberg I was pleasantly surprised to see the Skara bot add this: > >>? | Linux x64 | Windows x64 | macOS x64 >> -- | -- | -- | -- >> Build / test | ?? (1/1 passed) | ?? (1/1 passed) | ?? (1/1 passed) > > I was going to ask you what I needed to do so that you could generate this. I guess the short answer is that what I've already done is sufficient. Thanks! > @rwestberg I was pleasantly surprised to see the Skara bot add this: > > > Linux x64 > > Windows x64 > > macOS x64 > > > > > > > > > > Build / test > > heavy_check_mark (1/1 passed) > > heavy_check_mark (1/1 passed) > > heavy_check_mark (1/1 passed) > > I was going to ask you what I needed to do so that you could generate this. I guess the short answer is that what I've already done is sufficient. Thanks! I noticed this in the openjdk/mobile repository as well, and that looks great. In that repository, there seems to be a different configuration, as there is a line for "build" and a line for "test/tier 1" ( e.g. https://github.com/openjdk/mobile/pull/10 ) I wonder how configurable this is? ------------- PR: https://git.openjdk.java.net/jfx/pull/338 From kcr at openjdk.java.net Mon Oct 26 16:58:31 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 26 Oct 2020 16:58:31 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo In-Reply-To: References: Message-ID: <-eDYvRKiZp6S6De2i6Wq_KVFfPf5Ri99O3dYVo3H4r4=.83764206-2ca7-4ea1-a4b0-a918c363f343@github.com> On Sat, 24 Oct 2020 16:56:46 GMT, Johan Vos wrote: >> @rwestberg I was pleasantly surprised to see the Skara bot add this: >> >>>? | Linux x64 | Windows x64 | macOS x64 >>> -- | -- | -- | -- >>> Build / test | ?? (1/1 passed) | ?? (1/1 passed) | ?? (1/1 passed) >> >> I was going to ask you what I needed to do so that you could generate this. I guess the short answer is that what I've already done is sufficient. Thanks! > >> @rwestberg I was pleasantly surprised to see the Skara bot add this: >> >> > Linux x64 >> > Windows x64 >> > macOS x64 >> > >> > >> > >> > >> > Build / test >> > heavy_check_mark (1/1 passed) >> > heavy_check_mark (1/1 passed) >> > heavy_check_mark (1/1 passed) >> >> I was going to ask you what I needed to do so that you could generate this. I guess the short answer is that what I've already done is sufficient. Thanks! > > I noticed this in the openjdk/mobile repository as well, and that looks great. In that repository, there seems to be a different configuration, as there is a line for "build" and a line for "test/tier 1" ( e.g. https://github.com/openjdk/mobile/pull/10 ) > > I wonder how configurable this is? The jdk workflow is split into a build job and multiple test jobs (since it takes so long they need the parallelism when running the tests). It's more complicated that way, since you have to feed the results of the build job into all of the test jobs, and there is duplication of some of the configuration steps. I don't know that it would buy us much, so I wasn't planning to split the jobs -- at leat not initially. The build and test are done in separate steps within the job so it's easy to see which one failed. Maybe Robin can comment further as to whether we could do something a bit more clever. ------------- PR: https://git.openjdk.java.net/jfx/pull/338 From rwestberg at openjdk.java.net Mon Oct 26 16:58:32 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Mon, 26 Oct 2020 16:58:32 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo In-Reply-To: <-eDYvRKiZp6S6De2i6Wq_KVFfPf5Ri99O3dYVo3H4r4=.83764206-2ca7-4ea1-a4b0-a918c363f343@github.com> References: <-eDYvRKiZp6S6De2i6Wq_KVFfPf5Ri99O3dYVo3H4r4=.83764206-2ca7-4ea1-a4b0-a918c363f343@github.com> Message-ID: On Sat, 24 Oct 2020 18:26:29 GMT, Kevin Rushforth wrote: >>> @rwestberg I was pleasantly surprised to see the Skara bot add this: >>> >>> > Linux x64 >>> > Windows x64 >>> > macOS x64 >>> > >>> > >>> > >>> > >>> > Build / test >>> > heavy_check_mark (1/1 passed) >>> > heavy_check_mark (1/1 passed) >>> > heavy_check_mark (1/1 passed) >>> >>> I was going to ask you what I needed to do so that you could generate this. I guess the short answer is that what I've already done is sufficient. Thanks! >> >> I noticed this in the openjdk/mobile repository as well, and that looks great. In that repository, there seems to be a different configuration, as there is a line for "build" and a line for "test/tier 1" ( e.g. https://github.com/openjdk/mobile/pull/10 ) >> >> I wonder how configurable this is? > > The jdk workflow is split into a build job and multiple test jobs (since it takes so long they need the parallelism when running the tests). It's more complicated that way, since you have to feed the results of the build job into all of the test jobs, and there is duplication of some of the configuration steps. I don't know that it would buy us much, so I wasn't planning to split the jobs -- at leat not initially. > > The build and test are done in separate steps within the job so it's easy to see which one failed. Maybe Robin can comment further as to whether we could do something a bit more clever. > I noticed this in the openjdk/mobile repository as well, and that looks great. In that repository, there seems to be a different configuration, as there is a line for "build" and a line for "test/tier 1" ( e.g. [openjdk/mobile#10](https://github.com/openjdk/mobile/pull/10) ) > > I wonder how configurable this is? The output is not very configurable at all. :) You can see https://github.com/openjdk/skara/blob/bd4cc7e9a6ff7b04c6dc650a969638d5c1471031/bots/pr/src/main/java/org/openjdk/skara/bots/pr/TestResults.java#L42 for details. But it should support additional tiers at least if any were added in the future. ------------- PR: https://git.openjdk.java.net/jfx/pull/338 From kcr at openjdk.java.net Mon Oct 26 16:58:33 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 26 Oct 2020 16:58:33 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo In-Reply-To: References: Message-ID: On Sat, 24 Oct 2020 16:28:28 GMT, Kevin Rushforth wrote: >> This is a proposed fix for [JDK-8254691](https://bugs.openjdk.java.net/browse/JDK-8254691) to enable GitHub actions for the jfx repo. It is similar in purpose to what was done for the jdk repo. >> >> Once this is integrated, and subsequently merged into your personal fork, a GitHub Actions workflow will run on every push to any branch in your personal fork except a production branch (so that syncing the upstream `master` or `jfx*` branch won't cause a build) or any branch whose name that starts with `WIP`. >> >> The workflow does a build and (headless) test run on all three platforms: Linux, macOS, and Windows. The build is done without building the native media or WebKit libraries. Web tests are excluded. >> >> Here is the job that resulted from the most recent push to the `8254691-github-actions` branch in my personal fork: >> >> https://github.com/kevinrushforth/jfx/actions/runs/329355746 >> >> The workflow checks out the sources for the branch, downloads the boot JDK, installs the needed software packages, and then runs two build steps, `gradlew all` followed by `gradlew test -x :web:test`. >> >> The Skara tooling will process the results of the GitHub actions run, and show them in the **Testing** section of a pull request, as you can see below. >> >> Follow-on work: >> >> 1. Get BOOT JDK parameters from `build.properties`. Currently the location of the bootJDK is hardcoded in the [`submit.yml`](https://github.com/kevinrushforth/jfx/blob/8254691-github-actions/.github/workflows/submit.yml) file. This should be obtained from build.properties; we might need to add a couple more properties. >> >> 2. Check the shasum of the downloaded bootJDK and enable caching of the JDK (in order to save download time). This requires step 1 to be done first. >> >> 3. Locate the Visual Studio compiler on Windows. The location and version of the Microsoft Visual Studio 2019 compiler is hard-coded which will break if and when the GitHub build farm updates their Windows system. This will require making our build itself a little smarter, possibly using `vswhere`. > > .github/workflows/submit.yml line 31: > >> 29: push: >> 30: branches-ignore: >> 31: - master > > Add `jfx[0-9]*` to this. Also consider adding `WIP.*`, `scratch.*`, and similar. I propose to ignore the following branches: branches-ignore: - master - main - 'jfx[0-9]+' - 'WIP*' The thinking behind this is that you will still get build / test by default, but if you are are working on something experimental and don't want the noise of an automatic build / test on every push to your branch, you can prefix your branch name with "WIP". ------------- PR: https://git.openjdk.java.net/jfx/pull/338 From jpereda at openjdk.java.net Mon Oct 26 20:33:18 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 26 Oct 2020 20:33:18 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results In-Reply-To: References: Message-ID: <5n-Wwf-ZReMA33kIZC2d9GYX9-fx2Q1b-zIGCrhqNrk=.553d4fa6-13bb-4e13-9289-77b6a5bd292a@github.com> On Mon, 26 Oct 2020 10:03:20 GMT, Jeanette Winzenburg wrote: >> @kleopatra Thanks for checking. >> >> As discussed in the JBS issue, there is a call in `CheckBoxSkin::layoutChildren` that, probably by mistake, calls `snapSizeX` twice, and that gives different results when a different UI scale is used. >> >> This PR applies to the snapSizeXX methods, so it is guaranteed that `snapSizeXX(snapSizeXX(a)) == snapSizeXX(a)`. With the included test, _this_ issue should now be fixed. >> >> However, you are totally right, the CheckBox test from the JBS issue only works fine with this PR either if `Stage::sizeToScene` is called or if the Scene is created with a defined width, so we still have another issue laying around. >> >> Running the CheckBox test on Windows with 1.75% UI scale and without calling `sizeToScene`, produces this log of width and height values: >> >> Scene::resizeRootOnSceneSizeChange 256.0, 33.0 >> ... >> Scene::resizeRootOnSceneSizeChange 256.0, 33.0 >> ... >> // WindowEvent.RESIZE event UI scale 1.75 >> ... >> Scene::resizeRootOnSceneSizeChange 256.0, 33.14285659790039 >> >> Both values should be snapped, as these are generated with snap methods in HBox. However, this is not the case for height, as there are some conversions in between: This 33.14285659790039 value comes from an int (`View`: height = (int) (33.0 x 1.75) = 58) to float (`TKSceneListener`: h = 33.142857) to double (`Scene` width = 33.14285659790039). However, the proper snapped value should be 33.14285714285714. >> >> However, if we add a call to `stage.sizeToScene()`, then the log is: >> >> Scene::resizeRootOnSceneSizeChange 256.0, 33.0 >> ... >> Scene::resizeRootOnSceneSizeChange 256.0, 33.0 >> ... >> Scene::resizeRootOnSceneSizeChange 256.0, 33.14285659790039 >> ... >> Scene::resizeRootOnSceneSizeChange 257.1428571428571, 33.14285714285714 >> ... >> Scene::resizeRootOnSceneSizeChange 257.1428571428571, 33.14285714285714 >> ... >> both width and height have stable snapped values, and the checkbox layout is correct. >> >> Back to the 256.0 value of width, this value comes from margin (8.0 * 2) + controls width(54.0 * 4) + spacing (8.0 * 3), but the value 54.0 is not properly computed, as at this point the UI scale is still 1.0. >> Once the UI scale is set to 1.75 the checkBox width is 54.285714285714285, and the scene's width is 257.14285714285714. >> >> So the issue can be related to the UI scale value taken into account too late, and how this change doesn't trigger an update of the scene. >> >> Does it make sense to address this issue with the current PR? > > thanks for the additional info - good dig ?? > > As you noted, there are two issues: > > - the implementation of the scaled snaps to make them stable (against nested calls) BTW, any reason snappedXXInset are not scaled? > - a timing/sequence issue with applying the scale > > So might separate them out in different issues, the first with a new one with this PR fixing it. Depends a bit on granularity of issues - personally, would prefer it, though, if only to make snapping issues more prominent. OK, https://bugs.openjdk.java.net/browse/JDK-8255415 has been filed (and the current PR targets that issue). https://bugs.openjdk.java.net/browse/JDK-8199592 will remain open until a fix for using the correct UI scale to perform the preferred size calculations is proposed. ------------- PR: https://git.openjdk.java.net/jfx/pull/336 From kcr at openjdk.java.net Mon Oct 26 23:25:21 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 26 Oct 2020 23:25:21 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v10] In-Reply-To: References: Message-ID: On Sun, 25 Oct 2020 13:24:44 GMT, Florian Kirmaier wrote: >> It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 >> >> I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. >> >> It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. >> I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but the tests with JMemoryBuddy are basically always correct. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8244297 > Added some more whitespaces based on review Thanks for making the suggested changes. I left one more comment inline and a couple very minor points (which I only mention as something you might want to fix when you take care of the one issue I raised). The rest looks good. I see that you modified the InitialNodesMemoryLeakTest to use JMemeoryBuddy. In order to verify that the assertions are working, I injected an error by reverting the fix for the [JDK-8216377](URL). The modified test still correctly catches the bug: $ gradle --info -PFULL_TEST=true cleanTest :systemTests:test --tests InitialNodesMemoryLeakTest ... test.javafx.scene.InitialNodesMemoryLeakTest > testRootNodeMemoryLeak STANDARD_OUT No Heapdump was created. You might want to change the configuration to get a HeapDump. Gradle Test Executor 1 finished executing tests. > Task :systemTests:test FAILED test.javafx.scene.InitialNodesMemoryLeakTest > testRootNodeMemoryLeak FAILED java.lang.AssertionError: Content of WeakReference was not collected. content: Group at 149ab2ce at test.util.memory.JMemoryBuddy.assertCollectable(JMemoryBuddy.java:91) at test.javafx.scene.InitialNodesMemoryLeakTest.testRootNodeMemoryLeak(InitialNodesMemoryLeakTest.java:89) 1 test completed, 1 failed Good. modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 134: > 132: > 133: /** > 134: * Checks whether the content of the WeakReference can not be collected. Minor: cannot is one word. modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 150: > 148: public static boolean checkNotCollectable(WeakReference weakReference) { > 149: createGarbage(); > 150: System.gc(); I recommend calling `System.runFinalization();` here. Also, do you think there is value in checking in a loop? Or is that overkill? One drawback of checking in a loop for the negative case is that you end up going through the loop all the way to the end in the expected case where a reference is not collectable, so it might be best to leave it as a single check as you have done. modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 216: > 214: } > 215: > 216: Minor: there are extra blank lines here. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From kcr at openjdk.java.net Tue Oct 27 00:06:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 27 Oct 2020 00:06:14 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 08:32:59 GMT, Jose Pereda wrote: > As discussed in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an already snapped value (either intentionally or by mistake), the result should be the same, otherwise we'll be jumping unnecessary from a valid pixel to another pixel. > > This PR provides a fix to `snapSizeXX` methods used in `Region`, which ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value before ceiling, to ensure snapping a snapped value gives the same value. > > A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 different UI scales is provided. > For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. Only for 1.75 and the random 1.374562997 value fails (the test fails for around 2% of the values with 1.75 and around 10% with 1.374562997). > With the proposed fix, it doesn't fail at all. Looks good. I can confirm that this fixes the problem of `snapSizeXY(snapSizeXY(val)) != snapSizeXY(val)` and that it fixes the test case from [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592) when `sizeToScene` is called (as noted above this is a fix for one of the two underlying problems). I also verified that the new test will catch the bug. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/336 From kcr at openjdk.java.net Tue Oct 27 00:45:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 27 Oct 2020 00:45:18 GMT Subject: RFR: 8254049: Update WebView to public suffix list 2020-04-24 In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 04:29:13 GMT, Arun Joseph wrote: > We should use the public_suffix_list.dat file in the JDK instead. Reading the public_suffix_list.dat file is modified to be similar to [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). If the file is not present, `isPublicSuffix()` returns `false`, which is similar to how WebKit ignores the public suffix check when it is disabled. > > Test: Run PublicSuffixesTest.java I haven't done an exhaustive review yet, but it generally seems to work. I left a few questions below. modules/javafx.web/src/main/java/com/sun/webkit/network/PublicSuffixes.java line 69: > 67: * The mapping from domain names to public suffix list rules. > 68: */ > 69: private static final Map rulesCache = new ConcurrentHashMap<>(); I'm not sure that this needs to be concurrent, especially if you initialize it in a static init block (see my comment below). modules/javafx.web/src/main/java/com/sun/webkit/network/PublicSuffixes.java line 132: > 130: return null; > 131: } > 132: return rulesCache.computeIfAbsent(tld, k -> createRules(tld)); If the public_suffixes file cannot be loaded (for example, if it is removed from the JDK), then this causes a warning to be logged on every call to this (basically on every load of any web site). It might be better to call `createRules` from a static init block. modules/javafx.web/src/main/java/com/sun/webkit/network/PublicSuffixes.java line 89: > 87: > 88: Rules rules = Rules.getRules(domain); > 89: return rules == null ? false : rules.match(domain); This will return `false` if there is no `public_suffix_list.dat` file or if there is an error parsing it. Can you confirm that this is the desired fallback behavior? ------------- PR: https://git.openjdk.java.net/jfx/pull/324 From aghaisas at openjdk.java.net Tue Oct 27 05:45:20 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 27 Oct 2020 05:45:20 GMT Subject: RFR: 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException In-Reply-To: <8RGHmndopjRYkCjt3PFYfpCA0Qhy8yp0q4P3KNzHZY8=.ab19efa4-59cb-4304-bac6-c84067ad1493@github.com> References: <8RGHmndopjRYkCjt3PFYfpCA0Qhy8yp0q4P3KNzHZY8=.ab19efa4-59cb-4304-bac6-c84067ad1493@github.com> Message-ID: On Fri, 23 Oct 2020 15:44:43 GMT, Jeanette Winzenburg wrote: >> This is a test fix. >> >> Root cause: >> - For ButtonTest - Incorrect use of MouseEventFirer - which puts Button on to the stage and shows it before firing mouse event >> - For ComboBoxTest - adding ComboBox to a Stage, not showing the Stage but trying to show the ComboBox >> >> >> Fix : >> - For ButtonTest - Moved MouseEventFirer usage from test class to the 2 tests that need it >> - For ComboBoxTest - Started using StageLoader (which adds comboBox to the stage and shows it) instead of separate Scene and Stage creation. >> >> >> I have attached the logs captured before and after this fix to the JBS. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ButtonTest.java line 425: > >> 423: >> 424: mouse.dispose(); >> 425: } > > just curious: do we have to dispose the mouseFirer? If so, that pattern isn't safe because it will not happen if the test fails. Hmm.. very good point. I believe, we should use dispose mechanism whenever available for a readable cleanup. Both classes MouseEventFirer & StageLoader provide dispose method and the user of these classes should use it. Now, this can be handled in two ways - 1) Keep a reference at test class level - it will be null by default - individual tests will create the object and update the class reference - we can dispose in cleanup method after the test 2) Use Try blocks in tests that use MouseEventFirerer or StageLoader objects and dispose them in finally{} blocks. We can use (1) if many tests in a test class use MouseEventFirerer or StageLoader objects - for example ComboBoxTest and use approach (2) if very few tests use these classes - for example ButtonTest. > modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 658: > >> 656: StageLoader sl = new StageLoader(comboBox); >> 657: >> 658: > > good catch :) But wouldn't show the stage have the same effect? (It's just me having a personal dislike of stageloader :) stage.show() has the same effect of fixing the bug. In fact, I fixed it initially with exact this fix. When I looked at the other tests in ComboBoxTest class, I saw that there is a pattern of creating a Stage, creating a Scene with ComboBox and then adding Scene to the Stage. What was missed was stage.show(). The StageLoader does exactly these steps (including the missed stage.show()). StageLoader might be a misfit at some of the other places in our tests (I believe that is the reason for your dislike), but I feel using StageLoader is a better fit in ComboBoxTest. ------------- PR: https://git.openjdk.java.net/jfx/pull/337 From ajit.ghaisas at oracle.com Tue Oct 27 08:57:48 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 27 Oct 2020 14:27:48 +0530 Subject: CFV: New OpenJFX Committer: Pankaj Bansal In-Reply-To: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> References: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> Message-ID: <34DFED09-08DD-4974-A975-354D3B4DF0B2@oracle.com> Vote: YES Regards, Ajit > On 23-Oct-2020, at 8:08 PM, Kevin Rushforth wrote: > > I hereby nominate Pankaj Bansal [1] to OpenJFX Committer. > > Pankaj is a member of Java client team at Oracle, who has contributed 11 commits [2] to OpenJFX. > > Votes are due by November 6, 2020. > > Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. > > Thanks. > > -- Kevin > > [1] https://openjdk.java.net/census#pbansal > > [2] https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Pankaj+Bansal%22&type=commits > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From fastegal at openjdk.java.net Tue Oct 27 10:21:16 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 27 Oct 2020 10:21:16 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 00:03:18 GMT, Kevin Rushforth wrote: >> As discussed in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an already snapped value (either intentionally or by mistake), the result should be the same, otherwise we'll be jumping unnecessary from a valid pixel to another pixel. >> >> This PR provides a fix to `snapSizeXX` methods used in `Region`, which ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value before ceiling, to ensure snapping a snapped value gives the same value. >> >> A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 different UI scales is provided. >> For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. Only for 1.75 and the random 1.374562997 value fails (the test fails for around 2% of the values with 1.75 and around 10% with 1.374562997). >> With the proposed fix, it doesn't fail at all. > > Looks good. > > I can confirm that this fixes the problem of `snapSizeXY(snapSizeXY(val)) != snapSizeXY(val)` and that it fixes the test case from [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592) when `sizeToScene` is called (as noted above this is a fix for one of the two underlying problems). > > I also verified that the new test will catch the bug. wondering about other places where scaled ceiling is used, f.i. snapPortion (which is package private and only used in HBox/VBox) - could they have the same problem? ------------- PR: https://git.openjdk.java.net/jfx/pull/336 From fastegal at openjdk.java.net Tue Oct 27 10:21:20 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 27 Oct 2020 10:21:20 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 08:32:59 GMT, Jose Pereda wrote: > As discussed in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an already snapped value (either intentionally or by mistake), the result should be the same, otherwise we'll be jumping unnecessary from a valid pixel to another pixel. > > This PR provides a fix to `snapSizeXX` methods used in `Region`, which ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value before ceiling, to ensure snapping a snapped value gives the same value. > > A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 different UI scales is provided. > For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. Only for 1.75 and the random 1.374562997 value fails (the test fails for around 2% of the values with 1.75 and around 10% with 1.374562997). > With the proposed fix, it doesn't fail at all. modules/javafx.graphics/src/test/java/test/javafx/scene/layout/RegionTest.java line 1256: > 1254: > 1255: // Test for JDK-8199592 > 1256: @Test public void snappingASnappedValueGivesTheSameValueTest() { code comment still pointing to old issue :) ------------- PR: https://git.openjdk.java.net/jfx/pull/336 From fastegal at openjdk.java.net Tue Oct 27 10:26:21 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 27 Oct 2020 10:26:21 GMT Subject: RFR: 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException In-Reply-To: References: <8RGHmndopjRYkCjt3PFYfpCA0Qhy8yp0q4P3KNzHZY8=.ab19efa4-59cb-4304-bac6-c84067ad1493@github.com> Message-ID: On Tue, 27 Oct 2020 05:32:47 GMT, Ajit Ghaisas wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/ButtonTest.java line 425: >> >>> 423: >>> 424: mouse.dispose(); >>> 425: } >> >> just curious: do we have to dispose the mouseFirer? If so, that pattern isn't safe because it will not happen if the test fails. > > Hmm.. very good point. I believe, we should use dispose mechanism whenever available for a readable cleanup. Both classes MouseEventFirer & StageLoader provide dispose method and the user of these classes should use it. > Now, this can be handled in two ways - > 1) Keep a reference at test class level - it will be null by default - individual tests will create the object and update the class reference - we can dispose in cleanup method after the test > 2) Use Try blocks in tests that use MouseEventFirerer or StageLoader objects and dispose them in finally{} blocks. > > We can use (1) if many tests in a test class use MouseEventFirerer or StageLoader objects - for example ComboBoxTest and use approach (2) if very few tests use these classes - for example ButtonTest. makes sense :) ------------- PR: https://git.openjdk.java.net/jfx/pull/337 From rajath.kamath at oracle.com Tue Oct 27 10:28:15 2020 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Tue, 27 Oct 2020 03:28:15 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Pankaj Bansal In-Reply-To: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> References: <28097709-a98d-6570-eabc-52375bc2ea98@oracle.com> Message-ID: Vote: YES -----Original Message----- From: Kevin Rushforth Sent: Friday, October 23, 2020 8:08 PM To: openjfx-dev at openjdk.java.net Subject: CFV: New OpenJFX Committer: Pankaj Bansal I hereby nominate Pankaj Bansal [1] to OpenJFX Committer. Pankaj is a member of Java client team at Oracle, who has contributed 11 commits [2] to OpenJFX. Votes are due by November 6, 2020. Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. Thanks. -- Kevin [1] https://openjdk.java.net/census#pbansal [2] https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Pankaj+Bansal%22&type=commits [3] http://openjdk.java.net/census#openjfx [4] http://openjdk.java.net/bylaws#lazy-consensus [5] http://openjdk.java.net/projects#project-committer From fastegal at openjdk.java.net Tue Oct 27 10:34:19 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 27 Oct 2020 10:34:19 GMT Subject: RFR: 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException In-Reply-To: References: <8RGHmndopjRYkCjt3PFYfpCA0Qhy8yp0q4P3KNzHZY8=.ab19efa4-59cb-4304-bac6-c84067ad1493@github.com> Message-ID: On Tue, 27 Oct 2020 05:41:02 GMT, Ajit Ghaisas wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 658: >> >>> 656: StageLoader sl = new StageLoader(comboBox); >>> 657: >>> 658: >> >> good catch :) But wouldn't show the stage have the same effect? (It's just me having a personal dislike of stageloader :) > > stage.show() has the same effect of fixing the bug. In fact, I fixed it initially with exact this fix. > > When I looked at the other tests in ComboBoxTest class, I saw that there is a pattern of creating a Stage, creating a Scene with ComboBox and then adding Scene to the Stage. What was missed was stage.show(). The StageLoader does exactly these steps (including the missed stage.show()). > StageLoader might be a misfit at some of the other places in our tests (I believe that is the reason for your dislike), but I feel using StageLoader is a better fit in ComboBoxTest. thanks! Wondering as to when/why Stageloader might be a misfit? I completely gave up on using it a while ago, so don't really remember *cough ------------- PR: https://git.openjdk.java.net/jfx/pull/337 From jpereda at openjdk.java.net Tue Oct 27 10:38:34 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 27 Oct 2020 10:38:34 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results [v2] In-Reply-To: References: Message-ID: > As discussed in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an already snapped value (either intentionally or by mistake), the result should be the same, otherwise we'll be jumping unnecessary from a valid pixel to another pixel. > > This PR provides a fix to `snapSizeXX` methods used in `Region`, which ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value before ceiling, to ensure snapping a snapped value gives the same value. > > A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 different UI scales is provided. > For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. Only for 1.75 and the random 1.374562997 value fails (the test fails for around 2% of the values with 1.75 and around 10% with 1.374562997). > With the proposed fix, it doesn't fail at all. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Update JBS reference in RegionTest ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/336/files - new: https://git.openjdk.java.net/jfx/pull/336/files/ee0dafc7..5ff5fcce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=336&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=336&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/336.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/336/head:pull/336 PR: https://git.openjdk.java.net/jfx/pull/336 From jpereda at openjdk.java.net Tue Oct 27 10:38:35 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 27 Oct 2020 10:38:35 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results [v2] In-Reply-To: References: Message-ID: <_iGvHOjWmADmhAzOtwz3Z4gkQY03QZMhgXn2z0ky4aY=.8b44128a-2cc9-43d1-855f-44d85bafe2cb@github.com> On Tue, 27 Oct 2020 10:16:19 GMT, Jeanette Winzenburg wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Update JBS reference in RegionTest > > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/RegionTest.java line 1256: > >> 1254: >> 1255: // Test for JDK-8199592 >> 1256: @Test public void snappingASnappedValueGivesTheSameValueTest() { > > code comment still pointing to old issue :) Fixed ------------- PR: https://git.openjdk.java.net/jfx/pull/336 From jpereda at openjdk.java.net Tue Oct 27 10:43:22 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 27 Oct 2020 10:43:22 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results [v2] In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 10:18:26 GMT, Jeanette Winzenburg wrote: >> Looks good. >> >> I can confirm that this fixes the problem of `snapSizeXY(snapSizeXY(val)) != snapSizeXY(val)` and that it fixes the test case from [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592) when `sizeToScene` is called (as noted above this is a fix for one of the two underlying problems). >> >> I also verified that the new test will catch the bug. > > wondering about other places where scaled ceiling is used, f.i. snapPortion (which is package private and only used in HBox/VBox) - could they have the same problem? @kleopatra That's a good question. I already saw it, but given it has private/package private access in a public class, simply trying to test it would imply creating a public access to snapPortionXX. I guess that is out of scope for now? ------------- PR: https://git.openjdk.java.net/jfx/pull/336 From fastegal at openjdk.java.net Tue Oct 27 10:44:20 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 27 Oct 2020 10:44:20 GMT Subject: RFR: 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException In-Reply-To: References: <8RGHmndopjRYkCjt3PFYfpCA0Qhy8yp0q4P3KNzHZY8=.ab19efa4-59cb-4304-bac6-c84067ad1493@github.com> Message-ID: On Tue, 27 Oct 2020 10:23:39 GMT, Jeanette Winzenburg wrote: >> Hmm.. very good point. I believe, we should use dispose mechanism whenever available for a readable cleanup. Both classes MouseEventFirer & StageLoader provide dispose method and the user of these classes should use it. >> Now, this can be handled in two ways - >> 1) Keep a reference at test class level - it will be null by default - individual tests will create the object and update the class reference - we can dispose in cleanup method after the test >> 2) Use Try blocks in tests that use MouseEventFirerer or StageLoader objects and dispose them in finally{} blocks. >> >> We can use (1) if many tests in a test class use MouseEventFirerer or StageLoader objects - for example ComboBoxTest and use approach (2) if very few tests use these classes - for example ButtonTest. > > makes sense :) just looked at MouseEventFirer (a bit late, sry ;): all it does is to dispose the Stageloader it created (if it received a bare node) - so if we add a node to a stage and/or wrap it into our own loader, we don't really need to dispose the firer (though it doesn't hurt except a very minimal code clutter) ------------- PR: https://git.openjdk.java.net/jfx/pull/337 From jvos at openjdk.java.net Tue Oct 27 10:47:23 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 27 Oct 2020 10:47:23 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results [v2] In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 10:38:34 GMT, Jose Pereda wrote: >> As discussed in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an already snapped value (either intentionally or by mistake), the result should be the same, otherwise we'll be jumping unnecessary from a valid pixel to another pixel. >> >> This PR provides a fix to `snapSizeXX` methods used in `Region`, which ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value before ceiling, to ensure snapping a snapped value gives the same value. >> >> A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 different UI scales is provided. >> For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. Only for 1.75 and the random 1.374562997 value fails (the test fails for around 2% of the values with 1.75 and around 10% with 1.374562997). >> With the proposed fix, it doesn't fail at all. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Update JBS reference in RegionTest modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 303: > 301: } > 302: > 303: private static double scaledCeil(double value, double scale) { Can you explicitly add here that this method guarantees `scaledCeil(scaledCeil(val, scale), scale) == scaledCeil (val, scale)` It seems other code already assumed this, but it should not be taken for granted, so now that your fix assures this is the case, it can be taken for granted. ------------- PR: https://git.openjdk.java.net/jfx/pull/336 From fastegal at openjdk.java.net Tue Oct 27 10:53:16 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 27 Oct 2020 10:53:16 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results [v2] In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 10:39:42 GMT, Jose Pereda wrote: > > > @kleopatra That's a good question. > > I already saw it, but given it has private/package private access in a public class, simply trying to test it would imply creating a public access to snapPortionXX. > I guess that is out of scope for now? for testing, you can add an accessor to RegionShim (just did and it indeed seems to fail with the same setup as your test). ------------- PR: https://git.openjdk.java.net/jfx/pull/336 From jpereda at openjdk.java.net Tue Oct 27 11:16:19 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 27 Oct 2020 11:16:19 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results [v2] In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 10:50:26 GMT, Jeanette Winzenburg wrote: >> @kleopatra That's a good question. >> >> I already saw it, but given it has private/package private access in a public class, simply trying to test it would imply creating a public access to snapPortionXX. >> I guess that is out of scope for now? > >> >> >> @kleopatra That's a good question. >> >> I already saw it, but given it has private/package private access in a public class, simply trying to test it would imply creating a public access to snapPortionXX. >> I guess that is out of scope for now? > > for testing, you can add an accessor to RegionShim (just did and it indeed seems to fail with the same setup as your test). Ah, indeed, that helps, and I can see the failing tests too. I'll extend then this PR to those methods too (which still fall under the JBS title). ------------- PR: https://git.openjdk.java.net/jfx/pull/336 From jpereda at openjdk.java.net Tue Oct 27 11:16:23 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 27 Oct 2020 11:16:23 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results [v2] In-Reply-To: References: Message-ID: <9NDLDDTMq7FyV3zbr9Di4gboLnsEBIru59e8cnfNZpI=.4c1898b7-7c8e-429d-a768-7a359798199c@github.com> On Tue, 27 Oct 2020 10:44:00 GMT, Johan Vos wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Update JBS reference in RegionTest > > modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 303: > >> 301: } >> 302: >> 303: private static double scaledCeil(double value, double scale) { > > Can you explicitly add here that this method guarantees > `scaledCeil(scaledCeil(val, scale), scale) == scaledCeil (val, scale)` > > It seems other code already assumed this, but it should not be taken for granted, so now that your fix assures this is the case, it can be taken for granted. Ok, makes sense, I will add that. ------------- PR: https://git.openjdk.java.net/jfx/pull/336 From aghaisas at openjdk.java.net Tue Oct 27 11:35:28 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 27 Oct 2020 11:35:28 GMT Subject: RFR: 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException [v2] In-Reply-To: References: Message-ID: <5sWw_g4roW1RfUCI2zribIKr8yxPPHdJxabFF6dnJds=.a587beed-4642-495a-928c-1e5171ad31ff@github.com> > This is a test fix. > > Root cause: > - For ButtonTest - Incorrect use of MouseEventFirer - which puts Button on to the stage and shows it before firing mouse event > - For ComboBoxTest - adding ComboBox to a Stage, not showing the Stage but trying to show the ComboBox > > > Fix : > - For ButtonTest - Moved MouseEventFirer usage from test class to the 2 tests that need it > - For ComboBoxTest - Started using StageLoader (which adds comboBox to the stage and shows it) instead of separate Scene and Stage creation. > > > I have attached the logs captured before and after this fix to the JBS. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: review_fixes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/337/files - new: https://git.openjdk.java.net/jfx/pull/337/files/8a6fc1cf..4826d814 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=337&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=337&range=00-01 Stats: 151 lines in 2 files changed: 10 ins; 94 del; 47 mod Patch: https://git.openjdk.java.net/jfx/pull/337.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/337/head:pull/337 PR: https://git.openjdk.java.net/jfx/pull/337 From aghaisas at openjdk.java.net Tue Oct 27 11:35:29 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 27 Oct 2020 11:35:29 GMT Subject: RFR: 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException [v2] In-Reply-To: References: <8RGHmndopjRYkCjt3PFYfpCA0Qhy8yp0q4P3KNzHZY8=.ab19efa4-59cb-4304-bac6-c84067ad1493@github.com> Message-ID: <3gSitabEU7p4wuTa5auD4ek3oUuQxCWxoy3T1UpcBlA=.d6689554-5c36-4e66-a938-1e472e61d60f@github.com> On Tue, 27 Oct 2020 10:41:17 GMT, Jeanette Winzenburg wrote: >> makes sense :) > > just looked at MouseEventFirer (a bit late, sry ;): all it does is to dispose the Stageloader it created (if it received a bare node) - so if we add a node to a stage and/or wrap it into our own loader, we don't really need to dispose the firer (though it doesn't hurt except a very minimal code clutter) If we use our own loader - we would need to dispose that as well :) Also, I found approach (1) of using reference at test class level and cleaning it up in cleanup method after the test is more suitable as in ButtonTest, the assertion happens in event handler. Wrapping it in try..finally will need additional code. I will push the changes in a moment. ------------- PR: https://git.openjdk.java.net/jfx/pull/337 From fastegal at openjdk.java.net Tue Oct 27 11:40:20 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 27 Oct 2020 11:40:20 GMT Subject: RFR: 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException [v2] In-Reply-To: <3gSitabEU7p4wuTa5auD4ek3oUuQxCWxoy3T1UpcBlA=.d6689554-5c36-4e66-a938-1e472e61d60f@github.com> References: <8RGHmndopjRYkCjt3PFYfpCA0Qhy8yp0q4P3KNzHZY8=.ab19efa4-59cb-4304-bac6-c84067ad1493@github.com> <3gSitabEU7p4wuTa5auD4ek3oUuQxCWxoy3T1UpcBlA=.d6689554-5c36-4e66-a938-1e472e61d60f@github.com> Message-ID: On Tue, 27 Oct 2020 11:30:23 GMT, Ajit Ghaisas wrote: >> just looked at MouseEventFirer (a bit late, sry ;): all it does is to dispose the Stageloader it created (if it received a bare node) - so if we add a node to a stage and/or wrap it into our own loader, we don't really need to dispose the firer (though it doesn't hurt except a very minimal code clutter) > > If we use our own loader - we would need to dispose that as well :) > > Also, I found approach (1) of using reference at test class level and cleaning it up in cleanup method after the test is more suitable as in ButtonTest, the assertion happens in event handler. Wrapping it in try..finally will need additional code. > I will push the changes in a moment. nit-picking: we already do dispose our own loader (or cleanup our stage), don't we :) the change looks good ------------- PR: https://git.openjdk.java.net/jfx/pull/337 From aghaisas at openjdk.java.net Tue Oct 27 12:00:31 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 27 Oct 2020 12:00:31 GMT Subject: RFR: 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException [v2] In-Reply-To: References: <8RGHmndopjRYkCjt3PFYfpCA0Qhy8yp0q4P3KNzHZY8=.ab19efa4-59cb-4304-bac6-c84067ad1493@github.com> Message-ID: On Tue, 27 Oct 2020 10:31:48 GMT, Jeanette Winzenburg wrote: >> stage.show() has the same effect of fixing the bug. In fact, I fixed it initially with exact this fix. >> >> When I looked at the other tests in ComboBoxTest class, I saw that there is a pattern of creating a Stage, creating a Scene with ComboBox and then adding Scene to the Stage. What was missed was stage.show(). The StageLoader does exactly these steps (including the missed stage.show()). >> StageLoader might be a misfit at some of the other places in our tests (I believe that is the reason for your dislike), but I feel using StageLoader is a better fit in ComboBoxTest. > > thanks! > > Wondering as to when/why Stageloader might be a misfit? I completely gave up on using it a while ago, so don't really remember *cough It is not that StageLoader is bad as such. By misfit - I meant - error prone to be used in tests that already use their own Scene and Stage creation. ------------- PR: https://git.openjdk.java.net/jfx/pull/337 From aghaisas at openjdk.java.net Tue Oct 27 12:00:33 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 27 Oct 2020 12:00:33 GMT Subject: RFR: 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException [v2] In-Reply-To: References: <8RGHmndopjRYkCjt3PFYfpCA0Qhy8yp0q4P3KNzHZY8=.ab19efa4-59cb-4304-bac6-c84067ad1493@github.com> <3gSitabEU7p4wuTa5auD4ek3oUuQxCWxoy3T1UpcBlA=.d6689554-5c36-4e66-a938-1e472e61d60f@github.com> Message-ID: On Tue, 27 Oct 2020 11:37:40 GMT, Jeanette Winzenburg wrote: >> If we use our own loader - we would need to dispose that as well :) >> >> Also, I found approach (1) of using reference at test class level and cleaning it up in cleanup method after the test is more suitable as in ButtonTest, the assertion happens in event handler. Wrapping it in try..finally will need additional code. >> I will push the changes in a moment. > > nit-picking: we already do dispose our own loader (or cleanup our stage), don't we :) > > the change looks good Can you please mark it as Approved? ------------- PR: https://git.openjdk.java.net/jfx/pull/337 From fastegal at openjdk.java.net Tue Oct 27 12:11:21 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 27 Oct 2020 12:11:21 GMT Subject: RFR: 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException [v2] In-Reply-To: <5sWw_g4roW1RfUCI2zribIKr8yxPPHdJxabFF6dnJds=.a587beed-4642-495a-928c-1e5171ad31ff@github.com> References: <5sWw_g4roW1RfUCI2zribIKr8yxPPHdJxabFF6dnJds=.a587beed-4642-495a-928c-1e5171ad31ff@github.com> Message-ID: <9xNAiky-hIfjr9BIfe5yJcMXU90gXKRIvtpWnfmW6go=.b81a18c5-16b7-43ce-81c8-7f379d90f734@github.com> On Tue, 27 Oct 2020 11:35:28 GMT, Ajit Ghaisas wrote: >> This is a test fix. >> >> Root cause: >> - For ButtonTest - Incorrect use of MouseEventFirer - which puts Button on to the stage and shows it before firing mouse event >> - For ComboBoxTest - adding ComboBox to a Stage, not showing the Stage but trying to show the ComboBox >> >> >> Fix : >> - For ButtonTest - Moved MouseEventFirer usage from test class to the 2 tests that need it >> - For ComboBoxTest - Started using StageLoader (which adds comboBox to the stage and shows it) instead of separate Scene and Stage creation. >> >> >> I have attached the logs captured before and after this fix to the JBS. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > review_fixes fix looks good to me - approving, but probably will need a "real" reviewer :) ------------- Marked as reviewed by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/337 From github.com+10960818+schmidor at openjdk.java.net Tue Oct 27 12:12:29 2020 From: github.com+10960818+schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Tue, 27 Oct 2020 12:12:29 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v2] In-Reply-To: References: Message-ID: > When connecting via Remote Desktop to a Windows 10 machine ans starting a JavaFX application, the D3D pipeline is used successfully. > After closing the the Remote Desktop session and reconnecting, the D3D requests fail with an D3DERR_DEVICEREMOVED HResult, and the application contents are not rendered anymore. > Reinitializing the whole pipeline fixes that. Oliver Schmidtmer has updated the pull request incrementally with two additional commits since the last revision: - Ressource already freed from pool - Recreate if adapterCount is zero ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/315/files - new: https://git.openjdk.java.net/jfx/pull/315/files/501f5e28..651f960c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=315&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=315&range=00-01 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/315.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/315/head:pull/315 PR: https://git.openjdk.java.net/jfx/pull/315 From fastegal at openjdk.java.net Tue Oct 27 12:14:16 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 27 Oct 2020 12:14:16 GMT Subject: RFR: 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException [v2] In-Reply-To: References: <8RGHmndopjRYkCjt3PFYfpCA0Qhy8yp0q4P3KNzHZY8=.ab19efa4-59cb-4304-bac6-c84067ad1493@github.com> Message-ID: On Tue, 27 Oct 2020 11:57:03 GMT, Ajit Ghaisas wrote: >> thanks! >> >> Wondering as to when/why Stageloader might be a misfit? I completely gave up on using it a while ago, so don't really remember *cough > > It is not that StageLoader is bad as such. By misfit - I meant - error prone to be used in tests that already use their own Scene and Stage creation. ahh .. I see, thanks :) ------------- PR: https://git.openjdk.java.net/jfx/pull/337 From jpereda at openjdk.java.net Tue Oct 27 12:24:26 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 27 Oct 2020 12:24:26 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results [v3] In-Reply-To: References: Message-ID: <6qgJ8cuptggis721V9IHM1wwomIlQ4nVMB0QSHocFlI=.e7815b36-206d-4b9a-a3cf-1caa7423621c@github.com> > As discussed in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an already snapped value (either intentionally or by mistake), the result should be the same, otherwise we'll be jumping unnecessary from a valid pixel to another pixel. > > This PR provides a fix to `snapSizeXX` methods used in `Region`, which ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value before ceiling, to ensure snapping a snapped value gives the same value. > > A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 different UI scales is provided. > For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. Only for 1.75 and the random 1.374562997 value fails (the test fails for around 2% of the values with 1.75 and around 10% with 1.374562997). > With the proposed fix, it doesn't fail at all. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Add javadoc to scaledCeil ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/336/files - new: https://git.openjdk.java.net/jfx/pull/336/files/5ff5fcce..988afefb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=336&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=336&range=01-02 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/336.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/336/head:pull/336 PR: https://git.openjdk.java.net/jfx/pull/336 From jpereda at openjdk.java.net Tue Oct 27 12:49:31 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 27 Oct 2020 12:49:31 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results [v4] In-Reply-To: References: Message-ID: > As discussed in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an already snapped value (either intentionally or by mistake), the result should be the same, otherwise we'll be jumping unnecessary from a valid pixel to another pixel. > > This PR provides a fix to `snapSizeXX` methods used in `Region`, which ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value before ceiling, to ensure snapping a snapped value gives the same value. > > A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 different UI scales is provided. > For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. Only for 1.75 and the random 1.374562997 value fails (the test fails for around 2% of the values with 1.75 and around 10% with 1.374562997). > With the proposed fix, it doesn't fail at all. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Extend fix to scaledFloor, thought the method is currently unused. No tests will be provided. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/336/files - new: https://git.openjdk.java.net/jfx/pull/336/files/988afefb..216868f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=336&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=336&range=02-03 Stats: 11 lines in 1 file changed: 10 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/336.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/336/head:pull/336 PR: https://git.openjdk.java.net/jfx/pull/336 From jpereda at openjdk.java.net Tue Oct 27 12:56:28 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 27 Oct 2020 12:56:28 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results [v5] In-Reply-To: References: Message-ID: > As discussed in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an already snapped value (either intentionally or by mistake), the result should be the same, otherwise we'll be jumping unnecessary from a valid pixel to another pixel. > > This PR provides a fix to `snapSizeXX` methods used in `Region`, which ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value before ceiling, to ensure snapping a snapped value gives the same value. > > A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 different UI scales is provided. > For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. Only for 1.75 and the random 1.374562997 value fails (the test fails for around 2% of the values with 1.75 and around 10% with 1.374562997). > With the proposed fix, it doesn't fail at all. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Apply fix to snapPortionXX methods, extend test. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/336/files - new: https://git.openjdk.java.net/jfx/pull/336/files/216868f1..2b8e15eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=336&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=336&range=03-04 Stats: 58 lines in 3 files changed: 54 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/336.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/336/head:pull/336 PR: https://git.openjdk.java.net/jfx/pull/336 From kcr at openjdk.java.net Tue Oct 27 17:42:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 27 Oct 2020 17:42:15 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo In-Reply-To: References: <-eDYvRKiZp6S6De2i6Wq_KVFfPf5Ri99O3dYVo3H4r4=.83764206-2ca7-4ea1-a4b0-a918c363f343@github.com> Message-ID: On Mon, 26 Oct 2020 08:29:14 GMT, Robin Westberg wrote: >> The jdk workflow is split into a build job and multiple test jobs (since it takes so long they need the parallelism when running the tests). It's more complicated that way, since you have to feed the results of the build job into all of the test jobs, and there is duplication of some of the configuration steps. I don't know that it would buy us much, so I wasn't planning to split the jobs -- at leat not initially. >> >> The build and test are done in separate steps within the job so it's easy to see which one failed. Maybe Robin can comment further as to whether we could do something a bit more clever. > >> I noticed this in the openjdk/mobile repository as well, and that looks great. In that repository, there seems to be a different configuration, as there is a line for "build" and a line for "test/tier 1" ( e.g. [openjdk/mobile#10](https://github.com/openjdk/mobile/pull/10) ) >> >> I wonder how configurable this is? > > The output is not very configurable at all. :) You can see https://github.com/openjdk/skara/blob/bd4cc7e9a6ff7b04c6dc650a969638d5c1471031/bots/pr/src/main/java/org/openjdk/skara/bots/pr/TestResults.java#L42 for details. But it should support additional tiers at least if any were added in the future. ### Note to reviewers: If you want to test this yourself you can pull the PR branch into a branch in your local repo and push it to your personal fork. Something like the following should work for you, assuming that you are in your local repo with `origin` pointing to your personal fork: git fetch https://github.com/openjdk/jfx.git pull/338/head:pr-338 git push -u origin pr-338 Then you will be able to see the GitHub action workflow and track its progress by clicking on the "Actions" tab on your personal fork repo page. ------------- PR: https://git.openjdk.java.net/jfx/pull/338 From kcr at openjdk.java.net Tue Oct 27 19:05:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 27 Oct 2020 19:05:18 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo In-Reply-To: References: <-eDYvRKiZp6S6De2i6Wq_KVFfPf5Ri99O3dYVo3H4r4=.83764206-2ca7-4ea1-a4b0-a918c363f343@github.com> Message-ID: On Tue, 27 Oct 2020 17:39:08 GMT, Kevin Rushforth wrote: >>> I noticed this in the openjdk/mobile repository as well, and that looks great. In that repository, there seems to be a different configuration, as there is a line for "build" and a line for "test/tier 1" ( e.g. [openjdk/mobile#10](https://github.com/openjdk/mobile/pull/10) ) >>> >>> I wonder how configurable this is? >> >> The output is not very configurable at all. :) You can see https://github.com/openjdk/skara/blob/bd4cc7e9a6ff7b04c6dc650a969638d5c1471031/bots/pr/src/main/java/org/openjdk/skara/bots/pr/TestResults.java#L42 for details. But it should support additional tiers at least if any were added in the future. > > ### Note to reviewers: > > If you want to test this yourself you can pull the PR branch into a branch in your local repo and push it to your personal fork. Something like the following should work for you, assuming that you are in your local repo with `origin` pointing to your personal fork: > > git fetch https://github.com/openjdk/jfx.git pull/338/head:pr-338 > git push -u origin pr-338 > > Then you will be able to see the GitHub action workflow and track its progress by clicking on the "Actions" tab on your personal fork repo page. See PR #339 for an example (using an intentionally injected failure) of what a failed build or test will look like. ------------- PR: https://git.openjdk.java.net/jfx/pull/338 From fkirmaier at openjdk.java.net Tue Oct 27 19:27:25 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 27 Oct 2020 19:27:25 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v10] In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 22:49:41 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8244297 >> Added some more whitespaces based on review > > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 150: > >> 148: public static boolean checkNotCollectable(WeakReference weakReference) { >> 149: createGarbage(); >> 150: System.gc(); > > I recommend calling `System.runFinalization();` here. > > Also, do you think there is value in checking in a loop? Or is that overkill? One drawback of checking in a loop for the negative case is that you end up going through the loop all the way to the end in the expected case where a reference is not collectable, so it might be best to leave it as a single check as you have done. I've added runFinalization followed with another System.gc (otherwise it wouldn't make any difference) I'm quite sure it's avoiding an error in the library, but I don't have a unit-test for it yet. It's a tradeoff between speed and reliability. The library tries to avoid false-negative test results at all costs. false-positive results are tolerated for speed if they are "sufficiently reliable". The Library has tests for assertNotCollectable, which are executed with every commit for different JVM's, and I don't remember any false-positive results (which would be visible as a negative test result, because the unit-test checks for failing tests). For that reason, we can assume they are "sufficiently reliable" despite the theoretical problem. > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 216: > >> 214: } >> 215: >> 216: > > Minor: there are extra blank lines here. done ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From kcr at openjdk.java.net Tue Oct 27 20:43:22 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 27 Oct 2020 20:43:22 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v10] In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 19:24:35 GMT, Florian Kirmaier wrote: >> modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 150: >> >>> 148: public static boolean checkNotCollectable(WeakReference weakReference) { >>> 149: createGarbage(); >>> 150: System.gc(); >> >> I recommend calling `System.runFinalization();` here. >> >> Also, do you think there is value in checking in a loop? Or is that overkill? One drawback of checking in a loop for the negative case is that you end up going through the loop all the way to the end in the expected case where a reference is not collectable, so it might be best to leave it as a single check as you have done. > > I've added runFinalization followed with another System.gc (otherwise it wouldn't make any difference) > I'm quite sure it's avoiding an error in the library, but I don't have a unit-test for it yet. > > It's a tradeoff between speed and reliability. The library tries to avoid false-negative test results at all costs. > false-positive results are tolerated for speed if they are "sufficiently reliable". > The Library has tests for assertNotCollectable, which are executed with every commit for different JVM's, and I don't remember any false-positive results (which would be visible as a negative test result, because the unit-test checks for failing tests). For that reason, we can assume they are "sufficiently reliable" despite the theoretical problem. That sounds fine then. As soon as you've pushed the follow-on fix (to add the `runFinalization` and a second `gc`) I'll finish my review. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From kcr at openjdk.java.net Tue Oct 27 21:39:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 27 Oct 2020 21:39:17 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results [v5] In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 12:56:28 GMT, Jose Pereda wrote: >> As discussed in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an already snapped value (either intentionally or by mistake), the result should be the same, otherwise we'll be jumping unnecessary from a valid pixel to another pixel. >> >> This PR provides a fix to `snapSizeXX` methods used in `Region`, which ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value before ceiling, to ensure snapping a snapped value gives the same value. >> >> A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 different UI scales is provided. >> For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. Only for 1.75 and the random 1.374562997 value fails (the test fails for around 2% of the values with 1.75 and around 10% with 1.374562997). >> With the proposed fix, it doesn't fail at all. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Apply fix to snapPortionXX methods, extend test. The updated fix and test looks good and is more complete. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/336 From kcr at openjdk.java.net Tue Oct 27 22:00:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 27 Oct 2020 22:00:17 GMT Subject: RFR: 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException [v2] In-Reply-To: <5sWw_g4roW1RfUCI2zribIKr8yxPPHdJxabFF6dnJds=.a587beed-4642-495a-928c-1e5171ad31ff@github.com> References: <5sWw_g4roW1RfUCI2zribIKr8yxPPHdJxabFF6dnJds=.a587beed-4642-495a-928c-1e5171ad31ff@github.com> Message-ID: <3gNZr-QIdmLZlbxd7w9uMK-JfUK1txMPvg-1SuLlpq8=.330ce0f8-932c-4a38-bb47-e8b2be862e11@github.com> On Tue, 27 Oct 2020 11:35:28 GMT, Ajit Ghaisas wrote: >> This is a test fix. >> >> Root cause: >> - For ButtonTest - Incorrect use of MouseEventFirer - which puts Button on to the stage and shows it before firing mouse event >> - For ComboBoxTest - adding ComboBox to a Stage, not showing the Stage but trying to show the ComboBox >> >> >> Fix : >> - For ButtonTest - Moved MouseEventFirer usage from test class to the 2 tests that need it >> - For ComboBoxTest - Started using StageLoader (which adds comboBox to the stage and shows it) instead of separate Scene and Stage creation. >> >> >> I have attached the logs captured before and after this fix to the JBS. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > review_fixes Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/337 From kcr at openjdk.java.net Tue Oct 27 23:16:22 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 27 Oct 2020 23:16:22 GMT Subject: RFR: 8255487: Mark SandboxAppTest unstable on Windows Message-ID: This test is somewhat unstable on Windows. Even after the test timeout was increased to 25 seconds, it still times out on some Windows machines. The proposed fix is to mark this test unstable on Windows so our nightly build will not execute it and get frequent failures. It can still be run by passing `-PUNSTABLE_TEST=true` to gradle. For example: gradle --info -PUNSTABLE_TEST=true -PFULL_TEST=true cleanTest :systemTests:test --tests SandboxAppTest ------------- Commit messages: - 8255487: Mark SandboxAppTest unstable on Windows Changes: https://git.openjdk.java.net/jfx/pull/340/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=340&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255487 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/340.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/340/head:pull/340 PR: https://git.openjdk.java.net/jfx/pull/340 From aghaisas at openjdk.java.net Wed Oct 28 02:25:16 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 28 Oct 2020 02:25:16 GMT Subject: Integrated: 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 11:35:50 GMT, Ajit Ghaisas wrote: > This is a test fix. > > Root cause: > - For ButtonTest - Incorrect use of MouseEventFirer - which puts Button on to the stage and shows it before firing mouse event > - For ComboBoxTest - adding ComboBox to a Stage, not showing the Stage but trying to show the ComboBox > > > Fix : > - For ButtonTest - Moved MouseEventFirer usage from test class to the 2 tests that need it > - For ComboBoxTest - Started using StageLoader (which adds comboBox to the stage and shows it) instead of separate Scene and Stage creation. > > > I have attached the logs captured before and after this fix to the JBS. This pull request has now been integrated. Changeset: 690d2666 Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/690d2666 Stats: 156 lines in 2 files changed: 12 ins; 93 del; 51 mod 8255337: [TestBug] Controls unit tests - ButtonTest and ComboBoxTest - log ClassCastException Reviewed-by: fastegal, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/337 From aghaisas at openjdk.java.net Wed Oct 28 07:00:26 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 28 Oct 2020 07:00:26 GMT Subject: RFR: 8255497: [TestBug] Controls unit tests - clean up unnecessary prints on STANDARD_OUT Message-ID: This is a test cleanup task. More details in the JBS. ------------- Commit messages: - clear_stdout_prints Changes: https://git.openjdk.java.net/jfx/pull/341/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=341&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255497 Stats: 35 lines in 8 files changed: 2 ins; 15 del; 18 mod Patch: https://git.openjdk.java.net/jfx/pull/341.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/341/head:pull/341 PR: https://git.openjdk.java.net/jfx/pull/341 From fkirmaier at openjdk.java.net Wed Oct 28 09:47:32 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 28 Oct 2020 09:47:32 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v11] In-Reply-To: References: Message-ID: > It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 > > I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. > > It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. > I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but the tests with JMemoryBuddy are basically always correct. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8244297 more improvements based on code-review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/204/files - new: https://git.openjdk.java.net/jfx/pull/204/files/91bda93f..6ece3a7a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=204&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=204&range=09-10 Stats: 9 lines in 1 file changed: 3 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/204.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/204/head:pull/204 PR: https://git.openjdk.java.net/jfx/pull/204 From fkirmaier at openjdk.java.net Wed Oct 28 09:47:32 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 28 Oct 2020 09:47:32 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v10] In-Reply-To: References: Message-ID: <9oUOfku86NYH6aMXcFCppOcHWR01qsqGbwmkr3BIs18=.db0fa2ff-d864-462c-98e5-0bbabdd069a8@github.com> On Tue, 27 Oct 2020 20:40:23 GMT, Kevin Rushforth wrote: >> I've added runFinalization followed with another System.gc (otherwise it wouldn't make any difference) >> I'm quite sure it's avoiding an error in the library, but I don't have a unit-test for it yet. >> >> It's a tradeoff between speed and reliability. The library tries to avoid false-negative test results at all costs. >> false-positive results are tolerated for speed if they are "sufficiently reliable". >> The Library has tests for assertNotCollectable, which are executed with every commit for different JVM's, and I don't remember any false-positive results (which would be visible as a negative test result, because the unit-test checks for failing tests). For that reason, we can assume they are "sufficiently reliable" despite the theoretical problem. > > That sounds fine then. > > As soon as you've pushed the follow-on fix (to add the `runFinalization` and a second `gc`) I'll finish my review. I forgot to push my changes yesterday. They are pushed now! ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From arapte at openjdk.java.net Wed Oct 28 13:35:51 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 28 Oct 2020 13:35:51 GMT Subject: RFR: 8254013: gradle test should run all test classes even if they don't end with "Test" In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 11:45:08 GMT, Kevin Rushforth wrote: > The test targets in `build.gradle` are set up to run only classes whose name ends with exactly `Test`. A test class named `RunMyTest.java` will be run, but a test called `CheckSomething.java` will not be. This was done because gradle's built-in scanner for test classes was buggy in earlier versions of gradle. It seems to have been fixed in the gradle 3.x time frame from what I can tell. > > The current approach leads to two problems. The first is that gradle will try to execute all classes named `XxxxxTest.java` whether or not it should. Attempting to execute utility classes without test methods (meaning without at least one method annotated with `@Test`) or `abstract` classes (whether or not there are any test methods) will fail. > > The second is that a test class that isn't named `XxxxxTest.java` will not be run, even if it contains `@Test` methods. This can (and has) lead to tests being skipped when they should be run. > > The solution is to enable gradle's built-in scanning for test classes which works exactly like you would expect it to: it runs any concrete class that has at least one `@Test` method or whose parent class has such a method. This means that a class with no test methods that subclasses an abstract class with `@Test` methods will be run correctly. > > I ran a full test on all three platforms. The following test classes which were formerly not run are now run: > > modules/javafx.base: test.javafx.collections.ObservableListWithExtractor : 52 tests > modules/javafx.base: test.javafx.event.EventSerializationEventExists 0 tests (*) > modules/javafx.controls:. test.javafx.scene.control.MiscellaneousTests : 3 tests > tests/system: test.com.sun.javafx.application.SwingNoExit : 1 test > > They pass on all three platforms. > > (*) - There is only one test in this class and it is currently `@Ignore`d Looks good to me, verified that tests in files which are not suffixed with `Test` get executed now. buildSrc/build.gradle file also has the code that we are changing here, scanForTestClasses = false include "**/*Test.*" I think it won't affect as there are no tests there. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/329 From pbansal at openjdk.java.net Wed Oct 28 14:29:46 2020 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Wed, 28 Oct 2020 14:29:46 GMT Subject: RFR: 8254013: gradle test should run all test classes even if they don't end with "Test" In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 11:45:08 GMT, Kevin Rushforth wrote: > The test targets in `build.gradle` are set up to run only classes whose name ends with exactly `Test`. A test class named `RunMyTest.java` will be run, but a test called `CheckSomething.java` will not be. This was done because gradle's built-in scanner for test classes was buggy in earlier versions of gradle. It seems to have been fixed in the gradle 3.x time frame from what I can tell. > > The current approach leads to two problems. The first is that gradle will try to execute all classes named `XxxxxTest.java` whether or not it should. Attempting to execute utility classes without test methods (meaning without at least one method annotated with `@Test`) or `abstract` classes (whether or not there are any test methods) will fail. > > The second is that a test class that isn't named `XxxxxTest.java` will not be run, even if it contains `@Test` methods. This can (and has) lead to tests being skipped when they should be run. > > The solution is to enable gradle's built-in scanning for test classes which works exactly like you would expect it to: it runs any concrete class that has at least one `@Test` method or whose parent class has such a method. This means that a class with no test methods that subclasses an abstract class with `@Test` methods will be run correctly. > > I ran a full test on all three platforms. The following test classes which were formerly not run are now run: > > modules/javafx.base: test.javafx.collections.ObservableListWithExtractor : 52 tests > modules/javafx.base: test.javafx.event.EventSerializationEventExists 0 tests (*) > modules/javafx.controls:. test.javafx.scene.control.MiscellaneousTests : 3 tests > tests/system: test.com.sun.javafx.application.SwingNoExit : 1 test > > They pass on all three platforms. > > (*) - There is only one test in this class and it is currently `@Ignore`d Marked as reviewed by pbansal (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/329 From kcr at openjdk.java.net Wed Oct 28 14:35:42 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 28 Oct 2020 14:35:42 GMT Subject: Integrated: 8254013: gradle test should run all test classes even if they don't end with "Test" In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 11:45:08 GMT, Kevin Rushforth wrote: > The test targets in `build.gradle` are set up to run only classes whose name ends with exactly `Test`. A test class named `RunMyTest.java` will be run, but a test called `CheckSomething.java` will not be. This was done because gradle's built-in scanner for test classes was buggy in earlier versions of gradle. It seems to have been fixed in the gradle 3.x time frame from what I can tell. > > The current approach leads to two problems. The first is that gradle will try to execute all classes named `XxxxxTest.java` whether or not it should. Attempting to execute utility classes without test methods (meaning without at least one method annotated with `@Test`) or `abstract` classes (whether or not there are any test methods) will fail. > > The second is that a test class that isn't named `XxxxxTest.java` will not be run, even if it contains `@Test` methods. This can (and has) lead to tests being skipped when they should be run. > > The solution is to enable gradle's built-in scanning for test classes which works exactly like you would expect it to: it runs any concrete class that has at least one `@Test` method or whose parent class has such a method. This means that a class with no test methods that subclasses an abstract class with `@Test` methods will be run correctly. > > I ran a full test on all three platforms. The following test classes which were formerly not run are now run: > > modules/javafx.base: test.javafx.collections.ObservableListWithExtractor : 52 tests > modules/javafx.base: test.javafx.event.EventSerializationEventExists 0 tests (*) > modules/javafx.controls:. test.javafx.scene.control.MiscellaneousTests : 3 tests > tests/system: test.com.sun.javafx.application.SwingNoExit : 1 test > > They pass on all three platforms. > > (*) - There is only one test in this class and it is currently `@Ignore`d This pull request has now been integrated. Changeset: 4f1eb7dc Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/4f1eb7dc Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8254013: gradle test should run all test classes even if they don't end with "Test" Reviewed-by: arapte, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/329 From kcr at openjdk.java.net Wed Oct 28 14:43:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 28 Oct 2020 14:43:52 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo [v2] In-Reply-To: References: Message-ID: > This is a proposed fix for [JDK-8254691](https://bugs.openjdk.java.net/browse/JDK-8254691) to enable GitHub actions for the jfx repo. It is similar in purpose to what was done for the jdk repo. > > Once this is integrated, and subsequently merged into your personal fork, a GitHub Actions workflow will run on every push to any branch in your personal fork except a production branch (so that syncing the upstream `master` or `jfx*` branch won't cause a build) or any branch whose name that starts with `WIP`. > > The workflow does a build and (headless) test run on all three platforms: Linux, macOS, and Windows. The build is done without building the native media or WebKit libraries. Web tests are excluded. > > Here is the job that resulted from the most recent push to the `8254691-github-actions` branch in my personal fork: > > https://github.com/kevinrushforth/jfx/actions/runs/329355746 > > The workflow checks out the sources for the branch, downloads the boot JDK, installs the needed software packages, and then runs two build steps, `gradlew all` followed by `gradlew test -x :web:test`. > > The Skara tooling will process the results of the GitHub actions run, and show them in the **Testing** section of a pull request, as you can see below. > > Follow-on work: > > 1. Get BOOT JDK parameters from `build.properties`. Currently the location of the bootJDK is hardcoded in the [`submit.yml`](https://github.com/kevinrushforth/jfx/blob/8254691-github-actions/.github/workflows/submit.yml) file. This should be obtained from build.properties; we might need to add a couple more properties. > > 2. Check the shasum of the downloaded bootJDK and enable caching of the JDK (in order to save download time). This requires step 1 to be done first. > > 3. Locate the Visual Studio compiler on Windows. The location and version of the Microsoft Visual Studio 2019 compiler is hard-coded which will break if and when the GitHub build farm updates their Windows system. This will require making our build itself a little smarter, possibly using `vswhere`. 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 three additional commits since the last revision: - Merge branch 'master' into 8254691-github-actions - Ignore additional branches; minor cleanup - WIP: 8254691: Enable GitHub actions for jfx repo Initial working version on Linux, Mac, Windows ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/338/files - new: https://git.openjdk.java.net/jfx/pull/338/files/61044f67..b3e01031 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=338&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=338&range=00-01 Stats: 160 lines in 3 files changed: 12 ins; 93 del; 55 mod Patch: https://git.openjdk.java.net/jfx/pull/338.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/338/head:pull/338 PR: https://git.openjdk.java.net/jfx/pull/338 From kcr at openjdk.java.net Wed Oct 28 14:43:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 28 Oct 2020 14:43:53 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo In-Reply-To: References: <-eDYvRKiZp6S6De2i6Wq_KVFfPf5Ri99O3dYVo3H4r4=.83764206-2ca7-4ea1-a4b0-a918c363f343@github.com> Message-ID: <_alqlXdOH8kscy1h6Gr8bg1GFu3yOD6vCaqgENfaraw=.de21bebb-1c83-48e9-8c25-98e21933ec98@github.com> On Tue, 27 Oct 2020 19:02:40 GMT, Kevin Rushforth wrote: >> ### Note to reviewers: >> >> If you want to test this yourself you can pull the PR branch into a branch in your local repo and push it to your personal fork. Something like the following should work for you, assuming that you are in your local repo with `origin` pointing to your personal fork: >> >> git fetch https://github.com/openjdk/jfx.git pull/338/head:pr-338 >> git push -u origin pr-338 >> >> Then you will be able to see the GitHub action workflow and track its progress by clicking on the "Actions" tab on your personal fork repo page. > > See PR #339 for an example (using an intentionally injected failure) of what a failed build or test will look like. I merged `master` into my local branch so it would run the tests again on an up-to-date repo. ------------- PR: https://git.openjdk.java.net/jfx/pull/338 From kcr at openjdk.java.net Wed Oct 28 15:03:54 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 28 Oct 2020 15:03:54 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v11] In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 09:47:32 GMT, Florian Kirmaier wrote: >> It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 >> >> I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. >> >> It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. >> I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but the tests with JMemoryBuddy are basically always correct. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8244297 > more improvements based on code-review Looks good! ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/204 From kcr at openjdk.java.net Wed Oct 28 15:19:41 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 28 Oct 2020 15:19:41 GMT Subject: RFR: 8255497: [TestBug] Controls unit tests - clean up unnecessary prints on STANDARD_OUT In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 06:55:49 GMT, Ajit Ghaisas wrote: > This is a test cleanup task. More details in the JBS. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/341 From aghaisas at openjdk.java.net Wed Oct 28 15:54:43 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 28 Oct 2020 15:54:43 GMT Subject: Integrated: 8255497: [TestBug] Controls unit tests - clean up unnecessary prints on STANDARD_OUT In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 06:55:49 GMT, Ajit Ghaisas wrote: > This is a test cleanup task. More details in the JBS. This pull request has now been integrated. Changeset: 7da928b2 Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/7da928b2 Stats: 35 lines in 8 files changed: 2 ins; 15 del; 18 mod 8255497: [TestBug] Controls unit tests - clean up unnecessary prints on STANDARD_OUT Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/341 From aghaisas at openjdk.java.net Thu Oct 29 06:46:40 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 29 Oct 2020 06:46:40 GMT Subject: RFR: 8255487: Mark SandboxAppTest unstable on Windows In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 23:11:44 GMT, Kevin Rushforth wrote: > This test is somewhat unstable on Windows. Even after the test timeout was increased to 25 seconds, it still times out on some Windows machines. > > The proposed fix is to mark this test unstable on Windows so our nightly build will not execute it and get frequent failures. It can still be run by passing `-PUNSTABLE_TEST=true` to gradle. For example: > > gradle --info -PUNSTABLE_TEST=true -PFULL_TEST=true cleanTest :systemTests:test --tests SandboxAppTest Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/340 From johan.vos at gluonhq.com Thu Oct 29 10:53:20 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 29 Oct 2020 11:53:20 +0100 Subject: RFR: 8255586: Change JavaFX release version in 11-dev to 11.0.10 Message-ID: Hi Kevin, Please review the webrev at http://cr.openjdk.java.net/~jvos/8255586/webrev.00/ which bumps the security version in JavaFX to 11.0.10 Fix for https://bugs.openjdk.java.net/browse/JDK-8255586 Thanks, - Johan From kcr at openjdk.java.net Thu Oct 29 11:42:42 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 29 Oct 2020 11:42:42 GMT Subject: Integrated: 8255487: Mark SandboxAppTest unstable on Windows In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 23:11:44 GMT, Kevin Rushforth wrote: > This test is somewhat unstable on Windows. Even after the test timeout was increased to 25 seconds, it still times out on some Windows machines. > > The proposed fix is to mark this test unstable on Windows so our nightly build will not execute it and get frequent failures. It can still be run by passing `-PUNSTABLE_TEST=true` to gradle. For example: > > gradle --info -PUNSTABLE_TEST=true -PFULL_TEST=true cleanTest :systemTests:test --tests SandboxAppTest This pull request has now been integrated. Changeset: 0376e602 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/0376e602 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod 8255487: Mark SandboxAppTest unstable on Windows Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/340 From kevin.rushforth at oracle.com Thu Oct 29 11:50:32 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 29 Oct 2020 04:50:32 -0700 Subject: RFR: 8255586: Change JavaFX release version in 11-dev to 11.0.10 In-Reply-To: References: Message-ID: +1 On 10/29/2020 3:53 AM, Johan Vos wrote: > Hi Kevin, > > Please review the webrev at > http://cr.openjdk.java.net/~jvos/8255586/webrev.00/ which bumps the > security version in JavaFX to 11.0.10 > Fix for https://bugs.openjdk.java.net/browse/JDK-8255586 > > Thanks, > > - Johan From johan.vos at gluonhq.com Thu Oct 29 13:33:09 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 29 Oct 2020 14:33:09 +0100 Subject: Request to backport issues to JavaFX 11 (for 11.0.10) Message-ID: Hi Kevin, I request permission to backport the following issues to JavaFX 11: JDK-8178297: TableView scrolls slightly when adding new elements JDK-8252811: The list of cells in a VirtualFlow is cleared every time the number of items changes - Johan From kevin.rushforth at oracle.com Thu Oct 29 13:56:31 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 29 Oct 2020 06:56:31 -0700 Subject: Request to backport issues to JavaFX 11 (for 11.0.10) In-Reply-To: References: Message-ID: <7e9c6896-01f3-20d4-9a2a-f8a2d169a67c@oracle.com> Approved. -- Kevin On 10/29/2020 6:33 AM, Johan Vos wrote: > Hi Kevin, > > I request permission to backport the following issues to JavaFX 11: > > JDK-8178297: TableView scrolls slightly when adding new elements > JDK-8252811: The list of cells in a VirtualFlow is cleared every time the > number of items changes > > - Johan From johan.vos at gluonhq.com Thu Oct 29 16:36:32 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 29 Oct 2020 17:36:32 +0100 Subject: Request to backport JDK-8197536 to JavaFX 11 (for 11.0.10) Message-ID: Hi Kevin, I request permission to also backport the following issue to JavaFX 11: JDK-8197536 TableView, ListView: unexpected scrolling behaviour on up/down keys Thanks, - Johan From kevin.rushforth at oracle.com Thu Oct 29 16:41:26 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 29 Oct 2020 09:41:26 -0700 Subject: Request to backport JDK-8197536 to JavaFX 11 (for 11.0.10) In-Reply-To: References: Message-ID: Approved. On 10/29/2020 9:36 AM, Johan Vos wrote: > Hi Kevin, > > I request permission to also backport the following issue to JavaFX 11: > > JDK-8197536 TableView, ListView: unexpected scrolling behaviour on up/down > keys > > Thanks, > > - Johan From arapte at openjdk.java.net Thu Oct 29 18:33:45 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 29 Oct 2020 18:33:45 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo [v2] In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 14:43:52 GMT, Kevin Rushforth wrote: >> This is a proposed fix for [JDK-8254691](https://bugs.openjdk.java.net/browse/JDK-8254691) to enable GitHub actions for the jfx repo. It is similar in purpose to what was done for the jdk repo. >> >> Once this is integrated, and subsequently merged into your personal fork, a GitHub Actions workflow will run on every push to any branch in your personal fork except a production branch (so that syncing the upstream `master` or `jfx*` branch won't cause a build) or any branch whose name that starts with `WIP`. >> >> The workflow does a build and (headless) test run on all three platforms: Linux, macOS, and Windows. The build is done without building the native media or WebKit libraries. Web tests are excluded. >> >> Here is the job that resulted from the most recent push to the `8254691-github-actions` branch in my personal fork: >> >> https://github.com/kevinrushforth/jfx/actions/runs/329355746 >> >> The workflow checks out the sources for the branch, downloads the boot JDK, installs the needed software packages, and then runs two build steps, `gradlew all` followed by `gradlew test -x :web:test`. >> >> The Skara tooling will process the results of the GitHub actions run, and show them in the **Testing** section of a pull request, as you can see below. >> >> Follow-on work: >> >> 1. Get BOOT JDK parameters from `build.properties`. Currently the location of the bootJDK is hardcoded in the [`submit.yml`](https://github.com/kevinrushforth/jfx/blob/8254691-github-actions/.github/workflows/submit.yml) file. This should be obtained from build.properties; we might need to add a couple more properties. >> >> 2. Check the shasum of the downloaded bootJDK and enable caching of the JDK (in order to save download time). This requires step 1 to be done first. >> >> 3. Locate the Visual Studio compiler on Windows. The location and version of the Microsoft Visual Studio 2019 compiler is hard-coded which will break if and when the GitHub build farm updates their Windows system. This will require making our build itself a little smarter, possibly using `vswhere`. > > 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 three additional commits since the last revision: > > - Merge branch 'master' into 8254691-github-actions > - Ignore additional branches; minor cleanup > - WIP: 8254691: Enable GitHub actions for jfx repo > > Initial working version on Linux, Mac, Windows Looks good to me. Verified a dummy PR with two commits. Actions executed correctly on both commits. Also verified that test failure is reported correctly and failed test can be found in log under Actions section. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/338 From arapte at openjdk.java.net Fri Oct 30 09:48:48 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 30 Oct 2020 09:48:48 GMT Subject: RFR: 8244297: Provide utility for testing for memory leaks [v11] In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 09:47:32 GMT, Florian Kirmaier wrote: >> It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 >> >> I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. >> >> It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. >> I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but the tests with JMemoryBuddy are basically always correct. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8244297 > more improvements based on code-review looks good to me too... ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/204 From ebresie at gmail.com Fri Oct 30 14:24:26 2020 From: ebresie at gmail.com (Eric Bresie) Date: Fri, 30 Oct 2020 09:24:26 -0500 Subject: RFR: 8254691: Enable GitHub actions for jfx repo In-Reply-To: _alqlXdOH8kscy1h6Gr8bg1GFu3yOD6vCaqgENfaraw=.de21bebb-1c83-48e9-8c25-98e21933ec98@github.com References: FG8ccT_ancsjR4uB88JuzlxmqcgSoP6u3xmp7BzuhK4=.7cf8656b-6d87-42b1-8e89-20f9eeb8fb4f@github.com G5CGPqgoZql-aRsZMK-Mvpz5zmR0pVyT5Ra7iJ9kZB8=.b7d0a141-2cc1-40c6-b3b1-f38297915c14@github.com vzECPJ9M-Zq8Pcw5uvL85Ulw3AWuuTl5Sdq3PyIwWYA=.c730a7c9-caa8-4c32-95d8-1516dc056fa3@github.com -eDYvRKiZp6S6De2i6Wq_KVFfPf5Ri99O3dYVo3H4r4=.83764206-2ca7-4ea1-a4b0-a918c363f343@github.com rWkpwqs_eYYFOaRh9U1u6BvUqA_bUhK0C3WYbV_F6Gw=.fa01f0f0-2222-49e4-8e51-755d9e998569@github.com QnI4rM-Ut6eeLOyY_CHETcmoxw6fMXYvvav5G6JvsGs=.75320716-f4a1-4d9a-8c70-8262bd35fa5e@github.com k0mz_ZLG_oeOGupYm4Qjhm7XA4On3F6ZRoiKFEWNKU8=.ffd6fc1d-03d8-4691-b122-2e925d8cf953@github.com k0mz_ZLG_oeOGupYm4Qjhm7XA4On3F6ZRoiKFEWNKU8=.ffd6fc1d-03d8-4691-b122-2e925d8cf953@github.com Message-ID: So this doesn?t show lower level test just basically a build successfully pass/fail on each platform? Or would it show any low level tests if they failed? Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) > On October 28, 2020 at 9:43:53 AM CDT, Kevin Rushforth wrote: > On Tue, 27 Oct 2020 19:02:40 GMT, Kevin Rushforth wrote: > > > > ### Note to reviewers: > > > > > > If you want to test this yourself you can pull the PR branch into a branch in your local repo and push it to your personal fork. Something like the following should work for you, assuming that you are in your local repo with `origin` pointing to your personal fork: > > > > > > git fetch https://github.com/openjdk/jfx.git pull/338/head:pr-338 > > > git push -u origin pr-338 > > > > > > Then you will be able to see the GitHub action workflow and track its progress by clicking on the "Actions" tab on your personal fork repo page. > > > > See PR #339 for an example (using an intentionally injected failure) of what a failed build or test will look like. > > I merged `master` into my local branch so it would run the tests again on an up-to-date repo. > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/338 From jvos at openjdk.java.net Fri Oct 30 16:38:56 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 30 Oct 2020 16:38:56 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo [v2] In-Reply-To: References: Message-ID: <5v3VRC9QHyC4LUb61ELbWjZtxLrV07rFI0wyK5lDbx8=.9d4b52a5-b6d5-44f9-bde3-178c592cff9b@github.com> On Wed, 28 Oct 2020 14:43:52 GMT, Kevin Rushforth wrote: >> This is a proposed fix for [JDK-8254691](https://bugs.openjdk.java.net/browse/JDK-8254691) to enable GitHub actions for the jfx repo. It is similar in purpose to what was done for the jdk repo. >> >> Once this is integrated, and subsequently merged into your personal fork, a GitHub Actions workflow will run on every push to any branch in your personal fork except a production branch (so that syncing the upstream `master` or `jfx*` branch won't cause a build) or any branch whose name that starts with `WIP`. >> >> The workflow does a build and (headless) test run on all three platforms: Linux, macOS, and Windows. The build is done without building the native media or WebKit libraries. Web tests are excluded. >> >> Here is the job that resulted from the most recent push to the `8254691-github-actions` branch in my personal fork: >> >> https://github.com/kevinrushforth/jfx/actions/runs/329355746 >> >> The workflow checks out the sources for the branch, downloads the boot JDK, installs the needed software packages, and then runs two build steps, `gradlew all` followed by `gradlew test -x :web:test`. >> >> The Skara tooling will process the results of the GitHub actions run, and show them in the **Testing** section of a pull request, as you can see below. >> >> Follow-on work: >> >> 1. Get BOOT JDK parameters from `build.properties`. Currently the location of the bootJDK is hardcoded in the [`submit.yml`](https://github.com/kevinrushforth/jfx/blob/8254691-github-actions/.github/workflows/submit.yml) file. This should be obtained from build.properties; we might need to add a couple more properties. >> >> 2. Check the shasum of the downloaded bootJDK and enable caching of the JDK (in order to save download time). This requires step 1 to be done first. >> >> 3. Locate the Visual Studio compiler on Windows. The location and version of the Microsoft Visual Studio 2019 compiler is hard-coded which will break if and when the GitHub build farm updates their Windows system. This will require making our build itself a little smarter, possibly using `vswhere`. > > 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 three additional commits since the last revision: > > - Merge branch 'master' into 8254691-github-actions > - Ignore additional branches; minor cleanup > - WIP: 8254691: Enable GitHub actions for jfx repo > > Initial working version on Linux, Mac, Windows .github/workflows/submit.yml line 63: > 61: BOOT_JDK_VERSION: "15" > 62: BOOT_JDK_FILENAME: "openjdk-15_linux-x64_bin.tar.gz" > 63: BOOT_JDK_URL: "https://download.java.net/java/GA/jdk15/779bf45e88a44cbd9ea6621d33e33db1/36/GPL/openjdk-15_linux-x64_bin.tar.gz" Should this be 15.0.1 ? (same for win/mac) ------------- PR: https://git.openjdk.java.net/jfx/pull/338 From jvos at openjdk.java.net Fri Oct 30 17:07:54 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 30 Oct 2020 17:07:54 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo [v2] In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 18:30:47 GMT, Ambarish Rapte wrote: >> 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 three additional commits since the last revision: >> >> - Merge branch 'master' into 8254691-github-actions >> - Ignore additional branches; minor cleanup >> - WIP: 8254691: Enable GitHub actions for jfx repo >> >> Initial working version on Linux, Mac, Windows > > Looks good to me. Verified a dummy PR with two commits. > Actions executed correctly on both commits. Also verified that test failure is reported correctly and failed test can be found in log under Actions section. This works fine. I have a minor comment (about using 15.0.1, but since we don't use that in build.properties either, I think it's not an issue), and apart from that, this looks very good. ------------- PR: https://git.openjdk.java.net/jfx/pull/338 From arapte at openjdk.java.net Fri Oct 30 17:20:59 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 30 Oct 2020 17:20:59 GMT Subject: RFR: 8088739: [TestBug] RegionBackgroundImageUITest fail with timeout error Message-ID: Each test in RegionBackgroundImageUITest makes several calls to `robot.getPixelColor()` on App thread. Due to this each test requires more than **60** seconds for execution. Fix is to save a screen capture of Scene (on App thread) and then read pixel color from the screen capture(not on app thread). This reduces execution time of each test to less than **3** seconds. Ideally with this fix(commit#1) all the tests should pass. All tests do pass on Windows and Linux but three tests fail on Mac, which used to pass without this change. - RegionBackgroundImageUITest.unalignedImage - RegionBackgroundFillUITest.testScenario2 - RegionBackgroundFillUITest.testScenario3 commit#2 solves the above problem. Solution is to fallback to test color again by reading it using `robot.getPixelColor()` on App thread when a test fails. One test RegionBackgroundImageUITest.unalignedImage_Cover, fails only on Mac platform, before and after this fix. It is reported as a new issue [JDK-8255679](https://bugs.openjdk.java.net/browse/JDK-8255679) This is a test fix and affects only the tests that extend from `RegionUITestBase` test class and does not affect other tests. Verified that `RegionBackgroundImageUITest` and `RegionBackgroundFillUITest` tests pass on all three platforms(except RegionBackgroundImageUITest.unalignedImage_Cover which fails on Mac). ------------- Commit messages: - fix for tests failing on Mac - ideal fix, but causes 3 test fail Changes: https://git.openjdk.java.net/jfx/pull/344/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=344&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8088739 Stats: 33 lines in 3 files changed: 28 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/344.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/344/head:pull/344 PR: https://git.openjdk.java.net/jfx/pull/344 From fkirmaier at openjdk.java.net Fri Oct 30 20:10:56 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 30 Oct 2020 20:10:56 GMT Subject: Integrated: 8244297: Provide utility for testing for memory leaks In-Reply-To: References: Message-ID: On Sun, 3 May 2020 21:39:41 GMT, Florian Kirmaier wrote: > It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 > > I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. > > It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. > I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but the tests with JMemoryBuddy are basically always correct. This pull request has now been integrated. Changeset: 1a113344 Author: Florian Kirmaier Committer: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/1a113344 Stats: 427 lines in 5 files changed: 329 ins; 70 del; 28 mod 8244297: Provide utility for testing for memory leaks Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From jvos at openjdk.java.net Fri Oct 30 20:59:01 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 30 Oct 2020 20:59:01 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering Message-ID: Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. ------------- Commit messages: - use a default handle if no external library is needed. - Add Monocle implementation that works with any EGL-based system Changes: https://git.openjdk.java.net/jfx/pull/343/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=343&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254569 Stats: 300 lines in 7 files changed: 296 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/343.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/343/head:pull/343 PR: https://git.openjdk.java.net/jfx/pull/343 From kcr at openjdk.java.net Sat Oct 31 14:37:50 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 31 Oct 2020 14:37:50 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo [v2] In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 17:05:37 GMT, Johan Vos wrote: >> Looks good to me. Verified a dummy PR with two commits. >> Actions executed correctly on both commits. Also verified that test failure is reported correctly and failed test can be found in log under Actions section. > > This works fine. I have a minor comment (about using 15.0.1, but since we don't use that in build.properties either, I think it's not an issue), and apart from that, this looks very good. I'd rather update the boot JDK to 15.0.1 as a follow-on fix, so that it matches the version defined in build.properties. I filed the following follow-on issues: [JDK-8255714](https://bugs.openjdk.java.net/browse/JDK-8255714): Switch FX build to use JDK 15.0.1 as boot JDK [JDK-8255712](https://bugs.openjdk.java.net/browse/JDK-8255712): GitHub actions: read boot JDK version and URL from build.properties [JDK-8255713](https://bugs.openjdk.java.net/browse/JDK-8255713): GitHub actions: JavaFX build should discover Visual Studio compiler on system ------------- PR: https://git.openjdk.java.net/jfx/pull/338 From kcr at openjdk.java.net Sat Oct 31 14:48:51 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 31 Oct 2020 14:48:51 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo [v2] In-Reply-To: References: Message-ID: On Sat, 31 Oct 2020 14:35:09 GMT, Kevin Rushforth wrote: >> This works fine. I have a minor comment (about using 15.0.1, but since we don't use that in build.properties either, I think it's not an issue), and apart from that, this looks very good. > > I'd rather update the boot JDK to 15.0.1 as a follow-on fix, so that it matches the version defined in build.properties. I filed the following follow-on issues: > > [JDK-8255714](https://bugs.openjdk.java.net/browse/JDK-8255714): Switch FX build to use JDK 15.0.1 as boot JDK > [JDK-8255712](https://bugs.openjdk.java.net/browse/JDK-8255712): GitHub actions: read boot JDK version and URL from build.properties > [JDK-8255713](https://bugs.openjdk.java.net/browse/JDK-8255713): GitHub actions: JavaFX build should discover Visual Studio compiler on system > So this doesn?t show lower level test just basically a build successfully pass/fail on each platform? Or would it show any low level tests if they failed? If there is a build or test failure you get a link to the failing tasks and can look at the log file to see the failures (no summary at the present time, though). For example, here are the results from the test build done in PR #339 : | | Linux x64 | Windows x64 | macOS x64 | | --- | ----- | ----- | ----- | | Build / test | ?? (1/1 passed) | ? (1/1 failed) | ? (1/1 failed) | **Failed test tasks** - [Windows x64](https://github.com/kevinrushforth/jfx/runs/1316694644) - [macOS x64](https://github.com/kevinrushforth/jfx/runs/1316694612) ------------- PR: https://git.openjdk.java.net/jfx/pull/338 From jvos at openjdk.java.net Sat Oct 31 15:06:52 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 31 Oct 2020 15:06:52 GMT Subject: RFR: 8254691: Enable GitHub actions for jfx repo [v2] In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 14:43:52 GMT, Kevin Rushforth wrote: >> This is a proposed fix for [JDK-8254691](https://bugs.openjdk.java.net/browse/JDK-8254691) to enable GitHub actions for the jfx repo. It is similar in purpose to what was done for the jdk repo. >> >> Once this is integrated, and subsequently merged into your personal fork, a GitHub Actions workflow will run on every push to any branch in your personal fork except a production branch (so that syncing the upstream `master` or `jfx*` branch won't cause a build) or any branch whose name that starts with `WIP`. >> >> The workflow does a build and (headless) test run on all three platforms: Linux, macOS, and Windows. The build is done without building the native media or WebKit libraries. Web tests are excluded. >> >> Here is the job that resulted from the most recent push to the `8254691-github-actions` branch in my personal fork: >> >> https://github.com/kevinrushforth/jfx/actions/runs/329355746 >> >> The workflow checks out the sources for the branch, downloads the boot JDK, installs the needed software packages, and then runs two build steps, `gradlew all` followed by `gradlew test -x :web:test`. >> >> The Skara tooling will process the results of the GitHub actions run, and show them in the **Testing** section of a pull request, as you can see below. >> >> Follow-on work: >> >> 1. Get BOOT JDK parameters from `build.properties`. Currently the location of the bootJDK is hardcoded in the [`submit.yml`](https://github.com/kevinrushforth/jfx/blob/8254691-github-actions/.github/workflows/submit.yml) file. This should be obtained from build.properties; we might need to add a couple more properties. >> >> 2. Check the shasum of the downloaded bootJDK and enable caching of the JDK (in order to save download time). This requires step 1 to be done first. >> >> 3. Locate the Visual Studio compiler on Windows. The location and version of the Microsoft Visual Studio 2019 compiler is hard-coded which will break if and when the GitHub build farm updates their Windows system. This will require making our build itself a little smarter, possibly using `vswhere`. > > 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 three additional commits since the last revision: > > - Merge branch 'master' into 8254691-github-actions > - Ignore additional branches; minor cleanup > - WIP: 8254691: Enable GitHub actions for jfx repo > > Initial working version on Linux, Mac, Windows Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/338 From kcr at openjdk.java.net Sat Oct 31 15:33:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 31 Oct 2020 15:33:52 GMT Subject: Integrated: 8254691: Enable GitHub actions for jfx repo In-Reply-To: References: Message-ID: <-Ajb0rVLgj-ARtbw6tZtWl-U15rjuV9wgst5MjIr37U=.59258390-7515-441b-bdf6-4564502eb8b0@github.com> On Sat, 24 Oct 2020 14:41:08 GMT, Kevin Rushforth wrote: > This is a proposed fix for [JDK-8254691](https://bugs.openjdk.java.net/browse/JDK-8254691) to enable GitHub actions for the jfx repo. It is similar in purpose to what was done for the jdk repo. > > Once this is integrated, and subsequently merged into your personal fork, a GitHub Actions workflow will run on every push to any branch in your personal fork except a production branch (so that syncing the upstream `master` or `jfx*` branch won't cause a build) or any branch whose name that starts with `WIP`. > > The workflow does a build and (headless) test run on all three platforms: Linux, macOS, and Windows. The build is done without building the native media or WebKit libraries. Web tests are excluded. > > Here is the job that resulted from the most recent push to the `8254691-github-actions` branch in my personal fork: > > https://github.com/kevinrushforth/jfx/actions/runs/329355746 > > The workflow checks out the sources for the branch, downloads the boot JDK, installs the needed software packages, and then runs two build steps, `gradlew all` followed by `gradlew test -x :web:test`. > > The Skara tooling will process the results of the GitHub actions run, and show them in the **Testing** section of a pull request, as you can see below. > > Follow-on work: > > 1. Get BOOT JDK parameters from `build.properties`. Currently the location of the bootJDK is hardcoded in the [`submit.yml`](https://github.com/kevinrushforth/jfx/blob/8254691-github-actions/.github/workflows/submit.yml) file. This should be obtained from build.properties; we might need to add a couple more properties. > > 2. Check the shasum of the downloaded bootJDK and enable caching of the JDK (in order to save download time). This requires step 1 to be done first. > > 3. Locate the Visual Studio compiler on Windows. The location and version of the Microsoft Visual Studio 2019 compiler is hard-coded which will break if and when the GitHub build farm updates their Windows system. This will require making our build itself a little smarter, possibly using `vswhere`. This pull request has now been integrated. Changeset: 51c09e5a Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/51c09e5a Stats: 285 lines in 1 file changed: 285 ins; 0 del; 0 mod 8254691: Enable GitHub actions for jfx repo Reviewed-by: arapte, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/338 From kartikohri13 at gmail.com Sat Oct 31 15:49:23 2020 From: kartikohri13 at gmail.com (Kartik Ohri) Date: Sat, 31 Oct 2020 21:19:23 +0530 Subject: RFR: JDK-8248122: java.base should not handle JavaFX application in a specific way In-Reply-To: References: Message-ID: Hi! I was unable to add the openjfx to the PR on github and was unsure which other mailing list is right for discussing this change, hence I am sending it here. If this is the wrong mailing list, pardon me and kindly point me in the right direction. The related pull request is https://github.com/openjdk/jdk/pull/978 and the webrev is available at https://openjdk.github.io/cr/?repo=jdk&pr=978&range=00. Thank you. Regards, Kartik From kevin.rushforth at oracle.com Sat Oct 31 16:19:03 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 31 Oct 2020 09:19:03 -0700 Subject: RFR: JDK-8248122: java.base should not handle JavaFX application in a specific way In-Reply-To: References: Message-ID: <39b4c05d-58a5-824e-4f75-b02142350226@oracle.com> Yes, this is the right list for discussing the impact of your proposed change on JavaFX applications. I added a comment to that affect in the PR, essentially saying that this PR cannot go in as proposed for JDK 16, since it will cause a behavioral regression and will break some existing JavaFX applications. If it is done, it will need to be done carefully. Can you say more about the reason you are proposing this change? The stated reason in the bug report is to allow the JavaFX modules to be run on the classpath, which is not a supported use case. There might be other reasons to get rid of the special case logic used to launch JavaFX applications, which can be discussed. -- Kevin On 10/31/2020 8:49 AM, Kartik Ohri wrote: > Hi! > I was unable to add the openjfx to the PR on github and was unsure which > other mailing list is right for discussing this change, hence I am sending > it here. If this is the wrong mailing list, pardon me and kindly point me > in the right direction. > > The related pull request is https://github.com/openjdk/jdk/pull/978 and the > webrev is available at > https://openjdk.github.io/cr/?repo=jdk&pr=978&range=00. > > Thank you. > Regards, > Kartik From kartikohri13 at gmail.com Sat Oct 31 16:39:09 2020 From: kartikohri13 at gmail.com (Kartik Ohri) Date: Sat, 31 Oct 2020 22:09:09 +0530 Subject: RFR: JDK-8248122: java.base should not handle JavaFX application in a specific way In-Reply-To: <39b4c05d-58a5-824e-4f75-b02142350226@oracle.com> References: <39b4c05d-58a5-824e-4f75-b02142350226@oracle.com> Message-ID: Hi! I did not propose the patch to allow JavaFX modules to be run from classpath. That bug report just made me aware of the inconsistency. My rationale behind proposing the patch was only that JavaFX should be treated just like any other java application. I had not seen the earlier discussion on the other ticket you referred to. Otherwise, I would not have proposed this patch in the first place due to the compatibility concerns around it. Regards, Kartik From kevin.rushforth at oracle.com Sat Oct 31 16:50:48 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 31 Oct 2020 09:50:48 -0700 Subject: RFR: JDK-8248122: java.base should not handle JavaFX application in a specific way In-Reply-To: References: <39b4c05d-58a5-824e-4f75-b02142350226@oracle.com> Message-ID: <694f3bb6-9075-f3a8-2edf-aed6360d0c27@oracle.com> I see. Thanks for the explanation. We can continue the discussion on this list (and separately on the core-libs-dev list) then. It will allow us to make a deliberate (and hopefully informed) decision as to what we want to do going forward. Thanks. -- Kevin On 10/31/2020 9:39 AM, Kartik Ohri wrote: > Hi! > I did not propose the patch to allow JavaFX modules to be run from > classpath. That bug report just made me aware of the inconsistency. My > rationale behind proposing the patch was only that JavaFX should be > treated just like any other java application. > > I had not seen the earlier discussion on the other ticket you referred > to. Otherwise, I would not have proposed this patch in the first place > due to the compatibility?concerns around it. > Regards, > Kartik