From almatvee at openjdk.org Fri Jul 1 02:15:25 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 1 Jul 2022 02:15:25 GMT Subject: RFR: 8288450: Update attribution in gstreamer.md file Message-ID: Doc-only change to update the license attribution in our gstreamer.md and glib.md files. ------------- Commit messages: - 8288450: Update attribution in gstreamer.md file Changes: https://git.openjdk.org/jfx/pull/807/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=807&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288450 Stats: 128 lines in 2 files changed: 126 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/807.diff Fetch: git fetch https://git.openjdk.org/jfx pull/807/head:pull/807 PR: https://git.openjdk.org/jfx/pull/807 From mhanl at openjdk.org Fri Jul 1 08:00:51 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 1 Jul 2022 08:00:51 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v5] In-Reply-To: References: Message-ID: > This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. > > I also added tests which will succeed before and after to verify that nothing got broken by this change. > Also I made a benchmark test. Results: > > | Benchmark | Mode| Cnt | Score | Error | Units > | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | > | ListBenchmark OLD | thrpt | 25 | 722,842 | ? 26,93 | ops/s > | ListBenchmark NEW | thrpt | 25 | 29262,274 | ? 2088,712 | ops/s > > Edit: I also made a synthetic benchmark by measuring the same code below 100 times with `System.nanoTime`. > ListBenchmark OLD (avg): 21-23ms > ListBenchmark NEW (avg): 2 ms > >
Benchmark code > > > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import org.openjdk.jmh.annotations.Benchmark; > import org.openjdk.jmh.annotations.Scope; > import org.openjdk.jmh.annotations.Setup; > import org.openjdk.jmh.annotations.State; > import org.openjdk.jmh.annotations.TearDown; > > import java.util.ArrayList; > import java.util.List; > > @State(Scope.Benchmark) > public class ListBenchmark { > > List strings; > > @Setup > public void setup() { > strings = new ArrayList<>(); > for(int i = 0; i< 100000;i++) { > strings.add("abc: " + i); > } > } > > @TearDown > public void tearDown() { > strings = null; > } > > @Benchmark > public ObservableList init() { > return FXCollections.observableArrayList(strings); > } > } > > >
Marius Hanl has updated the pull request incrementally with two additional commits since the last revision: - 8283346: Added null to the test data - 8283346: Refactoring: Using the ArrayList constructor directly ------------- Changes: - all: https://git.openjdk.org/jfx/pull/758/files - new: https://git.openjdk.org/jfx/pull/758/files/3f288403..28fbd344 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=758&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=758&range=03-04 Stats: 6 lines in 2 files changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/758.diff Fetch: git fetch https://git.openjdk.org/jfx pull/758/head:pull/758 PR: https://git.openjdk.org/jfx/pull/758 From mhanl at openjdk.org Fri Jul 1 08:00:55 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 1 Jul 2022 08:00:55 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v4] In-Reply-To: References: <0bgs0QoUoqrObRP1Ch0BewkS7ETnEDL2mnoBMi4bME0=.7e6d5429-b9a5-4759-a99a-e48b4407c356@github.com> Message-ID: On Thu, 30 Jun 2022 19:36:34 GMT, Nir Lisker wrote: > Looks good. I left a few small comments. > > I ran some benchmarks and I can reproduce the performance improvement both in the array (varargs) and the collection variants of the method. Thanks for the review and verifying the improvement. I implemented your suggested changes. > modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 351: > >> 349: public static ObservableList observableArrayList(E... items) { >> 350: ArrayList backingList = new ArrayList<>(items.length); >> 351: backingList.addAll(Arrays.asList(items)); > > Unless I'm missing something again, this can be written as > `ArrayList backingList = new ArrayList<>(Arrays.asList(items));` > > I created benchmarks based on yours, and there is no significant difference between these two (their scores are within the error ranges of each other). > > I don't mind leaving it as is if you think it's clearer, I personally prefer the 1 line variant. Thanks. I totally missed that, I prefer the 1 line variant as well. > modules/javafx.base/src/test/java/test/javafx/collections/FXCollectionsTest.java line 47: > >> 45: @Test >> 46: public void testCreateObservableArrayListFromArray() { >> 47: ObservableList observableList = FXCollections.observableArrayList("1", "2", "3"); > > I would add a `null` element (like `"1", "2", null`) to test that the method accepts `null`s, especially after I fell for it myself. Good idea, will do. ------------- PR: https://git.openjdk.org/jfx/pull/758 From jhendrikx at openjdk.org Fri Jul 1 09:04:11 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 1 Jul 2022 09:04:11 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v17] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <_gd3ukG8x9KEj0prENidAHfsptHgB5xUWDhFHbGCtv0=.2f8ffa59-c98d-48cb-bdbd-0a022f2c6412@github.com> > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Standard JavaFX + Optional: > label.textProperty().bind(Bindings.createStringBinding( > () -> Optinal.ofNullable(employee.get()) > .map(Employee::getCompany) > .map(Company::getName) > .orElse(""), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Add null checks in Subscription - Update copyrights ------------- Changes: - all: https://git.openjdk.org/jfx/pull/675/files - new: https://git.openjdk.org/jfx/pull/675/files/2c3a9d95..6ae74d19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=675&range=16 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=675&range=15-16 Stats: 14 lines in 10 files changed: 4 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.org/jfx pull/675/head:pull/675 PR: https://git.openjdk.org/jfx/pull/675 From jhendrikx at openjdk.org Fri Jul 1 09:06:19 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 1 Jul 2022 09:06:19 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v16] In-Reply-To: <4SyeeOKmJpOlJV_5pxkAn9fjjjUVLL84t7NYzoA--is=.2f8ca931-cf15-4cd9-a407-a0094373c930@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <1qQDzVEpKEXbHbLIbogyIxEhdd0by8G47jGVIuvuYiY=.ebb06ac9-acb7-41cb-8c27-a2de8503c2c7@github.com> <4SyeeOKmJpOlJV_5pxkAn9fjjjUVLL84t7NYzoA--is=.2f8ca931-cf15-4cd9-a407-a0094373c930@github.com> Message-ID: On Thu, 30 Jun 2022 22:46:26 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: >> >> - Move private binding classes to com.sun.javafx.binding package >> - Add note to Bindings#select to consider ObservableValue#flatMap >> - Fix bug invalidation bug in FlatMappedBinding >> >> Also fixed a secondary issue where the indirect source of the binding >> was unsubscribed and resubscribed each time its value was recomputed. >> >> Add additional comments to clarify how FlatMappedBinding works. >> >> Added test cases for these newly discovered issues. >> - Fix typos in LazyObjectBinding >> - Rename observeInputs to observeSources > > modules/javafx.base/src/main/java/javafx/beans/binding/Bindings.java line 443: > >> 441: * Since 19, it is recommended to use {@link ObservableValue#flatMap(java.util.function.Function)} >> 442: * to select a nested member of an {@link ObservableValue}. >> 443: *

> > This should be added to the CSR. I've updated the CSR. ------------- PR: https://git.openjdk.org/jfx/pull/675 From mhanl at openjdk.org Fri Jul 1 12:16:36 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 1 Jul 2022 12:16:36 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v6] In-Reply-To: References: Message-ID: <9LxdzDx_IKxgrNdEl6cKqDxRu9Z_BBQzSbvn-yv0GEE=.45a0ec0b-0ab0-4b67-9a45-c310999a45f3@github.com> > This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. > > I also added tests which will succeed before and after to verify that nothing got broken by this change. > Also I made a benchmark test. Results: > > | Benchmark | Mode| Cnt | Score | Error | Units > | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | > | ListBenchmark OLD | thrpt | 25 | 722,842 | ? 26,93 | ops/s > | ListBenchmark NEW | thrpt | 25 | 29262,274 | ? 2088,712 | ops/s > > Edit: I also made a synthetic benchmark by measuring the same code below 100 times with `System.nanoTime`. > ListBenchmark OLD (avg): 21-23ms > ListBenchmark NEW (avg): 2 ms > >
Benchmark code > > > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import org.openjdk.jmh.annotations.Benchmark; > import org.openjdk.jmh.annotations.Scope; > import org.openjdk.jmh.annotations.Setup; > import org.openjdk.jmh.annotations.State; > import org.openjdk.jmh.annotations.TearDown; > > import java.util.ArrayList; > import java.util.List; > > @State(Scope.Benchmark) > public class ListBenchmark { > > List strings; > > @Setup > public void setup() { > strings = new ArrayList<>(); > for(int i = 0; i< 100000;i++) { > strings.add("abc: " + i); > } > } > > @TearDown > public void tearDown() { > strings = null; > } > > @Benchmark > public ObservableList init() { > return FXCollections.observableArrayList(strings); > } > } > > >
Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8283346: Inline ArrayList creation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/758/files - new: https://git.openjdk.org/jfx/pull/758/files/28fbd344..8fe4603a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=758&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=758&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/758.diff Fetch: git fetch https://git.openjdk.org/jfx pull/758/head:pull/758 PR: https://git.openjdk.org/jfx/pull/758 From kcr at openjdk.org Fri Jul 1 13:09:52 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Jul 2022 13:09:52 GMT Subject: RFR: 8288450: Update attribution in gstreamer.md file In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 02:07:54 GMT, Alexander Matveev wrote: > Doc-only change to update the license attribution in our gstreamer.md and glib.md files. Looks good with a minor (optional) comment in two places. modules/javafx.media/src/main/legal/glib.md line 38: > 36: ``` > 37: > 38: #### LGPL 2.1 Minor: to match the other sections and also what we did for WebKit, you might change this to `LGPL 2.1 License` modules/javafx.media/src/main/legal/gstreamer.md line 36: > 34: ``` > 35: > 36: #### LGPL 2.1 Minor: to match the other sections and also what we did for WebKit, you might change this to `LGPL 2.1 License` ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/807 From kcr at openjdk.org Fri Jul 1 13:26:06 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Jul 2022 13:26:06 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v17] In-Reply-To: <_gd3ukG8x9KEj0prENidAHfsptHgB5xUWDhFHbGCtv0=.2f8ffa59-c98d-48cb-bdbd-0a022f2c6412@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <_gd3ukG8x9KEj0prENidAHfsptHgB5xUWDhFHbGCtv0=.2f8ffa59-c98d-48cb-bdbd-0a022f2c6412@github.com> Message-ID: On Fri, 1 Jul 2022 09:04:11 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Add null checks in Subscription > - Update copyrights While running tests I noticed that your branch is very out of date w.r.t. master. Can you merge in the latest master in order to get a new GHA test run with the latest changes included? ------------- PR: https://git.openjdk.org/jfx/pull/675 From jhendrikx at openjdk.org Fri Jul 1 15:16:24 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 1 Jul 2022 15:16:24 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Standard JavaFX + Optional: > label.textProperty().bind(Bindings.createStringBinding( > () -> Optinal.ofNullable(employee.get()) > .map(Employee::getCompany) > .map(Company::getName) > .orElse(""), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request 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 27 additional commits since the last revision: - Merge branch 'openjdk:master' into feature/fluent-bindings - Add null checks in Subscription - Update copyrights - Move private binding classes to com.sun.javafx.binding package - Add note to Bindings#select to consider ObservableValue#flatMap - Fix bug invalidation bug in FlatMappedBinding Also fixed a secondary issue where the indirect source of the binding was unsubscribed and resubscribed each time its value was recomputed. Add additional comments to clarify how FlatMappedBinding works. Added test cases for these newly discovered issues. - Fix typos in LazyObjectBinding - Rename observeInputs to observeSources - Expand flatMap javadoc with additional wording from Optional#flatMap - Add since tags to all new API - ... and 17 more: https://git.openjdk.org/jfx/compare/53453a6c...d66f2ba6 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/675/files - new: https://git.openjdk.org/jfx/pull/675/files/6ae74d19..d66f2ba6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=675&range=17 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=675&range=16-17 Stats: 575873 lines in 7694 files changed: 293905 ins; 175409 del; 106559 mod Patch: https://git.openjdk.org/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.org/jfx pull/675/head:pull/675 PR: https://git.openjdk.org/jfx/pull/675 From jhendrikx at openjdk.org Fri Jul 1 15:26:58 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 1 Jul 2022 15:26:58 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v17] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <_gd3ukG8x9KEj0prENidAHfsptHgB5xUWDhFHbGCtv0=.2f8ffa59-c98d-48cb-bdbd-0a022f2c6412@github.com> Message-ID: On Fri, 1 Jul 2022 13:23:58 GMT, Kevin Rushforth wrote: > While running tests I noticed that your branch is very out of date w.r.t. master. Can you merge in the latest master in order to get a new GHA test run with the latest changes included? It's updated, linux build just passed so probably no issues. ------------- PR: https://git.openjdk.org/jfx/pull/675 From kcr at openjdk.org Fri Jul 1 16:09:40 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Jul 2022 16:09:40 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <__KsjzHzaSKfAiR-FqsQ4xbeJzaBKDZzB--_IqoTL2A=.6ceee855-9afa-455f-947f-5bbe7a5c0e2b@github.com> On Fri, 1 Jul 2022 15:16:24 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request 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 27 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/fluent-bindings > - Add null checks in Subscription > - Update copyrights > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API > - ... and 17 more: https://git.openjdk.org/jfx/compare/ed1b74f9...d66f2ba6 Looks good! ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/675 From mstrauss at openjdk.org Fri Jul 1 16:15:18 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 1 Jul 2022 16:15:18 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Fri, 1 Jul 2022 15:16:24 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request 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 27 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/fluent-bindings > - Add null checks in Subscription > - Update copyrights > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API > - ... and 17 more: https://git.openjdk.org/jfx/compare/decc318e...d66f2ba6 Marked as reviewed by mstrauss (Author). ------------- PR: https://git.openjdk.org/jfx/pull/675 From nlisker at openjdk.org Fri Jul 1 16:20:52 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 1 Jul 2022 16:20:52 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v6] In-Reply-To: <9LxdzDx_IKxgrNdEl6cKqDxRu9Z_BBQzSbvn-yv0GEE=.45a0ec0b-0ab0-4b67-9a45-c310999a45f3@github.com> References: <9LxdzDx_IKxgrNdEl6cKqDxRu9Z_BBQzSbvn-yv0GEE=.45a0ec0b-0ab0-4b67-9a45-c310999a45f3@github.com> Message-ID: On Fri, 1 Jul 2022 12:16:36 GMT, Marius Hanl wrote: >> This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. >> >> I also added tests which will succeed before and after to verify that nothing got broken by this change. >> Also I made a benchmark test. Results: >> >> | Benchmark | Mode| Cnt | Score | Error | Units >> | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | >> | ListBenchmark OLD | thrpt | 25 | 722,842 | ? 26,93 | ops/s >> | ListBenchmark NEW | thrpt | 25 | 29262,274 | ? 2088,712 | ops/s >> >> Edit: I also made a synthetic benchmark by measuring the same code below 100 times with `System.nanoTime`. >> ListBenchmark OLD (avg): 21-23ms >> ListBenchmark NEW (avg): 2 ms >> >>
Benchmark code >> >> >> import javafx.collections.FXCollections; >> import javafx.collections.ObservableList; >> import org.openjdk.jmh.annotations.Benchmark; >> import org.openjdk.jmh.annotations.Scope; >> import org.openjdk.jmh.annotations.Setup; >> import org.openjdk.jmh.annotations.State; >> import org.openjdk.jmh.annotations.TearDown; >> >> import java.util.ArrayList; >> import java.util.List; >> >> @State(Scope.Benchmark) >> public class ListBenchmark { >> >> List strings; >> >> @Setup >> public void setup() { >> strings = new ArrayList<>(); >> for(int i = 0; i< 100000;i++) { >> strings.add("abc: " + i); >> } >> } >> >> @TearDown >> public void tearDown() { >> strings = null; >> } >> >> @Benchmark >> public ObservableList init() { >> return FXCollections.observableArrayList(strings); >> } >> } >> >> >>
> > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8283346: Inline ArrayList creation Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/758 From mstrauss at openjdk.org Fri Jul 1 16:27:58 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 1 Jul 2022 16:27:58 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v6] In-Reply-To: <9LxdzDx_IKxgrNdEl6cKqDxRu9Z_BBQzSbvn-yv0GEE=.45a0ec0b-0ab0-4b67-9a45-c310999a45f3@github.com> References: <9LxdzDx_IKxgrNdEl6cKqDxRu9Z_BBQzSbvn-yv0GEE=.45a0ec0b-0ab0-4b67-9a45-c310999a45f3@github.com> Message-ID: On Fri, 1 Jul 2022 12:16:36 GMT, Marius Hanl wrote: >> This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. >> >> I also added tests which will succeed before and after to verify that nothing got broken by this change. >> Also I made a benchmark test. Results: >> >> | Benchmark | Mode| Cnt | Score | Error | Units >> | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | >> | ListBenchmark OLD | thrpt | 25 | 722,842 | ? 26,93 | ops/s >> | ListBenchmark NEW | thrpt | 25 | 29262,274 | ? 2088,712 | ops/s >> >> Edit: I also made a synthetic benchmark by measuring the same code below 100 times with `System.nanoTime`. >> ListBenchmark OLD (avg): 21-23ms >> ListBenchmark NEW (avg): 2 ms >> >>
Benchmark code >> >> >> import javafx.collections.FXCollections; >> import javafx.collections.ObservableList; >> import org.openjdk.jmh.annotations.Benchmark; >> import org.openjdk.jmh.annotations.Scope; >> import org.openjdk.jmh.annotations.Setup; >> import org.openjdk.jmh.annotations.State; >> import org.openjdk.jmh.annotations.TearDown; >> >> import java.util.ArrayList; >> import java.util.List; >> >> @State(Scope.Benchmark) >> public class ListBenchmark { >> >> List strings; >> >> @Setup >> public void setup() { >> strings = new ArrayList<>(); >> for(int i = 0; i< 100000;i++) { >> strings.add("abc: " + i); >> } >> } >> >> @TearDown >> public void tearDown() { >> strings = null; >> } >> >> @Benchmark >> public ObservableList init() { >> return FXCollections.observableArrayList(strings); >> } >> } >> >> >>
> > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8283346: Inline ArrayList creation Marked as reviewed by mstrauss (Author). ------------- PR: https://git.openjdk.org/jfx/pull/758 From almatvee at openjdk.org Fri Jul 1 20:41:46 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 1 Jul 2022 20:41:46 GMT Subject: RFR: 8288450: Update attribution in gstreamer.md file [v2] In-Reply-To: References: Message-ID: > Doc-only change to update the license attribution in our gstreamer.md and glib.md files. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8288450: Update attribution in gstreamer.md file [v2] ------------- Changes: - all: https://git.openjdk.org/jfx/pull/807/files - new: https://git.openjdk.org/jfx/pull/807/files/3f480997..e214f1df Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=807&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=807&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/807.diff Fetch: git fetch https://git.openjdk.org/jfx pull/807/head:pull/807 PR: https://git.openjdk.org/jfx/pull/807 From kcr at openjdk.org Fri Jul 1 21:03:56 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Jul 2022 21:03:56 GMT Subject: RFR: 8288450: Update attribution in gstreamer.md file [v2] In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 20:41:46 GMT, Alexander Matveev wrote: >> Doc-only change to update the license attribution in our gstreamer.md and glib.md files. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8288450: Update attribution in gstreamer.md file [v2] Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/807 From kevin.rushforth at oracle.com Fri Jul 1 22:43:57 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 1 Jul 2022 15:43:57 -0700 Subject: Proposed schedule for JavaFX 19 In-Reply-To: References: Message-ID: As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 19 starts on July 14, 2022 at 16:00 UTC (09:00 Pacific time), which is a little less than two weeks from now. During rampdown of JavaFX 19, the "master" branch of the jfx repo will be open for JavaFX 20 fixes. Please allow sufficient time for any feature that needs a CSR. New features should be far enough along in the review process that you can finalize the CSR by Thursday, July 7, or it is likely to miss the window for this release, in which case it can be targeted for JavaFX 20. We will follow the same process as in previous releases for getting fixes into JavaFX 19 during rampdown. I'll send a message with detailed information when we fork, but candidates for fixing during RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc bugs of any priority. Some small enhancements might be considered during RDP1, but they require explicit approval; the bar will be high for such requests. -- Kevin On 5/9/2022 3:28 PM, Kevin Rushforth wrote: > Here is the proposed schedule for JavaFX 19. > > RDP1: Jul 14, 2022 (aka ?feature freeze?) > RDP2: Aug 4, 2022 > Freeze: Aug 25, 2022 > GA: Sep 13, 2022 > > We plan to fork a jfx19 stabilization branch at RDP1. The GA date is > one week ahead of JDK 19, matching what we did for 18. > > 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 nlisker at openjdk.org Sat Jul 2 00:48:50 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 2 Jul 2022 00:48:50 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 23:19:36 GMT, Andy Goryachev wrote: > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files I found my branch that was dealing with the Eclipse files update: https://github.com/openjdk/jfx/compare/master...nlisker:jfx:8221708_Update_Eclipse_project_files It contains changes to the apps project too. I compared your changes with mine, although mine are outdated in some places. * You can remove the eclipse project and classpath files from `jfx/buildSrc`. It's a groovy project that is not very relevant. it can be manually imported if someone needs it. * I'm still getting errors in tests/system: Description Resource Path Location Type AfterAll cannot be resolved to a type DoubleShortcutProcessingTest.java /tests/system/src/test/java/test/robot/javafx/scene line 78 Java Problem Assertions cannot be resolved DoubleShortcutProcessingTest.java /tests/system/src/test/java/test/robot/javafx/scene line 68 Java Problem Assertions cannot be resolved DoubleShortcutProcessingTest.java /tests/system/src/test/java/test/robot/javafx/scene line 159 Java Problem Assertions cannot be resolved DoubleShortcutProcessingTest.java /tests/system/src/test/java/test/robot/javafx/scene line 162 Java Problem Assumptions cannot be resolved DoubleShortcutProcessingTest.java /tests/system/src/test/java/test/robot/javafx/scene line 64 Java Problem BeforeAll cannot be resolved to a type DoubleShortcutProcessingTest.java /tests/system/src/test/java/test/robot/javafx/scene line 72 Java Problem ClipboardTransferable cannot be resolved to a type ClipboardTest.java /tests/system/src/test/java/test/javafx/scene/input line 132 Java Problem MacPasteboardShim cannot be resolved to a type MacPasteboardTest.java /tests/system/src/test/java/test/com/sun/glass/ui/mac line 51 Java Problem MacPasteboardShim cannot be resolved to a type MacPasteboardTest.java /tests/system/src/test/java/test/com/sun/glass/ui/mac line 57 Java Problem MacPasteboardShim cannot be resolved to a type MacPasteboardTest.java /tests/system/src/test/java/test/com/sun/glass/ui/mac line 57 Java Problem MacPasteboardShim cannot be resolved to a type MacPasteboardTest.java /tests/system/src/test/java/test/com/sun/glass/ui/mac line 75 Java Problem MacPasteboardShim cannot be resolved to a type MacPasteboardTest.java /tests/system/src/test/java/test/com/sun/glass/ui/mac line 76 Java Problem MacPasteboardShim cannot be resolved to a type MacPasteboardTest.java /tests/system/src/test/java/test/com/sun/glass/ui/mac line 91 Java Problem MacPasteboardShim cannot be resolved to a type MacPasteboardTest.java /tests/system/src/test/java/test/com/sun/glass/ui/mac line 92 Java Problem MacPasteboardShim cannot be resolved to a type MacPasteboardTest.java /tests/system/src/test/java/test/com/sun/glass/ui/mac line 102 Java Problem MacPasteboardShim cannot be resolved to a type MacPasteboardTest.java /tests/system/src/test/java/test/com/sun/glass/ui/mac line 103 Java Problem SunClipboard cannot be resolved to a type ClipboardTest.java /tests/system/src/test/java/test/javafx/scene/input line 146 Java Problem Test cannot be resolved to a type DoubleShortcutProcessingTest.java /tests/system/src/test/java/test/robot/javafx/scene line 62 Java Problem The import com.sun.glass.ui.mac cannot be resolved MacPasteboardTest.java /tests/system/src/test/java/test/com/sun/glass/ui/mac line 30 Java Problem The import org.junit.jupiter cannot be resolved DoubleShortcutProcessingTest.java /tests/system/src/test/java/test/robot/javafx/scene line 33 Java Problem The import org.junit.jupiter cannot be resolved DoubleShortcutProcessingTest.java /tests/system/src/test/java/test/robot/javafx/scene line 34 Java Problem The import org.junit.jupiter cannot be resolved DoubleShortcutProcessingTest.java /tests/system/src/test/java/test/robot/javafx/scene line 35 Java Problem The import org.junit.jupiter cannot be resolved DoubleShortcutProcessingTest.java /tests/system/src/test/java/test/robot/javafx/scene line 36 Java Problem The import org.junit.jupiter cannot be resolved DoubleShortcutProcessingTest.java /tests/system/src/test/java/test/robot/javafx/scene line 37 Java Problem The import sun.awt.datatransfer cannot be resolved ClipboardTest.java /tests/system/src/test/java/test/javafx/scene/input line 44 Java Problem The import sun.awt.datatransfer cannot be resolved ClipboardTest.java /tests/system/src/test/java/test/javafx/scene/input line 45 Java Problem The method clearNativeContext() of type ClipboardTest.CustomClipboard must override or implement a supertype method ClipboardTest.java /tests/system/src/test/java/test/javafx/scene/input line 192 Java Problem The method getClipboardData(long) of type ClipboardTest.CustomClipboard must override or implement a supertype method ClipboardTest.java /tests/system/src/test/java/test/javafx/scene/input line 207 Java Problem The method getClipboardFormats() of type ClipboardTest.CustomClipboard must override or implement a supertype method ClipboardTest.java /tests/system/src/test/java/test/javafx/scene/input line 202 Java Problem The method getID() of type ClipboardTest.CustomClipboard must override or implement a supertype method ClipboardTest.java /tests/system/src/test/java/test/javafx/scene/input line 187 Java Problem The method registerClipboardViewerChecked() of type ClipboardTest.CustomClipboard must override or implement a supertype method ClipboardTest.java /tests/system/src/test/java/test/javafx/scene/input line 216 Java Problem The method setContentsNative(Transferable) of type ClipboardTest.CustomClipboard must override or implement a supertype method ClipboardTest.java /tests/system/src/test/java/test/javafx/scene/input line 197 Java Problem The method unregisterClipboardViewerChecked() of type ClipboardTest.CustomClipboard must override or implement a supertype method ClipboardTest.java /tests/system/src/test/java/test/javafx/scene/input line 221 Java Problem The type com.sun.webkit.WebPage is not accessible PageFillTest.java /tests/system/src/test/java/test/javafx/scene/web line 28 Java Problem The type com.sun.webkit.WebPage is not accessible StraightLineTest.java /tests/system/src/test/java/test/javafx/scene/web line 28 Java Problem The type com.sun.webkit.WebPage is not accessible WebPageTest.java /tests/system/src/test/java/test/javafx/scene/web line 41 Java Problem The type com.sun.webkit.WebPageShim is not accessible PageFillTest.java /tests/system/src/test/java/test/javafx/scene/web line 29 Java Problem The type com.sun.webkit.WebPageShim is not accessible StraightLineTest.java /tests/system/src/test/java/test/javafx/scene/web line 29 Java Problem The type com.sun.webkit.WebPageShim is not accessible WebPageTest.java /tests/system/src/test/java/test/javafx/scene/web line 42 Java Problem WebPage cannot be resolved to a type PageFillTest.java /tests/system/src/test/java/test/javafx/scene/web line 184 Java Problem WebPage cannot be resolved to a type PageFillTest.java /tests/system/src/test/java/test/javafx/scene/web line 237 Java Problem WebPage cannot be resolved to a type WebPageTest.java /tests/system/src/test/java/test/javafx/scene/web line 138 Java Problem WebPageShim cannot be resolved PageFillTest.java /tests/system/src/test/java/test/javafx/scene/web line 186 Java Problem WebPageShim cannot be resolved PageFillTest.java /tests/system/src/test/java/test/javafx/scene/web line 239 Java Problem WebPageShim cannot be resolved WebPageTest.java /tests/system/src/test/java/test/javafx/scene/web line 140 Java Problem Do you not get these? modules/javafx.graphics/.classpath line 5: > 3: > 4: > 5: I think that you can remove these source folders too. Did you get errors with `build/hlsl/Decora` and `build/hlsl/Prism`? These are generated for Windows, so possibly on Linux/Mac you would get errors, but marking them with "ignore_optional_problems" should resolve these. In general, we should be able to remove OS-specific folders. modules/javafx.swing/.classpath line 9: > 7: > 8: > 9: This folder doesn't exist, it should be giving you an error, does it not? ------------- Changes requested by nlisker (Reviewer). PR: https://git.openjdk.org/jfx/pull/804 From mstrauss at openjdk.org Sat Jul 2 01:13:36 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 2 Jul 2022 01:13:36 GMT Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value [v3] In-Reply-To: References: Message-ID: <-fva4z7AeyvBPeAu7eeffqfuAkiynC4CKWiIShr7EzI=.d50466d8-6cf7-482b-9950-1969a840370d@github.com> > The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa. > > The following program shows the problem for HBox: > > Region r1 = new Region(); > Region r2 = new Region(); > Region r3 = new Region(); > Region r4 = new Region(); > Region r5 = new Region(); > Region r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6); > hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox1.setPrefHeight(40); > > r1 = new Region(); > r2 = new Region(); > r3 = new Region(); > r4 = new Region(); > r5 = new Region(); > r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6); > hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox2.setPrefHeight(40); > hbox2.setPrefWidth(152); > > VBox root = new VBox(new HBox(hbox1), new HBox(hbox2)); > root.setSpacing(20); > Scene scene = new Scene(root, 500, 250); > > primaryStage.setScene(scene); > primaryStage.show(); > > > Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example. > ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png) > > I've filed a bug report and will change the title of the GitHub issue as soon as it's posted. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into fixes/box-snap-to-pixel - changed some method names, make test config a local class - added documentation, improved method names - Merge branch 'master' into fixes/box-snap-to-pixel - Fix pixel-snapping glitches in VBox/HBox - Failing test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/445/files - new: https://git.openjdk.org/jfx/pull/445/files/744f19f5..ecaed633 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=445&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=445&range=01-02 Stats: 584863 lines in 7798 files changed: 298388 ins; 179859 del; 106616 mod Patch: https://git.openjdk.org/jfx/pull/445.diff Fetch: git fetch https://git.openjdk.org/jfx pull/445/head:pull/445 PR: https://git.openjdk.org/jfx/pull/445 From mstrauss at openjdk.org Sat Jul 2 01:27:47 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 2 Jul 2022 01:27:47 GMT Subject: RFR: 8251483: TableCell: NPE on modifying item's list [v2] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 22:43:58 GMT, Marius Hanl wrote: >> This PR fixes an issue where the item of the table row is null, although the cell itself is not empty (non null value). >> >> The fix is to call `indexChanged(..)` immediately after the index was changed, but before all `indexProperty()` listener are notified. >> The then notified listener in `TableRowSkinBase` will update the underlying cells, which will eventually result in an call to `updateItem(..)`, where the NPE happened (and now not anymore, since the table row is now correctly setup before). >> >> There is one special case: When the index didn't changed at all, we manually call `indexChanged(..)` (just like before) since when a property is not changed, `invalidated()` is not called, but we need to notify subclasses that `updateIndex(..)` was called. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8251483: Updated copyright year The changed code makes sense, and fixes the issue. ------------- Marked as reviewed by mstrauss (Author). PR: https://git.openjdk.org/jfx/pull/741 From mstrauss at openjdk.org Sat Jul 2 02:35:50 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 2 Jul 2022 02:35:50 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException [v4] In-Reply-To: References: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Message-ID: On Wed, 22 Jun 2022 09:48:14 GMT, Florian Kirmaier wrote: >> Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. >> ticket: https://bugs.openjdk.java.net/browse/JDK-8256397 >> run test: `./gradlew --continue -PFULL_TEST=true controls:test --tests "*MultipleSelectionModelImplTest*"` > > Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge remote-tracking branch 'origjfx/master' into JDK-8256397 > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/MultipleSelectionModelImplTest.java > - JDK_8256397 > Added a small test-factory, to test more cases > - 8256397 > Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. modules/javafx.controls/src/test/java/test/javafx/scene/control/MultipleSelectionModelImplTest.java line 1452: > 1450: > 1451: @Test > 1452: public void test_8256397() throws InterruptedException { This test should probably get a meaningful name. ------------- PR: https://git.openjdk.org/jfx/pull/353 From mstrauss at openjdk.org Sat Jul 2 05:26:49 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 2 Jul 2022 05:26:49 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException In-Reply-To: References: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Message-ID: On Tue, 17 Nov 2020 12:38:32 GMT, Jeanette Winzenburg wrote: >> Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. >> ticket: https://bugs.openjdk.java.net/browse/JDK-8256397 >> run test: `./gradlew --continue -PFULL_TEST=true controls:test --tests "*MultipleSelectionModelImplTest*"` > > good catch :) > > No review, just a couple of comments: > > - other subclasses of MultipleSelectionModelBase might have similar issues > - the fix gets rid of the error (good!) but might fire incorrect changes (see below) > - there are quite a lot of open issues related to change notification, some might profit from a fix of this > - tests, tests, tests .. :) > > selectIndices might involve disjoint intervals in the change (even for addition which is unusual in the "normal" implementations of observableLists) > > // initial selection, starting from empty > selectionModel.selectIndices(0, /*1, IMPORTANT: remove some index */ 2, 3); > System.out.println(change); > // expected and actual change > { [0, 2, 3] added at 0 } > > // add selection of disjoint indices (assuming a longer items list) > selectionModel.selectIndices(1, 5, 7); > System.out.println(change); > // actual > { [1, 2, 3] added at 1 } > // expected > { [1] added at 1, [5, 7] added at 4 } I don't understand how the original code, as well as the proposed solution, can work at all. Let's take @kleopatra's example: selectionModel.selectIndices(0, 2, 3); // ---> expected: { [0, 2, 3] added at 0 } selectionModel.selectIndices(1, 5, 7); // ---> expected: { [1] added at 1, [5, 7] added at 4 } In order to find the two sub-ranges `[1]` and `[5, 7]`, we need to compare the _newly added_ indices to the _entire_ list of selected indices. Without doing that, we can't just "know" that there are two contiguous sub-ranges in `[1, 5, 7]`. However, the algorithm that supposedly tries to do that, doesn't even look at the current list of selected indices (except for a single `indexOf` call, which doesn't do the trick): int pos = 0; int start = 0; int end = 0; // starting from pos, we keep going until the value is // not the next value int startValue = sortedNewIndices.get(pos++); start = indexOf(startValue); end = start + 1; int endValue = startValue; while (pos < size) { int previousEndValue = endValue; endValue = sortedNewIndices.get(pos++); ++end; if (previousEndValue != (endValue - 1)) { _nextAdd(start, end); start = end; continue; } // special case for when we get to the point where the loop is about to end // and we have uncommitted changes to fire. if (pos == size) { _nextAdd(start, end); } } I think this algorithm mistakenly finds contiguous ranges within the list of _newly added_ indices, which is not what we want. Here is an algorithm that works: int startIndex = indexOf(sortedNewIndices.get(0)); int endIndex = startIndex + 1; for (int i = 1; i < sortedNewIndices.size(); ++i) { int currentValue = get(endIndex); int currentNewValue = sortedNewIndices.get(i); if (currentValue != currentNewValue) { _nextAdd(startIndex, endIndex); while (get(endIndex) != currentNewValue) ++endIndex; startIndex = endIndex++; } else { ++endIndex; } if (i == sortedNewIndices.size() - 1) { _nextAdd(startIndex, endIndex); } } Unfortunately, even with the working algorithm, the list change notifications are still not correct in all cases due to another (probably unrelated) bug in `SelectedIndicesList.get(int)`: If I remove the optimization that is implemented in that method, and replace it with a simple lookup, the notifications are always correct in my tests: @Override public Integer get(int index) { for (int lastGetIndex = 0, lastGetValue = bitset.nextSetBit(0); lastGetValue >= 0 || lastGetIndex == index; lastGetIndex++, lastGetValue = bitset.nextSetBit(lastGetValue + 1)) { if (lastGetIndex == index) { return lastGetValue; } } return -1; } Test 1: selectionModel.selectIndices(0, 2, 3); // ---> { [0, 2, 3] added at 0 } selectionModel.selectIndices(1, 5, 7); // ---> { [1] added at 1, [5, 7] added at 4 } Test 2: selectionModel.selectIndices(1, 3, 4); // ---> { [1, 3, 4] added at 0 } selectionModel.selectIndices(0, 5, 7); // ---> { [0] added at 0, [5, 7] added at 4 } selectionModel.selectIndices(6, 8, 9); // ---> { [6] added at 5, [8, 9] added at 7 } ------------- PR: https://git.openjdk.org/jfx/pull/353 From kcr at openjdk.org Sat Jul 2 11:52:33 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 2 Jul 2022 11:52:33 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v6] In-Reply-To: <9LxdzDx_IKxgrNdEl6cKqDxRu9Z_BBQzSbvn-yv0GEE=.45a0ec0b-0ab0-4b67-9a45-c310999a45f3@github.com> References: <9LxdzDx_IKxgrNdEl6cKqDxRu9Z_BBQzSbvn-yv0GEE=.45a0ec0b-0ab0-4b67-9a45-c310999a45f3@github.com> Message-ID: On Fri, 1 Jul 2022 12:16:36 GMT, Marius Hanl wrote: >> This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. >> >> I also added tests which will succeed before and after to verify that nothing got broken by this change. >> Also I made a benchmark test. Results: >> >> | Benchmark | Mode| Cnt | Score | Error | Units >> | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | >> | ListBenchmark OLD | thrpt | 25 | 722,842 | ? 26,93 | ops/s >> | ListBenchmark NEW | thrpt | 25 | 29262,274 | ? 2088,712 | ops/s >> >> Edit: I also made a synthetic benchmark by measuring the same code below 100 times with `System.nanoTime`. >> ListBenchmark OLD (avg): 21-23ms >> ListBenchmark NEW (avg): 2 ms >> >>
Benchmark code >> >> >> import javafx.collections.FXCollections; >> import javafx.collections.ObservableList; >> import org.openjdk.jmh.annotations.Benchmark; >> import org.openjdk.jmh.annotations.Scope; >> import org.openjdk.jmh.annotations.Setup; >> import org.openjdk.jmh.annotations.State; >> import org.openjdk.jmh.annotations.TearDown; >> >> import java.util.ArrayList; >> import java.util.List; >> >> @State(Scope.Benchmark) >> public class ListBenchmark { >> >> List strings; >> >> @Setup >> public void setup() { >> strings = new ArrayList<>(); >> for(int i = 0; i< 100000;i++) { >> strings.add("abc: " + i); >> } >> } >> >> @TearDown >> public void tearDown() { >> strings = null; >> } >> >> @Benchmark >> public ObservableList init() { >> return FXCollections.observableArrayList(strings); >> } >> } >> >> >>
> > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8283346: Inline ArrayList creation Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/758 From mhanl at openjdk.org Sat Jul 2 12:40:32 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 2 Jul 2022 12:40:32 GMT Subject: Integrated: 8283346: Optimize observable ArrayList creation in FXCollections In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 21:10:14 GMT, Marius Hanl wrote: > This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. > > I also added tests which will succeed before and after to verify that nothing got broken by this change. > Also I made a benchmark test. Results: > > | Benchmark | Mode| Cnt | Score | Error | Units > | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | > | ListBenchmark OLD | thrpt | 25 | 722,842 | ? 26,93 | ops/s > | ListBenchmark NEW | thrpt | 25 | 29262,274 | ? 2088,712 | ops/s > > Edit: I also made a synthetic benchmark by measuring the same code below 100 times with `System.nanoTime`. > ListBenchmark OLD (avg): 21-23ms > ListBenchmark NEW (avg): 2 ms > >
Benchmark code > > > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import org.openjdk.jmh.annotations.Benchmark; > import org.openjdk.jmh.annotations.Scope; > import org.openjdk.jmh.annotations.Setup; > import org.openjdk.jmh.annotations.State; > import org.openjdk.jmh.annotations.TearDown; > > import java.util.ArrayList; > import java.util.List; > > @State(Scope.Benchmark) > public class ListBenchmark { > > List strings; > > @Setup > public void setup() { > strings = new ArrayList<>(); > for(int i = 0; i< 100000;i++) { > strings.add("abc: " + i); > } > } > > @TearDown > public void tearDown() { > strings = null; > } > > @Benchmark > public ObservableList init() { > return FXCollections.observableArrayList(strings); > } > } > > >
This pull request has now been integrated. Changeset: b3eca1f6 Author: Marius Hanl Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/b3eca1f64977343c06e6035fab385935055b6d6b Stats: 49 lines in 2 files changed: 41 ins; 4 del; 4 mod 8283346: Optimize observable ArrayList creation in FXCollections Reviewed-by: mstrauss, nlisker, kcr ------------- PR: https://git.openjdk.org/jfx/pull/758 From mstrauss at openjdk.org Sat Jul 2 15:47:20 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 2 Jul 2022 15:47:20 GMT Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value [v4] In-Reply-To: References: Message-ID: > The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa. > > The following program shows the problem for HBox: > > Region r1 = new Region(); > Region r2 = new Region(); > Region r3 = new Region(); > Region r4 = new Region(); > Region r5 = new Region(); > Region r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6); > hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox1.setPrefHeight(40); > > r1 = new Region(); > r2 = new Region(); > r3 = new Region(); > r4 = new Region(); > r5 = new Region(); > r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6); > hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox2.setPrefHeight(40); > hbox2.setPrefWidth(152); > > VBox root = new VBox(new HBox(hbox1), new HBox(hbox2)); > root.setSpacing(20); > Scene scene = new Scene(root, 500, 250); > > primaryStage.setScene(scene); > primaryStage.show(); > > > Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example. > ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png) > > I've filed a bug report and will change the title of the GitHub issue as soon as it's posted. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Improved code documentation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/445/files - new: https://git.openjdk.org/jfx/pull/445/files/ecaed633..c1835959 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=445&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=445&range=02-03 Stats: 79 lines in 2 files changed: 58 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jfx/pull/445.diff Fetch: git fetch https://git.openjdk.org/jfx pull/445/head:pull/445 PR: https://git.openjdk.org/jfx/pull/445 From mstrauss at openjdk.org Sun Jul 3 15:01:19 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 3 Jul 2022 15:01:19 GMT Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value [v5] In-Reply-To: References: Message-ID: > The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa. > > The following program shows the problem for HBox: > > Region r1 = new Region(); > Region r2 = new Region(); > Region r3 = new Region(); > Region r4 = new Region(); > Region r5 = new Region(); > Region r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6); > hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox1.setPrefHeight(40); > > r1 = new Region(); > r2 = new Region(); > r3 = new Region(); > r4 = new Region(); > r5 = new Region(); > r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6); > hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox2.setPrefHeight(40); > hbox2.setPrefWidth(152); > > VBox root = new VBox(new HBox(hbox1), new HBox(hbox2)); > root.setSpacing(20); > Scene scene = new Scene(root, 500, 250); > > primaryStage.setScene(scene); > primaryStage.show(); > > > Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example. > ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png) > > I've filed a bug report and will change the title of the GitHub issue as soon as it's posted. Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - revert snappedSum - don't call snappedSum in hot loop ------------- Changes: - all: https://git.openjdk.org/jfx/pull/445/files - new: https://git.openjdk.org/jfx/pull/445/files/c1835959..e8ffd3d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=445&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=445&range=03-04 Stats: 36 lines in 2 files changed: 4 ins; 8 del; 24 mod Patch: https://git.openjdk.org/jfx/pull/445.diff Fetch: git fetch https://git.openjdk.org/jfx pull/445/head:pull/445 PR: https://git.openjdk.org/jfx/pull/445 From nlisker at openjdk.org Sun Jul 3 20:18:16 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 3 Jul 2022 20:18:16 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Fri, 1 Jul 2022 15:16:24 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request 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 27 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/fluent-bindings > - Add null checks in Subscription > - Update copyrights > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API > - ... and 17 more: https://git.openjdk.org/jfx/compare/65ebda05...d66f2ba6 Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/675 From nlisker at openjdk.org Sun Jul 3 23:39:36 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 3 Jul 2022 23:39:36 GMT Subject: RFR: 8283063: Optimize Observable{List/Set/Map}Wrapper.retainAll/removeAll In-Reply-To: References: Message-ID: <-aiwH9PDbedjpWb7bH4HslseE9dcMsYURM9exz-aKUQ=.ad96630a-350a-4a1a-8d6e-612a501a0032@github.com> On Sat, 12 Mar 2022 04:57:37 GMT, Michael Strau? wrote: > `Observable{List/Set/Map}Wrapper.retainAll/removeAll` can be optimized for some edge cases. > > 1. `removeAll(c)`: > This is a no-op if 'c' is empty. > For `ObservableListWrapper`, returning early skips an object allocation. For `ObservableSetWrapper` and `ObservableMapWrapper`, returning early prevents an enumeration of the entire collection. > > 2. `retainAll(c)`: > This is a no-op if the backing collection is empty, or equivalent to `clear()` if `c` is empty. > > I've added some tests to verify the optimized behavior for each of the three classes. Not sure if you want to do this as part of this fix, but `ModifiableObservableListBase#addAll` can also be optimized in a similar way by checking if `c` is empty. The other methods there can also be optimized, but the `ObservableListWrappe` class overrides them anyway, so it depends on how inclusive you want this change to be. modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableSetWrapper.java line 359: > 357: > 358: return false; > 359: } This is good, but if `!c.isEmpty()` then we can optimize too, I think: if `backingSet.isEmpty()`, then removing/retaining all will also return `false`. Then again, the iterator will return quickly, so it might not do much. If you take this path, I think that doing these optimizations in the `removeAll` and `retainAll` before calling this method will be clearer, similarly to how it's done in the `List` case. Same comment for the `Map` wrapper. ------------- PR: https://git.openjdk.org/jfx/pull/751 From jvos at openjdk.org Mon Jul 4 13:17:51 2022 From: jvos at openjdk.org (Johan Vos) Date: Mon, 4 Jul 2022 13:17:51 GMT Subject: [jfx17u] Integrated: 8286261: Selection of non-expanded non-leaf treeItem grows unexpectedly when adding two-level descendants In-Reply-To: <0DKkqNHCqRB_Scpvdpxc1vjbXqZo-oyMF9xxzn5gR80=.d9ecbd3b-3eb3-46b3-ad51-385e24934b4f@github.com> References: <0DKkqNHCqRB_Scpvdpxc1vjbXqZo-oyMF9xxzn5gR80=.d9ecbd3b-3eb3-46b3-ad51-385e24934b4f@github.com> Message-ID: On Wed, 29 Jun 2022 19:43:14 GMT, Johan Vos wrote: > 8286261: Selection of non-expanded non-leaf treeItem grows unexpectedly when adding two-level descendants > > Reviewed-by: aghaisas This pull request has now been integrated. Changeset: d3c26c46 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/d3c26c4613a995c3ea0b15286c3de70b0463d33e Stats: 179 lines in 5 files changed: 171 ins; 0 del; 8 mod 8286261: Selection of non-expanded non-leaf treeItem grows unexpectedly when adding two-level descendants Backport-of: 19a855e8ec3972377359ecbc0f71808f34c1b288 ------------- PR: https://git.openjdk.org/jfx17u/pull/70 From jvos at openjdk.org Mon Jul 4 14:00:23 2022 From: jvos at openjdk.org (Johan Vos) Date: Mon, 4 Jul 2022 14:00:23 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed Message-ID: In order to fix the issues reported in JDK-8089589, the VirtualFlow now uses the real sizes of the elements that are displayed. This allows for a more natural way of scrolling through lists that contain items of very different sizes. The algorithm that is used, does not calculate the size of each individual cell upfront, as that would be a major performance overhead (especially for large lists). Instead, we estimate the total size and the size of the individual cells based on the real measured size of a (growing) number of cells. There are a number of key variables that depend on this estimated size: * position * aboluteOffset * currentIndex As a consequence, when the estimated size is changing, the absoluteOffset may change which may lead to a new currentIndex. If this happens during a layout phase, or a "complex" operation (e.g. scroll to an item and select it), this may lead to visually unexpected artifacts. While the rendering becomes more "correct" when the estimated size is improving, it is more important that we do not create visual confusion. The difficulty is that there are a large number of ways to manipulate the VirtualFlow, and different entry points may have different expectations about which variables should be kept constant (or only changed gradually). In this PR, we focus on consistency in the scrollTo method, where we want to keep the top-cell constant. In case the estimated size is improved during the scrollTo execution, or the next layoutChildren invocation, this implies keeping the result of computeCurrentIndex() constant so that after scrolling to a cell and selecting it, the selected cell is indeed the one that is scrolled to. This PR contains a number of tests for this scrollTo behaviour, that should also be considered as regression test in case we want to add more invariants later. ------------- Commit messages: - Add more consistency between key-values. The position, absoluteOffset and currentIndex Changes: https://git.openjdk.org/jfx/pull/808/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=808&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8277785 Stats: 372 lines in 4 files changed: 333 ins; 19 del; 20 mod Patch: https://git.openjdk.org/jfx/pull/808.diff Fetch: git fetch https://git.openjdk.org/jfx pull/808/head:pull/808 PR: https://git.openjdk.org/jfx/pull/808 From mstrauss at openjdk.org Mon Jul 4 16:35:49 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 4 Jul 2022 16:35:49 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 13:52:40 GMT, Johan Vos wrote: > In order to fix the issues reported in JDK-8089589, the VirtualFlow now uses the real sizes of the elements that are displayed. This allows for a more natural way of scrolling through lists that contain items of very different sizes. > The algorithm that is used, does not calculate the size of each individual cell upfront, as that would be a major performance overhead (especially for large lists). Instead, we estimate the total size and the size of the individual cells based on the real measured size of a (growing) number of cells. > > There are a number of key variables that depend on this estimated size: > * position > * aboluteOffset > * currentIndex > > As a consequence, when the estimated size is changing, the absoluteOffset may change which may lead to a new currentIndex. If this happens during a layout phase, or a "complex" operation (e.g. scroll to an item and select it), this may lead to visually unexpected artifacts. While the rendering becomes more "correct" when the estimated size is improving, it is more important that we do not create visual confusion. > > The difficulty is that there are a large number of ways to manipulate the VirtualFlow, and different entry points may have different expectations about which variables should be kept constant (or only changed gradually). > > In this PR, we focus on consistency in the scrollTo method, where we want to keep the top-cell constant. In case the estimated size is improved during the scrollTo execution, or the next layoutChildren invocation, this implies keeping the result of computeCurrentIndex() constant so that after scrolling to a cell and selecting it, the selected cell is indeed the one that is scrolled to. > > This PR contains a number of tests for this scrollTo behaviour, that should also be considered as regression test in case we want to add more invariants later. The proposed PR also fixes the issue with `setPosition` described [here](https://bugs.openjdk.org/browse/JDK-8278064). ------------- PR: https://git.openjdk.org/jfx/pull/808 From mhanl at openjdk.org Tue Jul 5 03:50:40 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 5 Jul 2022 03:50:40 GMT Subject: Integrated: 8251483: TableCell: NPE on modifying item's list In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 22:27:51 GMT, Marius Hanl wrote: > This PR fixes an issue where the item of the table row is null, although the cell itself is not empty (non null value). > > The fix is to call `indexChanged(..)` immediately after the index was changed, but before all `indexProperty()` listener are notified. > The then notified listener in `TableRowSkinBase` will update the underlying cells, which will eventually result in an call to `updateItem(..)`, where the NPE happened (and now not anymore, since the table row is now correctly setup before). > > There is one special case: When the index didn't changed at all, we manually call `indexChanged(..)` (just like before) since when a property is not changed, `invalidated()` is not called, but we need to notify subclasses that `updateIndex(..)` was called. This pull request has now been integrated. Changeset: 222b2b11 Author: Marius Hanl Committer: Ajit Ghaisas URL: https://git.openjdk.org/jfx/commit/222b2b11ee58717eb355eac86ad39fffea256d00 Stats: 76 lines in 3 files changed: 67 ins; 0 del; 9 mod 8251483: TableCell: NPE on modifying item's list Reviewed-by: aghaisas, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/741 From jvos at openjdk.org Tue Jul 5 11:42:08 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 5 Jul 2022 11:42:08 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Fri, 1 Jul 2022 15:16:24 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request 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 27 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/fluent-bindings > - Add null checks in Subscription > - Update copyrights > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API > - ... and 17 more: https://git.openjdk.org/jfx/compare/598c4dd7...d66f2ba6 Given the general consensus, I am ok with this being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/675 From kevin.rushforth at oracle.com Tue Jul 5 15:45:01 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 5 Jul 2022 08:45:01 -0700 Subject: New unit test failures with latest jfx master Message-ID: As a heads-up, a recent integration has caused many new unit test failures in the javafx.controls module. JDK-8289751 [1] has been filed to track this. This bug will either be fixed, or else the commit in question will be backed out within the next 12-16 hours. -- Kevin [1] https://bugs.openjdk.org/browse/JDK-8289751 From mstrauss at openjdk.org Tue Jul 5 17:18:18 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Jul 2022 17:18:18 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Fri, 1 Jul 2022 15:16:24 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request 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 27 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/fluent-bindings > - Add null checks in Subscription > - Update copyrights > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API > - ... and 17 more: https://git.openjdk.org/jfx/compare/b8ce56f8...d66f2ba6 I have yet another question. The following test passes for `Bindings.select`, but fails for `ObservableValue.flatMap`: JMemoryBuddy.memoryTest(test -> { class ValueHolder { final StringProperty value = new SimpleStringProperty(this, "value"); StringProperty valueProperty() { return value; } } ObjectProperty valueHolderProperty = new SimpleObjectProperty<>(); valueHolderProperty.set(new ValueHolder()); // Map the nested property value ObservableValue mapped = valueHolderProperty.flatMap(ValueHolder::valueProperty); // Note: the test passes when using the following alternative to flatMap: // ObservableValue mapped = Bindings.selectString(valueHolderProperty, "value"); // Bind the mapped value to a property that will soon be GC'ed. ObjectProperty otherProperty = new SimpleObjectProperty<>(); otherProperty.bind(mapped); test.setAsReferenced(valueHolderProperty); test.assertCollectable(otherProperty); test.assertCollectable(mapped); // expectation: the mapped value is eligible for GC }); My observation is that a flat-mapped value that was once observed is not eligible for garbage-collection even when the observer itself is collected. This seems to be quite unexpected to me, because it means that a bound property that is collected without being manually unbound will cause a memory leak in the mapped binding. Is this by design? If so, I think this can lead to subtle and hard to diagnose bugs, and should be documented at the very least. ------------- PR: https://git.openjdk.org/jfx/pull/675 From duke at openjdk.org Tue Jul 5 18:46:57 2022 From: duke at openjdk.org (Andy Goryachev) Date: Tue, 5 Jul 2022 18:46:57 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 17:33:32 GMT, Andy Goryachev wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8289255 > - Revert "8279297: removed unused Shape.setMode method" > > This reverts commit 6b3b7e51f168a02f68c3bc0324528164680cb6c9. > - 8279297: removed unused Shape.setMode method > - 8289255: reverted gradlew > - 8289255: reverted gradlew > - 8289255: remove executable flag > - 8289255: updated eclipse .classpath and other configuration files Note: tests are failing due to JDK-8289751 ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Tue Jul 5 19:01:31 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Jul 2022 19:01:31 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 18:40:40 GMT, Andy Goryachev wrote: >> I marked line 9, which is `src/test/java`. This folder does not exist in the repo, but the classpath file defines it. It creates an error. Do you not get this error? > > there is nothing in javafx.swing/src/test/java (no tests??) > git does not version directories, unlike some other VCs. I wonder if we should either add a dummy file there, or may be create a test? FWIW, the only test in `modules/javafx.swing/src/test/java` was removed by [JDK-8234110](https://bugs.openjdk.org/browse/JDK-8234110). While we could put in a dummy test class, the nature of the javafx.swing module is that unit tests are unlikely to be useful (which is why the one test that was there was moved to the system tests area with all the other Swing interop tests). ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Tue Jul 5 18:46:58 2022 From: duke at openjdk.org (Andy Goryachev) Date: Tue, 5 Jul 2022 18:46:58 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 18:10:51 GMT, Nir Lisker wrote: >> line 4 is >> >> shims seem to be required, notice you get a bunch of shim-related warnings above. > > I marked line 9, which is `src/test/java`. This folder does not exist in the repo, but the classpath file defines it. It creates an error. Do you not get this error? there is nothing in javafx.swing/src/test/java (no tests??) git does not version directories, unlike some other VCs. I wonder if we should either add a dummy file there, or may be create a test? ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Tue Jul 5 18:52:33 2022 From: duke at openjdk.org (Andy Goryachev) Date: Tue, 5 Jul 2022 18:52:33 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 18:23:23 GMT, Nir Lisker wrote: >> 1. I will try to incorporate your changes, especially in apps/. My initial goal was to fix the build of everything except apps/ >> 2. I do get some warnings, they will be addressed by other fixes under JDK-8289379. But others (ex: MacPasteboardShim) I do not see, as those have been fixed. Could you please make sure you have no modified files and do a refresh? >> 3. Could you clarify your point about build/hlsl/Decora and build/hlsl/Prism please? I noticed there is nothing there, and nothing seem to be put there. Also, there are build/gensrc/jsl-prism and build/gensrc/jsl-decora directories being created, so I felt we can remove these entries from .classpath. I do build on Mac though. > > 1. The way the apps are structured is that each app is its own project, which means that there are many new projects to create and configure. It can be a bit of work, though I have done it in my branch already. If you want to leave it to round 2 of fixing the Eclipse files it's fine. > > 2+3. I worked directly from master and from your branch, so no files have been changed. The folders under `build` are OS-specific and are generated as needed by the build. Since you are on Mac, it would explain why the hlsl folders are empty, but they are not empty on Windows. This is why they are marked as "ignore_optional_problems" - to not produce errors even on the wrong system. Since they don't contain Java classes that are referenced by the build (as far as I could tell), it should be safe to remove the `build/...` source folders in general. I don't know if on Mac you get any issues, but I assume you don't. 1. I would rather leave the apps/ for day 2, if I may. 2+3. Currently, on Mac, I don't see any issues related to build/... folders. I think, generally speaking, it's a bad idea to refer to derived folders as source - it complicates the build process in Eclipse. Does my branch fail on windows in Eclipse, Nir? I mean, do I need to make changes to address this comment? ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Tue Jul 5 19:07:18 2022 From: duke at openjdk.org (Andy Goryachev) Date: Tue, 5 Jul 2022 19:07:18 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 18:58:21 GMT, Kevin Rushforth wrote: >> there is nothing in javafx.swing/src/test/java (no tests??) >> git does not version directories, unlike some other VCs. I wonder if we should either add a dummy file there, or may be create a test? > > FWIW, the only test in `modules/javafx.swing/src/test/java` was removed by [JDK-8234110](https://bugs.openjdk.org/browse/JDK-8234110). While we could put in a dummy test class, the nature of the javafx.swing module is that unit tests are unlikely to be useful (which is why the one test that was there was moved to the system tests area with all the other Swing interop tests). will remove src/test/java from swing .classpath thank you, Kevin. ------------- PR: https://git.openjdk.org/jfx/pull/804 From nlisker at openjdk.org Tue Jul 5 18:26:51 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 5 Jul 2022 18:26:51 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 17:50:26 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/.classpath line 5: >> >>> 3: >>> 4: >>> 5: >> >> I think that you can remove these source folders too. >> >> Did you get errors with `build/hlsl/Decora` and `build/hlsl/Prism`? These are generated for Windows, so possibly on Linux/Mac you would get errors, but marking them with "ignore_optional_problems" should resolve these. >> >> In general, we should be able to remove OS-specific folders. > > 1. I will try to incorporate your changes, especially in apps/. My initial goal was to fix the build of everything except apps/ > 2. I do get some warnings, they will be addressed by other fixes under JDK-8289379. But others (ex: MacPasteboardShim) I do not see, as those have been fixed. Could you please make sure you have no modified files and do a refresh? > 3. Could you clarify your point about build/hlsl/Decora and build/hlsl/Prism please? I noticed there is nothing there, and nothing seem to be put there. Also, there are build/gensrc/jsl-prism and build/gensrc/jsl-decora directories being created, so I felt we can remove these entries from .classpath. I do build on Mac though. 1. The way the apps are structured is that each app is its own project, which means that there are many new projects to create and configure. It can be a bit of work, though I have done it in my branch already. If you want to leave it to round 2 of fixing the Eclipse files it's fine. 2+3. I worked directly from master and from your branch, so no files have been changed. The folders under `build` are OS-specific and are generated as needed by the build. Since you are on Mac, it would explain why the hlsl folders are empty, but they are not empty on Windows. This is why they are marked as "ignore_optional_problems" - to not produce errors even on the wrong system. Since they don't contain Java classes that are referenced by the build (as far as I could tell), it should be safe to remove the `build/...` source folders in general. I don't know if on Mac you get any issues, but I assume you don't. ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Tue Jul 5 19:07:18 2022 From: duke at openjdk.org (Andy Goryachev) Date: Tue, 5 Jul 2022 19:07:18 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v3] In-Reply-To: References: Message-ID: > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8289255 remove javafx.swing/src/test/java as source folder ------------- Changes: - all: https://git.openjdk.org/jfx/pull/804/files - new: https://git.openjdk.org/jfx/pull/804/files/9b6cb4c9..ecb43690 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/804.diff Fetch: git fetch https://git.openjdk.org/jfx pull/804/head:pull/804 PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Tue Jul 5 17:54:54 2022 From: duke at openjdk.org (Andy Goryachev) Date: Tue, 5 Jul 2022 17:54:54 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v2] In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 18:47:57 GMT, Nir Lisker wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8289255 >> - Revert "8279297: removed unused Shape.setMode method" >> >> This reverts commit 6b3b7e51f168a02f68c3bc0324528164680cb6c9. >> - 8279297: removed unused Shape.setMode method >> - 8289255: reverted gradlew >> - 8289255: reverted gradlew >> - 8289255: remove executable flag >> - 8289255: updated eclipse .classpath and other configuration files > > modules/javafx.graphics/.classpath line 5: > >> 3: >> 4: >> 5: > > I think that you can remove these source folders too. > > Did you get errors with `build/hlsl/Decora` and `build/hlsl/Prism`? These are generated for Windows, so possibly on Linux/Mac you would get errors, but marking them with "ignore_optional_problems" should resolve these. > > In general, we should be able to remove OS-specific folders. 1. I will try to incorporate your changes, especially in apps/. My initial goal was to fix the build of everything except apps/ 2. I do get some warnings, they will be addressed by other fixes under JDK-8289379. But others (ex: MacPasteboardShim) I do not see, as those have been fixed. Could you please make sure you have no modified files and do a refresh? 3. Could you clarify your point about build/hlsl/Decora and build/hlsl/Prism please? I noticed there is nothing there, and nothing seem to be put there. Also, there are build/gensrc/jsl-prism and build/gensrc/jsl-decora directories being created, so I felt we can remove these entries from .classpath. I do build on Mac though. > modules/javafx.swing/.classpath line 9: > >> 7: >> 8: >> 9: > > This folder doesn't exist, it should be giving you an error, does it not? line 4 is shims seem to be required, notice you get a bunch of shim-related warnings above. ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Tue Jul 5 20:24:38 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Jul 2022 20:24:38 GMT Subject: RFR: 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 In-Reply-To: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> References: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> Message-ID: <3prFmfS9Yc8hHdYV10k_d5NrwMHG-e3YyevOO_vNm0Y=.2eb40162-5c8d-4c22-9661-cd92d8c42e92@github.com> On Tue, 5 Jul 2022 19:23:13 GMT, Jose Pereda wrote: > This PR solves an IAE exception that happens when invoking a ColorChooser control within a WebView, by getting the r, g, b values from the Color before calling the colorChooser. > > A system test is included, to verify that there is no exception and the two native functions that are modified produce the expected color components. I'll review this. @arapte or @jaybhaskar can one you also review? Btw, the failing GHA tests are due to [JDK-8289751](https://bugs.openjdk.org/browse/JDK-8289751). Since web tests and system tests aren't run on GHA the failures aren't relevant. ------------- PR: https://git.openjdk.org/jfx/pull/809 From duke at openjdk.org Tue Jul 5 17:33:32 2022 From: duke at openjdk.org (Andy Goryachev) Date: Tue, 5 Jul 2022 17:33:32 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v2] In-Reply-To: References: Message-ID: > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8289255 - Revert "8279297: removed unused Shape.setMode method" This reverts commit 6b3b7e51f168a02f68c3bc0324528164680cb6c9. - 8279297: removed unused Shape.setMode method - 8289255: reverted gradlew - 8289255: reverted gradlew - 8289255: remove executable flag - 8289255: updated eclipse .classpath and other configuration files ------------- Changes: - all: https://git.openjdk.org/jfx/pull/804/files - new: https://git.openjdk.org/jfx/pull/804/files/b847bd38..9b6cb4c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=00-01 Stats: 125 lines in 5 files changed: 108 ins; 4 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/804.diff Fetch: git fetch https://git.openjdk.org/jfx pull/804/head:pull/804 PR: https://git.openjdk.org/jfx/pull/804 From nlisker at openjdk.org Tue Jul 5 19:20:47 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 5 Jul 2022 19:20:47 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 19:02:20 GMT, Andy Goryachev wrote: >> FWIW, the only test in `modules/javafx.swing/src/test/java` was removed by [JDK-8234110](https://bugs.openjdk.org/browse/JDK-8234110). While we could put in a dummy test class, the nature of the javafx.swing module is that unit tests are unlikely to be useful (which is why the one test that was there was moved to the system tests area with all the other Swing interop tests). > > will remove src/test/java from swing .classpath > thank you, Kevin. > there is nothing in javafx.swing/src/test/java (no tests??) git does not version directories, unlike some other VCs. I think I understand now why you didn't see the error. You had an empty folder, for some reason, that made Eclipse satisfied with the classpath file entry. The folder does not exist in the repo, so I expect anyone who clones it to get an error for a missing folder. This is why I removed it in my branch. ------------- PR: https://git.openjdk.org/jfx/pull/804 From jpereda at openjdk.org Tue Jul 5 19:29:20 2022 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Jul 2022 19:29:20 GMT Subject: RFR: 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 Message-ID: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> This PR solves an IAE exception that happens when invoking a ColorChooser control within a WebView, by getting the r, g, b values from the Color before calling the colorChooser. A system test is included, to verify that there is no exception and the two native functions that are modified produce the expected color components. ------------- Commit messages: - Get rgb values from color before calling colorChooser, including test Changes: https://git.openjdk.org/jfx/pull/809/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=809&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289587 Stats: 184 lines in 3 files changed: 178 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/809.diff Fetch: git fetch https://git.openjdk.org/jfx pull/809/head:pull/809 PR: https://git.openjdk.org/jfx/pull/809 From mhanl at openjdk.org Tue Jul 5 20:40:43 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 5 Jul 2022 20:40:43 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v4] In-Reply-To: References: Message-ID: > Initialize the `(Tree)TableView` when creating the measure row. > This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). > > With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. > I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 > > Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit` is not triggered twice. Some tests catched that (see `test_rt_31015`). Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing ------------- Changes: - all: https://git.openjdk.org/jfx/pull/805/files - new: https://git.openjdk.org/jfx/pull/805/files/b6dcccdb..eb95e91d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=805&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=805&range=02-03 Stats: 125 lines in 5 files changed: 108 ins; 4 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/805.diff Fetch: git fetch https://git.openjdk.org/jfx pull/805/head:pull/805 PR: https://git.openjdk.org/jfx/pull/805 From nlisker at openjdk.org Tue Jul 5 18:13:41 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 5 Jul 2022 18:13:41 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 17:52:24 GMT, Andy Goryachev wrote: >> modules/javafx.swing/.classpath line 9: >> >>> 7: >>> 8: >>> 9: >> >> This folder doesn't exist, it should be giving you an error, does it not? > > line 4 is > > shims seem to be required, notice you get a bunch of shim-related warnings above. I marked line 9, which is `src/test/java`. This folder does not exist in the repo, but the classpath file defines it. It creates an error. Do you not get this error? ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Tue Jul 5 22:36:38 2022 From: duke at openjdk.org (Andy Goryachev) Date: Tue, 5 Jul 2022 22:36:38 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v4] In-Reply-To: References: Message-ID: > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8289255 remove javafx.graphics/build/gensrc as source folder ------------- Changes: - all: https://git.openjdk.org/jfx/pull/804/files - new: https://git.openjdk.org/jfx/pull/804/files/ecb43690..3095904b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/804.diff Fetch: git fetch https://git.openjdk.org/jfx pull/804/head:pull/804 PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Tue Jul 5 23:23:55 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Jul 2022 23:23:55 GMT Subject: RFR: 8289751: Multiple unit test failures after JDK-8251483 In-Reply-To: <65vgp8GcZluZgnts5nLsprGqo6SzvzAbEQqRcbeMIkU=.d830cf6b-6ca1-45cd-b4fe-9e3d7c766138@github.com> References: <65vgp8GcZluZgnts5nLsprGqo6SzvzAbEQqRcbeMIkU=.d830cf6b-6ca1-45cd-b4fe-9e3d7c766138@github.com> Message-ID: On Tue, 5 Jul 2022 23:09:37 GMT, Marius Hanl wrote: > As also discussed in the ticket, we need to disable/ignore this two tests for now. > > With the fix for [JDK-8251483](https://bugs.openjdk.org/browse/JDK-8251483) the table row item is never null in a non empty table cell. > In the meantime with [JDK-8251480](https://bugs.openjdk.org/browse/JDK-8251480) and [JDK-8285197](https://bugs.openjdk.org/browse/JDK-8285197) we changed the table column header autosizing to be more complete by adding the table row to the setup. > Unfortunately we don't set the table view for the table row, therefore it can not know the underlying item (he knows the index but not where he can get the corresponding data for that index) -> table row item can be null in a non empty table cell (again). > > This will be fixed in https://github.com/openjdk/jfx/pull/805 (and the tests can be reenabled) Looks good. I confirm that all tests pass after this. As discussed in the JBS issue, we might want to file a follow-on issue to investigate the cascading failures caused when these two tests fail. Thank you for fixing this quickly. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/811 From mhanl at openjdk.org Tue Jul 5 23:27:39 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 5 Jul 2022 23:27:39 GMT Subject: RFR: 8289751: Multiple unit test failures after JDK-8251483 In-Reply-To: References: <65vgp8GcZluZgnts5nLsprGqo6SzvzAbEQqRcbeMIkU=.d830cf6b-6ca1-45cd-b4fe-9e3d7c766138@github.com> Message-ID: On Tue, 5 Jul 2022 23:21:19 GMT, Kevin Rushforth wrote: > Thank you for fixing this quickly. Thank you very much for your time as well! I am glad that I could help. ------------- PR: https://git.openjdk.org/jfx/pull/811 From mhanl at openjdk.org Tue Jul 5 23:30:48 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 5 Jul 2022 23:30:48 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v5] In-Reply-To: References: Message-ID: > Initialize the `(Tree)TableView` when creating the measure row. > This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). > > With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. > I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 > > Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit` is not triggered twice. Some tests catched that (see `test_rt_31015`). Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Enable tests again - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing ------------- Changes: - all: https://git.openjdk.org/jfx/pull/805/files - new: https://git.openjdk.org/jfx/pull/805/files/eb95e91d..4839de00 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=805&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=805&range=03-04 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/805.diff Fetch: git fetch https://git.openjdk.org/jfx pull/805/head:pull/805 PR: https://git.openjdk.org/jfx/pull/805 From duke at openjdk.org Tue Jul 5 22:36:39 2022 From: duke at openjdk.org (Andy Goryachev) Date: Tue, 5 Jul 2022 22:36:39 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v4] In-Reply-To: References: Message-ID: <12jWuHH0mHFIa0RMNZQ1yyP6UKlPpVpcSfy8jUfDFoo=.4b538a6f-5c22-42a4-a70d-08e9889cef28@github.com> On Tue, 5 Jul 2022 21:45:54 GMT, Nir Lisker wrote: >> 1. I would rather leave the apps/ for day 2, if I may. >> 2+3. Currently, on Mac, I don't see any issues related to build/... folders. I think, generally speaking, it's a bad idea to refer to derived folders as source - it complicates the build process in Eclipse. Does my branch fail on windows in Eclipse, Nir? I mean, do I need to make changes to address this comment? > > I don't get any errors on the graphics module, I'm suggesting that you remove the entries: > > > good point. removing ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Tue Jul 5 21:44:43 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Jul 2022 21:44:43 GMT Subject: RFR: 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 In-Reply-To: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> References: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> Message-ID: <7pe3ExzzgIDUJTfyK3t474vBFrxtTMNtdgpKFR6EPLo=.467056e6-7ffa-4676-8b9b-270add7244f5@github.com> On Tue, 5 Jul 2022 19:23:13 GMT, Jose Pereda wrote: > This PR solves an IAE exception that happens when invoking a ColorChooser control within a WebView, by getting the r, g, b values from the Color before calling the colorChooser. > > A system test is included, to verify that there is no exception and the two native functions that are modified produce the expected color components. Looks good. I confirm that the new test fails without the fix and passes with the fix. I see the construct `auto [r, g, b, a] = color.toSRGBALossy()` is used in other places to similarly extract the color, so looks like it was just missed in the two places you found. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/809 From mstrauss at openjdk.org Tue Jul 5 22:20:44 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Jul 2022 22:20:44 GMT Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value [v5] In-Reply-To: References: Message-ID: On Sun, 3 Jul 2022 15:01:19 GMT, Michael Strau? wrote: >> The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa. >> >> The following program shows the problem for HBox: >> >> Region r1 = new Region(); >> Region r2 = new Region(); >> Region r3 = new Region(); >> Region r4 = new Region(); >> Region r5 = new Region(); >> Region r6 = new Region(); >> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); >> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); >> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); >> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); >> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); >> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); >> r1.setPrefWidth(25.3); >> r2.setPrefWidth(25.3); >> r3.setPrefWidth(25.4); >> r4.setPrefWidth(25.3); >> r5.setPrefWidth(25.3); >> r6.setPrefWidth(25.4); >> r1.setMaxHeight(30); >> r2.setMaxHeight(30); >> r3.setMaxHeight(30); >> r4.setMaxHeight(30); >> r5.setMaxHeight(30); >> r6.setMaxHeight(30); >> HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6); >> hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); >> hbox1.setPrefHeight(40); >> >> r1 = new Region(); >> r2 = new Region(); >> r3 = new Region(); >> r4 = new Region(); >> r5 = new Region(); >> r6 = new Region(); >> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); >> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); >> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); >> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); >> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); >> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); >> r1.setPrefWidth(25.3); >> r2.setPrefWidth(25.3); >> r3.setPrefWidth(25.4); >> r4.setPrefWidth(25.3); >> r5.setPrefWidth(25.3); >> r6.setPrefWidth(25.4); >> r1.setMaxHeight(30); >> r2.setMaxHeight(30); >> r3.setMaxHeight(30); >> r4.setMaxHeight(30); >> r5.setMaxHeight(30); >> r6.setMaxHeight(30); >> HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6); >> hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); >> hbox2.setPrefHeight(40); >> hbox2.setPrefWidth(152); >> >> VBox root = new VBox(new HBox(hbox1), new HBox(hbox2)); >> root.setSpacing(20); >> Scene scene = new Scene(root, 500, 250); >> >> primaryStage.setScene(scene); >> primaryStage.show(); >> >> >> Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example. >> ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png) >> >> I've filed a bug report and will change the title of the GitHub issue as soon as it's posted. > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - revert snappedSum > - don't call snappedSum in hot loop I've expanded the documentation of the improved algorithm, which hopefully makes it easier to understand the changes. ------------- PR: https://git.openjdk.org/jfx/pull/445 From mhanl at openjdk.org Tue Jul 5 23:18:13 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 5 Jul 2022 23:18:13 GMT Subject: RFR: 8289751: Multiple unit test failures after JDK-8251483 Message-ID: <65vgp8GcZluZgnts5nLsprGqo6SzvzAbEQqRcbeMIkU=.d830cf6b-6ca1-45cd-b4fe-9e3d7c766138@github.com> As also discussed in the ticket, we need to disable/ignore this two tests for now. With the fix for [JDK-8251483](https://bugs.openjdk.org/browse/JDK-8251483) the table row item is never null in a non empty table cell. In the meantime with [JDK-8251480](https://bugs.openjdk.org/browse/JDK-8251480) and [JDK-8285197](https://bugs.openjdk.org/browse/JDK-8285197) we changed the table column header autosizing to be more complete by adding the table row to the setup. Unfortunately we don't set the table view for the table row, therefore it can not know the underlying item (he knows the index but not where he can get the corresponding data for that index) -> table row item can be null in a non empty table cell (again). This will be fixed in https://github.com/openjdk/jfx/pull/805 (and the tests can be reenabled) ------------- Commit messages: - Disabled currently failing tests Changes: https://git.openjdk.org/jfx/pull/811/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=811&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289751 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/811.diff Fetch: git fetch https://git.openjdk.org/jfx pull/811/head:pull/811 PR: https://git.openjdk.org/jfx/pull/811 From mhanl at openjdk.org Tue Jul 5 23:27:40 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 5 Jul 2022 23:27:40 GMT Subject: Integrated: 8289751: Multiple unit test failures after JDK-8251483 In-Reply-To: <65vgp8GcZluZgnts5nLsprGqo6SzvzAbEQqRcbeMIkU=.d830cf6b-6ca1-45cd-b4fe-9e3d7c766138@github.com> References: <65vgp8GcZluZgnts5nLsprGqo6SzvzAbEQqRcbeMIkU=.d830cf6b-6ca1-45cd-b4fe-9e3d7c766138@github.com> Message-ID: On Tue, 5 Jul 2022 23:09:37 GMT, Marius Hanl wrote: > As also discussed in the ticket, we need to disable/ignore this two tests for now. > > With the fix for [JDK-8251483](https://bugs.openjdk.org/browse/JDK-8251483) the table row item is never null in a non empty table cell. > In the meantime with [JDK-8251480](https://bugs.openjdk.org/browse/JDK-8251480) and [JDK-8285197](https://bugs.openjdk.org/browse/JDK-8285197) we changed the table column header autosizing to be more complete by adding the table row to the setup. > Unfortunately we don't set the table view for the table row, therefore it can not know the underlying item (he knows the index but not where he can get the corresponding data for that index) -> table row item can be null in a non empty table cell (again). > > This will be fixed in https://github.com/openjdk/jfx/pull/805 (and the tests can be reenabled) This pull request has now been integrated. Changeset: b9f39076 Author: Marius Hanl Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/b9f39076bbd4065da61f0c4610d6823a48c6eb46 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod 8289751: Multiple unit test failures after JDK-8251483 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/811 From nlisker at openjdk.org Tue Jul 5 21:49:45 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 5 Jul 2022 21:49:45 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 18:49:40 GMT, Andy Goryachev wrote: >> 1. The way the apps are structured is that each app is its own project, which means that there are many new projects to create and configure. It can be a bit of work, though I have done it in my branch already. If you want to leave it to round 2 of fixing the Eclipse files it's fine. >> >> 2+3. I worked directly from master and from your branch, so no files have been changed. The folders under `build` are OS-specific and are generated as needed by the build. Since you are on Mac, it would explain why the hlsl folders are empty, but they are not empty on Windows. This is why they are marked as "ignore_optional_problems" - to not produce errors even on the wrong system. Since they don't contain Java classes that are referenced by the build (as far as I could tell), it should be safe to remove the `build/...` source folders in general. I don't know if on Mac you get any issues, but I assume you don't. > > 1. I would rather leave the apps/ for day 2, if I may. > 2+3. Currently, on Mac, I don't see any issues related to build/... folders. I think, generally speaking, it's a bad idea to refer to derived folders as source - it complicates the build process in Eclipse. Does my branch fail on windows in Eclipse, Nir? I mean, do I need to make changes to address this comment? I don't get any errors on the graphics module, I'm suggesting that you remove the entries: ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Wed Jul 6 12:30:08 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Jul 2022 12:30:08 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux [v4] In-Reply-To: References: Message-ID: > This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK 19 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). > > 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 four commits: - Merge remote-tracking branch 'origin/master' into 8283402-gcc-11.2 - Merge branch 'master' into 8283402-gcc-11.2 - Merge branch 'master' into 8283402-gcc-11.2 - 8283402: Update to gcc 11.2 on Linux ------------- Changes: https://git.openjdk.org/jfx/pull/761/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=761&range=03 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/761.diff Fetch: git fetch https://git.openjdk.org/jfx pull/761/head:pull/761 PR: https://git.openjdk.org/jfx/pull/761 From kcr at openjdk.org Wed Jul 6 15:24:55 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Jul 2022 15:24:55 GMT Subject: RFR: 8289396: Fix warnings: Null pointer access: The variable instance can only be null at this location In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 15:14:03 GMT, Andy Goryachev wrote: > - removed meaningless test case Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/813 From kcr at openjdk.org Wed Jul 6 11:44:55 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Jul 2022 11:44:55 GMT Subject: RFR: [WIP] 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v7] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: On Mon, 30 May 2022 08:10:36 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Precalculate size of cells that are likely going to be used in rendering. > This avoid resizing cells after their position has been laid out, leading > to misalignments. > Relaxed some tests that check on the number of invocations on updateItem. > We heavily use the accumcell for calculating sizes, and that cell is released > every time, leading to a call to updateItem as well (but this call should > not do any CPU intensive work) I guess this should be closed in favor of #808 ? ------------- PR: https://git.openjdk.org/jfx/pull/712 From duke at openjdk.org Wed Jul 6 14:10:21 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 6 Jul 2022 14:10:21 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v5] In-Reply-To: References: Message-ID: <0_w73THtgdXwcmsz61_VwPzqNEFkWm1rxJ1FniwzIpk=.d64bbf54-e0e4-4fc6-89ad-71b10507c305@github.com> > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8289255 - 8289255 remove javafx.graphics/build/gensrc as source folder - 8289255 remove javafx.swing/src/test/java as source folder - Merge remote-tracking branch 'origin/master' into JDK-8289255 - Revert "8279297: removed unused Shape.setMode method" This reverts commit 6b3b7e51f168a02f68c3bc0324528164680cb6c9. - 8279297: removed unused Shape.setMode method - 8289255: reverted gradlew - 8289255: reverted gradlew - 8289255: remove executable flag - 8289255: updated eclipse .classpath and other configuration files ------------- Changes: - all: https://git.openjdk.org/jfx/pull/804/files - new: https://git.openjdk.org/jfx/pull/804/files/3095904b..9d06dc7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=03-04 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/804.diff Fetch: git fetch https://git.openjdk.org/jfx pull/804/head:pull/804 PR: https://git.openjdk.org/jfx/pull/804 From jhendrikx at openjdk.org Wed Jul 6 06:17:13 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 6 Jul 2022 06:17:13 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Fri, 1 Jul 2022 15:16:24 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request 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 27 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/fluent-bindings > - Add null checks in Subscription > - Update copyrights > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API > - ... and 17 more: https://git.openjdk.org/jfx/compare/50192012...d66f2ba6 > I have yet another question. The following test passes for `Bindings.select`, but fails for `ObservableValue.flatMap`: > > Is this by design? If so, I think this can lead to subtle and hard to diagnose bugs, and should be documented at the very least. This is by design, but it is a break from current JavaFX behaviour to ensure there are no surprises when making much more intensive use of mappings. In current JavaFX's, mappings are used sparingly as they are fairly limited and akward to use. For example, there is a `concat` function for `StringExpression`, but other useful functions like `lowerCase`, `prepend`, `trim`, `substring`, etc. are missing. There is `Bindings#when` to akwardly simulate a ternary expression, and there are arithmetic functions which, like `BigDecimal`, are quite akward to use. With the introduction of an arbitrary mapping function `map`, we can expect such mappings to be used much more often and I think that it is therefore important that they are predictable and are not subject to the whim of the garbage collector. Let me try to explain. Please have a look at these six tests: // #1 Baseline JavaFX bind on property: JMemoryBuddy.memoryTest(test -> { StringProperty labelText = new SimpleStringProperty(this, "labelText"); StringProperty model = new SimpleStringProperty(this, "model"); ObservableValue expression = model; labelText.bind(expression); test.setAsReferenced(labelText); test.setAsReferenced(model); test.assertNotCollectable(expression); // makes sense, as it is the same as model }); // #2 Baseline JavaFX listener on property: JMemoryBuddy.memoryTest(test -> { StringProperty labelText = new SimpleStringProperty(this, "labelText"); StringProperty model = new SimpleStringProperty(this, "model"); ObservableValue expression = model; expression.addListener((obs, old, current) -> labelText.set(current)); test.setAsReferenced(labelText); test.setAsReferenced(model); test.assertNotCollectable(expression); // makes sense, as it is the same as model }); // #3 Baseline JavaFX bind on concatted result: JMemoryBuddy.memoryTest(test -> { StringProperty labelText = new SimpleStringProperty(this, "labelText"); StringProperty model = new SimpleStringProperty(this, "model"); ObservableValue expression = model.concat("%"); labelText.bind(expression); test.setAsReferenced(labelText); test.setAsReferenced(model); test.assertNotCollectable(expression); // expression is being used, please don't collect }); // #4 Baseline JavaFX listener on concatted result: JMemoryBuddy.memoryTest(test -> { StringProperty labelText = new SimpleStringProperty(this, "labelText"); StringProperty model = new SimpleStringProperty(this, "model"); ObservableValue expression = model.concat("%"); expression.addListener((obs, old, current) -> labelText.set(current)); test.setAsReferenced(labelText); test.setAsReferenced(model); test.assertCollectable(expression); // !!!! -- listener stops working, expression was collected! }); // #5 Fluent bindings with bind: JMemoryBuddy.memoryTest(test -> { StringProperty labelText = new SimpleStringProperty(this, "labelText"); StringProperty model = new SimpleStringProperty(this, "model"); ObservableValue expression = model.map(x -> x + "%"); labelText.bind(expression); test.setAsReferenced(labelText); test.setAsReferenced(model); test.assertNotCollectable(expression); // expression is being used, please don't collect }); // #6 Fluent bindings with listener: JMemoryBuddy.memoryTest(test -> { StringProperty labelText = new SimpleStringProperty(this, "labelText"); StringProperty model = new SimpleStringProperty(this, "model"); ObservableValue expression = model.map(x -> x + "%"); expression.addListener((obs, old, current) -> labelText.set(current)); test.setAsReferenced(labelText); test.setAsReferenced(model); test.assertNotCollectable(expression); // expression is being used, please don't collect }); It contains six tests, using different variations of observing a model and updating a value when it changes: - Using a binding or listener - Observe a property directly or a derived value - For the derived case, using JavaFX or Fluent Bindings These tests all pass, but test #4 is the odd one out. It is the only one that allows the expression to be garbage collected, which will likely come as a big surprise to the user. Nothing in the docs of `concat` or `addListener` clarifies this behaviour. The documentation of `addListener` mentions it makes a strong reference, but that does not explain why this is happening and may even lead to more confusion as it is not the listener the user added that is the culprit; it is the listener added by `concat` that is being GC'd. Note that in these tests this seems relatively innocent, but in a real application the listener added on expression will stop working randomly and the label stops getting updates. Consider if it was written as: model.concat("%").addListener((obs, old, current) -> LOGGER.info("Download progress is at: " + current)); The above would break after a while, while fluent versions would keep working: model.map(x -> x + "%").addListener((obs, old, current) -> LOGGER.info("Download progress is at: " + current)); model.map(x -> "Download progres is at: " + x + "%").addListener((obs, old, current) -> LOGGER.info(current)); Also note that the below version (listening directly on `model`) also keeps working: model.addListener((obs, old, current) -> LOGGER.info("Download progress is at: " + current + "%")); As we'd expect fluent mappings to be used much more in normal code, the difference in behaviours between an unmapped value and a mapped value IMHO becomes hard to justify. A simple code change where the value is defined (by adding a mapping to it) could lead to existing listeners to stop working: ObservableValue progressProperty() { return directProperty; } vs: ObservableValue progressProperty() { return directProperty.concat("%"); // dangerous change! } vs: ObservableValue progressProperty() { return directProperty.map(x -> x + "%"); // safe change } Coming back to your test; I agree that it is strange behaviour when compared to the `Bindings#select` case. But the strange behaviour is IMHO caused by JavaFX's reliance on a rather unpredictable mechanism in the first place: weak references and their interaction with the GC. A listener "stub" is actually left behind after `otherProperty` is GC'd, which unfortunately cannot be cleaned up immediately as the GC has no callback mechanism to notify you when a weak reference was collected (aside from polling a `ReferenceQueue`). Instead, JavaFX is relying here on a later invalidation to clean up this stub -- if an invalidation never occurs, JavaFX leaks these stubs: // Sample program that shows stub leakage: public static void main(String[] args) throws InterruptedException { StringProperty x = new SimpleStringProperty(); // Startup Thread.sleep(20000); for(int i = 0; i < 10000000; i++) { new SimpleStringProperty().bind(x); } // Bindings added System.gc(); // 400 MB of uncollectable stubs does not get GC'd Thread.sleep(20000); // Triggers "stub" clean-up (which fails miserably because of lots of array copying) x.set("A"); System.gc(); Thread.sleep(20000); } ![image](https://user-images.githubusercontent.com/995917/177480797-825bd41c-f373-4318-953e-c1d7ef785e22.png) All this interacts with how the fluent bindings are implemented. They observe their source when they themselves are observed. This is done using normal listeners (not weak listeners) to make sure there are no surprises for users (relying on GC is IMHO always surprising behaviour). If they were to use weak listeners, test cases like #6 and the `LOGGER` examples would fail. ------------- PR: https://git.openjdk.org/jfx/pull/675 From kcr at openjdk.org Wed Jul 6 11:43:55 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Jul 2022 11:43:55 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 13:52:40 GMT, Johan Vos wrote: > In order to fix the issues reported in JDK-8089589, the VirtualFlow now uses the real sizes of the elements that are displayed. This allows for a more natural way of scrolling through lists that contain items of very different sizes. > The algorithm that is used, does not calculate the size of each individual cell upfront, as that would be a major performance overhead (especially for large lists). Instead, we estimate the total size and the size of the individual cells based on the real measured size of a (growing) number of cells. > > There are a number of key variables that depend on this estimated size: > * position > * aboluteOffset > * currentIndex > > As a consequence, when the estimated size is changing, the absoluteOffset may change which may lead to a new currentIndex. If this happens during a layout phase, or a "complex" operation (e.g. scroll to an item and select it), this may lead to visually unexpected artifacts. While the rendering becomes more "correct" when the estimated size is improving, it is more important that we do not create visual confusion. > > The difficulty is that there are a large number of ways to manipulate the VirtualFlow, and different entry points may have different expectations about which variables should be kept constant (or only changed gradually). > > In this PR, we focus on consistency in the scrollTo method, where we want to keep the top-cell constant. In case the estimated size is improved during the scrollTo execution, or the next layoutChildren invocation, this implies keeping the result of computeCurrentIndex() constant so that after scrolling to a cell and selecting it, the selected cell is indeed the one that is scrolled to. > > This PR contains a number of tests for this scrollTo behaviour, that should also be considered as regression test in case we want to add more invariants later. The fix looks good to me, although I did leave a question about one of the boundary checks. This will need additional testing. Several of the `assertEquals` calls have the expected and actual args backwards. I also left a few minor formatting comments (I didn't note all of them). modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2321: > 2319: */ > 2320: void getCellSizesInExpectedViewport(int index) { > 2321: double estlength = getOrCreateCellSize(index); Minor: indentation. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2323: > 2321: double estlength = getOrCreateCellSize(index); > 2322: int i = index; > 2323: while ((estlength < viewportLength) && (++i < getCellCount())){ Minor: need space before `{` modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2328: > 2326: if (estlength < viewportLength) { > 2327: int j = index; > 2328: while ((estlength < viewportLength) && (--j > 0)) { Is the `> 0` intentional or should it be `>= 0`? modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3098: > 3096: estSize = estimatedSize / itemCount; > 3097: > 3098: if (keepRatio ) { Minor: there is an extra space before the `)` modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewKeyInputTest.java line 1837: > 1835: } > 1836: > 1837: @Ignore // there is no guarantee that there will be 8 selected items (can be 7 as well) Ideally we would have an open bug ID for an `@Ignore`d test. In this case, it might or might not be worth filing one to fix the test. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2189: > 2187: > 2188: @Test public void testUnfixedCellScrollResize() { > 2189: final ObservableList items = FXCollections.observableArrayList(300,300,70,20); Minor: add spaces after the commas. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2197: > 2195: public void updateItem(Integer item, boolean empty) { > 2196: super.updateItem(item, empty); > 2197: if (!empty && (item!=null)) { Minor: space around the `!=` modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2212: > 2210: IndexedCell cell = VirtualFlowTestUtils.getCell(listView, i); > 2211: if ((cell != null) && (cell.getItem() == 20)) { > 2212: assertEquals("Last cell doesn't end at listview end", cell.getLayoutY(), viewportLength - 20,1.); Expected and actual args are backwards. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2216: > 2214: } > 2215: if ((cell != null) && (cell.getItem() == 70)) { > 2216: assertEquals("Secondlast cell doesn't end properly", cell.getLayoutY(), viewportLength - 20 - 70,1.); Expected and actual args are backwards. Minor: space after the last comma. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2224: > 2222: // resize cells and make sure they align after scrolling > 2223: ObservableList list = FXCollections.observableArrayList(); > 2224: list.addAll(300,300,20,21); Expected and actual args are backwards. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2233: > 2231: IndexedCell cell = VirtualFlowTestUtils.getCell(listView, i); > 2232: if ((cell != null) && (cell.getItem() == 21)) { > 2233: assertEquals("Last cell doesn't end at listview end", cell.getLayoutY(), viewportLength - 21,1.); Expected and actual args are backwards. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2237: > 2235: } > 2236: if ((cell != null) && (cell.getItem() == 20)) { > 2237: assertEquals("Secondlast cell doesn't end properly", cell.getLayoutY(), viewportLength - 21 - 20,1.); Expected and actual args are backwards. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2265: > 2263: Toolkit.getToolkit().firePulse(); > 2264: int cc = VirtualFlowTestUtils.getCellCount(listView); > 2265: assertEquals(cc, 15); Expected and actual args are backwards. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2374: > 2372: double viewportLength = listViewHeight - 2; // it would be better to calculate this from listView but there is no API for this > 2373: > 2374: for(int height: heights) { Minor: space after `for` modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2400: > 2398: assertTrue("Our cell must be visible!", scrollToCell.isVisible()); > 2399: > 2400: if(lastCell.isVisible() && sumOfHeights >= viewportLength) { Minor: space after `if` modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2406: > 2404: if(sumOfHeights < viewportLength) { > 2405: // If we have less cells then space, then all cells are shown, and the position of the last cell, is the sum of the height of the previous cells. > 2406: assertEquals("Last cell should be at the bottom, if we scroll to it", lastCell.getLayoutY(), sumOfHeights - lastCellSize,1.); Expected and actual args are backwards. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2410: > 2408: if(shouldScrollToBottom && sumOfHeights > viewportLength) { > 2409: // If we scroll to the bottom, then the last cell should be exactly at the bottom > 2410: // assertEquals("", lastCell.getLayoutY(), viewportLength - lastCellSize,1.); Expected and actual args are backwards. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2414: > 2412: if(!shouldScrollToBottom && sumOfHeights > viewportLength) { > 2413: // If we don't scroll to the bottom, and the cells are bigger than the available space, then our cell should be at the top. > 2414: assertEquals("Our cell mut be at the top", scrollToCell.getLayoutY(), 0,1.); Expected and actual args are backwards. ------------- PR: https://git.openjdk.org/jfx/pull/808 From john.hendrikx at gmail.com Wed Jul 6 13:52:04 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 6 Jul 2022 15:52:04 +0200 Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <352ba376-df85-a866-b424-91927a71821b@gmail.com> I posted a reply on Github, but it's not making it to the list (that I can see) for some reason. --John On 05/07/2022 19:18, Michael Strau? wrote: > On Fri, 1 Jul 2022 15:16:24 GMT, John Hendrikx wrote: > > I have yet another question. The following test passes for `Bindings.select`, but fails for `ObservableValue.flatMap`: > > > JMemoryBuddy.memoryTest(test -> { > class ValueHolder { > final StringProperty value = new SimpleStringProperty(this, "value"); > StringProperty valueProperty() { return value; } > } > > ObjectProperty valueHolderProperty = new SimpleObjectProperty<>(); > valueHolderProperty.set(new ValueHolder()); > > // Map the nested property value > ObservableValue mapped = valueHolderProperty.flatMap(ValueHolder::valueProperty); > > // Note: the test passes when using the following alternative to flatMap: > // ObservableValue mapped = Bindings.selectString(valueHolderProperty, "value"); > > // Bind the mapped value to a property that will soon be GC'ed. > ObjectProperty otherProperty = new SimpleObjectProperty<>(); > otherProperty.bind(mapped); > > test.setAsReferenced(valueHolderProperty); > test.assertCollectable(otherProperty); > test.assertCollectable(mapped); // expectation: the mapped value is eligible for GC > }); > > > My observation is that a flat-mapped value that was once observed is not eligible for garbage-collection even when the observer itself is collected. This seems to be quite unexpected to me, because it means that a bound property that is collected without being manually unbound will cause a memory leak in the mapped binding. > > Is this by design? If so, I think this can lead to subtle and hard to diagnose bugs, and should be documented at the very least. > > ------------- > > PR: https://git.openjdk.org/jfx/pull/675 From kcr at openjdk.org Wed Jul 6 12:30:10 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Jul 2022 12:30:10 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux [v2] In-Reply-To: References: Message-ID: <6_DoNNYnl84CMLJRD9FMBqs_hOBpRYJpbjQZP6f9bKc=.2223badb-4cac-44b7-a029-cb99dcbd9227@github.com> On Wed, 15 Jun 2022 08:31:28 GMT, Johan Vos 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 8283402-gcc-11.2 >> - 8283402: Update to gcc 11.2 on Linux > > This is working on our build/ci pipeline now, using a dedicated devkit that is very similar to the one produced by https://github.com/openjdk/jdk/tree/master/make/devkit . > I think this PR can now be reviewed/integrated. @johanvos @arapte This is ready for review again. ------------- PR: https://git.openjdk.org/jfx/pull/761 From mstrauss at openjdk.org Wed Jul 6 15:00:57 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Jul 2022 15:00:57 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Wed, 6 Jul 2022 07:07:20 GMT, John Hendrikx wrote: >> I have yet another question. The following test passes for `Bindings.select`, but fails for `ObservableValue.flatMap`: >> >> >> JMemoryBuddy.memoryTest(test -> { >> class ValueHolder { >> final StringProperty value = new SimpleStringProperty(this, "value"); >> StringProperty valueProperty() { return value; } >> } >> >> ObjectProperty valueHolderProperty = new SimpleObjectProperty<>(); >> valueHolderProperty.set(new ValueHolder()); >> >> // Map the nested property value >> ObservableValue mapped = valueHolderProperty.flatMap(ValueHolder::valueProperty); >> >> // Note: the test passes when using the following alternative to flatMap: >> // ObservableValue mapped = Bindings.selectString(valueHolderProperty, "value"); >> >> // Bind the mapped value to a property that will soon be GC'ed. >> ObjectProperty otherProperty = new SimpleObjectProperty<>(); >> otherProperty.bind(mapped); >> >> test.setAsReferenced(valueHolderProperty); >> test.assertCollectable(otherProperty); >> test.assertCollectable(mapped); // expectation: the mapped value is eligible for GC >> }); >> >> >> My observation is that a flat-mapped value that was once observed is not eligible for garbage-collection even when the observer itself is collected. This seems to be quite unexpected to me, because it means that a bound property that is collected without being manually unbound will cause a memory leak in the mapped binding. >> >> Is this by design? If so, I think this can lead to subtle and hard to diagnose bugs, and should be documented at the very least. > > Some more about the GC problem discovered by @mstr2 > > ### How to deal with this when using Fluent bindings (`conditionOn`) > > In the initial proposal, there was a `conditionOn` mechanism and `Subscription` mechanism. `conditionOn` can be used to make your bindings conditional on some external factor to ensure they are automatically cleaned up. The Fluent bindings only require their final result to be unsubscribed, as all intermediate steps will unsubscribe themselves from their source as soon as they themselves become unobserved: > >> a listens to b, listens to c > > If `a` becomes unobserved, it unsubscribes itself from `b`, which unsubscribes itself from `c`. `c` is now eligible for GC. With standard JavaFX listeners, such a chain must be unsubscribed at each step making it almost impossible to use in practice. > > Using `conditionOn` the chain of mappings can be automatically unsubscribed: > > ObservableValue condition = ... ; > > longLivedProperty.conditionOn(condition) > .map(x -> x + "%") > .addListener((obs, old, current) -> ... ); > > The condition can be anything, like a `Skinnable` reference becoming `null`, a piece of UI becoming invisible, etc. > > Note that even though `conditionOn` is currently not available as a nice short-cut, you can still do this with the current implementation: > > ObservableValue condition = ... ; > > condition.flatMap(c -> c ? longLivedProperty : null) > .map(x -> x + "%") > .addListener((obs, old, current) -> ... ); > > `longLivedProperty` will be unsubscribed as soon as `condition` becomes false. > > ### How to deal with this when using Fluent bindings (`Subscription`) > > Although `conditionOn` is IMHO by far the preferred mechanism to handle clean-up, `Subscription` also could be very useful. It is less awkward to use than `addListener` / `removeListener` because the `Subscription` is returned: > > ChangeListener, String, String> listener = (obs, old, current) -> ... ; > x.addListener(listener); > x.removeListener(listener); > > vs: > > Subscription s = x.subscribe((obs, old, current) -> ... ); > s.unsubscribe(); > > Subscriptions can also be combined: > > Subscription s = x.subscribe((obs, old, current) -> ... ) > .and(y.subscribe( ... )) > .and(z.subscribe( ... )); > > s.unsubscribe(); // releases listeners on x, y and z > > ### Dealing with "stub" memory leak in current JavaFX > > Relying on `invalidated` or `changed` being called to clean up dead listeners is perhaps not ideal. It may be an idea to start using a `ReferenceQueue` where all such stubs are registered when they get GC'd. As JavaFX is already continuously running its UI and render threads, it is no great leap to check this `ReferenceQueue` each tick and pro-actively clean up these stubs. Alternatively, a single daemon thread could be used specifically for this purpose. The FX thread would be more suitable however as listener clean-up must be done on that thread anyway. > > This would solve the issue found by @mstr2 in any normal JavaFX application (one where the FX thread is running), and would also solve the issue I highlighted with stubs not being cleaned up in my test program. Thanks @hjohn for the detailed explanation. However, I'm not convinced that this is the right model. Many applications will use a layered architecture where a short-lived property is bound to a long-lived property: var label = new Label(); // scoped to the lifetime of a dialog window var caption = model.captionProperty(); // scoped to the lifetime of the application label.textProperty().bind(caption); This works fine, and doesn't require users to think about unbinding the property before it goes out of scope. I would argue that this is a fundamental feature of the JavaFX property system which makes it easy to reason about code. You give the following example as the "odd one out": // #4 Baseline JavaFX listener on concatted result: JMemoryBuddy.memoryTest(test -> { StringProperty labelText = new SimpleStringProperty(this, "labelText"); StringProperty model = new SimpleStringProperty(this, "model"); ObservableValue expression = model.concat("%"); expression.addListener((obs, old, current) -> labelText.set(current)); test.setAsReferenced(labelText); test.setAsReferenced(model); test.assertCollectable(expression); // !!!! -- listener stops working, expression was collected! }); I don't agree that there is anything wrong with this code, other than the fact that a listener was added to a transient value (`expression`). In fact, I would argue that this is a good model: the lifetime of a property is determined by its reachability from user code. If it's not reachable, then it's eligible for collection. With this model in mind, it's also immediately clear why the code works then using `bind` instead of `addListener`: // #3 Baseline JavaFX bind on concatted result: JMemoryBuddy.memoryTest(test -> { StringProperty labelText = new SimpleStringProperty(this, "labelText"); StringProperty model = new SimpleStringProperty(this, "model"); ObservableValue expression = model.concat("%"); labelText.bind(expression); test.setAsReferenced(labelText); test.setAsReferenced(model); test.assertNotCollectable(expression); // expression is being used, please don't collect }); Now, `expression` is not a transient value because it is logically reachable from `labelText`. Any alternative to this model involves some form of explicit lifetime management (`conditionOn`, `Subscription`, etc). However, as we can see with listeners (that need to be manually added and removed), explicit lifetime management is one of the most abundant sources of bugs. Coming back to my first example, what I would like to see is the following code work as expected: var label = new Label(); // scoped to the lifetime of a dialog window var caption = model.captionProperty(); // scoped to the lifetime of the application // I shouldn't have to worry about this code: label.textProperty().bind(caption.map(String::toUpperCase)); However, not only does this code leak memory, it also makes it far too easy to leak memory. The API looks and feels natural and easy to use, but hides a bug that will not be visible to most users. I would argue that the potential for bugs is on the same order of magnitude as with explicitly added listeners, but much more subtle as it's hidden in a nice and fluent API. Here's my conclusion: I think the "reachability" model is superior to manual and explicit lifetime management, and I think we should make it work before integrating this PR. As currently proposed, the new `map` and `flatMap` APIs have the potential to cause lots of bugs, or force users to use weird constructs to prevent memory leaks. ------------- PR: https://git.openjdk.org/jfx/pull/675 From duke at openjdk.org Wed Jul 6 14:50:00 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 6 Jul 2022 14:50:00 GMT Subject: RFR: 8289390: Fix warnings: type parameter E is hiding the type E Message-ID: - trivial change removes 4 eclipse warnings ------------- Commit messages: - 8289390: fixed type parameter hiding another type Changes: https://git.openjdk.org/jfx/pull/812/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=812&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289390 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/812.diff Fetch: git fetch https://git.openjdk.org/jfx pull/812/head:pull/812 PR: https://git.openjdk.org/jfx/pull/812 From duke at openjdk.org Wed Jul 6 15:19:16 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 6 Jul 2022 15:19:16 GMT Subject: RFR: 8289396: Fix warnings: Null pointer access: The variable instance can only be null at this location Message-ID: - removed meaningless test case ------------- Commit messages: - 8289396: removed meaningless test case Changes: https://git.openjdk.org/jfx/pull/813/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=813&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289396 Stats: 12 lines in 1 file changed: 0 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/813.diff Fetch: git fetch https://git.openjdk.org/jfx pull/813/head:pull/813 PR: https://git.openjdk.org/jfx/pull/813 From duke at openjdk.org Wed Jul 6 18:21:25 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 6 Jul 2022 18:21:25 GMT Subject: RFR: 8289171: Blank final field 'dialog' may not have been initialized in scene.control.Dialog:521 Message-ID: <9lH57ws0_bRkAtc5rDlx7_-vqQUOsQPJVrJayfQQNlQ=.a8819954-4882-4249-bd27-bc8c935302b0@github.com> - changed initialization sequence ------------- Commit messages: - 8289171: proper initialization sequence Changes: https://git.openjdk.org/jfx/pull/815/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=815&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289171 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/815.diff Fetch: git fetch https://git.openjdk.org/jfx pull/815/head:pull/815 PR: https://git.openjdk.org/jfx/pull/815 From duke at openjdk.org Wed Jul 6 17:09:44 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 6 Jul 2022 17:09:44 GMT Subject: Integrated: 8289390: Fix warnings: type parameter E is hiding the type E In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 14:45:13 GMT, Andy Goryachev wrote: > - trivial change removes 4 eclipse warnings This pull request has now been integrated. Changeset: 77ecfb71 Author: Andy Goryachev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/77ecfb7115abe54e8e29c1110717c8f5a2ffef18 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8289390: Fix warnings: type parameter E is hiding the type E Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/812 From mstrauss at openjdk.org Wed Jul 6 16:30:09 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Jul 2022 16:30:09 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <1byOl97gCv-4KsIbYKBmyzUj5vz9paliwE4GY4VO8Uw=.685f9935-ecac-4dc6-9496-297bf82b29f8@github.com> On Fri, 1 Jul 2022 15:16:24 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request 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 27 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/fluent-bindings > - Add null checks in Subscription > - Update copyrights > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API > - ... and 17 more: https://git.openjdk.org/jfx/compare/37b47b07...d66f2ba6 Going a step further, I think the idea of actively disposing dead listeners can help us solve this problem. But there's a catch: we can't just assume that we can safely call `removeListener` from a disposer thread (nor from the JavaFX application thread, for that matter). There is no requirement that an `ObservableValue` implementation be safe to use with regards to concurrent reads and writes. In order to remove a listener on an arbitrary thread, we need to introduce a stronger thread-safety guarantee than we currently have. We can't do that in general, as there are countless `ObservableValue` implementations that would be broken after this change. But we _can_ do it for mapped bindings (or any built-in binding implementations). Let's say we introduce a marker interface that represents a thread-safety guarantee with regards to `addListener` and `removeListener`: /** * Marker interface for {@link ObservableValue} implementations indicating that * listeners can be concurrently added and removed. */ interface ConcurrentListenerAccess {} Now we can use the existing `Disposer` mechanism to automatically schedule listeners to be removed from `ConcurrentListenerAccess` implementations when the bound property is eligible for collection. It's sufficient to implement `ConcurrentListenerAccess` for `ObjectBinding` to make `map` and `flatMap` work the way I'd expect it to work. ------------- PR: https://git.openjdk.org/jfx/pull/675 From kcr at openjdk.org Wed Jul 6 16:46:49 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Jul 2022 16:46:49 GMT Subject: RFR: 8289390: Fix warnings: type parameter E is hiding the type E In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 14:45:13 GMT, Andy Goryachev wrote: > - trivial change removes 4 eclipse warnings Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/812 From duke at openjdk.org Wed Jul 6 18:20:22 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 6 Jul 2022 18:20:22 GMT Subject: RFR: 8279297: Remove Shape::setMode method Message-ID: - removed unused method ------------- Commit messages: - 8279297: removed unused Shape.setMode method Changes: https://git.openjdk.org/jfx/pull/814/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=814&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8279297 Stats: 16 lines in 2 files changed: 0 ins; 14 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/814.diff Fetch: git fetch https://git.openjdk.org/jfx pull/814/head:pull/814 PR: https://git.openjdk.org/jfx/pull/814 From duke at openjdk.org Wed Jul 6 17:07:52 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 6 Jul 2022 17:07:52 GMT Subject: Integrated: 8289396: Fix warnings: Null pointer access: The variable instance can only be null at this location In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 15:14:03 GMT, Andy Goryachev wrote: > - removed meaningless test case This pull request has now been integrated. Changeset: 704baa31 Author: Andy Goryachev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/704baa31abb87025241feecfb4474efd33775d9d Stats: 12 lines in 1 file changed: 0 ins; 11 del; 1 mod 8289396: Fix warnings: Null pointer access: The variable instance can only be null at this location Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/813 From mstrauss at openjdk.org Wed Jul 6 16:38:48 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Jul 2022 16:38:48 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Wed, 6 Jul 2022 12:43:45 GMT, Kevin Rushforth wrote: > The conclusion I take from all of this is that the current implementation is fine, but we might consider a follow-up issue to clean up dead listener stubs. It's important to realize that for `map` and `flatMap`, removing dead listeners is not an optimization like it would be for other bindings, but fundamentally changes their semantics. That's why I think we should decide how we want to handle this issue now, rather than later when the API is already out in the wild. ------------- PR: https://git.openjdk.org/jfx/pull/675 From jhendrikx at openjdk.org Wed Jul 6 07:11:18 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 6 Jul 2022 07:11:18 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Tue, 5 Jul 2022 17:14:41 GMT, Michael Strau? wrote: >> John Hendrikx 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 27 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into feature/fluent-bindings >> - Add null checks in Subscription >> - Update copyrights >> - Move private binding classes to com.sun.javafx.binding package >> - Add note to Bindings#select to consider ObservableValue#flatMap >> - Fix bug invalidation bug in FlatMappedBinding >> >> Also fixed a secondary issue where the indirect source of the binding >> was unsubscribed and resubscribed each time its value was recomputed. >> >> Add additional comments to clarify how FlatMappedBinding works. >> >> Added test cases for these newly discovered issues. >> - Fix typos in LazyObjectBinding >> - Rename observeInputs to observeSources >> - Expand flatMap javadoc with additional wording from Optional#flatMap >> - Add since tags to all new API >> - ... and 17 more: https://git.openjdk.org/jfx/compare/7472f0a3...d66f2ba6 > > I have yet another question. The following test passes for `Bindings.select`, but fails for `ObservableValue.flatMap`: > > > JMemoryBuddy.memoryTest(test -> { > class ValueHolder { > final StringProperty value = new SimpleStringProperty(this, "value"); > StringProperty valueProperty() { return value; } > } > > ObjectProperty valueHolderProperty = new SimpleObjectProperty<>(); > valueHolderProperty.set(new ValueHolder()); > > // Map the nested property value > ObservableValue mapped = valueHolderProperty.flatMap(ValueHolder::valueProperty); > > // Note: the test passes when using the following alternative to flatMap: > // ObservableValue mapped = Bindings.selectString(valueHolderProperty, "value"); > > // Bind the mapped value to a property that will soon be GC'ed. > ObjectProperty otherProperty = new SimpleObjectProperty<>(); > otherProperty.bind(mapped); > > test.setAsReferenced(valueHolderProperty); > test.assertCollectable(otherProperty); > test.assertCollectable(mapped); // expectation: the mapped value is eligible for GC > }); > > > My observation is that a flat-mapped value that was once observed is not eligible for garbage-collection even when the observer itself is collected. This seems to be quite unexpected to me, because it means that a bound property that is collected without being manually unbound will cause a memory leak in the mapped binding. > > Is this by design? If so, I think this can lead to subtle and hard to diagnose bugs, and should be documented at the very least. Some more about the GC problem discovered by @mstr2 ### How to deal with this when using Fluent bindings (`conditionOn`) In the initial proposal, there was a `conditionOn` mechanism and `Subscription` mechanism. `conditionOn` can be used to make your bindings conditional on some external factor to ensure they are automatically cleaned up. The Fluent bindings only require their final result to be unsubscribed, as all intermediate steps will unsubscribe themselves from their source as soon as they themselves become unobserved: > a listens to b, listens to c If `a` becomes unobserved, it unsubscribes itself from `b`, which unsubscribes itself from `c`. `c` is now eligible for GC. With standard JavaFX listeners, such a chain must be unsubscribed at each step making it almost impossible to use in practice. Using `conditionOn` the chain of mappings can be automatically unsubscribed: ObservableValue condition = ... ; longLivedProperty.conditionOn(condition) .map(x -> x + "%") .addListener((obs, old, current) -> ... ); The condition can be anything, like a `Skinnable` reference becoming `null`, a piece of UI becoming invisible, etc. Note that even though `conditionOn` is currently not available as a nice short-cut, you can still do this with the current implementation: ObservableValue condition = ... ; condition.flatMap(c -> c ? longLivedProperty : null) .map(x -> x + "%") .addListener((obs, old, current) -> ... ); `longLivedProperty` will be unsubscribed as soon as `condition` becomes false. ### How to deal with this when using Fluent bindings (`Subscription`) Although `conditionOn` is IMHO by far the preferred mechanism to handle clean-up, `Subscription` also could be very useful. It is less awkward to use than `addListener` / `removeListener` because the `Subscription` is returned: ChangeListener, String, String> listener = (obs, old, current) -> ... ; x.addListener(listener); x.removeListener(listener); vs: Subscription s = x.subscribe((obs, old, current) -> ... ); s.unsubscribe(); Subscriptions can also be combined: Subscription s = x.subscribe((obs, old, current) -> ... ) .and(y.subscribe( ... )) .and(z.subscribe( ... )); s.unsubscribe(); // releases listeners on x, y and z ### Dealing with "stub" memory leak in current JavaFX Relying on `invalidated` or `changed` being called to clean up dead listeners is perhaps not ideal. It may be an idea to start using a `ReferenceQueue` where all such stubs are registered when they get GC'd. As JavaFX is already continuously running its UI and render threads, it is no great leap to check this `ReferenceQueue` each tick and pro-actively clean up these stubs. Alternatively, a single daemon thread could be used specifically for this purpose. The FX thread would be more suitable however as listener clean-up must be done on that thread anyway. This would solve the issue found by @mstr2 in any normal JavaFX application (one where the FX thread is running), and would also solve the issue I highlighted with stubs not being cleaned up in my test program. ------------- PR: https://git.openjdk.org/jfx/pull/675 From mstrauss at openjdk.org Thu Jul 7 00:07:28 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Jul 2022 00:07:28 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v10] In-Reply-To: References: Message-ID: <6I_JJIP37axCWdQHGEG3zvXQ9jYZ28crn3SlQKYqq7A=.e72e86ca-3196-45b1-ba10-d6bbbd3558c9@github.com> On Wed, 6 Jul 2022 23:36:26 GMT, Michael Strau? wrote: >> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > address review comments I've updated the CSR as requested. > One more comment: Have you addressed all questions from @kleopatra ? The question was about a parent that is inserted above a focused node in the scene graph. Currently, a focused node remains the focus owner of the scene, even if it is removed from the scene graph in this way. Independent of whether that's a bug, I don't think that question is relevant for this particular PR. We might create a follow-up ticket to investigate the issue and determine whether it's a bug or not. ------------- PR: https://git.openjdk.org/jfx/pull/475 From jhendrikx at openjdk.org Wed Jul 6 22:10:08 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 6 Jul 2022 22:10:08 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <_3mrndQxThjA_y8x5T28dIJj5_DDh0bJ2pN1YqMLWdY=.f18c7e4b-510c-4e79-a56c-dae02b2d9691@github.com> On Wed, 6 Jul 2022 07:07:20 GMT, John Hendrikx wrote: >> I have yet another question. The following test passes for `Bindings.select`, but fails for `ObservableValue.flatMap`: >> >> >> JMemoryBuddy.memoryTest(test -> { >> class ValueHolder { >> final StringProperty value = new SimpleStringProperty(this, "value"); >> StringProperty valueProperty() { return value; } >> } >> >> ObjectProperty valueHolderProperty = new SimpleObjectProperty<>(); >> valueHolderProperty.set(new ValueHolder()); >> >> // Map the nested property value >> ObservableValue mapped = valueHolderProperty.flatMap(ValueHolder::valueProperty); >> >> // Note: the test passes when using the following alternative to flatMap: >> // ObservableValue mapped = Bindings.selectString(valueHolderProperty, "value"); >> >> // Bind the mapped value to a property that will soon be GC'ed. >> ObjectProperty otherProperty = new SimpleObjectProperty<>(); >> otherProperty.bind(mapped); >> >> test.setAsReferenced(valueHolderProperty); >> test.assertCollectable(otherProperty); >> test.assertCollectable(mapped); // expectation: the mapped value is eligible for GC >> }); >> >> >> My observation is that a flat-mapped value that was once observed is not eligible for garbage-collection even when the observer itself is collected. This seems to be quite unexpected to me, because it means that a bound property that is collected without being manually unbound will cause a memory leak in the mapped binding. >> >> Is this by design? If so, I think this can lead to subtle and hard to diagnose bugs, and should be documented at the very least. > > Some more about the GC problem discovered by @mstr2 > > ### How to deal with this when using Fluent bindings (`conditionOn`) > > In the initial proposal, there was a `conditionOn` mechanism and `Subscription` mechanism. `conditionOn` can be used to make your bindings conditional on some external factor to ensure they are automatically cleaned up. The Fluent bindings only require their final result to be unsubscribed, as all intermediate steps will unsubscribe themselves from their source as soon as they themselves become unobserved: > >> a listens to b, listens to c > > If `a` becomes unobserved, it unsubscribes itself from `b`, which unsubscribes itself from `c`. `c` is now eligible for GC. With standard JavaFX listeners, such a chain must be unsubscribed at each step making it almost impossible to use in practice. > > Using `conditionOn` the chain of mappings can be automatically unsubscribed: > > ObservableValue condition = ... ; > > longLivedProperty.conditionOn(condition) > .map(x -> x + "%") > .addListener((obs, old, current) -> ... ); > > The condition can be anything, like a `Skinnable` reference becoming `null`, a piece of UI becoming invisible, etc. > > Note that even though `conditionOn` is currently not available as a nice short-cut, you can still do this with the current implementation: > > ObservableValue condition = ... ; > > condition.flatMap(c -> c ? longLivedProperty : null) > .map(x -> x + "%") > .addListener((obs, old, current) -> ... ); > > `longLivedProperty` will be unsubscribed as soon as `condition` becomes false. > > ### How to deal with this when using Fluent bindings (`Subscription`) > > Although `conditionOn` is IMHO by far the preferred mechanism to handle clean-up, `Subscription` also could be very useful. It is less awkward to use than `addListener` / `removeListener` because the `Subscription` is returned: > > ChangeListener, String, String> listener = (obs, old, current) -> ... ; > x.addListener(listener); > x.removeListener(listener); > > vs: > > Subscription s = x.subscribe((obs, old, current) -> ... ); > s.unsubscribe(); > > Subscriptions can also be combined: > > Subscription s = x.subscribe((obs, old, current) -> ... ) > .and(y.subscribe( ... )) > .and(z.subscribe( ... )); > > s.unsubscribe(); // releases listeners on x, y and z > > ### Dealing with "stub" memory leak in current JavaFX > > Relying on `invalidated` or `changed` being called to clean up dead listeners is perhaps not ideal. It may be an idea to start using a `ReferenceQueue` where all such stubs are registered when they get GC'd. As JavaFX is already continuously running its UI and render threads, it is no great leap to check this `ReferenceQueue` each tick and pro-actively clean up these stubs. Alternatively, a single daemon thread could be used specifically for this purpose. The FX thread would be more suitable however as listener clean-up must be done on that thread anyway. > > This would solve the issue found by @mstr2 in any normal JavaFX application (one where the FX thread is running), and would also solve the issue I highlighted with stubs not being cleaned up in my test program. > Thanks @hjohn for the detailed explanation. However, I'm not convinced that this is the right model. Many applications will use a layered architecture where a short-lived property is bound to a long-lived property: > > ```java > var label = new Label(); // scoped to the lifetime of a dialog window > var caption = model.captionProperty(); // scoped to the lifetime of the application > > label.textProperty().bind(caption); > ``` > > This works fine, and doesn't require users to think about unbinding the property before it goes out of scope. I would argue that this is a fundamental feature of the JavaFX property system which makes it easy to reason about code. I'm not entirely in agreement here, but also not entirely disagreeing. I mean, if there was a way to make this work perfectly, then I agree that this "automatic" unsubscribing is a great mechanism. However, because you are relying on the GC the code is actually subtly broken right from the start -- you just don't notice it so easily: 1) Listeners which are considered to be "gone" (closed the UI) may still be working in the background listening to long lived models, which can trigger all kinds of things. For example, I've seen a UI bound to a long lived model that would store a "last selected" item when the selection changes. When that UI is closed and reopened you can sometimes see this storage happening twice, or three or four times, because the old listeners weren't GC'd yet. Explicit management is required to avoid such problems. 2) Code that may seem to work fine during a quick testing session may stop working when exercised a bit longer and a GC occurs. This is quite a common thing that JavaFX newcomers encounter. They're playing around using the expression mechanism, code seems to work, but after using a UI for a while, it suddenly stops updating something. They forgot to make a hard reference somewhere. 3) The issues I highlighted in my earlier post. Why is there a difference in how listeners work when it is a property vs an expression? Why does it work differently when using a binding? Replacing a binding with a listener and vice versa can have surprising consequences. The GC issues are some of the hardest to debug, as the problem may appear or disappear (depending on the type) at any time during debugging if the GC kicks in. Bug reports from users are going to be even harder to analyze as they're basically going to be describing something that occurs infrequently and without any pattern to it, and you can't reproduce it. You'll have to ask things like the exact GC used, any GC parameters, all things that are normally completely irrelevant but now may have serious repercussions. Conservative GC's may not even be suitable to use in combination with JavaFX (when not using explicit unbinding/unsubscribing). With a regular memory leak I can make a heap dump and see that a piece of UI has 500 copies in memory. While not fun, finding a GC root then is often sufficient to find the offending reference and solve the problem. > Any alternative to this model involves some form of explicit lifetime management (`conditionOn`, `Subscription`, etc). However, as we can see with listeners (that need to be manually added and removed), explicit lifetime management is one of the most abundant sources of bugs. I don't disagree that is a big source of bugs, however the trade off made introduces a new category of bugs that is fleeting and an order of magnitude harder to reproduce and reason about. > Coming back to my first example, what I would like to see is the following code work as expected: > > ```java > var label = new Label(); // scoped to the lifetime of a dialog window > var caption = model.captionProperty(); // scoped to the lifetime of the application > > // I shouldn't have to worry about this code: > label.textProperty().bind(caption.map(String::toUpperCase)); > ``` > > However, not only does this code leak memory, it also makes it far too easy to leak memory. The API looks and feels natural and easy to use, but hides a bug that will not be visible to most users. I would argue that the potential for bugs is on the same order of magnitude as with explicitly added listeners, but much more subtle as it's hidden in a nice and fluent API. Just to make sure we are on same page, it leaks a bit more memory than it would if it was using `concat` or a regular property, as the listener stub is leaked + the mapping itself. The label is not leaked. The leak "fixes" itself (in both cases) once caption is updated: the left over listener stub which `label` added gets removed, which in turn causes an unsubscribe on the mapping, which in turn unsubscribes itself from `caption`. The mapping is then eligible for GC. > Here's my conclusion: I think the "reachability" model is superior to manual and explicit lifetime management, and I think we should make it work before integrating this PR. As currently proposed, the new `map` and `flatMap` APIs have the potential to cause lots of bugs, or force users to use weird constructs to prevent memory leaks. I think something might be possible. I personally however find that for anything but the most trivial FX apps, explicit management (although not for the case you highlighted above) is preferable to avoid hard to pin down bugs related to untimely GC's. Explicit management could be far simpler than it currently is, with a little bit of help from JavaFX. An `isShowing` property on `Node` in combination with `conditionOn` (since `while` is unfortunately a keyword) would make binding/listeners between properties with different lifecycles a lot simpler: label.textProperty().bind(caption.conditionOn(label::isShowing)); // the mapping is optional, this already has value Note that if caption never changes, just binding it regularly will leave stubs behind with the new and old mechanism. Not a big memory leak, but it may add up if the binding is in something like a frequently occurring dialog or progress indicator or something. ------------- PR: https://git.openjdk.org/jfx/pull/675 From jhendrikx at openjdk.org Wed Jul 6 22:41:22 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 6 Jul 2022 22:41:22 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Wed, 6 Jul 2022 22:24:36 GMT, John Hendrikx wrote: >> John Hendrikx 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 27 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into feature/fluent-bindings >> - Add null checks in Subscription >> - Update copyrights >> - Move private binding classes to com.sun.javafx.binding package >> - Add note to Bindings#select to consider ObservableValue#flatMap >> - Fix bug invalidation bug in FlatMappedBinding >> >> Also fixed a secondary issue where the indirect source of the binding >> was unsubscribed and resubscribed each time its value was recomputed. >> >> Add additional comments to clarify how FlatMappedBinding works. >> >> Added test cases for these newly discovered issues. >> - Fix typos in LazyObjectBinding >> - Rename observeInputs to observeSources >> - Expand flatMap javadoc with additional wording from Optional#flatMap >> - Add since tags to all new API >> - ... and 17 more: https://git.openjdk.org/jfx/compare/a2456300...d66f2ba6 > >> Let's say we introduce a marker interface that represents a thread-safety guarantee with regards to `addListener` and `removeListener`: >> >> ```java >> interface ConcurrentListenerAccess {} >> ``` >> >> Now we can use the existing `Disposer` mechanism to automatically schedule listeners to be removed from `ConcurrentListenerAccess` implementations when the bound property is eligible for collection. >> >> It's sufficient to implement `ConcurrentListenerAccess` for `LazyObjectBinding` to make `map` and `flatMap` work the way I'd expect it to work. > > You mean by `Disposer` something like `com.sun.prism.impl.Disposer`? I see that it has a `ReferenceQueue` in it, so I'm guessing that's the mechanism you are referring to. How would you want this triggered? I think a thread blocking on the queue might be best. > > I think this is a very nice idea to potentially tackle this problem. > @hjohn Thanks for your detailed analysis of the bindings GC situation. The conclusion I take from all of this is that the current implementation is fine, but we might consider a follow-up issue to clean up dead listener stubs. >From @mstr2 analysis, it is slightly more than just the stub in the case of the fluent bindings. See illustration below, assuming `caption` is the only hard reference, the dashed boxes represent things that are eligible for GC, dashed lines represent weak references. If `caption` is modified, triggering a clean-up, then everything is eligible for GC aside from `caption`: ![image](https://user-images.githubusercontent.com/995917/177654654-4bb1e4c2-2f6a-49dc-9673-53805047505e.png) It might be good to fix this right away. ------------- PR: https://git.openjdk.org/jfx/pull/675 From jpereda at openjdk.org Thu Jul 7 08:56:21 2022 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 7 Jul 2022 08:56:21 GMT Subject: RFR: 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 [v2] In-Reply-To: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> References: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> Message-ID: > This PR solves an IAE exception that happens when invoking a ColorChooser control within a WebView, by getting the r, g, b values from the Color before calling the colorChooser. > > A system test is included, to verify that there is no exception and the two native functions that are modified produce the expected color components. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Rework test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/809/files - new: https://git.openjdk.org/jfx/pull/809/files/456d3ce8..c94e695e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=809&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=809&range=00-01 Stats: 150 lines in 1 file changed: 47 ins; 51 del; 52 mod Patch: https://git.openjdk.org/jfx/pull/809.diff Fetch: git fetch https://git.openjdk.org/jfx pull/809/head:pull/809 PR: https://git.openjdk.org/jfx/pull/809 From mstrauss at openjdk.org Wed Jul 6 23:44:42 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Jul 2022 23:44:42 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v9] In-Reply-To: <4YNxvDyBB-4rcgBKq8RnylA0qhO2MHDlsc87mI9MxnM=.bf31df0a-9a56-424e-9ac4-023d0ce1fde1@github.com> References: <9Z3b1Vw8BdqMw_V4fJRZVUtDMgqZyXU33CHkNjfrG5U=.9f8f9c70-a781-4f58-86c5-4ec8ad1dedf0@github.com> <4YNxvDyBB-4rcgBKq8RnylA0qhO2MHDlsc87mI9MxnM=.bf31df0a-9a56-424e-9ac4-023d0ce1fde1@github.com> Message-ID: On Wed, 6 Jul 2022 22:28:23 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ButtonBehavior.java line 181: >> >>> 179: */ >>> 180: protected void mousePressed(MouseEvent e) { >>> 181: if (getNode().isFocusTraversable()) { >> >> The old code used to skip the call to `requestFocus()` if the node was already `focused` (here and in a couple other cases), in order to correctly update the `focusVisible` state. This is probably fine; can you think of any possible side effects of this? > > that should read: > > The old code used to skip the call to requestFocus() if the node was already focused (here and in a couple other cases). _It now always calls it_ in order to correctly update the focusVisible state. I don't think there are any side effects, since the old code just returned from `Scene.(KeyHandler).requestFocus(Node)` without doing anything when the node was already the focus owner of the scene. ------------- PR: https://git.openjdk.org/jfx/pull/475 From mstrauss at openjdk.org Wed Jul 6 18:41:55 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Jul 2022 18:41:55 GMT Subject: RFR: 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 In-Reply-To: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> References: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> Message-ID: On Tue, 5 Jul 2022 19:23:13 GMT, Jose Pereda wrote: > This PR solves an IAE exception that happens when invoking a ColorChooser control within a WebView, by getting the r, g, b values from the Color before calling the colorChooser. > > A system test is included, to verify that there is no exception and the two native functions that are modified produce the expected color components. tests/system/src/test/java/test/javafx/scene/web/ColorChooserTest.java line 41: > 39: import javafx.stage.Stage; > 40: import javafx.stage.Window; > 41: import org.junit.AfterClass; Since this is a new file, you could also use the JUnit5 API. ------------- PR: https://git.openjdk.org/jfx/pull/809 From arapte at openjdk.org Thu Jul 7 05:31:54 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 7 Jul 2022 05:31:54 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux [v4] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 12:30:08 GMT, Kevin Rushforth wrote: >> This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK 19 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). >> >> 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 four commits: > > - Merge remote-tracking branch 'origin/master' into 8283402-gcc-11.2 > - Merge branch 'master' into 8283402-gcc-11.2 > - Merge branch 'master' into 8283402-gcc-11.2 > - 8283402: Update to gcc 11.2 on Linux Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/761 From mstrauss at openjdk.org Wed Jul 6 23:44:51 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Jul 2022 23:44:51 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v9] In-Reply-To: References: <9Z3b1Vw8BdqMw_V4fJRZVUtDMgqZyXU33CHkNjfrG5U=.9f8f9c70-a781-4f58-86c5-4ec8ad1dedf0@github.com> Message-ID: On Wed, 6 Jul 2022 22:17:52 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision: >> >> - Merge branch 'master' into feature/focusvisible >> - Updated since tag >> - Update copyright headers >> - Merge branch 'master' into feature/focusvisible >> - fixed undeterministic test failures >> - minor wording change >> - restart github actions >> - Merge branch 'master' of https://github.com/mstr2/jfx into feature/focusvisible >> - changes per discussion, added test >> - wording >> - ... and 13 more: https://git.openjdk.org/jfx/compare/7cf8f2d0...0c7d6e72 > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8191: > >> 8189: */ >> 8190: private void updateRemovedParentFocus(Node oldParent) { >> 8191: if (oldParent != null && focusWithin.get()) { > > I see that you aren't calling `this.focusWithin.set(false)`. Is that because in the case of the node that was removed from its parent, it will have its `focused` property set to false (as a result of it being removed from the scene), which will then set its `focusWithin` to false? Yes, that's correct. A node that is removed from a scene graph cannot be focused, which also means that it can't have focusWithin. > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 4056: > >> 4054: >> 4055: private void setFocusVisible(Node node, boolean focusVisible) { >> 4056: Node.FocusPropertyBase property = (Node.FocusPropertyBase)node.focusVisibleProperty(); > > Did you consider using a similar pattern to `ReadOnlyBooleanWrapper` to avoid the cast? Given that an application can't call the set method (either by casting or by using reflection), I don't see a problem with this, so it is just a question. I removed the cast by making the `Node.focusVisible` field package-private. That should make it clearer that the property is actually set from outside the `Node` class. ------------- PR: https://git.openjdk.org/jfx/pull/475 From arapte at openjdk.org Thu Jul 7 07:53:48 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 7 Jul 2022 07:53:48 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux [v4] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 12:30:08 GMT, Kevin Rushforth wrote: >> This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK 19 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). >> >> 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 four commits: > > - Merge remote-tracking branch 'origin/master' into 8283402-gcc-11.2 > - Merge branch 'master' into 8283402-gcc-11.2 > - Merge branch 'master' into 8283402-gcc-11.2 > - 8283402: Update to gcc 11.2 on Linux Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/761 From nlisker at openjdk.org Thu Jul 7 02:37:13 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 7 Jul 2022 02:37:13 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <-4ZjlSo1l7YrQ3m664vyYUaWebiNwcvj0KPefS2s6LU=.bec585fe-c45f-4f3d-8e1b-be8e0c589686@github.com> On Fri, 1 Jul 2022 15:16:24 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request 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 27 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/fluent-bindings > - Add null checks in Subscription > - Update copyrights > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API > - ... and 17 more: https://git.openjdk.org/jfx/compare/a0830f34...d66f2ba6 I didn't get into the fine details of the GC discussion yet, but I have a few points I would like to share: 1. @hjohn's example 4, which seems to be a point of some disagreement, is a _de facto_ issue. Even if the technicalities or semantics imply that this is correct behavior, StackOverflow is littered with "why did my listener suddenly stopped working?" questions that are caused by this, and I have fell into this pitfall more than once myself (by starting from something like example 2, then making a slight change that transforms the code into something like example 4). I didn't look yet into the possible alternatives discussed here for dealing with this, but I do believe that going with "this behavior is technically correct" is not the best _practical_ decision, provided that changing it will be backwards compatible. 2. On the subject of `Disposer` and cleaning references in a background thread, the JDK has [Cleaner](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/ref/Cleaner.html) (there is a nice recent Inside Java [post](https://inside.java/2022/05/25/clean-cleaner/) about it), which seems to do what we need, at least abstractly. I didn't look at the code to see if it fits our needs exactly. It also uses a `ReferenceQueue` with `PhantomReference`s. 3. It is clear to me that whatever GC/referencing model we choose to go with eventually (with whatever combination of fluent vs. regular bindings, listeners vs. bindings, expressions vs. properties...), we will have to document what is expected of the user, and we will have to do it very well. Currently, there are some mentions in the docs of listeners holding strong references, and weak references being used in the implementation ("user beware"), but we will need to be a lot more explicit in my opinion. Something like @hjohn's set of examples or some snippets from this discussion would be a good starting point. If we don't want to commit to some detail, we should at least document the current behavior with a note that it might change. It's just too easy to mess this up (even before this PR was considered). I don't mind taking care of such a PR when an implementation is agreed upon. ------------- PR: https://git.openjdk.org/jfx/pull/675 From duke at openjdk.org Wed Jul 6 21:38:36 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 6 Jul 2022 21:38:36 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v7] In-Reply-To: References: Message-ID: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8289255: removed 3DViewer test folders from .classpath ------------- Changes: - all: https://git.openjdk.org/jfx/pull/804/files - new: https://git.openjdk.org/jfx/pull/804/files/3a5e2451..7221e596 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/804.diff Fetch: git fetch https://git.openjdk.org/jfx pull/804/head:pull/804 PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Wed Jul 6 22:34:01 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Jul 2022 22:34:01 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v7] In-Reply-To: References: Message-ID: On Wed, 8 Dec 2021 10:33:53 GMT, Jeanette Winzenburg wrote: >>> yeah that's true, but might happen behind the scenes - we can move a focused node from one parent to another by simply adding it the new. >> >> Yes, you're right, I wasn't thinking of that behavior. I think that should be logically seen as an atomic operation, even though it might not be implemented as such. So in this case, `Scene.focusOwner` wouldn't change. However, I'd still argue that a node that is not part of the scene graph (non-atomically) should not be the focus owner of the scene graph. > >>However, I'd still argue that a node that is not part of the scene graph (non-atomically) should not be the focus owner of the scene graph. > > I agree :) > > But that's what seems to happen: in my example, add a handler to remove the focused "moving" button. When removed, the scene's focus owner is either the next focusable (the "move" button) or null if there is none. On re-adding the button, it's either unfocused (if there had been a next focusable) or focused (if there is none). Not sure what happens in your test snippet .. One more comment: Have you addressed all questions from @kleopatra ? ------------- PR: https://git.openjdk.org/jfx/pull/475 From jpereda at openjdk.org Thu Jul 7 08:56:21 2022 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 7 Jul 2022 08:56:21 GMT Subject: RFR: 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 [v2] In-Reply-To: References: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> Message-ID: On Wed, 6 Jul 2022 18:38:20 GMT, Michael Strau? wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Rework test > > tests/system/src/test/java/test/javafx/scene/web/ColorChooserTest.java line 41: > >> 39: import javafx.stage.Stage; >> 40: import javafx.stage.Window; >> 41: import org.junit.AfterClass; > > Since this is a new file, you could also use the JUnit5 API. Done, I've reworked the test ------------- PR: https://git.openjdk.org/jfx/pull/809 From mstrauss at openjdk.org Wed Jul 6 23:36:26 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Jul 2022 23:36:26 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v10] In-Reply-To: References: Message-ID: > This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: address review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/475/files - new: https://git.openjdk.org/jfx/pull/475/files/0c7d6e72..40522b80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=475&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=475&range=08-09 Stats: 6 lines in 3 files changed: 2 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/475.diff Fetch: git fetch https://git.openjdk.org/jfx pull/475/head:pull/475 PR: https://git.openjdk.org/jfx/pull/475 From kcr at openjdk.org Wed Jul 6 22:34:00 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Jul 2022 22:34:00 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v9] In-Reply-To: <9Z3b1Vw8BdqMw_V4fJRZVUtDMgqZyXU33CHkNjfrG5U=.9f8f9c70-a781-4f58-86c5-4ec8ad1dedf0@github.com> References: <9Z3b1Vw8BdqMw_V4fJRZVUtDMgqZyXU33CHkNjfrG5U=.9f8f9c70-a781-4f58-86c5-4ec8ad1dedf0@github.com> Message-ID: On Thu, 19 May 2022 04:03:46 GMT, Michael Strau? wrote: >> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision: > > - Merge branch 'master' into feature/focusvisible > - Updated since tag > - Update copyright headers > - Merge branch 'master' into feature/focusvisible > - fixed undeterministic test failures > - minor wording change > - restart github actions > - Merge branch 'master' of https://github.com/mstr2/jfx into feature/focusvisible > - changes per discussion, added test > - wording > - ... and 13 more: https://git.openjdk.org/jfx/compare/b608ace8...0c7d6e72 The API looks good. I also reviewed the implementation, and it seems fine. I left a few comments inline. If you still want to get this into JavaFX 19, can you update the CSR as follows? 1. Change the `@since` tags from 18 to 19 2. For the two new properties, please add the two public methods for each property, replacing the "private" field (if you prefer, you can leave the private field as well). 3. The diffs for `cssref.html` need to be added to the Specification section. Once you do that, I will "Review" the CSR, since I am done reviewing the API changes in this PR. You can then Finalize it. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ButtonBehavior.java line 181: > 179: */ > 180: protected void mousePressed(MouseEvent e) { > 181: if (getNode().isFocusTraversable()) { The old code used to skip the call to `requestFocus()` if the node was already `focused` (here and in a couple other cases), in order to correctly update the `focusVisible` state. This is probably fine; can you think of any possible side effects of this? modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8191: > 8189: */ > 8190: private void updateRemovedParentFocus(Node oldParent) { > 8191: if (oldParent != null && focusWithin.get()) { I see that you aren't calling `this.focusWithin.set(false)`. Is that because in the case of the node that was removed from its parent, it will have its `focused` property set to false (as a result of it being removed from the scene), which will then set its `focusWithin` to false? modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 4056: > 4054: > 4055: private void setFocusVisible(Node node, boolean focusVisible) { > 4056: Node.FocusPropertyBase property = (Node.FocusPropertyBase)node.focusVisibleProperty(); Did you consider using a similar pattern to `ReadOnlyBooleanWrapper` to avoid the cast? Given that an application can't call the set method (either by casting or by using reflection), I don't see a problem with this, so it is just a question. modules/javafx.graphics/src/test/java/test/javafx/scene/FocusTest.java line 844: > 842: > 843: node2.requestFocus(); > 844: You might also check that node2 is focused and not focusVisible. ------------- PR: https://git.openjdk.org/jfx/pull/475 From duke at openjdk.org Wed Jul 6 20:03:43 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 6 Jul 2022 20:03:43 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v6] In-Reply-To: References: Message-ID: > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8289255 - Merge remote-tracking branch 'origin/master' into JDK-8289255 - 8289255 remove javafx.graphics/build/gensrc as source folder - 8289255 remove javafx.swing/src/test/java as source folder - Merge remote-tracking branch 'origin/master' into JDK-8289255 - Revert "8279297: removed unused Shape.setMode method" This reverts commit 6b3b7e51f168a02f68c3bc0324528164680cb6c9. - 8279297: removed unused Shape.setMode method - 8289255: reverted gradlew - 8289255: reverted gradlew - 8289255: remove executable flag - ... and 1 more: https://git.openjdk.org/jfx/compare/59d162d2...3a5e2451 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/804/files - new: https://git.openjdk.org/jfx/pull/804/files/9d06dc7b..3a5e2451 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=04-05 Stats: 16 lines in 2 files changed: 0 ins; 11 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/804.diff Fetch: git fetch https://git.openjdk.org/jfx pull/804/head:pull/804 PR: https://git.openjdk.org/jfx/pull/804 From mstrauss at openjdk.org Thu Jul 7 00:36:07 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Jul 2022 00:36:07 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <4pIpRbVT1Pw1AUCs3FMQR2ljWpQPbfzobD7E28zL0Qo=.c783740d-1571-434d-8dce-f8ea4f4f518f@github.com> On Fri, 1 Jul 2022 15:16:24 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request 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 27 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/fluent-bindings > - Add null checks in Subscription > - Update copyrights > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API > - ... and 17 more: https://git.openjdk.org/jfx/compare/cacb6847...d66f2ba6 > I'm not entirely in agreement here, but also not entirely disagreeing. I mean, if there was a way to make this work perfectly, then I agree that this "automatic" unsubscribing is a great mechanism. However, because you are relying on the GC the code is actually subtly broken right from the start -- you just don't notice it so easily: > > 1. [...] > 2. [...] > 3. The issues I highlighted in my earlier post. Why is there a difference in how listeners work when it is a property vs an expression? Why does it work differently when using a binding? Replacing a binding with a listener and vice versa can have surprising consequences. I think a model with the following properties would be more consistent and easier to understand than that we currently have: 1. An `ObservableValue` is eligible for collection if it is not reachable from user code, independent of whether it has listeners. 2. A derived `ObservableValue` keeps its base value alive, i.e. the base value is reachable through the derived value. The second property ensures that it will be sufficient to keep a reference to the last `ObservableValue` in an expressions like `caption.map(String::toUpperCase).map(String::toLowerCase()` without losing any of the intermediate values. It is true that manually added listeners may suffer from unexpected collection, but something has to give. It seems like a reasonable trade-off to make listeners more complicated than binding expressions (which also hopefully discourages the use of manually added listeners). I would also argue that it is easier to explain that it's not the _listener_ that's different in properties v. expressions, it's the _reachability_ of the `ObservableValue` that's different. > Just to make sure we are on same page, it leaks a bit more memory than it would if it was using `concat` or a regular property, as the listener stub is leaked + the mapping itself. The label is not leaked. The leak "fixes" itself (in both cases) once caption is updated: the left over listener stub which `label` added gets removed, which in turn causes an unsubscribe on the mapping, which in turn unsubscribes itself from `caption`. The mapping is then eligible for GC. Thanks for this clarification, I wasn't aware that the leaked listener is actually removed when the source property is changed. That makes the issue a little bit less concerning, but I'd still prefer a solution that doesn't require the source property to change. ------------- PR: https://git.openjdk.org/jfx/pull/675 From jhendrikx at openjdk.org Wed Jul 6 22:28:05 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 6 Jul 2022 22:28:05 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Fri, 1 Jul 2022 15:16:24 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request 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 27 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/fluent-bindings > - Add null checks in Subscription > - Update copyrights > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API > - ... and 17 more: https://git.openjdk.org/jfx/compare/cdb2f0a8...d66f2ba6 > Let's say we introduce a marker interface that represents a thread-safety guarantee with regards to `addListener` and `removeListener`: > > ```java > interface ConcurrentListenerAccess {} > ``` > > Now we can use the existing `Disposer` mechanism to automatically schedule listeners to be removed from `ConcurrentListenerAccess` implementations when the bound property is eligible for collection. > > It's sufficient to implement `ConcurrentListenerAccess` for `LazyObjectBinding` to make `map` and `flatMap` work the way I'd expect it to work. You mean by `Disposer` something like `com.sun.prism.impl.Disposer`? I see that it has a `ReferenceQueue` in it, so I'm guessing that's the mechanism you are referring to. How would you want this triggered? I think a thread blocking on the queue might be best. I think this is a very nice idea to potentially tackle this problem. ------------- PR: https://git.openjdk.org/jfx/pull/675 From kcr at openjdk.org Wed Jul 6 22:34:03 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Jul 2022 22:34:03 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v9] In-Reply-To: References: <9Z3b1Vw8BdqMw_V4fJRZVUtDMgqZyXU33CHkNjfrG5U=.9f8f9c70-a781-4f58-86c5-4ec8ad1dedf0@github.com> Message-ID: <4YNxvDyBB-4rcgBKq8RnylA0qhO2MHDlsc87mI9MxnM=.bf31df0a-9a56-424e-9ac4-023d0ce1fde1@github.com> On Wed, 6 Jul 2022 21:32:05 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision: >> >> - Merge branch 'master' into feature/focusvisible >> - Updated since tag >> - Update copyright headers >> - Merge branch 'master' into feature/focusvisible >> - fixed undeterministic test failures >> - minor wording change >> - restart github actions >> - Merge branch 'master' of https://github.com/mstr2/jfx into feature/focusvisible >> - changes per discussion, added test >> - wording >> - ... and 13 more: https://git.openjdk.org/jfx/compare/b608ace8...0c7d6e72 > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ButtonBehavior.java line 181: > >> 179: */ >> 180: protected void mousePressed(MouseEvent e) { >> 181: if (getNode().isFocusTraversable()) { > > The old code used to skip the call to `requestFocus()` if the node was already `focused` (here and in a couple other cases), in order to correctly update the `focusVisible` state. This is probably fine; can you think of any possible side effects of this? that should read: The old code used to skip the call to requestFocus() if the node was already focused (here and in a couple other cases). _It now always calls it_ in order to correctly update the focusVisible state. ------------- PR: https://git.openjdk.org/jfx/pull/475 From kcr at openjdk.org Wed Jul 6 12:46:35 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Jul 2022 12:46:35 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Wed, 6 Jul 2022 07:07:20 GMT, John Hendrikx wrote: >> I have yet another question. The following test passes for `Bindings.select`, but fails for `ObservableValue.flatMap`: >> >> >> JMemoryBuddy.memoryTest(test -> { >> class ValueHolder { >> final StringProperty value = new SimpleStringProperty(this, "value"); >> StringProperty valueProperty() { return value; } >> } >> >> ObjectProperty valueHolderProperty = new SimpleObjectProperty<>(); >> valueHolderProperty.set(new ValueHolder()); >> >> // Map the nested property value >> ObservableValue mapped = valueHolderProperty.flatMap(ValueHolder::valueProperty); >> >> // Note: the test passes when using the following alternative to flatMap: >> // ObservableValue mapped = Bindings.selectString(valueHolderProperty, "value"); >> >> // Bind the mapped value to a property that will soon be GC'ed. >> ObjectProperty otherProperty = new SimpleObjectProperty<>(); >> otherProperty.bind(mapped); >> >> test.setAsReferenced(valueHolderProperty); >> test.assertCollectable(otherProperty); >> test.assertCollectable(mapped); // expectation: the mapped value is eligible for GC >> }); >> >> >> My observation is that a flat-mapped value that was once observed is not eligible for garbage-collection even when the observer itself is collected. This seems to be quite unexpected to me, because it means that a bound property that is collected without being manually unbound will cause a memory leak in the mapped binding. >> >> Is this by design? If so, I think this can lead to subtle and hard to diagnose bugs, and should be documented at the very least. > > Some more about the GC problem discovered by @mstr2 > > ### How to deal with this when using Fluent bindings (`conditionOn`) > > In the initial proposal, there was a `conditionOn` mechanism and `Subscription` mechanism. `conditionOn` can be used to make your bindings conditional on some external factor to ensure they are automatically cleaned up. The Fluent bindings only require their final result to be unsubscribed, as all intermediate steps will unsubscribe themselves from their source as soon as they themselves become unobserved: > >> a listens to b, listens to c > > If `a` becomes unobserved, it unsubscribes itself from `b`, which unsubscribes itself from `c`. `c` is now eligible for GC. With standard JavaFX listeners, such a chain must be unsubscribed at each step making it almost impossible to use in practice. > > Using `conditionOn` the chain of mappings can be automatically unsubscribed: > > ObservableValue condition = ... ; > > longLivedProperty.conditionOn(condition) > .map(x -> x + "%") > .addListener((obs, old, current) -> ... ); > > The condition can be anything, like a `Skinnable` reference becoming `null`, a piece of UI becoming invisible, etc. > > Note that even though `conditionOn` is currently not available as a nice short-cut, you can still do this with the current implementation: > > ObservableValue condition = ... ; > > condition.flatMap(c -> c ? longLivedProperty : null) > .map(x -> x + "%") > .addListener((obs, old, current) -> ... ); > > `longLivedProperty` will be unsubscribed as soon as `condition` becomes false. > > ### How to deal with this when using Fluent bindings (`Subscription`) > > Although `conditionOn` is IMHO by far the preferred mechanism to handle clean-up, `Subscription` also could be very useful. It is less awkward to use than `addListener` / `removeListener` because the `Subscription` is returned: > > ChangeListener, String, String> listener = (obs, old, current) -> ... ; > x.addListener(listener); > x.removeListener(listener); > > vs: > > Subscription s = x.subscribe((obs, old, current) -> ... ); > s.unsubscribe(); > > Subscriptions can also be combined: > > Subscription s = x.subscribe((obs, old, current) -> ... ) > .and(y.subscribe( ... )) > .and(z.subscribe( ... )); > > s.unsubscribe(); // releases listeners on x, y and z > > ### Dealing with "stub" memory leak in current JavaFX > > Relying on `invalidated` or `changed` being called to clean up dead listeners is perhaps not ideal. It may be an idea to start using a `ReferenceQueue` where all such stubs are registered when they get GC'd. As JavaFX is already continuously running its UI and render threads, it is no great leap to check this `ReferenceQueue` each tick and pro-actively clean up these stubs. Alternatively, a single daemon thread could be used specifically for this purpose. The FX thread would be more suitable however as listener clean-up must be done on that thread anyway. > > This would solve the issue found by @mstr2 in any normal JavaFX application (one where the FX thread is running), and would also solve the issue I highlighted with stubs not being cleaned up in my test program. @hjohn Thanks for your detailed analysis of the bindings GC situation. The conclusion I take from all of this is that the current implementation is fine, but we might consider a follow-up issue to clean up dead listener stubs. If so, my initial take on that later cleanup issue is that we might use the Disposer mechanism on a thread other than the JavaFX application thread, but that can be a topic for later discussion. @mstr2 What are your thoughts on this? ------------- PR: https://git.openjdk.org/jfx/pull/675 From duke at openjdk.org Wed Jul 6 19:03:26 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 6 Jul 2022 19:03:26 GMT Subject: RFR: 8289395: Fix warnings: Varargs methods should only override or be overridden by other varargs methods Message-ID: <-Qjxdv4Rvjm9fm0g9pMpinAhp4hZPNO4I5M8oRnemPo=.08c5af80-652e-45a9-8391-c16bc66ad2e5@github.com> - fixed varargs ------------- Commit messages: - 8289395: fixed varargs Changes: https://git.openjdk.org/jfx/pull/816/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=816&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289395 Stats: 16 lines in 8 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/816.diff Fetch: git fetch https://git.openjdk.org/jfx pull/816/head:pull/816 PR: https://git.openjdk.org/jfx/pull/816 From duke at openjdk.org Wed Jul 6 18:25:52 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 6 Jul 2022 18:25:52 GMT Subject: RFR: 8289171: Blank final field 'dialog' may not have been initialized in scene.control.Dialog:521 In-Reply-To: <9lH57ws0_bRkAtc5rDlx7_-vqQUOsQPJVrJayfQQNlQ=.a8819954-4882-4249-bd27-bc8c935302b0@github.com> References: <9lH57ws0_bRkAtc5rDlx7_-vqQUOsQPJVrJayfQQNlQ=.a8819954-4882-4249-bd27-bc8c935302b0@github.com> Message-ID: On Wed, 6 Jul 2022 18:16:02 GMT, Andy Goryachev wrote: > - changed initialization sequence E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/g/gtk+2.0/libgail18_2.24.32-4ubuntu4_amd64.deb 503 Service Unavailable [IP: 40.119.46.219 80] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Error: Process completed with exit code 100. ------------- PR: https://git.openjdk.org/jfx/pull/815 From jpereda at openjdk.org Thu Jul 7 09:43:56 2022 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 7 Jul 2022 09:43:56 GMT Subject: RFR: 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 [v3] In-Reply-To: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> References: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> Message-ID: > This PR solves an IAE exception that happens when invoking a ColorChooser control within a WebView, by getting the r, g, b values from the Color before calling the colorChooser. > > A system test is included, to verify that there is no exception and the two native functions that are modified produce the expected color components. Jose Pereda 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 8289587-colorrgb - Rework test - Get rgb values from color before calling colorChooser, including test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/809/files - new: https://git.openjdk.org/jfx/pull/809/files/c94e695e..31348ab3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=809&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=809&range=01-02 Stats: 19 lines in 4 files changed: 3 ins; 11 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/809.diff Fetch: git fetch https://git.openjdk.org/jfx pull/809/head:pull/809 PR: https://git.openjdk.org/jfx/pull/809 From mstrauss at openjdk.org Thu Jul 7 00:40:06 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Jul 2022 00:40:06 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Wed, 6 Jul 2022 22:24:36 GMT, John Hendrikx wrote: > You mean by `Disposer` something like `com.sun.prism.impl.Disposer`? I see that it has a `ReferenceQueue` in it, so I'm guessing that's the mechanism you are referring to. How would you want this triggered? I think a thread blocking on the queue might be best. > > I think this is a very nice idea to potentially tackle this problem. We already have `com.sun.javafx.property.adapter.Disposer`, which polls a `ReferenceQueue` on a separate thread. It's used for JavaBean properties. ------------- PR: https://git.openjdk.org/jfx/pull/675 From jvos at openjdk.org Thu Jul 7 10:18:54 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 7 Jul 2022 10:18:54 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 11:40:40 GMT, Kevin Rushforth wrote: > The fix looks good to me, although I did leave a question about one of the boundary checks. This will need additional testing. Several of the `assertEquals` calls have the expected and actual args backwards. I also left a few minor formatting comments (I didn't note all of them). I did a reformat on the sections that you mentioned. Doing a reformat with NetBeans on the whole file would cause too many changes that would hide the real changes, so that is probably a bit too much? > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2321: > >> 2319: */ >> 2320: void getCellSizesInExpectedViewport(int index) { >> 2321: double estlength = getOrCreateCellSize(index); > > Minor: indentation. done > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2323: > >> 2321: double estlength = getOrCreateCellSize(index); >> 2322: int i = index; >> 2323: while ((estlength < viewportLength) && (++i < getCellCount())){ > > Minor: need space before `{` done > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2328: > >> 2326: if (estlength < viewportLength) { >> 2327: int j = index; >> 2328: while ((estlength < viewportLength) && (--j > 0)) { > > Is the `> 0` intentional or should it be `>= 0`? it should also allow cases where j == 0 indeed. Fixed by replacing `--j` to `j--` > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3098: > >> 3096: estSize = estimatedSize / itemCount; >> 3097: >> 3098: if (keepRatio ) { > > Minor: there is an extra space before the `)` done > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewKeyInputTest.java line 1837: > >> 1835: } >> 1836: >> 1837: @Ignore // there is no guarantee that there will be 8 selected items (can be 7 as well) > > Ideally we would have an open bug ID for an `@Ignore`d test. In this case, it might or might not be worth filing one to fix the test. I filed https://bugs.openjdk.org/browse/JDK-8289909 for this. > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2189: > >> 2187: >> 2188: @Test public void testUnfixedCellScrollResize() { >> 2189: final ObservableList items = FXCollections.observableArrayList(300,300,70,20); > > Minor: add spaces after the commas. done > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2374: > >> 2372: double viewportLength = listViewHeight - 2; // it would be better to calculate this from listView but there is no API for this >> 2373: >> 2374: for(int height: heights) { > > Minor: space after `for` done > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2400: > >> 2398: assertTrue("Our cell must be visible!", scrollToCell.isVisible()); >> 2399: >> 2400: if(lastCell.isVisible() && sumOfHeights >= viewportLength) { > > Minor: space after `if` done > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2410: > >> 2408: if(shouldScrollToBottom && sumOfHeights > viewportLength) { >> 2409: // If we scroll to the bottom, then the last cell should be exactly at the bottom >> 2410: // assertEquals("", lastCell.getLayoutY(), viewportLength - lastCellSize,1.); > > Expected and actual args are backwards. this particular assert was commented out, and I removed it. I reverted the args in the previous one though. > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2414: > >> 2412: if(!shouldScrollToBottom && sumOfHeights > viewportLength) { >> 2413: // If we don't scroll to the bottom, and the cells are bigger than the available space, then our cell should be at the top. >> 2414: assertEquals("Our cell mut be at the top", scrollToCell.getLayoutY(), 0,1.); > > Expected and actual args are backwards. done ------------- PR: https://git.openjdk.org/jfx/pull/808 From jvos at openjdk.org Thu Jul 7 11:15:06 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 7 Jul 2022 11:15:06 GMT Subject: RFR: [WIP] 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v8] In-Reply-To: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: > When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. Johan Vos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'master' into 8277785 - Precalculate size of cells that are likely going to be used in rendering. This avoid resizing cells after their position has been laid out, leading to misalignments. Relaxed some tests that check on the number of invocations on updateItem. We heavily use the accumcell for calculating sizes, and that cell is released every time, leading to a call to updateItem as well (but this call should not do any CPU intensive work) - Try to keep visible cells at their original position when improving the estimate. This reduces annoying effects when re-layouting cells without relevant changes. This should not be done when we don't have a valid estimate yet/anymore, or when the absoluteOffset is set to infinity (which may happen if the position is set to infinity, which is the case in some calls in Skin classes). - Don't recalculate estimated size while doing a layout cycle. There are a number of paths possible that first calculate an offset/position, and later do a layoutChildren pass. The offset/position calculations (e.g. in scrollTo calls) assume a specific estimatedSize. If that size is changed between the first call and the layoutChildren logic, the result will not look as intended. Hence, we should avoid updating the estimated size at the start of the layout phase. We can do it safely at the end. Thanks to Zeiss and Florian Kirmaier for providing additional tests. - Don't shift cells if we are already showing the lowest index cell. - Add test to check if there are no empty cells at the end of a List in case there are enough leading cells available. - Add the option to shift all cells down in case the current calculations would lead to empty cells at the end of the view, while there are available cells before the beginning of the view. - resize cell when getting it from the pile, and recalculate total estimated size ------------- Changes: - all: https://git.openjdk.org/jfx/pull/712/files - new: https://git.openjdk.org/jfx/pull/712/files/67b351ac..585119de Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=712&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=712&range=06-07 Stats: 572523 lines in 7576 files changed: 290856 ins; 175331 del; 106336 mod Patch: https://git.openjdk.org/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.org/jfx pull/712/head:pull/712 PR: https://git.openjdk.org/jfx/pull/712 From jvos at openjdk.org Thu Jul 7 11:12:48 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 7 Jul 2022 11:12:48 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v2] In-Reply-To: References: Message-ID: > In order to fix the issues reported in JDK-8089589, the VirtualFlow now uses the real sizes of the elements that are displayed. This allows for a more natural way of scrolling through lists that contain items of very different sizes. > The algorithm that is used, does not calculate the size of each individual cell upfront, as that would be a major performance overhead (especially for large lists). Instead, we estimate the total size and the size of the individual cells based on the real measured size of a (growing) number of cells. > > There are a number of key variables that depend on this estimated size: > * position > * aboluteOffset > * currentIndex > > As a consequence, when the estimated size is changing, the absoluteOffset may change which may lead to a new currentIndex. If this happens during a layout phase, or a "complex" operation (e.g. scroll to an item and select it), this may lead to visually unexpected artifacts. While the rendering becomes more "correct" when the estimated size is improving, it is more important that we do not create visual confusion. > > The difficulty is that there are a large number of ways to manipulate the VirtualFlow, and different entry points may have different expectations about which variables should be kept constant (or only changed gradually). > > In this PR, we focus on consistency in the scrollTo method, where we want to keep the top-cell constant. In case the estimated size is improved during the scrollTo execution, or the next layoutChildren invocation, this implies keeping the result of computeCurrentIndex() constant so that after scrolling to a cell and selecting it, the selected cell is indeed the one that is scrolled to. > > This PR contains a number of tests for this scrollTo behaviour, that should also be considered as regression test in case we want to add more invariants later. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: process reviewer comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/808/files - new: https://git.openjdk.org/jfx/pull/808/files/55f6ba94..c077f10e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=808&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=808&range=00-01 Stats: 71 lines in 2 files changed: 3 ins; 4 del; 64 mod Patch: https://git.openjdk.org/jfx/pull/808.diff Fetch: git fetch https://git.openjdk.org/jfx pull/808/head:pull/808 PR: https://git.openjdk.org/jfx/pull/808 From jvos at openjdk.org Thu Jul 7 11:15:08 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 7 Jul 2022 11:15:08 GMT Subject: Withdrawn: [WIP] 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed In-Reply-To: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: <6ucGWpdPEAzjpVroIEGQ2lagIQ9UtUsB-kMJHBbpbPQ=.536c5cdb-9507-46ec-b497-498bc2af7a45@github.com> On Sun, 9 Jan 2022 15:20:36 GMT, Johan Vos wrote: > When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/712 From jvos at openjdk.org Thu Jul 7 11:15:07 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 7 Jul 2022 11:15:07 GMT Subject: RFR: [WIP] 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v7] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: On Mon, 30 May 2022 08:10:36 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Precalculate size of cells that are likely going to be used in rendering. > This avoid resizing cells after their position has been laid out, leading > to misalignments. > Relaxed some tests that check on the number of invocations on updateItem. > We heavily use the accumcell for calculating sizes, and that cell is released > every time, leading to a call to updateItem as well (but this call should > not do any CPU intensive work) Closed in favor of #808 ------------- PR: https://git.openjdk.org/jfx/pull/712 From arapte at openjdk.org Thu Jul 7 12:29:56 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 7 Jul 2022 12:29:56 GMT Subject: RFR: 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 [v3] In-Reply-To: References: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> Message-ID: On Thu, 7 Jul 2022 09:43:56 GMT, Jose Pereda wrote: >> This PR solves an IAE exception that happens when invoking a ColorChooser control within a WebView, by getting the r, g, b values from the Color before calling the colorChooser. >> >> A system test is included, to verify that there is no exception and the two native functions that are modified produce the expected color components. > > Jose Pereda 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 8289587-colorrgb > - Rework test > - Get rgb values from color before calling colorChooser, including test Looks good. Updated test fails without fix and passes with fix. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/809 From jhendrikx at openjdk.org Thu Jul 7 13:00:24 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 7 Jul 2022 13:00:24 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Fri, 1 Jul 2022 15:16:24 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request 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 27 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/fluent-bindings > - Add null checks in Subscription > - Update copyrights > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API > - ... and 17 more: https://git.openjdk.org/jfx/compare/fc59ad03...d66f2ba6 > Going a step further, I think the idea of actively disposing dead listeners can help us solve this problem. But there's a catch: we can't just assume that we can safely call `removeListener` from a disposer thread (nor from the JavaFX application thread, for that matter). > > There is no requirement that an `ObservableValue` implementation be safe to use with regards to concurrent reads and writes. In order to remove a listener on an arbitrary thread, we need to introduce a stronger thread-safety guarantee than we currently have. We can't do that in general, as there are countless `ObservableValue` implementations that would be broken after this change. But we _can_ do it for mapped bindings (or any built-in binding implementations). > > Now we can use the existing `Disposer` mechanism to automatically schedule listeners to be removed from `ConcurrentListenerAccess` implementations when the bound property is eligible for collection. I've done some experimenting using a `Cleaner` suggested by @nlisker; I changed the private `WeakListener` class inside of `StringPropertyBase` and then added `synchronized` to all its `addListener` and `removeListener` methods: private static class Listener implements InvalidationListener, WeakListener { private static final Cleaner CLEANER = Cleaner.create(); private final WeakReference wref; private final Cleanable cleanable; public Listener(StringPropertyBase ref, Observable observable) { this.wref = new WeakReference<>(ref); Cleanable c = () -> observable.removeListener(this); this.cleanable = observable instanceof ConcurrentListenerAccess ? CLEANER.register(ref, c::clean) : c; } @Override public void invalidated(Observable observable) { StringPropertyBase ref = wref.get(); if (ref == null) { cleanable.clean(); } else { ref.markInvalid(); } } @Override public boolean wasGarbageCollected() { return wref.get() == null; } } Doing 100.000 throwaway binds on a single property, this mechanism manages to keep up quite well using standard GC settings. Within seconds, all 100.000 stubs have been cleaned up (note: 100.000 is already an insane amount). If I go higher, the cleaning mechanism can't quite keep up, but that's primarily because the operation becomes quite expensive due to the large listener list involved (cleaning doesn't start immediately, and if the list of listeners managed by `ExpressionHelper` has grown close to a million items, removing items one by one is quite slow). > It's sufficient to implement `ConcurrentListenerAccess` for `LazyObjectBinding` to make `map` and `flatMap` work the way I'd expect it to work. >From what I can see, we'd need to change all locations where `bind` is implemented using a weak listener, and add a `Cleaner`. Those same classes need their add/remove listener methods synchronized (putting `synchronized` on the static helper methods in `ExpressionListener` doesn't look like a good idea as it would block listener changes to unrelated properties). If there is agreement on this approach, I could create a separate MR for this (since it could be implemented and merged before this one) or integrate the changes into this one. ------------- PR: https://git.openjdk.org/jfx/pull/675 From nlisker at openjdk.org Thu Jul 7 13:46:52 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 7 Jul 2022 13:46:52 GMT Subject: RFR: 8289171: Blank final field 'dialog' may not have been initialized in scene.control.Dialog:521 In-Reply-To: <9lH57ws0_bRkAtc5rDlx7_-vqQUOsQPJVrJayfQQNlQ=.a8819954-4882-4249-bd27-bc8c935302b0@github.com> References: <9lH57ws0_bRkAtc5rDlx7_-vqQUOsQPJVrJayfQQNlQ=.a8819954-4882-4249-bd27-bc8c935302b0@github.com> Message-ID: On Wed, 6 Jul 2022 18:16:02 GMT, Andy Goryachev wrote: > - changed initialization sequence Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/815 From duke at openjdk.org Thu Jul 7 14:23:01 2022 From: duke at openjdk.org (Andy Goryachev) Date: Thu, 7 Jul 2022 14:23:01 GMT Subject: Integrated: 8279297: Remove Shape::setMode method In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 18:12:42 GMT, Andy Goryachev wrote: > - removed unused method This pull request has now been integrated. Changeset: 28b8220e Author: Andy Goryachev Committer: Nir Lisker URL: https://git.openjdk.org/jfx/commit/28b8220e051620674f247c22a217bb9590d103a2 Stats: 16 lines in 2 files changed: 0 ins; 14 del; 2 mod 8279297: Remove Shape::setMode method Reviewed-by: nlisker ------------- PR: https://git.openjdk.org/jfx/pull/814 From duke at openjdk.org Thu Jul 7 14:25:09 2022 From: duke at openjdk.org (Andy Goryachev) Date: Thu, 7 Jul 2022 14:25:09 GMT Subject: Integrated: 8289171: Blank final field 'dialog' may not have been initialized in scene.control.Dialog:521 In-Reply-To: <9lH57ws0_bRkAtc5rDlx7_-vqQUOsQPJVrJayfQQNlQ=.a8819954-4882-4249-bd27-bc8c935302b0@github.com> References: <9lH57ws0_bRkAtc5rDlx7_-vqQUOsQPJVrJayfQQNlQ=.a8819954-4882-4249-bd27-bc8c935302b0@github.com> Message-ID: On Wed, 6 Jul 2022 18:16:02 GMT, Andy Goryachev wrote: > - changed initialization sequence This pull request has now been integrated. Changeset: 4dcd9e06 Author: Andy Goryachev Committer: Nir Lisker URL: https://git.openjdk.org/jfx/commit/4dcd9e0656a84ff6afb62656ac1cb81ff09a0f6b Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8289171: Blank final field 'dialog' may not have been initialized in scene.control.Dialog:521 Reviewed-by: nlisker ------------- PR: https://git.openjdk.org/jfx/pull/815 From duke at openjdk.org Thu Jul 7 16:39:43 2022 From: duke at openjdk.org (Andy Goryachev) Date: Thu, 7 Jul 2022 16:39:43 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: <4paFU2AuCO8MFweHEIiBK8mqMIYgpi0RbCrpEkOVSEg=.f8cb11ef-ebc7-437d-a302-ba0df34e7d97@github.com> References: <4paFU2AuCO8MFweHEIiBK8mqMIYgpi0RbCrpEkOVSEg=.f8cb11ef-ebc7-437d-a302-ba0df34e7d97@github.com> Message-ID: On Thu, 30 Jun 2022 15:30:56 GMT, Nir Lisker wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files > > I scheduled to review this today or tomorrow. @nlisker are the changes acceptable or do we need more work? I'd like to merge this PR because otherwise I have to cherry pick to submit other PRs, and cherry picking is not a good idea, generally speaking. thank you. ------------- PR: https://git.openjdk.org/jfx/pull/804 From nlisker at openjdk.org Thu Jul 7 14:11:42 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 7 Jul 2022 14:11:42 GMT Subject: RFR: 8279297: Remove Shape::setMode method In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 18:12:42 GMT, Andy Goryachev wrote: > - removed unused method Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/814 From kcr at openjdk.org Thu Jul 7 23:59:42 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Jul 2022 23:59:42 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Thu, 7 Jul 2022 12:56:02 GMT, John Hendrikx wrote: > If there is agreement on this approach, I could create a separate MR for this (since it could be implemented and merged before this one) or integrate the changes into this one. I need to read through the recent GC discussion one more time, but I like the approach of using a Cleaner to get rid of stale bindings that would otherwise be released when the base property changes. I think the cleanup could be done as a follow-on fix, in which case it wouldn't block getting this in. The cleanup should also go into JavaFX 19, but that could go in after RDP1 (whereas this feature cannot). ------------- PR: https://git.openjdk.org/jfx/pull/675 From nlisker at openjdk.org Thu Jul 7 20:47:44 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 7 Jul 2022 20:47:44 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v7] In-Reply-To: References: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> Message-ID: On Thu, 7 Jul 2022 20:37:29 GMT, Andy Goryachev wrote: > This PR does not fix apps/ project. In fact, I think .project in apps/ should be removed, and instead we should create individual projects, either for a group (i.e. samples, toys), or for each application (i.e. Robot, 3DViewer). > > This work depends on the cleanup. We could probably do it in a separate bug. What do you think? That's fine, but I saw that you changed the 3DViewer and Ensemble8 files, and there are still errors there, so either leave apps completely out of this PR or bring it to a point where there are no errors. As in my branch that I linked above in the review comment, I also created a separate project for each app. The `apps` project itself still needs a .project file because it's a gradle project that is created automatically by the gradle build. It doesn't need to be a Java project though, so the .project file can have the gradle nature only. ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Thu Jul 7 22:09:52 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Jul 2022 22:09:52 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 10:12:58 GMT, Johan Vos wrote: > I did a reformat on the sections that you mentioned. Doing a reformat with NetBeans on the whole file would cause too many changes that would hide the real changes, so that is probably a bit too much? Perfect (and yes, I prefer to only reformat the sections being modified). >> modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewKeyInputTest.java line 1837: >> >>> 1835: } >>> 1836: >>> 1837: @Ignore // there is no guarantee that there will be 8 selected items (can be 7 as well) >> >> Ideally we would have an open bug ID for an `@Ignore`d test. In this case, it might or might not be worth filing one to fix the test. > > I filed https://bugs.openjdk.org/browse/JDK-8289909 for this. Thanks. In that case can you update the annotiation to `@Ignore("JDK-8289909")`? ------------- PR: https://git.openjdk.org/jfx/pull/808 From jpereda at openjdk.org Thu Jul 7 22:26:46 2022 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 7 Jul 2022 22:26:46 GMT Subject: Integrated: 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 In-Reply-To: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> References: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> Message-ID: On Tue, 5 Jul 2022 19:23:13 GMT, Jose Pereda wrote: > This PR solves an IAE exception that happens when invoking a ColorChooser control within a WebView, by getting the r, g, b values from the Color before calling the colorChooser. > > A system test is included, to verify that there is no exception and the two native functions that are modified produce the expected color components. This pull request has now been integrated. Changeset: fc6a6023 Author: Jose Pereda URL: https://git.openjdk.org/jfx/commit/fc6a60234b0feec80b05257cc93407f651805303 Stats: 180 lines in 3 files changed: 174 ins; 0 del; 6 mod 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/809 From nlisker at openjdk.org Thu Jul 7 20:23:53 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 7 Jul 2022 20:23:53 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v7] In-Reply-To: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> References: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> Message-ID: On Wed, 6 Jul 2022 21:38:36 GMT, Andy Goryachev wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8289255: removed 3DViewer test folders from .classpath In addition, now I'm getting an error on `apps/samples/3DViewer`: `The type java.lang.Class cannot be resolved. It is indirectly referenced from required .class files` ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Fri Jul 8 05:09:30 2022 From: duke at openjdk.org (Andy Goryachev) Date: Fri, 8 Jul 2022 05:09:30 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v7] In-Reply-To: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> References: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> Message-ID: On Wed, 6 Jul 2022 21:38:36 GMT, Andy Goryachev wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8289255: removed 3DViewer test folders from .classpath No, my workspace (jfx) was imported as a gradle project. I think it created a bunch of .project and .classpath files that *never worked* - I could not get them to compile. I had to reset all of them, and now I have 0 errors and 0 warnings with the apps project closed. At this point, I am not sure why you see these errors - do you have any files modified/created? Could you close the apps project in eclipse and do Project -> Clean followed by Project -> Build All? ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Thu Jul 7 22:09:50 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Jul 2022 22:09:50 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 11:12:48 GMT, Johan Vos wrote: >> In order to fix the issues reported in JDK-8089589, the VirtualFlow now uses the real sizes of the elements that are displayed. This allows for a more natural way of scrolling through lists that contain items of very different sizes. >> The algorithm that is used, does not calculate the size of each individual cell upfront, as that would be a major performance overhead (especially for large lists). Instead, we estimate the total size and the size of the individual cells based on the real measured size of a (growing) number of cells. >> >> There are a number of key variables that depend on this estimated size: >> * position >> * aboluteOffset >> * currentIndex >> >> As a consequence, when the estimated size is changing, the absoluteOffset may change which may lead to a new currentIndex. If this happens during a layout phase, or a "complex" operation (e.g. scroll to an item and select it), this may lead to visually unexpected artifacts. While the rendering becomes more "correct" when the estimated size is improving, it is more important that we do not create visual confusion. >> >> The difficulty is that there are a large number of ways to manipulate the VirtualFlow, and different entry points may have different expectations about which variables should be kept constant (or only changed gradually). >> >> In this PR, we focus on consistency in the scrollTo method, where we want to keep the top-cell constant. In case the estimated size is improved during the scrollTo execution, or the next layoutChildren invocation, this implies keeping the result of computeCurrentIndex() constant so that after scrolling to a cell and selecting it, the selected cell is indeed the one that is scrolled to. >> >> This PR contains a number of tests for this scrollTo behaviour, that should also be considered as regression test in case we want to add more invariants later. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > process reviewer comments I noted a couple more `assertEquals` calls where it looks like the expected and actual are backwards. The rest looks good. I'll finish my testing tomorrow. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2213: > 2211: IndexedCell cell = VirtualFlowTestUtils.getCell(listView, i); > 2212: if ((cell != null) && (cell.getItem() == 20)) { > 2213: assertEquals("Last cell doesn't end at listview end", cell.getLayoutY(), viewportLength - 20, 1.); I think the expected and actual args are backwards here, too. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2217: > 2215: } > 2216: if ((cell != null) && (cell.getItem() == 70)) { > 2217: assertEquals("Secondlast cell doesn't end properly", cell.getLayoutY(), viewportLength - 20 - 70, 1.); expected and actual args are backwards. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2234: > 2232: IndexedCell cell = VirtualFlowTestUtils.getCell(listView, i); > 2233: if ((cell != null) && (cell.getItem() == 21)) { > 2234: assertEquals("Last cell doesn't end at listview end", cell.getLayoutY(), viewportLength - 21, 1.); expected and actual args are backwards. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2238: > 2236: } > 2237: if ((cell != null) && (cell.getItem() == 20)) { > 2238: assertEquals("Secondlast cell doesn't end properly", cell.getLayoutY(), viewportLength - 21 - 20, 1.); expected and actual args are backwards. ------------- PR: https://git.openjdk.org/jfx/pull/808 From nlisker at openjdk.org Thu Jul 7 22:22:48 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 7 Jul 2022 22:22:48 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v7] In-Reply-To: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> References: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> Message-ID: On Wed, 6 Jul 2022 21:38:36 GMT, Andy Goryachev wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8289255: removed 3DViewer test folders from .classpath If you want to used Buildship in your projects, you need to import them as gradle projects. This will add the gradle nature to them. Here are the instructions: https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse The problem is that not everyone will want to use Buildship, so the .project files will be different. We will need to think what to do about that. Maybe even if there is the gradle nature in a project file and Buildship isn't installed, then Eclipse will just ignore it, which will be ideal, but maybe it will give errors. ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Thu Jul 7 22:12:50 2022 From: duke at openjdk.org (Andy Goryachev) Date: Thu, 7 Jul 2022 22:12:50 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v7] In-Reply-To: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> References: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> Message-ID: On Wed, 6 Jul 2022 21:38:36 GMT, Andy Goryachev wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8289255: removed 3DViewer test folders from .classpath I have gradle and buildship installed. Is there a step missing, after some one checks out the jfx repo? ------------- PR: https://git.openjdk.org/jfx/pull/804 From lbourges at openjdk.org Thu Jul 7 22:46:53 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Thu, 7 Jul 2022 22:46:53 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v3] In-Reply-To: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> > Changelog for this MarlinFX 0.9.4.5 release: > > The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: > - improved Stroker to handle huge coordinates, up to 1E15 > - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 > > > This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: > - Update DPQS to latest OpenJDK 14 patch > - Improve cubic curve offset computation > > > The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: > - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. > > > Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: > - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. > > > This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. > > Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: > see https://github.com/bourgesl/nearly-optimal-mergesort-code Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: fixed pixel color tests on hi-dpi ------------- Changes: - all: https://git.openjdk.org/jfx/pull/674/files - new: https://git.openjdk.org/jfx/pull/674/files/94874a15..f7e5eb5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=674&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=674&range=01-02 Stats: 28 lines in 1 file changed: 10 ins; 4 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/674.diff Fetch: git fetch https://git.openjdk.org/jfx pull/674/head:pull/674 PR: https://git.openjdk.org/jfx/pull/674 From mstrauss at openjdk.org Fri Jul 8 01:10:47 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 8 Jul 2022 01:10:47 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v10] In-Reply-To: References: Message-ID: <0KjoegB0bPwZB_28qx4DcnZsamDhL4qfnhMbHOAmPRw=.cffd923d-500e-424e-adb6-ab26f7113a1f@github.com> On Wed, 6 Jul 2022 23:36:26 GMT, Michael Strau? wrote: >> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > address review comments I've finalized the CSR. I hope this PR can attract a timely second review in order to make it into JFX 19. ------------- PR: https://git.openjdk.org/jfx/pull/475 From kcr at openjdk.org Thu Jul 7 21:54:56 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Jul 2022 21:54:56 GMT Subject: RFR: 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 [v3] In-Reply-To: References: <8ai-dZJpm0tkCuM44hAmbreqlz7PmXPoo_NWfUE4eb8=.c6ad54be-dae1-418b-b59e-8e147c19f8a7@github.com> Message-ID: <3CrS_5JZgyuHRHFw6mOozdRAroMFLlGHGJGGTmRJk6U=.4d87ee79-f950-4e02-ba3d-ff665b0953d7@github.com> On Thu, 7 Jul 2022 09:43:56 GMT, Jose Pereda wrote: >> This PR solves an IAE exception that happens when invoking a ColorChooser control within a WebView, by getting the r, g, b values from the Color before calling the colorChooser. >> >> A system test is included, to verify that there is no exception and the two native functions that are modified produce the expected color components. > > Jose Pereda 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 8289587-colorrgb > - Rework test > - Get rgb values from color before calling colorChooser, including test Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/809 From nlisker at openjdk.org Thu Jul 7 20:58:39 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 7 Jul 2022 20:58:39 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v7] In-Reply-To: References: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> Message-ID: On Thu, 7 Jul 2022 20:47:41 GMT, Andy Goryachev wrote: > Let me see what it would take to create individual projects for toys and such. You can look at my branch, it does exactly that, and I added all the module reads/exports (unless something changed). ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Thu Jul 7 23:22:42 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Jul 2022 23:22:42 GMT Subject: RFR: 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build Message-ID: On Windows platforms we redistribute the Visual Studio runtime libraries with the JavaFX build so that JavaFX applications can run on systems that don't have them installed already. The main C++ runtime library is `msvcp140.dll`, which we ship along with the other native libraries for JavaFX. Additional C++ functionality has been added to `msvcp140_1.dll` and `msvcp140_2.dll`, neither of which are shipped. Recently, WebKit has started using some standard C++ functions that are only found in `msvcp140_2.dll`. We need to include the two missing libraries as part of the JavaFX build (in addition to `msvcp140.dll`, which is already included). ------------- Commit messages: - 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build Changes: https://git.openjdk.org/jfx/pull/818/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=818&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289952 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/818.diff Fetch: git fetch https://git.openjdk.org/jfx pull/818/head:pull/818 PR: https://git.openjdk.org/jfx/pull/818 From nlisker at openjdk.org Thu Jul 7 21:53:01 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 7 Jul 2022 21:53:01 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v7] In-Reply-To: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> References: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> Message-ID: On Wed, 6 Jul 2022 21:38:36 GMT, Andy Goryachev wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8289255: removed 3DViewer test folders from .classpath Gradle creates apps automatically as a gradle project, so it needs the gradle nature. I can have a look later again. Do you use Buildship? Maybe that's a source of differences as I certainly don't get thousands of errors. ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Thu Jul 7 21:29:51 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Jul 2022 21:29:51 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v10] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 23:36:26 GMT, Michael Strau? wrote: >> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/475 From duke at openjdk.org Thu Jul 7 22:00:53 2022 From: duke at openjdk.org (Andy Goryachev) Date: Thu, 7 Jul 2022 22:00:53 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v7] In-Reply-To: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> References: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> Message-ID: On Wed, 6 Jul 2022 21:38:36 GMT, Andy Goryachev wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8289255: removed 3DViewer test folders from .classpath I am not using gradle to build in eclipse. the expectation is that I can open apps project and it would at least compile. but right now, even though the .project file in apps/ has no nature whatsoever, it seems to be compiled as java, or at least all java sources show errors. Here is .project in apps/ : apps github ate the file. here is the .project in apps/ after I merged your branch: ` apps ` ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Thu Jul 7 23:24:41 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Jul 2022 23:24:41 GMT Subject: RFR: 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 23:16:12 GMT, Kevin Rushforth wrote: > On Windows platforms we redistribute the Visual Studio runtime libraries with the JavaFX build so that JavaFX applications can run on systems that don't have them installed already. The main C++ runtime library is `msvcp140.dll`, which we ship along with the other native libraries for JavaFX. Additional C++ functionality has been added to `msvcp140_1.dll` and `msvcp140_2.dll`, neither of which are shipped. > > Recently, WebKit has started using some standard C++ functions that are only found in `msvcp140_2.dll`. We need to include the two missing libraries as part of the JavaFX build (in addition to `msvcp140.dll`, which is already included). NOTE: This really should have been done back when we updated to Visual Studio 2019, but we didn't do that because of [JDK-8281089](https://bugs.openjdk.org/browse/JDK-8281089), which would have caused a jlinked application to fail. Now that JDK-8281089 is fixed, we can now include these libraries and expect them to work even when using the JMODs with jlink. ------------- PR: https://git.openjdk.org/jfx/pull/818 From duke at openjdk.org Thu Jul 7 20:40:50 2022 From: duke at openjdk.org (Andy Goryachev) Date: Thu, 7 Jul 2022 20:40:50 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v7] In-Reply-To: References: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> Message-ID: On Thu, 7 Jul 2022 20:20:00 GMT, Nir Lisker wrote: > In addition, now I'm getting an error on apps/samples/3DViewer: The type java.lang.Class cannot be resolved. It is indirectly referenced from required .class files This PR does not fix apps/ project. In fact, I think .project in apps/ should be removed, and instead we should create individual projects, either for a group (i.e. samples, toys), or for each application (i.e. Robot, 3DViewer). This work depends on the cleanup. We could probably do it in a separate bug. What do you think? ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Thu Jul 7 20:50:39 2022 From: duke at openjdk.org (Andy Goryachev) Date: Thu, 7 Jul 2022 20:50:39 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v7] In-Reply-To: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> References: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> Message-ID: On Wed, 6 Jul 2022 21:38:36 GMT, Andy Goryachev wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8289255: removed 3DViewer test folders from .classpath I did have samples project open - that would explain my changes in 3DViewer and Ensemble8 files. Let me see what it would take to create individual projects for toys and such. I will change the nature of the apps .project to gradle. ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Thu Jul 7 21:46:46 2022 From: duke at openjdk.org (Andy Goryachev) Date: Thu, 7 Jul 2022 21:46:46 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v7] In-Reply-To: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> References: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> Message-ID: On Wed, 6 Jul 2022 21:38:36 GMT, Andy Goryachev wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8289255: removed 3DViewer test folders from .classpath Nir: I've merged your branch into mine (ag.apps, not yet pushed). Two things: 1. Even though apps/.project has no nature, opening it in eclipse results in 30K errors (class not found) 2. when I close apps/ project, I get the following errors in systemTests: Description Location Path Resource The package myapp3.pkg2 does not exist or is empty line 33 /systemTests/src/testapp3/java/mymod module-info.java The package myapp3.pkg3 does not exist or is empty line 34 /systemTests/src/testapp3/java/mymod module-info.java The package myapp3 does not exist or is empty line 30 /systemTests/src/testapp3/java/mymod module-info.java The project was not built due to "module-info [in module-info.java [in mymod [in src/testapp2/java [in systemTests]]]] does not exist". Fix the problem, then try refreshing this project and building it since it may be inconsistent Unknown systemTests Do we really need a .project file in apps/? ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Thu Jul 7 21:29:53 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Jul 2022 21:29:53 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v10] In-Reply-To: <6I_JJIP37axCWdQHGEG3zvXQ9jYZ28crn3SlQKYqq7A=.e72e86ca-3196-45b1-ba10-d6bbbd3558c9@github.com> References: <6I_JJIP37axCWdQHGEG3zvXQ9jYZ28crn3SlQKYqq7A=.e72e86ca-3196-45b1-ba10-d6bbbd3558c9@github.com> Message-ID: On Thu, 7 Jul 2022 00:04:36 GMT, Michael Strau? wrote: > I've updated the CSR as requested. I just Reviewed it, so go ahead and Finalize it. > > One more comment: Have you addressed all questions from @kleopatra ? > > The question was about a parent that is inserted above a focused node in the scene graph. Currently, a focused node remains the focus owner of the scene, even if it is removed from the scene graph in this way. Independent of whether that's a bug, I don't think that question is relevant for this particular PR. I agree. > We might create a follow-up ticket to investigate the issue and determine whether it's a bug or not. Yes, this sounds like a bug. A follow-up issue seems in order. ------------- PR: https://git.openjdk.org/jfx/pull/475 From mstrauss at openjdk.org Fri Jul 8 01:27:04 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 8 Jul 2022 01:27:04 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <1zJJOFDBAL1wshuHykkh22mKBMlADe6xilTGWLhrCTo=.37131e24-de2a-4606-95f7-abc25307b5dd@github.com> On Fri, 1 Jul 2022 15:16:24 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request 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 27 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/fluent-bindings > - Add null checks in Subscription > - Update copyrights > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API > - ... and 17 more: https://git.openjdk.org/jfx/compare/3805c371...d66f2ba6 I was concerned that the current implementation might leave behind a stale listener that is never collected. If that was the case, I would not be in favor of integrating this PR. But as it turns out, the stale listener is cleared when the source property changes, which doesn't make it as serious an issue as I originally thought. I see no problem with integrating this PR now, and fix the cleanup issue later. ------------- PR: https://git.openjdk.org/jfx/pull/675 From nlisker at openjdk.org Thu Jul 7 22:06:53 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 7 Jul 2022 22:06:53 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v7] In-Reply-To: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> References: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> Message-ID: On Wed, 6 Jul 2022 21:38:36 GMT, Andy Goryachev wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8289255: removed 3DViewer test folders from .classpath Ah, that explains it. I use Buildship which adds the gradle nature. I don't know how eclipse handles projects with no nature, I will have to look at that. It also means that there are going to be conflicts between those who use Buildship and those who don't. ------------- PR: https://git.openjdk.org/jfx/pull/804 From nlisker at openjdk.org Thu Jul 7 20:19:55 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 7 Jul 2022 20:19:55 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v7] In-Reply-To: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> References: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> Message-ID: On Wed, 6 Jul 2022 21:38:36 GMT, Andy Goryachev wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8289255: removed 3DViewer test folders from .classpath You didn't address my [review comment](https://github.com/openjdk/jfx/pull/804#pullrequestreview-1026557434) yet. ------------- PR: https://git.openjdk.org/jfx/pull/804 From aghaisas at openjdk.org Fri Jul 8 07:58:59 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 8 Jul 2022 07:58:59 GMT Subject: RFR: 8276056: Control.skin.setSkin(Skin) fails to call dispose() on discarded Skin In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 13:35:15 GMT, Marius Hanl wrote: > For some reason the `skinProperty` did not allow to set a new skin which is the same class as the previous one. > This leads to multiple issues: > 1. When creating a new skin (same class as previous), the skin will likely install some children and listener but is then rejected when setting it due to the `skinProperty` class constraint > -> Control is in a weird state as the current skin was not disposed since it is still set, although we already created and 'set' a new skin > 2. A skin of the same class can behave differently, so it is not really valid to reject a skin just because it is the same class as the previous > -> Just imagine we have the following skin class > > class MyCustomButtonSkin extends ButtonSkin { > public MyCustomButtonSkin(Button button, boolean someFlag) { super(button); ... } > } > > Now if we would change the skin of the Button two times like this: > > button.setSkin(new MyCustomButtonSkin(button, true)); > button.setSkin(new MyCustomButtonSkin(button, false)); > > The second time the skin will be rejected as it is the same class, although I may changed the skin behaviour, in this case demonstrated by a boolean flag for showing purposes. Looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/806 From lbourges at openjdk.org Fri Jul 8 05:43:49 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 8 Jul 2022 05:43:49 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v3] In-Reply-To: <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> Message-ID: On Thu, 7 Jul 2022 22:46:53 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > fixed pixel color tests on hi-dpi I fixed the test using fuzzy logic (green vs red components). Could you @johanvos or @kevinrushforth confirm it passes now on mac ? My macbook is not ready yet to build openjfx... I will merge with my latest marlin code asap = 0.9.4.6 (2 more bugs fixed), low risk (few lines) if you agree. Cheers, Laurent ------------- PR: https://git.openjdk.org/jfx/pull/674 From kcr at openjdk.org Fri Jul 8 13:11:13 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Jul 2022 13:11:13 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: <-4ZjlSo1l7YrQ3m664vyYUaWebiNwcvj0KPefS2s6LU=.bec585fe-c45f-4f3d-8e1b-be8e0c589686@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <-4ZjlSo1l7YrQ3m664vyYUaWebiNwcvj0KPefS2s6LU=.bec585fe-c45f-4f3d-8e1b-be8e0c589686@github.com> Message-ID: On Thu, 7 Jul 2022 02:31:54 GMT, Nir Lisker wrote: >> John Hendrikx 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 27 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into feature/fluent-bindings >> - Add null checks in Subscription >> - Update copyrights >> - Move private binding classes to com.sun.javafx.binding package >> - Add note to Bindings#select to consider ObservableValue#flatMap >> - Fix bug invalidation bug in FlatMappedBinding >> >> Also fixed a secondary issue where the indirect source of the binding >> was unsubscribed and resubscribed each time its value was recomputed. >> >> Add additional comments to clarify how FlatMappedBinding works. >> >> Added test cases for these newly discovered issues. >> - Fix typos in LazyObjectBinding >> - Rename observeInputs to observeSources >> - Expand flatMap javadoc with additional wording from Optional#flatMap >> - Add since tags to all new API >> - ... and 17 more: https://git.openjdk.org/jfx/compare/a289c17f...d66f2ba6 > > I didn't get into the fine details of the GC discussion yet, but I have a few points I would like to share: > > 1. @hjohn's example 4, which seems to be a point of some disagreement, is a _de facto_ issue. Even if the technicalities or semantics imply that this is correct behavior, StackOverflow is littered with "why did my listener suddenly stopped working?" questions that are caused by this, and I have fell into this pitfall more than once myself (by starting from something like example 2, then making a slight change that transforms the code into something like example 4). > I didn't look yet into the possible alternatives discussed here for dealing with this, but I do believe that going with "this behavior is technically correct" is not the best _practical_ decision, provided that changing it will be backwards compatible. > 2. On the subject of `Disposer` and cleaning references in a background thread, the JDK has [Cleaner](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/ref/Cleaner.html) (there is a nice recent Inside Java [post](https://inside.java/2022/05/25/clean-cleaner/) about it), which seems to do what we need, at least abstractly. I didn't look at the code to see if it fits our needs exactly. It also uses a `ReferenceQueue` with `PhantomReference`s. > 3. It is clear to me that whatever GC/referencing model we choose to go with eventually (with whatever combination of fluent vs. regular bindings, listeners vs. bindings, expressions vs. properties...), we will have to document what is expected of the user, and we will have to do it very well. Currently, there are some mentions in the docs of listeners holding strong references, and weak references being used in the implementation ("user beware"), but we will need to be a lot more explicit in my opinion. Something like @hjohn's set of examples or some snippets from this discussion would be a good starting point. If we don't want to commit to some detail, we should at least document the current behavior with a note that it might change. It's just too easy to mess this up (even before this PR was considered). I don't mind taking care of such a PR when an implementation is agreed upon. Additionally, can you file a docs bug to clarify the GC behavior of bindings and mappings as suggested by @nlisker in point 3 of [this comment](https://github.com/openjdk/jfx/pull/675#issuecomment-1176975103)? ------------- PR: https://git.openjdk.org/jfx/pull/675 From aghaisas at openjdk.org Fri Jul 8 12:38:56 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 8 Jul 2022 12:38:56 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v11] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 11:48:51 GMT, Michael Strau? wrote: >> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > added javadoc param tag Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/475 From kcr at openjdk.org Fri Jul 8 12:10:51 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Jul 2022 12:10:51 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v11] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 11:48:51 GMT, Michael Strau? wrote: >> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > added javadoc param tag Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/475 From kcr at openjdk.org Fri Jul 8 13:07:09 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Jul 2022 13:07:09 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Fri, 8 Jul 2022 10:16:33 GMT, John Hendrikx wrote: >> John Hendrikx 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 27 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into feature/fluent-bindings >> - Add null checks in Subscription >> - Update copyrights >> - Move private binding classes to com.sun.javafx.binding package >> - Add note to Bindings#select to consider ObservableValue#flatMap >> - Fix bug invalidation bug in FlatMappedBinding >> >> Also fixed a secondary issue where the indirect source of the binding >> was unsubscribed and resubscribed each time its value was recomputed. >> >> Add additional comments to clarify how FlatMappedBinding works. >> >> Added test cases for these newly discovered issues. >> - Fix typos in LazyObjectBinding >> - Rename observeInputs to observeSources >> - Expand flatMap javadoc with additional wording from Optional#flatMap >> - Add since tags to all new API >> - ... and 17 more: https://git.openjdk.org/jfx/compare/71632011...d66f2ba6 > > Remember this program? :) > >> ``` >> // Sample program that shows stub leakage: >> public static void main(String[] args) throws InterruptedException { >> StringProperty x = new SimpleStringProperty(); >> >> // Startup >> Thread.sleep(20000); >> >> for(int i = 0; i < 10000000; i++) { >> new SimpleStringProperty().bind(x); >> } >> >> // Bindings added >> System.gc(); // 400 MB of uncollectable stubs does not get GC'd >> Thread.sleep(20000); >> >> // Triggers "stub" clean-up (which fails miserably because of lots of array copying) >> x.set("A"); >> >> System.gc(); >> Thread.sleep(20000); >> } >> ``` >> >> ![image](https://user-images.githubusercontent.com/995917/177480797-825bd41c-f373-4318-953e-c1d7ef785e22.png) > > I modified `ExpressionHelper` to use a custom `Collection` class that has `O(log N)` performance for the only things it uses (add at end, remove a specific listener, iteration). It has the exact same characteristics as `ArrayList`, that is, it is ordered, it allows duplicates and it maintains the exact positions when duplicates are part of the list, which means the call order of listeners is exactly the same (a `LinkedHashMap` would not have this characteristic). Furthermore, it is very similar to an `ArrayList`, which means relatively low overhead (there is no `Entry` wrapper for each item in the "list") and good cache locality when iterating. > > Performance looks now like this: > > ![image](https://user-images.githubusercontent.com/995917/177971749-ab4e0b9e-81db-47f5-9e6b-24a45ef84021.png) > > The price for this is increased memory use (you can see that having 10.000.000 binding stubs took around 400 MB before, and now it takes about twice that). The extra memory use is only paid when there is more than 1 listener (as per how `ExpressionHelper` operates). @hjohn If there are no more questions or concerns raised in the next few hours, you can integrate this PR. Please file the follow-up JBS bug to address the cleanup. ------------- PR: https://git.openjdk.org/jfx/pull/675 From kevin.rushforth at oracle.com Fri Jul 8 12:12:49 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 8 Jul 2022 05:12:49 -0700 Subject: CFV: New OpenJFX Committer: Marius Hanl In-Reply-To: <9409a586-5d92-5eba-3b83-d02f00c5520a@oracle.com> References: <9409a586-5d92-5eba-3b83-d02f00c5520a@oracle.com> Message-ID: Vote: YES -- Kevin On 7/8/2022 5:12 AM, Kevin Rushforth wrote: > I hereby nominate Marius Hanl [1] to OpenJFX Committer. > > Marius is an OpenJFX community member, who has contributed 22 commits > [2] to OpenJFX. > > Votes are due by July 22, 2022 at 13:00 UTC. > > 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 [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#mhanl > > [2] > https://github.com/openjdk/jfx/search?q=author-name%3A%22Marius+Hanl%22&s=author-date&type=commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > From mstrauss at openjdk.org Fri Jul 8 11:48:54 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 8 Jul 2022 11:48:54 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v10] In-Reply-To: <771mp3W1ibG8msS7g4rQ_IWI3vbMqEZWuF9JLz-7pBg=.e9138394-b376-4608-86c7-60b481118c69@github.com> References: <771mp3W1ibG8msS7g4rQ_IWI3vbMqEZWuF9JLz-7pBg=.e9138394-b376-4608-86c7-60b481118c69@github.com> Message-ID: <4uS1D9_Tuv5t_A3SJCF89IGfbUyhX5SB8BIHd6aGYB4=.f12746f8-944d-42cf-aadb-8bc0b0d38d35@github.com> On Fri, 8 Jul 2022 11:07:22 GMT, Ajit Ghaisas wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> address review comments > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/FocusTraversalInputMap.java line 90: > >> 88: * @param node The node to traverse on >> 89: * @param dir The direction to traverse >> 90: */ > > Missing `@param` for traversal method. I've added the missing tag. ------------- PR: https://git.openjdk.org/jfx/pull/475 From kevin.rushforth at oracle.com Fri Jul 8 12:12:19 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 8 Jul 2022 05:12:19 -0700 Subject: CFV: New OpenJFX Committer: Marius Hanl Message-ID: <9409a586-5d92-5eba-3b83-d02f00c5520a@oracle.com> I hereby nominate Marius Hanl [1] to OpenJFX Committer. Marius is an OpenJFX community member, who has contributed 22 commits [2] to OpenJFX. Votes are due by July 22, 2022 at 13:00 UTC. 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 [6]. Thanks. -- Kevin [1] https://openjdk.java.net/census#mhanl [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Marius+Hanl%22&s=author-date&type=commits [3] https://openjdk.java.net/census#openjfx [4] https://openjdk.java.net/bylaws#lazy-consensus [6] https://openjdk.java.net/projects#project-committer From mstrauss at openjdk.org Fri Jul 8 11:48:51 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 8 Jul 2022 11:48:51 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v11] In-Reply-To: References: Message-ID: > This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: added javadoc param tag ------------- Changes: - all: https://git.openjdk.org/jfx/pull/475/files - new: https://git.openjdk.org/jfx/pull/475/files/40522b80..9a8a838e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=475&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=475&range=09-10 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/475.diff Fetch: git fetch https://git.openjdk.org/jfx pull/475/head:pull/475 PR: https://git.openjdk.org/jfx/pull/475 From kevin.rushforth at oracle.com Fri Jul 8 12:31:53 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 8 Jul 2022 05:31:53 -0700 Subject: =?UTF-8?Q?CFV=3a_New_OpenJFX_Committer=3a_Michael_Strau=c3=9f?= Message-ID: <24c276e4-8aaf-c054-ecdf-ad6b263d1009@oracle.com> I hereby nominate Michael Strau? [1] to OpenJFX Committer. Michael is an OpenJFX community member, who has contributed 16 commits [2] to OpenJFX. Votes are due by July 22, 2022 at 13:00 UTC. 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 [6]. Thanks. -- Kevin [1] https://openjdk.org/census#mstrauss [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Michael+Strau%C3%9F%22&s=author-date&type=commits https://github.com/openjdk/jfx/search?q=author-name%3A%22mstr2%22&type=commits [3] https://openjdk.org/census#openjfx [4] https://openjdk.org/bylaws#lazy-consensus [6] https://openjdk.org/projects#project-committer From kevin.rushforth at oracle.com Fri Jul 8 12:38:39 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 8 Jul 2022 05:38:39 -0700 Subject: CFV sent with the wrong subject Message-ID: <28648d89-eccf-9478-dd72-5c12ee23ff50@oracle.com> I mistakenly sent out the initial CFV for Michael Strau? with the wrong subject line (I missed changing the Subject line when copying from the CFV for Marius Hanl). When replying to either the two active nominations, please make sure that the subject and the body match so that the intent of your vote is clear. Sorry for the confusion! -- Kevin From aghaisas at openjdk.org Fri Jul 8 11:37:48 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 8 Jul 2022 11:37:48 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v10] In-Reply-To: References: Message-ID: <771mp3W1ibG8msS7g4rQ_IWI3vbMqEZWuF9JLz-7pBg=.e9138394-b376-4608-86c7-60b481118c69@github.com> On Wed, 6 Jul 2022 23:36:26 GMT, Michael Strau? wrote: >> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Overall this has baked well. I have a very minor comment for a missing javadoc tag. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/FocusTraversalInputMap.java line 90: > 88: * @param node The node to traverse on > 89: * @param dir The direction to traverse > 90: */ Missing `@param` for traversal method. ------------- PR: https://git.openjdk.org/jfx/pull/475 From mhanl at openjdk.org Fri Jul 8 15:03:42 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 8 Jul 2022 15:03:42 GMT Subject: Integrated: 8276056: Control.skin.setSkin(Skin) fails to call dispose() on discarded Skin In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 13:35:15 GMT, Marius Hanl wrote: > For some reason the `skinProperty` did not allow to set a new skin which is the same class as the previous one. > This leads to multiple issues: > 1. When creating a new skin (same class as previous), the skin will likely install some children and listener but is then rejected when setting it due to the `skinProperty` class constraint > -> Control is in a weird state as the current skin was not disposed since it is still set, although we already created and 'set' a new skin > 2. A skin of the same class can behave differently, so it is not really valid to reject a skin just because it is the same class as the previous > -> Just imagine we have the following skin class > > class MyCustomButtonSkin extends ButtonSkin { > public MyCustomButtonSkin(Button button, boolean someFlag) { super(button); ... } > } > > Now if we would change the skin of the Button two times like this: > > button.setSkin(new MyCustomButtonSkin(button, true)); > button.setSkin(new MyCustomButtonSkin(button, false)); > > The second time the skin will be rejected as it is the same class, although I may changed the skin behaviour, in this case demonstrated by a boolean flag for showing purposes. This pull request has now been integrated. Changeset: 178d8987 Author: Marius Hanl Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/178d8987e3c9524bf47cffd23d72149af204ac79 Stats: 49 lines in 2 files changed: 34 ins; 13 del; 2 mod 8276056: Control.skin.setSkin(Skin) fails to call dispose() on discarded Skin Co-authored-by: Jeanette Winzenburg Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/806 From kevin.rushforth at oracle.com Fri Jul 8 12:32:32 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 8 Jul 2022 05:32:32 -0700 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_OpenJFX_Committer=3a_Michael_Strau=c3=9f?= In-Reply-To: <24c276e4-8aaf-c054-ecdf-ad6b263d1009@oracle.com> References: <24c276e4-8aaf-c054-ecdf-ad6b263d1009@oracle.com> Message-ID: <9f4269e2-7ab6-a98e-0e16-fa726882569d@oracle.com> Vote: YES -- Kevin On 7/8/2022 5:31 AM, Kevin Rushforth wrote: > I hereby nominate Michael Strau? [1] to OpenJFX Committer. > > Michael is an OpenJFX community member, who has contributed 16 commits > [2] to OpenJFX. > > Votes are due by July 22, 2022 at 13:00 UTC. > > 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 [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#mstrauss > > [2] > https://github.com/openjdk/jfx/search?q=author-name%3A%22Michael+Strau%C3%9F%22&s=author-date&type=commits > > https://github.com/openjdk/jfx/search?q=author-name%3A%22mstr2%22&type=commits > > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [6] https://openjdk.org/projects#project-committer > > > From jhendrikx at openjdk.org Fri Jul 8 10:20:15 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 8 Jul 2022 10:20:15 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Fri, 1 Jul 2022 15:16:24 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request 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 27 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/fluent-bindings > - Add null checks in Subscription > - Update copyrights > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API > - ... and 17 more: https://git.openjdk.org/jfx/compare/d9654f5e...d66f2ba6 Remember this program? :) > ``` > // Sample program that shows stub leakage: > public static void main(String[] args) throws InterruptedException { > StringProperty x = new SimpleStringProperty(); > > // Startup > Thread.sleep(20000); > > for(int i = 0; i < 10000000; i++) { > new SimpleStringProperty().bind(x); > } > > // Bindings added > System.gc(); // 400 MB of uncollectable stubs does not get GC'd > Thread.sleep(20000); > > // Triggers "stub" clean-up (which fails miserably because of lots of array copying) > x.set("A"); > > System.gc(); > Thread.sleep(20000); > } > ``` > > ![image](https://user-images.githubusercontent.com/995917/177480797-825bd41c-f373-4318-953e-c1d7ef785e22.png) I modified `ExpressionHelper` to use a custom `Collection` class that has `O(log N)` performance for the only things it uses (add at end, remove a specific listener, iteration). It has the exact same characteristics as `ArrayList`, that is, it is ordered, it allows duplicates and it maintains the exact positions when duplicates are part of the list, which means the call order of listeners is exactly the same (a `LinkedHashMap` would not have this characteristic). Furthermore, it is very similar to an `ArrayList`, which means relatively low overhead (there is no `Entry` wrapper for each item in the "list") and good cache locality when iterating. Performance looks now like this: ![image](https://user-images.githubusercontent.com/995917/177971749-ab4e0b9e-81db-47f5-9e6b-24a45ef84021.png) The price for this is increased memory use (you can see that having 10.000.000 binding stubs took around 400 MB before, and now it takes about twice that). The extra memory use is only paid when there is more than 1 listener (as per how `ExpressionHelper` operates). ------------- PR: https://git.openjdk.org/jfx/pull/675 From kevin.rushforth at oracle.com Fri Jul 8 12:29:13 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 8 Jul 2022 05:29:13 -0700 Subject: CFV: New OpenJFX Committer: Marius Hanl Message-ID: I hereby nominate Michael Strau? [1] to OpenJFX Committer. Michael is an OpenJFX community member, who has contributed 15 commits [2] to OpenJFX. Votes are due by July 22, 2022 at 13:00 UTC. 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 [6]. Thanks. -- Kevin [1] https://openjdk.org/census#mstrauss [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Michael+Strau%C3%9F%22&s=author-date&type=commits https://github.com/openjdk/jfx/search?q=author-name%3A%22mstr2%22&type=commits [3] https://openjdk.org/census#openjfx [4] https://openjdk.org/bylaws#lazy-consensus [6] https://openjdk.org/projects#project-committer From arapte at openjdk.org Fri Jul 8 05:56:33 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 8 Jul 2022 05:56:33 GMT Subject: RFR: 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 23:16:12 GMT, Kevin Rushforth wrote: > On Windows platforms we redistribute the Visual Studio runtime libraries with the JavaFX build so that JavaFX applications can run on systems that don't have them installed already. The main C++ runtime library is `msvcp140.dll`, which we ship along with the other native libraries for JavaFX. Additional C++ functionality has been added to `msvcp140_1.dll` and `msvcp140_2.dll`, neither of which are shipped. > > Recently, WebKit has started using some standard C++ functions that are only found in `msvcp140_2.dll`. We need to include the two missing libraries as part of the JavaFX build (in addition to `msvcp140.dll`, which is already included). Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/818 From nlisker at openjdk.org Fri Jul 8 14:37:14 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 8 Jul 2022 14:37:14 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: <-4ZjlSo1l7YrQ3m664vyYUaWebiNwcvj0KPefS2s6LU=.bec585fe-c45f-4f3d-8e1b-be8e0c589686@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <-4ZjlSo1l7YrQ3m664vyYUaWebiNwcvj0KPefS2s6LU=.bec585fe-c45f-4f3d-8e1b-be8e0c589686@github.com> Message-ID: On Thu, 7 Jul 2022 02:31:54 GMT, Nir Lisker wrote: >> John Hendrikx 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 27 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into feature/fluent-bindings >> - Add null checks in Subscription >> - Update copyrights >> - Move private binding classes to com.sun.javafx.binding package >> - Add note to Bindings#select to consider ObservableValue#flatMap >> - Fix bug invalidation bug in FlatMappedBinding >> >> Also fixed a secondary issue where the indirect source of the binding >> was unsubscribed and resubscribed each time its value was recomputed. >> >> Add additional comments to clarify how FlatMappedBinding works. >> >> Added test cases for these newly discovered issues. >> - Fix typos in LazyObjectBinding >> - Rename observeInputs to observeSources >> - Expand flatMap javadoc with additional wording from Optional#flatMap >> - Add since tags to all new API >> - ... and 17 more: https://git.openjdk.org/jfx/compare/62bcd33c...d66f2ba6 > > I didn't get into the fine details of the GC discussion yet, but I have a few points I would like to share: > > 1. @hjohn's example 4, which seems to be a point of some disagreement, is a _de facto_ issue. Even if the technicalities or semantics imply that this is correct behavior, StackOverflow is littered with "why did my listener suddenly stopped working?" questions that are caused by this, and I have fell into this pitfall more than once myself (by starting from something like example 2, then making a slight change that transforms the code into something like example 4). > I didn't look yet into the possible alternatives discussed here for dealing with this, but I do believe that going with "this behavior is technically correct" is not the best _practical_ decision, provided that changing it will be backwards compatible. > 2. On the subject of `Disposer` and cleaning references in a background thread, the JDK has [Cleaner](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/ref/Cleaner.html) (there is a nice recent Inside Java [post](https://inside.java/2022/05/25/clean-cleaner/) about it), which seems to do what we need, at least abstractly. I didn't look at the code to see if it fits our needs exactly. It also uses a `ReferenceQueue` with `PhantomReference`s. > 3. It is clear to me that whatever GC/referencing model we choose to go with eventually (with whatever combination of fluent vs. regular bindings, listeners vs. bindings, expressions vs. properties...), we will have to document what is expected of the user, and we will have to do it very well. Currently, there are some mentions in the docs of listeners holding strong references, and weak references being used in the implementation ("user beware"), but we will need to be a lot more explicit in my opinion. Something like @hjohn's set of examples or some snippets from this discussion would be a good starting point. If we don't want to commit to some detail, we should at least document the current behavior with a note that it might change. It's just too easy to mess this up (even before this PR was considered). I don't mind taking care of such a PR when an implementation is agreed upon. > Additionally, can you file a docs bug to clarify the GC behavior of bindings and mappings as suggested by @nlisker in point 3 of [this comment](https://github.com/openjdk/jfx/pull/675#issuecomment-1176975103)? @hjohn If the followup work on this issue is too much and you want to focus on the implementation, you can assign it to me. ------------- PR: https://git.openjdk.org/jfx/pull/675 From kevin.rushforth at oracle.com Fri Jul 8 12:30:50 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 8 Jul 2022 05:30:50 -0700 Subject: CFV: New OpenJFX Committer: Marius Hanl In-Reply-To: References: Message-ID: <06044c35-b84e-282e-c7e5-f6ad05f20cf3@oracle.com> Correction, Michael has contributed 16 Commits. On 7/8/2022 5:29 AM, Kevin Rushforth wrote: > I hereby nominate Michael Strau? [1] to OpenJFX Committer. > > Michael is an OpenJFX community member, who has contributed 15 commits > [2] to OpenJFX. > > Votes are due by July 22, 2022 at 13:00 UTC. > > 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 [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#mstrauss > > [2] > https://github.com/openjdk/jfx/search?q=author-name%3A%22Michael+Strau%C3%9F%22&s=author-date&type=commits > > https://github.com/openjdk/jfx/search?q=author-name%3A%22mstr2%22&type=commits > > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [6] https://openjdk.org/projects#project-committer > > From duke at openjdk.org Fri Jul 8 16:56:39 2022 From: duke at openjdk.org (Andy Goryachev) Date: Fri, 8 Jul 2022 16:56:39 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v8] In-Reply-To: References: Message-ID: <81Le_1U5Ee9xvFQZdgPBTVDsWeMuzjQYrZdOirN8-uU=.f20e1c1a-b333-4575-99da-3795451425f3@github.com> > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: - added javafx.controls/com.sun.javafx.scene.control dependency - Merge remote-tracking branch 'origin/master' into JDK-8289255 - 8289255: removed 3DViewer test folders from .classpath - Merge remote-tracking branch 'origin/master' into JDK-8289255 - Merge remote-tracking branch 'origin/master' into JDK-8289255 - 8289255 remove javafx.graphics/build/gensrc as source folder - 8289255 remove javafx.swing/src/test/java as source folder - Merge remote-tracking branch 'origin/master' into JDK-8289255 - Revert "8279297: removed unused Shape.setMode method" This reverts commit 6b3b7e51f168a02f68c3bc0324528164680cb6c9. - 8279297: removed unused Shape.setMode method - ... and 4 more: https://git.openjdk.org/jfx/compare/1e375c48...e8f9898e ------------- Changes: - all: https://git.openjdk.org/jfx/pull/804/files - new: https://git.openjdk.org/jfx/pull/804/files/7221e596..e8f9898e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=06-07 Stats: 249 lines in 9 files changed: 208 ins; 28 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/804.diff Fetch: git fetch https://git.openjdk.org/jfx pull/804/head:pull/804 PR: https://git.openjdk.org/jfx/pull/804 From nlisker at gmail.com Fri Jul 8 17:40:01 2022 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 8 Jul 2022 20:40:01 +0300 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_OpenJFX_Committer=3A_Michael_Strau=C3=9F?= In-Reply-To: <24c276e4-8aaf-c054-ecdf-ad6b263d1009@oracle.com> References: <24c276e4-8aaf-c054-ecdf-ad6b263d1009@oracle.com> Message-ID: Vote: YES On Fri, Jul 8, 2022 at 8:39 PM Kevin Rushforth wrote: > I hereby nominate Michael Strau? [1] to OpenJFX Committer. > > Michael is an OpenJFX community member, who has contributed 16 commits > [2] to OpenJFX. > > Votes are due by July 22, 2022 at 13:00 UTC. > > 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 [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#mstrauss > > [2] > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Michael+Strau%C3%9F%22&s=author-date&type=commits > > https://github.com/openjdk/jfx/search?q=author-name%3A%22mstr2%22&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [6] https://openjdk.org/projects#project-committer > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Fri Jul 8 17:40:17 2022 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 8 Jul 2022 20:40:17 +0300 Subject: CFV: New OpenJFX Committer: Marius Hanl In-Reply-To: <9409a586-5d92-5eba-3b83-d02f00c5520a@oracle.com> References: <9409a586-5d92-5eba-3b83-d02f00c5520a@oracle.com> Message-ID: Vote: YES On Fri, Jul 8, 2022 at 8:37 PM Kevin Rushforth wrote: > I hereby nominate Marius Hanl [1] to OpenJFX Committer. > > Marius is an OpenJFX community member, who has contributed 22 commits > [2] to OpenJFX. > > Votes are due by July 22, 2022 at 13:00 UTC. > > 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 [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#mhanl > > [2] > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Marius+Hanl%22&s=author-date&type=commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Fri Jul 8 17:56:38 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 8 Jul 2022 17:56:38 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v7] In-Reply-To: References: <2XnacEX0fQgZIk4EDMMpQaFZFDckftnlthf6j8thHBo=.d62cd4b6-1602-458e-98f9-28e2439f1628@github.com> Message-ID: On Thu, 7 Jul 2022 22:26:17 GMT, Andy Goryachev wrote: > No, my workspace (jfx) was imported as a gradle project. I think it created a bunch of .project and .classpath files that never worked - I could not get them to compile. I had to reset all of them That's what I wrote in the instructions - gradle creates its own project files that are wrong (it's not smart enough to handle modular projects yet), and they need to be reverted to those in the repo, or in this PR in this case. I updated to the latest commit and imported as Gradle projects in a new workspace (and reverted to this PR's Eclipse files). I still get an error on 3DViewer: `The type java.lang.Class cannot be resolved. It is indirectly referenced from required .class files`. This error points at some configuration issue. If you don't get this error for some reason then we can continue and get there when we do the apps folder, otherwise it should be fixed. In addition, If I import as Java projects (not as Gradle), `buildSrc` still has project files that should be removed (and apps is a mess, which is fine for now). `tests` also has project files that need to be fixed (`tests` includes the Gradle project `systemTests`) if they are imported this way. The errors are the ones I posted in my review comment. If you want to work on `tests` on a later PR that's also fine because there is some work to do there. ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Fri Jul 8 18:05:05 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Jul 2022 18:05:05 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v3] In-Reply-To: <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> Message-ID: On Thu, 7 Jul 2022 22:46:53 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > fixed pixel color tests on hi-dpi Yes, the tests now all pass on my MacBook Pro which has a retina display. > I will merge with my latest marlin code asap = 0.9.4.6 (2 more bugs fixed), low risk (few lines) if you agree. Yes, that would be fine. Let's change the titles of this PR and the JBS issue to reflect the .6 patch version. Also, can you merge in the latest upstream master? Your branch is very out of date. Since I am just starting the review, I'm not sure whether we will be able to get this in before the RDP1 deadline, so it will either just barely make JavaFX 19 (if right before RDP1) or it can be integrated early in JavaFX 20. ------------- PR: https://git.openjdk.org/jfx/pull/674 From kcr at openjdk.org Fri Jul 8 18:05:06 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Jul 2022 18:05:06 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v3] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> Message-ID: On Fri, 8 Jul 2022 18:01:25 GMT, Kevin Rushforth wrote: > I will merge with my latest marlin code asap = 0.9.4.6 (2 more bugs fixed), low risk (few lines) if you agree. (but don't change your branch name or would need to create a new PR, which doesn't seem worth it) ------------- PR: https://git.openjdk.org/jfx/pull/674 From jhendrikx at openjdk.org Fri Jul 1 15:26:58 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 1 Jul 2022 15:26:58 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v17] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <_gd3ukG8x9KEj0prENidAHfsptHgB5xUWDhFHbGCtv0=.2f8ffa59-c98d-48cb-bdbd-0a022f2c6412@github.com> Message-ID: On Fri, 1 Jul 2022 13:23:58 GMT, Kevin Rushforth wrote: > While running tests I noticed that your branch is very out of date w.r.t. master. Can you merge in the latest master in order to get a new GHA test run with the latest changes included? It's updated, linux build just passed so probably no issues. ------------- PR: https://git.openjdk.org/jfx/pull/675 From duke at openjdk.org Fri Jul 8 18:47:49 2022 From: duke at openjdk.org (Andy Goryachev) Date: Fri, 8 Jul 2022 18:47:49 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v9] In-Reply-To: References: Message-ID: <2XOkYMxvyIRIOSfVqB563y5Vfv_nSX_uJ5vkBmXS3NM=.69c8dd5a-66bf-414e-820a-be04b6d8eec8@github.com> > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files > > the list of eclipse projects that do compile in Eclipse as a result of this PR are: > - base > - controls > - fxml > - graphics > - jfx > - media > - swing > - swt > - systemTests (can be dropped in favor ot tests > - tests > - web > > Not supported (should be removed from workspace or simply closed): > - apps > - apps/* > - buildSrc Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8289255: fixed tests/.classpath ------------- Changes: - all: https://git.openjdk.org/jfx/pull/804/files - new: https://git.openjdk.org/jfx/pull/804/files/e8f9898e..313cd7bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=07-08 Stats: 14 lines in 2 files changed: 11 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/804.diff Fetch: git fetch https://git.openjdk.org/jfx pull/804/head:pull/804 PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Fri Jul 8 18:47:52 2022 From: duke at openjdk.org (Andy Goryachev) Date: Fri, 8 Jul 2022 18:47:52 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v8] In-Reply-To: <81Le_1U5Ee9xvFQZdgPBTVDsWeMuzjQYrZdOirN8-uU=.f20e1c1a-b333-4575-99da-3795451425f3@github.com> References: <81Le_1U5Ee9xvFQZdgPBTVDsWeMuzjQYrZdOirN8-uU=.f20e1c1a-b333-4575-99da-3795451425f3@github.com> Message-ID: On Fri, 8 Jul 2022 16:56:39 GMT, Andy Goryachev wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files >> >> the list of eclipse projects that do compile in Eclipse as a result of this PR are: >> - base >> - controls >> - fxml >> - graphics >> - jfx >> - media >> - swing >> - swt >> - systemTests (can be dropped in favor ot tests >> - tests >> - web >> >> Not supported (should be removed from workspace or simply closed): >> - apps >> - apps/* >> - buildSrc > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: > > - added javafx.controls/com.sun.javafx.scene.control dependency > - Merge remote-tracking branch 'origin/master' into JDK-8289255 > - 8289255: removed 3DViewer test folders from .classpath > - Merge remote-tracking branch 'origin/master' into JDK-8289255 > - Merge remote-tracking branch 'origin/master' into JDK-8289255 > - 8289255 remove javafx.graphics/build/gensrc as source folder > - 8289255 remove javafx.swing/src/test/java as source folder > - Merge remote-tracking branch 'origin/master' into JDK-8289255 > - Revert "8279297: removed unused Shape.setMode method" > > This reverts commit 6b3b7e51f168a02f68c3bc0324528164680cb6c9. > - 8279297: removed unused Shape.setMode method > - ... and 4 more: https://git.openjdk.org/jfx/compare/2629aae0...e8f9898e Nir, I think I understand what the problem is. For the purposes of this PR, buildSrc, apps(toys, samples), tests are not included. (The purpose of this PR is to be able to compile in Eclipse and get to 0 warnings for essential parts). systemTests *is* included, as it contains system tests, and I am not sure how eclipse actually handles this kind of nested .projects's (tests/.project and tests/system/.project). I will update this PR such that tests/ can be included instead of systemTests/. apps/ will require more work, and is also impacted by the cleanup effort you and Kevin discussed in the related tickets. I would certainly like to participate in this effort, under a separate ticket. To summarize, the list of eclipse projects that do compile in Eclipse as a result of this PR are: - base - controls - fxml - graphics - jfx - media - swing - swt - systemTests (can be dropped in favor ot tests - tests - web Not supported (should be removed from workspace or simply closed): - apps - apps/* - buildSrc ------------- PR: https://git.openjdk.org/jfx/pull/804 From johan at lodgon.com Fri Jul 8 18:50:00 2022 From: johan at lodgon.com (Johan Vos) Date: Fri, 8 Jul 2022 20:50:00 +0200 Subject: CFV: New OpenJFX Committer: Marius Hanl In-Reply-To: <9409a586-5d92-5eba-3b83-d02f00c5520a@oracle.com> References: <9409a586-5d92-5eba-3b83-d02f00c5520a@oracle.com> Message-ID: Vote: YES Op vr 8 jul. 2022 om 19:37 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > I hereby nominate Marius Hanl [1] to OpenJFX Committer. > > Marius is an OpenJFX community member, who has contributed 22 commits > [2] to OpenJFX. > > Votes are due by July 22, 2022 at 13:00 UTC. > > 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 [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#mhanl > > [2] > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Marius+Hanl%22&s=author-date&type=commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at lodgon.com Fri Jul 8 18:50:15 2022 From: johan at lodgon.com (Johan Vos) Date: Fri, 8 Jul 2022 20:50:15 +0200 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_OpenJFX_Committer=3A_Michael_Strau=C3=9F?= In-Reply-To: <24c276e4-8aaf-c054-ecdf-ad6b263d1009@oracle.com> References: <24c276e4-8aaf-c054-ecdf-ad6b263d1009@oracle.com> Message-ID: Vote: YES Op vr 8 jul. 2022 om 19:38 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > I hereby nominate Michael Strau? [1] to OpenJFX Committer. > > Michael is an OpenJFX community member, who has contributed 16 commits > [2] to OpenJFX. > > Votes are due by July 22, 2022 at 13:00 UTC. > > 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 [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#mstrauss > > [2] > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Michael+Strau%C3%9F%22&s=author-date&type=commits > > https://github.com/openjdk/jfx/search?q=author-name%3A%22mstr2%22&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [6] https://openjdk.org/projects#project-committer > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbourges at openjdk.org Fri Jul 8 19:04:55 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 8 Jul 2022 19:04:55 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v3] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> Message-ID: On Fri, 8 Jul 2022 18:02:44 GMT, Kevin Rushforth wrote: >> Yes, the tests now all pass on my MacBook Pro which has a retina display. >> >>> I will merge with my latest marlin code asap = 0.9.4.6 (2 more bugs fixed), low risk (few lines) if you agree. >> >> Yes, that would be fine. Let's change the titles of this PR and the JBS issue to reflect the .6 patch version. Also, can you merge in the latest upstream master? Your branch is very out of date. >> >> Since I am just starting the review, I'm not sure whether we will be able to get this in before the RDP1 deadline, so it will either just barely make JavaFX 19 (if right before RDP1) or it can be integrated early in JavaFX 20. > >> I will merge with my latest marlin code asap = 0.9.4.6 (2 more bugs fixed), low risk (few lines) if you agree. > > (but don't change your branch name or would need to create a new PR, which doesn't seem worth it) Thanks @kevinrushforth for instructions. The dpqs part and stroker changes were released in marlin 0.9.4.5 publicly on my github... so it passed the production to me. If you have any question, please ask. Cheers, Laurent (covid+ since wednesday) ------------- PR: https://git.openjdk.org/jfx/pull/674 From mstrauss at openjdk.org Fri Jul 8 19:05:05 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 8 Jul 2022 19:05:05 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <-4ZjlSo1l7YrQ3m664vyYUaWebiNwcvj0KPefS2s6LU=.bec585fe-c45f-4f3d-8e1b-be8e0c589686@github.com> Message-ID: On Fri, 8 Jul 2022 14:34:54 GMT, Nir Lisker wrote: >> I didn't get into the fine details of the GC discussion yet, but I have a few points I would like to share: >> >> 1. @hjohn's example 4, which seems to be a point of some disagreement, is a _de facto_ issue. Even if the technicalities or semantics imply that this is correct behavior, StackOverflow is littered with "why did my listener suddenly stopped working?" questions that are caused by this, and I have fell into this pitfall more than once myself (by starting from something like example 2, then making a slight change that transforms the code into something like example 4). >> I didn't look yet into the possible alternatives discussed here for dealing with this, but I do believe that going with "this behavior is technically correct" is not the best _practical_ decision, provided that changing it will be backwards compatible. >> 2. On the subject of `Disposer` and cleaning references in a background thread, the JDK has [Cleaner](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/ref/Cleaner.html) (there is a nice recent Inside Java [post](https://inside.java/2022/05/25/clean-cleaner/) about it), which seems to do what we need, at least abstractly. I didn't look at the code to see if it fits our needs exactly. It also uses a `ReferenceQueue` with `PhantomReference`s. >> 3. It is clear to me that whatever GC/referencing model we choose to go with eventually (with whatever combination of fluent vs. regular bindings, listeners vs. bindings, expressions vs. properties...), we will have to document what is expected of the user, and we will have to do it very well. Currently, there are some mentions in the docs of listeners holding strong references, and weak references being used in the implementation ("user beware"), but we will need to be a lot more explicit in my opinion. Something like @hjohn's set of examples or some snippets from this discussion would be a good starting point. If we don't want to commit to some detail, we should at least document the current behavior with a note that it might change. It's just too easy to mess this up (even before this PR was considered). I don't mind taking care of such a PR when an implementation is agreed upon. > >> Additionally, can you file a docs bug to clarify the GC behavior of bindings and mappings as suggested by @nlisker in point 3 of [this comment](https://github.com/openjdk/jfx/pull/675#issuecomment-1176975103)? > > @hjohn If the followup work on this issue is too much and you want to focus on the implementation, you can assign it to me. > I've done some experimenting using a `Cleaner` suggested by @nlisker; > [...] > From what I can see, we'd need to change all locations where `bind` is implemented using a weak listener, and add a `Cleaner`. Yes, this must be implemented for all `*PropertyBase` classes. We can save a few bytes for non-`ConcurrentListenerAccess` observables with an implementation like this: private static class Listener implements InvalidationListener, WeakListener { private final WeakReference wref; private final Cleaner.Cleanable cleanable; public Listener(StringPropertyBase ref, Observable observable) { this.wref = new WeakReference<>(ref); if (observable instanceof ConcurrentListenerAccess) { cleanable = CLEANER.register(ref, this::removeListener); } else { cleanable = null; } } // Note: dispose() must be called in StringPropertyBase.unbind() public void dispose() { if (cleanable != null) { cleanable.clean(); } else { removeListener(); } } private void removeListener() { StringPropertyBase ref = wref.get(); if (ref != null) { ref.observable.removeListener(this); } } @Override public void invalidated(Observable observable) { StringPropertyBase ref = wref.get(); if (ref == null) { dispose(); } else { ref.markInvalid(); } } @Override public boolean wasGarbageCollected() { return wref.get() == null; } } > Those same classes need their add/remove listener methods synchronized (putting synchronized on the static helper methods in ExpressionListener doesn't look like a good idea as it would block listener changes to unrelated properties). Not sure I'm following here. Do you want to implement this pattern for all property implementations? If we just want to implement it for mapped bindings, only the `LazyObjectBinding` class needs to be thread-safe. Note that it's not enough for the `addListener` and `removeListener` methods to be `synchronized`. _All_ reads and writes must be protected, which (in the case of `LazyObjectBinding`) includes the `invalidate` and `isObserved` methods. But if we do that, the lock tax must be paid on every single access to the `ExpressionHelper` field (because `ExpressionHelper` is not thread-safe). Locking any and all usages of `ExpressionHelper` can have performance implications that we need to evaluate carefully. However, I think we might get away with an implementation that only requires locking for the `addListener`/`removeListener` methods, but (crucially) not for `fireValueChangedEvent`: private volatile ConcurrentExpressionHelper helper = null; @Override public synchronized void addListener(InvalidationListener listener) { helper = ConcurrentExpressionHelper.addListener(helper, this, listener); } @Override public synchronized void removeListener(InvalidationListener listener) { helper = ConcurrentExpressionHelper.removeListener(helper, listener); } @Override public synchronized void addListener(ChangeListener listener) { helper = ConcurrentExpressionHelper.addListener(helper, this, listener); } @Override public synchronized void removeListener(ChangeListener listener) { helper = ConcurrentExpressionHelper.removeListener(helper, listener); } protected void fireValueChangedEvent() { ConcurrentExpressionHelper.fireValueChangedEvent(helper); } This implementation works by creating immutable specializations of [ConcurrentExpressionHelper](https://gist.github.com/mstr2/1efc9e866f81622253711a963bd272fc). When a listener is added, a new `ConcurrentExpressionHelper` instance is created, which doesn't interfere with an existing instance that is currently in use by `ConcurrentExpressionHelper.fireValueChangedEvent`. The`ConcurrentExpressionHelper.Generic` specialization is mutable, but uses the lock-free `ConcurrentLinkedQueue` to store its listeners. `ConcurrentExpressionHelper` avoids locking the (probably most frequently invoked) `fireValueChangedEvent` method, but sacrifices cache locality when a large number of listeners is added. We should probably benchmark all of these proposals before deciding on a solution. ------------- PR: https://git.openjdk.org/jfx/pull/675 From lbourges at openjdk.org Fri Jul 8 19:05:03 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 8 Jul 2022 19:05:03 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v3] In-Reply-To: <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> Message-ID: On Thu, 7 Jul 2022 22:46:53 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > fixed pixel color tests on hi-dpi See https://bourgesl.github.io/github-release-stats/?username=bourgesl&repository=marlin-renderer ~ 1000 downloads on 0.9.4.5 releases... ------------- PR: https://git.openjdk.org/jfx/pull/674 From duke at openjdk.org Fri Jul 8 19:12:11 2022 From: duke at openjdk.org (Andy Goryachev) Date: Fri, 8 Jul 2022 19:12:11 GMT Subject: RFR: 8289388: Fix warnings: method is overriding a synchronized method without being synchronized Message-ID: Fixes warnings generated by the latest Eclipse: method is overriding a synchronized method without being synchronized ------------- Commit messages: - 8289388: fixed method is overriding a synchronized method warning Changes: https://git.openjdk.org/jfx/pull/819/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=819&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289388 Stats: 7 lines in 3 files changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/819.diff Fetch: git fetch https://git.openjdk.org/jfx pull/819/head:pull/819 PR: https://git.openjdk.org/jfx/pull/819 From kcr at openjdk.org Fri Jul 8 19:29:18 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Jul 2022 19:29:18 GMT Subject: RFR: 8289835: Change JavaFX release version to 20 Message-ID: Bump the version number of JavaFX to 20. I will integrate this to `master` as part of forking the `jfx19` stabilization branch, which is scheduled for Thursday, July 14, 2022 at 16:00 UTC. ------------- Commit messages: - 8289835: Change JavaFX release version to 20 Changes: https://git.openjdk.org/jfx/pull/820/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=820&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289835 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/820.diff Fetch: git fetch https://git.openjdk.org/jfx pull/820/head:pull/820 PR: https://git.openjdk.org/jfx/pull/820 From thiago.sayao at gmail.com Fri Jul 8 19:44:41 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 8 Jul 2022 16:44:41 -0300 Subject: CFV: New OpenJFX Committer: Marius Hanl In-Reply-To: <9409a586-5d92-5eba-3b83-d02f00c5520a@oracle.com> References: <9409a586-5d92-5eba-3b83-d02f00c5520a@oracle.com> Message-ID: Vote: YES PS: I understand I can vote, if not, sorry for the mistake. -- Thiago Em sex., 8 de jul. de 2022 ?s 14:37, Kevin Rushforth < kevin.rushforth at oracle.com> escreveu: > I hereby nominate Marius Hanl [1] to OpenJFX Committer. > > Marius is an OpenJFX community member, who has contributed 22 commits > [2] to OpenJFX. > > Votes are due by July 22, 2022 at 13:00 UTC. > > 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 [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#mhanl > > [2] > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Marius+Hanl%22&s=author-date&type=commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Jul 8 19:54:11 2022 From: duke at openjdk.org (Andy Goryachev) Date: Fri, 8 Jul 2022 19:54:11 GMT Subject: RFR: 8289389: Fix warnings: type should also implement hashCode() since it overrides Object.equals() Message-ID: - added missing hashCode() methods ------------- Commit messages: - 8289389: implemented missing hashCode() Changes: https://git.openjdk.org/jfx/pull/821/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=821&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289389 Stats: 81 lines in 9 files changed: 70 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/821.diff Fetch: git fetch https://git.openjdk.org/jfx pull/821/head:pull/821 PR: https://git.openjdk.org/jfx/pull/821 From prr at openjdk.org Fri Jul 8 20:07:12 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 8 Jul 2022 20:07:12 GMT Subject: RFR: 8288137: The set of available printers is not updated without application restart Message-ID: This fixes the issue that the default printer or set of available printers is fixed from the first call to it in the lifetime of the application. Now subsequent calls will check to see if there are changes. A manual test is provided for verifying this - it requires you to add/remove printers at the system level to verify anything related to this fix. ------------- Commit messages: - 8288137 - 8288137 - 8288137 Changes: https://git.openjdk.org/jfx/pull/817/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=817&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288137 Stats: 216 lines in 3 files changed: 199 ins; 3 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/817.diff Fetch: git fetch https://git.openjdk.org/jfx pull/817/head:pull/817 PR: https://git.openjdk.org/jfx/pull/817 From kcr at openjdk.org Fri Jul 8 20:07:13 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Jul 2022 20:07:13 GMT Subject: RFR: 8288137: The set of available printers is not updated without application restart In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 22:23:55 GMT, Phil Race wrote: > This fixes the issue that the default printer or set of available printers is fixed from the first call to it in the lifetime of the application. > Now subsequent calls will check to see if there are changes. > A manual test is provided for verifying this - it requires you to add/remove printers at the system level to verify anything related to this fix. I tested it on Windows by adding and removing a printer, and it does what I would expect. I left a couple questions on the implementation, along with a minor formatting issue. You'll also need to fix the whitespace error that `jcheck` reported. modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java line 100: > 98: // The map is useful when updating > 99: private static HashMap pMap = new HashMap<>(); > 100: //private static TreeSet printers = null; Since this is unused, I recommend to remove it. modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java line 138: > 136: } > 137: } > 138: lastTime = System.currentTimeMillis(); Is `lastTime` intended to be the last time you updated the printers or the last time the `getAllPrinters` method was called? If the former, then you would want to set `lastTime` right after `updatePrinters`. If the latter, then it's fine where it is. modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java line 192: > 190: if (oldDefaultService != null && newDefaultService != null) { > 191: if (!oldDefaultService.equals(newDefaultService)) { > 192: defaultPrinter = findDefaultPrinter(printerSet, newDefaultService); Don't you also want to find the default printer in the case where the old `default` printer was null and the `newDefaultService` is not null? modules/javafx.graphics/src/main/java/javafx/print/Printer.java line 95: > 93: } else { > 94: defaultPrinter.setValue(p); > 95: } Minor: indentation is off for these two lines ------------- PR: https://git.openjdk.org/jfx/pull/817 From prr at openjdk.org Fri Jul 8 20:07:13 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 8 Jul 2022 20:07:13 GMT Subject: RFR: 8288137: The set of available printers is not updated without application restart In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 15:07:46 GMT, Kevin Rushforth wrote: >> This fixes the issue that the default printer or set of available printers is fixed from the first call to it in the lifetime of the application. >> Now subsequent calls will check to see if there are changes. >> A manual test is provided for verifying this - it requires you to add/remove printers at the system level to verify anything related to this fix. > > modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java line 138: > >> 136: } >> 137: } >> 138: lastTime = System.currentTimeMillis(); > > Is `lastTime` intended to be the last time you updated the printers or the last time the `getAllPrinters` method was called? If the former, then you would want to set `lastTime` right after `updatePrinters`. If the latter, then it's fine where it is. The last time we updated. If the number of printers has changed I will always rebuild the printer list (set) but if they are the same what are the odds a printer was removed and another one added ? I figured if 2 minutes has passed since we last checked it is worth it, but I am not re-setting this every time we called getAllPrinters() else if you kept calling it every 30 seconds .. then we'd never get past that check. > modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java line 192: > >> 190: if (oldDefaultService != null && newDefaultService != null) { >> 191: if (!oldDefaultService.equals(newDefaultService)) { >> 192: defaultPrinter = findDefaultPrinter(printerSet, newDefaultService); > > Don't you also want to find the default printer in the case where the old `default` printer was null and the `newDefaultService` is not null? Updating this. > modules/javafx.graphics/src/main/java/javafx/print/Printer.java line 95: > >> 93: } else { >> 94: defaultPrinter.setValue(p); >> 95: } > > Minor: indentation is off for these two lines That's what you get for trying to use an IDE ... will fix .. ------------- PR: https://git.openjdk.org/jfx/pull/817 From kcr at openjdk.org Fri Jul 8 20:07:13 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Jul 2022 20:07:13 GMT Subject: RFR: 8288137: The set of available printers is not updated without application restart In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 17:31:11 GMT, Phil Race wrote: >> modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java line 138: >> >>> 136: } >>> 137: } >>> 138: lastTime = System.currentTimeMillis(); >> >> Is `lastTime` intended to be the last time you updated the printers or the last time the `getAllPrinters` method was called? If the former, then you would want to set `lastTime` right after `updatePrinters`. If the latter, then it's fine where it is. > > The last time we updated. > If the number of printers has changed I will always rebuild the printer list (set) but if they are the same > what are the odds a printer was removed and another one added ? > I figured if 2 minutes has passed since we last checked it is worth it, but I am not re-setting this every > time we called getAllPrinters() else if you kept calling it every 30 seconds .. then we'd never get past that check. In that case shouldn't the assignment of `lastTime` be moved up two lines, right below the call to `updatePrinters`? Or am I missing something? ------------- PR: https://git.openjdk.org/jfx/pull/817 From duke at openjdk.org Fri Jul 8 20:18:11 2022 From: duke at openjdk.org (Andy Goryachev) Date: Fri, 8 Jul 2022 20:18:11 GMT Subject: RFR: 8289381: Fix warnings: The assignment to variable has no effect Message-ID: <8ZIqfLXOqwV6k3BMjgvJaIeshaltbyWD5i4ROMqdh1A=.9abf256f-c3d0-4eb9-852a-c15749619b51@github.com> trivial change, removed unnecessary code. ------------- Commit messages: - 8289381: fixed The assignment to variable has no effect Changes: https://git.openjdk.org/jfx/pull/822/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=822&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289381 Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/822.diff Fetch: git fetch https://git.openjdk.org/jfx pull/822/head:pull/822 PR: https://git.openjdk.org/jfx/pull/822 From prr at openjdk.org Fri Jul 8 20:30:32 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 8 Jul 2022 20:30:32 GMT Subject: RFR: 8288137: The set of available printers is not updated without application restart [v2] In-Reply-To: References: Message-ID: > This fixes the issue that the default printer or set of available printers is fixed from the first call to it in the lifetime of the application. > Now subsequent calls will check to see if there are changes. > A manual test is provided for verifying this - it requires you to add/remove printers at the system level to verify anything related to this fix. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8288137 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/817/files - new: https://git.openjdk.org/jfx/pull/817/files/0cb60d76..4932450c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=817&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=817&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/817.diff Fetch: git fetch https://git.openjdk.org/jfx pull/817/head:pull/817 PR: https://git.openjdk.org/jfx/pull/817 From prr at openjdk.org Fri Jul 8 20:30:32 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 8 Jul 2022 20:30:32 GMT Subject: RFR: 8288137: The set of available printers is not updated without application restart [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 18:12:36 GMT, Kevin Rushforth wrote: >> The last time we updated. >> If the number of printers has changed I will always rebuild the printer list (set) but if they are the same >> what are the odds a printer was removed and another one added ? >> I figured if 2 minutes has passed since we last checked it is worth it, but I am not re-setting this every >> time we called getAllPrinters() else if you kept calling it every 30 seconds .. then we'd never get past that check. > > In that case shouldn't the assignment of `lastTime` be moved up two lines, right below the call to `updatePrinters`? Or am I missing something? I guess I knew what I wanted but didn't have the code to match :-) ------------- PR: https://git.openjdk.org/jfx/pull/817 From thiago.sayao at gmail.com Fri Jul 8 20:40:22 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 8 Jul 2022 17:40:22 -0300 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_OpenJFX_Committer=3A_Michael_Strau=C3=9F?= In-Reply-To: <24c276e4-8aaf-c054-ecdf-ad6b263d1009@oracle.com> References: <24c276e4-8aaf-c054-ecdf-ad6b263d1009@oracle.com> Message-ID: Vote: YES -- Thiago. Em sex., 8 de jul. de 2022 ?s 14:38, Kevin Rushforth < kevin.rushforth at oracle.com> escreveu: > I hereby nominate Michael Strau? [1] to OpenJFX Committer. > > Michael is an OpenJFX community member, who has contributed 16 commits > [2] to OpenJFX. > > Votes are due by July 22, 2022 at 13:00 UTC. > > 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 [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#mstrauss > > [2] > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Michael+Strau%C3%9F%22&s=author-date&type=commits > > https://github.com/openjdk/jfx/search?q=author-name%3A%22mstr2%22&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [6] https://openjdk.org/projects#project-committer > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Jul 8 20:52:15 2022 From: duke at openjdk.org (Andy Goryachev) Date: Fri, 8 Jul 2022 20:52:15 GMT Subject: RFR: 8289394: Fix warnings: Unlikely argument type Message-ID: Fixes "Unlikely argument type" warning generated by the latest Eclipse IDE. This warning should be reclassified as an error, as it catches bugs missed by javac. In this case, the following places seem to contain bugs: - apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/TimelineController.java - modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/GetEvent.java The fixes include: - using objects of the right type - adding @SuppressWarnings("unlikely-arg-type") in places where intended (e.g. assertFalse) There was an earlier discussion about using IDE-specific @SuppressWarnings in the code. While I might disagree (I think it is ok to use IDE-specific @SuppressWarnings), the tests can be reworked to avoid @SuppressWarnings. Please let me know. Thanks! ------------- Commit messages: - 8289394: fixed whitespace - 8289394: fixed unlikely argument type warning Changes: https://git.openjdk.org/jfx/pull/823/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=823&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289394 Stats: 48 lines in 15 files changed: 18 ins; 12 del; 18 mod Patch: https://git.openjdk.org/jfx/pull/823.diff Fetch: git fetch https://git.openjdk.org/jfx pull/823/head:pull/823 PR: https://git.openjdk.org/jfx/pull/823 From jhendrikx at openjdk.org Fri Jul 8 20:52:58 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 8 Jul 2022 20:52:58 GMT Subject: Integrated: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Thu, 18 Nov 2021 20:58:06 GMT, John Hendrikx wrote: > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Standard JavaFX + Optional: > label.textProperty().bind(Bindings.createStringBinding( > () -> Optinal.ofNullable(employee.get()) > .map(Employee::getCompany) > .map(Company::getName) > .orElse(""), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. This pull request has now been integrated. Changeset: 60c75b82 Author: John Hendrikx Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/60c75b82a4e1523b108fa79f44084190d78f5be1 Stats: 1923 lines in 12 files changed: 1919 ins; 0 del; 4 mod 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue Reviewed-by: nlisker, mstrauss, kcr ------------- PR: https://git.openjdk.org/jfx/pull/675 From prr at openjdk.org Fri Jul 8 21:01:31 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 8 Jul 2022 21:01:31 GMT Subject: RFR: 8288137: The set of available printers is not updated without application restart [v3] In-Reply-To: References: Message-ID: > This fixes the issue that the default printer or set of available printers is fixed from the first call to it in the lifetime of the application. > Now subsequent calls will check to see if there are changes. > A manual test is provided for verifying this - it requires you to add/remove printers at the system level to verify anything related to this fix. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8288137 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/817/files - new: https://git.openjdk.org/jfx/pull/817/files/4932450c..21ec7bdd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=817&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=817&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/817.diff Fetch: git fetch https://git.openjdk.org/jfx pull/817/head:pull/817 PR: https://git.openjdk.org/jfx/pull/817 From prr at openjdk.org Fri Jul 8 21:01:31 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 8 Jul 2022 21:01:31 GMT Subject: RFR: 8288137: The set of available printers is not updated without application restart [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 20:26:08 GMT, Phil Race wrote: >> In that case shouldn't the assignment of `lastTime` be moved up two lines, right below the call to `updatePrinters`? Or am I missing something? > > I guess I knew what I wanted but didn't have the code to match :-) I think I know how it ended up outside the conditions .. I also need to set it up on the first time through else the 2nd call will always trigger a refresh since otherwise lastTime will be zero .. fixing that. ------------- PR: https://git.openjdk.org/jfx/pull/817 From jhendrikx at openjdk.org Fri Jul 8 21:03:03 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 8 Jul 2022 21:03:03 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v18] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <-4ZjlSo1l7YrQ3m664vyYUaWebiNwcvj0KPefS2s6LU=.bec585fe-c45f-4f3d-8e1b-be8e0c589686@github.com> Message-ID: On Fri, 8 Jul 2022 19:01:31 GMT, Michael Strau? wrote: > Not sure I'm following here. Do you want to implement this pattern for all property implementations? If we just want to implement it for mapped bindings, only the `LazyObjectBinding` class needs to be thread-safe. Yes, true, only making it thread-safe for that class should remove a chain of fluent bindings. I think however that it would be good to implement this for as many classes as we can as the stub cleaning is normally only triggered on invalidation/changes (and as I recently discovered, when `ExpressionHelper` resizes its backing list). > Note that it's not enough for the `addListener` and `removeListener` methods to be `synchronized`. _All_ reads and writes must be protected, which (in the case of `LazyObjectBinding`) includes the `invalidate` and `isObserved` methods. Yes, true, I only fixed synchronization issues in my experiment and didn't look much further than that yet. > But if we do that, the lock tax must be paid on every single access to the `ExpressionHelper` field (because `ExpressionHelper` is not thread-safe). Locking any and all usages of `ExpressionHelper` can have performance implications that we need to evaluate carefully. Yeah, we shouldn't do that, it synchronizes all accesses to all property lists everywhere, it would be an easy "fix" as it's in one place, but it doesn't feel right. > However, I think we might get away with an implementation that only requires locking for the `addListener`/`removeListener` methods, but (crucially) not for `fireValueChangedEvent`: > > This implementation works by creating immutable specializations of [ConcurrentExpressionHelper](https://gist.github.com/mstr2/1efc9e866f81622253711a963bd272fc). When a listener is added, a new `ConcurrentExpressionHelper` instance is created, which doesn't interfere with an existing instance that is currently in use by `ConcurrentExpressionHelper.fireValueChangedEvent`. The`ConcurrentExpressionHelper.Generic` specialization is mutable, but uses the lock-free `ConcurrentLinkedQueue` to store its listeners. I see you have been playing with improving `ExpressionHelper` as well :) I noticed there is a bug in the current one, where a copy of the list is made each time when `locked` is `true`, even when the list was already copied for the "current" lock. I ran into this problem right after I fixed the performance issue (it wasn't obvious before as it was already very slow, but basically an extra copy is happening in some circumstances on top of the array copying that is done to remove an entry). The situation where `locked` is true doesn't happen that often for normal code, but it happens specifically in the case when a call to `invalidated` is cleaning up dead stubs... > `ConcurrentExpressionHelper` avoids locking the (probably most frequently invoked) `fireValueChangedEvent` method, but sacrifices cache locality when a large number of listeners is added. We should probably benchmark all of these proposals before deciding on a solution. Yes, I think that's a good idea, I considered using `ConcurrentLinkedQueue` as well since we don't need a structure with index based access, but I couldn't find one with good O performance for `remove(T)` that wouldn't subtly change the current semantics. FWIW, here's the quick `Collection` implementation I whipped up: https://gist.github.com/hjohn/8fee1e5d1a9eacbbb3e021f8a37f582b And the changes in `ExpressionHelper` (including different locking): https://gist.github.com/hjohn/f88362ea78adef96f3a54d97e2405076 ------------- PR: https://git.openjdk.org/jfx/pull/675 From nlisker at openjdk.org Fri Jul 8 21:08:48 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 8 Jul 2022 21:08:48 GMT Subject: RFR: 8289381: Fix warnings: The assignment to variable has no effect In-Reply-To: <8ZIqfLXOqwV6k3BMjgvJaIeshaltbyWD5i4ROMqdh1A=.9abf256f-c3d0-4eb9-852a-c15749619b51@github.com> References: <8ZIqfLXOqwV6k3BMjgvJaIeshaltbyWD5i4ROMqdh1A=.9abf256f-c3d0-4eb9-852a-c15749619b51@github.com> Message-ID: <5C5gMKX2EeszcwQSNPrEZAqXkwHpoajEXJQ0QnXRCnc=.6ff6b4e7-45b8-4caa-9f13-b3f29e6ef1e6@github.com> On Fri, 8 Jul 2022 20:11:22 GMT, Andy Goryachev wrote: > trivial change, removed unnecessary code. Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/822 From duke at openjdk.org Fri Jul 8 21:13:50 2022 From: duke at openjdk.org (Andy Goryachev) Date: Fri, 8 Jul 2022 21:13:50 GMT Subject: Integrated: 8289381: Fix warnings: The assignment to variable has no effect In-Reply-To: <8ZIqfLXOqwV6k3BMjgvJaIeshaltbyWD5i4ROMqdh1A=.9abf256f-c3d0-4eb9-852a-c15749619b51@github.com> References: <8ZIqfLXOqwV6k3BMjgvJaIeshaltbyWD5i4ROMqdh1A=.9abf256f-c3d0-4eb9-852a-c15749619b51@github.com> Message-ID: On Fri, 8 Jul 2022 20:11:22 GMT, Andy Goryachev wrote: > trivial change, removed unnecessary code. This pull request has now been integrated. Changeset: 187fbe1e Author: Andy Goryachev Committer: Nir Lisker URL: https://git.openjdk.org/jfx/commit/187fbe1e4f41de023fdff245f48370d146d671aa Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod 8289381: Fix warnings: The assignment to variable has no effect Reviewed-by: nlisker ------------- PR: https://git.openjdk.org/jfx/pull/822 From kcr at openjdk.org Fri Jul 8 21:39:56 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Jul 2022 21:39:56 GMT Subject: RFR: 8288137: The set of available printers is not updated without application restart [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:01:31 GMT, Phil Race wrote: >> This fixes the issue that the default printer or set of available printers is fixed from the first call to it in the lifetime of the application. >> Now subsequent calls will check to see if there are changes. >> A manual test is provided for verifying this - it requires you to add/remove printers at the system level to verify anything related to this fix. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8288137 The changes to when `lastTime` is stored looks good (both of them). I just noticed that the test is backwards, though. ------------- PR: https://git.openjdk.org/jfx/pull/817 From kcr at openjdk.org Fri Jul 8 21:39:59 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Jul 2022 21:39:59 GMT Subject: RFR: 8288137: The set of available printers is not updated without application restart [v2] In-Reply-To: References: Message-ID: <0QIwq1nhkVbGLFfb13d4LAS2BFM1KMhoSyBu7AjgQ64=.45db7c7c-4b85-4790-bf44-d971638c2168@github.com> On Fri, 8 Jul 2022 20:30:32 GMT, Phil Race wrote: >> This fixes the issue that the default printer or set of available printers is fixed from the first call to it in the lifetime of the application. >> Now subsequent calls will check to see if there are changes. >> A manual test is provided for verifying this - it requires you to add/remove printers at the system level to verify anything related to this fix. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8288137 modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java line 133: > 131: PrintServiceLookup.lookupPrintServices(null, null); > 132: if ((newServices.length != printerSet.size()) || > 133: (lastTime + 120000) > System.currentTimeMillis()) { I missed this earlier. The test is backwards. It should be `<` not `>` . ------------- PR: https://git.openjdk.org/jfx/pull/817 From nlisker at openjdk.org Fri Jul 8 21:40:53 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 8 Jul 2022 21:40:53 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v9] In-Reply-To: <2XOkYMxvyIRIOSfVqB563y5Vfv_nSX_uJ5vkBmXS3NM=.69c8dd5a-66bf-414e-820a-be04b6d8eec8@github.com> References: <2XOkYMxvyIRIOSfVqB563y5Vfv_nSX_uJ5vkBmXS3NM=.69c8dd5a-66bf-414e-820a-be04b6d8eec8@github.com> Message-ID: On Fri, 8 Jul 2022 18:47:49 GMT, Andy Goryachev wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files >> >> the list of eclipse projects that do compile in Eclipse as a result of this PR are: >> - base >> - controls >> - fxml >> - graphics >> - jfx >> - media >> - swing >> - swt >> - systemTests (can be dropped in favor ot tests >> - tests >> - web >> >> Not supported (should be removed from workspace or simply closed): >> - apps >> - apps/* >> - buildSrc > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8289255: fixed tests/.classpath Since apps are not included in the goal of this PR, please revert the changes made to them. I will review the changes to `tests` and then the PR can be integrated if there are no further issues. A followup issue should be filed for `apps` in JBS if there is none. ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Fri Jul 8 21:41:50 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Jul 2022 21:41:50 GMT Subject: RFR: 8289394: Fix warnings: Unlikely argument type In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 20:31:31 GMT, Andy Goryachev wrote: > Fixes "Unlikely argument type" warning generated by the latest Eclipse IDE. > > This warning should be reclassified as an error, as it catches bugs missed by javac. In this case, the following places seem to contain bugs: > - apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/TimelineController.java > - modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/GetEvent.java > > The fixes include: > - using objects of the right type > - adding @SuppressWarnings("unlikely-arg-type") in places where intended (e.g. assertFalse) > > There was an earlier discussion about using IDE-specific @SuppressWarnings in the code. While I might disagree (I think it is ok to use IDE-specific @SuppressWarnings), the tests can be reworked to avoid @SuppressWarnings. Please let me know. Thanks! This will need a bit more scrutiny since there is a logic change. I suspect the proposed change is correct and that the existing code is buggy. I'll take a look at the `@SuppressWarnings` question. ------------- PR: https://git.openjdk.org/jfx/pull/823 From duke at openjdk.org Fri Jul 8 21:44:06 2022 From: duke at openjdk.org (Andy Goryachev) Date: Fri, 8 Jul 2022 21:44:06 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package Message-ID: The fix includes: - renaming of offending methods to avoid confusion - explicitly declaring the offending methods as private ------------- Commit messages: - 8289384: fixed method does not override the inherited... warning Changes: https://git.openjdk.org/jfx/pull/824/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=824&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289384 Stats: 28 lines in 11 files changed: 1 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/824.diff Fetch: git fetch https://git.openjdk.org/jfx pull/824/head:pull/824 PR: https://git.openjdk.org/jfx/pull/824 From kcr at openjdk.org Fri Jul 8 21:46:51 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Jul 2022 21:46:51 GMT Subject: RFR: 8289389: Fix warnings: type should also implement hashCode() since it overrides Object.equals() In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 19:46:20 GMT, Andy Goryachev wrote: > - added missing hashCode() methods This is not a complete review, just one thing I spotted quickly. modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 2329: > 2327: return 0; > 2328: } > 2329: return location.hashCode(); Shouldn't this be: `location.toExternalForm().hashCode()`? ------------- PR: https://git.openjdk.org/jfx/pull/821 From nlisker at openjdk.org Fri Jul 8 21:53:50 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 8 Jul 2022 21:53:50 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 23:47:21 GMT, Kevin Rushforth wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files >> >> the list of eclipse projects that do compile in Eclipse as a result of this PR are: >> - base >> - controls >> - fxml >> - graphics >> - jfx >> - media >> - swing >> - swt >> - systemTests (can be dropped in favor ot tests >> - tests >> - web >> >> Not supported (should be removed from workspace or simply closed): >> - apps >> - apps/* >> - buildSrc > > Once the OCA status has been verified, the review can proceed formally. > > @nlisker Would you be able to review these changes? I'm not an Eclipse user. > > @kleopatra your input would be helpful, too, if you are willing to take a look. @kevinrushforth 2 questions that are relevant to the future work on the Eclipse files: 1. The jfx gradle build treats `tests/system` as a project but not its parent `test`. The cleanup talked about wiring up `manual` and `performance` to the build. Do you have an idea when the work on this will start? 2. The cleanup also talked about moving `apps/toys` and `apps/tests` to `tests/manual`. This means that `apps/samples` is the only folder to remain in `apps` (`apps/performance` was removed already). Is there a point to keeping the hierarchy? Maybe just `apps` or just `samples` will be sufficient in this case. ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Fri Jul 8 21:53:50 2022 From: duke at openjdk.org (Andy Goryachev) Date: Fri, 8 Jul 2022 21:53:50 GMT Subject: RFR: 8289389: Fix warnings: type should also implement hashCode() since it overrides Object.equals() [v2] In-Reply-To: References: Message-ID: <0fTAATcre_hBsBKlRtFkFOqehJE4YZvgm0D4Q2rKJK8=.03babaf5-5f65-4b49-a0da-da4e30ef2a31@github.com> > - added missing hashCode() methods Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8289389: toExternalForm() ------------- Changes: - all: https://git.openjdk.org/jfx/pull/821/files - new: https://git.openjdk.org/jfx/pull/821/files/8a371304..d82e683f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=821&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=821&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/821.diff Fetch: git fetch https://git.openjdk.org/jfx pull/821/head:pull/821 PR: https://git.openjdk.org/jfx/pull/821 From duke at openjdk.org Fri Jul 8 21:53:51 2022 From: duke at openjdk.org (Andy Goryachev) Date: Fri, 8 Jul 2022 21:53:51 GMT Subject: RFR: 8289389: Fix warnings: type should also implement hashCode() since it overrides Object.equals() [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:41:29 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8289389: toExternalForm() > > modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 2329: > >> 2327: return 0; >> 2328: } >> 2329: return location.hashCode(); > > Shouldn't this be: `location.toExternalForm().hashCode()`? good point. will fix. ------------- PR: https://git.openjdk.org/jfx/pull/821 From nlisker at openjdk.org Fri Jul 8 22:03:33 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 8 Jul 2022 22:03:33 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private modules/javafx.graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderGraphics.java line 92: > 90: BaseShaderContext getBaseShaderContext() { > 91: return context; > 92: } Mentioning this was brought up in relation to a different PR: https://github.com/openjdk/jfx/pull/628#issuecomment-924898354 ------------- PR: https://git.openjdk.org/jfx/pull/824 From prr at openjdk.org Fri Jul 8 22:27:41 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 8 Jul 2022 22:27:41 GMT Subject: RFR: 8288137: The set of available printers is not updated without application restart [v4] In-Reply-To: References: Message-ID: <0rXLXNASeWJqc2xtUMu2faY4lqmCUXraCDxg-fdewXw=.34b11ffc-4388-4386-8f16-41c5ff81b37e@github.com> > This fixes the issue that the default printer or set of available printers is fixed from the first call to it in the lifetime of the application. > Now subsequent calls will check to see if there are changes. > A manual test is provided for verifying this - it requires you to add/remove printers at the system level to verify anything related to this fix. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8288137 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/817/files - new: https://git.openjdk.org/jfx/pull/817/files/21ec7bdd..490e17da Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=817&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=817&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/817.diff Fetch: git fetch https://git.openjdk.org/jfx pull/817/head:pull/817 PR: https://git.openjdk.org/jfx/pull/817 From prr at openjdk.org Fri Jul 8 22:27:44 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 8 Jul 2022 22:27:44 GMT Subject: RFR: 8288137: The set of available printers is not updated without application restart [v2] In-Reply-To: <0QIwq1nhkVbGLFfb13d4LAS2BFM1KMhoSyBu7AjgQ64=.45db7c7c-4b85-4790-bf44-d971638c2168@github.com> References: <0QIwq1nhkVbGLFfb13d4LAS2BFM1KMhoSyBu7AjgQ64=.45db7c7c-4b85-4790-bf44-d971638c2168@github.com> Message-ID: On Fri, 8 Jul 2022 21:13:37 GMT, Kevin Rushforth wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8288137 > > modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java line 133: > >> 131: PrintServiceLookup.lookupPrintServices(null, null); >> 132: if ((newServices.length != printerSet.size()) || >> 133: (lastTime + 120000) > System.currentTimeMillis()) { > > I missed this earlier. The test is backwards. It should be `<` not `>` . fixed ------------- PR: https://git.openjdk.org/jfx/pull/817 From duke at openjdk.org Fri Jul 8 22:27:52 2022 From: duke at openjdk.org (Andy Goryachev) Date: Fri, 8 Jul 2022 22:27:52 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v10] In-Reply-To: References: Message-ID: > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files > > the list of eclipse projects that do compile in Eclipse as a result of this PR are: > - base > - controls > - fxml > - graphics > - jfx > - media > - swing > - swt > - systemTests (can be dropped in favor ot tests > - tests > - web > > Not supported (should be removed from workspace or simply closed): > - apps > - apps/* > - buildSrc Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8289255: revert apps/ ------------- Changes: - all: https://git.openjdk.org/jfx/pull/804/files - new: https://git.openjdk.org/jfx/pull/804/files/313cd7bc..dbcd4f73 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=08-09 Stats: 58 lines in 2 files changed: 0 ins; 34 del; 24 mod Patch: https://git.openjdk.org/jfx/pull/804.diff Fetch: git fetch https://git.openjdk.org/jfx pull/804/head:pull/804 PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Fri Jul 8 22:27:53 2022 From: duke at openjdk.org (Andy Goryachev) Date: Fri, 8 Jul 2022 22:27:53 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v9] In-Reply-To: References: <2XOkYMxvyIRIOSfVqB563y5Vfv_nSX_uJ5vkBmXS3NM=.69c8dd5a-66bf-414e-820a-be04b6d8eec8@github.com> Message-ID: On Fri, 8 Jul 2022 21:37:38 GMT, Nir Lisker wrote: > Since apps are not included in the goal of this PR, please revert the changes made to them. reverted. ------------- PR: https://git.openjdk.org/jfx/pull/804 From mstrauss at openjdk.org Fri Jul 8 23:12:50 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 8 Jul 2022 23:12:50 GMT Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value [v6] In-Reply-To: References: Message-ID: > The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa. > > The following program shows the problem for HBox: > > Region r1 = new Region(); > Region r2 = new Region(); > Region r3 = new Region(); > Region r4 = new Region(); > Region r5 = new Region(); > Region r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6); > hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox1.setPrefHeight(40); > > r1 = new Region(); > r2 = new Region(); > r3 = new Region(); > r4 = new Region(); > r5 = new Region(); > r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6); > hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox2.setPrefHeight(40); > hbox2.setPrefWidth(152); > > VBox root = new VBox(new HBox(hbox1), new HBox(hbox2)); > root.setSpacing(20); > Scene scene = new Scene(root, 500, 250); > > primaryStage.setScene(scene); > primaryStage.show(); > > > Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example. > ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png) > > I've filed a bug report and will change the title of the GitHub issue as soon as it's posted. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge branch 'openjdk:master' into fixes/box-snap-to-pixel - revert snappedSum - don't call snappedSum in hot loop - Improved code documentation - Merge branch 'master' into fixes/box-snap-to-pixel - changed some method names, make test config a local class - added documentation, improved method names - Merge branch 'master' into fixes/box-snap-to-pixel - Fix pixel-snapping glitches in VBox/HBox - Failing test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/445/files - new: https://git.openjdk.org/jfx/pull/445/files/e8ffd3d7..94c1a7c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=445&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=445&range=04-05 Stats: 2982 lines in 63 files changed: 2238 ins; 44 del; 700 mod Patch: https://git.openjdk.org/jfx/pull/445.diff Fetch: git fetch https://git.openjdk.org/jfx pull/445/head:pull/445 PR: https://git.openjdk.org/jfx/pull/445 From jhendrikx at openjdk.org Fri Jul 8 23:49:44 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 8 Jul 2022 23:49:44 GMT Subject: RFR: 8289389: Fix warnings: type should also implement hashCode() since it overrides Object.equals() [v2] In-Reply-To: <0fTAATcre_hBsBKlRtFkFOqehJE4YZvgm0D4Q2rKJK8=.03babaf5-5f65-4b49-a0da-da4e30ef2a31@github.com> References: <0fTAATcre_hBsBKlRtFkFOqehJE4YZvgm0D4Q2rKJK8=.03babaf5-5f65-4b49-a0da-da4e30ef2a31@github.com> Message-ID: On Fri, 8 Jul 2022 21:53:50 GMT, Andy Goryachev wrote: >> - added missing hashCode() methods > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8289389: toExternalForm() Just a general note, shouldn't most of these use `Objects.hash`? I see a lot of code in the form of: if(x == null) return 0; return x.hashCode(); And even a few where hashes are calculated manually for two values: x.hashCode() * 31 + y.hashCode(); These could be written as: Objects.hash(x); // null check for free Objects.hash(x, y); // free null checks and hashes are merged modules/javafx.graphics/src/main/java/com/sun/javafx/css/CalculatedValue.java line 101: > 99: } > 100: return h; > 101: } Just an example, but wouldn't: `Objects.hash(relative, origin, value)` here work just as well? ------------- PR: https://git.openjdk.org/jfx/pull/821 From nlisker at openjdk.org Sat Jul 9 01:31:48 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 9 Jul 2022 01:31:48 GMT Subject: RFR: 8289389: Fix warnings: type should also implement hashCode() since it overrides Object.equals() [v2] In-Reply-To: References: <0fTAATcre_hBsBKlRtFkFOqehJE4YZvgm0D4Q2rKJK8=.03babaf5-5f65-4b49-a0da-da4e30ef2a31@github.com> Message-ID: <6XudVuXK7LMoL4WOJx0fwAS6sDGFBtKB1DvZ8QVsfo0=.50f76f4a-57c1-46d0-b946-7127ff296818@github.com> On Fri, 8 Jul 2022 23:45:58 GMT, John Hendrikx wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8289389: toExternalForm() > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/CalculatedValue.java line 101: > >> 99: } >> 100: return h; >> 101: } > > Just an example, but wouldn't: `Objects.hash(relative, origin, value)` here work just as well? Honestly, I would just turn this class into a `record` and everything will be taken care of. I'm not sure it is within the scope of the fix. ------------- PR: https://git.openjdk.org/jfx/pull/821 From nlisker at openjdk.org Sat Jul 9 03:16:30 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 9 Jul 2022 03:16:30 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v10] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 22:27:52 GMT, Andy Goryachev wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files >> >> the list of eclipse projects that do compile in Eclipse as a result of this PR are: >> - base >> - controls >> - fxml >> - graphics >> - jfx >> - media >> - swing >> - swt >> - systemTests (can be dropped in favor ot tests >> - tests >> - web >> >> Not supported (should be removed from workspace or simply closed): >> - apps >> - apps/* >> - buildSrc > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8289255: revert apps/ It might be a good idea to add the JUnit 5 container to all modules preemptively so that when someone adds a test with Junit 5 we won't need to patch the classpath file ad-hoc. Fine to leave as is. ------------- Marked as reviewed by nlisker (Reviewer). PR: https://git.openjdk.org/jfx/pull/804 From ajit.ghaisas at oracle.com Sat Jul 9 05:52:09 2022 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Sat, 9 Jul 2022 05:52:09 +0000 Subject: =?utf-8?B?UmU6IENGVjogTmV3IE9wZW5KRlggQ29tbWl0dGVyOiBNaWNoYWVsIFN0cmF1?= =?utf-8?B?w58=?= In-Reply-To: <24c276e4-8aaf-c054-ecdf-ad6b263d1009@oracle.com> References: <24c276e4-8aaf-c054-ecdf-ad6b263d1009@oracle.com> Message-ID: <6D906AFF-0BCA-4F89-BC12-D867B40168D6@oracle.com> Vote : YES Regards, Ajit > On 08-Jul-2022, at 6:01 PM, Kevin Rushforth wrote: > > I hereby nominate Michael Strau? [1] to OpenJFX Committer. > > Michael is an OpenJFX community member, who has contributed 16 commits [2] to OpenJFX. > > Votes are due by July 22, 2022 at 13:00 UTC. > > 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 [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#mstrauss > > [2] > https://github.com/openjdk/jfx/search?q=author-name%3A%22Michael+Strau%C3%9F%22&s=author-date&type=commits > https://github.com/openjdk/jfx/search?q=author-name%3A%22mstr2%22&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [6] https://openjdk.org/projects#project-committer > > > From ajit.ghaisas at oracle.com Sat Jul 9 05:53:16 2022 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Sat, 9 Jul 2022 05:53:16 +0000 Subject: CFV: New OpenJFX Committer: Marius Hanl In-Reply-To: <9409a586-5d92-5eba-3b83-d02f00c5520a@oracle.com> References: <9409a586-5d92-5eba-3b83-d02f00c5520a@oracle.com> Message-ID: <86742A10-2BDA-48B7-8EE5-A448C1BC16AA@oracle.com> Vote : YES Regards, Ajit > On 08-Jul-2022, at 5:42 PM, Kevin Rushforth wrote: > > I hereby nominate Marius Hanl [1] to OpenJFX Committer. > > Marius is an OpenJFX community member, who has contributed 22 commits [2] to OpenJFX. > > Votes are due by July 22, 2022 at 13:00 UTC. > > 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 [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#mhanl > > [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Marius+Hanl%22&s=author-date&type=commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > From bourges.laurent at gmail.com Sat Jul 9 10:33:41 2022 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sat, 9 Jul 2022 12:33:41 +0200 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_OpenJFX_Committer=3A_Michael_Strau=C3=9F?= In-Reply-To: <6D906AFF-0BCA-4F89-BC12-D867B40168D6@oracle.com> References: <24c276e4-8aaf-c054-ecdf-ad6b263d1009@oracle.com> <6D906AFF-0BCA-4F89-BC12-D867B40168D6@oracle.com> Message-ID: Vote: YES Congratulations, michael ! Le sam. 9 juil. 2022, 07:53, Ajit Ghaisas a ?crit : > Vote : YES > > Regards, > Ajit > > > On 08-Jul-2022, at 6:01 PM, Kevin Rushforth > wrote: > > > > I hereby nominate Michael Strau? [1] to OpenJFX Committer. > > > > Michael is an OpenJFX community member, who has contributed 16 commits > [2] to OpenJFX. > > > > Votes are due by July 22, 2022 at 13:00 UTC. > > > > 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 [6]. > > > > Thanks. > > > > -- Kevin > > > > > > [1] https://openjdk.org/census#mstrauss > > > > [2] > > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Michael+Strau%C3%9F%22&s=author-date&type=commits > > > https://github.com/openjdk/jfx/search?q=author-name%3A%22mstr2%22&type=commits > > > > [3] https://openjdk.org/census#openjfx > > > > [4] https://openjdk.org/bylaws#lazy-consensus > > > > [6] https://openjdk.org/projects#project-committer > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fastegal at swingempire.de Sat Jul 9 10:34:54 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Sat, 09 Jul 2022 12:34:54 +0200 Subject: CFV: New OpenJFX Committer: Michael =?utf-8?b?U3RyYXXDnw==?= In-Reply-To: <24c276e4-8aaf-c054-ecdf-ad6b263d1009@oracle.com> Message-ID: <20220709123454.Horde.m4FHYSEItFViXVy04CF_tHW@webmail.df.eu> Vote: YES -- Jeanette Zitat von Kevin Rushforth : > I hereby nominate Michael Strau? [1] to OpenJFX Committer. > > Michael is an OpenJFX community member, who has contributed 16 > commits [2] to OpenJFX. > > Votes are due by July 22, 2022 at 13:00 UTC. > > 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 [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#mstrauss > > [2] > https://github.com/openjdk/jfx/search?q=author-name%3A%22Michael+Strau%C3%9F%22&s=author-date&type=commits > https://github.com/openjdk/jfx/search?q=author-name%3A%22mstr2%22&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [6] https://openjdk.org/projects#project-committer From fastegal at swingempire.de Sat Jul 9 10:35:33 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Sat, 09 Jul 2022 12:35:33 +0200 Subject: CFV: New OpenJFX Committer: Marius Hanl In-Reply-To: <9409a586-5d92-5eba-3b83-d02f00c5520a@oracle.com> Message-ID: <20220709123533.Horde.TRsazupcEYOSI4ReSowlIfa@webmail.df.eu> Vote: YES -- Jeanette Zitat von Kevin Rushforth : > I hereby nominate Marius Hanl [1] to OpenJFX Committer. > > Marius is an OpenJFX community member, who has contributed 22 > commits [2] to OpenJFX. > > Votes are due by July 22, 2022 at 13:00 UTC. > > 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 [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#mhanl > > [2] > https://github.com/openjdk/jfx/search?q=author-name%3A%22Marius+Hanl%22&s=author-date&type=commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer From john.hendrikx at gmail.com Sat Jul 9 11:02:26 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 9 Jul 2022 13:02:26 +0200 Subject: Listeners behavior discussion Message-ID: <94890151-3f47-ef4e-c5f6-536af8378147@gmail.com> Hi all, I'm looking into ExpressionHelper as part of my evaluation of adding Cleaner's to clean up weak listeners stubs a bit more eagerly. I would like to hear your thoughts on the following: ExpressionHelper has a locking mechanism so that when an event occurs, it is fired to the listeners which were active at the moment the event was triggered. This is achieved by making a copy of the listeners *if* the list is modified while an event emission is in progress. This uses a simple boolean for the lock ("locked"). It is however conceivable (although perhaps not good practice) to change the value again while the event emission is occurring. An easy example I can think of is that when a text field is modified, a ChangeListener may change the value to uppercase if the field should only contain uppercase characters.? This will trigger a nested event emission for the same property.? JavaFX does not prohibit this (and probably can't anymore for backwards compatibility reasons).? There are several problems with this: 1) The locking mechanism does not take nesting into account, therefore when the 2nd nested emission completes, the listener lists are unlocked, and the first event emission will continue with the lists unlocked. If there is any modification after the 2nd emission completes, listeners may be skipped, notified twice or an IndexOutOfBoundsException may occur. 2) The events received by the listeners are inconsistent depending on where you are in relation to the listener that made the nested change.? Let's say there are three listeners, A, B and C in that order.? Listener B will change any uneven number to the next higher even number.? The events seen by the three listeners when the value changes from 2 to 3 are: A: 2 -> 3; 3 -> 4 B: 2 -> 3; 3 -> 4 C: 3 -> 4; 2 -> 4 IMHO, we should strive to have the exact same events for all three listeners: 2 -> 3; 3 -> 4 or prohibit this with an exception. I think it is possible to change this so all listeners receive the exact same events; this would be achieved by delaying the 2nd event emission until the first has finished. I think the specification for how invalidation/change listener event notification works should perhaps be documented somewhere. I think it should be: When an event occurs, the currently list of registered listeners will receive this event in the order they were registered, regardless of whether the list is modified during the event emission. If during emission, another event occurs for the same property, it will be queued and emitted immediately after the current emission completes. This ensures all registered listeners receive the same events irrespective of registration order.? Event emission is serialized, that is to say, no two emissions for the same property will ever run concurrently. ===== Implementation ideas If we can all agree on the above specification, I think an implementation can be created that never needs to copy a listener list.? The main trick to get this correct is in how events are emitted. First, when a nested emission occurs (easily detected by the fact that the list is locked), the change for the nested emission is buffered.? The nested emission is then triggered as soon as the first finishes (when the first emission is about to unlock, it checks for a nested emission, and does another emission if one is present, and so on).? If there are multiple emissions after an emission finishes, they probably can and should be rolled into a single one.? Note that nested emissions can easily go wrong (two listeners that change values in conflicting ways) and cause an infinite loop -- we're not looking to prevent these kinds of bugs here, although we could set a limit before "giving up". Secondly, while the lists are locked, any additions or removals to the list should be buffered. Just before the list is unlocked (and before a second emission occurs), all changes are applied. This has the additional bonus that any mass changes to the listener list (for example when a large number of stubs were determined to require clean up) can use mass change functions like #removeAll and #addAll, potentially saving a lot of copying of the listener list, on top of the copy that is already avoided due to the lock. The fireValueChangedEvent method should be synchronized, so only the same thread could potentially trigger a nested emission.? I think we should steer clear from allowing multiple threads to emit events for the same property concurrently as this will make the events received unpredictable and probably even incorrect (the last change received may not reflect the actual current value!). Thanks for reading, I look forward to hearing your thoughts! --John From kcr at openjdk.org Sat Jul 9 12:08:42 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 9 Jul 2022 12:08:42 GMT Subject: RFR: 8288137: The set of available printers is not updated without application restart [v4] In-Reply-To: <0rXLXNASeWJqc2xtUMu2faY4lqmCUXraCDxg-fdewXw=.34b11ffc-4388-4386-8f16-41c5ff81b37e@github.com> References: <0rXLXNASeWJqc2xtUMu2faY4lqmCUXraCDxg-fdewXw=.34b11ffc-4388-4386-8f16-41c5ff81b37e@github.com> Message-ID: On Fri, 8 Jul 2022 22:27:41 GMT, Phil Race wrote: >> This fixes the issue that the default printer or set of available printers is fixed from the first call to it in the lifetime of the application. >> Now subsequent calls will check to see if there are changes. >> A manual test is provided for verifying this - it requires you to add/remove printers at the system level to verify anything related to this fix. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8288137 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/817 From kcr at openjdk.org Sat Jul 9 12:23:55 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 9 Jul 2022 12:23:55 GMT Subject: RFR: 8289389: Fix warnings: type should also implement hashCode() since it overrides Object.equals() [v2] In-Reply-To: <6XudVuXK7LMoL4WOJx0fwAS6sDGFBtKB1DvZ8QVsfo0=.50f76f4a-57c1-46d0-b946-7127ff296818@github.com> References: <0fTAATcre_hBsBKlRtFkFOqehJE4YZvgm0D4Q2rKJK8=.03babaf5-5f65-4b49-a0da-da4e30ef2a31@github.com> <6XudVuXK7LMoL4WOJx0fwAS6sDGFBtKB1DvZ8QVsfo0=.50f76f4a-57c1-46d0-b946-7127ff296818@github.com> Message-ID: On Sat, 9 Jul 2022 01:28:20 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/CalculatedValue.java line 101: >> >>> 99: } >>> 100: return h; >>> 101: } >> >> Just an example, but wouldn't: `Objects.hash(relative, origin, value)` here work just as well? > > Honestly, I would just turn this class into a `record` and everything will be taken care of. I'm not sure it is within the scope of the fix. Such a change is definitely out of scope. More importantly, we can't use `record` anywhere in JavaFX until we bump the minimum version of the JDK needed to run JavaFX. I plan to start a discussion on the openjfx-dev mailing list, since it has been something I've wanted to do for a while now. ------------- PR: https://git.openjdk.org/jfx/pull/821 From jvos at openjdk.org Sat Jul 9 19:09:52 2022 From: jvos at openjdk.org (Johan Vos) Date: Sat, 9 Jul 2022 19:09:52 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux [v4] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 12:30:08 GMT, Kevin Rushforth wrote: >> This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK 19 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). >> >> 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 four commits: > > - Merge remote-tracking branch 'origin/master' into 8283402-gcc-11.2 > - Merge branch 'master' into 8283402-gcc-11.2 > - Merge branch 'master' into 8283402-gcc-11.2 > - 8283402: Update to gcc 11.2 on Linux I confirm this works with a GCC 11.2 built from source (on an Ubuntu 22.0.4 system). ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.org/jfx/pull/761 From michaelstrau2 at gmail.com Sun Jul 10 05:33:32 2022 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sun, 10 Jul 2022 07:33:32 +0200 Subject: Listeners behavior discussion In-Reply-To: <94890151-3f47-ef4e-c5f6-536af8378147@gmail.com> References: <94890151-3f47-ef4e-c5f6-536af8378147@gmail.com> Message-ID: >From what I understand, you are essentially suggesting to solve an existing bug in ExpressionHelper, where inconsistent change notifications can be produced when a listener modifies its ObservableValue. At first, it seems like a good idea to defer a nested change notification until after all listeners have been invoked for the current change. But upon closer inspection, even with the proposed fix, there are more problems: Let's consider three listeners A, B, and C that are invoked in this order. If B changes the value, then C would seem to receive a correct change notification. However, if C tried to get() the value, it would not see the value that's reported in the change notification, but the value that B set. That's not good. We might be tempted to just add a similar deferred update mechanism to the value itself, so that C can still get() the old value even after B already set a new value. But that would create another problem: if the value is only applied after all listeners have run, B could observe that get() == "foo", then call set("bar"), and after that be astonished to learn that get() == "foo" (because the value is not yet applied). I don't think there is a way to support nested value changes, deliver the same events to all listeners, and be consistent at the same time. Something has to give. The easiest option, quite obviously, is to disallow nested value changes entirely. Another option may be the following algorithm: 1. When B changes the value, the scheduled change notification for C is updated to reflect the new value (but it still needs to retain the old value from the perspective of C). 2. After A, B and C have run, C is already up to date with the newest value. In the deferred phase, only A and B receive additional change notifications for the new value. This prevents basic inconsistencies with regards to the value being observed, but may introduce higher-order inconsistencies where different listeners for the same value can observe different change histories. As for your proposed specification: ExpressionHelper is an implementation detail and not public API. As far as I know, we don't specify the invocation order of listeners, and I see no compelling reason why we should. Listeners should not depend on their order of invocation with respect to other listeners. Of course, users can currently depend on that (because it's implemented as such), but we probably shouldn't invite them to write even more of such code. Similarly, I see no compelling reason to include language about concurrency in ObservableValue's specification. ObservableValue doesn't have any thread-safety guarantee at all; any attempt to use it from multiple threads should be assumed to potentially result in corrupted state. On Sat, Jul 9, 2022 at 1:02 PM John Hendrikx wrote: > > Hi all, > > I'm looking into ExpressionHelper as part of my evaluation of adding > Cleaner's to clean up weak listeners stubs a bit more eagerly. > > I would like to hear your thoughts on the following: > > ExpressionHelper has a locking mechanism so that when an event occurs, > it is fired to the listeners which were active at the moment the event > was triggered. This is achieved by making a copy of the listeners *if* > the list is modified while an event emission is in progress. This uses a > simple boolean for the lock ("locked"). > > It is however conceivable (although perhaps not good practice) to change > the value again while the event emission is occurring. An easy example I > can think of is that when a text field is modified, a ChangeListener may > change the value to uppercase if the field should only contain uppercase > characters. This will trigger a nested event emission for the same > property. JavaFX does not prohibit this (and probably can't anymore for > backwards compatibility reasons). There are several problems with this: > > 1) The locking mechanism does not take nesting into account, therefore > when the 2nd nested emission completes, the listener lists are unlocked, > and the first event emission will continue with the lists unlocked. If > there is any modification after the 2nd emission completes, listeners > may be skipped, notified twice or an IndexOutOfBoundsException may occur. > > 2) The events received by the listeners are inconsistent depending on > where you are in relation to the listener that made the nested change. > Let's say there are three listeners, A, B and C in that order. Listener > B will change any uneven number to the next higher even number. The > events seen by the three listeners when the value changes from 2 to 3 are: > > A: 2 -> 3; 3 -> 4 > B: 2 -> 3; 3 -> 4 > C: 3 -> 4; 2 -> 4 > > IMHO, we should strive to have the exact same events for all three > listeners: 2 -> 3; 3 -> 4 or prohibit this with an exception. > > I think it is possible to change this so all listeners receive the exact > same events; this would be achieved by delaying the 2nd event emission > until the first has finished. > > I think the specification for how invalidation/change listener event > notification works should perhaps be documented somewhere. I think it > should be: > > When an event occurs, the currently list of registered listeners will > receive this event in the order they were registered, regardless of > whether the list is modified during the event emission. If during > emission, another event occurs for the same property, it will be queued > and emitted immediately after the current emission completes. This > ensures all registered listeners receive the same events irrespective of > registration order. Event emission is serialized, that is to say, no > two emissions for the same property will ever run concurrently. > > ===== > > Implementation ideas > > If we can all agree on the above specification, I think an > implementation can be created that never needs to copy a listener list. > The main trick to get this correct is in how events are emitted. First, > when a nested emission occurs (easily detected by the fact that the list > is locked), the change for the nested emission is buffered. The nested > emission is then triggered as soon as the first finishes (when the first > emission is about to unlock, it checks for a nested emission, and does > another emission if one is present, and so on). If there are multiple > emissions after an emission finishes, they probably can and should be > rolled into a single one. Note that nested emissions can easily go > wrong (two listeners that change values in conflicting ways) and cause > an infinite loop -- we're not looking to prevent these kinds of bugs > here, although we could set a limit before "giving up". > > Secondly, while the lists are locked, any additions or removals to the > list should be buffered. Just before the list is unlocked (and before a > second emission occurs), all changes are applied. This has the > additional bonus that any mass changes to the listener list (for example > when a large number of stubs were determined to require clean up) can > use mass change functions like #removeAll and #addAll, potentially > saving a lot of copying of the listener list, on top of the copy that is > already avoided due to the lock. > > The fireValueChangedEvent method should be synchronized, so only the > same thread could potentially trigger a nested emission. I think we > should steer clear from allowing multiple threads to emit events for the > same property concurrently as this will make the events received > unpredictable and probably even incorrect (the last change received may > not reflect the actual current value!). > > Thanks for reading, I look forward to hearing your thoughts! > > --John > > From john.hendrikx at gmail.com Sun Jul 10 13:06:41 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sun, 10 Jul 2022 15:06:41 +0200 Subject: Listeners behavior discussion In-Reply-To: References: <94890151-3f47-ef4e-c5f6-536af8378147@gmail.com> Message-ID: <7931ad4c-f95c-e61a-2c40-1d1228103813@gmail.com> Hey, thanks for commenting, I have added my comments inline. > From what I understand, you are essentially suggesting to solve an > existing bug in ExpressionHelper, where inconsistent change > notifications can be produced when a listener modifies its > ObservableValue. Well, and the fact that it will prematurely release the lock when a nested emission finishes (and there is another bug in there which I didn't mention in my previous post, while the lock is held, each change of the listener list as part of the same emission triggers another unnecessary copy). > At first, it seems like a good idea to defer a nested change > notification until after all listeners have been invoked for the > current change. But upon closer inspection, even with the proposed > fix, there are more problems: > Let's consider three listeners A, B, and C that are invoked in this > order. If B changes the value, then C would seem to receive a correct > change notification. However, if C tried to get() the value, it would > not see the value that's reported in the change notification, but the > value that B set. That's not good. I think relying on #get when you're using a ChangeListener is a bit odd (since we're allowing threading, #get could report anything anyway). For an InvalidationListener it wouldn't matter, since it's allowed to get 2 invalidations where nothing changed. What I think is not good is that the ChangeListener is receiving events that never happened, happened in a different order or events where the current value didn't actually change. This is not documented anywhere: "the old value can be incorrect, don't rely on it" or "the change the event reports may never have actually happened" or "you may receive two changes with no change in the current value reported".? All I would like to see is to formalize this somewhat, so we know what the implementation *should* be doing, instead of having to guess at what is a bug and what is intended. Also, I'm like 99% sure nested changes are already happening inside JavaFX code itself, for example, during layout.? The more complicated layouts can take a few passes to "settle", and even though there may not be a direct change of the same property, it can also be triggered by changing another property which in turn changes the original property, all occurring during the first emission still of the original property. I can do an experiment where I disallow this (by throwing an exception if the list is already locked), but I'm pretty sure that tests are going to fail. > We might be tempted to just add a similar deferred update mechanism to > the value itself, so that C can still get() the old value even after B > already set a new value. But that would create another problem: if the > value is only applied after all listeners have run, B could observe > that get() == "foo", then call set("bar"), and after that be > astonished to learn that get() == "foo" (because the value is not yet > applied). Agreed, I don't think this would work at all, especially not for invalidation listeners. > I don't think there is a way to support nested value changes, deliver > the same events to all listeners, and be consistent at the same time. > Something has to give. The easiest option, quite obviously, is to > disallow nested value changes entirely. I think what I described still stands -- it's not an uncommon problem in event listening frameworks. The only argument against it at the moment is that a direct #get could report something that is not the same as the current value, which I think is not really a concern. You want to act on the *change*, a historical event that should reflect what actually happened so you can look at the old value and the new value and perhaps even derive something from those two (like the difference).? A ChangeListener might even have logic to ignore the current change if it notices that #get reports something different as another change will follow soon after (guaranteed by the framework). > Another option may be the following algorithm: > 1. When B changes the value, the scheduled change notification for C > is updated to reflect the new value (but it still needs to retain the > old value from the perspective of C). > 2. After A, B and C have run, C is already up to date with the newest > value. In the deferred phase, only A and B receive additional change > notifications for the new value. It's not a bad idea, but I think it would be even harder to implement. The problem here is that the listener list can also be modified during emission, and so it would be very hard to track which listeners were notified already, which weren't notified yet, etc. It also removes some of the guarantees that a listener should receive all change events as they occurred (if we want to guarantee that). Basically, the order of listeners becomes a serious influence here, something that I think should be avoided. I mean, we are making an effort to notify all *original* listeners that were part of the list, but then are not concerned with giving all of them the same event information? > As for your proposed specification: ExpressionHelper is an > implementation detail and not public API. As far as I know, we don't > specify the invocation order of listeners, and I see no compelling > reason why we should. Listeners should not depend on their order of > invocation with respect to other listeners. Of course, users can > currently depend on that (because it's implemented as such), but we > probably shouldn't invite them to write even more of such code. I may not have been clear, I'm not proposing to make ExpressionHelper public.? However, since it is used in the majority of our listener registration and notification system, and there is no formal specification as to how listeners should work in the face of concurrent changes, nested changes and listener add/removal, the only place to find what the system is currently doing is in ExpressionHelper. Unfortunately, what ExpressionHelper is currently doing would not make for a very good specification that users can rely and build complicated logic on. Primitives which are hard to predict or are just plain misrepresenting events are not a solid foundation to build upon. I know that currently we don't specific invocation order, but this is another thing that probably would break JavaFX if changed. It is sort of implied though; adding duplicate listeners is allowed, which will be notified twice, and the docs mention that removal would remove the first instance, implying there is somekind of ordering going on. The docs could have stated that duplicates would only be notified once and that removal would remove all matches, but it doesn't. I'll see what happens when I swap out ExpressionHelper for one that ignores order and disallowes nested changes (one at a time) :) > Similarly, I see no compelling reason to include language about > concurrency in ObservableValue's specification. ObservableValue > doesn't have any thread-safety guarantee at all; any attempt to use it > from multiple threads should be assumed to potentially result in > corrupted state. I'm not that concerned with this part, although in light of perhaps having background cleaning of listener stubs, it could be worthwhile to just specify it. If JavaFX itself has a need to do background listener removal, then so could users. All it requires is synchronization per property while events are emitted. --John From michaelstrau2 at gmail.com Sun Jul 10 13:54:40 2022 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sun, 10 Jul 2022 15:54:40 +0200 Subject: Listeners behavior discussion In-Reply-To: <7931ad4c-f95c-e61a-2c40-1d1228103813@gmail.com> References: <94890151-3f47-ef4e-c5f6-536af8378147@gmail.com> <7931ad4c-f95c-e61a-2c40-1d1228103813@gmail.com> Message-ID: Your explanation for why it's okay for a ChangeListener to get() a different value than the reported new value is quite convincing. We'd only need to clearly document that a change event should only ever be interpreted as a historical fact, not a description of current reality. Of course, there are surely many cases where a ChangeListener directly or indirectly acts on the current state of the world, erroneously assuming that historical fact == current reality. Can you think of scenarios where this would constitute a bug, and if so, should we have our property implementations have a flag to choose whether nested changes are allowed? On the other hand, considering that writing code that recursively changes a value is very suspicious in almost all cases, maybe disallowing it entirely and having something like a "setLater" mechanism to break a cycle would be a solution that doesn't invite strange bugs. In this case, change notifications would always correspond exactly to the current state of the world. I have more thoughts on your implementation ideas, but it's probably best to hold back that discussion until there's agreement on the core concepts. On Sun, Jul 10, 2022 at 3:06 PM John Hendrikx wrote: > > Hey, thanks for commenting, I have added my comments inline. > > > From what I understand, you are essentially suggesting to solve an > > existing bug in ExpressionHelper, where inconsistent change > > notifications can be produced when a listener modifies its > > ObservableValue. > Well, and the fact that it will prematurely release the lock when a > nested emission finishes (and there is another bug in there which I > didn't mention in my previous post, while the lock is held, each change > of the listener list as part of the same emission triggers another > unnecessary copy). > > At first, it seems like a good idea to defer a nested change > > notification until after all listeners have been invoked for the > > current change. But upon closer inspection, even with the proposed > > fix, there are more problems: > > Let's consider three listeners A, B, and C that are invoked in this > > order. If B changes the value, then C would seem to receive a correct > > change notification. However, if C tried to get() the value, it would > > not see the value that's reported in the change notification, but the > > value that B set. That's not good. > > I think relying on #get when you're using a ChangeListener is a bit odd > (since we're allowing threading, #get could report anything anyway). For > an InvalidationListener it wouldn't matter, since it's allowed to get 2 > invalidations where nothing changed. What I think is not good is that > the ChangeListener is receiving events that never happened, happened in > a different order or events where the current value didn't actually > change. This is not documented anywhere: "the old value can be > incorrect, don't rely on it" or "the change the event reports may never > have actually happened" or "you may receive two changes with no change > in the current value reported". All I would like to see is to formalize > this somewhat, so we know what the implementation *should* be doing, > instead of having to guess at what is a bug and what is intended. > > Also, I'm like 99% sure nested changes are already happening inside > JavaFX code itself, for example, during layout. The more complicated > layouts can take a few passes to "settle", and even though there may not > be a direct change of the same property, it can also be triggered by > changing another property which in turn changes the original property, > all occurring during the first emission still of the original property. > > I can do an experiment where I disallow this (by throwing an exception > if the list is already locked), but I'm pretty sure that tests are going > to fail. > > > We might be tempted to just add a similar deferred update mechanism to > > the value itself, so that C can still get() the old value even after B > > already set a new value. But that would create another problem: if the > > value is only applied after all listeners have run, B could observe > > that get() == "foo", then call set("bar"), and after that be > > astonished to learn that get() == "foo" (because the value is not yet > > applied). > Agreed, I don't think this would work at all, especially not for > invalidation listeners. > > I don't think there is a way to support nested value changes, deliver > > the same events to all listeners, and be consistent at the same time. > > Something has to give. The easiest option, quite obviously, is to > > disallow nested value changes entirely. > > I think what I described still stands -- it's not an uncommon problem in > event listening frameworks. The only argument against it at the moment > is that a direct #get could report something that is not the same as the > current value, which I think is not really a concern. You want to act on > the *change*, a historical event that should reflect what actually > happened so you can look at the old value and the new value and perhaps > even derive something from those two (like the difference). A > ChangeListener might even have logic to ignore the current change if it > notices that #get reports something different as another change will > follow soon after (guaranteed by the framework). > > > Another option may be the following algorithm: > > 1. When B changes the value, the scheduled change notification for C > > is updated to reflect the new value (but it still needs to retain the > > old value from the perspective of C). > > 2. After A, B and C have run, C is already up to date with the newest > > value. In the deferred phase, only A and B receive additional change > > notifications for the new value. > > It's not a bad idea, but I think it would be even harder to implement. > The problem here is that the listener list can also be modified during > emission, and so it would be very hard to track which listeners were > notified already, which weren't notified yet, etc. > > It also removes some of the guarantees that a listener should receive > all change events as they occurred (if we want to guarantee that). > Basically, the order of listeners becomes a serious influence here, > something that I think should be avoided. I mean, we are making an > effort to notify all *original* listeners that were part of the list, > but then are not concerned with giving all of them the same event > information? > > > As for your proposed specification: ExpressionHelper is an > > implementation detail and not public API. As far as I know, we don't > > specify the invocation order of listeners, and I see no compelling > > reason why we should. Listeners should not depend on their order of > > invocation with respect to other listeners. Of course, users can > > currently depend on that (because it's implemented as such), but we > > probably shouldn't invite them to write even more of such code. > > I may not have been clear, I'm not proposing to make ExpressionHelper > public. However, since it is used in the majority of our listener > registration and notification system, and there is no formal > specification as to how listeners should work in the face of concurrent > changes, nested changes and listener add/removal, the only place to find > what the system is currently doing is in ExpressionHelper. > Unfortunately, what ExpressionHelper is currently doing would not make > for a very good specification that users can rely and build complicated > logic on. Primitives which are hard to predict or are just plain > misrepresenting events are not a solid foundation to build upon. > > I know that currently we don't specific invocation order, but this is > another thing that probably would break JavaFX if changed. It is sort of > implied though; adding duplicate listeners is allowed, which will be > notified twice, and the docs mention that removal would remove the first > instance, implying there is somekind of ordering going on. The docs > could have stated that duplicates would only be notified once and that > removal would remove all matches, but it doesn't. > > I'll see what happens when I swap out ExpressionHelper for one that > ignores order and disallowes nested changes (one at a time) :) > > > Similarly, I see no compelling reason to include language about > > concurrency in ObservableValue's specification. ObservableValue > > doesn't have any thread-safety guarantee at all; any attempt to use it > > from multiple threads should be assumed to potentially result in > > corrupted state. > > I'm not that concerned with this part, although in light of perhaps > having background cleaning of listener stubs, it could be worthwhile to > just specify it. If JavaFX itself has a need to do background listener > removal, then so could users. All it requires is synchronization per > property while events are emitted. > > --John > From nlisker at gmail.com Sun Jul 10 18:11:38 2022 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 10 Jul 2022 21:11:38 +0300 Subject: Listeners behavior discussion In-Reply-To: References: <94890151-3f47-ef4e-c5f6-536af8378147@gmail.com> <7931ad4c-f95c-e61a-2c40-1d1228103813@gmail.com> Message-ID: There was a previous implementation discussion that touched on some of the points here in https://github.com/openjdk/jfx/pull/108 I think there are a few (semi-)independent points here: 1. Order of listeners: as John said, there is no specification of the order of listeners, but the add/removeListener methods imply that there is some sort of order by saying that the "first occurrence" will be removed. 2. Dispatch order: the docs don't specify (from what I could find) the order in which listeners receive events. That is, if listener1 and listener2 are registered in that order, I didn't find anything that specifies that they will be notified in this order, although It makes sense that they are. From the API perspective, there is no `getListeners()` method or the like that allows me to see the order, so I have to "remember" that order somehow, and that's an indication that the order is actually not important. Furthermore, the order is separate for invalidation listeners and change listeners: first all invalidation listeners are notified, then all change listeners, even if all the change listeners were registered before. This alone can be surprising. 3. Concurrent modification of listeners: if a listener is added or removed from another thread (while an event is being sent through the listener list or otherwise), what should happen. 4. Nested events (relevant only for change listeners I think): if a value is changed inside a listener, what should happen. The docs in ChangeListener#changed mention that it is "bad practice", but don't prohibit it. I have some thoughts, but I haven't constructed an opinion yet: 1+2. It should be tested how much practical maneuvering room we have here first. If we don't keep an ordered collection of listeners, or don't dispatch the event to them in that order, or even if we dispatch first to all change listeners and then to all invalidation listeners, what breaks? This will give us an idea of our options. 3. I agree with Michael that as long as there is no mention of thread safety in any of the relevant classes (observables and listeners), the behavior should be unspecified, exactly as it is in core JDK classes that don't specify anything. We can revisit this when the GC part of the story is on the move, as John said. 4. I don't think we can restrict nested changes at this point considering the docs, and I remember some classes in JavaFX doing this (I think it was in the animation package). However, I propose to look at another approach: The event dispatcher will use an iterator, and whatever changes happen during iteration will reflect on it (if they are relevant). It is not guaranteed that all listeners that were registered *at the time of the event* will receive it, but only those that are registered in time for a dispatch. It removes the hurdles of locking or maintaining a queue. Also, if I have a listener1 whose job is to remove a listener2 when an event is received, it's very probable that I don't want listener2 to react to the event (unless it wasn't registered before listener1, in which case "too late", but see also points 1+2). If this approach is viable, it should also be tested practically. On Sun, Jul 10, 2022 at 4:55 PM Michael Strau? wrote: > Your explanation for why it's okay for a ChangeListener to get() a > different value than the reported new value is quite convincing. We'd > only need to clearly document that a change event should only ever be > interpreted as a historical fact, not a description of current > reality. > > Of course, there are surely many cases where a ChangeListener directly > or indirectly acts on the current state of the world, erroneously > assuming that historical fact == current reality. Can you think of > scenarios where this would constitute a bug, and if so, should we have > our property implementations have a flag to choose whether nested > changes are allowed? > > On the other hand, considering that writing code that recursively > changes a value is very suspicious in almost all cases, maybe > disallowing it entirely and having something like a "setLater" > mechanism to break a cycle would be a solution that doesn't invite > strange bugs. In this case, change notifications would always > correspond exactly to the current state of the world. > > I have more thoughts on your implementation ideas, but it's probably > best to hold back that discussion until there's agreement on the core > concepts. > > On Sun, Jul 10, 2022 at 3:06 PM John Hendrikx > wrote: > > > > Hey, thanks for commenting, I have added my comments inline. > > > > > From what I understand, you are essentially suggesting to solve an > > > existing bug in ExpressionHelper, where inconsistent change > > > notifications can be produced when a listener modifies its > > > ObservableValue. > > Well, and the fact that it will prematurely release the lock when a > > nested emission finishes (and there is another bug in there which I > > didn't mention in my previous post, while the lock is held, each change > > of the listener list as part of the same emission triggers another > > unnecessary copy). > > > At first, it seems like a good idea to defer a nested change > > > notification until after all listeners have been invoked for the > > > current change. But upon closer inspection, even with the proposed > > > fix, there are more problems: > > > Let's consider three listeners A, B, and C that are invoked in this > > > order. If B changes the value, then C would seem to receive a correct > > > change notification. However, if C tried to get() the value, it would > > > not see the value that's reported in the change notification, but the > > > value that B set. That's not good. > > > > I think relying on #get when you're using a ChangeListener is a bit odd > > (since we're allowing threading, #get could report anything anyway). For > > an InvalidationListener it wouldn't matter, since it's allowed to get 2 > > invalidations where nothing changed. What I think is not good is that > > the ChangeListener is receiving events that never happened, happened in > > a different order or events where the current value didn't actually > > change. This is not documented anywhere: "the old value can be > > incorrect, don't rely on it" or "the change the event reports may never > > have actually happened" or "you may receive two changes with no change > > in the current value reported". All I would like to see is to formalize > > this somewhat, so we know what the implementation *should* be doing, > > instead of having to guess at what is a bug and what is intended. > > > > Also, I'm like 99% sure nested changes are already happening inside > > JavaFX code itself, for example, during layout. The more complicated > > layouts can take a few passes to "settle", and even though there may not > > be a direct change of the same property, it can also be triggered by > > changing another property which in turn changes the original property, > > all occurring during the first emission still of the original property. > > > > I can do an experiment where I disallow this (by throwing an exception > > if the list is already locked), but I'm pretty sure that tests are going > > to fail. > > > > > We might be tempted to just add a similar deferred update mechanism to > > > the value itself, so that C can still get() the old value even after B > > > already set a new value. But that would create another problem: if the > > > value is only applied after all listeners have run, B could observe > > > that get() == "foo", then call set("bar"), and after that be > > > astonished to learn that get() == "foo" (because the value is not yet > > > applied). > > Agreed, I don't think this would work at all, especially not for > > invalidation listeners. > > > I don't think there is a way to support nested value changes, deliver > > > the same events to all listeners, and be consistent at the same time. > > > Something has to give. The easiest option, quite obviously, is to > > > disallow nested value changes entirely. > > > > I think what I described still stands -- it's not an uncommon problem in > > event listening frameworks. The only argument against it at the moment > > is that a direct #get could report something that is not the same as the > > current value, which I think is not really a concern. You want to act on > > the *change*, a historical event that should reflect what actually > > happened so you can look at the old value and the new value and perhaps > > even derive something from those two (like the difference). A > > ChangeListener might even have logic to ignore the current change if it > > notices that #get reports something different as another change will > > follow soon after (guaranteed by the framework). > > > > > Another option may be the following algorithm: > > > 1. When B changes the value, the scheduled change notification for C > > > is updated to reflect the new value (but it still needs to retain the > > > old value from the perspective of C). > > > 2. After A, B and C have run, C is already up to date with the newest > > > value. In the deferred phase, only A and B receive additional change > > > notifications for the new value. > > > > It's not a bad idea, but I think it would be even harder to implement. > > The problem here is that the listener list can also be modified during > > emission, and so it would be very hard to track which listeners were > > notified already, which weren't notified yet, etc. > > > > It also removes some of the guarantees that a listener should receive > > all change events as they occurred (if we want to guarantee that). > > Basically, the order of listeners becomes a serious influence here, > > something that I think should be avoided. I mean, we are making an > > effort to notify all *original* listeners that were part of the list, > > but then are not concerned with giving all of them the same event > > information? > > > > > As for your proposed specification: ExpressionHelper is an > > > implementation detail and not public API. As far as I know, we don't > > > specify the invocation order of listeners, and I see no compelling > > > reason why we should. Listeners should not depend on their order of > > > invocation with respect to other listeners. Of course, users can > > > currently depend on that (because it's implemented as such), but we > > > probably shouldn't invite them to write even more of such code. > > > > I may not have been clear, I'm not proposing to make ExpressionHelper > > public. However, since it is used in the majority of our listener > > registration and notification system, and there is no formal > > specification as to how listeners should work in the face of concurrent > > changes, nested changes and listener add/removal, the only place to find > > what the system is currently doing is in ExpressionHelper. > > Unfortunately, what ExpressionHelper is currently doing would not make > > for a very good specification that users can rely and build complicated > > logic on. Primitives which are hard to predict or are just plain > > misrepresenting events are not a solid foundation to build upon. > > > > I know that currently we don't specific invocation order, but this is > > another thing that probably would break JavaFX if changed. It is sort of > > implied though; adding duplicate listeners is allowed, which will be > > notified twice, and the docs mention that removal would remove the first > > instance, implying there is somekind of ordering going on. The docs > > could have stated that duplicates would only be notified once and that > > removal would remove all matches, but it doesn't. > > > > I'll see what happens when I swap out ExpressionHelper for one that > > ignores order and disallowes nested changes (one at a time) :) > > > > > Similarly, I see no compelling reason to include language about > > > concurrency in ObservableValue's specification. ObservableValue > > > doesn't have any thread-safety guarantee at all; any attempt to use it > > > from multiple threads should be assumed to potentially result in > > > corrupted state. > > > > I'm not that concerned with this part, although in light of perhaps > > having background cleaning of listener stubs, it could be worthwhile to > > just specify it. If JavaFX itself has a need to do background listener > > removal, then so could users. All it requires is synchronization per > > property while events are emitted. > > > > --John > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Sun Jul 10 19:43:52 2022 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 10 Jul 2022 22:43:52 +0300 Subject: JDK-8290038: Improve documentation for the referencing model of bindings and listeners in combination with GC Message-ID: Hi, Is it intended for this issue to go into 19? If so, we need to figure out the new memory management model quickly. If not, I take it that we are happy for now with the unspecified behaviors and specify them later. Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Sun Jul 10 20:06:50 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 10 Jul 2022 20:06:50 GMT Subject: RFR: 8289395: Fix warnings: Varargs methods should only override or be overridden by other varargs methods In-Reply-To: <-Qjxdv4Rvjm9fm0g9pMpinAhp4hZPNO4I5M8oRnemPo=.08c5af80-652e-45a9-8391-c16bc66ad2e5@github.com> References: <-Qjxdv4Rvjm9fm0g9pMpinAhp4hZPNO4I5M8oRnemPo=.08c5af80-652e-45a9-8391-c16bc66ad2e5@github.com> Message-ID: On Wed, 6 Jul 2022 18:52:08 GMT, Andy Goryachev wrote: > - fixed varargs Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/816 From john.hendrikx at gmail.com Mon Jul 11 06:09:09 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 11 Jul 2022 08:09:09 +0200 Subject: Listeners behavior discussion In-Reply-To: References: <94890151-3f47-ef4e-c5f6-536af8378147@gmail.com> <7931ad4c-f95c-e61a-2c40-1d1228103813@gmail.com> Message-ID: <4554113b-3ac4-8c08-3132-7f30e3082978@gmail.com> I've done some preliminary testing on the limits of what's possible. Disallowing nested changes broke about 50 tests. Changing the order of listener events broke 9 tests (I reversed the order, see this diff for what I did: https://github.com/hjohn/jfx/commit/c7588c49d42257f75627f15ca7ed01147d5e5e3d). I investigated the tests that broke when the ordering changed. They're all Tree/Table/ListView tests. The tests breaking all seem to interact with the selection and focus model, so there might be some kind of ordering dependency in there (list of the 9 tests that broke added at end of this post). Disallowing nested emissions broke far more, Spinner, ComboBox, ColorPicker, Scroll related things, TableCell.? I didn't run systemTests or web tests, so there might be even more that breaks. Further comments inline: On 10/07/2022 20:11, Nir Lisker wrote: > There was a previous implementation discussion that touched on some of > the points here in https://github.com/openjdk/jfx/pull/108 > > I think there are a few (semi-)independent points here: > 1. Order of listeners: as John said, there is no specification of the > order of listeners, but the add/removeListener methods imply that > there is some sort of order by saying that the "first occurrence" will > be removed. > 2. Dispatch order: the docs don't specify (from what I could find) the > order in which listeners receive events. That is, if listener1 and > listener2 are registered in that order, I didn't find anything that > specifies?that they will be notified in this order, although It makes > sense that they are. From the API perspective, there is no > `getListeners()` method or the like that allows me to see the > order,?so I have to "remember" that order somehow, and that's an > indication that the order is actually not important. > Furthermore, the order is separate for invalidation listeners and > change listeners: first all invalidation listeners are notified, then > all change listeners, even if all the change listeners were > registered?before. This alone can be surprising. > 3. Concurrent modification of listeners: if a listener is added or > removed from another thread (while an event is being sent through the > listener list or otherwise), what should happen. > 4. Nested events (relevant only for change listeners I think): if a > value is changed inside a listener, what should happen. The docs in > ChangeListener#changed mention that it is "bad practice", but don't > prohibit it. Thanks, good summary there. > I have some thoughts, but I haven't constructed an opinion yet: > 1+2. It should be tested how much practical maneuvering?room we have > here first. If we don't keep an ordered collection of listeners, or > don't dispatch the event to them in that order, or even if we dispatch > first to all change listeners and then to all invalidation listeners, > what breaks? This will give us an idea of our options. > 3. I agree with Michael that as long as there is no mention of thread > safety?in any of the relevant classes (observables and listeners), the > behavior should be unspecified, exactly as it is in core JDK classes > that don't specify anything. We can revisit this when the GC part of > the story is on the move, as John said. > 4. I don't think we can restrict nested changes at this point > considering the docs, and I remember some classes in JavaFX doing this > (I think it was in the animation package). However, I propose to look > at another approach: The event dispatcher will use an iterator, and > whatever changes happen during iteration will reflect on it (if they > are relevant). It is not guaranteed that all listeners that were > registered *at the time of the event* will receive it, but only those > that are registered in time for a dispatch. It removes the hurdles of > locking or maintaining a queue. Also, if I have a listener1 whose job > is to remove a listener2 when an event is received, it's very probable > that I don't want listener2 to react to the event (unless it wasn't > registered before listener1, in which case "too late", but see also > points 1+2). > If this approach is viable, it should also be tested practically. > As for the last point, I don't think we should change a current event emission. When an event occurs, I think every one that was registered should receive it (which is currently ensured by making a copy). Doing it differently (allowing the list to change during emission of a single event) would actually introduce ordering effects and would be a much harder behavior to document. As for it removing hurdles, I think a copy free approach is already possible *if* we specify that changes are historical (ie. everyone at the time of registration receives the exact same change event, regardless of nested value changes or nested listener list changes). If changes are historical, the implementation probably must delay nested value changes to adhere to the specification. If we further specify (or implement in this case) that for a single property, no more than a single emission can run concurrently (this seems reasonable IMHO, especially given the fact that concurrent emissions probably hardly happen currently as it would break too much things in unexpected ways), then the implementation can buffer any list modifications made. All the above taken together will allow a copy free use of listener list. A lock is still needed to detect a nested emission, when to buffer changes and to prevent emissions on another thread. --John ListViewTest > ensureSelectionIsCorrectWhenItemsChange FAILED ??? java.lang.AssertionError: expected:<0> but was:<-1> ??????? at org.junit.Assert.fail(Assert.java:89) ??????? at org.junit.Assert.failNotEquals(Assert.java:835) ??????? at org.junit.Assert.assertEquals(Assert.java:647) ??????? at org.junit.Assert.assertEquals(Assert.java:633) ??????? at test.javafx.scene.control.ListViewTest.ensureSelectionIsCorrectWhenItemsChange(ListViewTest.java:337) TableViewTest > ensureSelectionIsCorrectWhenItemsChange FAILED ??? java.lang.AssertionError: expected:<0> but was:<-1> ??????? at org.junit.Assert.fail(Assert.java:89) ??????? at org.junit.Assert.failNotEquals(Assert.java:835) ??????? at org.junit.Assert.assertEquals(Assert.java:647) ??????? at org.junit.Assert.assertEquals(Assert.java:633) ??????? at test.javafx.scene.control.TableViewTest.ensureSelectionIsCorrectWhenItemsChange(TableViewTest.java:351) TreeTableViewTest > test_rt27180_expandBranch_laterSiblingSelected_singleSelection FAILED ??? java.lang.AssertionError ??????? at org.junit.Assert.fail(Assert.java:87) ??????? at org.junit.Assert.assertTrue(Assert.java:42) ??????? at org.junit.Assert.assertTrue(Assert.java:53) ??????? at test.javafx.scene.control.TreeTableViewTest.test_rt27180_expandBranch_laterSiblingSelected_singleSelection(TreeTableViewTest.java:2315) TreeTableViewTest > test_rt27180_expandBranch_laterSiblingAndChildrenSelected FAILED ??? java.lang.AssertionError ??????? at org.junit.Assert.fail(Assert.java:87) ??????? at org.junit.Assert.assertTrue(Assert.java:42) ??????? at org.junit.Assert.assertTrue(Assert.java:53) ??????? at test.javafx.scene.control.TreeTableViewTest.test_rt27180_expandBranch_laterSiblingAndChildrenSelected(TreeTableViewTest.java:2340) TreeTableViewTest > test_rt27185 FAILED ??? java.lang.AssertionError: expected: but was: ??????? at org.junit.Assert.fail(Assert.java:89) ??????? at org.junit.Assert.failNotEquals(Assert.java:835) ??????? at org.junit.Assert.assertEquals(Assert.java:120) ??????? at org.junit.Assert.assertEquals(Assert.java:146) ??????? at test.javafx.scene.control.TreeTableViewTest.test_rt27185(TreeTableViewTest.java:1569) TreeViewTest > test_rt27180_expandBranch_laterSiblingSelected_singleSelection FAILED ??? java.lang.AssertionError ??????? at org.junit.Assert.fail(Assert.java:87) ??????? at org.junit.Assert.assertTrue(Assert.java:42) ??????? at org.junit.Assert.assertTrue(Assert.java:53) ??????? at test.javafx.scene.control.TreeViewTest.test_rt27180_expandBranch_laterSiblingSelected_singleSelection(TreeViewTest.java:1018) TreeViewTest > test_rt27180_collapseBranch_laterSiblingAndChildrenSelected FAILED ??? java.lang.AssertionError ??????? at org.junit.Assert.fail(Assert.java:87) ??????? at org.junit.Assert.assertTrue(Assert.java:42) ??????? at org.junit.Assert.assertTrue(Assert.java:53) ??????? at test.javafx.scene.control.TreeViewTest.test_rt27180_collapseBranch_laterSiblingAndChildrenSelected(TreeViewTest.java:999) TreeViewTest > test_rt27180_expandBranch_laterSiblingAndChildrenSelected FAILED ??? java.lang.AssertionError ??????? at org.junit.Assert.fail(Assert.java:87) ??????? at org.junit.Assert.assertTrue(Assert.java:42) ??????? at org.junit.Assert.assertTrue(Assert.java:53) ??????? at test.javafx.scene.control.TreeViewTest.test_rt27180_expandBranch_laterSiblingAndChildrenSelected(TreeViewTest.java:1043) TreeViewTest > test_rt27185 FAILED ??? java.lang.AssertionError: expected: but was: ??????? at org.junit.Assert.fail(Assert.java:89) ??????? at org.junit.Assert.failNotEquals(Assert.java:835) ??????? at org.junit.Assert.assertEquals(Assert.java:120) ??????? at org.junit.Assert.assertEquals(Assert.java:146) ??????? at test.javafx.scene.control.TreeViewTest.test_rt27185(TreeViewTest.java:630) From sykora at openjdk.org Mon Jul 11 07:07:50 2022 From: sykora at openjdk.org (Joeri Sykora) Date: Mon, 11 Jul 2022 07:07:50 GMT Subject: RFR: 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 23:16:12 GMT, Kevin Rushforth wrote: > On Windows platforms we redistribute the Visual Studio runtime libraries with the JavaFX build so that JavaFX applications can run on systems that don't have them installed already. The main C++ runtime library is `msvcp140.dll`, which we ship along with the other native libraries for JavaFX. Additional C++ functionality has been added to `msvcp140_1.dll` and `msvcp140_2.dll`, neither of which are shipped. > > Recently, WebKit has started using some standard C++ functions that are only found in `msvcp140_2.dll`. We need to include the two missing libraries as part of the JavaFX build (in addition to `msvcp140.dll`, which is already included). Marked as reviewed by sykora (Author). ------------- PR: https://git.openjdk.org/jfx/pull/818 From arapte at openjdk.org Mon Jul 11 07:20:32 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 11 Jul 2022 07:20:32 GMT Subject: RFR: 8289835: Change JavaFX release version to 20 In-Reply-To: References: Message-ID: <07AVYTdnhLSbD0fmmwS4WjRVv9IzbFdVawdl4orJSo8=.761aab19-5d07-42a3-a470-2f94add5cafe@github.com> On Fri, 8 Jul 2022 19:22:26 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 20. I will integrate this to `master` as part of forking the `jfx19` stabilization branch, which is scheduled for Thursday, July 14, 2022 at 16:00 UTC. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/820 From john.hendrikx at gmail.com Mon Jul 11 07:57:19 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 11 Jul 2022 09:57:19 +0200 Subject: Listeners behavior discussion In-Reply-To: <4554113b-3ac4-8c08-3132-7f30e3082978@gmail.com> References: <94890151-3f47-ef4e-c5f6-536af8378147@gmail.com> <7931ad4c-f95c-e61a-2c40-1d1228103813@gmail.com> <4554113b-3ac4-8c08-3132-7f30e3082978@gmail.com> Message-ID: I've done another test, where I delayed nested event emission (code here: https://github.com/hjohn/jfx/commit/fe63a4ee2284c0ed440c4521504a3c5db55f631d) No tests broke.? Basically, the change will queue up at most one nested event emission. It will use the historically correct old/new values for each emission. Even though nothing broke, I saw a rather curious practice in SpinnerValueFactory.? The value factory has an internal value property on which it places restrictions using a change listener which will cap the value to a minimum or maximum when its out of range. This value is in turn bound to a read only property Spinner#valueProperty. Depending on where you check the value of the spinner in user code, you get different results.? Assuming a spinner in the range of [0, 100] with a current value of 99, changing the value to 200 triggers the following events when observing Spinner#valueProperty: 99 -> 200 200 -> 100 When you observe Spinner#valueFactoryProperty#valueProperty you instead see: 200 -> 100 (send out by a nested emission) 99 -> 100 (send out when the top level emission finishes) When you apply my change, both these would be the same for both properties: 99 -> 200 200 -> 100 I think its odd in the first place these events are published. When I limit a spinner to a certain range, I'd never expect to see out of range values published. Instead I'd only expect: 99 -> 100 Still, I think the delayed version sends out more consistent events in this case. --John From fkirmaier at openjdk.org Mon Jul 11 08:00:41 2022 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Mon, 11 Jul 2022 08:00:41 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v5] In-Reply-To: References: Message-ID: > Making the initial listener of the ListProperty weak fixes the problem. > The same is fixed for Set and Map. > Due to a smart implementation, this is done without any performance drawback. > (The trick is to have an object, which is both the WeakReference and the Changelistener) > By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8277848 Added 3 more tests to verify that a bug discussed in the PR does not appear. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/689/files - new: https://git.openjdk.org/jfx/pull/689/files/acd470e1..5294483b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=689&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=689&range=03-04 Stats: 33 lines in 3 files changed: 33 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/689.diff Fetch: git fetch https://git.openjdk.org/jfx pull/689/head:pull/689 PR: https://git.openjdk.org/jfx/pull/689 From fkirmaier at openjdk.org Mon Jul 11 08:21:48 2022 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Mon, 11 Jul 2022 08:21:48 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v5] In-Reply-To: References: Message-ID: <8rqIEYtvwkemOrRi9cSv7h9ClYuuyb7kQx13e5H7FAw=.e6544596-e69c-4432-8223-fefeb9bc01b2@github.com> On Mon, 11 Jul 2022 08:00:41 GMT, Florian Kirmaier wrote: >> Making the initial listener of the ListProperty weak fixes the problem. >> The same is fixed for Set and Map. >> Due to a smart implementation, this is done without any performance drawback. >> (The trick is to have an object, which is both the WeakReference and the Changelistener) >> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8277848 > Added 3 more tests to verify that a bug discussed in the PR does not appear. **Discussed Property Leak** @mstr2 I've added your test to the PR and it's green. I think you mixed something up when testing this. I've added the same test for the other property types. **Lazyness** I don't know whether it's a good idea to add laziness to an existing API. But it's not the scope of my PR. I only try to fix a fundamental bug. Honestly, I'm not a big fan of laziness, because of the complexity, it tends to introduce. ------------- PR: https://git.openjdk.org/jfx/pull/689 From jvos at openjdk.org Mon Jul 11 09:11:58 2022 From: jvos at openjdk.org (Johan Vos) Date: Mon, 11 Jul 2022 09:11:58 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v3] In-Reply-To: References: Message-ID: > In order to fix the issues reported in JDK-8089589, the VirtualFlow now uses the real sizes of the elements that are displayed. This allows for a more natural way of scrolling through lists that contain items of very different sizes. > The algorithm that is used, does not calculate the size of each individual cell upfront, as that would be a major performance overhead (especially for large lists). Instead, we estimate the total size and the size of the individual cells based on the real measured size of a (growing) number of cells. > > There are a number of key variables that depend on this estimated size: > * position > * aboluteOffset > * currentIndex > > As a consequence, when the estimated size is changing, the absoluteOffset may change which may lead to a new currentIndex. If this happens during a layout phase, or a "complex" operation (e.g. scroll to an item and select it), this may lead to visually unexpected artifacts. While the rendering becomes more "correct" when the estimated size is improving, it is more important that we do not create visual confusion. > > The difficulty is that there are a large number of ways to manipulate the VirtualFlow, and different entry points may have different expectations about which variables should be kept constant (or only changed gradually). > > In this PR, we focus on consistency in the scrollTo method, where we want to keep the top-cell constant. In case the estimated size is improved during the scrollTo execution, or the next layoutChildren invocation, this implies keeping the result of computeCurrentIndex() constant so that after scrolling to a cell and selecting it, the selected cell is indeed the one that is scrolled to. > > This PR contains a number of tests for this scrollTo behaviour, that should also be considered as regression test in case we want to add more invariants later. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Add link to issue about ignored test Reverse expected and actual args in some tests. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/808/files - new: https://git.openjdk.org/jfx/pull/808/files/c077f10e..ce9f83eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=808&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=808&range=01-02 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/808.diff Fetch: git fetch https://git.openjdk.org/jfx pull/808/head:pull/808 PR: https://git.openjdk.org/jfx/pull/808 From fkirmaier at openjdk.org Mon Jul 11 11:46:40 2022 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Mon, 11 Jul 2022 11:46:40 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v3] In-Reply-To: References: Message-ID: <0lyhy_jToIUUo81XcHgpPAqreNEDFB-MsHMDrWk-I_0=.8158afc5-22b9-4d8b-8167-aedb85bded99@github.com> On Mon, 11 Jul 2022 09:11:58 GMT, Johan Vos wrote: >> In order to fix the issues reported in JDK-8089589, the VirtualFlow now uses the real sizes of the elements that are displayed. This allows for a more natural way of scrolling through lists that contain items of very different sizes. >> The algorithm that is used, does not calculate the size of each individual cell upfront, as that would be a major performance overhead (especially for large lists). Instead, we estimate the total size and the size of the individual cells based on the real measured size of a (growing) number of cells. >> >> There are a number of key variables that depend on this estimated size: >> * position >> * aboluteOffset >> * currentIndex >> >> As a consequence, when the estimated size is changing, the absoluteOffset may change which may lead to a new currentIndex. If this happens during a layout phase, or a "complex" operation (e.g. scroll to an item and select it), this may lead to visually unexpected artifacts. While the rendering becomes more "correct" when the estimated size is improving, it is more important that we do not create visual confusion. >> >> The difficulty is that there are a large number of ways to manipulate the VirtualFlow, and different entry points may have different expectations about which variables should be kept constant (or only changed gradually). >> >> In this PR, we focus on consistency in the scrollTo method, where we want to keep the top-cell constant. In case the estimated size is improved during the scrollTo execution, or the next layoutChildren invocation, this implies keeping the result of computeCurrentIndex() constant so that after scrolling to a cell and selecting it, the selected cell is indeed the one that is scrolled to. >> >> This PR contains a number of tests for this scrollTo behaviour, that should also be considered as regression test in case we want to add more invariants later. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Add link to issue about ignored test > Reverse expected and actual args in some tests. I've retested this version of the PR, and I can confirm, that it fixes the bug in the real-world application! So no regression happened when moving to the new PR! So great work! Not sure whether the first two tests are still necessary. The tests I wrote, basically used these test as a template and tried to generalize/parametrize it. But I guess more tests don't do any harm. There are 2 issues, we shouldn't forget about **after** this PR: 1.) In my original tests I had a snippet which is removed in this version. I still think the test is correct but it fails. So we should investigate it. // After clicking, the cells shouldn't move listView.getSelectionModel().select(scrollToIndex); listView.requestLayout(); Toolkit.getToolkit().firePulse(); assertEquals("Upper cell shouldn't move after changing heights and clicking", previousLayoutY, scrollToCell.getLayoutY(), 1.); 2.) In the previous [PR](https://github.com/openjdk/jfx/pull/712) we reported issues when scrolling after jumping to an index - including a video. As discussed with Johan we would like to investigate this further after this PR. ------------- PR: https://git.openjdk.org/jfx/pull/808 From jose.pereda at gluonhq.com Mon Jul 11 11:49:16 2022 From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=) Date: Mon, 11 Jul 2022 13:49:16 +0200 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_OpenJFX_Committer=3A_Michael_Strau=C3=9F?= In-Reply-To: <20220709123454.Horde.m4FHYSEItFViXVy04CF_tHW@webmail.df.eu> References: <24c276e4-8aaf-c054-ecdf-ad6b263d1009@oracle.com> <20220709123454.Horde.m4FHYSEItFViXVy04CF_tHW@webmail.df.eu> Message-ID: Vote: YES On Sat, Jul 9, 2022 at 12:36 PM Jeanette Winzenburg wrote: > > Vote: YES > > -- Jeanette > > Zitat von Kevin Rushforth : > > > I hereby nominate Michael Strau? [1] to OpenJFX Committer. > > > > Michael is an OpenJFX community member, who has contributed 16 > > commits [2] to OpenJFX. > > > > Votes are due by July 22, 2022 at 13:00 UTC. > > > > 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 [6]. > > > > Thanks. > > > > -- Kevin > > > > > > [1] https://openjdk.org/census#mstrauss > > > > [2] > > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Michael+Strau%C3%9F%22&s=author-date&type=commits > > > https://github.com/openjdk/jfx/search?q=author-name%3A%22mstr2%22&type=commits > > > > [3] https://openjdk.org/census#openjfx > > > > [4] https://openjdk.org/bylaws#lazy-consensus > > > > [6] https://openjdk.org/projects#project-committer > > > > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.pereda at gluonhq.com Mon Jul 11 11:49:51 2022 From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=) Date: Mon, 11 Jul 2022 13:49:51 +0200 Subject: CFV: New OpenJFX Committer: Marius Hanl In-Reply-To: <20220709123533.Horde.TRsazupcEYOSI4ReSowlIfa@webmail.df.eu> References: <9409a586-5d92-5eba-3b83-d02f00c5520a@oracle.com> <20220709123533.Horde.TRsazupcEYOSI4ReSowlIfa@webmail.df.eu> Message-ID: Vote: YES On Sat, Jul 9, 2022 at 12:37 PM Jeanette Winzenburg wrote: > > Vote: YES > > -- Jeanette > > Zitat von Kevin Rushforth : > > > I hereby nominate Marius Hanl [1] to OpenJFX Committer. > > > > Marius is an OpenJFX community member, who has contributed 22 > > commits [2] to OpenJFX. > > > > Votes are due by July 22, 2022 at 13:00 UTC. > > > > 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 [6]. > > > > Thanks. > > > > -- Kevin > > > > > > [1] https://openjdk.java.net/census#mhanl > > > > [2] > > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Marius+Hanl%22&s=author-date&type=commits > > > > [3] https://openjdk.java.net/census#openjfx > > > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > > > [6] https://openjdk.java.net/projects#project-committer > > > > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Mon Jul 11 12:51:45 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Jul 2022 12:51:45 GMT Subject: Integrated: 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 23:16:12 GMT, Kevin Rushforth wrote: > On Windows platforms we redistribute the Visual Studio runtime libraries with the JavaFX build so that JavaFX applications can run on systems that don't have them installed already. The main C++ runtime library is `msvcp140.dll`, which we ship along with the other native libraries for JavaFX. Additional C++ functionality has been added to `msvcp140_1.dll` and `msvcp140_2.dll`, neither of which are shipped. > > Recently, WebKit has started using some standard C++ functions that are only found in `msvcp140_2.dll`. We need to include the two missing libraries as part of the JavaFX build (in addition to `msvcp140.dll`, which is already included). This pull request has now been integrated. Changeset: cbb53b22 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/cbb53b22fc87e880d59ac3e217a86a4733d2b0f3 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build Reviewed-by: arapte, sykora ------------- PR: https://git.openjdk.org/jfx/pull/818 From kcr at openjdk.org Mon Jul 11 12:53:58 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Jul 2022 12:53:58 GMT Subject: Integrated: 8283402: Update to gcc 11.2 on Linux In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 12:19:10 GMT, Kevin Rushforth wrote: > This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK 19 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). > > I ran a full build and test, including media and WebKit. This pull request has now been integrated. Changeset: c7d3fd92 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/c7d3fd9276916ec3964e77148791bd7375487ffc Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod 8283402: Update to gcc 11.2 on Linux Reviewed-by: arapte, jvos ------------- PR: https://git.openjdk.org/jfx/pull/761 From kcr at openjdk.org Mon Jul 11 12:55:57 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Jul 2022 12:55:57 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v3] In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 09:11:58 GMT, Johan Vos wrote: >> In order to fix the issues reported in JDK-8089589, the VirtualFlow now uses the real sizes of the elements that are displayed. This allows for a more natural way of scrolling through lists that contain items of very different sizes. >> The algorithm that is used, does not calculate the size of each individual cell upfront, as that would be a major performance overhead (especially for large lists). Instead, we estimate the total size and the size of the individual cells based on the real measured size of a (growing) number of cells. >> >> There are a number of key variables that depend on this estimated size: >> * position >> * aboluteOffset >> * currentIndex >> >> As a consequence, when the estimated size is changing, the absoluteOffset may change which may lead to a new currentIndex. If this happens during a layout phase, or a "complex" operation (e.g. scroll to an item and select it), this may lead to visually unexpected artifacts. While the rendering becomes more "correct" when the estimated size is improving, it is more important that we do not create visual confusion. >> >> The difficulty is that there are a large number of ways to manipulate the VirtualFlow, and different entry points may have different expectations about which variables should be kept constant (or only changed gradually). >> >> In this PR, we focus on consistency in the scrollTo method, where we want to keep the top-cell constant. In case the estimated size is improved during the scrollTo execution, or the next layoutChildren invocation, this implies keeping the result of computeCurrentIndex() constant so that after scrolling to a cell and selecting it, the selected cell is indeed the one that is scrolled to. >> >> This PR contains a number of tests for this scrollTo behaviour, that should also be considered as regression test in case we want to add more invariants later. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Add link to issue about ignored test > Reverse expected and actual args in some tests. I think you missed one place where the `assertEquals` args are backwards. See https://github.com/openjdk/jfx/pull/808#discussion_r914724734 I'll do final testing today, but so far everything looks good. ------------- PR: https://git.openjdk.org/jfx/pull/808 From michaelstrau2 at gmail.com Mon Jul 11 13:06:18 2022 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 11 Jul 2022 15:06:18 +0200 Subject: Listeners behavior discussion In-Reply-To: <4554113b-3ac4-8c08-3132-7f30e3082978@gmail.com> References: <94890151-3f47-ef4e-c5f6-536af8378147@gmail.com> <7931ad4c-f95c-e61a-2c40-1d1228103813@gmail.com> <4554113b-3ac4-8c08-3132-7f30e3082978@gmail.com> Message-ID: 1. I don't understand your point about concurrency. The only way you end up in ExpressionHelper.fireValueChangedEvent is through the *PropertyBase and binding implementations, none of which are specified to support concurrent access. If you call set(...) in anything other than a strictly single-threaded context, you're relying on unspecified behavior (in this case, you're actually pretty likely to corrupt property state). There's no need to even consider concurrent access *except* when it is only an implementation detail that cannot be observed from the outside. Note that even if we did specify that event emission may not happen concurrently (and enforced that by making fireValueChangedEvent a synchronized method), that still would not make it acceptable to modify or access a property from multiple threads. Property implementations would need to be explicitly designed for that, which they are not (and should not be, in my opinion). 2. Listener invocation order: I don't think we can specify this for ObservableValue, as it could render many existing third-party implementations defective. We could, however, guarantee an ordering for the *PropertyBase implementations. But then our story for ObservableValue would be: "You can't rely on any particular order, except when the ObservableValue is a PropertyBase, then you can. But be aware that your code may silently break if someone changes the implementation of your ObservableValue to something other than PropertyBase." That doesn't sound like a great story. I'd much rather we fix the code that depends on a particular order of listener invocations. 3. Adding and removing listeners: The specification is pretty simple for the normal case. If you add a listener, you'll get a change notification for the next change. If you remove a listener, you will not get a change notification for the next change. Problems arise when a listener is added or removed during a change notification. I see no great reason to guarantee that additions or removals of listeners during a change will have any particular effect for the current change. It should be expressly unspecified whether an added or removed listener is invoked during a change. First of all, I think that adding or removing listeners during a change notification is pretty dubious to begin with, and we shouldn't encourage applications to do that. But what's more important is that such a guarantee severely limits the design space for ObservableValue implementations for an extremely dubious benefit. The cost vs benefit ratio seems pretty off. Here's an example: if we leave this unspecified, we have the option of using lock-free listener lists that support removals on a background thread (ConcurrentLinkedQueue is such an implementation). That's a huge benefit that, in my opinion, far outweighs the usefulness of having applications be able to rely on weird nested code. On Mon, Jul 11, 2022 at 8:09 AM John Hendrikx wrote: > > I've done some preliminary testing on the limits of what's possible. > > Disallowing nested changes broke about 50 tests. Changing the order of > listener events broke 9 tests (I reversed the order, see this diff for > what I did: > https://github.com/hjohn/jfx/commit/c7588c49d42257f75627f15ca7ed01147d5e5e3d). > > I investigated the tests that broke when the ordering changed. They're > all Tree/Table/ListView tests. The tests breaking all seem to interact > with the selection and focus model, so there might be some kind of > ordering dependency in there (list of the 9 tests that broke added at > end of this post). > > Disallowing nested emissions broke far more, Spinner, ComboBox, > ColorPicker, Scroll related things, TableCell. I didn't run systemTests > or web tests, so there might be even more that breaks. > > Further comments inline: > > On 10/07/2022 20:11, Nir Lisker wrote: > > There was a previous implementation discussion that touched on some of > > the points here in https://github.com/openjdk/jfx/pull/108 > > > > I think there are a few (semi-)independent points here: > > 1. Order of listeners: as John said, there is no specification of the > > order of listeners, but the add/removeListener methods imply that > > there is some sort of order by saying that the "first occurrence" will > > be removed. > > 2. Dispatch order: the docs don't specify (from what I could find) the > > order in which listeners receive events. That is, if listener1 and > > listener2 are registered in that order, I didn't find anything that > > specifies that they will be notified in this order, although It makes > > sense that they are. From the API perspective, there is no > > `getListeners()` method or the like that allows me to see the > > order, so I have to "remember" that order somehow, and that's an > > indication that the order is actually not important. > > Furthermore, the order is separate for invalidation listeners and > > change listeners: first all invalidation listeners are notified, then > > all change listeners, even if all the change listeners were > > registered before. This alone can be surprising. > > 3. Concurrent modification of listeners: if a listener is added or > > removed from another thread (while an event is being sent through the > > listener list or otherwise), what should happen. > > 4. Nested events (relevant only for change listeners I think): if a > > value is changed inside a listener, what should happen. The docs in > > ChangeListener#changed mention that it is "bad practice", but don't > > prohibit it. > > Thanks, good summary there. > > > I have some thoughts, but I haven't constructed an opinion yet: > > 1+2. It should be tested how much practical maneuvering room we have > > here first. If we don't keep an ordered collection of listeners, or > > don't dispatch the event to them in that order, or even if we dispatch > > first to all change listeners and then to all invalidation listeners, > > what breaks? This will give us an idea of our options. > > 3. I agree with Michael that as long as there is no mention of thread > > safety in any of the relevant classes (observables and listeners), the > > behavior should be unspecified, exactly as it is in core JDK classes > > that don't specify anything. We can revisit this when the GC part of > > the story is on the move, as John said. > > 4. I don't think we can restrict nested changes at this point > > considering the docs, and I remember some classes in JavaFX doing this > > (I think it was in the animation package). However, I propose to look > > at another approach: The event dispatcher will use an iterator, and > > whatever changes happen during iteration will reflect on it (if they > > are relevant). It is not guaranteed that all listeners that were > > registered *at the time of the event* will receive it, but only those > > that are registered in time for a dispatch. It removes the hurdles of > > locking or maintaining a queue. Also, if I have a listener1 whose job > > is to remove a listener2 when an event is received, it's very probable > > that I don't want listener2 to react to the event (unless it wasn't > > registered before listener1, in which case "too late", but see also > > points 1+2). > > If this approach is viable, it should also be tested practically. > > > As for the last point, I don't think we should change a current event > emission. When an event occurs, I think every one that was registered > should receive it (which is currently ensured by making a copy). Doing > it differently (allowing the list to change during emission of a single > event) would actually introduce ordering effects and would be a much > harder behavior to document. > > As for it removing hurdles, I think a copy free approach is already > possible *if* we specify that changes are historical (ie. everyone at > the time of registration receives the exact same change event, > regardless of nested value changes or nested listener list changes). > > If changes are historical, the implementation probably must delay nested > value changes to adhere to the specification. > > If we further specify (or implement in this case) that for a single > property, no more than a single emission can run concurrently (this > seems reasonable IMHO, especially given the fact that concurrent > emissions probably hardly happen currently as it would break too much > things in unexpected ways), then the implementation can buffer any list > modifications made. > > All the above taken together will allow a copy free use of listener > list. A lock is still needed to detect a nested emission, when to buffer > changes and to prevent emissions on another thread. > > --John > > > ListViewTest > ensureSelectionIsCorrectWhenItemsChange FAILED > java.lang.AssertionError: expected:<0> but was:<-1> > at org.junit.Assert.fail(Assert.java:89) > at org.junit.Assert.failNotEquals(Assert.java:835) > at org.junit.Assert.assertEquals(Assert.java:647) > at org.junit.Assert.assertEquals(Assert.java:633) > at > test.javafx.scene.control.ListViewTest.ensureSelectionIsCorrectWhenItemsChange(ListViewTest.java:337) > > TableViewTest > ensureSelectionIsCorrectWhenItemsChange FAILED > java.lang.AssertionError: expected:<0> but was:<-1> > at org.junit.Assert.fail(Assert.java:89) > at org.junit.Assert.failNotEquals(Assert.java:835) > at org.junit.Assert.assertEquals(Assert.java:647) > at org.junit.Assert.assertEquals(Assert.java:633) > at > test.javafx.scene.control.TableViewTest.ensureSelectionIsCorrectWhenItemsChange(TableViewTest.java:351) > > TreeTableViewTest > > test_rt27180_expandBranch_laterSiblingSelected_singleSelection FAILED > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:87) > at org.junit.Assert.assertTrue(Assert.java:42) > at org.junit.Assert.assertTrue(Assert.java:53) > at > test.javafx.scene.control.TreeTableViewTest.test_rt27180_expandBranch_laterSiblingSelected_singleSelection(TreeTableViewTest.java:2315) > > TreeTableViewTest > > test_rt27180_expandBranch_laterSiblingAndChildrenSelected FAILED > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:87) > at org.junit.Assert.assertTrue(Assert.java:42) > at org.junit.Assert.assertTrue(Assert.java:53) > at > test.javafx.scene.control.TreeTableViewTest.test_rt27180_expandBranch_laterSiblingAndChildrenSelected(TreeTableViewTest.java:2340) > > TreeTableViewTest > test_rt27185 FAILED > java.lang.AssertionError: expected: ]> but was: > at org.junit.Assert.fail(Assert.java:89) > at org.junit.Assert.failNotEquals(Assert.java:835) > at org.junit.Assert.assertEquals(Assert.java:120) > at org.junit.Assert.assertEquals(Assert.java:146) > at > test.javafx.scene.control.TreeTableViewTest.test_rt27185(TreeTableViewTest.java:1569) > > TreeViewTest > > test_rt27180_expandBranch_laterSiblingSelected_singleSelection FAILED > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:87) > at org.junit.Assert.assertTrue(Assert.java:42) > at org.junit.Assert.assertTrue(Assert.java:53) > at > test.javafx.scene.control.TreeViewTest.test_rt27180_expandBranch_laterSiblingSelected_singleSelection(TreeViewTest.java:1018) > > TreeViewTest > > test_rt27180_collapseBranch_laterSiblingAndChildrenSelected FAILED > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:87) > at org.junit.Assert.assertTrue(Assert.java:42) > at org.junit.Assert.assertTrue(Assert.java:53) > at > test.javafx.scene.control.TreeViewTest.test_rt27180_collapseBranch_laterSiblingAndChildrenSelected(TreeViewTest.java:999) > > TreeViewTest > test_rt27180_expandBranch_laterSiblingAndChildrenSelected > FAILED > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:87) > at org.junit.Assert.assertTrue(Assert.java:42) > at org.junit.Assert.assertTrue(Assert.java:53) > at > test.javafx.scene.control.TreeViewTest.test_rt27180_expandBranch_laterSiblingAndChildrenSelected(TreeViewTest.java:1043) > > TreeViewTest > test_rt27185 FAILED > java.lang.AssertionError: expected: ]> but was: > at org.junit.Assert.fail(Assert.java:89) > at org.junit.Assert.failNotEquals(Assert.java:835) > at org.junit.Assert.assertEquals(Assert.java:120) > at org.junit.Assert.assertEquals(Assert.java:146) > at > test.javafx.scene.control.TreeViewTest.test_rt27185(TreeViewTest.java:630) > From jvos at openjdk.org Mon Jul 11 13:59:36 2022 From: jvos at openjdk.org (Johan Vos) Date: Mon, 11 Jul 2022 13:59:36 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: Message-ID: > In order to fix the issues reported in JDK-8089589, the VirtualFlow now uses the real sizes of the elements that are displayed. This allows for a more natural way of scrolling through lists that contain items of very different sizes. > The algorithm that is used, does not calculate the size of each individual cell upfront, as that would be a major performance overhead (especially for large lists). Instead, we estimate the total size and the size of the individual cells based on the real measured size of a (growing) number of cells. > > There are a number of key variables that depend on this estimated size: > * position > * aboluteOffset > * currentIndex > > As a consequence, when the estimated size is changing, the absoluteOffset may change which may lead to a new currentIndex. If this happens during a layout phase, or a "complex" operation (e.g. scroll to an item and select it), this may lead to visually unexpected artifacts. While the rendering becomes more "correct" when the estimated size is improving, it is more important that we do not create visual confusion. > > The difficulty is that there are a large number of ways to manipulate the VirtualFlow, and different entry points may have different expectations about which variables should be kept constant (or only changed gradually). > > In this PR, we focus on consistency in the scrollTo method, where we want to keep the top-cell constant. In case the estimated size is improved during the scrollTo execution, or the next layoutChildren invocation, this implies keeping the result of computeCurrentIndex() constant so that after scrolling to a cell and selecting it, the selected cell is indeed the one that is scrolled to. > > This PR contains a number of tests for this scrollTo behaviour, that should also be considered as regression test in case we want to add more invariants later. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: reverse one more expected/actual set of args. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/808/files - new: https://git.openjdk.org/jfx/pull/808/files/ce9f83eb..b525b80b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=808&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=808&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/808.diff Fetch: git fetch https://git.openjdk.org/jfx pull/808/head:pull/808 PR: https://git.openjdk.org/jfx/pull/808 From duke at openjdk.org Mon Jul 11 15:22:46 2022 From: duke at openjdk.org (Andy Goryachev) Date: Mon, 11 Jul 2022 15:22:46 GMT Subject: RFR: 8289389: Fix warnings: type should also implement hashCode() since it overrides Object.equals() [v2] In-Reply-To: References: <0fTAATcre_hBsBKlRtFkFOqehJE4YZvgm0D4Q2rKJK8=.03babaf5-5f65-4b49-a0da-da4e30ef2a31@github.com> Message-ID: On Fri, 8 Jul 2022 23:45:58 GMT, John Hendrikx wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8289389: toExternalForm() > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/CalculatedValue.java line 101: > >> 99: } >> 100: return h; >> 101: } > > Just an example, but wouldn't: `Objects.hash(relative, origin, value)` here work just as well? @hjohn: yes, but at a price: Object.hash(Object ...) incurs overhead by creating a temporary Object[] + boxing of a Boolean. ------------- PR: https://git.openjdk.org/jfx/pull/821 From duke at openjdk.org Mon Jul 11 15:32:01 2022 From: duke at openjdk.org (Andy Goryachev) Date: Mon, 11 Jul 2022 15:32:01 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files [v10] In-Reply-To: References: Message-ID: On Sat, 9 Jul 2022 03:13:35 GMT, Nir Lisker wrote: > It might be a good idea to add the JUnit 5 container to all modules preemptively so that when someone adds a test with Junit 5 we won't need to patch the classpath file ad-hoc. Fine to leave as is. I agree. Let's do it as a part of apps/ ------------- PR: https://git.openjdk.org/jfx/pull/804 From jhendrikx at openjdk.org Mon Jul 11 18:59:51 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 11 Jul 2022 18:59:51 GMT Subject: RFR: 8289389: Fix warnings: type should also implement hashCode() since it overrides Object.equals() [v2] In-Reply-To: References: <0fTAATcre_hBsBKlRtFkFOqehJE4YZvgm0D4Q2rKJK8=.03babaf5-5f65-4b49-a0da-da4e30ef2a31@github.com> Message-ID: <6I06qWCgstqz_fZsq3Pap3vHqF3c240djrAdarIcXfY=.b76ba0ea-eece-404d-ba8c-b411aad74d17@github.com> On Mon, 11 Jul 2022 15:19:30 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/CalculatedValue.java line 101: >> >>> 99: } >>> 100: return h; >>> 101: } >> >> Just an example, but wouldn't: `Objects.hash(relative, origin, value)` here work just as well? > > @hjohn: yes, but at a price: Object.hash(Object ...) incurs overhead by creating a temporary Object[] + boxing of a Boolean. Ah, I didn't realize you checked how this is optimized by the JIT. ------------- PR: https://git.openjdk.org/jfx/pull/821 From duke at openjdk.org Mon Jul 11 19:48:11 2022 From: duke at openjdk.org (Andy Goryachev) Date: Mon, 11 Jul 2022 19:48:11 GMT Subject: Integrated: 8289395: Fix warnings: Varargs methods should only override or be overridden by other varargs methods In-Reply-To: <-Qjxdv4Rvjm9fm0g9pMpinAhp4hZPNO4I5M8oRnemPo=.08c5af80-652e-45a9-8391-c16bc66ad2e5@github.com> References: <-Qjxdv4Rvjm9fm0g9pMpinAhp4hZPNO4I5M8oRnemPo=.08c5af80-652e-45a9-8391-c16bc66ad2e5@github.com> Message-ID: <4t1L5dDYg4dQRWbZNb1PDMmbAezse3puhqbPfFcf6TU=.424ae363-afa7-4643-a419-e571557a861a@github.com> On Wed, 6 Jul 2022 18:52:08 GMT, Andy Goryachev wrote: > - fixed varargs This pull request has now been integrated. Changeset: 13f3e1f7 Author: Andy Goryachev Committer: Nir Lisker URL: https://git.openjdk.org/jfx/commit/13f3e1f7457c4e0af0002bf9157704c67f7eb576 Stats: 16 lines in 8 files changed: 0 ins; 0 del; 16 mod 8289395: Fix warnings: Varargs methods should only override or be overridden by other varargs methods Reviewed-by: nlisker ------------- PR: https://git.openjdk.org/jfx/pull/816 From duke at openjdk.org Mon Jul 11 19:49:48 2022 From: duke at openjdk.org (Andy Goryachev) Date: Mon, 11 Jul 2022 19:49:48 GMT Subject: Integrated: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 23:19:36 GMT, Andy Goryachev wrote: > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files > > the list of eclipse projects that do compile in Eclipse as a result of this PR are: > - base > - controls > - fxml > - graphics > - jfx > - media > - swing > - swt > - systemTests (can be dropped in favor ot tests > - tests > - web > > Not supported (should be removed from workspace or simply closed): > - apps > - apps/* > - buildSrc This pull request has now been integrated. Changeset: 437c078a Author: Andy Goryachev Committer: Nir Lisker URL: https://git.openjdk.org/jfx/commit/437c078abe32b1aa8a4a99987454efeae5358c6b Stats: 53 lines in 6 files changed: 24 ins; 22 del; 7 mod 8289255: update Eclipse .classpath and other configuration files Reviewed-by: nlisker ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Mon Jul 11 20:13:49 2022 From: duke at openjdk.org (Andy Goryachev) Date: Mon, 11 Jul 2022 20:13:49 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 22:00:24 GMT, Nir Lisker wrote: >> The fix includes: >> - renaming of offending methods to avoid confusion >> - explicitly declaring the offending methods as private > > modules/javafx.graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderGraphics.java line 92: > >> 90: BaseShaderContext getBaseShaderContext() { >> 91: return context; >> 92: } > > Mentioning this was brought up in relation to a different PR: https://github.com/openjdk/jfx/pull/628#issuecomment-924898354 I think it's a safe change (and this method should probably be made private, as it is only called from the same class). ------------- PR: https://git.openjdk.org/jfx/pull/824 From kcr at openjdk.org Mon Jul 11 20:45:47 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Jul 2022 20:45:47 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: <1rpJ1Gj2fburkhm5l37iTLNpGF1goyOYyS-OIi_Uauc=.461a1f95-fbbf-41b0-9ec9-09c7291d045d@github.com> On Mon, 11 Jul 2022 20:10:23 GMT, Andy Goryachev wrote: > I think it's a safe change Agreed. > (and this method should probably be made private, as it is only called from the same class). No, it's called from `CachingShapeRep`, which you (necessarily) modified as part of this PR. ------------- PR: https://git.openjdk.org/jfx/pull/824 From duke at openjdk.org Mon Jul 11 20:54:51 2022 From: duke at openjdk.org (Andy Goryachev) Date: Mon, 11 Jul 2022 20:54:51 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: <1rpJ1Gj2fburkhm5l37iTLNpGF1goyOYyS-OIi_Uauc=.461a1f95-fbbf-41b0-9ec9-09c7291d045d@github.com> References: <1rpJ1Gj2fburkhm5l37iTLNpGF1goyOYyS-OIi_Uauc=.461a1f95-fbbf-41b0-9ec9-09c7291d045d@github.com> Message-ID: On Mon, 11 Jul 2022 20:42:22 GMT, Kevin Rushforth wrote: >> I think it's a safe change (and this method should probably be made private, as it is only called from the same class). > >> I think it's a safe change > > Agreed. > >> (and this method should probably be made private, as it is only called from the same class). > > No, it's called from `CachingShapeRep`, which you (necessarily) modified as part of this PR. right, sorry - that's why I did not make it private. (note to self: double check before responding) ------------- PR: https://git.openjdk.org/jfx/pull/824 From kcr at openjdk.org Mon Jul 11 20:59:43 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Jul 2022 20:59:43 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private One question: did you check that all of the methods you changed to private scope are only called from other methods in the same class where they are defined (and not called from another class, such as an inner class or lambda, in the same file)? ------------- PR: https://git.openjdk.org/jfx/pull/824 From kcr at openjdk.org Mon Jul 11 21:15:47 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Jul 2022 21:15:47 GMT Subject: RFR: 8289389: Fix warnings: type should also implement hashCode() since it overrides Object.equals() [v2] In-Reply-To: <6I06qWCgstqz_fZsq3Pap3vHqF3c240djrAdarIcXfY=.b76ba0ea-eece-404d-ba8c-b411aad74d17@github.com> References: <0fTAATcre_hBsBKlRtFkFOqehJE4YZvgm0D4Q2rKJK8=.03babaf5-5f65-4b49-a0da-da4e30ef2a31@github.com> <6I06qWCgstqz_fZsq3Pap3vHqF3c240djrAdarIcXfY=.b76ba0ea-eece-404d-ba8c-b411aad74d17@github.com> Message-ID: <6QCdDXeX-jH_1OAqOJN3s8lv5KhIbPvlLI_BluNl_0U=.47ef2d9a-eef2-4d6c-91f8-a1c6605f0b7e@github.com> On Mon, 11 Jul 2022 18:56:36 GMT, John Hendrikx wrote: >> @hjohn: yes, but at a price: Object.hash(Object ...) incurs overhead by creating a temporary Object[] + boxing of a Boolean. > > Ah, I didn't realize you checked how this is optimized by the JIT. In order to reduce collisions, the hash of each component is typically added to `h * 31` even when that hash is 0, whereas you skip the `h = 31 * h` in the case of null. It might not be a problem in practice, since value and origin are unlikely to collide, being of different types, but you might want to look at it. In any case, I need to time to look at it, which I won't have until after JavaFX 19 RDP1, so let's leave this until then. ------------- PR: https://git.openjdk.org/jfx/pull/821 From duke at openjdk.org Mon Jul 11 21:40:44 2022 From: duke at openjdk.org (Andy Goryachev) Date: Mon, 11 Jul 2022 21:40:44 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 20:55:50 GMT, Kevin Rushforth wrote: > One question: did you check that all of the methods you changed to private scope are only called from other methods in the same class where they are defined (and not called from another class, such as an inner class or lambda, in the same file)? yes, of course. besides, all these cases would generate an error or a warning in eclipse. ------------- PR: https://git.openjdk.org/jfx/pull/824 From kcr at openjdk.org Mon Jul 11 22:05:48 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Jul 2022 22:05:48 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: <084hnLsB4Kel95cDF9pk-xXhz9wu_DEn_yI-z6jgrxA=.0c197718-810e-4f7d-8e76-695c212bb698@github.com> On Mon, 11 Jul 2022 21:37:43 GMT, Andy Goryachev wrote: > > One question: did you check that all of the methods you changed to private scope are only called from other methods in the same class where they are defined (and not called from another class, such as an inner class or lambda, in the same file)? > > yes, of course. Thanks for confirming (I spot-checked it, and didn't see any). > besides, all these cases would generate an error or a warning in eclipse. Are you sure? So you are saying that the following would generate a warning in Eclipse? public class SomeClass { private double meth(double x) { return Math.sqrt(x); } static class NestedClass { double meth(SomeClass cls, double x) { return cls.meth(x); } } } This is a simple (and contrived) example, but in more complicated cases, the compiler sometimes has to generate a bridge method for private methods. In any case, it sounds like this isn't even a potential problem here. ------------- PR: https://git.openjdk.org/jfx/pull/824 From mstrauss at openjdk.org Mon Jul 11 22:08:47 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 11 Jul 2022 22:08:47 GMT Subject: Integrated: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 18:17:27 GMT, Michael Strau? wrote: > This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. This pull request has now been integrated. Changeset: 8d5d3ca8 Author: Michael Strau? Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/8d5d3ca85f83765e661d108bf86b5b7372d75947 Stats: 638 lines in 22 files changed: 464 ins; 14 del; 160 mod 8268225: Support :focus-visible and :focus-within CSS pseudoclasses Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/475 From duke at openjdk.org Mon Jul 11 22:17:49 2022 From: duke at openjdk.org (Andy Goryachev) Date: Mon, 11 Jul 2022 22:17:49 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private Kevin, what I meant actually, is that Eclipse would generate a warning when compiler creates a synthetic accessor: Access to enclosing method beginChange() from the type ObservableListBase is emulated by a synthetic accessor method line 59 /base/src/main/java/com/sun/javafx/collections ElementObservableListDecorator.java there are about 81 warnings like this, if enabled. I decided to disable them because it may not be a trivial change. Your snippet, of course, compiles without a problem, as it should. ------------- PR: https://git.openjdk.org/jfx/pull/824 From kcr at openjdk.org Mon Jul 11 22:26:50 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Jul 2022 22:26:50 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private Thanks for the explanation. I hadn't realized the Eclipse compiler had such a warning. ------------- PR: https://git.openjdk.org/jfx/pull/824 From kcr at openjdk.org Mon Jul 11 22:33:52 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Jul 2022 22:33:52 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: <7mcIEFwSqvQkzOGoTpVdXvJQlQ_gnm-RaT6eLDpHFH0=.2944074b-6f66-4551-88b0-bf699113d59e@github.com> On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private Looks good to me. @nlisker any concerns? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/824 From nlisker at openjdk.org Mon Jul 11 22:33:53 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 11 Jul 2022 22:33:53 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private I haven't had time to look at this one yet. Will do so later today or tomorrow. ------------- PR: https://git.openjdk.org/jfx/pull/824 From duke at openjdk.org Mon Jul 11 22:44:41 2022 From: duke at openjdk.org (Andy Goryachev) Date: Mon, 11 Jul 2022 22:44:41 GMT Subject: RFR: 8289389: Fix warnings: type should also implement hashCode() since it overrides Object.equals() [v3] In-Reply-To: References: Message-ID: <2meyA6GVDIpND6K0cfYBvQL8-_Deg0v91sE7yfPlQiE=.bc0d1e6b-1d83-412f-9054-3eb64eaa4bc0@github.com> > - added missing hashCode() methods Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8289389: minimize the impact of collision ------------- Changes: - all: https://git.openjdk.org/jfx/pull/821/files - new: https://git.openjdk.org/jfx/pull/821/files/d82e683f..ed53414c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=821&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=821&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/821.diff Fetch: git fetch https://git.openjdk.org/jfx pull/821/head:pull/821 PR: https://git.openjdk.org/jfx/pull/821 From duke at openjdk.org Mon Jul 11 22:44:43 2022 From: duke at openjdk.org (Andy Goryachev) Date: Mon, 11 Jul 2022 22:44:43 GMT Subject: RFR: 8289389: Fix warnings: type should also implement hashCode() since it overrides Object.equals() [v2] In-Reply-To: <6QCdDXeX-jH_1OAqOJN3s8lv5KhIbPvlLI_BluNl_0U=.47ef2d9a-eef2-4d6c-91f8-a1c6605f0b7e@github.com> References: <0fTAATcre_hBsBKlRtFkFOqehJE4YZvgm0D4Q2rKJK8=.03babaf5-5f65-4b49-a0da-da4e30ef2a31@github.com> <6I06qWCgstqz_fZsq3Pap3vHqF3c240djrAdarIcXfY=.b76ba0ea-eece-404d-ba8c-b411aad74d17@github.com> <6QCdDXeX-jH_1OAqOJN3s8lv5KhIbPvlLI_BluNl_0U=.47ef2d9a-eef2-4d6c-91f8-a1c6605f0b7e@github.com> Message-ID: On Mon, 11 Jul 2022 21:12:02 GMT, Kevin Rushforth wrote: >> Ah, I didn't realize you checked how this is optimized by the JIT. > > In order to reduce collisions, the hash of each component is typically added to `h * 31` even when that hash is 0, whereas you skip the `h = 31 * h` in the case of null. It might not be a problem in practice, since value and origin are unlikely to collide, being of different types, but you might want to look at it. > > In any case, I need to time to look at it, which I won't have until after JavaFX 19 RDP1, so let's leave this until then. you bring a good point, Kevin, thank you! ------------- PR: https://git.openjdk.org/jfx/pull/821 From andrea.vacondio at gmail.com Tue Jul 12 08:58:21 2022 From: andrea.vacondio at gmail.com (Andrea Vacondio) Date: Tue, 12 Jul 2022 10:58:21 +0200 Subject: Drag and drop of Outlook attachments Message-ID: Hello, can anyone point me or tell me the current support regarding JavaFX drag and drop of Outlook attachments? This is the only bug report I found https://bugs.openjdk.org/browse/JDK-8133342 Also, is there a searchable version of the mailing list? https:// mail.openjdk.org/pipermail/open Thanks Andrea -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Jul 12 11:34:50 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 12 Jul 2022 11:34:50 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 13:59:36 GMT, Johan Vos wrote: >> In order to fix the issues reported in JDK-8089589, the VirtualFlow now uses the real sizes of the elements that are displayed. This allows for a more natural way of scrolling through lists that contain items of very different sizes. >> The algorithm that is used, does not calculate the size of each individual cell upfront, as that would be a major performance overhead (especially for large lists). Instead, we estimate the total size and the size of the individual cells based on the real measured size of a (growing) number of cells. >> >> There are a number of key variables that depend on this estimated size: >> * position >> * aboluteOffset >> * currentIndex >> >> As a consequence, when the estimated size is changing, the absoluteOffset may change which may lead to a new currentIndex. If this happens during a layout phase, or a "complex" operation (e.g. scroll to an item and select it), this may lead to visually unexpected artifacts. While the rendering becomes more "correct" when the estimated size is improving, it is more important that we do not create visual confusion. >> >> The difficulty is that there are a large number of ways to manipulate the VirtualFlow, and different entry points may have different expectations about which variables should be kept constant (or only changed gradually). >> >> In this PR, we focus on consistency in the scrollTo method, where we want to keep the top-cell constant. In case the estimated size is improved during the scrollTo execution, or the next layoutChildren invocation, this implies keeping the result of computeCurrentIndex() constant so that after scrolling to a cell and selecting it, the selected cell is indeed the one that is scrolled to. >> >> This PR contains a number of tests for this scrollTo behaviour, that should also be considered as regression test in case we want to add more invariants later. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > reverse one more expected/actual set of args. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/808 From arapte at openjdk.org Tue Jul 12 12:06:55 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 12 Jul 2022 12:06:55 GMT Subject: RFR: 8288137: The set of available printers is not updated without application restart [v4] In-Reply-To: <0rXLXNASeWJqc2xtUMu2faY4lqmCUXraCDxg-fdewXw=.34b11ffc-4388-4386-8f16-41c5ff81b37e@github.com> References: <0rXLXNASeWJqc2xtUMu2faY4lqmCUXraCDxg-fdewXw=.34b11ffc-4388-4386-8f16-41c5ff81b37e@github.com> Message-ID: On Fri, 8 Jul 2022 22:27:41 GMT, Phil Race wrote: >> This fixes the issue that the default printer or set of available printers is fixed from the first call to it in the lifetime of the application. >> Now subsequent calls will check to see if there are changes. >> A manual test is provided for verifying this - it requires you to add/remove printers at the system level to verify anything related to this fix. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8288137 Verified that available printers get updated correctly, by running provided test. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/817 From fkirmaier at openjdk.org Tue Jul 12 13:21:59 2022 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 12 Jul 2022 13:21:59 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 13:59:36 GMT, Johan Vos wrote: >> In order to fix the issues reported in JDK-8089589, the VirtualFlow now uses the real sizes of the elements that are displayed. This allows for a more natural way of scrolling through lists that contain items of very different sizes. >> The algorithm that is used, does not calculate the size of each individual cell upfront, as that would be a major performance overhead (especially for large lists). Instead, we estimate the total size and the size of the individual cells based on the real measured size of a (growing) number of cells. >> >> There are a number of key variables that depend on this estimated size: >> * position >> * aboluteOffset >> * currentIndex >> >> As a consequence, when the estimated size is changing, the absoluteOffset may change which may lead to a new currentIndex. If this happens during a layout phase, or a "complex" operation (e.g. scroll to an item and select it), this may lead to visually unexpected artifacts. While the rendering becomes more "correct" when the estimated size is improving, it is more important that we do not create visual confusion. >> >> The difficulty is that there are a large number of ways to manipulate the VirtualFlow, and different entry points may have different expectations about which variables should be kept constant (or only changed gradually). >> >> In this PR, we focus on consistency in the scrollTo method, where we want to keep the top-cell constant. In case the estimated size is improved during the scrollTo execution, or the next layoutChildren invocation, this implies keeping the result of computeCurrentIndex() constant so that after scrolling to a cell and selecting it, the selected cell is indeed the one that is scrolled to. >> >> This PR contains a number of tests for this scrollTo behaviour, that should also be considered as regression test in case we want to add more invariants later. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > reverse one more expected/actual set of args. Marked as reviewed by fkirmaier (Author). ------------- PR: https://git.openjdk.org/jfx/pull/808 From nlisker at openjdk.org Tue Jul 12 22:50:54 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 12 Jul 2022 22:50:54 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private I've finished an analysis of a few of the cases here. After checking the [JLS](https://docs.oracle.com/javase/specs/jls/se18/html/jls-9.html#jls-9.6.4.4), in my opinion this warning should be turned off without "fixing" its occurrences for the following reason: If a method in a supertype is not visible to a subtype, then it is an implementation detail. Subtypes should not be concerned with the names of methods outside of their visibility (whether in the hierarchy or not). If a method is supposed to override another method, then the `@Override` annotation should be used. This will give the definitiveness of overriding - if the method really is overriding, nothing else is needed; if it isn't, a compiler error occurs. Therefore, my recommendation is to fix all "method x is overriding method y but does not have the `@Override` annotation" warnings (I have my Eclipse set to treat missing override annotations as an error even, and it has served me well). Once all overriding methods are annotated and all non-overriding methods are not annotated, this warning becomes meaningless. One interesting case is the one I mentioned with `D3DGraphics#getContext`: it really does override the superinterfce method, but also has the same signature of a method in `BaseShaderGraphics`, resulting in a "fake override", but the `@Override` annotation is still applicable. If we turn off the "fake override" warning, everything remains clear because the IDE tells us which method is really being overridden. In fact, this warning just made this case more confusing because it implies an override that doesn't happen, and hides the one that really does. ------------- PR: https://git.openjdk.org/jfx/pull/824 From kcr at openjdk.org Tue Jul 12 23:04:57 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 12 Jul 2022 23:04:57 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private At a minimum it seems that this needs more discussion, which will need to wait until after the fork. ------------- PR: https://git.openjdk.org/jfx/pull/824 From duke at openjdk.org Tue Jul 12 23:04:58 2022 From: duke at openjdk.org (Andy Goryachev) Date: Tue, 12 Jul 2022 23:04:58 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private +1 for JLS While I agree that leaving the code as is does not cause issues (since the methods are not getting overriden), it might fall under maintainability rubric. Especially in the case of BaseShaderGraphics, where a human surely gets confused. Some people do have eclipse and can F3 to see the superclass. So I would suggest to merge all of my changes. If this is unacceptable, at least merge the BaseShaderGraphics change, as it is rather confusing. The good thing is that we only have a very few places, so the probability of confusion due to this issue is rather low. ------------- PR: https://git.openjdk.org/jfx/pull/824 From kcr at openjdk.org Tue Jul 12 23:16:49 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 12 Jul 2022 23:16:49 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v3] In-Reply-To: <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> Message-ID: On Thu, 7 Jul 2022 22:46:53 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > fixed pixel color tests on hi-dpi At this point, due to time constraints, we will need to do this early in JavaFX 20 rather than late in JavaFX 19 (which is probably better anyway). ------------- PR: https://git.openjdk.org/jfx/pull/674 From jpereda at openjdk.org Tue Jul 12 23:35:51 2022 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 12 Jul 2022 23:35:51 GMT Subject: RFR: 8284676: TreeTableView loses sort ordering when applied on empty table In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 15:59:17 GMT, Ambarish Rapte wrote: > Issue: In a TreeTableView if root item has no children then TreeTableView does not retain if a sort order is set. > > Cause: This is a regression of fix for [JDK-8256283](https://bugs.openjdk.org/browse/JDK-8256283), which returned false from `SortPolicy.call()` function if root item has no children. This function is called from `TreeTableView.sort()` line #1863. When the returned value is false then line #1885 gets executed, which removes the sort order that was added. > > Fix: The fix for [JDK-8256283](https://bugs.openjdk.org/browse/JDK-8256283) is modified to return true instead. Added a test that fails without and passes with fix. Looks good, minor naming issue modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 789: > 787: } > 788: > 789: @Test public void testSetSortOrderretainsWhenRootHasNoChildren() { Minor, fix the camel case: `testSetSortOrderRetainsWhenRootHasNoChildren` ------------- PR: https://git.openjdk.org/jfx/pull/825 From arapte at openjdk.org Wed Jul 13 05:06:45 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 13 Jul 2022 05:06:45 GMT Subject: RFR: 8284676: TreeTableView loses sort ordering when applied on empty table [v2] In-Reply-To: References: Message-ID: > Issue: In a TreeTableView if root item has no children then TreeTableView does not retain if a sort order is set. > > Cause: This is a regression of fix for [JDK-8256283](https://bugs.openjdk.org/browse/JDK-8256283), which returned false from `SortPolicy.call()` function if root item has no children. This function is called from `TreeTableView.sort()` line #1863. When the returned value is false then line #1885 gets executed, which removes the sort order that was added. > > Fix: The fix for [JDK-8256283](https://bugs.openjdk.org/browse/JDK-8256283) is modified to return true instead. Added a test that fails without and passes with fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: review comment: correct test name ------------- Changes: - all: https://git.openjdk.org/jfx/pull/825/files - new: https://git.openjdk.org/jfx/pull/825/files/5768d03c..39353ce3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=825&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=825&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/825.diff Fetch: git fetch https://git.openjdk.org/jfx pull/825/head:pull/825 PR: https://git.openjdk.org/jfx/pull/825 From arapte at openjdk.org Wed Jul 13 05:06:47 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 13 Jul 2022 05:06:47 GMT Subject: RFR: 8284676: TreeTableView loses sort ordering when applied on empty table [v2] In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 23:14:17 GMT, Jose Pereda wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> review comment: correct test name > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 789: > >> 787: } >> 788: >> 789: @Test public void testSetSortOrderretainsWhenRootHasNoChildren() { > > Minor, fix the camel case: `testSetSortOrderRetainsWhenRootHasNoChildren` Thanks, it is corrected now. ------------- PR: https://git.openjdk.org/jfx/pull/825 From jhendrikx at openjdk.org Wed Jul 13 07:41:58 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 13 Jul 2022 07:41:58 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 22:33:47 GMT, Nir Lisker wrote: > I've finished an analysis of a few of the cases here. After checking the [JLS](https://docs.oracle.com/javase/specs/jls/se18/html/jls-9.html#jls-9.6.4.4), in my opinion this warning should be turned off without "fixing" its occurrences for the following reason: If a method in a supertype is not visible to a subtype, then it is an implementation detail. Subtypes should not be concerned with the names of methods outside of their visibility (whether in the hierarchy or not). If a method is supposed to override another method, then the `@Override` annotation should be used. This will give the definitiveness of overriding - if the method really is overriding, nothing else is needed; if it isn't, a compiler error occurs. > > Therefore, my recommendation is to fix all "method x is overriding method y but does not have the `@Override` annotation" warnings (I have my Eclipse set to treat missing override annotations as an error even, and it has served me well). Once all overriding methods are annotated and all non-overriding methods are not annotated, this warning becomes meaningless. Eclipse user here. I have most of the name shadowing conflicts off, for precisely the reason that I should not have to care about whether or not something that is (package) private happens to coincide with a supertype or enclosing type. When writing a new (package) private method, trying to avoid a name that happens to be used in a super or enclosing type doesn't even come into play -- it is private for a reason. Not to mention that a new method added to the super or enclosing type might suddenly cause "warnings" for (package) private methods in a sub or nested type, which is ridiculous. Instead, use `@Override` always, and make it an error if it is missing. These compiler warning settings are more than likely just a left over from the days before `@Override` existed. ------------- PR: https://git.openjdk.org/jfx/pull/824 From jpereda at openjdk.org Wed Jul 13 07:44:52 2022 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 13 Jul 2022 07:44:52 GMT Subject: RFR: 8284676: TreeTableView loses sort ordering when applied on empty table [v2] In-Reply-To: References: Message-ID: <2L15f1clGIpU-B_K5ob2JK0iqbQ1TtlJcPtqxsyju0E=.fad418c1-221a-4fb0-8c98-10732d8d67a5@github.com> On Wed, 13 Jul 2022 05:06:45 GMT, Ambarish Rapte wrote: >> Issue: In a TreeTableView if root item has no children then TreeTableView does not retain if a sort order is set. >> >> Cause: This is a regression of fix for [JDK-8256283](https://bugs.openjdk.org/browse/JDK-8256283), which returned false from `SortPolicy.call()` function if root item has no children. This function is called from `TreeTableView.sort()` line #1863. When the returned value is false then line #1885 gets executed, which removes the sort order that was added. >> >> Fix: The fix for [JDK-8256283](https://bugs.openjdk.org/browse/JDK-8256283) is modified to return true instead. Added a test that fails without and passes with fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > review comment: correct test name Marked as reviewed by jpereda (Committer). ------------- PR: https://git.openjdk.org/jfx/pull/825 From nlisker at openjdk.org Wed Jul 13 09:31:23 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 13 Jul 2022 09:31:23 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 07:35:06 GMT, John Hendrikx wrote: > These compiler warning settings are more than likely just a left over from the days before `@Override` existed. My thoughts as well. `@Override` was added in 1.5. I think this warning was added prior. ------------- PR: https://git.openjdk.org/jfx/pull/824 From nlisker at openjdk.org Wed Jul 13 11:01:18 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 13 Jul 2022 11:01:18 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: <0jM9mAv00k42mO6TeqDthMt0xCVIY4ulJwb-HDS2f8M=.ba6e4342-308b-4a53-9759-89261143a602@github.com> On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private I turned on errors on missing `@Override` annotations. I got over 1k errors. I think it's worth fixing it in batches. ------------- PR: https://git.openjdk.org/jfx/pull/824 From craigraw at gmail.com Wed Jul 13 11:31:24 2022 From: craigraw at gmail.com (Craig Raw) Date: Wed, 13 Jul 2022 13:31:24 +0200 Subject: TreeTableView inefficiency In-Reply-To: References: Message-ID: It appears that my initial email (below) did not make it into the list archive. However, I have now found the relevant issue: https://bugs.openjdk.org/browse/JDK-8280442 I want to note however that the presented workaround of using getTableRow().isVisible() does not work in general. I find that if one has a context menu on the cell with an action that causes the TreeTableView to be hidden, when one returns to the table the display is incorrect with rows in the wrong place. I have additionally added a check to see if the last time updateItem was called, it was called with the same TreeTableCell object, and to avoid any computation if that is the case - this appears to work. private static EntryCell lastCell; @Override protected void updateItem(Entry entry, boolean empty) { super.updateItem(entry, empty); //Return immediately to avoid CPU usage when updating the same invisible cell to determine tableview size (see https://bugs.openjdk.org/browse/JDK-8280442) if(this == lastCell && !getTableRow().isVisible()) { return; } lastCell = this; //computation.... } Craig On Tue, Jul 12, 2022 at 4:34 PM Craig Raw wrote: > Hi all, > > I'm observing behaviour in TreeTableView (and, I assume, TableView) that > is strange and seems to me to be inefficient for tables with many rows. > > On initially displaying the table, the behaviour is as I would expect - a > number of instances of TreeTableCell objects are created, and updateItem > is called on them. There are some repeat calls on the same TreeTableCell > object, but the number of calls is small compared to the number of items in > the data model. > > However, any interaction, however minor, with the scrollbar of the table > (either user or programmatic) causes updateItem to be called on the same > TreeTableCell object for every item in the underlying data model. With a > model with thousands of data rows, this results in several minutes of CPU > usage doing nothing of apparent use, creating and overwriting the same > text, graphic, tooltip and contextmenu member variables on the same object > for each data row. > > Once this is completed, the table seems to revert to normal behaviour - > any new rows that are scrolled into view results in a small number of > updateItem calls on new TreeTableCell objects commensurate with the > number of rows revealed. > > I have reproduced this on MacOS, Linux and Windows using JavaFX 18. > > Is this behaviour expected? If not, are there any workarounds? > > Thanks, > Craig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Wed Jul 13 11:40:08 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Jul 2022 11:40:08 GMT Subject: RFR: 8284676: TreeTableView loses sort ordering when applied on empty table [v2] In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 05:06:45 GMT, Ambarish Rapte wrote: >> Issue: In a TreeTableView if root item has no children then TreeTableView does not retain if a sort order is set. >> >> Cause: This is a regression of fix for [JDK-8256283](https://bugs.openjdk.org/browse/JDK-8256283), which returned false from `SortPolicy.call()` function if root item has no children. This function is called from `TreeTableView.sort()` line #1863. When the returned value is false then line #1885 gets executed, which removes the sort order that was added. >> >> Fix: The fix for [JDK-8256283](https://bugs.openjdk.org/browse/JDK-8256283) is modified to return true instead. Added a test that fails without and passes with fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > review comment: correct test name Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/825 From kcr at openjdk.org Wed Jul 13 11:57:21 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Jul 2022 11:57:21 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: <4NoHc7igBh4hAbUO9feJS3Eqc9Jgyyj3i2YCF_lkss8=.6f1eddc2-a3d5-4879-999a-8d89d5242639@github.com> On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private Removing approval pending further discussion. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/824 From jvos at openjdk.org Wed Jul 13 13:30:15 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 13 Jul 2022 13:30:15 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 13:45:13 GMT, Marius Hanl wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> reverse one more expected/actual set of args. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1074: > >> 1072: lastHeight = -1; >> 1073: releaseCell(accumCell); >> 1074: // accumCell = null; > > Is this intentional or did you may forgot to add back this two lines of code? This is intentional -- it was already moved to comments, and there is no need to destroy the accumCell (releasing it is what we need) ------------- PR: https://git.openjdk.org/jfx/pull/808 From kevin.rushforth at oracle.com Wed Jul 13 14:35:44 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 13 Jul 2022 07:35:44 -0700 Subject: FINAL REMINDER: JavaFX 19 RDP1 starts tomorrow [was: Proposed schedule for JavaFX 19] In-Reply-To: References: Message-ID: <69d6cf7e-a4f8-7d07-470e-c9388cd6aa71@oracle.com> As a reminder, JavaFX 19 RDP1 starts tomorrow, July 14th. I will fork the 'jfx19' branch at 16:00 UTC. -- Kevin On 7/1/2022 3:43 PM, Kevin Rushforth wrote: > As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 19 starts on July > 14, 2022 at 16:00 UTC (09:00 Pacific time), which is a little less > than two weeks from now. > > During rampdown of JavaFX 19, the "master" branch of the jfx repo will > be open for JavaFX 20 fixes. > > Please allow sufficient time for any feature that needs a CSR. New > features should be far enough along in the review process that you can > finalize the CSR by Thursday, July 7, or it is likely to miss the > window for this release, in which case it can be targeted for JavaFX 20. > > We will follow the same process as in previous releases for getting > fixes into JavaFX 19 during rampdown. I'll send a message with > detailed information when we fork, but candidates for fixing during > RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc > bugs of any priority. Some small enhancements might be considered > during RDP1, but they require explicit approval; the bar will be high > for such requests. > > -- Kevin > > > On 5/9/2022 3:28 PM, Kevin Rushforth wrote: >> Here is the proposed schedule for JavaFX 19. >> >> RDP1: Jul 14, 2022 (aka ?feature freeze?) >> RDP2: Aug 4, 2022 >> Freeze: Aug 25, 2022 >> GA: Sep 13, 2022 >> >> We plan to fork a jfx19 stabilization branch at RDP1. The GA date is >> one week ahead of JDK 19, matching what we did for 18. >> >> 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 duke at openjdk.org Wed Jul 13 14:57:16 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 13 Jul 2022 14:57:16 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: <0jM9mAv00k42mO6TeqDthMt0xCVIY4ulJwb-HDS2f8M=.ba6e4342-308b-4a53-9759-89261143a602@github.com> References: <0jM9mAv00k42mO6TeqDthMt0xCVIY4ulJwb-HDS2f8M=.ba6e4342-308b-4a53-9759-89261143a602@github.com> Message-ID: On Wed, 13 Jul 2022 10:57:37 GMT, Nir Lisker wrote: > I turned on errors on missing `@Override` annotations. I got over 1k errors. I think it's worth fixing it in batches. missing @override is a different warning. people do tend not to use this annotation, so any legacy code base usually contains lots of those. same with synthetic accessors and unused imports. I am ok with fixing all warnings, but people who use other IDEs or the IDEs with these warnings suppressed are bound to introduce them again and again. ------------- PR: https://git.openjdk.org/jfx/pull/824 From duke at openjdk.org Wed Jul 13 15:01:18 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 13 Jul 2022 15:01:18 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 07:35:06 GMT, John Hendrikx wrote: > Instead, use `@Override` always, and make it an error if it is missing. These compiler warning settings are more than likely just a left over from the days before `@Override` existed. right, however @Override is not missing in the case of BaseShaderGraphics. I'd rather fix both warnings. ------------- PR: https://git.openjdk.org/jfx/pull/824 From arapte at openjdk.org Wed Jul 13 15:06:14 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 13 Jul 2022 15:06:14 GMT Subject: Integrated: 8284676: TreeTableView loses sort ordering when applied on empty table In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 15:59:17 GMT, Ambarish Rapte wrote: > Issue: In a TreeTableView if root item has no children then TreeTableView does not retain if a sort order is set. > > Cause: This is a regression of fix for [JDK-8256283](https://bugs.openjdk.org/browse/JDK-8256283), which returned false from `SortPolicy.call()` function if root item has no children. This function is called from `TreeTableView.sort()` line #1863. When the returned value is false then line #1885 gets executed, which removes the sort order that was added. > > Fix: The fix for [JDK-8256283](https://bugs.openjdk.org/browse/JDK-8256283) is modified to return true instead. Added a test that fails without and passes with fix. This pull request has now been integrated. Changeset: 0132ac89 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/0132ac89033334ec9d9ec6149d116e8c352f89ec Stats: 15 lines in 2 files changed: 14 ins; 0 del; 1 mod 8284676: TreeTableView loses sort ordering when applied on empty table Reviewed-by: kcr, jpereda ------------- PR: https://git.openjdk.org/jfx/pull/825 From jhendrikx at openjdk.org Wed Jul 13 15:17:12 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 13 Jul 2022 15:17:12 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: <4midXbo2apS9X83ZhADgVurqOKyRfpIvP3laqWUFu9U=.bdcac33f-c935-43b7-aa8f-ed2fb5faff05@github.com> On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private > > I turned on errors on missing `@Override` annotations. I got over 1k errors. I think it's worth fixing it in batches. > > missing @OverRide is a different warning. people do tend not to use this annotation, so any legacy code base usually contains lots of those. same with synthetic accessors and unused imports. You perhaps mean that old code bases may have many places where this is not done, but new code written by professional developers without `@Override` seems highly suspect as it is a very valuable annotation, especially during refactors and method renames -- the IDE will warn you if for some reason a method is declared overridden but doesn't override anything, very handy when an overridden method was renamed and you forgot one of its subclasses where it was overridden. Unused imports, just reorganize them one time project wide (same for `@Override`, it's a safe change). Synthetic accessors, aside from making call stacks a little uglier, they don't really need attention at all (they're not a performance issue in modern JVM's). > I am ok with fixing all warnings, but people who use other IDEs or the IDEs with these warnings suppressed are bound to introduce them again and again. Missing overrides should be signaled in code reviews and/or automated. All IDE's support this and so they should just be configured properly. In my experience, I haven't seen code with missing `@Override`s unless the code base is incredibly old -- I'm a warning fixer myself, and I prefer to keep the warning list empty, so I would certainly have noticed this. Making JavaFX warning free would be a very good step, especially since some of the warnings can actually point to real issues. Eclipse makes such missing annotations (or other dubious constructs) painfully obvious with its clear and direct list of errors and warnings project wide. IntelliJ makes this a lot harder and is often (in my experience) a "source" of new warnings because people are not made aware of them explicitly enough. That is however no excuse for allowing such warnings to accumulate in the code base. ------------- PR: https://git.openjdk.org/jfx/pull/824 From duke at openjdk.org Wed Jul 13 15:31:17 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 13 Jul 2022 15:31:17 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: <4midXbo2apS9X83ZhADgVurqOKyRfpIvP3laqWUFu9U=.bdcac33f-c935-43b7-aa8f-ed2fb5faff05@github.com> References: <4midXbo2apS9X83ZhADgVurqOKyRfpIvP3laqWUFu9U=.bdcac33f-c935-43b7-aa8f-ed2fb5faff05@github.com> Message-ID: On Wed, 13 Jul 2022 15:15:10 GMT, John Hendrikx wrote: >> The fix includes: >> - renaming of offending methods to avoid confusion >> - explicitly declaring the offending methods as private > >> > I turned on errors on missing `@Override` annotations. I got over 1k errors. I think it's worth fixing it in batches. >> >> missing @OverRide is a different warning. people do tend not to use this annotation, so any legacy code base usually contains lots of those. same with synthetic accessors and unused imports. > > You perhaps mean that old code bases may have many places where this is not done, but new code written by professional developers without `@Override` seems highly suspect as it is a very valuable annotation, especially during refactors and method renames -- the IDE will warn you if for some reason a method is declared overridden but doesn't override anything, very handy when an overridden method was renamed and you forgot one of its subclasses where it was overridden. > > Unused imports, just reorganize them one time project wide (same for `@Override`, it's a safe change). > > Synthetic accessors, aside from making call stacks a little uglier, they don't really need attention at all (they're not a performance issue in modern JVM's). > >> I am ok with fixing all warnings, but people who use other IDEs or the IDEs with these warnings suppressed are bound to introduce them again and again. > > Missing overrides should be signaled in code reviews and/or automated. All IDE's support this and so they should just be configured properly. In my experience, I haven't seen code with missing `@Override`s unless the code base is incredibly old -- I'm a warning fixer myself, and I prefer to keep the warning list empty, so I would certainly have noticed this. Making JavaFX warning free would be a very good step, especially since some of the warnings can actually point to real issues. > > Eclipse makes such missing annotations (or other dubious constructs) painfully obvious with its clear and direct list of errors and warnings project wide. IntelliJ makes this a lot harder and is often (in my experience) a "source" of new warnings because people are not made aware of them explicitly enough. That is however no excuse for allowing such warnings to accumulate in the code base. @hjohn : I wholeheartedly agree. Created JDK-8290244 to fix @override's at a later date, on a per-module basis. ------------- PR: https://git.openjdk.org/jfx/pull/824 From nlisker at openjdk.org Wed Jul 13 15:38:16 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 13 Jul 2022 15:38:16 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private I personally disabled the "does not override method in a different package" warning. The synthetic methods one I never had on and never knew existed even, I don't see any reason for it. Unused imports and missing `@Override`s should be fixed in my opinion. It's just that the fixes make a lot of noise and touch many files. The graphics module fix might need to be split up because it's huge. ------------- PR: https://git.openjdk.org/jfx/pull/824 From duke at openjdk.org Wed Jul 13 15:42:21 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 13 Jul 2022 15:42:21 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private I agree - we might want to leave synthetic methods as is and suppress the warning in Eclipse preferences, as the changes may not be trivial. ------------- PR: https://git.openjdk.org/jfx/pull/824 From prr at openjdk.org Wed Jul 13 16:05:42 2022 From: prr at openjdk.org (Phil Race) Date: Wed, 13 Jul 2022 16:05:42 GMT Subject: Integrated: 8288137: The set of available printers is not updated without application restart In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 22:23:55 GMT, Phil Race wrote: > This fixes the issue that the default printer or set of available printers is fixed from the first call to it in the lifetime of the application. > Now subsequent calls will check to see if there are changes. > A manual test is provided for verifying this - it requires you to add/remove printers at the system level to verify anything related to this fix. This pull request has now been integrated. Changeset: b9a1ec5d Author: Phil Race URL: https://git.openjdk.org/jfx/commit/b9a1ec5dc369f0f207c0d66557698a05ee4f52f5 Stats: 216 lines in 3 files changed: 199 ins; 3 del; 14 mod 8288137: The set of available printers is not updated without application restart Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/817 From duke at openjdk.org Wed Jul 13 19:55:39 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 13 Jul 2022 19:55:39 GMT Subject: RFR: 8289606: CustomSecurityManagerTest fails on Mac M1 Message-ID: - sampling at 1/3 of screen height instead of the very top to avoid hitting OS UI found on the newer Macs with a notch - change applies to all platforms ------------- Commit messages: - 8289606: fixed CustomSecurityManagerTest fails on Mac M1 Changes: https://git.openjdk.org/jfx/pull/826/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=826&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289606 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/826.diff Fetch: git fetch https://git.openjdk.org/jfx pull/826/head:pull/826 PR: https://git.openjdk.org/jfx/pull/826 From kcr at openjdk.org Wed Jul 13 20:25:16 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Jul 2022 20:25:16 GMT Subject: RFR: 8289606: CustomSecurityManagerTest fails on Mac M1 In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 19:48:21 GMT, Andy Goryachev wrote: > - sampling at 1/3 of screen height instead of the very top to avoid hitting OS UI found on the newer Macs with a notch > - change applies to all platforms Given what this test is trying to test, the proposed fix seems fine. I confirm that this test fails on my Mac M1 without the fix and passes with the fix. One thing I just spotted is that this test makes the same mistake as `MouseLocationOnScreenTest -- see [JDK-8289611](https://bugs.openjdk.org/browse/JDK-8289611) -- in that it uses the bounds rather than the visual bounds of the screen. You can either look into that as well, or leave it as a fix for another day. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/826 From duke at openjdk.org Wed Jul 13 20:59:08 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 13 Jul 2022 20:59:08 GMT Subject: Integrated: 8289606: CustomSecurityManagerTest fails on Mac M1 In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 19:48:21 GMT, Andy Goryachev wrote: > - sampling at 1/3 of screen height instead of the very top to avoid hitting OS UI found on the newer Macs with a notch > - change applies to all platforms This pull request has now been integrated. Changeset: eb8e9ef5 Author: Andy Goryachev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/eb8e9ef5c1d5da024734c0d43dad184e54c28f56 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod 8289606: CustomSecurityManagerTest fails on Mac M1 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/826 From kcr at openjdk.org Wed Jul 13 21:17:07 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Jul 2022 21:17:07 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v5] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 23:30:48 GMT, Marius Hanl wrote: >> Initialize the `(Tree)TableView` when creating the measure row. >> This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). >> >> With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. >> I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 >> >> Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does not the table and therefore installs some listener on it in order to fire corresponding edit events. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Enable tests again > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing > - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup > - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener > - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing The code change looks quite reasonable to me, but it would be good to get additional eyes on this. @aghaisas will also review it. @kleopatra do you have any thoughts on this? ------------- PR: https://git.openjdk.org/jfx/pull/805 From aghaisas at openjdk.org Thu Jul 14 07:18:13 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 14 Jul 2022 07:18:13 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: Message-ID: <8xmJDcGn_JMhqMqC8TzpFb7fbuv9irEWDei4zTyk0Co=.b3617048-fc42-48fa-95f7-5d3971f6f0a4@github.com> On Mon, 11 Jul 2022 13:59:36 GMT, Johan Vos wrote: >> In order to fix the issues reported in JDK-8089589, the VirtualFlow now uses the real sizes of the elements that are displayed. This allows for a more natural way of scrolling through lists that contain items of very different sizes. >> The algorithm that is used, does not calculate the size of each individual cell upfront, as that would be a major performance overhead (especially for large lists). Instead, we estimate the total size and the size of the individual cells based on the real measured size of a (growing) number of cells. >> >> There are a number of key variables that depend on this estimated size: >> * position >> * aboluteOffset >> * currentIndex >> >> As a consequence, when the estimated size is changing, the absoluteOffset may change which may lead to a new currentIndex. If this happens during a layout phase, or a "complex" operation (e.g. scroll to an item and select it), this may lead to visually unexpected artifacts. While the rendering becomes more "correct" when the estimated size is improving, it is more important that we do not create visual confusion. >> >> The difficulty is that there are a large number of ways to manipulate the VirtualFlow, and different entry points may have different expectations about which variables should be kept constant (or only changed gradually). >> >> In this PR, we focus on consistency in the scrollTo method, where we want to keep the top-cell constant. In case the estimated size is improved during the scrollTo execution, or the next layoutChildren invocation, this implies keeping the result of computeCurrentIndex() constant so that after scrolling to a cell and selecting it, the selected cell is indeed the one that is scrolled to. >> >> This PR contains a number of tests for this scrollTo behaviour, that should also be considered as regression test in case we want to add more invariants later. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > reverse one more expected/actual set of args. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/808 From fkirmaier at openjdk.org Thu Jul 14 08:05:25 2022 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 14 Jul 2022 08:05:25 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException [v5] In-Reply-To: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> References: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Message-ID: > Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. > ticket: https://bugs.openjdk.java.net/browse/JDK-8256397 > run test: `./gradlew --continue -PFULL_TEST=true controls:test --tests "*MultipleSelectionModelImplTest*"` Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK_8256397 Fixed more issues with the multiple selection model change events, and verified them with more unit-tests. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/353/files - new: https://git.openjdk.org/jfx/pull/353/files/3a4e2f0b..833afbb1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=353&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=353&range=03-04 Stats: 84 lines in 2 files changed: 52 ins; 20 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/353.diff Fetch: git fetch https://git.openjdk.org/jfx pull/353/head:pull/353 PR: https://git.openjdk.org/jfx/pull/353 From fkirmaier at openjdk.org Thu Jul 14 08:16:11 2022 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 14 Jul 2022 08:16:11 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException In-Reply-To: References: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Message-ID: On Sat, 2 Jul 2022 05:23:22 GMT, Michael Strau? wrote: >> good catch :) >> >> No review, just a couple of comments: >> >> - other subclasses of MultipleSelectionModelBase might have similar issues >> - the fix gets rid of the error (good!) but might fire incorrect changes (see below) >> - there are quite a lot of open issues related to change notification, some might profit from a fix of this >> - tests, tests, tests .. :) >> >> selectIndices might involve disjoint intervals in the change (even for addition which is unusual in the "normal" implementations of observableLists) >> >> // initial selection, starting from empty >> selectionModel.selectIndices(0, /*1, IMPORTANT: remove some index */ 2, 3); >> System.out.println(change); >> // expected and actual change >> { [0, 2, 3] added at 0 } >> >> // add selection of disjoint indices (assuming a longer items list) >> selectionModel.selectIndices(1, 5, 7); >> System.out.println(change); >> // actual >> { [1, 2, 3] added at 1 } >> // expected >> { [1] added at 1, [5, 7] added at 4 } > > I don't understand how the original code, as well as the proposed solution, can work at all. Let's take @kleopatra's example: > > selectionModel.selectIndices(0, 2, 3); > // ---> expected: { [0, 2, 3] added at 0 } > selectionModel.selectIndices(1, 5, 7); > // ---> expected: { [1] added at 1, [5, 7] added at 4 } > > In order to find the two sub-ranges `[1]` and `[5, 7]`, we need to compare the _newly added_ indices to the _entire_ list of selected indices. Without doing that, we can't just "know" that there are two contiguous sub-ranges in `[1, 5, 7]`. > > However, the algorithm that supposedly tries to do that, doesn't even look at the current list of selected indices (except for a single `indexOf` call, which doesn't do the trick): > > int pos = 0; > int start = 0; > int end = 0; > > // starting from pos, we keep going until the value is > // not the next value > int startValue = sortedNewIndices.get(pos++); > start = indexOf(startValue); > end = start + 1; > int endValue = startValue; > while (pos < size) { > int previousEndValue = endValue; > endValue = sortedNewIndices.get(pos++); > ++end; > if (previousEndValue != (endValue - 1)) { > _nextAdd(start, end); > start = end; > continue; > } > > // special case for when we get to the point where the loop is about to end > // and we have uncommitted changes to fire. > if (pos == size) { > _nextAdd(start, end); > } > } > > I think this algorithm mistakenly finds contiguous ranges within the list of _newly added_ indices, which is not what we want. > > Here is an algorithm that works: > > int startIndex = indexOf(sortedNewIndices.get(0)); > int endIndex = startIndex + 1; > > for (int i = 1; i < sortedNewIndices.size(); ++i) { > int currentValue = get(endIndex); > int currentNewValue = sortedNewIndices.get(i); > if (currentValue != currentNewValue) { > _nextAdd(startIndex, endIndex); > while (get(endIndex) != currentNewValue) ++endIndex; > startIndex = endIndex++; > } else { > ++endIndex; > } > > if (i == sortedNewIndices.size() - 1) { > _nextAdd(startIndex, endIndex); > } > } > > > Unfortunately, even with the working algorithm, the list change notifications are still not correct in all cases due to another (probably unrelated) bug in `SelectedIndicesList.get(int)`: If I remove the optimization that is implemented in that method, and replace it with a simple lookup, the notifications are always correct in my tests: > > @Override public Integer get(int index) { > for (int lastGetIndex = 0, lastGetValue = bitset.nextSetBit(0); > lastGetValue >= 0 || lastGetIndex == index; > lastGetIndex++, lastGetValue = bitset.nextSetBit(lastGetValue + 1)) { > if (lastGetIndex == index) { > return lastGetValue; > } > } > return -1; > } > > > Test 1: > > selectionModel.selectIndices(0, 2, 3); > // ---> { [0, 2, 3] added at 0 } > selectionModel.selectIndices(1, 5, 7); > // ---> { [1] added at 1, [5, 7] added at 4 } > > Test 2: > > selectionModel.selectIndices(1, 3, 4); > // ---> { [1, 3, 4] added at 0 } > selectionModel.selectIndices(0, 5, 7); > // ---> { [0] added at 0, [5, 7] added at 4 } > selectionModel.selectIndices(6, 8, 9); > // ---> { [6] added at 5, [8, 9] added at 7 } @mstr2 Thank you for the corrected version of the algorithm, and also for highlighting further bugs. I investigated the code a bit, and found the cause why the get method was so unreliable. It turned out, that the optimization in the get method only works when the bit-set is not changed. I've added some calls to the "reset" method, which resets the optimization when the bitset is changed. I've added the correction into the PR. I've also changed the tests, so we can easily test any case we come up with. Also all the tests you've provided are now part of the PR and are green! ------------- PR: https://git.openjdk.org/jfx/pull/353 From jvos at openjdk.org Thu Jul 14 09:44:35 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 14 Jul 2022 09:44:35 GMT Subject: Integrated: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 13:52:40 GMT, Johan Vos wrote: > In order to fix the issues reported in JDK-8089589, the VirtualFlow now uses the real sizes of the elements that are displayed. This allows for a more natural way of scrolling through lists that contain items of very different sizes. > The algorithm that is used, does not calculate the size of each individual cell upfront, as that would be a major performance overhead (especially for large lists). Instead, we estimate the total size and the size of the individual cells based on the real measured size of a (growing) number of cells. > > There are a number of key variables that depend on this estimated size: > * position > * aboluteOffset > * currentIndex > > As a consequence, when the estimated size is changing, the absoluteOffset may change which may lead to a new currentIndex. If this happens during a layout phase, or a "complex" operation (e.g. scroll to an item and select it), this may lead to visually unexpected artifacts. While the rendering becomes more "correct" when the estimated size is improving, it is more important that we do not create visual confusion. > > The difficulty is that there are a large number of ways to manipulate the VirtualFlow, and different entry points may have different expectations about which variables should be kept constant (or only changed gradually). > > In this PR, we focus on consistency in the scrollTo method, where we want to keep the top-cell constant. In case the estimated size is improved during the scrollTo execution, or the next layoutChildren invocation, this implies keeping the result of computeCurrentIndex() constant so that after scrolling to a cell and selecting it, the selected cell is indeed the one that is scrolled to. > > This PR contains a number of tests for this scrollTo behaviour, that should also be considered as regression test in case we want to add more invariants later. This pull request has now been integrated. Changeset: b8302f64 Author: Johan Vos URL: https://git.openjdk.org/jfx/commit/b8302f64f49e746a8645020cb778a4f3e4f4b893 Stats: 372 lines in 4 files changed: 332 ins; 19 del; 21 mod 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed Reviewed-by: kcr, fkirmaier, aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/808 From fkirmaier at openjdk.org Thu Jul 14 10:23:10 2022 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 14 Jul 2022 10:23:10 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v6] In-Reply-To: References: Message-ID: > Making the initial listener of the ListProperty weak fixes the problem. > The same is fixed for Set and Map. > Due to a smart implementation, this is done without any performance drawback. > (The trick is to have an object, which is both the WeakReference and the Changelistener) > By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8277848 Added tests to ensure no premature garbage collection is happening. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/689/files - new: https://git.openjdk.org/jfx/pull/689/files/5294483b..b744a098 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=689&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=689&range=04-05 Stats: 66 lines in 3 files changed: 66 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/689.diff Fetch: git fetch https://git.openjdk.org/jfx pull/689/head:pull/689 PR: https://git.openjdk.org/jfx/pull/689 From fkirmaier at openjdk.org Thu Jul 14 10:23:11 2022 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 14 Jul 2022 10:23:11 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v5] In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 14:44:03 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8277848 >> Added 3 more tests to verify that a bug discussed in the PR does not appear. > > This will require careful review and testing to make sure that we don't introduce any cases where the binding disappears too soon. The main thing we need to be careful about is that we don't take any cases that work reliably today (albeit at the cost of a memory leak) and make them subject to premature garbage collection. I also agree that it seems out of scope to introduce laziness into this existing API. Changing the implementation to use lazy bindings under-the-covers would be acceptable, but only if it caused no app-visible change in behavior. @kevinrushforth Yes, premature collection is quite a problem with weak binding, but luckily this can also be checked with unit tests. So I've added a unit test to verify, that the binding doesn't get collected prematurely. What we can't test, is whether some applications (or the internal JavaFX code) rely on the memory leak itself. But I guess that is how one can argue with any bug. ------------- PR: https://git.openjdk.org/jfx/pull/689 From lbourges at openjdk.org Thu Jul 14 13:15:56 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Thu, 14 Jul 2022 13:15:56 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v3] In-Reply-To: <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> Message-ID: <3QyFJJ00hCa3YXxvC28ZN_ylIjcmAS1ulppJmht8YAo=.377fa8e0-2f6e-4ce0-9c7c-64a72b0af423@github.com> On Thu, 7 Jul 2022 22:46:53 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > fixed pixel color tests on hi-dpi This PR corresponds to Marlin-FX 0.9.4.5 released in oct 2021, it is all good to go! Allright, just tell me when you will have time to review this large patch, I will be ready (on vacation between 07.22 and 08.22, but online and working on new bug fixes as no hurry). Bye, Laurent ------------- PR: https://git.openjdk.org/jfx/pull/674 From jhendrikx at openjdk.org Thu Jul 14 14:54:56 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 14 Jul 2022 14:54:56 GMT Subject: RFR: 8290037: Bindings should clean up after themselves when their weak listeners go out of scope Message-ID: This is an initial (incomplete) implementation of 8290037 for evaluation. If the approach is agreed, I will modify the rest of the `*PropertyBase` classes which use weak listeners, and add some tests. I didn't use `Cleaner` because cleaning up a listener may block. ------------- Commit messages: - Initial (incomplete) implementation for evaluation Changes: https://git.openjdk.org/jfx/pull/827/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=827&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290037 Stats: 192 lines in 4 files changed: 176 ins; 4 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/827.diff Fetch: git fetch https://git.openjdk.org/jfx pull/827/head:pull/827 PR: https://git.openjdk.org/jfx/pull/827 From kcr at openjdk.org Thu Jul 14 15:29:32 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Jul 2022 15:29:32 GMT Subject: RFR: 8290037: Bindings should clean up after themselves when their weak listeners go out of scope In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 14:48:14 GMT, John Hendrikx wrote: > This is an initial (incomplete) implementation of 8290037 for evaluation. > > If the approach is agreed, I will modify the rest of the `*PropertyBase` classes which use weak listeners, and add some tests. > > I didn't use `Cleaner` because cleaning up a listener may block. If we go this route it warrants updates to the API docs to describe the behavioral changes being introduced. Specifically, the synchronizing of the add / remove listener methods and any changes to the lifecycle of the bindings. ------------- PR: https://git.openjdk.org/jfx/pull/827 From kcr at openjdk.org Thu Jul 14 16:04:18 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Jul 2022 16:04:18 GMT Subject: Integrated: 8289835: Change JavaFX release version to 20 In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 19:22:26 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 20. I will integrate this to `master` as part of forking the `jfx19` stabilization branch, which is scheduled for Thursday, July 14, 2022 at 16:00 UTC. This pull request has now been integrated. Changeset: b5e40496 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/b5e40496883e5aa5faa10f11208df3b595b320c9 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod 8289835: Change JavaFX release version to 20 Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/820 From kevin.rushforth at oracle.com Thu Jul 14 16:12:51 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 14 Jul 2022 09:12:51 -0700 Subject: JavaFX 19 is in Rampdown Phase One (RDP1) Message-ID: <9912781c-2146-b25b-b5b3-a16ce2cba744@oracle.com> ?JavaFX 19 is now in Rampdown Phase One (RDP1) [1]. We have forked a new jfx19 branch [2] for stabilizing the JavaFX 19 release. Here is the short summary of what this means: - The master branch of the jfx repo is available for integrating bug fixes or enhancements for openjfx20. Most fixes will be integrated to master for 20. - The jfx19 branch of the jfx repo is now open for integrating fixes for openjfx19 that meet the RDP1 criteria as outlined below. - Reviewers and Committers now have an additional responsibility to verify the target branch of each pull request. - I will periodically sync jfx19 --> master, meaning that developers should integrate fixes to one or the other, not both DETAILS: P1-P3 bug fixes, and test or doc fixes of any priority are good candidates for integrating to jfx19 during RDP1. The only hard restriction is that enhancements need explicit approval, over and above the review of the PR, to go into jfx19. The bar for such approval is appropriately high. We also need to be careful to avoid potentially risky fixes during this time. Note that these restrictions apply to the jfx19 branch. The master branch is open for all openjfx20 fixes, including enhancements. As a reminder, we use a single openjdk/jfx GitHub repo with stabilization branches [3] rather than a separate stabilization repo. The jfx19 branch is used to stabilize the upcoming openjfx19 release. Please be aware of this, especially if you are a Reviewer or Committer in the Project. This allows all pull requests to be in the same place, but care needs to be taken for any PR that is targeted to jfx19 to ensure that it doesn't contain any commits from master after the jfx19 fork date. What that means is that if you intend a PR to be for jfx19, don't merge master into your local source branch! IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (OpenJFX 20 as of today). This is usually what we want. A PR should be targeted to `jfx19` if, and only if, it is intended for OpenJFX 19 and meets the criteria for the current rampdown phase (we're in RDP1 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx19`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 20. Reviewers also need to be extra careful when reviewing PRs targeted to jfx19 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed. We will use the same rules for RDP1 that the JDK uses [4], with the same three modifications we did for the previous release: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 19 release. As an obvious choice, derived from the JBS fix version, we will use "openjfx19-enhancement-request", "openjfx19-enhancement-yes", "openjfx19-enhancement-no" and "openjfx19-enhancement-nmi" as corresponding labels. 3. No explicit approval (no JBS label) is needed to integrate P4 bugs to the jfx19 branch during RDP1, as long as those bugs have otherwise met the usual code review criteria. Having said that, most P4 bugs should now go into master for openjfx20, since we do not want to risk anything that would destabilize the openjfx19 release without a compelling reason. Also, we have only 3 weeks until RDP2 of openjfx19 and we would be better served fixing higher priority bugs. Note that doc bugs and test bugs of any priority are fine to fix for openjfx19 during this time. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2022-May/034217.html [2] https://github.com/openjdk/jfx/tree/jfx19 [3] https://github.com/openjdk/jfx/branches/all [4] http://openjdk.org/jeps/3 From jhendrikx at openjdk.org Thu Jul 14 19:43:16 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 14 Jul 2022 19:43:16 GMT Subject: RFR: 8290037: Bindings should clean up after themselves when their weak listeners go out of scope In-Reply-To: References: Message-ID: <8MQxfAUQ55ZndAw_RYpzyLHy2f3W3pvtNzasW8kuhqA=.6754ae1c-d685-4b37-9fe1-40fd8877c26f@github.com> On Thu, 14 Jul 2022 14:48:14 GMT, John Hendrikx wrote: > This is an initial (incomplete) implementation of 8290037 for evaluation. > > If the approach is agreed, I will modify the rest of the `*PropertyBase` classes which use weak listeners, and add some tests. > > I didn't use `Cleaner` because cleaning up a listener may block. > If we go this route it warrants updates to the API docs to describe the behavioral changes being introduced. Specifically, the synchronizing of the add / remove listener methods and any changes to the lifecycle of the bindings. > > /reviewers 2 /csr Ah, I was hoping this was one of the routes without requiring a csr. Perhaps it needs a rethink. ------------- PR: https://git.openjdk.org/jfx/pull/827 From jhendrikx at openjdk.org Thu Jul 14 19:48:04 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 14 Jul 2022 19:48:04 GMT Subject: RFR: 8290037: Bindings should clean up after themselves when their weak listeners go out of scope [v2] In-Reply-To: References: Message-ID: > This is an initial (incomplete) implementation of 8290037 for evaluation. > > If the approach is agreed, I will modify the rest of the `*PropertyBase` classes which use weak listeners, and add some tests. > > I didn't use `Cleaner` because cleaning up a listener may block. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Made accidental public field private ------------- Changes: - all: https://git.openjdk.org/jfx/pull/827/files - new: https://git.openjdk.org/jfx/pull/827/files/c2a15137..e2e516a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=827&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=827&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/827.diff Fetch: git fetch https://git.openjdk.org/jfx pull/827/head:pull/827 PR: https://git.openjdk.org/jfx/pull/827 From duke at openjdk.org Thu Jul 14 21:01:37 2022 From: duke at openjdk.org (Andy Goryachev) Date: Thu, 14 Jul 2022 21:01:37 GMT Subject: RFR: 8289611: MouseLocationOnScreenTest sometimes fails on Mac M1 Message-ID: - using Screen.getVisualBounds() instead of Screen.getBounds() ------------- Commit messages: - 8289611: MouseLocationOnScreenTest sometimes fails on Mac M1 Changes: https://git.openjdk.org/jfx/pull/828/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=828&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289611 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/828.diff Fetch: git fetch https://git.openjdk.org/jfx pull/828/head:pull/828 PR: https://git.openjdk.org/jfx/pull/828 From jhendrikx at openjdk.org Thu Jul 14 23:42:59 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 14 Jul 2022 23:42:59 GMT Subject: [jfx19] RFR: 8290331 Binding value left null when immediately revalidated in invalidation listener Message-ID: I introduced a bug with the fluent bindings PR which affects all ObjectBindings. This is the code that fails: SimpleObjectProperty condition = new SimpleObjectProperty<>(true); ObservableValue binding = condition.map(Object::toString); binding.addListener(o -> { binding.getValue(); }); condition.set(false); assertEquals(false, binding.getValue()); // returns null (!) This PR fixes this problem and adds a test case to cover it. ------------- Commit messages: - Fix bug where ObjectBinding returns null when revalidated immediately Changes: https://git.openjdk.org/jfx/pull/829/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=829&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290331 Stats: 22 lines in 2 files changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/829.diff Fetch: git fetch https://git.openjdk.org/jfx pull/829/head:pull/829 PR: https://git.openjdk.org/jfx/pull/829 From kcr at openjdk.org Thu Jul 14 23:59:12 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Jul 2022 23:59:12 GMT Subject: [jfx19] RFR: 8290331 Binding value left null when immediately revalidated in invalidation listener In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 23:37:31 GMT, John Hendrikx wrote: > I introduced a bug with the fluent bindings PR which affects all ObjectBindings. > > This is the code that fails: > > SimpleObjectProperty condition = new SimpleObjectProperty<>(true); > ObservableValue binding = condition.map(Object::toString); > > binding.addListener(o -> { binding.getValue(); }); > > condition.set(false); > > assertEquals(false, binding.getValue()); // returns null (!) > > This PR fixes this problem and adds a test case to cover it. Good catch. And yes, this needs to go into JavaFX 19. ------------- PR: https://git.openjdk.org/jfx/pull/829 From mstrauss at openjdk.org Fri Jul 15 01:03:57 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 15 Jul 2022 01:03:57 GMT Subject: [jfx19] RFR: 8290331 Binding value left null when immediately revalidated in invalidation listener In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 23:37:31 GMT, John Hendrikx wrote: > I introduced a bug with the fluent bindings PR which affects all ObjectBindings. > > This is the code that fails: > > SimpleObjectProperty condition = new SimpleObjectProperty<>(true); > ObservableValue binding = condition.map(Object::toString); > > binding.addListener(o -> { binding.getValue(); }); > > condition.set(false); > > assertEquals(false, binding.getValue()); // returns null (!) > > This PR fixes this problem and adds a test case to cover it. Looks good to me. ------------- Marked as reviewed by mstrauss (Author). PR: https://git.openjdk.org/jfx/pull/829 From mstrauss at openjdk.org Fri Jul 15 01:11:51 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 15 Jul 2022 01:11:51 GMT Subject: [jfx19] RFR: 8290331 Binding value left null when immediately revalidated in invalidation listener In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 23:37:31 GMT, John Hendrikx wrote: > I introduced a bug with the fluent bindings PR which affects all ObjectBindings. > > This is the code that fails: > > SimpleObjectProperty condition = new SimpleObjectProperty<>(true); > ObservableValue binding = condition.map(Object::toString); > > binding.addListener(o -> { binding.getValue(); }); > > condition.set(false); > > assertEquals(false, binding.getValue()); // returns null (!) > > This PR fixes this problem and adds a test case to cover it. modules/javafx.base/src/main/java/javafx/beans/binding/ObjectBinding.java line 184: > 182: ExpressionHelper.fireValueChangedEvent(helper); > 183: > 184: if (!valid) { // if still invalid after calling listeners... On a personal note: I think implementation comments are best presented as a block, and not describing individual lines of code. That makes it a bit easier for future authors to work with the code. But that's just my two cents ? ------------- PR: https://git.openjdk.org/jfx/pull/829 From jhendrikx at openjdk.org Fri Jul 15 07:19:19 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 15 Jul 2022 07:19:19 GMT Subject: [jfx19] RFR: 8290331 Binding value left null when immediately revalidated in invalidation listener [v2] In-Reply-To: References: Message-ID: <8CqWcI0hfQMyw0CoIgiUNkWiaxfn2bXpSCe3fYMCVBc=.1358ca1a-6f6b-4d0d-8f5b-39fd99d4fa6c@github.com> > I introduced a bug with the fluent bindings PR which affects all ObjectBindings. > > This is the code that fails: > > SimpleObjectProperty condition = new SimpleObjectProperty<>(true); > ObservableValue binding = condition.map(Object::toString); > > binding.addListener(o -> { binding.getValue(); }); > > condition.set(false); > > assertEquals(false, binding.getValue()); // returns null (!) > > This PR fixes this problem and adds a test case to cover it. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Change explanatory comment to block comment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/829/files - new: https://git.openjdk.org/jfx/pull/829/files/4c8453af..34856569 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=829&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=829&range=00-01 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/829.diff Fetch: git fetch https://git.openjdk.org/jfx pull/829/head:pull/829 PR: https://git.openjdk.org/jfx/pull/829 From jhendrikx at openjdk.org Fri Jul 15 07:19:21 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 15 Jul 2022 07:19:21 GMT Subject: [jfx19] RFR: 8290331 Binding value left null when immediately revalidated in invalidation listener [v2] In-Reply-To: References: Message-ID: <5jH1cEfM1Ev683-R59XcTFhD0L3kJJaKrx-bydg3Frc=.e2dcfea8-3624-4ab1-9ca0-98489f433048@github.com> On Fri, 15 Jul 2022 01:08:46 GMT, Michael Strau? wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Change explanatory comment to block comment > > modules/javafx.base/src/main/java/javafx/beans/binding/ObjectBinding.java line 184: > >> 182: ExpressionHelper.fireValueChangedEvent(helper); >> 183: >> 184: if (!valid) { // if still invalid after calling listeners... > > On a personal note: I think implementation comments are best presented as a block, and not describing individual lines of code. That makes it a bit easier for future authors to work with the code. But that's just my two cents ? I like block comments as well, I'll change it. ------------- PR: https://git.openjdk.org/jfx/pull/829 From mstrauss at openjdk.org Fri Jul 15 08:53:22 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 15 Jul 2022 08:53:22 GMT Subject: [jfx19] RFR: 8290331 Binding value left null when immediately revalidated in invalidation listener [v2] In-Reply-To: <8CqWcI0hfQMyw0CoIgiUNkWiaxfn2bXpSCe3fYMCVBc=.1358ca1a-6f6b-4d0d-8f5b-39fd99d4fa6c@github.com> References: <8CqWcI0hfQMyw0CoIgiUNkWiaxfn2bXpSCe3fYMCVBc=.1358ca1a-6f6b-4d0d-8f5b-39fd99d4fa6c@github.com> Message-ID: On Fri, 15 Jul 2022 07:19:19 GMT, John Hendrikx wrote: >> I introduced a bug with the fluent bindings PR which affects all ObjectBindings. >> >> This is the code that fails: >> >> SimpleObjectProperty condition = new SimpleObjectProperty<>(true); >> ObservableValue binding = condition.map(Object::toString); >> >> binding.addListener(o -> { binding.getValue(); }); >> >> condition.set(false); >> >> assertEquals(false, binding.getValue()); // returns null (!) >> >> This PR fixes this problem and adds a test case to cover it. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Change explanatory comment to block comment Marked as reviewed by mstrauss (Author). ------------- PR: https://git.openjdk.org/jfx/pull/829 From jhendrikx at openjdk.org Fri Jul 15 09:13:30 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 15 Jul 2022 09:13:30 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners Message-ID: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. ------------- Commit messages: - Add conditional bindings to ObservableValue - Change explanatory comment to block comment - Fix bug where ObjectBinding returns null when revalidated immediately Changes: https://git.openjdk.org/jfx/pull/830/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290040 Stats: 587 lines in 7 files changed: 576 ins; 8 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/830.diff Fetch: git fetch https://git.openjdk.org/jfx pull/830/head:pull/830 PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Fri Jul 15 09:13:31 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 15 Jul 2022 09:13:31 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners In-Reply-To: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Fri, 15 Jul 2022 09:03:35 GMT, John Hendrikx wrote: > This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. > > It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). > > Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: > > label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); > > The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. > > The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. > > Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. > > (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 311: > 309: * @since 20 > 310: */ > 311: default ObservableValue when(ObservableValue condition) { Discussion: name? `when`, `conditionOn`, other suggestions? Note that this is not the same as a possible future method `filter`, as a `filter` would still keep observing its source at all times (and would use a `Predicate` as parameter). modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1422: > 1420: } > 1421: > 1422: public final ReadOnlyBooleanProperty showingProperty() { Discussion: Note I had to wrap the `ObservableValue` to become a `ReadOnlyBooleanProperty`, even though `ObservableValue` is already read-only and quite usable without the wrapper. I would have preferred to just have the showing property signature be: ObservableValue showingProperty(); However, I think it would not be detected as a JavaFX property then, and it would also break with the tradition that properties are, well, properties. Thoughts? ------------- PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Fri Jul 15 09:27:00 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 15 Jul 2022 09:27:00 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v2] In-Reply-To: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: > This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. > > It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). > > Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: > > label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); > > The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. > > The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. > > Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. > > (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Rename showing property to shown as it is already used in subclasses ------------- Changes: - all: https://git.openjdk.org/jfx/pull/830/files - new: https://git.openjdk.org/jfx/pull/830/files/a70161cb..fd19fc36 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=00-01 Stats: 34 lines in 3 files changed: 0 ins; 0 del; 34 mod Patch: https://git.openjdk.org/jfx/pull/830.diff Fetch: git fetch https://git.openjdk.org/jfx pull/830/head:pull/830 PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Fri Jul 15 09:27:02 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 15 Jul 2022 09:27:02 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v2] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Fri, 15 Jul 2022 09:23:20 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Rename showing property to shown as it is already used in subclasses modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1422: > 1420: } > 1421: > 1422: public final ReadOnlyBooleanProperty shownProperty() { Discussion: Note I had to wrap the ObservableValue to become a ReadOnlyBooleanProperty, even though ObservableValue is already read-only and quite usable without the wrapper. I would have preferred to just have the shown property signature be: ObservableValue shownProperty(); Or even better: ObservableValue shown(); However, I think it would not be detected as a JavaFX property then, and it would also break with the tradition that properties are, well, properties. Thoughts? ------------- PR: https://git.openjdk.org/jfx/pull/830 From fastegal at swingempire.de Fri Jul 15 09:44:06 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 15 Jul 2022 11:44:06 +0200 Subject: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader Message-ID: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> Hi, after synching my master branch with upstream (has been a long while since my previous update ;), I can't use the Eclipse projects (base, controls, graphics are the only ones I'm keeping for change in Eclipse) in another project: when running any application it's throwing the stacktrace below. My overall setup worked fine before (didn't dig yet when it started not to), running the tests inside the fx projects themselves is fine, though. Looks like there is something missing (native?) related to graphics. Where to start looking for the reason? Stacktrace: java.lang.ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:332) at javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) at javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) at javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) at javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) at java.base/java.lang.Thread.run(Thread.java:835) java.lang.InternalError: Error loading stock shader FillPgram_Color at javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) at javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) at javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) at javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) at java.base/java.lang.Thread.run(Thread.java:835) -- Thanks, Jeanette From nlisker at gmail.com Fri Jul 15 09:51:11 2022 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 15 Jul 2022 12:51:11 +0300 Subject: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> Message-ID: The Eclipse project files were updated recently in https://github.com/openjdk/jfx/pull/804. The OS-specific folders were removed. I tested it and I had no issue after this change. On what resource are you getting this error? On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < fastegal at swingempire.de> wrote: > > Hi, > > after synching my master branch with upstream (has been a long while > since my previous update ;), I can't use the Eclipse projects (base, > controls, graphics are the only ones I'm keeping for change in > Eclipse) in another project: when running any application it's > throwing the stacktrace below. > > My overall setup worked fine before (didn't dig yet when it started > not to), running the tests inside the fx projects themselves is fine, > though. > > Looks like there is something missing (native?) related to graphics. > > Where to start looking for the reason? > > Stacktrace: > > java.lang.ClassNotFoundException: > com.sun.prism.shader.FillPgram_Color_Loader > at > > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) > at > > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:332) > at > > javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) > at > > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > at > > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > at > > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > at > > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > at > > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > at > > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > at > > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > at > > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > at > > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > at > > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > at > javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at > javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at > > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > at > > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > at > > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > at > > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > at > javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > at > > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > at java.base/java.lang.Thread.run(Thread.java:835) > java.lang.InternalError: Error loading stock shader FillPgram_Color > at > > javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) > at > > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > at > > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > at > > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > at > > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > at > > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > at > > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > at > > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > at > > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > at > > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > at > > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > at > javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at > javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at > > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > at > > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > at > > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > at > > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > at > javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > at > > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > at java.base/java.lang.Thread.run(Thread.java:835) > > -- Thanks, Jeanette > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Fri Jul 15 09:56:34 2022 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 15 Jul 2022 12:56:34 +0300 Subject: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> Message-ID: To be more specific, FillPgram_Color_Loader.java is located under the build/gensrc folder, which is created during the javafx setup depending on the OS. Specifically, it's under build/gensrc/jsl-prism, which is Windows-specific. The change to the classpath file removed these folders from the source folders list in the build path, so I don't know why you would get this error. Nothing in the "main" source folders references these in compile- or build-time. On Fri, Jul 15, 2022 at 12:51 PM Nir Lisker wrote: > The Eclipse project files were updated recently in > https://github.com/openjdk/jfx/pull/804. The OS-specific folders were > removed. I tested it and I had no issue after this change. On what resource > are you getting this error? > > On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < > fastegal at swingempire.de> wrote: > >> >> Hi, >> >> after synching my master branch with upstream (has been a long while >> since my previous update ;), I can't use the Eclipse projects (base, >> controls, graphics are the only ones I'm keeping for change in >> Eclipse) in another project: when running any application it's >> throwing the stacktrace below. >> >> My overall setup worked fine before (didn't dig yet when it started >> not to), running the tests inside the fx projects themselves is fine, >> though. >> >> Looks like there is something missing (native?) related to graphics. >> >> Where to start looking for the reason? >> >> Stacktrace: >> >> java.lang.ClassNotFoundException: >> com.sun.prism.shader.FillPgram_Color_Loader >> at >> >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) >> at >> >> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >> at java.base/java.lang.Class.forName0(Native Method) >> at java.base/java.lang.Class.forName(Class.java:332) >> at >> >> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >> at >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >> at >> >> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >> at >> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >> at >> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> at >> >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> at >> >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >> at java.base/java.lang.Thread.run(Thread.java:835) >> java.lang.InternalError: Error loading stock shader FillPgram_Color >> at >> >> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >> at >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >> at >> >> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >> at >> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >> at >> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> at >> >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> at >> >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >> at java.base/java.lang.Thread.run(Thread.java:835) >> >> -- Thanks, Jeanette >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From fastegal at swingempire.de Fri Jul 15 10:03:34 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 15 Jul 2022 12:03:34 +0200 Subject: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> Message-ID: <20220715120334.Horde.RB97PaiDh4JCnX2evfVCsOL@webmail.df.eu> Zitat von Nir Lisker : > The Eclipse project files were updated recently in > https://github.com/openjdk/jfx/pull/804. The OS-specific folders were > removed. I tested it and I had no issue after this change. On what resource > are you getting this error? > hmm .. don't understand the question, sry ;) But just noticed that reverting the change in .classpath in graphics seemed to fix it .. > On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < > fastegal at swingempire.de> wrote: > >> >> Hi, >> >> after synching my master branch with upstream (has been a long while >> since my previous update ;), I can't use the Eclipse projects (base, >> controls, graphics are the only ones I'm keeping for change in >> Eclipse) in another project: when running any application it's >> throwing the stacktrace below. >> >> My overall setup worked fine before (didn't dig yet when it started >> not to), running the tests inside the fx projects themselves is fine, >> though. >> >> Looks like there is something missing (native?) related to graphics. >> >> Where to start looking for the reason? >> >> Stacktrace: >> >> java.lang.ClassNotFoundException: >> com.sun.prism.shader.FillPgram_Color_Loader >> at >> >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) >> at >> >> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >> at java.base/java.lang.Class.forName0(Native Method) >> at java.base/java.lang.Class.forName(Class.java:332) >> at >> >> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >> at >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >> at >> >> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >> at >> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >> at >> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> at >> >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> at >> >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >> at java.base/java.lang.Thread.run(Thread.java:835) >> java.lang.InternalError: Error loading stock shader FillPgram_Color >> at >> >> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >> at >> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >> at >> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >> at >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >> at >> >> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >> at >> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >> at >> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> at >> >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> at >> >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >> at java.base/java.lang.Thread.run(Thread.java:835) >> >> -- Thanks, Jeanette >> >> >> From fastegal at swingempire.de Fri Jul 15 10:18:54 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 15 Jul 2022 12:18:54 +0200 Subject: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> Message-ID: <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> Zitat von Nir Lisker : Hi Nir, thanks for the explanation - though I have no idea why Eclipse wants them (see them again after re-adding as source folders and all running as before). Not sure where to go from here, would prefer not to have a local classpath that differs from the one in the repository .. hmm -- Jeanette > To be more specific, FillPgram_Color_Loader.java is located under the > build/gensrc folder, which is created during the javafx setup depending on > the OS. Specifically, it's under build/gensrc/jsl-prism, which is > Windows-specific. > The change to the classpath file removed these folders from the source > folders list in the build path, so I don't know why you would get this > error. Nothing in the "main" source folders references these in compile- or > build-time. > > On Fri, Jul 15, 2022 at 12:51 PM Nir Lisker wrote: > >> The Eclipse project files were updated recently in >> https://github.com/openjdk/jfx/pull/804. The OS-specific folders were >> removed. I tested it and I had no issue after this change. On what resource >> are you getting this error? >> >> On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < >> fastegal at swingempire.de> wrote: >> >>> >>> Hi, >>> >>> after synching my master branch with upstream (has been a long while >>> since my previous update ;), I can't use the Eclipse projects (base, >>> controls, graphics are the only ones I'm keeping for change in >>> Eclipse) in another project: when running any application it's >>> throwing the stacktrace below. >>> >>> My overall setup worked fine before (didn't dig yet when it started >>> not to), running the tests inside the fx projects themselves is fine, >>> though. >>> >>> Looks like there is something missing (native?) related to graphics. >>> >>> Where to start looking for the reason? >>> >>> Stacktrace: >>> >>> java.lang.ClassNotFoundException: >>> com.sun.prism.shader.FillPgram_Color_Loader >>> at >>> >>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) >>> at >>> >>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >>> at java.base/java.lang.Class.forName0(Native Method) >>> at java.base/java.lang.Class.forName(Class.java:332) >>> at >>> >>> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >>> at >>> >>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >>> at >>> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >>> at >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >>> at java.base/java.lang.Thread.run(Thread.java:835) >>> java.lang.InternalError: Error loading stock shader FillPgram_Color >>> at >>> >>> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >>> at >>> >>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >>> at >>> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >>> at >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >>> at java.base/java.lang.Thread.run(Thread.java:835) >>> >>> -- Thanks, Jeanette >>> >>> >>> From nlisker at gmail.com Fri Jul 15 10:22:06 2022 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 15 Jul 2022 13:22:06 +0300 Subject: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> Message-ID: What resource is the error on? On Fri, Jul 15, 2022 at 1:19 PM Jeanette Winzenburg wrote: > > Zitat von Nir Lisker : > > Hi Nir, > > thanks for the explanation - though I have no idea why Eclipse wants > them (see them again after re-adding as source folders and all running > as before). > > Not sure where to go from here, would prefer not to have a local > classpath that differs from the one in the repository .. hmm > > -- Jeanette > > > To be more specific, FillPgram_Color_Loader.java is located under the > > build/gensrc folder, which is created during the javafx setup depending > on > > the OS. Specifically, it's under build/gensrc/jsl-prism, which is > > Windows-specific. > > The change to the classpath file removed these folders from the source > > folders list in the build path, so I don't know why you would get this > > error. Nothing in the "main" source folders references these in compile- > or > > build-time. > > > > On Fri, Jul 15, 2022 at 12:51 PM Nir Lisker wrote: > > > >> The Eclipse project files were updated recently in > >> https://github.com/openjdk/jfx/pull/804. The OS-specific folders were > >> removed. I tested it and I had no issue after this change. On what > resource > >> are you getting this error? > >> > >> On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < > >> fastegal at swingempire.de> wrote: > >> > >>> > >>> Hi, > >>> > >>> after synching my master branch with upstream (has been a long while > >>> since my previous update ;), I can't use the Eclipse projects (base, > >>> controls, graphics are the only ones I'm keeping for change in > >>> Eclipse) in another project: when running any application it's > >>> throwing the stacktrace below. > >>> > >>> My overall setup worked fine before (didn't dig yet when it started > >>> not to), running the tests inside the fx projects themselves is fine, > >>> though. > >>> > >>> Looks like there is something missing (native?) related to graphics. > >>> > >>> Where to start looking for the reason? > >>> > >>> Stacktrace: > >>> > >>> java.lang.ClassNotFoundException: > >>> com.sun.prism.shader.FillPgram_Color_Loader > >>> at > >>> > >>> > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) > >>> at > >>> > >>> > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > >>> at > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > >>> at java.base/java.lang.Class.forName0(Native Method) > >>> at java.base/java.lang.Class.forName(Class.java:332) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > >>> at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > >>> at > >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > >>> at > >>> > >>> > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > >>> at > >>> > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > >>> at > >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > >>> at java.base/java.lang.Thread.run(Thread.java:835) > >>> java.lang.InternalError: Error loading stock shader FillPgram_Color > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > >>> at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > >>> at > >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > >>> at > >>> > >>> > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > >>> at > >>> > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > >>> at > >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > >>> at java.base/java.lang.Thread.run(Thread.java:835) > >>> > >>> -- Thanks, Jeanette > >>> > >>> > >>> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fastegal at swingempire.de Fri Jul 15 10:29:11 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 15 Jul 2022 12:29:11 +0200 Subject: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> Message-ID: <20220715122911.Horde.PI8F52esq11DHLwN4orEfGO@webmail.df.eu> Zitat von Nir Lisker : > What resource is the error on? what do you mean by _resource_? It's on the console .. > > On Fri, Jul 15, 2022 at 1:19 PM Jeanette Winzenburg > wrote: > >> >> Zitat von Nir Lisker : >> >> Hi Nir, >> >> thanks for the explanation - though I have no idea why Eclipse wants >> them (see them again after re-adding as source folders and all running >> as before). >> >> Not sure where to go from here, would prefer not to have a local >> classpath that differs from the one in the repository .. hmm >> >> -- Jeanette >> >> > To be more specific, FillPgram_Color_Loader.java is located under the >> > build/gensrc folder, which is created during the javafx setup depending >> on >> > the OS. Specifically, it's under build/gensrc/jsl-prism, which is >> > Windows-specific. >> > The change to the classpath file removed these folders from the source >> > folders list in the build path, so I don't know why you would get this >> > error. Nothing in the "main" source folders references these in compile- >> or >> > build-time. >> > >> > On Fri, Jul 15, 2022 at 12:51 PM Nir Lisker wrote: >> > >> >> The Eclipse project files were updated recently in >> >> https://github.com/openjdk/jfx/pull/804. The OS-specific folders were >> >> removed. I tested it and I had no issue after this change. On what >> resource >> >> are you getting this error? >> >> >> >> On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < >> >> fastegal at swingempire.de> wrote: >> >> >> >>> >> >>> Hi, >> >>> >> >>> after synching my master branch with upstream (has been a long while >> >>> since my previous update ;), I can't use the Eclipse projects (base, >> >>> controls, graphics are the only ones I'm keeping for change in >> >>> Eclipse) in another project: when running any application it's >> >>> throwing the stacktrace below. >> >>> >> >>> My overall setup worked fine before (didn't dig yet when it started >> >>> not to), running the tests inside the fx projects themselves is fine, >> >>> though. >> >>> >> >>> Looks like there is something missing (native?) related to graphics. >> >>> >> >>> Where to start looking for the reason? >> >>> >> >>> Stacktrace: >> >>> >> >>> java.lang.ClassNotFoundException: >> >>> com.sun.prism.shader.FillPgram_Color_Loader >> >>> at >> >>> >> >>> >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) >> >>> at >> >>> >> >>> >> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >> >>> at >> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >> >>> at java.base/java.lang.Class.forName0(Native Method) >> >>> at java.base/java.lang.Class.forName(Class.java:332) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >> >>> at >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> >>> at >> >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >> >>> at >> >>> >> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >> >>> at >> >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >> >>> at java.base/java.lang.Thread.run(Thread.java:835) >> >>> java.lang.InternalError: Error loading stock shader FillPgram_Color >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >> >>> at >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> >>> at >> >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >> >>> at >> >>> >> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >> >>> at >> >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >> >>> at java.base/java.lang.Thread.run(Thread.java:835) >> >>> >> >>> -- Thanks, Jeanette >> >>> >> >>> >> >>> >> >> >> >> From jhendrikx at openjdk.org Fri Jul 15 10:31:15 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 15 Jul 2022 10:31:15 GMT Subject: [jfx19] RFR: 8290331 Binding value left null when immediately revalidated in invalidation listener [v2] In-Reply-To: <8CqWcI0hfQMyw0CoIgiUNkWiaxfn2bXpSCe3fYMCVBc=.1358ca1a-6f6b-4d0d-8f5b-39fd99d4fa6c@github.com> References: <8CqWcI0hfQMyw0CoIgiUNkWiaxfn2bXpSCe3fYMCVBc=.1358ca1a-6f6b-4d0d-8f5b-39fd99d4fa6c@github.com> Message-ID: On Fri, 15 Jul 2022 07:19:19 GMT, John Hendrikx wrote: >> I introduced a bug with the fluent bindings PR which affects all ObjectBindings. >> >> This is the code that fails: >> >> SimpleObjectProperty condition = new SimpleObjectProperty<>(true); >> ObservableValue binding = condition.map(Object::toString); >> >> binding.addListener(o -> { binding.getValue(); }); >> >> condition.set(false); >> >> assertEquals(false, binding.getValue()); // returns null (!) >> >> This PR fixes this problem and adds a test case to cover it. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Change explanatory comment to block comment > 8206449 Ah, nice, looks like that one can be closed then ------------- PR: https://git.openjdk.org/jfx/pull/829 From duke at openjdk.org Fri Jul 15 13:02:19 2022 From: duke at openjdk.org (Nicholas Bosshard) Date: Fri, 15 Jul 2022 13:02:19 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 13:59:36 GMT, Johan Vos wrote: >> In order to fix the issues reported in JDK-8089589, the VirtualFlow now uses the real sizes of the elements that are displayed. This allows for a more natural way of scrolling through lists that contain items of very different sizes. >> The algorithm that is used, does not calculate the size of each individual cell upfront, as that would be a major performance overhead (especially for large lists). Instead, we estimate the total size and the size of the individual cells based on the real measured size of a (growing) number of cells. >> >> There are a number of key variables that depend on this estimated size: >> * position >> * aboluteOffset >> * currentIndex >> >> As a consequence, when the estimated size is changing, the absoluteOffset may change which may lead to a new currentIndex. If this happens during a layout phase, or a "complex" operation (e.g. scroll to an item and select it), this may lead to visually unexpected artifacts. While the rendering becomes more "correct" when the estimated size is improving, it is more important that we do not create visual confusion. >> >> The difficulty is that there are a large number of ways to manipulate the VirtualFlow, and different entry points may have different expectations about which variables should be kept constant (or only changed gradually). >> >> In this PR, we focus on consistency in the scrollTo method, where we want to keep the top-cell constant. In case the estimated size is improved during the scrollTo execution, or the next layoutChildren invocation, this implies keeping the result of computeCurrentIndex() constant so that after scrolling to a cell and selecting it, the selected cell is indeed the one that is scrolled to. >> >> This PR contains a number of tests for this scrollTo behaviour, that should also be considered as regression test in case we want to add more invariants later. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > reverse one more expected/actual set of args. This fix seems to break `TreeTableView`. The tree jumps to the top when a `TreeItem` is expanded or collapsed. Tested with `19-ea-9`. Does not happen when running the same application with `19-ea-8`. ------------- PR: https://git.openjdk.org/jfx/pull/808 From kcr at openjdk.org Fri Jul 15 13:55:05 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Jul 2022 13:55:05 GMT Subject: RFR: 8289611: MouseLocationOnScreenTest sometimes fails on Mac M1 In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 20:55:25 GMT, Andy Goryachev wrote: > - using Screen.getVisualBounds() instead of Screen.getBounds() I can confirm that running the full set of tests fails without this fix and works with this fix. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/828 From nlisker at openjdk.org Fri Jul 15 13:57:03 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 15 Jul 2022 13:57:03 GMT Subject: [jfx19] RFR: 8290331 Binding value left null when immediately revalidated in invalidation listener In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 23:55:52 GMT, Kevin Rushforth wrote: >> I introduced a bug with the fluent bindings PR which affects all ObjectBindings. >> >> This is the code that fails: >> >> SimpleObjectProperty condition = new SimpleObjectProperty<>(true); >> ObservableValue binding = condition.map(Object::toString); >> >> binding.addListener(o -> { binding.getValue(); }); >> >> condition.set(false); >> >> assertEquals(false, binding.getValue()); // returns null (!) >> >> This PR fixes this problem and adds a test case to cover it. > > Good catch. And yes, this needs to go into JavaFX 19. @kevinrushforth Any idea why `/issue add` is only available to the author? If I can go to JBS and close it as a duplicate, it makes sense that I could mark it as such here. Is there some conceptual point I'm missing? ------------- PR: https://git.openjdk.org/jfx/pull/829 From kcr at openjdk.org Fri Jul 15 14:02:12 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Jul 2022 14:02:12 GMT Subject: [jfx19] RFR: 8290331 Binding value left null when immediately revalidated in invalidation listener In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 13:53:20 GMT, Nir Lisker wrote: > Any idea why /issue add is only available to the author? This is deliberate. Commands like `/issue` and `/summary` are under the purview of the Author of the PR, since they affect the commit message associated with this PR. In any case, it is not correct to add [JDK-8206449](https://bugs.openjdk.org/browse/JDK-8206449) as an additional issue fixed by this PR. Rather, JDK-8206449 is a duplicate of the previously integrated [JDK-8274771](https://bugs.openjdk.org/browse/JDK-8274771). ------------- PR: https://git.openjdk.org/jfx/pull/829 From nlisker at openjdk.org Fri Jul 15 14:09:17 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 15 Jul 2022 14:09:17 GMT Subject: [jfx19] RFR: 8290331 Binding value left null when immediately revalidated in invalidation listener [v2] In-Reply-To: <8CqWcI0hfQMyw0CoIgiUNkWiaxfn2bXpSCe3fYMCVBc=.1358ca1a-6f6b-4d0d-8f5b-39fd99d4fa6c@github.com> References: <8CqWcI0hfQMyw0CoIgiUNkWiaxfn2bXpSCe3fYMCVBc=.1358ca1a-6f6b-4d0d-8f5b-39fd99d4fa6c@github.com> Message-ID: <6lIx4iX1tY_x-G4hbZHnJqYxu0W7egO2q2s1DG8IDHU=.e125103b-f29b-4f04-9368-032c9f06b172@github.com> On Fri, 15 Jul 2022 07:19:19 GMT, John Hendrikx wrote: >> I introduced a bug with the fluent bindings PR which affects all ObjectBindings. >> >> This is the code that fails: >> >> SimpleObjectProperty condition = new SimpleObjectProperty<>(true); >> ObservableValue binding = condition.map(Object::toString); >> >> binding.addListener(o -> { binding.getValue(); }); >> >> condition.set(false); >> >> assertEquals(false, binding.getValue()); // returns null (!) >> >> This PR fixes this problem and adds a test case to cover it. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Change explanatory comment to block comment Alright, I closed [JDK-8206449](https://bugs.openjdk.org/browse/JDK-8206449) as duplicated of [JDK-8274771](https://bugs.openjdk.org/browse/JDK-8274771). ------------- PR: https://git.openjdk.org/jfx/pull/829 From duke at openjdk.org Fri Jul 15 15:07:08 2022 From: duke at openjdk.org (Andy Goryachev) Date: Fri, 15 Jul 2022 15:07:08 GMT Subject: Integrated: 8289611: MouseLocationOnScreenTest sometimes fails on Mac M1 In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 20:55:25 GMT, Andy Goryachev wrote: > - using Screen.getVisualBounds() instead of Screen.getBounds() This pull request has now been integrated. Changeset: 6d76dea2 Author: Andy Goryachev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/6d76dea2e207566c85315d7beb6bf4f722ac984f Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8289611: MouseLocationOnScreenTest sometimes fails on Mac M1 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/828 From kcr at openjdk.org Fri Jul 15 15:19:08 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Jul 2022 15:19:08 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: Message-ID: <3rli6NDAsWbLlqXC_gqTT52pgeYVNU0nynGIPS8uAkA=.4f46adb8-25f9-4157-bcac-4589d6296d1f@github.com> On Fri, 15 Jul 2022 01:17:16 GMT, Nicholas Bosshard wrote: > This fix seems to break `TreeTableView`. A new bug has been filed to track this: [JDK-8290348](https://bugs.openjdk.org/browse/JDK-8290348). ------------- PR: https://git.openjdk.org/jfx/pull/808 From andy.goryachev at oracle.com Fri Jul 15 15:44:08 2022 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 15 Jul 2022 15:44:08 +0000 Subject: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: <20220715122911.Horde.PI8F52esq11DHLwN4orEfGO@webmail.df.eu> References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> <20220715122911.Horde.PI8F52esq11DHLwN4orEfGO@webmail.df.eu> Message-ID: Jeanette, Nir: Apparently, the classes in build/gensrc are being accessed via reflection, for example D3DResourceFactory. createStockShader() ES2ResourceFactory. createStockShader() You say the problem went away after adding the classpath entries manually? -andy From: openjfx-dev on behalf of Jeanette Winzenburg Date: Friday, 2022/07/15 at 03:29 To: Nir Lisker Cc: openjfx-dev Subject: Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader Zitat von Nir Lisker : > What resource is the error on? what do you mean by _resource_? It's on the console .. > > On Fri, Jul 15, 2022 at 1:19 PM Jeanette Winzenburg > wrote: > >> >> Zitat von Nir Lisker : >> >> Hi Nir, >> >> thanks for the explanation - though I have no idea why Eclipse wants >> them (see them again after re-adding as source folders and all running >> as before). >> >> Not sure where to go from here, would prefer not to have a local >> classpath that differs from the one in the repository .. hmm >> >> -- Jeanette >> >> > To be more specific, FillPgram_Color_Loader.java is located under the >> > build/gensrc folder, which is created during the javafx setup depending >> on >> > the OS. Specifically, it's under build/gensrc/jsl-prism, which is >> > Windows-specific. >> > The change to the classpath file removed these folders from the source >> > folders list in the build path, so I don't know why you would get this >> > error. Nothing in the "main" source folders references these in compile- >> or >> > build-time. >> > >> > On Fri, Jul 15, 2022 at 12:51 PM Nir Lisker wrote: >> > >> >> The Eclipse project files were updated recently in >> >> https://github.com/openjdk/jfx/pull/804. The OS-specific folders were >> >> removed. I tested it and I had no issue after this change. On what >> resource >> >> are you getting this error? >> >> >> >> On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < >> >> fastegal at swingempire.de> wrote: >> >> >> >>> >> >>> Hi, >> >>> >> >>> after synching my master branch with upstream (has been a long while >> >>> since my previous update ;), I can't use the Eclipse projects (base, >> >>> controls, graphics are the only ones I'm keeping for change in >> >>> Eclipse) in another project: when running any application it's >> >>> throwing the stacktrace below. >> >>> >> >>> My overall setup worked fine before (didn't dig yet when it started >> >>> not to), running the tests inside the fx projects themselves is fine, >> >>> though. >> >>> >> >>> Looks like there is something missing (native?) related to graphics. >> >>> >> >>> Where to start looking for the reason? >> >>> >> >>> Stacktrace: >> >>> >> >>> java.lang.ClassNotFoundException: >> >>> com.sun.prism.shader.FillPgram_Color_Loader >> >>> at >> >>> >> >>> >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) >> >>> at >> >>> >> >>> >> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >> >>> at >> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >> >>> at java.base/java.lang.Class.forName0(Native Method) >> >>> at java.base/java.lang.Class.forName(Class.java:332) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >> >>> at >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> >>> at >> >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >> >>> at >> >>> >> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >> >>> at >> >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >> >>> at java.base/java.lang.Thread.run(Thread.java:835) >> >>> java.lang.InternalError: Error loading stock shader FillPgram_Color >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >> >>> at >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> >>> at >> >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >> >>> at >> >>> >> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >> >>> at >> >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >> >>> at java.base/java.lang.Thread.run(Thread.java:835) >> >>> >> >>> -- Thanks, Jeanette >> >>> >> >>> >> >>> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Fri Jul 15 16:05:52 2022 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 15 Jul 2022 16:05:52 +0000 Subject: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> Message-ID: Nir: So these folders are not needed to compile, but they are needed to run. I suggest we bring them back to .classpath and also modify build.gradle to create all 4 folders as a part of the corresponding target. What do you think? -andy From: openjfx-dev on behalf of Jeanette Winzenburg Date: Friday, 2022/07/15 at 03:19 To: openjfx-dev at openjdk.org Subject: Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader Zitat von Nir Lisker : Hi Nir, thanks for the explanation - though I have no idea why Eclipse wants them (see them again after re-adding as source folders and all running as before). Not sure where to go from here, would prefer not to have a local classpath that differs from the one in the repository .. hmm -- Jeanette > To be more specific, FillPgram_Color_Loader.java is located under the > build/gensrc folder, which is created during the javafx setup depending on > the OS. Specifically, it's under build/gensrc/jsl-prism, which is > Windows-specific. > The change to the classpath file removed these folders from the source > folders list in the build path, so I don't know why you would get this > error. Nothing in the "main" source folders references these in compile- or > build-time. > > On Fri, Jul 15, 2022 at 12:51 PM Nir Lisker wrote: > >> The Eclipse project files were updated recently in >> https://github.com/openjdk/jfx/pull/804. The OS-specific folders were >> removed. I tested it and I had no issue after this change. On what resource >> are you getting this error? >> >> On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < >> fastegal at swingempire.de> wrote: >> >>> >>> Hi, >>> >>> after synching my master branch with upstream (has been a long while >>> since my previous update ;), I can't use the Eclipse projects (base, >>> controls, graphics are the only ones I'm keeping for change in >>> Eclipse) in another project: when running any application it's >>> throwing the stacktrace below. >>> >>> My overall setup worked fine before (didn't dig yet when it started >>> not to), running the tests inside the fx projects themselves is fine, >>> though. >>> >>> Looks like there is something missing (native?) related to graphics. >>> >>> Where to start looking for the reason? >>> >>> Stacktrace: >>> >>> java.lang.ClassNotFoundException: >>> com.sun.prism.shader.FillPgram_Color_Loader >>> at >>> >>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) >>> at >>> >>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >>> at java.base/java.lang.Class.forName0(Native Method) >>> at java.base/java.lang.Class.forName(Class.java:332) >>> at >>> >>> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >>> at >>> >>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >>> at >>> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >>> at >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >>> at java.base/java.lang.Thread.run(Thread.java:835) >>> java.lang.InternalError: Error loading stock shader FillPgram_Color >>> at >>> >>> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >>> at >>> >>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >>> at >>> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >>> at >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >>> at java.base/java.lang.Thread.run(Thread.java:835) >>> >>> -- Thanks, Jeanette >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Fri Jul 15 16:51:27 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 15 Jul 2022 09:51:27 -0700 Subject: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> Message-ID: <8d1f8597-94d0-b691-9e73-0b1b3181edd4@oracle.com> On 7/15/2022 9:05 AM, Andy Goryachev wrote: > > Nir: > > So these folders are not needed to compile, but they are needed to run. > > I suggest we bring them back to .classpath > Is there a way to make it conditional? > and also modify build.gradle to create all 4 folders as a part of the > corresponding target. > I am not in favor of this change. There are platform-specific parts of the build, so IDEs should be able to adapt to this. -- Kevin > What do you think? > > -andy > > *From: *openjfx-dev on behalf of > Jeanette Winzenburg > *Date: *Friday, 2022/07/15 at 03:19 > *To: *openjfx-dev at openjdk.org > *Subject: *Re: Eclipse: ClassNotFoundException: > com.sun.prism.shader.FillPgram_Color_Loader > > > Zitat von Nir Lisker : > > Hi Nir, > > thanks for the explanation - though I have no idea why Eclipse wants > them (see them again after re-adding as source folders and all running > as before). > > Not sure where to go from here, would prefer not to have a local > classpath that differs from the one in the repository .. hmm > > -- Jeanette > > > To be more specific, FillPgram_Color_Loader.java is located under the > > build/gensrc folder, which is created during the javafx setup > depending on > > the OS. Specifically, it's under build/gensrc/jsl-prism, which is > > Windows-specific. > > The change to the classpath file removed these folders from the source > > folders list in the build path, so I don't know why you would get this > > error. Nothing in the "main" source folders references these in > compile- or > > build-time. > > > > On Fri, Jul 15, 2022 at 12:51 PM Nir Lisker wrote: > > > >> The Eclipse project files were updated recently in > >> https://github.com/openjdk/jfx/pull/804. The OS-specific folders were > >> removed. I tested it and I had no issue after this change. On what > resource > >> are you getting this error? > >> > >> On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < > >> fastegal at swingempire.de> wrote: > >> > >>> > >>> Hi, > >>> > >>> after synching my master branch with upstream (has been a long while > >>> since my previous update ;), I can't use the Eclipse projects (base, > >>> controls, graphics are the only ones I'm keeping for change in > >>> Eclipse) in another project: when running any application it's > >>> throwing the stacktrace below. > >>> > >>> My overall setup worked fine before (didn't dig yet when it started > >>> not to), running the tests inside the fx projects themselves is fine, > >>> though. > >>> > >>> Looks like there is something missing (native?) related to graphics. > >>> > >>> Where to start looking for the reason? > >>> > >>> Stacktrace: > >>> > >>> java.lang.ClassNotFoundException: > >>> com.sun.prism.shader.FillPgram_Color_Loader > >>>???????? at > >>> > >>> > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) > >>>???????? at > >>> > >>> > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > >>>???????? at > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > >>>???????? at java.base/java.lang.Class.forName0(Native Method) > >>>???????? at java.base/java.lang.Class.forName(Class.java:332) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > >>>???????? at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > >>>???????? at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > >>>???????? at > >>> > >>> > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > >>>???????? at > >>> > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > >>>???????? at > >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > >>>???????? at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > >>>???????? at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > >>>???????? at java.base/java.lang.Thread.run(Thread.java:835) > >>> java.lang.InternalError: Error loading stock shader FillPgram_Color > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > >>>???????? at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > >>>???????? at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > >>>???????? at > >>> > >>> > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > >>>???????? at > >>> > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > >>>???????? at > >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > >>>???????? at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > >>>???????? at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > >>>???????? at java.base/java.lang.Thread.run(Thread.java:835) > >>> > >>> -- Thanks, Jeanette > >>> > >>> > >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Fri Jul 15 17:17:02 2022 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 15 Jul 2022 17:17:02 +0000 Subject: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: <8d1f8597-94d0-b691-9e73-0b1b3181edd4@oracle.com> References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> <8d1f8597-94d0-b691-9e73-0b1b3181edd4@oracle.com> Message-ID: Kevin: The four classpath entries in question are build/hlsl/Prism build/gensrc/jsl-prism build/hlsl/Decora build/gensrc/jsl-decora once added to the Eclipse .classpath file (in graphics) I see two warnings (on Mac): Project 'graphics' is missing required source folder: 'build/hlsl/Decora' Build path graphics Project 'graphics' is missing required source folder: 'build/hlsl/Prism' Build path graphics For the moment I cannot verify the situation on Windows or Linux, but I think Nir mentioned that these directories might be created on Windows, so this is my current assumption. The problem in Eclipse is that these warnings (incomplete build path) cannot be turned off. One solution is to (re)create the missing directories manually after each [gradle clean]. The other solution is to modify gradle build to always create these directories, even if they are not used. This step is usually in ?init? target in the builds that utilize clean-init-build cycle. What could be the problem in creating empty directories? * Is there a way to make it conditional? In theory, yes, via classpath variables: https://stackoverflow.com/questions/495264/how-can-i-specify-an-eclipse-classpath-entry-for-specific-o-s-platform I?ve never used this before. So far these directories are the only place where we have platform differences in the classpath. Could someone with a Windows machine verify that 'build/hlsl/Decora' and 'build/hlsl/Prism' are not empty please? Thank you -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Friday, 2022/07/15 at 09:51 To: openjfx-dev at openjdk.org Subject: Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader On 7/15/2022 9:05 AM, Andy Goryachev wrote: Nir: So these folders are not needed to compile, but they are needed to run. I suggest we bring them back to .classpath Is there a way to make it conditional? and also modify build.gradle to create all 4 folders as a part of the corresponding target. I am not in favor of this change. There are platform-specific parts of the build, so IDEs should be able to adapt to this. -- Kevin What do you think? -andy From: openjfx-dev on behalf of Jeanette Winzenburg Date: Friday, 2022/07/15 at 03:19 To: openjfx-dev at openjdk.org Subject: Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader Zitat von Nir Lisker : Hi Nir, thanks for the explanation - though I have no idea why Eclipse wants them (see them again after re-adding as source folders and all running as before). Not sure where to go from here, would prefer not to have a local classpath that differs from the one in the repository .. hmm -- Jeanette > To be more specific, FillPgram_Color_Loader.java is located under the > build/gensrc folder, which is created during the javafx setup depending on > the OS. Specifically, it's under build/gensrc/jsl-prism, which is > Windows-specific. > The change to the classpath file removed these folders from the source > folders list in the build path, so I don't know why you would get this > error. Nothing in the "main" source folders references these in compile- or > build-time. > > On Fri, Jul 15, 2022 at 12:51 PM Nir Lisker wrote: > >> The Eclipse project files were updated recently in >> https://github.com/openjdk/jfx/pull/804. The OS-specific folders were >> removed. I tested it and I had no issue after this change. On what resource >> are you getting this error? >> >> On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < >> fastegal at swingempire.de> wrote: >> >>> >>> Hi, >>> >>> after synching my master branch with upstream (has been a long while >>> since my previous update ;), I can't use the Eclipse projects (base, >>> controls, graphics are the only ones I'm keeping for change in >>> Eclipse) in another project: when running any application it's >>> throwing the stacktrace below. >>> >>> My overall setup worked fine before (didn't dig yet when it started >>> not to), running the tests inside the fx projects themselves is fine, >>> though. >>> >>> Looks like there is something missing (native?) related to graphics. >>> >>> Where to start looking for the reason? >>> >>> Stacktrace: >>> >>> java.lang.ClassNotFoundException: >>> com.sun.prism.shader.FillPgram_Color_Loader >>> at >>> >>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) >>> at >>> >>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >>> at java.base/java.lang.Class.forName0(Native Method) >>> at java.base/java.lang.Class.forName(Class.java:332) >>> at >>> >>> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >>> at >>> >>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >>> at >>> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >>> at >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >>> at java.base/java.lang.Thread.run(Thread.java:835) >>> java.lang.InternalError: Error loading stock shader FillPgram_Color >>> at >>> >>> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >>> at >>> >>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >>> at >>> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >>> at >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >>> at java.base/java.lang.Thread.run(Thread.java:835) >>> >>> -- Thanks, Jeanette >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Fri Jul 15 18:03:49 2022 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 15 Jul 2022 21:03:49 +0300 Subject: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> <8d1f8597-94d0-b691-9e73-0b1b3181edd4@oracle.com> Message-ID: First of all, you can set "ignore optional compile problems" on a source folder in Eclipse. In fact, these folders were set as such before the change. But more importantly, I don't see how classes that are only used in reflection will cause a build error. If these folders are not referenced in compile time, Eclipse doesn't need them as source folders. Jeanette, the Problems view in Eclipse has a table where it shows the problem and the resource and path from which the error originates. If you get errors because of missing OS-specific folders, it's crucial to know what reports those errors, that is, who is looking for these folders. On Fri, Jul 15, 2022 at 8:17 PM Andy Goryachev wrote: > Kevin: > > > > The four classpath entries in question are > > build/hlsl/Prism > > build/gensrc/jsl-prism > > build/hlsl/Decora > > build/gensrc/jsl-decora > > > > once added to the Eclipse .classpath file (in graphics) I see two warnings > (on Mac): > > > > Project 'graphics' is missing required source folder: 'build/hlsl/Decora' > Build path graphics > > Project 'graphics' is missing required source folder: 'build/hlsl/Prism' > Build path graphics > > > > For the moment I cannot verify the situation on Windows or Linux, but I > think Nir mentioned that these directories might be created on Windows, so > this is my current assumption. > > > > The problem in Eclipse is that these warnings (incomplete build path) > cannot be turned off. One solution is to (re)create the missing > directories manually after each [gradle clean]. The other solution is to > modify gradle build to always create these directories, even if they are > not used. This step is usually in ?init? target in the builds that utilize > clean-init-build cycle. > > > > What could be the problem in creating empty directories? > > > > > > - Is there a way to make it conditional? > > > > In theory, yes, via classpath variables: > > > > > https://stackoverflow.com/questions/495264/how-can-i-specify-an-eclipse-classpath-entry-for-specific-o-s-platform > > > > I?ve never used this before. So far these directories are the only place > where we have platform differences in the classpath. > > > > Could someone with a Windows machine verify that 'build/hlsl/Decora' and > 'build/hlsl/Prism' are not empty please? > > > > Thank you > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Kevin > Rushforth > *Date: *Friday, 2022/07/15 at 09:51 > *To: *openjfx-dev at openjdk.org > *Subject: *Re: Eclipse: ClassNotFoundException: > com.sun.prism.shader.FillPgram_Color_Loader > > > > On 7/15/2022 9:05 AM, Andy Goryachev wrote: > > Nir: > > > > So these folders are not needed to compile, but they are needed to run. > > > > I suggest we bring them back to .classpath > > > Is there a way to make it conditional? > > > and also modify build.gradle to create all 4 folders as a part of the > corresponding target. > > > I am not in favor of this change. There are platform-specific parts of the > build, so IDEs should be able to adapt to this. > > -- Kevin > > > > > > What do you think? > > > > -andy > > > > > > > > *From: *openjfx-dev > on behalf of Jeanette Winzenburg > > *Date: *Friday, 2022/07/15 at 03:19 > *To: *openjfx-dev at openjdk.org > > *Subject: *Re: Eclipse: ClassNotFoundException: > com.sun.prism.shader.FillPgram_Color_Loader > > > Zitat von Nir Lisker : > > Hi Nir, > > thanks for the explanation - though I have no idea why Eclipse wants > them (see them again after re-adding as source folders and all running > as before). > > Not sure where to go from here, would prefer not to have a local > classpath that differs from the one in the repository .. hmm > > -- Jeanette > > > To be more specific, FillPgram_Color_Loader.java is located under the > > build/gensrc folder, which is created during the javafx setup depending > on > > the OS. Specifically, it's under build/gensrc/jsl-prism, which is > > Windows-specific. > > The change to the classpath file removed these folders from the source > > folders list in the build path, so I don't know why you would get this > > error. Nothing in the "main" source folders references these in compile- > or > > build-time. > > > > On Fri, Jul 15, 2022 at 12:51 PM Nir Lisker > wrote: > > > >> The Eclipse project files were updated recently in > >> https://github.com/openjdk/jfx/pull/804. The OS-specific folders were > >> removed. I tested it and I had no issue after this change. On what > resource > >> are you getting this error? > >> > >> On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < > >> fastegal at swingempire.de> wrote: > >> > >>> > >>> Hi, > >>> > >>> after synching my master branch with upstream (has been a long while > >>> since my previous update ;), I can't use the Eclipse projects (base, > >>> controls, graphics are the only ones I'm keeping for change in > >>> Eclipse) in another project: when running any application it's > >>> throwing the stacktrace below. > >>> > >>> My overall setup worked fine before (didn't dig yet when it started > >>> not to), running the tests inside the fx projects themselves is fine, > >>> though. > >>> > >>> Looks like there is something missing (native?) related to graphics. > >>> > >>> Where to start looking for the reason? > >>> > >>> Stacktrace: > >>> > >>> java.lang.ClassNotFoundException: > >>> com.sun.prism.shader.FillPgram_Color_Loader > >>> at > >>> > >>> > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) > >>> at > >>> > >>> > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > >>> at > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > >>> at java.base/java.lang.Class.forName0(Native Method) > >>> at java.base/java.lang.Class.forName(Class.java:332) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > >>> at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > >>> at > >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > >>> at > >>> > >>> > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > >>> at > >>> > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > >>> at > >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > >>> at java.base/java.lang.Thread.run(Thread.java:835) > >>> java.lang.InternalError: Error loading stock shader FillPgram_Color > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > >>> at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > >>> at > >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > >>> at > >>> > >>> > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > >>> at > >>> > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > >>> at > >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > >>> at java.base/java.lang.Thread.run(Thread.java:835) > >>> > >>> -- Thanks, Jeanette > >>> > >>> > >>> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Fri Jul 15 18:22:27 2022 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 15 Jul 2022 18:22:27 +0000 Subject: [External] : Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> <8d1f8597-94d0-b691-9e73-0b1b3181edd4@oracle.com> Message-ID: Nir: 1. Unfortunately, even with ?ignore optional problems? Eclipse generates the ?missing required source folder?. Below are the four entries I?ve added to modules/javafx.graphics/.classpath: 1. The classes in build/gensrc/ generate a runtime exception, not a build error. I wonder if perhaps we should add an entry to the library path instead. Let me check on this. 1. Again, Jeanette?s report was about runtime error. I wonder though if we have / should have a file that documents where reflection is being used. (Perhaps it already exists somewhere? Searching for ?reflection? turned out 4.5K hits?) What do you think? -andy From: Nir Lisker Date: Friday, 2022/07/15 at 11:04 To: Andy Goryachev , Jeanette Winzenburg Cc: Kevin Rushforth , openjfx-dev at openjdk.org Subject: [External] : Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader First of all, you can set "ignore optional compile problems" on a source folder in Eclipse. In fact, these folders were set as such before the change. But more importantly, I don't see how classes that are only used in reflection will cause a build error. If these folders are not referenced in compile time, Eclipse doesn't need them as source folders. Jeanette, the Problems view in Eclipse has a table where it shows the problem and the resource and path from which the error originates. If you get errors because of missing OS-specific folders, it's crucial to know what reports those errors, that is, who is looking for these folders. On Fri, Jul 15, 2022 at 8:17 PM Andy Goryachev > wrote: Kevin: The four classpath entries in question are build/hlsl/Prism build/gensrc/jsl-prism build/hlsl/Decora build/gensrc/jsl-decora once added to the Eclipse .classpath file (in graphics) I see two warnings (on Mac): Project 'graphics' is missing required source folder: 'build/hlsl/Decora' Build path graphics Project 'graphics' is missing required source folder: 'build/hlsl/Prism' Build path graphics For the moment I cannot verify the situation on Windows or Linux, but I think Nir mentioned that these directories might be created on Windows, so this is my current assumption. The problem in Eclipse is that these warnings (incomplete build path) cannot be turned off. One solution is to (re)create the missing directories manually after each [gradle clean]. The other solution is to modify gradle build to always create these directories, even if they are not used. This step is usually in ?init? target in the builds that utilize clean-init-build cycle. What could be the problem in creating empty directories? * Is there a way to make it conditional? In theory, yes, via classpath variables: https://stackoverflow.com/questions/495264/how-can-i-specify-an-eclipse-classpath-entry-for-specific-o-s-platform I?ve never used this before. So far these directories are the only place where we have platform differences in the classpath. Could someone with a Windows machine verify that 'build/hlsl/Decora' and 'build/hlsl/Prism' are not empty please? Thank you -andy From: openjfx-dev > on behalf of Kevin Rushforth > Date: Friday, 2022/07/15 at 09:51 To: openjfx-dev at openjdk.org > Subject: Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader On 7/15/2022 9:05 AM, Andy Goryachev wrote: Nir: So these folders are not needed to compile, but they are needed to run. I suggest we bring them back to .classpath Is there a way to make it conditional? and also modify build.gradle to create all 4 folders as a part of the corresponding target. I am not in favor of this change. There are platform-specific parts of the build, so IDEs should be able to adapt to this. -- Kevin What do you think? -andy From: openjfx-dev on behalf of Jeanette Winzenburg Date: Friday, 2022/07/15 at 03:19 To: openjfx-dev at openjdk.org Subject: Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader Zitat von Nir Lisker : Hi Nir, thanks for the explanation - though I have no idea why Eclipse wants them (see them again after re-adding as source folders and all running as before). Not sure where to go from here, would prefer not to have a local classpath that differs from the one in the repository .. hmm -- Jeanette > To be more specific, FillPgram_Color_Loader.java is located under the > build/gensrc folder, which is created during the javafx setup depending on > the OS. Specifically, it's under build/gensrc/jsl-prism, which is > Windows-specific. > The change to the classpath file removed these folders from the source > folders list in the build path, so I don't know why you would get this > error. Nothing in the "main" source folders references these in compile- or > build-time. > > On Fri, Jul 15, 2022 at 12:51 PM Nir Lisker wrote: > >> The Eclipse project files were updated recently in >> https://github.com/openjdk/jfx/pull/804. The OS-specific folders were >> removed. I tested it and I had no issue after this change. On what resource >> are you getting this error? >> >> On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < >> fastegal at swingempire.de> wrote: >> >>> >>> Hi, >>> >>> after synching my master branch with upstream (has been a long while >>> since my previous update ;), I can't use the Eclipse projects (base, >>> controls, graphics are the only ones I'm keeping for change in >>> Eclipse) in another project: when running any application it's >>> throwing the stacktrace below. >>> >>> My overall setup worked fine before (didn't dig yet when it started >>> not to), running the tests inside the fx projects themselves is fine, >>> though. >>> >>> Looks like there is something missing (native?) related to graphics. >>> >>> Where to start looking for the reason? >>> >>> Stacktrace: >>> >>> java.lang.ClassNotFoundException: >>> com.sun.prism.shader.FillPgram_Color_Loader >>> at >>> >>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) >>> at >>> >>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >>> at java.base/java.lang.Class.forName0(Native Method) >>> at java.base/java.lang.Class.forName(Class.java:332) >>> at >>> >>> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >>> at >>> >>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >>> at >>> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >>> at >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >>> at java.base/java.lang.Thread.run(Thread.java:835) >>> java.lang.InternalError: Error loading stock shader FillPgram_Color >>> at >>> >>> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >>> at >>> >>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >>> at >>> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >>> at >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >>> at java.base/java.lang.Thread.run(Thread.java:835) >>> >>> -- Thanks, Jeanette >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Fri Jul 15 19:34:20 2022 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 15 Jul 2022 22:34:20 +0300 Subject: [External] : Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> <8d1f8597-94d0-b691-9e73-0b1b3181edd4@oracle.com> Message-ID: Ah, I missed that it's during runtime. When I reviewed the PR I tested an external project which relies on the graphics module and it worked fine. I will try to find a case that throws this error and see what can be done. On Fri, Jul 15, 2022 at 9:22 PM Andy Goryachev wrote: > Nir: > > > > 1. Unfortunately, even with ?ignore optional problems? Eclipse > generates the ?missing required source folder?. Below are the four entries > I?ve added to modules/javafx.graphics/.classpath: > > > > > > > > "true"/> > > > > > > > > > > "true"/> > > > > > > > > > > "true"/> > > > > > > > > > > "true"/> > > > > "src/main/java"/> > > > > > > 1. The classes in build/gensrc/ generate a runtime exception, not a > build error. I wonder if perhaps we should add an entry to the library > path instead. Let me check on this. > > > > 1. Again, Jeanette?s report was about runtime error. I wonder though > if we have / should have a file that documents where reflection is being > used. (Perhaps it already exists somewhere? Searching for ?reflection? > turned out 4.5K hits?) > > > > What do you think? > > > > -andy > > > > *From: *Nir Lisker > *Date: *Friday, 2022/07/15 at 11:04 > *To: *Andy Goryachev , Jeanette Winzenburg < > fastegal at swingempire.de> > *Cc: *Kevin Rushforth , > openjfx-dev at openjdk.org > *Subject: *[External] : Re: Eclipse: ClassNotFoundException: > com.sun.prism.shader.FillPgram_Color_Loader > > First of all, you can set "ignore optional compile problems" on a source > folder in Eclipse. In fact, these folders were set as such before the > change. > > > > But more importantly, I don't see how classes that are only used in > reflection will cause a build error. If these folders are not referenced in > compile time, Eclipse doesn't need them as source folders. > > > > Jeanette, the Problems view in Eclipse has a table where it shows the > problem and the resource and path from which the error originates. If you > get errors because of missing OS-specific folders, it's crucial to know > what reports those errors, that is, who is looking for these folders. > > > > On Fri, Jul 15, 2022 at 8:17 PM Andy Goryachev > wrote: > > Kevin: > > > > The four classpath entries in question are > > build/hlsl/Prism > > build/gensrc/jsl-prism > > build/hlsl/Decora > > build/gensrc/jsl-decora > > > > once added to the Eclipse .classpath file (in graphics) I see two warnings > (on Mac): > > > > Project 'graphics' is missing required source folder: > 'build/hlsl/Decora' Build path graphics > > Project 'graphics' is missing required source folder: > 'build/hlsl/Prism' Build path graphics > > > > For the moment I cannot verify the situation on Windows or Linux, but I > think Nir mentioned that these directories might be created on Windows, so > this is my current assumption. > > > > The problem in Eclipse is that these warnings (incomplete build path) > cannot be turned off. One solution is to (re)create the missing > directories manually after each [gradle clean]. The other solution is to > modify gradle build to always create these directories, even if they are > not used. This step is usually in ?init? target in the builds that utilize > clean-init-build cycle. > > > > What could be the problem in creating empty directories? > > > > > > - Is there a way to make it conditional? > > > > In theory, yes, via classpath variables: > > > > > https://stackoverflow.com/questions/495264/how-can-i-specify-an-eclipse-classpath-entry-for-specific-o-s-platform > > > > > I?ve never used this before. So far these directories are the only place > where we have platform differences in the classpath. > > > > Could someone with a Windows machine verify that 'build/hlsl/Decora' and > 'build/hlsl/Prism' are not empty please? > > > > Thank you > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Kevin > Rushforth > *Date: *Friday, 2022/07/15 at 09:51 > *To: *openjfx-dev at openjdk.org > *Subject: *Re: Eclipse: ClassNotFoundException: > com.sun.prism.shader.FillPgram_Color_Loader > > > > On 7/15/2022 9:05 AM, Andy Goryachev wrote: > > Nir: > > > > So these folders are not needed to compile, but they are needed to run. > > > > I suggest we bring them back to .classpath > > > Is there a way to make it conditional? > > and also modify build.gradle to create all 4 folders as a part of the > corresponding target. > > > I am not in favor of this change. There are platform-specific parts of the > build, so IDEs should be able to adapt to this. > > -- Kevin > > > > > What do you think? > > > > -andy > > > > > > > > *From: *openjfx-dev > on behalf of Jeanette Winzenburg > > *Date: *Friday, 2022/07/15 at 03:19 > *To: *openjfx-dev at openjdk.org > > *Subject: *Re: Eclipse: ClassNotFoundException: > com.sun.prism.shader.FillPgram_Color_Loader > > > Zitat von Nir Lisker : > > Hi Nir, > > thanks for the explanation - though I have no idea why Eclipse wants > them (see them again after re-adding as source folders and all running > as before). > > Not sure where to go from here, would prefer not to have a local > classpath that differs from the one in the repository .. hmm > > -- Jeanette > > > To be more specific, FillPgram_Color_Loader.java is located under the > > build/gensrc folder, which is created during the javafx setup depending > on > > the OS. Specifically, it's under build/gensrc/jsl-prism, which is > > Windows-specific. > > The change to the classpath file removed these folders from the source > > folders list in the build path, so I don't know why you would get this > > error. Nothing in the "main" source folders references these in compile- > or > > build-time. > > > > On Fri, Jul 15, 2022 at 12:51 PM Nir Lisker > wrote: > > > >> The Eclipse project files were updated recently in > >> https://github.com/openjdk/jfx/pull/804 > . > The OS-specific folders were > >> removed. I tested it and I had no issue after this change. On what > resource > >> are you getting this error? > >> > >> On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < > >> fastegal at swingempire.de> wrote: > >> > >>> > >>> Hi, > >>> > >>> after synching my master branch with upstream (has been a long while > >>> since my previous update ;), I can't use the Eclipse projects (base, > >>> controls, graphics are the only ones I'm keeping for change in > >>> Eclipse) in another project: when running any application it's > >>> throwing the stacktrace below. > >>> > >>> My overall setup worked fine before (didn't dig yet when it started > >>> not to), running the tests inside the fx projects themselves is fine, > >>> though. > >>> > >>> Looks like there is something missing (native?) related to graphics. > >>> > >>> Where to start looking for the reason? > >>> > >>> Stacktrace: > >>> > >>> java.lang.ClassNotFoundException: > >>> com.sun.prism.shader.FillPgram_Color_Loader > >>> at > >>> > >>> > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) > >>> at > >>> > >>> > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > >>> at > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > >>> at java.base/java.lang.Class.forName0(Native Method) > >>> at java.base/java.lang.Class.forName(Class.java:332) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > >>> at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > >>> at > >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > >>> at > >>> > >>> > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > >>> at > >>> > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > >>> at > >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > >>> at java.base/java.lang.Thread.run(Thread.java:835) > >>> java.lang.InternalError: Error loading stock shader FillPgram_Color > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > >>> at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > >>> at > >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > >>> at > >>> > >>> > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > >>> at > >>> > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > >>> at > >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > >>> at java.base/java.lang.Thread.run(Thread.java:835) > >>> > >>> -- Thanks, Jeanette > >>> > >>> > >>> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Jul 15 21:01:19 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Jul 2022 21:01:19 GMT Subject: [jfx19] RFR: 8290331 Binding value left null when immediately revalidated in invalidation listener [v2] In-Reply-To: <8CqWcI0hfQMyw0CoIgiUNkWiaxfn2bXpSCe3fYMCVBc=.1358ca1a-6f6b-4d0d-8f5b-39fd99d4fa6c@github.com> References: <8CqWcI0hfQMyw0CoIgiUNkWiaxfn2bXpSCe3fYMCVBc=.1358ca1a-6f6b-4d0d-8f5b-39fd99d4fa6c@github.com> Message-ID: <1dsDfEToMpi4_R3J5msN40nxvzdS-tVg3zanHBLegrc=.cb119939-9dd3-4fea-9b94-2e3846e2b432@github.com> On Fri, 15 Jul 2022 07:19:19 GMT, John Hendrikx wrote: >> I introduced a bug with the fluent bindings PR which affects all ObjectBindings. >> >> This is the code that fails: >> >> SimpleObjectProperty condition = new SimpleObjectProperty<>(true); >> ObservableValue binding = condition.map(Object::toString); >> >> binding.addListener(o -> { binding.getValue(); }); >> >> condition.set(false); >> >> assertEquals(false, binding.getValue()); // returns null (!) >> >> This PR fixes this problem and adds a test case to cover it. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Change explanatory comment to block comment Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/829 From nlisker at gmail.com Fri Jul 15 22:32:47 2022 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 16 Jul 2022 01:32:47 +0300 Subject: [External] : Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> <8d1f8597-94d0-b691-9e73-0b1b3181edd4@oracle.com> Message-ID: > > > 1. Unfortunately, even with ?ignore optional problems? Eclipse > generates the ?missing required source folder?. > > I added the following to the classpath of graphics: Eclipse adds the non-existent source folder even though there is no such directory and does not complain. We should be able to revert the changes done to the graphics classpath file and then add the other platform-specific entries. Worst case, we could generate an empty folder, but that would require changing the build, which is not the best approach. I also managed to reproduce the runtime error by using an application that uses fonts. If you know what the Mac/Linux-specific folders are, I will add them to my classpath and see if everything works for me. On Fri, Jul 15, 2022 at 10:34 PM Nir Lisker wrote: > Ah, I missed that it's during runtime. When I reviewed the PR I tested an > external project which relies on the graphics module and it worked fine. I > will try to find a case that throws this error and see what can be done. > > On Fri, Jul 15, 2022 at 9:22 PM Andy Goryachev > wrote: > >> Nir: >> >> >> >> 1. Unfortunately, even with ?ignore optional problems? Eclipse >> generates the ?missing required source folder?. Below are the four entries >> I?ve added to modules/javafx.graphics/.classpath: >> >> >> >> >> >> >> >> > "true"/> >> >> >> >> >> >> >> >> >> >> > "true"/> >> >> >> >> >> >> >> >> >> >> > "true"/> >> >> >> >> >> >> >> >> >> >> > "true"/> >> >> >> >> > "src/main/java"/> >> >> >> >> >> >> 1. The classes in build/gensrc/ generate a runtime exception, not a >> build error. I wonder if perhaps we should add an entry to the library >> path instead. Let me check on this. >> >> >> >> 1. Again, Jeanette?s report was about runtime error. I wonder though >> if we have / should have a file that documents where reflection is being >> used. (Perhaps it already exists somewhere? Searching for ?reflection? >> turned out 4.5K hits?) >> >> >> >> What do you think? >> >> >> >> -andy >> >> >> >> *From: *Nir Lisker >> *Date: *Friday, 2022/07/15 at 11:04 >> *To: *Andy Goryachev , Jeanette Winzenburg < >> fastegal at swingempire.de> >> *Cc: *Kevin Rushforth , >> openjfx-dev at openjdk.org >> *Subject: *[External] : Re: Eclipse: ClassNotFoundException: >> com.sun.prism.shader.FillPgram_Color_Loader >> >> First of all, you can set "ignore optional compile problems" on a source >> folder in Eclipse. In fact, these folders were set as such before the >> change. >> >> >> >> But more importantly, I don't see how classes that are only used in >> reflection will cause a build error. If these folders are not referenced in >> compile time, Eclipse doesn't need them as source folders. >> >> >> >> Jeanette, the Problems view in Eclipse has a table where it shows the >> problem and the resource and path from which the error originates. If you >> get errors because of missing OS-specific folders, it's crucial to know >> what reports those errors, that is, who is looking for these folders. >> >> >> >> On Fri, Jul 15, 2022 at 8:17 PM Andy Goryachev >> wrote: >> >> Kevin: >> >> >> >> The four classpath entries in question are >> >> build/hlsl/Prism >> >> build/gensrc/jsl-prism >> >> build/hlsl/Decora >> >> build/gensrc/jsl-decora >> >> >> >> once added to the Eclipse .classpath file (in graphics) I see two >> warnings (on Mac): >> >> >> >> Project 'graphics' is missing required source folder: >> 'build/hlsl/Decora' Build path graphics >> >> Project 'graphics' is missing required source folder: >> 'build/hlsl/Prism' Build path graphics >> >> >> >> For the moment I cannot verify the situation on Windows or Linux, but I >> think Nir mentioned that these directories might be created on Windows, so >> this is my current assumption. >> >> >> >> The problem in Eclipse is that these warnings (incomplete build path) >> cannot be turned off. One solution is to (re)create the missing >> directories manually after each [gradle clean]. The other solution is to >> modify gradle build to always create these directories, even if they are >> not used. This step is usually in ?init? target in the builds that utilize >> clean-init-build cycle. >> >> >> >> What could be the problem in creating empty directories? >> >> >> >> >> >> - Is there a way to make it conditional? >> >> >> >> In theory, yes, via classpath variables: >> >> >> >> >> https://stackoverflow.com/questions/495264/how-can-i-specify-an-eclipse-classpath-entry-for-specific-o-s-platform >> >> >> >> >> I?ve never used this before. So far these directories are the only place >> where we have platform differences in the classpath. >> >> >> >> Could someone with a Windows machine verify that 'build/hlsl/Decora' and >> 'build/hlsl/Prism' are not empty please? >> >> >> >> Thank you >> >> -andy >> >> >> >> >> >> >> >> *From: *openjfx-dev on behalf of Kevin >> Rushforth >> *Date: *Friday, 2022/07/15 at 09:51 >> *To: *openjfx-dev at openjdk.org >> *Subject: *Re: Eclipse: ClassNotFoundException: >> com.sun.prism.shader.FillPgram_Color_Loader >> >> >> >> On 7/15/2022 9:05 AM, Andy Goryachev wrote: >> >> Nir: >> >> >> >> So these folders are not needed to compile, but they are needed to run. >> >> >> >> I suggest we bring them back to .classpath >> >> >> Is there a way to make it conditional? >> >> and also modify build.gradle to create all 4 folders as a part of the >> corresponding target. >> >> >> I am not in favor of this change. There are platform-specific parts of >> the build, so IDEs should be able to adapt to this. >> >> -- Kevin >> >> >> >> >> What do you think? >> >> >> >> -andy >> >> >> >> >> >> >> >> *From: *openjfx-dev >> on behalf of Jeanette Winzenburg >> >> *Date: *Friday, 2022/07/15 at 03:19 >> *To: *openjfx-dev at openjdk.org >> >> *Subject: *Re: Eclipse: ClassNotFoundException: >> com.sun.prism.shader.FillPgram_Color_Loader >> >> >> Zitat von Nir Lisker : >> >> Hi Nir, >> >> thanks for the explanation - though I have no idea why Eclipse wants >> them (see them again after re-adding as source folders and all running >> as before). >> >> Not sure where to go from here, would prefer not to have a local >> classpath that differs from the one in the repository .. hmm >> >> -- Jeanette >> >> > To be more specific, FillPgram_Color_Loader.java is located under the >> > build/gensrc folder, which is created during the javafx setup depending >> on >> > the OS. Specifically, it's under build/gensrc/jsl-prism, which is >> > Windows-specific. >> > The change to the classpath file removed these folders from the source >> > folders list in the build path, so I don't know why you would get this >> > error. Nothing in the "main" source folders references these in >> compile- or >> > build-time. >> > >> > On Fri, Jul 15, 2022 at 12:51 PM Nir Lisker >> wrote: >> > >> >> The Eclipse project files were updated recently in >> >> https://github.com/openjdk/jfx/pull/804 >> . >> The OS-specific folders were >> >> removed. I tested it and I had no issue after this change. On what >> resource >> >> are you getting this error? >> >> >> >> On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < >> >> fastegal at swingempire.de> wrote: >> >> >> >>> >> >>> Hi, >> >>> >> >>> after synching my master branch with upstream (has been a long while >> >>> since my previous update ;), I can't use the Eclipse projects (base, >> >>> controls, graphics are the only ones I'm keeping for change in >> >>> Eclipse) in another project: when running any application it's >> >>> throwing the stacktrace below. >> >>> >> >>> My overall setup worked fine before (didn't dig yet when it started >> >>> not to), running the tests inside the fx projects themselves is fine, >> >>> though. >> >>> >> >>> Looks like there is something missing (native?) related to graphics. >> >>> >> >>> Where to start looking for the reason? >> >>> >> >>> Stacktrace: >> >>> >> >>> java.lang.ClassNotFoundException: >> >>> com.sun.prism.shader.FillPgram_Color_Loader >> >>> at >> >>> >> >>> >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) >> >>> at >> >>> >> >>> >> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >> >>> at >> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >> >>> at java.base/java.lang.Class.forName0(Native Method) >> >>> at java.base/java.lang.Class.forName(Class.java:332) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >> >>> at >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> >>> at >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >> >>> at >> >>> >> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >> >>> at >> >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >> >>> at java.base/java.lang.Thread.run(Thread.java:835) >> >>> java.lang.InternalError: Error loading stock shader FillPgram_Color >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >> >>> at >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> >>> at >> >>> >> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >> >>> at >> >>> >> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >> >>> at >> >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> >>> at >> >>> >> >>> >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> >>> at >> >>> >> >>> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >> >>> at java.base/java.lang.Thread.run(Thread.java:835) >> >>> >> >>> -- Thanks, Jeanette >> >>> >> >>> >> >>> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Fri Jul 15 22:42:17 2022 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 15 Jul 2022 22:42:17 +0000 Subject: [External] : Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> <8d1f8597-94d0-b691-9e73-0b1b3181edd4@oracle.com> Message-ID: Nir: Which version of eclipse are you on? I've added your entry and my Eclipse (2022-06 4.24.0 on Mac) complains about Project 'graphics' is missing required source folder: 'build/hi' Build path graphics It does not allow to ignore this problem, as the only choices are "error" and "warning": [cid:image001.png at 01D89861.6F155BB0] What is the fear of modifying the build.gradle? -a From: Nir Lisker Date: Friday, 2022/07/15 at 15:33 To: Andy Goryachev Cc: Jeanette Winzenburg , Kevin Rushforth , openjfx-dev at openjdk.org Subject: Re: [External] : Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader 1. Unfortunately, even with ?ignore optional problems? Eclipse generates the ?missing required source folder?. I added the following to the classpath of graphics: Eclipse adds the non-existent source folder even though there is no such directory and does not complain. We should be able to revert the changes done to the graphics classpath file and then add the other platform-specific entries. Worst case, we could generate an empty folder, but that would require changing the build, which is not the best approach. I also managed to reproduce the runtime error by using an application that uses fonts. If you know what the Mac/Linux-specific folders are, I will add them to my classpath and see if everything works for me. On Fri, Jul 15, 2022 at 10:34 PM Nir Lisker > wrote: Ah, I missed that it's during runtime. When I reviewed the PR I tested an external project which relies on the graphics module and it worked fine. I will try to find a case that throws this error and see what can be done. On Fri, Jul 15, 2022 at 9:22 PM Andy Goryachev > wrote: Nir: 1. Unfortunately, even with ?ignore optional problems? Eclipse generates the ?missing required source folder?. Below are the four entries I?ve added to modules/javafx.graphics/.classpath: 1. The classes in build/gensrc/ generate a runtime exception, not a build error. I wonder if perhaps we should add an entry to the library path instead. Let me check on this. 1. Again, Jeanette?s report was about runtime error. I wonder though if we have / should have a file that documents where reflection is being used. (Perhaps it already exists somewhere? Searching for ?reflection? turned out 4.5K hits?) What do you think? -andy From: Nir Lisker > Date: Friday, 2022/07/15 at 11:04 To: Andy Goryachev >, Jeanette Winzenburg > Cc: Kevin Rushforth >, openjfx-dev at openjdk.org > Subject: [External] : Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader First of all, you can set "ignore optional compile problems" on a source folder in Eclipse. In fact, these folders were set as such before the change. But more importantly, I don't see how classes that are only used in reflection will cause a build error. If these folders are not referenced in compile time, Eclipse doesn't need them as source folders. Jeanette, the Problems view in Eclipse has a table where it shows the problem and the resource and path from which the error originates. If you get errors because of missing OS-specific folders, it's crucial to know what reports those errors, that is, who is looking for these folders. On Fri, Jul 15, 2022 at 8:17 PM Andy Goryachev > wrote: Kevin: The four classpath entries in question are build/hlsl/Prism build/gensrc/jsl-prism build/hlsl/Decora build/gensrc/jsl-decora once added to the Eclipse .classpath file (in graphics) I see two warnings (on Mac): Project 'graphics' is missing required source folder: 'build/hlsl/Decora' Build path graphics Project 'graphics' is missing required source folder: 'build/hlsl/Prism' Build path graphics For the moment I cannot verify the situation on Windows or Linux, but I think Nir mentioned that these directories might be created on Windows, so this is my current assumption. The problem in Eclipse is that these warnings (incomplete build path) cannot be turned off. One solution is to (re)create the missing directories manually after each [gradle clean]. The other solution is to modify gradle build to always create these directories, even if they are not used. This step is usually in ?init? target in the builds that utilize clean-init-build cycle. What could be the problem in creating empty directories? * Is there a way to make it conditional? In theory, yes, via classpath variables: https://stackoverflow.com/questions/495264/how-can-i-specify-an-eclipse-classpath-entry-for-specific-o-s-platform I?ve never used this before. So far these directories are the only place where we have platform differences in the classpath. Could someone with a Windows machine verify that 'build/hlsl/Decora' and 'build/hlsl/Prism' are not empty please? Thank you -andy From: openjfx-dev > on behalf of Kevin Rushforth > Date: Friday, 2022/07/15 at 09:51 To: openjfx-dev at openjdk.org > Subject: Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader On 7/15/2022 9:05 AM, Andy Goryachev wrote: Nir: So these folders are not needed to compile, but they are needed to run. I suggest we bring them back to .classpath Is there a way to make it conditional? and also modify build.gradle to create all 4 folders as a part of the corresponding target. I am not in favor of this change. There are platform-specific parts of the build, so IDEs should be able to adapt to this. -- Kevin What do you think? -andy From: openjfx-dev on behalf of Jeanette Winzenburg Date: Friday, 2022/07/15 at 03:19 To: openjfx-dev at openjdk.org Subject: Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader Zitat von Nir Lisker : Hi Nir, thanks for the explanation - though I have no idea why Eclipse wants them (see them again after re-adding as source folders and all running as before). Not sure where to go from here, would prefer not to have a local classpath that differs from the one in the repository .. hmm -- Jeanette > To be more specific, FillPgram_Color_Loader.java is located under the > build/gensrc folder, which is created during the javafx setup depending on > the OS. Specifically, it's under build/gensrc/jsl-prism, which is > Windows-specific. > The change to the classpath file removed these folders from the source > folders list in the build path, so I don't know why you would get this > error. Nothing in the "main" source folders references these in compile- or > build-time. > > On Fri, Jul 15, 2022 at 12:51 PM Nir Lisker wrote: > >> The Eclipse project files were updated recently in >> https://github.com/openjdk/jfx/pull/804. The OS-specific folders were >> removed. I tested it and I had no issue after this change. On what resource >> are you getting this error? >> >> On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < >> fastegal at swingempire.de> wrote: >> >>> >>> Hi, >>> >>> after synching my master branch with upstream (has been a long while >>> since my previous update ;), I can't use the Eclipse projects (base, >>> controls, graphics are the only ones I'm keeping for change in >>> Eclipse) in another project: when running any application it's >>> throwing the stacktrace below. >>> >>> My overall setup worked fine before (didn't dig yet when it started >>> not to), running the tests inside the fx projects themselves is fine, >>> though. >>> >>> Looks like there is something missing (native?) related to graphics. >>> >>> Where to start looking for the reason? >>> >>> Stacktrace: >>> >>> java.lang.ClassNotFoundException: >>> com.sun.prism.shader.FillPgram_Color_Loader >>> at >>> >>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) >>> at >>> >>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >>> at java.base/java.lang.Class.forName0(Native Method) >>> at java.base/java.lang.Class.forName(Class.java:332) >>> at >>> >>> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >>> at >>> >>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >>> at >>> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >>> at >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >>> at java.base/java.lang.Thread.run(Thread.java:835) >>> java.lang.InternalError: Error loading stock shader FillPgram_Color >>> at >>> >>> javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >>> at >>> >>> javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >>> at >>> >>> javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >>> at >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >>> at >>> >>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >>> at >>> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >>> at >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >>> at >>> >>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >>> at java.base/java.lang.Thread.run(Thread.java:835) >>> >>> -- Thanks, Jeanette >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 146611 bytes Desc: image001.png URL: From jhendrikx at openjdk.org Fri Jul 15 23:40:12 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 15 Jul 2022 23:40:12 GMT Subject: [jfx19] Integrated: 8290331 Binding value left null when immediately revalidated in invalidation listener In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 23:37:31 GMT, John Hendrikx wrote: > I introduced a bug with the fluent bindings PR which affects all ObjectBindings. > > This is the code that fails: > > SimpleObjectProperty condition = new SimpleObjectProperty<>(true); > ObservableValue binding = condition.map(Object::toString); > > binding.addListener(o -> { binding.getValue(); }); > > condition.set(false); > > assertEquals(false, binding.getValue()); // returns null (!) > > This PR fixes this problem and adds a test case to cover it. This pull request has now been integrated. Changeset: 4959f1bc Author: John Hendrikx Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/4959f1bce6078230353af4ed6552e1415b1adfaa Stats: 27 lines in 2 files changed: 26 ins; 0 del; 1 mod 8290331: Binding value left null when immediately revalidated in invalidation listener Reviewed-by: mstrauss, kcr ------------- PR: https://git.openjdk.org/jfx/pull/829 From kevin.rushforth at oracle.com Fri Jul 15 23:35:14 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 15 Jul 2022 16:35:14 -0700 Subject: [External] : Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> <8d1f8597-94d0-b691-9e73-0b1b3181edd4@oracle.com> Message-ID: > What is the fear of modifying the build.gradle? Maybe nothing, although we'd need to ensure that those empty dirs don't show up in the build artifacts. I just don't really care for the idea of modifying the product build to work around what looks like an IDE limitation, unless there is no choice and we can prove that it doesn't make a difference to the final artifacts. -- Kevin On 7/15/2022 3:42 PM, Andy Goryachev wrote: > > Nir: > > Which version of eclipse are you on? > > I've added your entry and my Eclipse (2022-06 4.24.0 on Mac) complains > about > > Project 'graphics' is missing required source folder: 'build/hi' Build > path ???? graphics > > It does not allow to ignore this problem, as the only choices are > "error" and "warning": > > What is the fear of modifying the build.gradle? > > -a > > *From: *Nir Lisker > *Date: *Friday, 2022/07/15 at 15:33 > *To: *Andy Goryachev > *Cc: *Jeanette Winzenburg , Kevin Rushforth > , openjfx-dev at openjdk.org > > *Subject: *Re: [External] : Re: Eclipse: ClassNotFoundException: > com.sun.prism.shader.FillPgram_Color_Loader > > 1. Unfortunately, even with ?ignore optional problems? Eclipse > generates the ?missing required source folder?. > > I added the following to the classpath of graphics: > > ? > ? ? > ? ? ? ? > ? ? > > > > Eclipse adds the non-existent?source folder even though there is no > such directory and does not complain. We should be able to revert the > changes done to the graphics classpath file and then add the other > platform-specific entries. > > Worst case, we could generate an empty folder, but that would require > changing the build, which is not the best approach. > > I also managed to reproduce the runtime error by using an application > that uses fonts. If you know what the Mac/Linux-specific folders are, > I will add them to my classpath and see if everything works for me. > > On Fri, Jul 15, 2022 at 10:34 PM Nir Lisker wrote: > > Ah, I missed that it's during runtime. When I reviewed the PR I > tested an external project which relies on the graphics module and > it worked fine. I will try to find a case that throws this error > and see what can be done. > > On Fri, Jul 15, 2022 at 9:22 PM Andy Goryachev > wrote: > > Nir: > > 1. Unfortunately, even with ?ignore optional problems? > Eclipse generates the ?missing required source folder?.? > Below are the four entries I?ve added to > modules/javafx.graphics/.classpath: > > > > ??????????????? > > > > ??????????????? > > ??????? > > > > ??????????????? > > > > ??????????????? > > ??????? > > > > ??????????????? > > > > ??????????????? > > ??????? > > > > ??????????????? > > > > ??????????????? > > ??????? path="src/main/java"/> > > 2. The classes in build/gensrc/ generate a runtime exception, > not a build error.? I wonder if perhaps we should add an > entry to the library path instead.? Let me check on this. > > 3. Again, Jeanette?s report was about runtime error.? I > wonder though if we have / should have a file that > documents where reflection is being used.? (Perhaps it > already exists somewhere?? Searching for ?reflection? > turned out 4.5K hits?) > > What do you think? > > -andy > > *From: *Nir Lisker > *Date: *Friday, 2022/07/15 at 11:04 > *To: *Andy Goryachev , Jeanette > Winzenburg > *Cc: *Kevin Rushforth , > openjfx-dev at openjdk.org > *Subject: *[External] : Re: Eclipse: ClassNotFoundException: > com.sun.prism.shader.FillPgram_Color_Loader > > First of all, you can set "ignore optional compile problems" > on a source folder in Eclipse. In fact, these folders were set > as such before the change. > > But more importantly, I don't see how classes that are only > used in reflection will cause a build error. If these folders > are not referenced in compile time, Eclipse doesn't need them > as source folders. > > Jeanette, the Problems view in Eclipse has a table where it > shows the problem and the resource and path from which the > error originates. If you get errors because of missing > OS-specific folders, it's crucial to know what reports those > errors, that is, who is looking for these folders. > > On Fri, Jul 15, 2022 at 8:17 PM Andy Goryachev > wrote: > > Kevin: > > The four classpath entries in question are > > build/hlsl/Prism > > build/gensrc/jsl-prism > > build/hlsl/Decora > > build/gensrc/jsl-decora > > once added to the Eclipse .classpath file (in graphics) I > see two warnings (on Mac): > > Project 'graphics' is missing required source folder: > 'build/hlsl/Decora' Build path???????????????????? graphics > > Project 'graphics' is missing required source folder: > 'build/hlsl/Prism' Build path???????????????????? graphics > > For the moment I cannot verify the situation on Windows or > Linux, but I think Nir mentioned that these directories > might be created on Windows, so this is my current assumption. > > The problem in Eclipse is that these warnings (incomplete > build path) cannot be turned off.? One solution is to > (re)create the missing directories manually after each > [gradle clean].? The other solution is to modify gradle > build to always create these directories, even if they are > not used.? This step is usually in ?init? target in the > builds that utilize clean-init-build cycle. > > What could be the problem in creating empty directories? > > * Is there a way to make it conditional? > > In theory, yes, via classpath variables: > > https://stackoverflow.com/questions/495264/how-can-i-specify-an-eclipse-classpath-entry-for-specific-o-s-platform > > > I?ve never used this before.? So far these directories are > the only place where we have platform differences in the > classpath. > > Could someone with a Windows machine verify that > 'build/hlsl/Decora'and 'build/hlsl/Prism'are not empty please? > > Thank you > > -andy > > *From: *openjfx-dev on > behalf of Kevin Rushforth > *Date: *Friday, 2022/07/15 at 09:51 > *To: *openjfx-dev at openjdk.org > *Subject: *Re: Eclipse: ClassNotFoundException: > com.sun.prism.shader.FillPgram_Color_Loader > > On 7/15/2022 9:05 AM, Andy Goryachev wrote: > > Nir: > > So these folders are not needed to compile, but they > are needed to run. > > I suggest we bring them back to .classpath > > > Is there a way to make it conditional? > > and also modify build.gradle to create all 4 folders > as a part of the corresponding target. > > > I am not in favor of this change. There are > platform-specific parts of the build, so IDEs should be > able to adapt to this. > > -- Kevin > > What do you think? > > -andy > > *From: *openjfx-dev > on behalf of > Jeanette Winzenburg > > *Date: *Friday, 2022/07/15 at 03:19 > *To: *openjfx-dev at openjdk.org > > *Subject: *Re: Eclipse: ClassNotFoundException: > com.sun.prism.shader.FillPgram_Color_Loader > > > Zitat von Nir Lisker > : > > Hi Nir, > > thanks for the explanation - though I have no idea why > Eclipse wants > them (see them again after re-adding as source folders > and all running > as before). > > Not sure where to go from here, would prefer not to > have a local > classpath that differs from the one in the repository > .. hmm > > -- Jeanette > > > To be more specific, FillPgram_Color_Loader.java is > located under the > > build/gensrc folder, which is created during the > javafx setup depending on > > the OS. Specifically, it's under > build/gensrc/jsl-prism, which is > > Windows-specific. > > The change to the classpath file removed these > folders from the source > > folders list in the build path, so I don't know why > you would get this > > error. Nothing in the "main" source folders > references these in compile- or > > build-time. > > > > On Fri, Jul 15, 2022 at 12:51 PM Nir Lisker > wrote: > > > >> The Eclipse project files were updated recently in > >> https://github.com/openjdk/jfx/pull/804 > . > The OS-specific folders were > >> removed. I tested it and I had no issue after this > change. On what resource > >> are you getting this error? > >> > >> On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < > >> fastegal at swingempire.de> wrote: > >> > >>> > >>> Hi, > >>> > >>> after synching my master branch with upstream (has > been a long while > >>> since my previous update ;), I can't use the > Eclipse projects (base, > >>> controls, graphics are the only ones I'm keeping > for change in > >>> Eclipse) in another project: when running any > application it's > >>> throwing the stacktrace below. > >>> > >>> My overall setup worked fine before (didn't dig > yet when it started > >>> not to), running the tests inside the fx projects > themselves is fine, > >>> though. > >>> > >>> Looks like there is something missing (native?) > related to graphics. > >>> > >>> Where to start looking for the reason? > >>> > >>> Stacktrace: > >>> > >>> java.lang.ClassNotFoundException: > >>> com.sun.prism.shader.FillPgram_Color_Loader > >>>???????? at > >>> > >>> > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) > >>>???????? at > >>> > >>> > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > >>>???????? at > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > >>>???????? at > java.base/java.lang.Class.forName0(Native Method) > >>>???????? at > java.base/java.lang.Class.forName(Class.java:332) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > >>>???????? at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > >>>???????? at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > >>>???????? at > >>> > >>> > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > >>>???????? at > >>> > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > >>>???????? at > >>> > javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > >>>???????? at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > >>>???????? at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > >>>???????? at > java.base/java.lang.Thread.run(Thread.java:835) > >>> java.lang.InternalError: Error loading stock > shader FillPgram_Color > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > >>>???????? at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > >>>???????? at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > >>>???????? at > >>> > >>> > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > >>>???????? at > >>> > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > >>>???????? at > >>> > javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > >>>???????? at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > >>>???????? at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > >>>???????? at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > >>>???????? at > java.base/java.lang.Thread.run(Thread.java:835) > >>> > >>> -- Thanks, Jeanette > >>> > >>> > >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 146611 bytes Desc: not available URL: From nlisker at gmail.com Sat Jul 16 00:07:43 2022 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 16 Jul 2022 03:07:43 +0300 Subject: [External] : Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> <8d1f8597-94d0-b691-9e73-0b1b3181edd4@oracle.com> Message-ID: I'm using 4.24 and I didn't touch the build options. Possibly Eclipse works differently on different platforms, but that would be a bug. [image: image.png][image: image.png] I have no folder and the project builds fine. I might need to test on Linux. On Sat, Jul 16, 2022 at 1:42 AM Andy Goryachev wrote: > Nir: > > > > Which version of eclipse are you on? > > > > I've added your entry and my Eclipse (2022-06 4.24.0 on Mac) complains > about > > > > Project 'graphics' is missing required source folder: 'build/hi' Build > path graphics > > > > It does not allow to ignore this problem, as the only choices are "error" > and "warning": > > > > > > > > > > What is the fear of modifying the build.gradle? > > > > -a > > > > > > *From: *Nir Lisker > *Date: *Friday, 2022/07/15 at 15:33 > *To: *Andy Goryachev > *Cc: *Jeanette Winzenburg , Kevin Rushforth < > kevin.rushforth at oracle.com>, openjfx-dev at openjdk.org < > openjfx-dev at openjdk.org> > *Subject: *Re: [External] : Re: Eclipse: ClassNotFoundException: > com.sun.prism.shader.FillPgram_Color_Loader > > > 1. Unfortunately, even with ?ignore optional problems? Eclipse > generates the ?missing required source folder?. > > > > I added the following to the classpath of graphics: > > > > > > > > > > > > > Eclipse adds the non-existent source folder even though there is no such > directory and does not complain. We should be able to revert the changes > done to the graphics classpath file and then add the other > platform-specific entries. > > Worst case, we could generate an empty folder, but that would require > changing the build, which is not the best approach. > > > > I also managed to reproduce the runtime error by using an application that > uses fonts. If you know what the Mac/Linux-specific folders are, I will add > them to my classpath and see if everything works for me. > > > > On Fri, Jul 15, 2022 at 10:34 PM Nir Lisker wrote: > > Ah, I missed that it's during runtime. When I reviewed the PR I tested an > external project which relies on the graphics module and it worked fine. I > will try to find a case that throws this error and see what can be done. > > > > On Fri, Jul 15, 2022 at 9:22 PM Andy Goryachev > wrote: > > Nir: > > > > 1. Unfortunately, even with ?ignore optional problems? Eclipse > generates the ?missing required source folder?. Below are the four entries > I?ve added to modules/javafx.graphics/.classpath: > > > > > > > > value="true"/> > > > > > > > > > > value="true"/> > > > > > > > > > > value="true"/> > > > > > > > > > > value="true"/> > > > > path="src/main/java"/> > > > > > > 1. The classes in build/gensrc/ generate a runtime exception, not a > build error. I wonder if perhaps we should add an entry to the library > path instead. Let me check on this. > > > > 1. Again, Jeanette?s report was about runtime error. I wonder though > if we have / should have a file that documents where reflection is being > used. (Perhaps it already exists somewhere? Searching for ?reflection? > turned out 4.5K hits?) > > > > What do you think? > > > > -andy > > > > *From: *Nir Lisker > *Date: *Friday, 2022/07/15 at 11:04 > *To: *Andy Goryachev , Jeanette Winzenburg < > fastegal at swingempire.de> > *Cc: *Kevin Rushforth , > openjfx-dev at openjdk.org > *Subject: *[External] : Re: Eclipse: ClassNotFoundException: > com.sun.prism.shader.FillPgram_Color_Loader > > First of all, you can set "ignore optional compile problems" on a source > folder in Eclipse. In fact, these folders were set as such before the > change. > > > > But more importantly, I don't see how classes that are only used in > reflection will cause a build error. If these folders are not referenced in > compile time, Eclipse doesn't need them as source folders. > > > > Jeanette, the Problems view in Eclipse has a table where it shows the > problem and the resource and path from which the error originates. If you > get errors because of missing OS-specific folders, it's crucial to know > what reports those errors, that is, who is looking for these folders. > > > > On Fri, Jul 15, 2022 at 8:17 PM Andy Goryachev > wrote: > > Kevin: > > > > The four classpath entries in question are > > build/hlsl/Prism > > build/gensrc/jsl-prism > > build/hlsl/Decora > > build/gensrc/jsl-decora > > > > once added to the Eclipse .classpath file (in graphics) I see two warnings > (on Mac): > > > > Project 'graphics' is missing required source folder: > 'build/hlsl/Decora' Build path graphics > > Project 'graphics' is missing required source folder: > 'build/hlsl/Prism' Build path graphics > > > > For the moment I cannot verify the situation on Windows or Linux, but I > think Nir mentioned that these directories might be created on Windows, so > this is my current assumption. > > > > The problem in Eclipse is that these warnings (incomplete build path) > cannot be turned off. One solution is to (re)create the missing > directories manually after each [gradle clean]. The other solution is to > modify gradle build to always create these directories, even if they are > not used. This step is usually in ?init? target in the builds that utilize > clean-init-build cycle. > > > > What could be the problem in creating empty directories? > > > > > > - Is there a way to make it conditional? > > > > In theory, yes, via classpath variables: > > > > > https://stackoverflow.com/questions/495264/how-can-i-specify-an-eclipse-classpath-entry-for-specific-o-s-platform > > > > > I?ve never used this before. So far these directories are the only place > where we have platform differences in the classpath. > > > > Could someone with a Windows machine verify that 'build/hlsl/Decora' and > 'build/hlsl/Prism' are not empty please? > > > > Thank you > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Kevin > Rushforth > *Date: *Friday, 2022/07/15 at 09:51 > *To: *openjfx-dev at openjdk.org > *Subject: *Re: Eclipse: ClassNotFoundException: > com.sun.prism.shader.FillPgram_Color_Loader > > > > On 7/15/2022 9:05 AM, Andy Goryachev wrote: > > Nir: > > > > So these folders are not needed to compile, but they are needed to run. > > > > I suggest we bring them back to .classpath > > > Is there a way to make it conditional? > > and also modify build.gradle to create all 4 folders as a part of the > corresponding target. > > > I am not in favor of this change. There are platform-specific parts of the > build, so IDEs should be able to adapt to this. > > -- Kevin > > > > What do you think? > > > > -andy > > > > > > > > *From: *openjfx-dev > on behalf of Jeanette Winzenburg > > *Date: *Friday, 2022/07/15 at 03:19 > *To: *openjfx-dev at openjdk.org > > *Subject: *Re: Eclipse: ClassNotFoundException: > com.sun.prism.shader.FillPgram_Color_Loader > > > Zitat von Nir Lisker : > > Hi Nir, > > thanks for the explanation - though I have no idea why Eclipse wants > them (see them again after re-adding as source folders and all running > as before). > > Not sure where to go from here, would prefer not to have a local > classpath that differs from the one in the repository .. hmm > > -- Jeanette > > > To be more specific, FillPgram_Color_Loader.java is located under the > > build/gensrc folder, which is created during the javafx setup depending > on > > the OS. Specifically, it's under build/gensrc/jsl-prism, which is > > Windows-specific. > > The change to the classpath file removed these folders from the source > > folders list in the build path, so I don't know why you would get this > > error. Nothing in the "main" source folders references these in compile- > or > > build-time. > > > > On Fri, Jul 15, 2022 at 12:51 PM Nir Lisker > wrote: > > > >> The Eclipse project files were updated recently in > >> https://github.com/openjdk/jfx/pull/804 > . > The OS-specific folders were > >> removed. I tested it and I had no issue after this change. On what > resource > >> are you getting this error? > >> > >> On Fri, Jul 15, 2022 at 12:44 PM Jeanette Winzenburg < > >> fastegal at swingempire.de> wrote: > >> > >>> > >>> Hi, > >>> > >>> after synching my master branch with upstream (has been a long while > >>> since my previous update ;), I can't use the Eclipse projects (base, > >>> controls, graphics are the only ones I'm keeping for change in > >>> Eclipse) in another project: when running any application it's > >>> throwing the stacktrace below. > >>> > >>> My overall setup worked fine before (didn't dig yet when it started > >>> not to), running the tests inside the fx projects themselves is fine, > >>> though. > >>> > >>> Looks like there is something missing (native?) related to graphics. > >>> > >>> Where to start looking for the reason? > >>> > >>> Stacktrace: > >>> > >>> java.lang.ClassNotFoundException: > >>> com.sun.prism.shader.FillPgram_Color_Loader > >>> at > >>> > >>> > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) > >>> at > >>> > >>> > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > >>> at > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > >>> at java.base/java.lang.Class.forName0(Native Method) > >>> at java.base/java.lang.Class.forName(Class.java:332) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:426) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > >>> at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > >>> at > >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > >>> at > >>> > >>> > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > >>> at > >>> > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > >>> at > >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > >>> at java.base/java.lang.Thread.run(Thread.java:835) > >>> java.lang.InternalError: Error loading stock shader FillPgram_Color > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > >>> at > >>> > >>> > javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > >>> at > >>> > javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > >>> at > >>> javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > >>> at > >>> > >>> > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > >>> at > >>> > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > >>> at > >>> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > >>> at > >>> > >>> > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > >>> at > >>> > >>> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > >>> at java.base/java.lang.Thread.run(Thread.java:835) > >>> > >>> -- Thanks, Jeanette > >>> > >>> > >>> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 146611 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 12035 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 4408 bytes Desc: not available URL: From jhendrikx at openjdk.org Sat Jul 16 13:31:46 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 16 Jul 2022 13:31:46 GMT Subject: [jfx19] RFR: 8290393: Fix code sample in docs of ObservableValue#flatMap Message-ID: <4XV6izpEHkc203ylHHi3m-MrNQyialwIB0nEyl8-YIE=.04749240-8beb-4a5d-a936-719823a7585a@github.com> Fix small error in flatmap docs ------------- Commit messages: - Fix code sample in docs of ObservableValue#flatMap Changes: https://git.openjdk.org/jfx/pull/831/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=831&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290393 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/831.diff Fetch: git fetch https://git.openjdk.org/jfx pull/831/head:pull/831 PR: https://git.openjdk.org/jfx/pull/831 From kcr at openjdk.org Sat Jul 16 13:41:05 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 16 Jul 2022 13:41:05 GMT Subject: [jfx19] RFR: 8290393: Fix code sample in docs of ObservableValue#flatMap In-Reply-To: <4XV6izpEHkc203ylHHi3m-MrNQyialwIB0nEyl8-YIE=.04749240-8beb-4a5d-a936-719823a7585a@github.com> References: <4XV6izpEHkc203ylHHi3m-MrNQyialwIB0nEyl8-YIE=.04749240-8beb-4a5d-a936-719823a7585a@github.com> Message-ID: On Sat, 16 Jul 2022 13:24:22 GMT, John Hendrikx wrote: > Fix small error in flatmap docs Looks good. You'll need to change the title of this PR to match the JBS issue (the JBS issue has the better bug title). ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/831 From john.hendrikx at gmail.com Sat Jul 16 14:03:58 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 16 Jul 2022 16:03:58 +0200 Subject: [jfx19] RFR: 8290331 Binding value left null when immediately revalidated in invalidation listener [v2] In-Reply-To: <6lIx4iX1tY_x-G4hbZHnJqYxu0W7egO2q2s1DG8IDHU=.e125103b-f29b-4f04-9368-032c9f06b172@github.com> References: <8CqWcI0hfQMyw0CoIgiUNkWiaxfn2bXpSCe3fYMCVBc=.1358ca1a-6f6b-4d0d-8f5b-39fd99d4fa6c@github.com> <6lIx4iX1tY_x-G4hbZHnJqYxu0W7egO2q2s1DG8IDHU=.e125103b-f29b-4f04-9368-032c9f06b172@github.com> Message-ID: I think the issue in JDK-8206449 might not be entirely resolved. Even though `value` is now cleared in `ObjectBinding`, I noticed that `ExpressionHelper` also maintains the current value when there are change listeners registered. Unfortunately, it forgets to clear this when all change listeners are removed but there are still sufficient invalidation listeners registered for it to need the Generic ExpressionHelper implementation. I think an overhaul of ExpressionHelper might be warranted: - Doesn't clear current value when it should - The locking done makes a new copy of the listener lists each time if there are multiple changes to these lists during an event emission (this can happen easily when many listener stubs have gone out of scope) - Change event emission should probably not be dependent on the order of listeners, see https://bugs.openjdk.org/browse/JDK-8290310 - Further optimizations are possible: ?? - Better remove performance -- although there is no JDK collection class that has fast remove(T) while allowing duplicates, it isn't hard to construct a specialized class that has fast `addLast`, fast `remove(T)` and fast iteration ?? - Single invalidation listener could just use the helper field directly (instanceof check can determine if it is an invalidation listener or a helper instance); this can save quite some memory as the fast majority of properties/bindings may never have more than 1 listener ?? - Single change maybe as well (requires current value to be passed into #fireValueChangedEvent, which is how most other ExpressionHelpers, except the base ExpressionHelper,? are done) -- note that many, if not all, users of ExpressionHelper often also have a copy of the current value maintained separately... ?? - Small listener lists could use a single array (using instanceof to distinguish between invalidation/change) I also find that there is a test for ExpressionHelper, testing a ton of edge cases, but I think this class shouldn't be tested at all.? Instead, a test should be there to test the behavior of classes implementing Observable and ObservableValue, regardless of whether they use ExpressionHelper internally. Such a test would be reusable, regardless of how these classes manage their listeners, or if some decide to not use `ExpressionHelper`. A good JUnit test should I think be constructed first, validating the current behavior based on classes implementing Observable and ObservableValue; these should be thorough enough to cover most (if not all) of the edge cases now tested in ExpressionHelperTest. With any luck, the test can be written in such a way that it can be parameterized on the type of class implementing ObservableValue, allowing a single test to test behavior of all *Property classes and all *Binding classes. --John On 15/07/2022 16:09, Nir Lisker wrote: > On Fri, 15 Jul 2022 07:19:19 GMT, John Hendrikx wrote: > >>> I introduced a bug with the fluent bindings PR which affects all ObjectBindings. >>> >>> This is the code that fails: >>> >>> SimpleObjectProperty condition = new SimpleObjectProperty<>(true); >>> ObservableValue binding = condition.map(Object::toString); >>> >>> binding.addListener(o -> { binding.getValue(); }); >>> >>> condition.set(false); >>> >>> assertEquals(false, binding.getValue()); // returns null (!) >>> >>> This PR fixes this problem and adds a test case to cover it. >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Change explanatory comment to block comment > Alright, I closed [JDK-8206449](https://bugs.openjdk.org/browse/JDK-8206449) as duplicated of [JDK-8274771](https://bugs.openjdk.org/browse/JDK-8274771). > > ------------- > > PR: https://git.openjdk.org/jfx/pull/829 From jhendrikx at openjdk.org Sat Jul 16 14:20:53 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 16 Jul 2022 14:20:53 GMT Subject: [jfx19] Integrated: 8290393: Code sample in javadoc of ObservableValue flatMap is incorrect In-Reply-To: <4XV6izpEHkc203ylHHi3m-MrNQyialwIB0nEyl8-YIE=.04749240-8beb-4a5d-a936-719823a7585a@github.com> References: <4XV6izpEHkc203ylHHi3m-MrNQyialwIB0nEyl8-YIE=.04749240-8beb-4a5d-a936-719823a7585a@github.com> Message-ID: On Sat, 16 Jul 2022 13:24:22 GMT, John Hendrikx wrote: > Fix small error in flatmap docs This pull request has now been integrated. Changeset: 92cefceb Author: John Hendrikx Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/92cefceb68aa8c521fb95dfba3439e0fa30dcfc6 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8290393: Code sample in javadoc of ObservableValue flatMap is incorrect Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/831 From nlisker at openjdk.org Sat Jul 16 14:54:43 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 16 Jul 2022 14:54:43 GMT Subject: [jfx19] RFR: 8290393: Code sample in javadoc of ObservableValue flatMap is incorrect In-Reply-To: <4XV6izpEHkc203ylHHi3m-MrNQyialwIB0nEyl8-YIE=.04749240-8beb-4a5d-a936-719823a7585a@github.com> References: <4XV6izpEHkc203ylHHi3m-MrNQyialwIB0nEyl8-YIE=.04749240-8beb-4a5d-a936-719823a7585a@github.com> Message-ID: <01IHTTG_t10aPmqYBL0XL2DzgRZKpeEUdpD8yB-vnN4=.4aef6359-6bf4-4194-a833-c6d683c88b31@github.com> On Sat, 16 Jul 2022 13:24:22 GMT, John Hendrikx wrote: > Fix small error in flatmap docs If we bump to Java 18 we would be able to use [JEP 413: Code Snippets in Java API Documentation](https://openjdk.org/jeps/413) and avoid these errors :) ------------- PR: https://git.openjdk.org/jfx/pull/831 From kcr at openjdk.org Sat Jul 16 15:21:58 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 16 Jul 2022 15:21:58 GMT Subject: RFR: Merge jfx19 Message-ID: Merge `jfx19` into master. ------------- Commit messages: - Merge jfx19 - 8290393: Code sample in javadoc of ObservableValue flatMap is incorrect - 8290331: Binding value left null when immediately revalidated in invalidation listener The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx/pull/832/files Stats: 31 lines in 3 files changed: 26 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/832.diff Fetch: git fetch https://git.openjdk.org/jfx pull/832/head:pull/832 PR: https://git.openjdk.org/jfx/pull/832 From kcr at openjdk.org Sat Jul 16 15:26:11 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 16 Jul 2022 15:26:11 GMT Subject: RFR: Merge jfx19 [v2] In-Reply-To: References: Message-ID: <1WWcWc3OdsiQDATYALhJSn1vQ1mTxAk2BYgYHyHPs_o=.88001bca-729f-40e6-b0e1-b01f22a8f765@github.com> > Merge `jfx19` into master. Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge jfx19 - 8289611: MouseLocationOnScreenTest sometimes fails on Mac M1 Reviewed-by: kcr - 8289835: Change JavaFX release version to 20 Reviewed-by: arapte ------------- Changes: - all: https://git.openjdk.org/jfx/pull/832/files - new: https://git.openjdk.org/jfx/pull/832/files/afdc8ac8..afdc8ac8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=832&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=832&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/832.diff Fetch: git fetch https://git.openjdk.org/jfx pull/832/head:pull/832 PR: https://git.openjdk.org/jfx/pull/832 From kcr at openjdk.org Sat Jul 16 15:26:13 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 16 Jul 2022 15:26:13 GMT Subject: Integrated: Merge jfx19 In-Reply-To: References: Message-ID: On Sat, 16 Jul 2022 15:16:12 GMT, Kevin Rushforth wrote: > Merge `jfx19` into master. This pull request has now been integrated. Changeset: e38979b9 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/e38979b90bd024946c6aac0e5ae32dcc121d2284 Stats: 31 lines in 3 files changed: 26 ins; 0 del; 5 mod Merge ------------- PR: https://git.openjdk.org/jfx/pull/832 From jvos at openjdk.org Sat Jul 16 18:53:45 2022 From: jvos at openjdk.org (Johan Vos) Date: Sat, 16 Jul 2022 18:53:45 GMT Subject: [jfx18] RFR: 8280841: Update SQLite to 3.37.2 Message-ID: Clean backport of 8280841: Update SQLite to 3.37.2 Reviewed-by: kcr, arapte ------------- Commit messages: - 8280841: Update SQLite to 3.37.2 Changes: https://git.openjdk.org/jfx/pull/833/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=833&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8280841 Stats: 22902 lines in 5 files changed: 11655 ins; 3597 del; 7650 mod Patch: https://git.openjdk.org/jfx/pull/833.diff Fetch: git fetch https://git.openjdk.org/jfx pull/833/head:pull/833 PR: https://git.openjdk.org/jfx/pull/833 From jvos at openjdk.org Sat Jul 16 18:58:29 2022 From: jvos at openjdk.org (Johan Vos) Date: Sat, 16 Jul 2022 18:58:29 GMT Subject: [jfx18] RFR: 8286256: Update libxml2 to 2.9.14 Message-ID: Clean backport of JDK-8286256 ------------- Commit messages: - 8286256: Update libxml2 to 2.9.14 Changes: https://git.openjdk.org/jfx/pull/834/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=834&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286256 Stats: 21664 lines in 81 files changed: 4429 ins; 4294 del; 12941 mod Patch: https://git.openjdk.org/jfx/pull/834.diff Fetch: git fetch https://git.openjdk.org/jfx pull/834/head:pull/834 PR: https://git.openjdk.org/jfx/pull/834 From jvos at openjdk.org Sat Jul 16 19:00:36 2022 From: jvos at openjdk.org (Johan Vos) Date: Sat, 16 Jul 2022 19:00:36 GMT Subject: [jfx18] RFR: 8282134: Certain regex can cause a JS trap in WebView Message-ID: Clean backport of 8282134: Certain regex can cause a JS trap in WebView Reviewed-by: kcr, arapte ------------- Commit messages: - 8282134: Certain regex can cause a JS trap in WebView Changes: https://git.openjdk.org/jfx/pull/835/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=835&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8282134 Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/835.diff Fetch: git fetch https://git.openjdk.org/jfx pull/835/head:pull/835 PR: https://git.openjdk.org/jfx/pull/835 From nlisker at openjdk.org Sun Jul 17 16:37:17 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 17 Jul 2022 16:37:17 GMT Subject: RFR: 8289394: Fix warnings: Unlikely argument type In-Reply-To: References: Message-ID: <6SaPVQEDPe_esRvxZbtDJ40Rtd7G8Y9hZ-j7mkHF5t0=.11226ec4-c868-41fa-8158-0134d88e2c35@github.com> On Fri, 8 Jul 2022 20:31:31 GMT, Andy Goryachev wrote: > Fixes "Unlikely argument type" warning generated by the latest Eclipse IDE. > > This warning should be reclassified as an error, as it catches bugs missed by javac. In this case, the following places seem to contain bugs: > - apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/TimelineController.java > - modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/GetEvent.java > > The fixes include: > - using objects of the right type > - adding @SuppressWarnings("unlikely-arg-type") in places where intended (e.g. assertFalse) > > There was an earlier discussion about using IDE-specific @SuppressWarnings in the code. While I might disagree (I think it is ok to use IDE-specific @SuppressWarnings), the tests can be reworked to avoid @SuppressWarnings. Please let me know. Thanks! Changes requested by nlisker (Reviewer). apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/TimelineController.java line 79: > 77: loopBtn.setDisable(false); > 78: playBtn.setSelected(t.getCurrentRate() != 0); > 79: loopBtn.setSelected(t.getCycleDuration().equals(Duration.INDEFINITE)); The correct fix is to check `t.getCycleCount() == Timeline.INDEFINITE`. modules/javafx.base/src/test/java/test/javafx/collections/ObservableSubListTest.java line 161: > 159: @Test > 160: public void testEqualsOnAnotherType() { > 161: assertFalse(sublist.equals(Integer.valueOf(7))); I'm not sure I see the point of this test. It's testing the implementation of the backing list, not the behavior of the sublist. Same for some other methods in this test, though it's not related to this PR. Let's see what Kevin thinks here. modules/javafx.graphics/src/test/java/test/javafx/css/Node_cssStyleMap_Test.java line 83: > 81: private void checkFoundStyle(Property property, Map, List