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.
> 
>
> 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.
> 
>
> 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.
> 
>
> 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.
>> 
>>
>> 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);
}

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>