From ebresie at gmail.com Sun Jan 2 14:56:41 2022 From: ebresie at gmail.com (Eric Bresie) Date: Sun, 2 Jan 2022 08:56:41 -0600 Subject: JDK-8088535 Memory Leak Message-ID: Noticed a recent tweet (1) about an older memory leak issue (2) and was curious if with recent performance and memory changes if anyone can confirm if this is still an issue or if it has been resolved as part of the recent changes. There appears to be a test attached to the original issue. Eric References: (1) https://twitter.com/dlemmermann/status/1477340490299330566?s=21 (2) https://bugs.openjdk.java.net/browse/JDK-8088535 -- Eric Bresie ebresie at gmail.com From arapte at openjdk.java.net Sun Jan 2 16:06:21 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sun, 2 Jan 2022 16:06:21 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v6] In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 13:13:09 GMT, Nir Lisker wrote: >> Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. >> >> I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. >> >> I noticed a drop of ~1 fps in the stress test of 5000 meshes. >> >> I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Added import Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From duke at openjdk.java.net Mon Jan 3 01:38:20 2022 From: duke at openjdk.java.net (Martin Fox) Date: Mon, 3 Jan 2022 01:38:20 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v5] In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 12:11:11 GMT, Johan Vos wrote: >> Martin Fox 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' into macshortcut >> - Fixed whitespace error. >> - A small number of keyboard layouts require the Option key to reach >> critical letters like 'Q'. Added a third probe (after Command and >> Shift+Command) to look for letters that require Option. The >> keyboards in question are Azeri, Turkmen, and the Sami layouts. >> - The code now queries both the shifted and unshifted characters for a key >> favoring digits and letters over everything else. This ensures we catch >> the digits on the French layout without interfering with Dvorak. >> - Mac - generate KeyCodes that match user's active keyboard layout. > > This looks ok, but I'm still a bit worried about possible regression. I understand that rigorous automated tests are hard in this case, but I wonder if we can have some basic tests at least. > Is there an issue in the Robot implementation preventing this? @johanvos I thought about your questions some more and decided to expand my KeyboardTest app. A new version is attached. The tests now cover as many keys as possible on German, French, and U.S. English layouts on Windows, Mac, and Linux. There are also tests for generic Latin and non-Latin layouts that check for proper behavior of KeyCodes A through Z, namely that they always generate characters and on Latin layouts those characters are ?a? through ?z?. The tests don?t cover dead keys or the top-row function keys because there?s too much variation across platforms. They also can?t cover keys that aren?t assigned KeyCodes like accented character keys. On Windows and Linux the biggest barrier to testing is the buggy Robot code. If you want to use this test app on Windows you?ll need to pull down PR #702. I?ll submit a PR for Linux this week. For now I would avoid the combination tests because they fail more often than not (but I?m working on that with PR #694) and aren't related to this PR. If we assume a Latin keyboard we can easily automate testing for about 60 keys (letters, portions of the keypad, Space, Tab, Home, End, and so on). I?ll look into creating an expanded automated test. But I still have no good plan for addressing punctuation and symbols which is historically where most of the bugs have been and the tests will only be useful if they are regularly run on a variety of different keyboard layouts. I'm not sure what to do with this test app. I would like to get it into the codebase since it?s useful for testing Robot fixes but there are three PR?s involved, this one for Mac, #702 for Windows, and an upcoming one for Linux. [KeyboardTest.txt](https://github.com/openjdk/jfx/files/7800066/KeyboardTest.txt) ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From hjohn at xs4all.nl Mon Jan 3 08:34:05 2022 From: hjohn at xs4all.nl (John Hendrikx) Date: Mon, 3 Jan 2022 09:34:05 +0100 Subject: JDK-8088535 Memory Leak In-Reply-To: References: Message-ID: I tested this, and it seems to still not work quite right. As far as I can see, it is not a memory leak, just slow performance when subtracting many shapes from roughly the same location from another shape. When the shapes are more spread out, it performs better. I don't think it is a major issue, definitely not for regular uses of shapes. Doing "game" like graphics is often an exercise to find how an API can be best exploited to get what you want with good performance; telling an API to brute-force render 10000 points in a 100x100 grid for example won't perform well, put them on a texture instead and it will perform well. This seems to be a similar case, so I'd recommend to use a Canvas, and draw circles on that instead. --John On 02/01/2022 15:56, Eric Bresie wrote: > Noticed a recent tweet (1) about an older memory leak issue (2) and was > curious if with recent performance and memory changes if anyone can confirm > if this is still an issue or if it has been resolved as part of the recent > changes. There appears to be a test attached to the original issue. > > Eric > > References: > (1) https://twitter.com/dlemmermann/status/1477340490299330566?s=21 > > (2) https://bugs.openjdk.java.net/browse/JDK-8088535 > From dlemmermann at gmail.com Mon Jan 3 12:27:26 2022 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Mon, 3 Jan 2022 13:27:26 +0100 Subject: JDK-8088535 Memory Leak In-Reply-To: References: Message-ID: In my case (1) it is a complex clipping shape that gets created based on an initial rectangle from which the code ?subtracts? a list of ellipses (2). The clip is set on paths so that their rendering stops before they enter the ellipses. ?Dirk (1) https://twitter.com/dlemmermann/status/1474059970857644032 (2) https://gist.github.com/5f4f45aa150c23f2e218b48a18d22121 > Am 03.01.2022 um 09:34 schrieb John Hendrikx : > > I tested this, and it seems to still not work quite right. > > As far as I can see, it is not a memory leak, just slow performance when subtracting many shapes from roughly the same location from another shape. When the shapes are more spread out, it performs better. > > I don't think it is a major issue, definitely not for regular uses of shapes. > > Doing "game" like graphics is often an exercise to find how an API can be best exploited to get what you want with good performance; telling an API to brute-force render 10000 points in a 100x100 grid for example won't perform well, put them on a texture instead and it will perform well. > > This seems to be a similar case, so I'd recommend to use a Canvas, and draw circles on that instead. > > --John > > On 02/01/2022 15:56, Eric Bresie wrote: >> Noticed a recent tweet (1) about an older memory leak issue (2) and was >> curious if with recent performance and memory changes if anyone can confirm >> if this is still an issue or if it has been resolved as part of the recent >> changes. There appears to be a test attached to the original issue. >> >> Eric >> >> References: >> (1) https://twitter.com/dlemmermann/status/1477340490299330566?s=21 >> >> (2) https://bugs.openjdk.java.net/browse/JDK-8088535 >> From kevin.rushforth at oracle.com Mon Jan 3 18:56:37 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 3 Jan 2022 10:56:37 -0800 Subject: Proposed schedule for JavaFX 18 In-Reply-To: References: Message-ID: <95cacaf5-32b6-911a-f318-bdd31cabd108@oracle.com> As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 18 starts on January 13, 2022 at 16:00 UTC (08:00 Pacific time), which is ten days from today. During rampdown of JavaFX 18, the "master" branch of the jfx repo will be open for JavaFX 19 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, January 6, or it is likely to miss the window for this release, in which case it can be targeted for JavaFX 19. We will follow the same process as in previous releases for getting fixes into JavaFX 18 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 11/16/2021 7:36 AM, Kevin Rushforth wrote: > Here is the proposed schedule for JavaFX 18. > > RDP1: Jan 13, 2022 (aka ?feature freeze?) > RDP2: Feb 3, 2022 > Freeze: Feb 24, 2022 > GA: Mar 15, 2022 > > We plan to fork a jfx18 stabilization branch at RDP1. The GA date is > one week ahead of JDK 18, matching what we did for 17. > > 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.java.net Tue Jan 4 03:32:24 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 4 Jan 2022 03:32:24 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v3] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Wed, 15 Dec 2021 11:43:36 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Upgrade tests to JUnit 5 This is the review of the API. I suggested also adding the examples in the POC or similar to the relevant methods. I have already commented on the implementation while we were discussing it in the mailing list, so that review will be minimal. I will review the tests soon, but after a quick look they seem fine. Don't worry about the CSR for now. When all reviewers agree on the API you can copy the final result to the CSR. Unrelated to the review, will it makes sense in the future to make all bindings lazily register listeners like `LazyObjectBinding`, perhaps when we introduce `Subscription`? modules/javafx.base/src/main/java/javafx/beans/binding/ObjectBinding.java line 193: > 191: * > 192: * @return {@code true} when this binding currently has one or more > 193: * listeners, otherwise {@code false} Maybe the method description `Checks if the binding has at least one listener registered on it.` is more straightforward, especially since it is a first-sentence summary. The `@return` description can contain the info on what is returned. As for that, maybe `{@code true} if this binding currently has one or more listeners registered on it, otherwise {@code false}` is more precise. I'm not sure if "registered on" or "registered to" is better, not that I think it matters. I would also like to see an explanation of how the method should/can be used by subclasses, but it looks to be tied to `Subscription`, which isn't added yet, so I don't have a good idea on this. modules/javafx.base/src/main/java/javafx/beans/binding/ObjectBinding.java line 204: > 202: * > 203: * @return {@code true} if this binding is allowed to become valid, otherwise > 204: * {@code false} Typo: overriden -> overridden I would add a a first-sentence summary and an explanation as to why a binding would not allow it. I would write something like Checks if the binding is allowed to become valid. Overriding classes can prevent a binding from becoming valid. This is useful when ____.

The default implementation always allows bindings to become valid. modules/javafx.base/src/main/java/javafx/beans/value/LazyObjectBinding.java line 77: > 75: > 76: /** > 77: * Called after a listener was added to start observing inputs, if they're not observed already. No need for a comma before "if". modules/javafx.base/src/main/java/javafx/beans/value/LazyObjectBinding.java line 99: > 97: > 98: /** > 99: * Called after a listener was removed to stop observing inputs, if this was the last listener No need for a comma before "if". modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 146: > 144: * Returns an {@link ObservableValue} which provides a mapping of the value > 145: * held by this {@code ObservableValue}, and provides {@code null} when this > 146: * {@code ObservableValue} holds {@code null}. No need to `@link` since we are in the same class already. While this description is very similar to that of ReactFX, I would prefer a shorter summary of what the method does as its first sentence, and this will allow to unpack the details more cleanly. Maybe something like: Creates an {@code ObservableValue} that holds the result of applying a mapping on the value held by this {@code ObservableValue}. The result is updated (lazily) when the value held by this {@code ObservableValue} changes. If this value is {@code null}, the resulting value is also {@code null} (the mapping is not applied).

For example, mapping a lower case string to an uppercase string, and to a check if the string is blank:

    var lowercase = new SimpleStringProperty("abcd");
    ObservableValue uppercase = lowercase.map(String::toUpperCase); // "ABCD"
    ObservableValue blank = lowercase.map(String::isBlank);        // false
    lowercase.set(" ");
    uppercase.getValue(); // " "
    blank.getValue();     // true
modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 149: > 147: * > 148: * @param the type of values held by the resulting {@code ObservableValue} > 149: * @param mapper a {@link Function} which converts a given value to a new value, cannot be null No need to `@link` since its linked in the method argument list when the docs are generated. `null` should be in `@code`. Worth thinking about adding the types of the conversion: `...which converts a given value of type {@code T} to a new value of type {@code U}` but I'm not sure it's necessary. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 152: > 150: * @return an {@link ObservableValue} which provides a mapping of the value > 151: * held by this {@code ObservableValue}, and provides {@code null} when > 152: * this {@code ObservableValue} holds {@code null}, never null No need for `@link`. Since we already explained how the mapping works, maybe we can be more brief here: an {@code ObservableValue} that holds the result of the mapping of the value held by this {@code ObservableValue}; never {@code null} itself modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 161: > 159: * Returns an {@link ObservableValue} which provides a mapping of the value > 160: * held by this {@code ObservableValue}, or {@code constant} when this > 161: * {@code ObservableValue} holds {@code null}. Similarly to `map`, but I would refrain from using the "mapping" terminology since we are not dealing with a map (function) on the surface: Creates an {@code ObservableValue} that holds the value held by this {@code ObservableValue}, or a given value if this value is {@code null}. The result is updated (lazily) when the value held by this {@code ObservableValue} changes. This method can be combined with {@link #map(Function)} to handle {@code null} values.

For example, mapping a lower case string to an uppercase string, and to a check if the string is blank, with alternatives for a {@code null} value:

    var lowercase = new SimpleStringProperty("abcd");
    ObservableValue uppercase = lowercase.map(String::toUpperCase).orElse(""); // "ABCD"
    ObservableValue blank = lowercase.map(String::isBlank).orElse(true);      // false
    lowercase.set(null);
    uppercase.getValue(); // ""
    blank.getValue();     // true
modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 164: > 162: * > 163: * @param constant an alternative value to use when this {@code ObservableValue} > 164: * holds {@code null}, can be null `... holds {@code null}; can be {@code null}` modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 167: > 165: * @return an {@link ObservableValue} which provides a mapping of the value > 166: * held by this {@code ObservableValue}, or {@code constant} when this > 167: * {@code ObservableValue} holds {@code null}, never null an {@code ObservableValue} that holds the value held by this {@code ObservableValue}, or the given value if it is {@code null}; never {@code null} itself modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 180: > 178: * > 179: * Returning {@code null} from {@code mapper} will result in an > 180: * {@code ObservableValue} which holds {@code null}. This one is hard for me to explain. It comes out convoluted regardless of how I phrase it. Creates an {@code ObservableValue} that holds the value of the {@code ObservableValue} resulting from applying a mapping on the value held by this {@code ObservableValue}. The result is updated (lazily) when either the values held by this {@code ObservableValue} or the value held by the {@code ObservableValue} in the mapping changes. If this value or the value returned by the mapping are {@code null}, the held value is also {@code null}.

For example, a property which is only true when the UI is visible:

    ObservableValue allShowing = listView.sceneProperty()
        .flatMap(Scene::windowProperty)
        .flatMap(Window::showingProperty)
        .orElse(false);
Changes in the values of any of: the scene of {@code listView}, the window of that scene, or the showing of that window, will updated the result boolean value {@code allShowing}.

This method is preferred over {@link javafx.beans.binding.Bindings Bindings#select} methods since it is type safe and handles {@code null}s in the call chain more easily. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 184: > 182: * @param the type of values held by the resulting {@code ObservableValue} > 183: * @param mapper a {@link Function} which converts a given value to an > 184: * {@code ObservableValue}, cannot be null `a {@code Function} that converts a given value to an {@code ObservableValue}; cannot be {@code null}` modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 188: > 186: * {@code ObservableValue} given by applying {@code mapper} on the value > 187: * held by this {@code ObservableValue}, and is {@code null} when this > 188: * {@code ObservableValue} holds {@code null}, never null an {@code ObservableValue} that holds the value of the {@code ObservableValue} resulting from applying a mapping on the value held by this {@code ObservableValue}; never {@code null} itself ------------- Changes requested by nlisker (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/675 From nlisker at openjdk.java.net Tue Jan 4 03:39:19 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 4 Jan 2022 03:39:19 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v3] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <0fF14xtpWyfezWOQmPwiZC-Ew9ATETo2AuUqQPNFwbg=.2b929a77-65f5-4494-95ec-b097ec0b930a@github.com> On Wed, 15 Dec 2021 11:43:36 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Upgrade tests to JUnit 5 modules/javafx.base/src/main/java/javafx/beans/value/MappedBinding.java line 34: > 32: > 33: class MappedBinding extends LazyObjectBinding { > 34: private final ObservableValue source; We usually have an empty line below the class declaration. Not sure if this is enforced. Same for the other classes. modules/javafx.base/src/main/java/javafx/beans/value/MappedBinding.java line 48: > 46: > 47: @Override > 48: protected T computeValue() { Maybe move this method above `observeInputs` like in `FlatMapBinding`. Same for `OrElseBinding`. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From kcr at openjdk.java.net Tue Jan 4 13:17:35 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 4 Jan 2022 13:17:35 GMT Subject: RFR: 8279396: Define version in .jcheck/conf Message-ID: <2jyVlYFKJllFoLeVOdBFjlni7SmJfLGpDBOAT0DQB6Q=.e2c6f503-fedf-43b7-8d91-96e8b463509d@github.com> This patch adds the version property to `.jcheck/conf`. By doing this we can remove the corresponding configuration from the Skara bots, which in turn reduces the need for timing and general complexity of starting a new JavaFX release. See openjdk/jdk#6929 for the similar PR for the `jdk` repo. ------------- Commit messages: - 8279396: Define version in .jcheck/conf Changes: https://git.openjdk.java.net/jfx/pull/706/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=706&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279396 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/706.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/706/head:pull/706 PR: https://git.openjdk.java.net/jfx/pull/706 From erikj at openjdk.java.net Tue Jan 4 14:19:17 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 4 Jan 2022 14:19:17 GMT Subject: RFR: 8279396: Define version in .jcheck/conf In-Reply-To: <2jyVlYFKJllFoLeVOdBFjlni7SmJfLGpDBOAT0DQB6Q=.e2c6f503-fedf-43b7-8d91-96e8b463509d@github.com> References: <2jyVlYFKJllFoLeVOdBFjlni7SmJfLGpDBOAT0DQB6Q=.e2c6f503-fedf-43b7-8d91-96e8b463509d@github.com> Message-ID: On Tue, 4 Jan 2022 13:09:33 GMT, Kevin Rushforth wrote: > This patch adds the version property to `.jcheck/conf`. By doing this we can remove the corresponding configuration from the Skara bots, which in turn reduces the need for timing and general complexity of starting a new JavaFX release. See openjdk/jdk#6929 for the similar PR for the `jdk` repo. Marked as reviewed by erikj (no project role). ------------- PR: https://git.openjdk.java.net/jfx/pull/706 From arapte at openjdk.java.net Tue Jan 4 15:28:20 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 4 Jan 2022 15:28:20 GMT Subject: RFR: 8279396: Define version in .jcheck/conf In-Reply-To: <2jyVlYFKJllFoLeVOdBFjlni7SmJfLGpDBOAT0DQB6Q=.e2c6f503-fedf-43b7-8d91-96e8b463509d@github.com> References: <2jyVlYFKJllFoLeVOdBFjlni7SmJfLGpDBOAT0DQB6Q=.e2c6f503-fedf-43b7-8d91-96e8b463509d@github.com> Message-ID: On Tue, 4 Jan 2022 13:09:33 GMT, Kevin Rushforth wrote: > This patch adds the version property to `.jcheck/conf`. By doing this we can remove the corresponding configuration from the Skara bots, which in turn reduces the need for timing and general complexity of starting a new JavaFX release. See openjdk/jdk#6929 for the similar PR for the `jdk` repo. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/706 From kcr at openjdk.java.net Tue Jan 4 16:20:13 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 4 Jan 2022 16:20:13 GMT Subject: Integrated: 8279396: Define version in .jcheck/conf In-Reply-To: <2jyVlYFKJllFoLeVOdBFjlni7SmJfLGpDBOAT0DQB6Q=.e2c6f503-fedf-43b7-8d91-96e8b463509d@github.com> References: <2jyVlYFKJllFoLeVOdBFjlni7SmJfLGpDBOAT0DQB6Q=.e2c6f503-fedf-43b7-8d91-96e8b463509d@github.com> Message-ID: On Tue, 4 Jan 2022 13:09:33 GMT, Kevin Rushforth wrote: > This patch adds the version property to `.jcheck/conf`. By doing this we can remove the corresponding configuration from the Skara bots, which in turn reduces the need for timing and general complexity of starting a new JavaFX release. See openjdk/jdk#6929 for the similar PR for the `jdk` repo. This pull request has now been integrated. Changeset: 1feba1f6 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/1feba1f6d372843c7c3546e6648dc9f5c9094923 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod 8279396: Define version in .jcheck/conf Reviewed-by: erikj, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/706 From kcr at openjdk.java.net Tue Jan 4 16:46:30 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 4 Jan 2022 16:46:30 GMT Subject: [jfx17u] RFR: 8279396: Define version in .jcheck/conf Message-ID: Backport fix to add `version` property to `.jcheck/conf`. This is needed in support of a Skara bot config change to take the fix version from the repo. ------------- Commit messages: - 8279396: Define version in .jcheck/conf Changes: https://git.openjdk.java.net/jfx17u/pull/27/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=27&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279396 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/27.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/27/head:pull/27 PR: https://git.openjdk.java.net/jfx17u/pull/27 From kcr at openjdk.java.net Tue Jan 4 16:51:36 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 4 Jan 2022 16:51:36 GMT Subject: [jfx11u] RFR: 8279396: Define version in .jcheck/conf Message-ID: Backport fix to add `version` property to `.jcheck/conf`. This is needed in support of a Skara bot config change to take the fix version from the repo. NOTE: the `UPDATING-version.md` file was not present in the repo. I copied it from mainline, since the instructions are identical. ------------- Commit messages: - 8279396: Define version in .jcheck/conf Changes: https://git.openjdk.java.net/jfx11u/pull/68/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=68&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279396 Stats: 41 lines in 2 files changed: 41 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/68.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/68/head:pull/68 PR: https://git.openjdk.java.net/jfx11u/pull/68 From jvos at openjdk.java.net Tue Jan 4 16:54:21 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 4 Jan 2022 16:54:21 GMT Subject: [jfx11u] RFR: 8279396: Define version in .jcheck/conf In-Reply-To: References: Message-ID: On Tue, 4 Jan 2022 16:45:52 GMT, Kevin Rushforth wrote: > Backport fix to add `version` property to `.jcheck/conf`. This is needed in support of a Skara bot config change to take the fix version from the repo. > > NOTE: the `UPDATING-version.md` file was not present in the repo. I copied it from mainline, since the instructions are identical. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/68 From kcr at openjdk.java.net Tue Jan 4 17:05:21 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 4 Jan 2022 17:05:21 GMT Subject: [jfx17u] RFR: 8279396: Define version in .jcheck/conf In-Reply-To: References: Message-ID: On Tue, 4 Jan 2022 16:39:00 GMT, Kevin Rushforth wrote: > Backport fix to add `version` property to `.jcheck/conf`. This is needed in support of a Skara bot config change to take the fix version from the repo. Reviewer: @johanvos ------------- PR: https://git.openjdk.java.net/jfx17u/pull/27 From kcr at openjdk.java.net Tue Jan 4 17:15:25 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 4 Jan 2022 17:15:25 GMT Subject: [jfx11u] Integrated: 8279396: Define version in .jcheck/conf In-Reply-To: References: Message-ID: On Tue, 4 Jan 2022 16:45:52 GMT, Kevin Rushforth wrote: > Backport fix to add `version` property to `.jcheck/conf`. This is needed in support of a Skara bot config change to take the fix version from the repo. > > NOTE: the `UPDATING-version.md` file was not present in the repo. I copied it from mainline, since the instructions are identical. This pull request has now been integrated. Changeset: e8066068 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/e80660685e879a0f259af1cbe55753d861c8196a Stats: 41 lines in 2 files changed: 41 ins; 0 del; 0 mod 8279396: Define version in .jcheck/conf Reviewed-by: jvos Backport-of: 1feba1f6d372843c7c3546e6648dc9f5c9094923 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/68 From jvos at openjdk.java.net Tue Jan 4 17:50:15 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 4 Jan 2022 17:50:15 GMT Subject: [jfx17u] RFR: 8279396: Define version in .jcheck/conf In-Reply-To: References: Message-ID: <39zclq3WP8SroCvmP5p5tAEY4wx3_zskZO0TcpNKeUY=.22ff1d2f-7608-4fd0-a889-eae6d3eb6299@github.com> On Tue, 4 Jan 2022 16:39:00 GMT, Kevin Rushforth wrote: > Backport fix to add `version` property to `.jcheck/conf`. This is needed in support of a Skara bot config change to take the fix version from the repo. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx17u/pull/27 From kcr at openjdk.java.net Tue Jan 4 17:56:23 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 4 Jan 2022 17:56:23 GMT Subject: [jfx17u] Integrated: 8279396: Define version in .jcheck/conf In-Reply-To: References: Message-ID: On Tue, 4 Jan 2022 16:39:00 GMT, Kevin Rushforth wrote: > Backport fix to add `version` property to `.jcheck/conf`. This is needed in support of a Skara bot config change to take the fix version from the repo. This pull request has now been integrated. Changeset: b6b7207a Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/b6b7207a1944bc80ab31f5ff6bdfcd168450207c Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod 8279396: Define version in .jcheck/conf Reviewed-by: jvos Backport-of: 1feba1f6d372843c7c3546e6648dc9f5c9094923 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/27 From jhendrikx at openjdk.java.net Wed Jan 5 12:29:01 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 5 Jan 2022 12:29:01 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v4] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Apply changes suggested in review and updated copyright years to 2022 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/675/files - new: https://git.openjdk.java.net/jfx/pull/675/files/312fb506..30e8ceac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=02-03 Stats: 182 lines in 11 files changed: 127 ins; 13 del; 42 mod Patch: https://git.openjdk.java.net/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/675/head:pull/675 PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Wed Jan 5 12:29:12 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 5 Jan 2022 12:29:12 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v3] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Sun, 2 Jan 2022 20:18:02 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Upgrade tests to JUnit 5 > > modules/javafx.base/src/main/java/javafx/beans/binding/ObjectBinding.java line 193: > >> 191: * >> 192: * @return {@code true} when this binding currently has one or more >> 193: * listeners, otherwise {@code false} > > Maybe the method description > `Checks if the binding has at least one listener registered on it.` > is more straightforward, especially since it is a first-sentence summary. The `@return` description can contain the info on what is returned. As for that, maybe > `{@code true} if this binding currently has one or more listeners registered on it, otherwise {@code false}` > is more precise. > I'm not sure if "registered on" or "registered to" is better, not that I think it matters. > > I would also like to see an explanation of how the method should/can be used by subclasses, but it looks to be tied to `Subscription`, which isn't added yet, so I don't have a good idea on this. It is not strictly tied to `Subscription`, the method is required to determine when `LazyObjectBinding` must register listeners on its dependencies and when it can remove them again (basically when it stops being lazy or when it can become lazy again). > modules/javafx.base/src/main/java/javafx/beans/binding/ObjectBinding.java line 204: > >> 202: * >> 203: * @return {@code true} if this binding is allowed to become valid, otherwise >> 204: * {@code false} > > Typo: overriden -> overridden > > I would add a a first-sentence summary and an explanation as to why a binding would not allow it. I would write something like > > Checks if the binding is allowed to become valid. Overriding classes can prevent a binding from becoming > valid. This is useful when ____. >

> The default implementation always allows bindings to become valid. I've made your suggested changes and added this explanation: "This is useful in subclasses which do not always listen for invalidations of their dependencies and prefer to recompute the current value instead. This can also be useful if caching of the current computed value is not desirable." Furthermore, I noticed I forgot to make the code changes that prevent caching of the value when the binding is invalid -- bindings currently cache their value even when invalid, which could lead to situations where something is still being referenced in an invalid binding that should have been GC'd. > modules/javafx.base/src/main/java/javafx/beans/value/MappedBinding.java line 34: > >> 32: >> 33: class MappedBinding extends LazyObjectBinding { >> 34: private final ObservableValue source; > > We usually have an empty line below the class declaration. Not sure if this is enforced. Same for the other classes. I've added them everywhere. > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 146: > >> 144: * Returns an {@link ObservableValue} which provides a mapping of the value >> 145: * held by this {@code ObservableValue}, and provides {@code null} when this >> 146: * {@code ObservableValue} holds {@code null}. > > No need to `@link` since we are in the same class already. > > While this description is very similar to that of ReactFX, I would prefer a shorter summary of what the method does as its first sentence, and this will allow to unpack the details more cleanly. Maybe something like: > > Creates an {@code ObservableValue} that holds the result of applying a mapping on the value held > by this {@code ObservableValue}. The result is updated (lazily) when the value held by this > {@code ObservableValue} changes. If this value is {@code null}, the resulting value is also {@code null} > (the mapping is not applied). >

> For example, mapping a lower case string to an uppercase string, and to a check if the string is blank: >

>     var lowercase = new SimpleStringProperty("abcd");
>     ObservableValue uppercase = lowercase.map(String::toUpperCase); // "ABCD"
>     ObservableValue blank = lowercase.map(String::isBlank);        // false
>     lowercase.set(" ");
>     uppercase.getValue(); // " "
>     blank.getValue();     // true
> 
Copied these suggestions with some slight modifications, and I simplified the example a little bit. > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 149: > >> 147: * >> 148: * @param the type of values held by the resulting {@code ObservableValue} >> 149: * @param mapper a {@link Function} which converts a given value to a new value, cannot be null > > No need to `@link` since its linked in the method argument list when the docs are generated. > `null` should be in `@code`. > > Worth thinking about adding the types of the conversion: > `...which converts a given value of type {@code T} to a new value of type {@code U}` > but I'm not sure it's necessary. The type parameters already have their own documentation lines, and I think `Function` itself clearly describes how this works already. > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 152: > >> 150: * @return an {@link ObservableValue} which provides a mapping of the value >> 151: * held by this {@code ObservableValue}, and provides {@code null} when >> 152: * this {@code ObservableValue} holds {@code null}, never null > > No need for `@link`. > > Since we already explained how the mapping works, maybe we can be more brief here: > > an {@code ObservableValue} that holds the result of the mapping of the value > held by this {@code ObservableValue}; never {@code null} itself I think that `@return` should mention that the returned observable can hold `null`, how about: an {@code ObservableValue} that holds a mapping of this {@code ObservableValue}'s value or holds {@code null} when the value is {@code null}; never returns {@code null} > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 161: > >> 159: * Returns an {@link ObservableValue} which provides a mapping of the value >> 160: * held by this {@code ObservableValue}, or {@code constant} when this >> 161: * {@code ObservableValue} holds {@code null}. > > Similarly to `map`, but I would refrain from using the "mapping" terminology since we are not dealing with a map (function) on the surface: > > > Creates an {@code ObservableValue} that holds the value held by this {@code ObservableValue}, > or a given value if this value is {@code null}. The result is updated (lazily) when the value held by this > {@code ObservableValue} changes. This method can be combined with {@link #map(Function)} to > handle {@code null} values. >

> For example, mapping a lower case string to an uppercase string, and to a check if the string is blank, > with alternatives for a {@code null} value: >

>     var lowercase = new SimpleStringProperty("abcd");
>     ObservableValue uppercase = lowercase.map(String::toUpperCase).orElse(""); // "ABCD"
>     ObservableValue blank = lowercase.map(String::isBlank).orElse(true);      // false
>     lowercase.set(null);
>     uppercase.getValue(); // ""
>     blank.getValue();     // true
> 
Copied this with some minor changes (I removed "lazily"). Simplified the example a bit. > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 167: > >> 165: * @return an {@link ObservableValue} which provides a mapping of the value >> 166: * held by this {@code ObservableValue}, or {@code constant} when this >> 167: * {@code ObservableValue} holds {@code null}, never null > > an {@code ObservableValue} that holds the value held by this {@code ObservableValue}, or the given > value if it is {@code null}; never {@code null} itself Would this be clear enough: an {@link ObservableValue} that holds this {@code ObservableValue}'s value or the given value when the value is {@code null}; never returns {@code null} > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 180: > >> 178: * >> 179: * Returning {@code null} from {@code mapper} will result in an >> 180: * {@code ObservableValue} which holds {@code null}. > > This one is hard for me to explain. It comes out convoluted regardless of how I phrase it. > > > Creates an {@code ObservableValue} that holds the value of the {@code ObservableValue} resulting > from applying a mapping on the value held by this {@code ObservableValue}. The result is updated (lazily) > when either the values held by this {@code ObservableValue} or the value held by the {@code ObservableValue} > in the mapping changes. If this value or the value returned by the mapping are {@code null}, the held value > is also {@code null}. >

> For example, a property which is only true when the UI is visible: >

>     ObservableValue allShowing = listView.sceneProperty()
>         .flatMap(Scene::windowProperty)
>         .flatMap(Window::showingProperty)
>         .orElse(false);
> 
> Changes in the values of any of: the scene of {@code listView}, the window of that scene, or the showing of that > window, will updated the result boolean value {@code allShowing}. >

> This method is preferred over {@link javafx.beans.binding.Bindings Bindings#select} methods since it is type > safe and handles {@code null}s in the call chain more easily. I think this reads okay. I made some minor changes to clarify the mapper is not called when this observable value holds null. I also adding some more lines to the example, and I removed "and handles {@code null}s in the call chain more easily" as I think that's not really true (`select` handles nulls fine, although it (used to) prints warnings I think). > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 188: > >> 186: * {@code ObservableValue} given by applying {@code mapper} on the value >> 187: * held by this {@code ObservableValue}, and is {@code null} when this >> 188: * {@code ObservableValue} holds {@code null}, never null > > an {@code ObservableValue} that holds the value of the {@code ObservableValue} resulting > from applying a mapping on the value held by this {@code ObservableValue}; never {@code null} itself How about: an {@code ObservableValue} holding the value of an {@code ObservableValue} resulting from a mapping of this {@code ObservableValue}'s value or holds {@code null} when the value is {@code null}; never returns {@code null} They are tough to describe; if you don't like the `or holds {@code null}` parts I can remove those from all the functions. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Wed Jan 5 12:29:12 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 5 Jan 2022 12:29:12 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v3] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Wed, 5 Jan 2022 09:45:21 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/javafx/beans/binding/ObjectBinding.java line 193: >> >>> 191: * >>> 192: * @return {@code true} when this binding currently has one or more >>> 193: * listeners, otherwise {@code false} >> >> Maybe the method description >> `Checks if the binding has at least one listener registered on it.` >> is more straightforward, especially since it is a first-sentence summary. The `@return` description can contain the info on what is returned. As for that, maybe >> `{@code true} if this binding currently has one or more listeners registered on it, otherwise {@code false}` >> is more precise. >> I'm not sure if "registered on" or "registered to" is better, not that I think it matters. >> >> I would also like to see an explanation of how the method should/can be used by subclasses, but it looks to be tied to `Subscription`, which isn't added yet, so I don't have a good idea on this. > > It is not strictly tied to `Subscription`, the method is required to determine when `LazyObjectBinding` must register listeners on its dependencies and when it can remove them again (basically when it stops being lazy or when it can become lazy again). I've added "This is useful for subclasses which want to conserve resources when not observed." ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From nlisker at openjdk.java.net Wed Jan 5 13:07:12 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 5 Jan 2022 13:07:12 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v3] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <-mDOwpCPQhyKmoc2N6cu3mzVe-YLXCqvw0gePMk7o3E=.90ecb3e0-027f-43db-888b-01ceef627e8e@github.com> On Wed, 5 Jan 2022 09:52:29 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/javafx/beans/binding/ObjectBinding.java line 204: >> >>> 202: * >>> 203: * @return {@code true} if this binding is allowed to become valid, otherwise >>> 204: * {@code false} >> >> Typo: overriden -> overridden >> >> I would add a a first-sentence summary and an explanation as to why a binding would not allow it. I would write something like >> >> Checks if the binding is allowed to become valid. Overriding classes can prevent a binding from becoming >> valid. This is useful when ____. >>

>> The default implementation always allows bindings to become valid. > > I've made your suggested changes and added this explanation: "This is useful in subclasses which do not always listen for invalidations of their dependencies and prefer to recompute the current value instead. This can also be useful if caching of the current computed value is not desirable." > > Furthermore, I noticed I forgot to make the code changes that prevent caching of the value when the binding is invalid -- bindings currently cache their value even when invalid, which could lead to situations where something is still being referenced in an invalid binding that should have been GC'd. Something like that was previously discussed in https://github.com/javafxports/openjdk-jfx/pull/110. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Wed Jan 5 13:28:12 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 5 Jan 2022 13:28:12 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v3] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Tue, 4 Jan 2022 03:28:57 GMT, Nir Lisker wrote: > Unrelated to the review, will it makes sense in the future to make all bindings lazily register listeners like `LazyObjectBinding`, perhaps when we introduce `Subscription`? That would need to be very well tested. There are some noticeable differences in behavior vs the standard bindings: 1) Standard bindings can more easily be GC'd (accidentally usually, but it could be intentional), take for example: textProperty.addListener((obs, old, current) -> System.out.println(current)); textProperty.concat("A").addListener((obs, old, current) -> System.out.println(current)); These behave very different. The first listener keeps working as you'd expect, while the second one can stop working as soon the GC runs. This is because `concat` results in an `ObservableValue` that is weakly bound. Compare this to: textProperty.map(x -> x + "A").addListener((obs, old, current) -> System.out.println(current)); This keeps working and will not be GC'd by accident. 2) Standard bindings will always cache values. This means that when `getValue` is called, it will just return the cached value instead of calling `computeValue`. If `computeValue` is really expensive (unwise since this happens on the FX thread) then this cost is paid each time for Lazy bindings, at least when they're not bound to anything else (unobserved) and you are just using `getValue`. Furthermore, for a chain of Lazy bindings that is unobserved, this would propagate through the entire chain. As soon as they're observed though, they become non-lazy and values are cached. In effect, Lazy bindings behave the same as standard bindings when they're observed but their behavior changes when not observed: they never become valid and they stop caching values This has pros and cons: Pro: Lazy bindings can be garbage collected when not referenced and not actively being used without the use of weak listeners. See the first example where the binding keeps working when used by `println` lambda. This is in contrast to traditional bindings which can be garbage collected when unreferenced by user code even if actively used(!!). This is a huge gotcha and one of the biggest reasons to use the lazy model. Pro: Lazy bindings don't register unnecessary listeners to be aware of changed or invalidated values that are not used by anyone. A good example is the problems we saw about a year ago where `Node` had created an `isShowing` property which bounds to its `Scene` and `Window`. This looks harmless, until you realize that a listener is created on these properties for each `Node` in existence. If a `Scene` has tens of thousands of `Node`s then that means that the `Scene#windowProperty` will have a listener list containing tens of thousands of entries. This list is not only expensive to change (when a node is added or removed) but also expensive to act on (when the scene, window or its showing state changes). And for what? Almost nobody was actually using this property, yet listeners had to be added for each and every `Node`. In effect with lazy bindings, it is much cheaper now to create properties that create convenient calculated values which will only register listeners or compute their values when in actual use. Con: lazy bindings never become valid when not observed. This means that `getValue` will always have to recompute the value as the value is not cached. However, if you register an invalidation listener the binding becomes observed and it will start behaving like a traditional binding sending invalidation events and caching the current value. A small "pro" here could be that this means that intermediate values in a long binding chain don't take up memory (and are prevented from GC), however that goes away as soon as the binding is observed. In summary: I think lazy bindings are far superior in the experience that they offer, but it does come at a cost that values may need to be recomputed every time when the bindings are unobserved. However, doing substantial work in `computeValue` is probably unwise anyway as it blocks the FX thread so making lazy binding the default behavior in well behaving code could be of only minor impact. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From mstrauss at openjdk.java.net Wed Jan 5 13:28:13 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 5 Jan 2022 13:28:13 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v3] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Wed, 5 Jan 2022 12:08:01 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 188: >> >>> 186: * {@code ObservableValue} given by applying {@code mapper} on the value >>> 187: * held by this {@code ObservableValue}, and is {@code null} when this >>> 188: * {@code ObservableValue} holds {@code null}, never null >> >> an {@code ObservableValue} that holds the value of the {@code ObservableValue} resulting >> from applying a mapping on the value held by this {@code ObservableValue}; never {@code null} itself > > How about: > > an {@code ObservableValue} holding the value of an {@code ObservableValue} > resulting from a mapping of this {@code ObservableValue}'s value or > holds {@code null} when the value is {@code null}; never returns {@code null} > > They are tough to describe; if you don't like the `or holds {@code null}` parts I can remove those from all the functions. Here's another attempt: a new {@link ObservableValue} instance that holds the value that was obtained by applying the mapping function on the value held by this {@code ObservableValue}. If this {@code ObservableValue} holds {@code null}, the new {@code ObservableValue} will also hold {@code null}. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From mstrauss at openjdk.java.net Wed Jan 5 17:53:17 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 5 Jan 2022 17:53:17 GMT Subject: RFR: 8267059: Gradle :clean and :apps tasks fail on Windows if ANT_HOME contains spaces [v2] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 13:39:13 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into fixes/JDK-8267059 >> - Use cmd /s option when building on Windows > > @tiainen or @arapte can one of you be the second reviewer on this? @kevinrushforth I think this is a very useful fix that has been tested by three people in the last months (of which only your review counts for Skara). Can you lower the number of required reviews to 1 in order for this PR to move forward to integration? ------------- PR: https://git.openjdk.java.net/jfx/pull/499 From fkirmaier at openjdk.java.net Wed Jan 5 18:14:44 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 5 Jan 2022 18:14:44 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v3] In-Reply-To: References: Message-ID: > Making the initial listener of the ListProperty weak fixes the problem. > The same is fixed for Set and Map. > Due to a smart implementation, this is done without any performance drawback. > (The trick is to have an object, which is both the WeakReference and the Changelistener) > By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8277848 Further optimization based code review. This Bugfix should now event improve the performance ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/689/files - new: https://git.openjdk.java.net/jfx/pull/689/files/f9b7009b..ec90b3d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=689&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=689&range=01-02 Stats: 106 lines in 3 files changed: 15 ins; 63 del; 28 mod Patch: https://git.openjdk.java.net/jfx/pull/689.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/689/head:pull/689 PR: https://git.openjdk.java.net/jfx/pull/689 From fkirmaier at openjdk.java.net Wed Jan 5 18:17:18 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 5 Jan 2022 18:17:18 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v2] In-Reply-To: References: Message-ID: On Fri, 31 Dec 2021 12:53:54 GMT, Michael Strau? wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8277848 >> Added missing change > > Why are the new listener imlementations called `BaseChangeListener` and `BaseInvalidationListener`, i.e. why the _Base_? > > Also, if you're going to the trouble of refactoring the existing listener implementation, have you considered merging the very similar implementations into a single class? You can then re-use the listener instance and save another object allocation in this way: > > > private static class Listener extends WeakReference> > implements InvalidationListener, ListChangeListener, WeakListener { > Listener(ListPropertyBase ref) { > super(ref); > } > > @Override > public boolean wasGarbageCollected() { > return get() == null; > } > > @Override > public void onChanged(Change change) { > ListPropertyBase ref = get(); > if(ref != null) { > ref.invalidateProperties(); > ref.invalidated(); > ref.fireValueChangedEvent(change); > } > } > > @Override > public void invalidated(Observable observable) { > ListPropertyBase ref = get(); > if (ref == null) { > observable.removeListener(this); > } else { > ref.markInvalid(ref.value); > } > } > } @mstr2 Great point. The chosen name was just because I needed a name. I switched now to the name "Listener". I've now merged the ChangeListener with the Invalidation Listener, as you've suggested. The PR should now improve the performance while fixing a bug. It might even be quite relevant because these classes are used very often. ------------- PR: https://git.openjdk.java.net/jfx/pull/689 From kcr at openjdk.java.net Wed Jan 5 18:51:17 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 Jan 2022 18:51:17 GMT Subject: RFR: 8267059: Gradle :clean and :apps tasks fail on Windows if ANT_HOME contains spaces [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 05:04:17 GMT, Michael Strau? wrote: >> This PR fixes an issue when building OpenJFX on Windows and command-line arguments contain paths with spaces. >> >> The problem is that on Windows, `ant` is invoked via `cmd`, which leads to quotes being interpreted twice. This can be fixed with the option `cmd /s`, which prevents interpreting quotes on the rest of the command line. The result is as if the rest of the command line had been typed verbatim at the command prompt. > > 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 two additional commits since the last revision: > > - Merge branch 'master' into fixes/JDK-8267059 > - Use cmd /s option when building on Windows @johanvos or @tiainen can you comment as to whether you have any concerns with this? It seems a safe fix to me. ------------- PR: https://git.openjdk.java.net/jfx/pull/499 From mstrauss at openjdk.java.net Wed Jan 5 19:35:19 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 5 Jan 2022 19:35:19 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v3] In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 18:14:44 GMT, Florian Kirmaier wrote: >> Making the initial listener of the ListProperty weak fixes the problem. >> The same is fixed for Set and Map. >> Due to a smart implementation, this is done without any performance drawback. >> (The trick is to have an object, which is both the WeakReference and the Changelistener) >> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8277848 > Further optimization based code review. > This Bugfix should now event improve the performance modules/javafx.base/src/main/java/javafx/beans/property/ListPropertyBase.java line 338: > 336: public void onChanged(Change change) { > 337: ListPropertyBase ref = get(); > 338: if(ref != null) { Minor: space after `if` modules/javafx.base/src/main/java/javafx/beans/property/MapPropertyBase.java line 339: > 337: public void onChanged(Change change) { > 338: MapPropertyBase ref = get(); > 339: if(ref != null) { Minor: space after `if` modules/javafx.base/src/main/java/javafx/beans/property/SetPropertyBase.java line 341: > 339: public void onChanged(Change change) { > 340: SetPropertyBase ref = get(); > 341: if(ref != null) { Minor: space after `if` ------------- PR: https://git.openjdk.java.net/jfx/pull/689 From duke at openjdk.java.net Thu Jan 6 08:17:53 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Thu, 6 Jan 2022 08:17:53 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v5] In-Reply-To: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: > This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. > > The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs > > There are currently 2 manual tests for this fix. Abhinay Agarwal has updated the pull request incrementally with two additional commits since the last revision: - Remove commented out method. Document constructors. - Add tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/673/files - new: https://git.openjdk.java.net/jfx/pull/673/files/2d321087..741aa92f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=673&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=673&range=03-04 Stats: 98 lines in 2 files changed: 58 ins; 40 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/673.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/673/head:pull/673 PR: https://git.openjdk.java.net/jfx/pull/673 From duke at openjdk.java.net Thu Jan 6 08:32:16 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Thu, 6 Jan 2022 08:32:16 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> <2ToUUw8Har8rqexRIrQovxsUvzzPrzHjIEDqRSz_9PQ=.d0dbaa50-f0e1-47ae-ab94-7ec79ba34ec9@github.com> Message-ID: On Wed, 22 Dec 2021 13:32:06 GMT, Kevin Rushforth wrote: >> A cache that's manually invalidated and then validated when needed is a form of lazy evaluation. The main point, regardless of how you name it, is to ensure that every call that modifies the underlying BitSet invalidates the size. If it does, and it can be proven to do so, then that's sufficient. > > I checked, and I think that `set(int index, int... indices)` is fine, since it doesn't modify `bitset` directly, and all of the methods it calls that do modify it, correctly invalidate `size`. > > One more thing I spotted that needs to be checked, is the `SelectedIndicesList(BitSet)` constructor. It saves a reference to the source `BitSet` without making a copy. If a caller ever modified the source `BitSet`, it would change the underlying `BitSet` seen by the `SelectedIndicesList` class, and the size would therefore be wrong. Even if the current code doesn't do this, it's somewhat fragile. I recommend adding a comment to the constructor, and to the one place it's called, noting that the source `BitSet` must not be modified after passing it to the constructor. > > Finally, there is a commented out `clearAndSelect` method that would break the new contract of invalidating size whenever the bitmap is modified, if that method were ever uncommented. Either it should be deleted as part of this PR or it should be modified with a (commented out, of course) `size = -1` in the right place(s). I have added some tests which calls public methods in `MultipleSelectionModelBase` and in turn calls methods from `SelectedIndicesList`. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From aghaisas at openjdk.java.net Thu Jan 6 12:39:19 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 6 Jan 2022 12:39:19 GMT Subject: RFR: 8279328: CssParser uses default charset instead of UTF-8 In-Reply-To: References: Message-ID: On Wed, 29 Dec 2021 15:39:39 GMT, Michael Strau? wrote: > `CssParser.parse(URL)` is specified to assume UTF-8 file encoding, but (implicitly) uses the default charset to read the file, potentially resulting in incorrect interpretation of the file content. > > This can be fixed by explicitly specifying the UTF-8 charset for `InputStreamReader`. The added test passes on my Mac without changing CssParser.java. It may be due to the default charset being UTF-8. Which platform did you test on? ------------- PR: https://git.openjdk.java.net/jfx/pull/705 From nlisker at openjdk.java.net Thu Jan 6 13:00:18 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 6 Jan 2022 13:00:18 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v6] In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 13:13:09 GMT, Nir Lisker wrote: >> Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. >> >> I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. >> >> I noticed a drop of ~1 fps in the stress test of 5000 meshes. >> >> I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Added import The CSR has been approved, but I don't see it being registered here. ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From kcr at openjdk.java.net Thu Jan 6 13:06:17 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 Jan 2022 13:06:17 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v6] In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 13:13:09 GMT, Nir Lisker wrote: >> Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. >> >> I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. >> >> I noticed a drop of ~1 fps in the stress test of 5000 meshes. >> >> I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Added import The Skara bot needed something to wake it up, and your comment did just that. ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From nlisker at openjdk.java.net Thu Jan 6 13:13:22 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 6 Jan 2022 13:13:22 GMT Subject: Integrated: 8234921: Add DirectionalLight to the selection of 3D light types In-Reply-To: References: Message-ID: On Mon, 28 Jun 2021 12:13:44 GMT, Nir Lisker wrote: > Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. > > I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. > > I noticed a drop of ~1 fps in the stress test of 5000 meshes. > > I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. This pull request has now been integrated. Changeset: 32f21ffd Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/32f21ffda9ca21285aac7119458efa35e9b44418 Stats: 543 lines in 29 files changed: 482 ins; 11 del; 50 mod 8234921: Add DirectionalLight to the selection of 3D light types Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From mstrauss at openjdk.java.net Thu Jan 6 15:21:16 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 6 Jan 2022 15:21:16 GMT Subject: RFR: 8279328: CssParser uses default charset instead of UTF-8 In-Reply-To: References: Message-ID: <11YiQ_P_rlTlmOLKowzBQGwML5Kl3_7A9iin5AApt2c=.7a1d4064-7d86-407c-831f-d07d796288cf@github.com> On Thu, 6 Jan 2022 12:35:56 GMT, Ajit Ghaisas wrote: > The added test passes on my Mac without changing CssParser.java. It may be due to the default charset being UTF-8. Which platform did you test on? Yes, the default charset on macOS is UTF-8. I?ve tested this on Windows 11, which uses Windows-1252 as the default charset. ------------- PR: https://git.openjdk.java.net/jfx/pull/705 From nlisker at openjdk.java.net Thu Jan 6 15:57:28 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 6 Jan 2022 15:57:28 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v4] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Wed, 5 Jan 2022 12:29:01 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Apply changes suggested in review and updated copyright years to 2022 modules/javafx.base/src/main/java/javafx/beans/binding/ObjectBinding.java line 194: > 192: /** > 193: * Checks if the binding has at least one listener registered on it. This > 194: * is useful for subclasses which want to conserve resources when not observed. Nitpick: "which" -> "that" modules/javafx.base/src/main/java/javafx/beans/binding/ObjectBinding.java line 205: > 203: /** > 204: * Checks if the binding is allowed to become valid. Overriding classes can > 205: * prevent a binding from becoming valid. This is useful in subclasses which Nitpick: "which" -> "that" modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 162: > 160: * > 161: * @param the type of values held by the resulting {@code ObservableValue} > 162: * @param mapper a {@code Function} which converts a given value to a new value, cannot be null `{@code null}` ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From nlisker at openjdk.java.net Thu Jan 6 15:57:28 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 6 Jan 2022 15:57:28 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v3] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Wed, 5 Jan 2022 10:51:28 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 152: >> >>> 150: * @return an {@link ObservableValue} which provides a mapping of the value >>> 151: * held by this {@code ObservableValue}, and provides {@code null} when >>> 152: * this {@code ObservableValue} holds {@code null}, never null >> >> No need for `@link`. >> >> Since we already explained how the mapping works, maybe we can be more brief here: >> >> an {@code ObservableValue} that holds the result of the mapping of the value >> held by this {@code ObservableValue}; never {@code null} itself > > I think that `@return` should mention that the returned observable can hold `null`, how about: > > an {@code ObservableValue} that holds a mapping of this {@code ObservableValue}'s value > or holds {@code null} when the value is {@code null}; never returns {@code null} Good idea to mention that it can hold `null`. I slightly prefer to say that the returned `ObservableValue` holds the result of the mapping rather than holds the mapping. I don't really mind it, but it's the phrasing used in the method description "holds the result of applying a mapping". "The mapping" itself could be mistaken for the mapping `Function` in my opinion. If you think it's clear, you can change it to that phrasing, it's also fine. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From nlisker at openjdk.java.net Thu Jan 6 17:10:24 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 6 Jan 2022 17:10:24 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v4] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <-LQI7iaRoyiyvVkL8WNyiYROrsxl_IIvInIg0cNXOjg=.469c661e-ed01-4d14-9fa6-91339cff2848@github.com> On Wed, 5 Jan 2022 12:29:01 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Apply changes suggested in review and updated copyright years to 2022 The changes look good. I added some minor grammar comments. I think that the API is in a good spot. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 145: > 143: /** > 144: * Creates an {@code ObservableValue} that holds the result of applying a > 145: * mapping on the value held by this {@code ObservableValue}. The result is After one of your suggestions, another phrasing for `on the value held by this {@code ObservableValue}` is `on this {@code ObservableValue}'s value`, which is a bit shorter. If you think it helps, you can make this change here and in other places. Fine to leave as it. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 164: > 162: * @param mapper a {@code Function} which converts a given value to a new value, cannot be null > 163: * @return an {@code ObservableValue} holding a mapping of this {@code ObservableValue}'s value > 164: * or holds {@code null} when the value is {@code null}; never returns {@code null} * Comma before "or" * holds -> holding (or the "holding" in the first line -> "that holds", just needs to be consistent) modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 178: > 176: *

> 177: * For example, mapping a string to an upper case string but leaving it blank > 178: * if the input was {@code null}: * Comma before "but" * "input was" -> "input is" modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 190: > 188: * holds {@code null}; can be {@code null} > 189: * @return an {@code ObservableValue} holding this {@code ObservableValue}'s value > 190: * or the given value when the value is {@code null}; never returns {@code null} Comma before "or" modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 201: > 199: * The result is updated when either this {@code ObservableValue} or the {@code ObservableValue} > 200: * resulting from the mapping changes. If this value is {@code null}, no mapping is applied > 201: * and the resulting value is {@code null}. If the mapping resulted in {@code null} then Comma before "then" modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 204: > 202: * the resulting value is also {@code null}. > 203: *

> 204: * For example, a property which is only true when a UI element is part of a {@code Scene} * {@code true} * "which" -> "that" modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 205: > 203: *

> 204: * For example, a property which is only true when a UI element is part of a {@code Scene} > 205: * which is part of a {@code Window} that is currently shown on screen: "which" -> "that" modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 232: > 230: * > 231: * @param the type of values held by the resulting {@code ObservableValue} > 232: * @param mapper a {@code Function} which converts a given value to an "which" -> "that" modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 236: > 234: * @return an {@code ObservableValue} holding the value of an {@code ObservableValue} > 235: * resulting from a mapping of this {@code ObservableValue}'s value or > 236: * holds {@code null} when the value is {@code null}; never returns {@code null} * Comma before "or" * holds -> holding (or the "holding" in the first line -> "that holds", just needs to be consistent) ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From kcr at openjdk.java.net Thu Jan 6 19:11:19 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 Jan 2022 19:11:19 GMT Subject: RFR: 8279228 Leak in ScrollPaneSkin, related to touch events In-Reply-To: References: Message-ID: On Thu, 23 Dec 2021 17:43:19 GMT, Florian Kirmaier wrote: > Fixing memoryleak, related to touch events in ScrollPaneWhen touchDetected or mouseDown is true, the sbTouch animation is running, > and the node is removed from the Scene, then the animation will never stop, causing a memory leak. > A simple fix is to also check, whether the Node is visible, by checking the "isTreeShowing" property. Two quick questions: 1. The fix checks whether or not the node is treeShowing at the time the `startSBReleasedAnimation` method is called. Is this sufficient? If a node's tree showing state changes, is it guaranteed that this method will be called? 2. Can you provide an automated test for this? ------------- PR: https://git.openjdk.java.net/jfx/pull/701 From kcr at openjdk.java.net Thu Jan 6 21:36:24 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 Jan 2022 21:36:24 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Fri, 17 Dec 2021 20:38:56 GMT, Kevin Rushforth wrote: >> Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: >> >> Update ROW_COUNT to 700_000 > > tests/manual/controls/SelectListViewTest.java line 66: > >> 64: long t = System.currentTimeMillis(); >> 65: listView.getSelectionModel().clearSelection(); >> 66: System.out.println("time:"+ (System.currentTimeMillis() - t)); > > MInor: space before the `+` here and a few places below. This is still pending. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From kcr at openjdk.java.net Thu Jan 6 21:36:23 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 Jan 2022 21:36:23 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v5] In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Thu, 6 Jan 2022 08:17:53 GMT, Abhinay Agarwal wrote: >> This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. >> >> The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs >> >> There are currently 2 manual tests for this fix. > > Abhinay Agarwal has updated the pull request incrementally with two additional commits since the last revision: > > - Remove commented out method. Document constructors. > - Add tests The fix looks good. I left a few comments on the tests. modules/javafx.controls/src/test/java/test/javafx/scene/control/MultipleSelectionModelImplTest.java line 1427: > 1425: assertTrue(model.isSelected(2)); > 1426: assertTrue(model.isSelected(5)); > 1427: assertFalse(model.isSelected(0)); I recommend to also check the size. modules/javafx.controls/src/test/java/test/javafx/scene/control/MultipleSelectionModelImplTest.java line 1436: > 1434: model.clearSelection(); > 1435: > 1436: assertTrue(model.getSelectedIndices().isEmpty()); I recommend to also check the size. tests/manual/controls/SelectTableViewTest.java line 40: > 38: public class SelectTableViewTest extends Application { > 39: > 40: final int ROW_COUNT = 700_000; This count is too large, even with the fix. I recommend changing it to something smaller (no more than `70_000`, which matches what you did for `SelectListViewTest`). tests/manual/controls/SelectTableViewTest.java line 101: > 99: long t = System.currentTimeMillis(); > 100: tableView.getSelectionModel().selectAll(); > 101: System.out.println("time:"+ (System.currentTimeMillis() - t)); Minor: space before the `+` here and a few places below (also in the other test as noted). ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From kcr at openjdk.java.net Fri Jan 7 00:35:12 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Jan 2022 00:35:12 GMT Subject: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v4] In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 03:43:42 GMT, Michael Strau? wrote: >> `com.sun.javafx.iio.ImageStorage` currently ignores the MIME image subtype specified for images encoded in data URIs. This should be improved as follows: >> >> 1. If the specified image subtype is not supported, an exception will be thrown. >> 2. If the specified image subtype is supported, but the data contained in the URI is of a different (but also supported) image format, the image will be loaded and a warning will be logged. For example, if the MIME type is "image/jpeg", but the image data is PNG, the following warning will be generated: >> >> >> Image format 'PNG' does not match MIME type 'image/jpeg' in URI 'data:image/jpeg;base64,iVBORw0KGgoAAA...AAAElFTkSuQmCC' >> >> >> Also, the javadoc of `javafx.scene.image.Image` incorrectly states: >> >> 94 * If a URL uses the "data" scheme, the data must be base64-encoded >> 95 * and the MIME type must either be empty or a subtype of the >> 96 * {@code image} type. >> >> However, omitting the MIME type of a data URI is specified to imply "text/plain" (RFC 2397, section 2). Since the `com.sun.javafx.util.DataURI` class is implemented according to this specification, trying to load an image without MIME type correctly fails with an `ImageStorageException`: "Unexpected MIME type: text". >> >> The solution is to fix the documentation: >> >> 94 * If a URL uses the "data" scheme, the data must be base64-encoded >> - 95 * and the MIME type must either be empty or a subtype of the >> - 96 * {@code image} type. >> + 95 * and the MIME type must be a subtype of the {@code image} type. >> + 96 * The MIME type must match the image format of the data contained in >> + 97 * the URL. In case of a mismatch between MIME type and image format, >> + 98 * the image will be loaded if the image format can be determined by >> + 99 * JavaFX, and a warning will be logged. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Added test for image format without signature The API doc change looks good to me. Go ahead and finalize the CSR. The fix and test look good with one question about what looks like an unrelated change. modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ImageStorage.java line 490: > 488: if (stream.read(header) <= 0) { > 489: return null; > 490: } What was the reason for this change? The former would work even if the stream returned less data that the size of the header in a single read, whereas the latter would fail. ------------- PR: https://git.openjdk.java.net/jfx/pull/676 From aghaisas at openjdk.java.net Fri Jan 7 06:38:12 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 7 Jan 2022 06:38:12 GMT Subject: RFR: 8279328: CssParser uses default charset instead of UTF-8 In-Reply-To: References: Message-ID: <5Yw2of8NFSdHJIoxT0agCATIQZZzcgUAVY6ktYtsD48=.fb487111-3e0f-4700-a85a-e786a334e3e6@github.com> On Wed, 29 Dec 2021 15:39:39 GMT, Michael Strau? wrote: > `CssParser.parse(URL)` is specified to assume UTF-8 file encoding, but (implicitly) uses the default charset to read the file, potentially resulting in incorrect interpretation of the file content. > > This can be fixed by explicitly specifying the UTF-8 charset for `InputStreamReader`. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/705 From duke at openjdk.java.net Fri Jan 7 07:39:20 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Fri, 7 Jan 2022 07:39:20 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v5] In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Thu, 6 Jan 2022 21:01:11 GMT, Kevin Rushforth wrote: >> Abhinay Agarwal has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove commented out method. Document constructors. >> - Add tests > > modules/javafx.controls/src/test/java/test/javafx/scene/control/MultipleSelectionModelImplTest.java line 1436: > >> 1434: model.clearSelection(); >> 1435: >> 1436: assertTrue(model.getSelectedIndices().isEmpty()); > > I recommend to also check the size. Isn't checking the size redundant in this case? `model.getSelectedIndices().isEmpty()` indicates that `model.getSelectedIndices().size()` is `0`. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From duke at openjdk.java.net Fri Jan 7 08:04:53 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Fri, 7 Jan 2022 08:04:53 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v6] In-Reply-To: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: <6T0ii9_HHpPM4DyQbVTeXwccSKe8fOeDkbZENSqnub4=.f24f50d0-80fc-42e4-9902-96bbc72abd18@github.com> > This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. > > The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs > > There are currently 2 manual tests for this fix. Abhinay Agarwal has updated the pull request incrementally with two additional commits since the last revision: - Format code and reduce test size - Add size assertion to test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/673/files - new: https://git.openjdk.java.net/jfx/pull/673/files/741aa92f..30fb31c4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=673&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=673&range=04-05 Stats: 16 lines in 3 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jfx/pull/673.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/673/head:pull/673 PR: https://git.openjdk.java.net/jfx/pull/673 From sykora at openjdk.java.net Fri Jan 7 09:16:18 2022 From: sykora at openjdk.java.net (Joeri Sykora) Date: Fri, 7 Jan 2022 09:16:18 GMT Subject: RFR: 8267059: Gradle :clean and :apps tasks fail on Windows if ANT_HOME contains spaces [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 05:04:17 GMT, Michael Strau? wrote: >> This PR fixes an issue when building OpenJFX on Windows and command-line arguments contain paths with spaces. >> >> The problem is that on Windows, `ant` is invoked via `cmd`, which leads to quotes being interpreted twice. This can be fixed with the option `cmd /s`, which prevents interpreting quotes on the rest of the command line. The result is as if the rest of the command line had been typed verbatim at the command prompt. > > 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 two additional commits since the last revision: > > - Merge branch 'master' into fixes/JDK-8267059 > - Use cmd /s option when building on Windows Marked as reviewed by sykora (Author). I've tested these changes and I can confirm that it works as expected. ------------- PR: https://git.openjdk.java.net/jfx/pull/499 From lbourges at openjdk.java.net Fri Jan 7 09:40:27 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 7 Jan 2022 09:40:27 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used Message-ID: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Draft PR to see how big is the MarlinFX 0.9.4.5 patch (DPQS, Path clipper fixes to handle huge coords) ------------- Commit messages: - fixed jcheck warning (tab) - Merge branch 'openjdk:master' into marlinFX-0.9.4.5 - minor changes (syntax, warnings) + merge with marlin 0.9.4.5 (jdk) - fixed bad IntArrayCache usages + clean white spaces - initial marlinFX 0.9.4.5 for openjfx 18 Changes: https://git.openjdk.java.net/jfx/pull/674/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=674&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274066 Stats: 4086 lines in 31 files changed: 2594 ins; 1218 del; 274 mod Patch: https://git.openjdk.java.net/jfx/pull/674.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/674/head:pull/674 PR: https://git.openjdk.java.net/jfx/pull/674 From jvos at openjdk.java.net Fri Jan 7 09:40:27 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 7 Jan 2022 09:40:27 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used In-Reply-To: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: <8_E09re9b46gsdoE3BZkKMVglJbd0Zfeprd3o6Q_dUY=.f4252b16-df4f-474a-b0d4-3550e1092a6e@github.com> On Wed, 17 Nov 2021 22:05:25 GMT, Laurent Bourg?s wrote: > Draft PR to see how big is the MarlinFX 0.9.4.5 patch (DPQS, Path clipper fixes to handle huge coords) @bourgesl can you rename the title of this PR to 8274066: Polygon filled outside its area when very large coordinates are used ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From lbourges at openjdk.java.net Fri Jan 7 09:40:27 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 7 Jan 2022 09:40:27 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used In-Reply-To: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Wed, 17 Nov 2021 22:05:25 GMT, Laurent Bourg?s wrote: > Draft PR to see how big is the MarlinFX 0.9.4.5 patch (DPQS, Path clipper fixes to handle huge coords) I will add changelog asap ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From kcr at openjdk.java.net Fri Jan 7 11:40:15 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Jan 2022 11:40:15 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v6] In-Reply-To: <6T0ii9_HHpPM4DyQbVTeXwccSKe8fOeDkbZENSqnub4=.f24f50d0-80fc-42e4-9902-96bbc72abd18@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> <6T0ii9_HHpPM4DyQbVTeXwccSKe8fOeDkbZENSqnub4=.f24f50d0-80fc-42e4-9902-96bbc72abd18@github.com> Message-ID: On Fri, 7 Jan 2022 08:04:53 GMT, Abhinay Agarwal wrote: >> This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. >> >> The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs >> >> There are currently 2 manual tests for this fix. > > Abhinay Agarwal has updated the pull request incrementally with two additional commits since the last revision: > > - Format code and reduce test size > - Add size assertion to test Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/673 From mstrauss at openjdk.java.net Fri Jan 7 11:50:20 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 7 Jan 2022 11:50:20 GMT Subject: Integrated: 8267059: Gradle :clean and :apps tasks fail on Windows if ANT_HOME contains spaces In-Reply-To: References: Message-ID: On Thu, 13 May 2021 00:07:15 GMT, Michael Strau? wrote: > This PR fixes an issue when building OpenJFX on Windows and command-line arguments contain paths with spaces. > > The problem is that on Windows, `ant` is invoked via `cmd`, which leads to quotes being interpreted twice. This can be fixed with the option `cmd /s`, which prevents interpreting quotes on the rest of the command line. The result is as if the rest of the command line had been typed verbatim at the command prompt. This pull request has now been integrated. Changeset: 487e4b17 Author: Michael Strau? Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/487e4b17e6bfca754f8fccf2f720a1bf686d1102 Stats: 45 lines in 1 file changed: 27 ins; 15 del; 3 mod 8267059: Gradle :clean and :apps tasks fail on Windows if ANT_HOME contains spaces Reviewed-by: kcr, sykora ------------- PR: https://git.openjdk.java.net/jfx/pull/499 From kcr at openjdk.java.net Fri Jan 7 13:01:45 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Jan 2022 13:01:45 GMT Subject: RFR: 8279615: Change JavaFX release version to 19 Message-ID: <7rssAxILuknW69p-jzMFo5inJlNS1eSU06SnvnwsYf8=.d496c57c-27a4-4be6-90ab-6cfdbd4f3cef@github.com> Bump the version number of JavaFX to 19. I will integrate this immediately after forking the `jfx18` stabilization branch, which is scheduled for Thursday, January 13, 2021 at 16:00 UTC. ------------- Commit messages: - 8279615: Change JavaFX release version to 19 Changes: https://git.openjdk.java.net/jfx/pull/707/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=707&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279615 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/707.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/707/head:pull/707 PR: https://git.openjdk.java.net/jfx/pull/707 From arapte at openjdk.java.net Fri Jan 7 13:16:20 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 7 Jan 2022 13:16:20 GMT Subject: RFR: 8279615: Change JavaFX release version to 19 In-Reply-To: <7rssAxILuknW69p-jzMFo5inJlNS1eSU06SnvnwsYf8=.d496c57c-27a4-4be6-90ab-6cfdbd4f3cef@github.com> References: <7rssAxILuknW69p-jzMFo5inJlNS1eSU06SnvnwsYf8=.d496c57c-27a4-4be6-90ab-6cfdbd4f3cef@github.com> Message-ID: On Fri, 7 Jan 2022 12:55:33 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 19. I will integrate this immediately after forking the `jfx18` stabilization branch, which is scheduled for Thursday, January 13, 2021 at 16:00 UTC. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/707 From jvos at openjdk.java.net Fri Jan 7 14:10:12 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 7 Jan 2022 14:10:12 GMT Subject: RFR: 8279615: Change JavaFX release version to 19 In-Reply-To: <7rssAxILuknW69p-jzMFo5inJlNS1eSU06SnvnwsYf8=.d496c57c-27a4-4be6-90ab-6cfdbd4f3cef@github.com> References: <7rssAxILuknW69p-jzMFo5inJlNS1eSU06SnvnwsYf8=.d496c57c-27a4-4be6-90ab-6cfdbd4f3cef@github.com> Message-ID: On Fri, 7 Jan 2022 12:55:33 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 19. I will integrate this immediately after forking the `jfx18` stabilization branch, which is scheduled for Thursday, January 13, 2022 at 16:00 UTC. ok (once 18 is branched) ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/707 From fkirmaier at openjdk.java.net Fri Jan 7 16:06:32 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 7 Jan 2022 16:06:32 GMT Subject: RFR: 8279228 Leak in ScrollPaneSkin, related to touch events In-Reply-To: References: Message-ID: On Thu, 23 Dec 2021 17:43:19 GMT, Florian Kirmaier wrote: > Fixing memoryleak, related to touch events in ScrollPaneWhen touchDetected or mouseDown is true, the sbTouch animation is running, > and the node is removed from the Scene, then the animation will never stop, causing a memory leak. > A simple fix is to also check, whether the Node is visible, by checking the "isTreeShowing" property. 1.) It's not only called at the beginning of the `startSBReleasedAnimation`, but whenever the animation is repeated, which is the cause for the leak. It happens when `touchDetected == true || mouseDown == true` is true. The animation is then basically restarted every frame. With my change, it also checks whether the node is still visible, which fixes the problem. 2.) It's probably possible if there is a way to simulate Touch Events. The Robot doesn't seem to support it. A test would also require a way to set the "IS_TOUCH_SUPPORTED" property. Honestly, I don't think it's a good time investment, because the fix is quite simple. I don't even know exactly when it happens - I've just made sure it no longer loops the animation when the ScrollPane is no longer visible. I've also applied the fix in an affected application, and it clearly fixes the problem. ------------- PR: https://git.openjdk.java.net/jfx/pull/701 From kcr at openjdk.java.net Fri Jan 7 18:24:54 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Jan 2022 18:24:54 GMT Subject: RFR: 8273998: Clarify specification for Window properties controlled by the window manager Message-ID: Update the API specification for the `Window` and `Stage` classes to clarify that the values for some properties and methods can be changed or ignored by the platform. Several of the properties already have a comment to the effect that the value can change externally, and thus the properties are not bindable, but this should be clarified further and for all such properties and methods. See the Description of the JBS issues for this bug and its associated CSR for more details. ------------- Commit messages: - additional doc updates - 8273998: Clarify specification for Window properties controlled by the window manager Changes: https://git.openjdk.java.net/jfx/pull/708/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=708&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273998 Stats: 84 lines in 2 files changed: 59 ins; 4 del; 21 mod Patch: https://git.openjdk.java.net/jfx/pull/708.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/708/head:pull/708 PR: https://git.openjdk.java.net/jfx/pull/708 From jpereda at openjdk.java.net Fri Jan 7 19:42:00 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 7 Jan 2022 19:42:00 GMT Subject: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected Message-ID: This PR adds a predicate to TableView and TreeTableView selection models order to remove rows from the selection only when there are no selected cells in that given row, when cell selection is enabled. Two tests have been added as well, that fail without this PR and pass with it. ------------- Commit messages: - Add a predicate to remove rows from selection based on selected cells Changes: https://git.openjdk.java.net/jfx/pull/709/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=709&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273336 Stats: 113 lines in 5 files changed: 110 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/709.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/709/head:pull/709 PR: https://git.openjdk.java.net/jfx/pull/709 From jpereda at openjdk.java.net Fri Jan 7 20:05:46 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 7 Jan 2022 20:05:46 GMT Subject: RFR: 8273339: IOOBE with ListChangeListener added to the selectedItems list of a TableView Message-ID: This PR converts the change's `from` field from a list of tablePositions into a list of selected indices of rows. It includes two tests for TableView and one for TreeTableView (the second test wasn't included due to an [issue|https://bugs.openjdk.java.net/browse/JDK-8232825] with key navigation), that pass with this PR and fail without it. ------------- Commit messages: - Convert change from list of tablePosition to list of rows Changes: https://git.openjdk.java.net/jfx/pull/710/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=710&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273339 Stats: 147 lines in 3 files changed: 143 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/710.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/710/head:pull/710 PR: https://git.openjdk.java.net/jfx/pull/710 From lbourges at openjdk.java.net Fri Jan 7 20:43:29 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 7 Jan 2022 20:43:29 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used In-Reply-To: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Wed, 17 Nov 2021 22:05:25 GMT, Laurent Bourg?s wrote: > Changelog for this MarlinFX 0.9.4.5 release: > > The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: > - removed simple-precision (float) variant > - improved Stroker to handle huge coordinates, up to 1E15 > - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 > > > This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: > - Update DPQS to latest OpenJDK 14 patch > - Improve cubic curve offset computation > > > The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: > - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. > > > Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: > - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. > > > This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. > > Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: > see https://github.com/bourgesl/nearly-optimal-mergesort-code Sorry I forgot to explain why I did not write any new test: - I wrote a quadrant test in my own project that tests this clipper bug exhaustively, using all combinations, but it was visual, not automated like a robot. - existing ClipShapeTest already validates using a fuzzy testing approach all clipper possible cases with small coords in range [-300, 300]. The new clipper algorithm in this patch still passes this hardness test on small coords, so no regression is present. I tested up to 10^6 random shapes for every test cases (order 1,2,3) + all cap/join/fill combinations. To conclude, I decided to skip writing another test for this bug. Cheers ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From kcr at openjdk.java.net Fri Jan 7 23:38:30 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Jan 2022 23:38:30 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used In-Reply-To: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Wed, 17 Nov 2021 22:05:25 GMT, Laurent Bourg?s wrote: > Changelog for this MarlinFX 0.9.4.5 release: > > The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: > - removed simple-precision (float) variant > - improved Stroker to handle huge coordinates, up to 1E15 > - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 > > > This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: > - Update DPQS to latest OpenJDK 14 patch > - Improve cubic curve offset computation > > > The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: > - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. > > > Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: > - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. > > > This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. > > Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: > see https://github.com/bourgesl/nearly-optimal-mergesort-code Would a targeted test for the failing case from the bug report make sense? ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From lbourges at openjdk.java.net Fri Jan 7 23:42:28 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 7 Jan 2022 23:42:28 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Fri, 7 Jan 2022 23:35:37 GMT, Kevin Rushforth wrote: > Would a targeted test for the failing case from the bug report make sense? I agree the rule is to have a test, I will write a basic test derived from user's case asap. ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From mhanl at openjdk.java.net Sat Jan 8 00:22:45 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Sat, 8 Jan 2022 00:22:45 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE Message-ID: This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`. The following NPEs are fixed (all are also covered by exactly one test case): NPEs with null selection model: - Mouse click on a `ListCell` - SPACE key press - KP_UP (arrow up) key press - HOME key press - END key press - BACK_SLASH + CTRL key press NPEs with null focus model: - SPACE key press - Select an items: getSelectionModel().select(1) - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3"); ------------- Commit messages: - 8279640: ListView with null SelectionModel/FocusModel throws NPE Changes: https://git.openjdk.java.net/jfx/pull/711/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=711&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279640 Stats: 145 lines in 4 files changed: 130 ins; 2 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/711.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/711/head:pull/711 PR: https://git.openjdk.java.net/jfx/pull/711 From jhendrikx at openjdk.java.net Sat Jan 8 14:35:32 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sat, 8 Jan 2022 14:35:32 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: References: Message-ID: <2Q7FHy6dTS8PGbKexvrc7vU7YR7aecvAaU2opcYxfgQ=.f77ca169-074e-4f5c-9e37-d5eb8f47937a@github.com> On Sat, 8 Jan 2022 00:17:36 GMT, Marius Hanl wrote: > This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`. > > The following NPEs are fixed (all are also covered by exactly one test case): > NPEs with null selection model: > - Mouse click on a `ListCell` > - SPACE key press > - KP_UP (arrow up) key press > - HOME key press > - END key press > - BACK_SLASH + CTRL key press > > NPEs with null focus model: > - SPACE key press > - Select an items: getSelectionModel().select(1) > - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3"); Was it considered to not allow these models to be set to `null` instead? Or to use a Null Object? I'd much prefer this instead of polluting the code with `null` checks on every access of these models. Furthermore, the API makes no mention what is supposed to happen when these models are set to `null`, so this seems undefined at this time. If `null` is supposed to be valid then I think the documentation should clearly state what this means. Having no focus model for example should probably mean that nothing can ever get focus and that the focused item is always null and index is always -1. Instead of adding null checks to achieve this however I'd use a `NullFocusModel` instance as it is easy to forget a `null` check (also when making future changes). Same goes for the selection model; if set to `null` it should not allow any kind of selection, which again seems best achieved by installing a model that ignores all such actions and always returns empty values. ------------- PR: https://git.openjdk.java.net/jfx/pull/711 From mstrauss at openjdk.java.net Sat Jan 8 16:58:23 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 8 Jan 2022 16:58:23 GMT Subject: Integrated: 8279328: CssParser uses default charset instead of UTF-8 In-Reply-To: References: Message-ID: On Wed, 29 Dec 2021 15:39:39 GMT, Michael Strau? wrote: > `CssParser.parse(URL)` is specified to assume UTF-8 file encoding, but (implicitly) uses the default charset to read the file, potentially resulting in incorrect interpretation of the file content. > > This can be fixed by explicitly specifying the UTF-8 charset for `InputStreamReader`. This pull request has now been integrated. Changeset: be3b3bd2 Author: Michael Strau? Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/be3b3bd2a3af078b7c43a400014721efc6824efa Stats: 31 lines in 2 files changed: 30 ins; 0 del; 1 mod 8279328: CssParser uses default charset instead of UTF-8 Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/705 From mstrauss at openjdk.java.net Sat Jan 8 17:08:59 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 8 Jan 2022 17:08:59 GMT Subject: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v5] In-Reply-To: References: Message-ID: > `com.sun.javafx.iio.ImageStorage` currently ignores the MIME image subtype specified for images encoded in data URIs. This should be improved as follows: > > 1. If the specified image subtype is not supported, an exception will be thrown. > 2. If the specified image subtype is supported, but the data contained in the URI is of a different (but also supported) image format, the image will be loaded and a warning will be logged. For example, if the MIME type is "image/jpeg", but the image data is PNG, the following warning will be generated: > > > Image format 'PNG' does not match MIME type 'image/jpeg' in URI 'data:image/jpeg;base64,iVBORw0KGgoAAA...AAAElFTkSuQmCC' > > > Also, the javadoc of `javafx.scene.image.Image` incorrectly states: > > 94 * If a URL uses the "data" scheme, the data must be base64-encoded > 95 * and the MIME type must either be empty or a subtype of the > 96 * {@code image} type. > > However, omitting the MIME type of a data URI is specified to imply "text/plain" (RFC 2397, section 2). Since the `com.sun.javafx.util.DataURI` class is implemented according to this specification, trying to load an image without MIME type correctly fails with an `ImageStorageException`: "Unexpected MIME type: text". > > The solution is to fix the documentation: > > 94 * If a URL uses the "data" scheme, the data must be base64-encoded > - 95 * and the MIME type must either be empty or a subtype of the > - 96 * {@code image} type. > + 95 * and the MIME type must be a subtype of the {@code image} type. > + 96 * The MIME type must match the image format of the data contained in > + 97 * the URL. In case of a mismatch between MIME type and image format, > + 98 * the image will be loaded if the image format can be determined by > + 99 * JavaFX, and a warning will be logged. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: revert code change ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/676/files - new: https://git.openjdk.java.net/jfx/pull/676/files/4cb5678a..35a41e06 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=676&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=676&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/676.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/676/head:pull/676 PR: https://git.openjdk.java.net/jfx/pull/676 From mstrauss at openjdk.java.net Sat Jan 8 17:30:55 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 8 Jan 2022 17:30:55 GMT Subject: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v6] In-Reply-To: References: Message-ID: > `com.sun.javafx.iio.ImageStorage` currently ignores the MIME image subtype specified for images encoded in data URIs. This should be improved as follows: > > 1. If the specified image subtype is not supported, an exception will be thrown. > 2. If the specified image subtype is supported, but the data contained in the URI is of a different (but also supported) image format, the image will be loaded and a warning will be logged. For example, if the MIME type is "image/jpeg", but the image data is PNG, the following warning will be generated: > > > Image format 'PNG' does not match MIME type 'image/jpeg' in URI 'data:image/jpeg;base64,iVBORw0KGgoAAA...AAAElFTkSuQmCC' > > > Also, the javadoc of `javafx.scene.image.Image` incorrectly states: > > 94 * If a URL uses the "data" scheme, the data must be base64-encoded > 95 * and the MIME type must either be empty or a subtype of the > 96 * {@code image} type. > > However, omitting the MIME type of a data URI is specified to imply "text/plain" (RFC 2397, section 2). Since the `com.sun.javafx.util.DataURI` class is implemented according to this specification, trying to load an image without MIME type correctly fails with an `ImageStorageException`: "Unexpected MIME type: text". > > The solution is to fix the documentation: > > 94 * If a URL uses the "data" scheme, the data must be base64-encoded > - 95 * and the MIME type must either be empty or a subtype of the > - 96 * {@code image} type. > + 95 * and the MIME type must be a subtype of the {@code image} type. > + 96 * The MIME type must match the image format of the data contained in > + 97 * the URL. In case of a mismatch between MIME type and image format, > + 98 * the image will be loaded if the image format can be determined by > + 99 * JavaFX, and a warning will be logged. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Don't let EOFException bubble up ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/676/files - new: https://git.openjdk.java.net/jfx/pull/676/files/35a41e06..3b086bd8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=676&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=676&range=04-05 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/676.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/676/head:pull/676 PR: https://git.openjdk.java.net/jfx/pull/676 From mstrauss at openjdk.java.net Sat Jan 8 17:36:27 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 8 Jan 2022 17:36:27 GMT Subject: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v4] In-Reply-To: References: Message-ID: On Fri, 7 Jan 2022 00:01:24 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Added test for image format without signature > > modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ImageStorage.java line 490: > >> 488: if (stream.read(header) <= 0) { >> 489: return null; >> 490: } > > What was the reason for this change? The former would work even if the stream returned less data that the size of the header in a single read, whereas the latter would fail. Well, almost. `ImageTools.readFully` throws `EOFException` if the input stream is empty. That doesn't make a lot of sense in the context of `getLoaderBySignature`, since the method should return `null` if the input stream doesn't contain enough data to detect a signature (and it doesn't seem useful to me to make a distinction between "not enough" bytes and zero bytes). I've opted to retain the use of `ImageTools.readFully`, but catch the `EOFException` and return `null` instead. ------------- PR: https://git.openjdk.java.net/jfx/pull/676 From jvos at openjdk.java.net Sun Jan 9 15:25:52 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Sun, 9 Jan 2022 15:25:52 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed Message-ID: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> 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. ------------- Commit messages: - resize cell when getting it from the pile, and recalculate total estimated size Changes: https://git.openjdk.java.net/jfx/pull/712/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=712&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277785 Stats: 63 lines in 2 files changed: 63 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712 From lbourges at openjdk.java.net Mon Jan 10 00:04:00 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 10 Jan 2022 00:04:00 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2] In-Reply-To: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: > Changelog for this MarlinFX 0.9.4.5 release: > > The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: > - improved Stroker to handle huge coordinates, up to 1E15 > - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 > > > This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: > - Update DPQS to latest OpenJDK 14 patch > - Improve cubic curve offset computation > > > The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: > - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. > > > Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: > - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. > > > This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. > > Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: > see https://github.com/bourgesl/nearly-optimal-mergesort-code Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: added test for huge polygon coords ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/674/files - new: https://git.openjdk.java.net/jfx/pull/674/files/8859d244..94874a15 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=674&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=674&range=00-01 Stats: 278 lines in 1 file changed: 278 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/674.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/674/head:pull/674 PR: https://git.openjdk.java.net/jfx/pull/674 From lbourges at openjdk.java.net Mon Jan 10 00:04:01 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 10 Jan 2022 00:04:01 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: <4sVOlT1qHLFA_JayZrcEdKwhrQrcsfzD95h8Km5KEDA=.c8a0d081-00f2-4451-85eb-727109c4dad1@github.com> On Fri, 7 Jan 2022 23:39:05 GMT, Laurent Bourg?s wrote: > Would a targeted test for the failing case from the bug report make sense? I added the HugePolygonClipTest that fails on jdk11, 17 ... but now passes. ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From fkirmaier at openjdk.java.net Mon Jan 10 09:02:31 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 10 Jan 2022 09:02:31 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed In-Reply-To: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: On Sun, 9 Jan 2022 15:20:36 GMT, Johan Vos wrote: > When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. I've just tested it with the TestProgram of the ticket, and it is now less wrong, but still not correct. There is a small empty are, of the size of about 5 pixels. Screenshot 2022-01-10 at 09 56 31 This happens with the 1, 2, and 3rd button, but not with the 4th button. The order of the clicks doesn't seem to matter. ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From fkirmaier at openjdk.java.net Mon Jan 10 11:49:27 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 10 Jan 2022 11:49:27 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException [v2] In-Reply-To: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> References: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Message-ID: > Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. > ticket: https://bugs.openjdk.java.net/browse/JDK-8256397 > run test: `./gradlew --continue -PFULL_TEST=true controls:test --tests "*MultipleSelectionModelImplTest*"` Florian Kirmaier has updated the pull request 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 one additional commit since the last revision: 8256397 Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/353/files - new: https://git.openjdk.java.net/jfx/pull/353/files/08f6abbf..2f6dd153 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=353&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=353&range=00-01 Stats: 727295 lines in 11058 files changed: 385829 ins; 235008 del; 106458 mod Patch: https://git.openjdk.java.net/jfx/pull/353.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/353/head:pull/353 PR: https://git.openjdk.java.net/jfx/pull/353 From aghaisas at openjdk.java.net Mon Jan 10 12:09:42 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 10 Jan 2022 12:09:42 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v6] In-Reply-To: <6T0ii9_HHpPM4DyQbVTeXwccSKe8fOeDkbZENSqnub4=.f24f50d0-80fc-42e4-9902-96bbc72abd18@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> <6T0ii9_HHpPM4DyQbVTeXwccSKe8fOeDkbZENSqnub4=.f24f50d0-80fc-42e4-9902-96bbc72abd18@github.com> Message-ID: <1i48CaSSPX7ObxDs2lxkhcjrl8VLV0qaPNJN27mbwG0=.779eefe0-faa0-4b96-8e99-7c0ee4ae5058@github.com> On Fri, 7 Jan 2022 08:04:53 GMT, Abhinay Agarwal wrote: >> This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. >> >> The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs >> >> There are currently 2 manual tests for this fix. > > Abhinay Agarwal has updated the pull request incrementally with two additional commits since the last revision: > > - Format code and reduce test size > - Add size assertion to test The code changes look good. I tested on Mac. This PR drastically improves the selection time for the provided manual test. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/673 From fkirmaier at openjdk.java.net Mon Jan 10 12:29:04 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 10 Jan 2022 12:29:04 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException [v3] In-Reply-To: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> References: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Message-ID: > Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. > ticket: https://bugs.openjdk.java.net/browse/JDK-8256397 > run test: `./gradlew --continue -PFULL_TEST=true controls:test --tests "*MultipleSelectionModelImplTest*"` Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK_8256397 Added a small test-factory, to test more cases ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/353/files - new: https://git.openjdk.java.net/jfx/pull/353/files/2f6dd153..42807262 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=353&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=353&range=01-02 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/353.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/353/head:pull/353 PR: https://git.openjdk.java.net/jfx/pull/353 From lbourges at openjdk.java.net Mon Jan 10 12:45:36 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 10 Jan 2022 12:45:36 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Fri, 7 Jan 2022 23:35:37 GMT, Kevin Rushforth wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Would a targeted test for the failing case from the bug report make sense? @kevinrushforth I added a new test: it fails on jfx11 & 17, passes with the patch. Ready for review ? ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From fkirmaier at openjdk.java.net Mon Jan 10 13:16:29 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 10 Jan 2022 13:16:29 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException [v3] In-Reply-To: References: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Message-ID: On Mon, 10 Jan 2022 12:29:04 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 incrementally with one additional commit since the last revision: > > JDK_8256397 > Added a small test-factory, to test more cases I've rebased the PR to the current master. I've also added some more test-cases. It would be great if we could finish the PR, because it's already a year old. If I make the following call, I get the following changes: selectionModel.selectIndices(0,2,3); c.getAddedSubList() -> [0, 2, 3] selectionModel.selectIndices(1,4,5); c.getAddedSubList() -> [1, 2, 3] This looks wrong to me, but I don't know the logic too well, can this be somehow correct? On the other side, I would like to finish it, without looking for other bugs. ------------- PR: https://git.openjdk.java.net/jfx/pull/353 From jpereda at openjdk.java.net Mon Jan 10 20:41:30 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 10 Jan 2022 20:41:30 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Wed, 29 Dec 2021 00:44:44 GMT, Andreas Heger wrote: > This also solves [JDK-8205915 [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage](https://bugs.openjdk.java.net/browse/JDK-8205915l). > > I must admit that I don't have 100% insight about what actually caused the problems and how the event flow completely works. > > In MacOS, key events with a command or control modifier are handled via the performKeyEquivalent method, first. If no view or window handles such a shortcut key event (indicated by a return value NO in performKeyEquivalent), the key event is sent a second time via the sendEvent method. Before this fix, the method **sendJavaKeyEvent** in **GlassViewDelegate.m** seemed to be called twice: first by performKeyEquivalent and then by sendEvent, since no responder returned YES in performKeyEquivalent. For not handling the same event twice in JFX, there seemed to be a workaround in **sendJavaKeyEvent** in **GlassViewDelegate.m**. It only handled the first call. The second call checked if the given event was exactly the same like in the last call. In this case it simply returned and did not forward the event. This means that all key events with a CMD or CTRL modifier were handled in JFX in the performKeyEquivalent event loop, even though they actually weren't used by the MacOS keyEquivale nt functionality and all responders returned NO in performKeyEquivalent. So MacOS sent the event again to all responders in the sendEvent loop. I assume that the window has been destroyed already, when MacOS tried to send the second event to it, because the closing was handled in the first call. Sending an event to a no longer existing window probably caused the crash by an unhandled exception. > > It seems that this problem existed in the past and there was a workaround in **GlassWindow.m**. In the method **performKeyEquivalent**, it was checked if the window was closed and if so, it returned YES. However, nowadays the window closing check did not work... self->gWindow->isClosed returned NO when I debugged it, although the window should be closed by the key event. Returning YES in case of a closed window is not a clean solution, anyway, because YES should mean that the shortcut key equivalent is handled. Another point is that Apple writes that overwriting performKeyEquivalent in an NSWindow subclass is discouraged. So, I completely deleted the method from **GlassWindow.m**, since it only returned the value of the super function, except for the non working closing check. > > Since the default version of performKeyEquivalent in NSWindow always returns NO, only deleting the method from **GlassWindow.m** did not fix the crash. So I tried to solve the problem that a shortcut key event is handled in the performKeyEquivalent loop. The call of **sendJavaKeyEvent** in **GlassViewDelegate.m** which is caused by a performKeyEquivalent should not be handled, actually. So, I simply removed this call which is done in **GlassView3D.m** **performKeyEquivalent** method. By removing the call, there is also no longer any need to check if the same key event was passed to **sendJavaKeyEvent** in **GlassViewDelegate.m**, so this check is also removed. > > I'm curious about your comments and reviews and I wonder if this is a clean solution. All my tests so far seemed to be fine. I've tested successfully this PR, running: - [JDK-8242544](https://bugs.openjdk.java.net/browse/JDK-8242544): https://bugs.openjdk.java.net/secure/attachment/87645/CrashMe.java - [JDK-8205915](https://bugs.openjdk.java.net/browse/JDK-8205915): https://bugs.openjdk.java.net/secure/attachment/77302/Main.java - And sample code from https://github.com/javafxports/openjdk-jfx/issues/370 The three of them work fine with this PR and fail without it. I've been thinking about the need of having some tests for this, but since this is only for Mac, and we need `performKeyEvent` being called, the system tests won't work. However, I guess a manual test is good enough? Any of the above cases can be easily added to tests/manual. ------------- PR: https://git.openjdk.java.net/jfx/pull/704 From jhendrikx at openjdk.java.net Mon Jan 10 21:09:15 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 10 Jan 2022 21:09:15 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v5] 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: <9nHf-iDivaY2uA-UZ4u0M_2pwvszEGwxh5TjJKhVXck=.63894eb0-dc08-47ac-b672-5b0d5e4a464a@github.com> > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix grammar mistakes and did some small rephrases ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/675/files - new: https://git.openjdk.java.net/jfx/pull/675/files/30e8ceac..040bfe40 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=03-04 Stats: 24 lines in 1 file changed: 0 ins; 1 del; 23 mod Patch: https://git.openjdk.java.net/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/675/head:pull/675 PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Mon Jan 10 21:09:17 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 10 Jan 2022 21:09:17 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v4] In-Reply-To: <-LQI7iaRoyiyvVkL8WNyiYROrsxl_IIvInIg0cNXOjg=.469c661e-ed01-4d14-9fa6-91339cff2848@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <-LQI7iaRoyiyvVkL8WNyiYROrsxl_IIvInIg0cNXOjg=.469c661e-ed01-4d14-9fa6-91339cff2848@github.com> Message-ID: On Thu, 6 Jan 2022 16:25:33 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Apply changes suggested in review and updated copyright years to 2022 > > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 145: > >> 143: /** >> 144: * Creates an {@code ObservableValue} that holds the result of applying a >> 145: * mapping on the value held by this {@code ObservableValue}. The result is > > After one of your suggestions, another phrasing for `on the value held by this {@code ObservableValue}` is `on this {@code ObservableValue}'s value`, which is a bit shorter. If you think it helps, you can make this change here and in other places. Fine to leave as it. I did another grammar pass and have tried to use the same phrasing everywhere. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jvos at openjdk.java.net Mon Jan 10 21:38:29 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 10 Jan 2022 21:38:29 GMT Subject: RFR: 8273998: Clarify specification for Window properties controlled by the window manager In-Reply-To: References: Message-ID: <5ubQhqcv-bVb8tdpsHIaJAfrZ2MYBa-ujzR7CELVAaI=.f824eb0e-aff9-48df-946e-d51ff103e203@github.com> On Fri, 7 Jan 2022 18:19:23 GMT, Kevin Rushforth wrote: > Update the API specification for the `Window` and `Stage` classes to clarify that the values for some properties and methods can be changed or ignored by the platform. Several of the properties already have a comment to the effect that the value can change externally, and thus the properties are not bindable, but this should be clarified further and for all such properties and methods. > > See the Description of the JBS issues for this bug and its associated CSR for more details. This looks ok to me. The clarifications make sense. There is unfortunately no guarantee about (low-level) cross-platform behaviour in these cases, but at least the JavaDoc makes this clear. ------------- PR: https://git.openjdk.java.net/jfx/pull/708 From duke at openjdk.java.net Tue Jan 11 04:48:29 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Tue, 11 Jan 2022 04:48:29 GMT Subject: Integrated: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: <4JkD7bXbNJ7ez5dEzgG5RhnL4ist5l8EngpNt8_TrhM=.18b25d91-5524-4452-9e99-27a8c7358939@github.com> On Wed, 17 Nov 2021 05:34:46 GMT, Abhinay Agarwal wrote: > This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. > > The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs > > There are currently 2 manual tests for this fix. This pull request has now been integrated. Changeset: 8c4f966b Author: Abhinay Agarwal Committer: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/8c4f966b163f68c517574e38c394b9349551ad08 Stats: 403 lines in 5 files changed: 357 ins; 40 del; 6 mod 8197991: Selecting many items in a TableView is very slow Co-authored-by: Naohiro Yoshimoto Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From mhanl at openjdk.java.net Tue Jan 11 08:18:26 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 11 Jan 2022 08:18:26 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: <2Q7FHy6dTS8PGbKexvrc7vU7YR7aecvAaU2opcYxfgQ=.f77ca169-074e-4f5c-9e37-d5eb8f47937a@github.com> References: <2Q7FHy6dTS8PGbKexvrc7vU7YR7aecvAaU2opcYxfgQ=.f77ca169-074e-4f5c-9e37-d5eb8f47937a@github.com> Message-ID: On Sat, 8 Jan 2022 14:32:30 GMT, John Hendrikx wrote: > Same goes for the selection model; if set to `null` it should not allow any kind of selection, which again seems best achieved by installing a model that ignores all such actions and always returns empty values. We had a similar discussion on https://github.com/openjdk/jfx/pull/557. We came to the conclusion that we allow null as a selection or focusmodel and don't set a noop selection model or something of this kind. The biggest problem with this is the following example: I as a developer set the selection model to null via `setSelectionModel(null)`. Now if the code silently set the selection model to an empty noop selection model, we won't get null when calling `getSelectionModel()`, which a developer would expect. Also from a look of the code, even if we use a noop focus model, we would still the focus because of the `anchor` stuff, which is set in the `ListViewBehaviour`. If we do a null check and fast return like now, they won't be set -> there are not visible. So it might not even fix our problem but makes even more. ------------- PR: https://git.openjdk.java.net/jfx/pull/711 From jhendrikx at openjdk.java.net Tue Jan 11 09:05:32 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Tue, 11 Jan 2022 09:05:32 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: References: Message-ID: <_1o1rIEYrV7bCc5272WY1RWTZC8COA1jnU8VOTG1pJw=.2ed841df-9bdf-4daa-a360-5857412abbea@github.com> On Sat, 8 Jan 2022 00:17:36 GMT, Marius Hanl wrote: > This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`. > > The following NPEs are fixed (all are also covered by exactly one test case): > NPEs with null selection model: > - Mouse click on a `ListCell` > - SPACE key press > - KP_UP (arrow up) key press > - HOME key press > - END key press > - BACK_SLASH + CTRL key press > > NPEs with null focus model: > - SPACE key press > - Select an items: getSelectionModel().select(1) > - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3"); > We had a similar discussion on #557. We came to the conclusion that we allow null as a selection or focusmodel and don't set a noop selection model or something of this kind. Even earlier though in https://github.com/javafxports/openjdk-jfx/issues/569 a `NONE` model was suggested. And I still think that makes much more sense, because in effect the "behavior" of the `NONE` model is now spread out over dozens of places in the code (as the `null` checks are what is defining the behavior) instead of in a single place. > The biggest problem with this is the following example: I as a developer set the selection model to null via `setSelectionModel(null)`. Now if the code silently set the selection model to an empty noop selection model, we won't get null when calling `getSelectionModel()`, which a developer would expect. This is an example from `ListView` which already does something custom because the property is lazily instantiated: public final MultipleSelectionModel getSelectionModel() { return selectionModel == null ? null : selectionModel.get(); } Just write that as: public final MultipleSelectionModel getSelectionModel() { return selectionModel == null ? null : selectionModel.get() == NONE_SELECTION_MODEL ? null : selectionModel.get(); } `NONE_SELECTION_MODEL` is stateless so only a single instance is needed. > Also from a look of the code, even if we use a noop focus model, we would still the focus because of the `anchor` stuff, which is set in the `ListViewBehaviour`. If we do a null check and fast return like now, they won't be set -> there are not visible. So it might not even fix our problem but makes even more. A check can also be done to see if something matches the `NONE` model, just like you can check for `null`, so you can still fast return in special cases. The chosen approach works as well of course. ------------- PR: https://git.openjdk.java.net/jfx/pull/711 From mhanl at openjdk.java.net Tue Jan 11 13:07:38 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 11 Jan 2022 13:07:38 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: <_1o1rIEYrV7bCc5272WY1RWTZC8COA1jnU8VOTG1pJw=.2ed841df-9bdf-4daa-a360-5857412abbea@github.com> References: <_1o1rIEYrV7bCc5272WY1RWTZC8COA1jnU8VOTG1pJw=.2ed841df-9bdf-4daa-a360-5857412abbea@github.com> Message-ID: On Tue, 11 Jan 2022 09:01:51 GMT, John Hendrikx wrote: > ``` > public final MultipleSelectionModel getSelectionModel() { > return selectionModel == null ? null : > selectionModel.get() == NONE_SELECTION_MODEL ? null : selectionModel.get(); > } > ``` That would work altough I think it's a bit hacky as when I listen on the `selectionModelProperty` I still would get the noop selection model. I'm in general not a fan of 'self-changing' properties. When a null value is possible, guards against are needed. Unfortunately there is no built-in way to forbid null in Java as whole. > A check can also be done to see if something matches the `NONE` model, just like you can check for `null`, so you can still fast return in special cases. But then I don't see any advantage as it makes no difference if we check for NONE model or null. Checks are needed in any case. ------------- PR: https://git.openjdk.java.net/jfx/pull/711 From duke at openjdk.java.net Tue Jan 11 14:47:53 2022 From: duke at openjdk.java.net (eduardsdv) Date: Tue, 11 Jan 2022 14:47:53 GMT Subject: RFR: 8244234: MenuButton: NPE on removing from scene with open popup Message-ID: <7ZKE5nr--G67c-cJVTfdL_enSZ3RgmOQsksX8cANW2Q=.909b7201-ddff-470f-9201-8e263f3d9fd5@github.com> The NPE occurs when the skinnable is removed from the scene while the popup is showing. The MenuButtonSkinBase, when popup becomes hidden, tries to remove Mnemonics from the scene and runs into NPE. To avoid NPE a null-check is added to the 'showing' listener. Since the mnemonics cannot be removed from the scene in standard way, when popup becomes hidden. They are now also removed from the scene, when the skinnable is removed from it. ------------- Commit messages: - 8244234: MenuButton: NPE on removing from scene with open popup Changes: https://git.openjdk.java.net/jfx/pull/713/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=713&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244234 Stats: 116 lines in 2 files changed: 101 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/jfx/pull/713.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/713/head:pull/713 PR: https://git.openjdk.java.net/jfx/pull/713 From mstrauss at openjdk.java.net Tue Jan 11 17:24:37 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 11 Jan 2022 17:24:37 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: References: <_1o1rIEYrV7bCc5272WY1RWTZC8COA1jnU8VOTG1pJw=.2ed841df-9bdf-4daa-a360-5857412abbea@github.com> Message-ID: On Tue, 11 Jan 2022 13:04:52 GMT, Marius Hanl wrote: > When a null value is possible, guards against are needed. Unfortunately there is no built-in way to forbid null in Java as whole. I think null checks should only be done to verify the preconditions of an operation, and not to guard against bugs. This means that, when `null` is not a _valid_ value for a property (regardless of whether it is a _possible_ value), no attempt should be made to guard against this in downstream code. In fact, I would argue that doing so is a strong code smell. The question is whether or not `null` should be a valid value for the `selectionModel` and `focusModel` properties. I think there are good reasons to think that it shouldn't. The primitive property classes (`IntegerProperty`, `BooleanProperty`, etc.) have the same issue, and they deal with this situation by coercing the invalid `null` value to their respective default value. It's not clear to me whether the `ListCellBehavior.anchor` attached property setter would need any special-casing. When `null` (or `-1` in case of `ListViewBehavior.setAnchor`) is passed in, it seems to remove the anchor. Isn't that what we'd expect? ------------- PR: https://git.openjdk.java.net/jfx/pull/711 From fkirmaier at openjdk.java.net Tue Jan 11 19:04:56 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 11 Jan 2022 19:04:56 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v4] In-Reply-To: References: Message-ID: > Making the initial listener of the ListProperty weak fixes the problem. > The same is fixed for Set and Map. > Due to a smart implementation, this is done without any performance drawback. > (The trick is to have an object, which is both the WeakReference and the Changelistener) > By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8277848 Added the 3 requests whitespaces ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/689/files - new: https://git.openjdk.java.net/jfx/pull/689/files/ec90b3d1..acd470e1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=689&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=689&range=02-03 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/689.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/689/head:pull/689 PR: https://git.openjdk.java.net/jfx/pull/689 From fkirmaier at openjdk.java.net Tue Jan 11 19:04:58 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 11 Jan 2022 19:04:58 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v3] In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 18:14:44 GMT, Florian Kirmaier wrote: >> Making the initial listener of the ListProperty weak fixes the problem. >> The same is fixed for Set and Map. >> Due to a smart implementation, this is done without any performance drawback. >> (The trick is to have an object, which is both the WeakReference and the Changelistener) >> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8277848 > Further optimization based code review. > This Bugfix should now event improve the performance I've added the 3 requested whitespaces! It sill would be great if CI could catch these minor problems. ------------- PR: https://git.openjdk.java.net/jfx/pull/689 From duke at openjdk.java.net Tue Jan 11 21:14:32 2022 From: duke at openjdk.java.net (Martin Fox) Date: Tue, 11 Jan 2022 21:14:32 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Wed, 29 Dec 2021 00:44:44 GMT, Andreas Heger wrote: > This also solves [JDK-8205915 [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage](https://bugs.openjdk.java.net/browse/JDK-8205915l). > > I must admit that I don't have 100% insight about what actually caused the problems and how the event flow completely works. > > In MacOS, key events with a command or control modifier are handled via the performKeyEquivalent method, first. If no view or window handles such a shortcut key event (indicated by a return value NO in performKeyEquivalent), the key event is sent a second time via the sendEvent method. Before this fix, the method **sendJavaKeyEvent** in **GlassViewDelegate.m** seemed to be called twice: first by performKeyEquivalent and then by sendEvent, since no responder returned YES in performKeyEquivalent. For not handling the same event twice in JFX, there seemed to be a workaround in **sendJavaKeyEvent** in **GlassViewDelegate.m**. It only handled the first call. The second call checked if the given event was exactly the same like in the last call. In this case it simply returned and did not forward the event. This means that all key events with a CMD or CTRL modifier were handled in JFX in the performKeyEquivalent event loop, even though they actually weren't used by the MacOS keyEquivale nt functionality and all responders returned NO in performKeyEquivalent. So MacOS sent the event again to all responders in the sendEvent loop. I assume that the window has been destroyed already, when MacOS tried to send the second event to it, because the closing was handled in the first call. Sending an event to a no longer existing window probably caused the crash by an unhandled exception. > > It seems that this problem existed in the past and there was a workaround in **GlassWindow.m**. In the method **performKeyEquivalent**, it was checked if the window was closed and if so, it returned YES. However, nowadays the window closing check did not work... self->gWindow->isClosed returned NO when I debugged it, although the window should be closed by the key event. Returning YES in case of a closed window is not a clean solution, anyway, because YES should mean that the shortcut key equivalent is handled. Another point is that Apple writes that overwriting performKeyEquivalent in an NSWindow subclass is discouraged. So, I completely deleted the method from **GlassWindow.m**, since it only returned the value of the super function, except for the non working closing check. > > Since the default version of performKeyEquivalent in NSWindow always returns NO, only deleting the method from **GlassWindow.m** did not fix the crash. So I tried to solve the problem that a shortcut key event is handled in the performKeyEquivalent loop. The call of **sendJavaKeyEvent** in **GlassViewDelegate.m** which is caused by a performKeyEquivalent should not be handled, actually. So, I simply removed this call which is done in **GlassView3D.m** **performKeyEquivalent** method. By removing the call, there is also no longer any need to check if the same key event was passed to **sendJavaKeyEvent** in **GlassViewDelegate.m**, so this check is also removed. > > I'm curious about your comments and reviews and I wonder if this is a clean solution. All my tests so far seemed to be fine. I reviewed the Mac glass code and it seems the smallest change we can make to prevent the crash is to set the NSWindow's contentView to a dummy NSView instead of nil. I don't see any place in the code where the contentView is inspected or is assumed to be a glass NSView subclass. I can submit the PR since I already have a branch set up to test it. I suspect performKeyEquivalent was originally implemented because before macOS 10.5 it was the only way to receive key events with the Cmd modifier. These days we can receive those events via keyDown. For now it's main purpose is to ensure we get key events before the system menu bar does. @jperedadnr The test case for JDK-8205915 tests a particular aspect of performKeyEquivalent that I just learned about (I've been watching some exciting WWDC videos lately). If the main and key windows are not the same they can both end up processing the same key event via performKeyEquivalent. That's a great test case. I don't think the javafxports test case reveals the underlying ordering issue. Cmd+V should be handled by the textField directly and the MenuItem should not fire. I suspect with performKeyEquivalent removed the opposite is happening and only the MenuItem is firing. ------------- PR: https://git.openjdk.java.net/jfx/pull/704 From duke at openjdk.java.net Tue Jan 11 22:23:45 2022 From: duke at openjdk.java.net (Martin Fox) Date: Tue, 11 Jan 2022 22:23:45 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog Message-ID: The OS crashes if the contentView of a window is set to nil while handling processKeyEquivalent. With this PR we just set the contentView to a basic do-nothing NSView for the interim. ------------- Commit messages: - Prevent OS crash when contentView is set to nil while processing shortcut Changes: https://git.openjdk.java.net/jfx/pull/714/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=714&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242544 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/714.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/714/head:pull/714 PR: https://git.openjdk.java.net/jfx/pull/714 From kcr at openjdk.java.net Wed Jan 12 00:28:29 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Jan 2022 00:28:29 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Tue, 11 Jan 2022 22:18:53 GMT, Martin Fox wrote: > The OS crashes if the contentView of a window is set to nil while handling processKeyEquivalent. With this PR we just set the contentView to a basic do-nothing NSView for the interim. Note: This PR proposes an alternative fix to the one put forth in #704. This fix is simpler and less intrusive. ------------- PR: https://git.openjdk.java.net/jfx/pull/714 From kcr at openjdk.java.net Wed Jan 12 00:33:27 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Jan 2022 00:33:27 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Wed, 29 Dec 2021 00:44:44 GMT, Andreas Heger wrote: > This also solves [JDK-8205915 [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage](https://bugs.openjdk.java.net/browse/JDK-8205915l). > > I must admit that I don't have 100% insight about what actually caused the problems and how the event flow completely works. > > In MacOS, key events with a command or control modifier are handled via the performKeyEquivalent method, first. If no view or window handles such a shortcut key event (indicated by a return value NO in performKeyEquivalent), the key event is sent a second time via the sendEvent method. Before this fix, the method **sendJavaKeyEvent** in **GlassViewDelegate.m** seemed to be called twice: first by performKeyEquivalent and then by sendEvent, since no responder returned YES in performKeyEquivalent. For not handling the same event twice in JFX, there seemed to be a workaround in **sendJavaKeyEvent** in **GlassViewDelegate.m**. It only handled the first call. The second call checked if the given event was exactly the same like in the last call. In this case it simply returned and did not forward the event. This means that all key events with a CMD or CTRL modifier were handled in JFX in the performKeyEquivalent event loop, even though they actually weren't used by the MacOS keyEquivale nt functionality and all responders returned NO in performKeyEquivalent. So MacOS sent the event again to all responders in the sendEvent loop. I assume that the window has been destroyed already, when MacOS tried to send the second event to it, because the closing was handled in the first call. Sending an event to a no longer existing window probably caused the crash by an unhandled exception. > > It seems that this problem existed in the past and there was a workaround in **GlassWindow.m**. In the method **performKeyEquivalent**, it was checked if the window was closed and if so, it returned YES. However, nowadays the window closing check did not work... self->gWindow->isClosed returned NO when I debugged it, although the window should be closed by the key event. Returning YES in case of a closed window is not a clean solution, anyway, because YES should mean that the shortcut key equivalent is handled. Another point is that Apple writes that overwriting performKeyEquivalent in an NSWindow subclass is discouraged. So, I completely deleted the method from **GlassWindow.m**, since it only returned the value of the super function, except for the non working closing check. > > Since the default version of performKeyEquivalent in NSWindow always returns NO, only deleting the method from **GlassWindow.m** did not fix the crash. So I tried to solve the problem that a shortcut key event is handled in the performKeyEquivalent loop. The call of **sendJavaKeyEvent** in **GlassViewDelegate.m** which is caused by a performKeyEquivalent should not be handled, actually. So, I simply removed this call which is done in **GlassView3D.m** **performKeyEquivalent** method. By removing the call, there is also no longer any need to check if the same key event was passed to **sendJavaKeyEvent** in **GlassViewDelegate.m**, so this check is also removed. > > I'm curious about your comments and reviews and I wonder if this is a clean solution. All my tests so far seemed to be fine. We will likely close this PR in favor of the less-intrusive #714 unless our testing or review of that PR reveals any problems. ------------- PR: https://git.openjdk.java.net/jfx/pull/704 From kcr at openjdk.java.net Wed Jan 12 14:58:34 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Jan 2022 14:58:34 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Tue, 11 Jan 2022 22:18:53 GMT, Martin Fox wrote: > The OS crashes if the contentView of a window is set to nil while handling processKeyEquivalent. With this PR we just set the contentView to a basic do-nothing NSView for the interim. The fix looks good, and as mentioned above, is minimally intrusive. I also ran a full set of tests with no problems. It would be helpful to add a manual test as part of this PR (maybe based on the test from the bug report). ------------- PR: https://git.openjdk.java.net/jfx/pull/714 From jvos at openjdk.java.net Wed Jan 12 15:46:43 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 12 Jan 2022 15:46:43 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Tue, 11 Jan 2022 22:18:53 GMT, Martin Fox wrote: > The OS crashes if the contentView of a window is set to nil while handling processKeyEquivalent. With this PR we just set the contentView to a basic do-nothing NSView for the interim. This looks good with the current tools/OS behaviour. It is still a bit of a hack, which may result in unexpected behaviour when the macos-specific tools change. But this is a general observation with macos, so I believe this is indeed the best (and least intrusive way) to prevent the crashes. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/714 From jpereda at openjdk.java.net Wed Jan 12 16:27:29 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 12 Jan 2022 16:27:29 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Tue, 11 Jan 2022 22:18:53 GMT, Martin Fox wrote: > The OS crashes if the contentView of a window is set to nil while handling processKeyEquivalent. With this PR we just set the contentView to a basic do-nothing NSView for the interim. This PR fixes the JDK-8242544 issue as intended. I've added a couple of minor comments. Regarding #704, which also fixed the related issue JDK-8205915 but was targeting JDK-8242544, maybe it should be just updated to target the former? modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 847: > 845: { > 846: // If the contentView is set to nil within performKeyEquivalent: the OS will crash. > 847: NSView* dummy = [[NSView alloc] initWithFrame: NSMakeRect(0, 0, 10, 10)]; The view could be also created with a (0, 0, 0, 0) rect, couldn't it? modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 848: > 846: // If the contentView is set to nil within performKeyEquivalent: the OS will crash. > 847: NSView* dummy = [[NSView alloc] initWithFrame: NSMakeRect(0, 0, 10, 10)]; > 848: [window->nsWindow performSelectorOnMainThread:@selector(setContentView:) withObject:dummy waitUntilDone:YES]; I'm not sure is needed or worth it, but maybe the `dummy` view should be released? ------------- PR: https://git.openjdk.java.net/jfx/pull/714 From kcr at openjdk.java.net Wed Jan 12 16:27:29 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Jan 2022 16:27:29 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Tue, 11 Jan 2022 22:18:53 GMT, Martin Fox wrote: > The OS crashes if the contentView of a window is set to nil while handling processKeyEquivalent. With this PR we just set the contentView to a basic do-nothing NSView for the interim. In the interest of getting as much testing as possible, I'm approving this fix now. If there isn't time to add a manual test, then it can be done in the `jfx18` branch during RDP1. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/714 From kcr at openjdk.java.net Wed Jan 12 16:27:29 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Jan 2022 16:27:29 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 16:14:58 GMT, Jose Pereda wrote: >> The OS crashes if the contentView of a window is set to nil while handling processKeyEquivalent. With this PR we just set the contentView to a basic do-nothing NSView for the interim. > > modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 848: > >> 846: // If the contentView is set to nil within performKeyEquivalent: the OS will crash. >> 847: NSView* dummy = [[NSView alloc] initWithFrame: NSMakeRect(0, 0, 10, 10)]; >> 848: [window->nsWindow performSelectorOnMainThread:@selector(setContentView:) withObject:dummy waitUntilDone:YES]; > > I'm not sure is needed or worth it, but maybe the `dummy` view should be released? That's a good question. ------------- PR: https://git.openjdk.java.net/jfx/pull/714 From duke at openjdk.java.net Wed Jan 12 16:51:31 2022 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 12 Jan 2022 16:51:31 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 16:24:48 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 848: >> >>> 846: // If the contentView is set to nil within performKeyEquivalent: the OS will crash. >>> 847: NSView* dummy = [[NSView alloc] initWithFrame: NSMakeRect(0, 0, 10, 10)]; >>> 848: [window->nsWindow performSelectorOnMainThread:@selector(setContentView:) withObject:dummy waitUntilDone:YES]; >> >> I'm not sure is needed or worth it, but maybe the `dummy` view should be released? > > That's a good question. Yes, it should be released. I will update the PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/714 From duke at openjdk.java.net Wed Jan 12 16:56:12 2022 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 12 Jan 2022 16:56:12 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2] In-Reply-To: References: Message-ID: <_xR2c7mRHB4zDcfvF8_g6TC2WEpYWra7zb__qZoH6NM=.ef100093-9929-4f08-8d34-2fe705fbf022@github.com> > The OS crashes if the contentView of a window is set to nil while handling processKeyEquivalent. With this PR we just set the contentView to a basic do-nothing NSView for the interim. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Releasing dummy NSView ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/714/files - new: https://git.openjdk.java.net/jfx/pull/714/files/5674733b..f71d80f8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=714&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=714&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/714.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/714/head:pull/714 PR: https://git.openjdk.java.net/jfx/pull/714 From kcr at openjdk.java.net Wed Jan 12 18:27:33 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Jan 2022 18:27:33 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2] In-Reply-To: <_xR2c7mRHB4zDcfvF8_g6TC2WEpYWra7zb__qZoH6NM=.ef100093-9929-4f08-8d34-2fe705fbf022@github.com> References: <_xR2c7mRHB4zDcfvF8_g6TC2WEpYWra7zb__qZoH6NM=.ef100093-9929-4f08-8d34-2fe705fbf022@github.com> Message-ID: On Wed, 12 Jan 2022 16:56:12 GMT, Martin Fox wrote: >> The OS crashes if the contentView of a window is set to nil while handling processKeyEquivalent. With this PR we just set the contentView to a basic do-nothing NSView for the interim. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Releasing dummy NSView Marked as reviewed by kcr (Lead). modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 849: > 847: NSView* dummy = [[NSView alloc] initWithFrame: NSMakeRect(0, 0, 10, 10)]; > 848: [window->nsWindow performSelectorOnMainThread:@selector(setContentView:) withObject:dummy waitUntilDone:YES]; > 849: [dummy release]; This looks fine, given that we wait until the previous call to `performSelectorOnMainThread` is done. ------------- PR: https://git.openjdk.java.net/jfx/pull/714 From kcr at openjdk.java.net Wed Jan 12 18:27:33 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Jan 2022 18:27:33 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2] In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 16:14:16 GMT, Jose Pereda wrote: >> Martin Fox has updated the pull request incrementally with one additional commit since the last revision: >> >> Releasing dummy NSView > > modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 847: > >> 845: { >> 846: // If the contentView is set to nil within performKeyEquivalent: the OS will crash. >> 847: NSView* dummy = [[NSView alloc] initWithFrame: NSMakeRect(0, 0, 10, 10)]; > > The view could be also created with a (0, 0, 0, 0) rect, couldn't it? I don't know. I'm always skeptical of 0 size rectangles. I'd either leave it as-is or maybe use a `(0,0,1,1)` rectangle. ------------- PR: https://git.openjdk.java.net/jfx/pull/714 From duke at openjdk.java.net Wed Jan 12 18:39:39 2022 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 12 Jan 2022 18:39:39 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2] In-Reply-To: References: Message-ID: <6jv8EudWhUxZPXrLs4H5r_tDV7CFjy9oBJjsd43LPBo=.57cc2c19-44dc-4682-a074-bad7b5dc0d4a@github.com> On Wed, 12 Jan 2022 18:23:20 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 847: >> >>> 845: { >>> 846: // If the contentView is set to nil within performKeyEquivalent: the OS will crash. >>> 847: NSView* dummy = [[NSView alloc] initWithFrame: NSMakeRect(0, 0, 10, 10)]; >> >> The view could be also created with a (0, 0, 0, 0) rect, couldn't it? > > I don't know. I'm always skeptical of 0 size rectangles. I'd either leave it as-is or maybe use a `(0,0,1,1)` rectangle. The initial size should not matter since it will be re-sized to the window's content bounds. But I would rather avoid doing something unusual like creating a 0-sized NSView even though it almost certainly will work. ------------- PR: https://git.openjdk.java.net/jfx/pull/714 From duke at openjdk.java.net Wed Jan 12 18:39:40 2022 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 12 Jan 2022 18:39:40 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2] In-Reply-To: References: <_xR2c7mRHB4zDcfvF8_g6TC2WEpYWra7zb__qZoH6NM=.ef100093-9929-4f08-8d34-2fe705fbf022@github.com> Message-ID: <0-tCqpGlbIFEUP-vkcZ9Uu3zD5K6Xhu5G-22tPEuAhY=.6325a564-1cdb-4bf9-9379-9e76aaa7fb3a@github.com> On Wed, 12 Jan 2022 18:24:36 GMT, Kevin Rushforth wrote: >> Martin Fox has updated the pull request incrementally with one additional commit since the last revision: >> >> Releasing dummy NSView > > modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 849: > >> 847: NSView* dummy = [[NSView alloc] initWithFrame: NSMakeRect(0, 0, 10, 10)]; >> 848: [window->nsWindow performSelectorOnMainThread:@selector(setContentView:) withObject:dummy waitUntilDone:YES]; >> 849: [dummy release]; > > This looks fine, given that we wait until the previous call to `performSelectorOnMainThread` is done. For what it's worth I did complete a full run of robot-based system tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/714 From jpereda at openjdk.java.net Wed Jan 12 18:47:31 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 12 Jan 2022 18:47:31 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2] In-Reply-To: <_xR2c7mRHB4zDcfvF8_g6TC2WEpYWra7zb__qZoH6NM=.ef100093-9929-4f08-8d34-2fe705fbf022@github.com> References: <_xR2c7mRHB4zDcfvF8_g6TC2WEpYWra7zb__qZoH6NM=.ef100093-9929-4f08-8d34-2fe705fbf022@github.com> Message-ID: On Wed, 12 Jan 2022 16:56:12 GMT, Martin Fox wrote: >> The OS crashes if the contentView of a window is set to nil while handling processKeyEquivalent. With this PR we just set the contentView to a basic do-nothing NSView for the interim. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Releasing dummy NSView Marked as reviewed by jpereda (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/714 From jpereda at openjdk.java.net Wed Jan 12 18:47:31 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 12 Jan 2022 18:47:31 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2] In-Reply-To: <6jv8EudWhUxZPXrLs4H5r_tDV7CFjy9oBJjsd43LPBo=.57cc2c19-44dc-4682-a074-bad7b5dc0d4a@github.com> References: <6jv8EudWhUxZPXrLs4H5r_tDV7CFjy9oBJjsd43LPBo=.57cc2c19-44dc-4682-a074-bad7b5dc0d4a@github.com> Message-ID: On Wed, 12 Jan 2022 18:34:19 GMT, Martin Fox wrote: >> I don't know. I'm always skeptical of 0 size rectangles. I'd either leave it as-is or maybe use a `(0,0,1,1)` rectangle. > > The initial size should not matter since it will be re-sized to the window's content bounds. But I would rather avoid doing something unusual like creating a 0-sized NSView even though it almost certainly will work. Okay, no problem then. ------------- PR: https://git.openjdk.java.net/jfx/pull/714 From duke at openjdk.java.net Wed Jan 12 18:56:33 2022 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 12 Jan 2022 18:56:33 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2] In-Reply-To: <_xR2c7mRHB4zDcfvF8_g6TC2WEpYWra7zb__qZoH6NM=.ef100093-9929-4f08-8d34-2fe705fbf022@github.com> References: <_xR2c7mRHB4zDcfvF8_g6TC2WEpYWra7zb__qZoH6NM=.ef100093-9929-4f08-8d34-2fe705fbf022@github.com> Message-ID: On Wed, 12 Jan 2022 16:56:12 GMT, Martin Fox wrote: >> The OS crashes if the contentView of a window is set to nil while handling processKeyEquivalent. With this PR we just set the contentView to a basic do-nothing NSView for the interim. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Releasing dummy NSView The manual test for this can also cover JDK-8205915 (a Cmd-based shortcut can be processed by two separate windows). This crash was blocking testing on that bug. I'll submit a fix for JDK-8205915 along with the manual test tomorrow. ------------- PR: https://git.openjdk.java.net/jfx/pull/714 From kcr at openjdk.java.net Wed Jan 12 19:36:31 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Jan 2022 19:36:31 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Wed, 29 Dec 2021 00:44:44 GMT, Andreas Heger wrote: > This also solves [JDK-8205915 [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage](https://bugs.openjdk.java.net/browse/JDK-8205915l). > > I must admit that I don't have 100% insight about what actually caused the problems and how the event flow completely works. > > In MacOS, key events with a command or control modifier are handled via the performKeyEquivalent method, first. If no view or window handles such a shortcut key event (indicated by a return value NO in performKeyEquivalent), the key event is sent a second time via the sendEvent method. Before this fix, the method **sendJavaKeyEvent** in **GlassViewDelegate.m** seemed to be called twice: first by performKeyEquivalent and then by sendEvent, since no responder returned YES in performKeyEquivalent. For not handling the same event twice in JFX, there seemed to be a workaround in **sendJavaKeyEvent** in **GlassViewDelegate.m**. It only handled the first call. The second call checked if the given event was exactly the same like in the last call. In this case it simply returned and did not forward the event. This means that all key events with a CMD or CTRL modifier were handled in JFX in the performKeyEquivalent event loop, even though they actually weren't used by the MacOS keyEquivale nt functionality and all responders returned NO in performKeyEquivalent. So MacOS sent the event again to all responders in the sendEvent loop. I assume that the window has been destroyed already, when MacOS tried to send the second event to it, because the closing was handled in the first call. Sending an event to a no longer existing window probably caused the crash by an unhandled exception. > > It seems that this problem existed in the past and there was a workaround in **GlassWindow.m**. In the method **performKeyEquivalent**, it was checked if the window was closed and if so, it returned YES. However, nowadays the window closing check did not work... self->gWindow->isClosed returned NO when I debugged it, although the window should be closed by the key event. Returning YES in case of a closed window is not a clean solution, anyway, because YES should mean that the shortcut key equivalent is handled. Another point is that Apple writes that overwriting performKeyEquivalent in an NSWindow subclass is discouraged. So, I completely deleted the method from **GlassWindow.m**, since it only returned the value of the super function, except for the non working closing check. > > Since the default version of performKeyEquivalent in NSWindow always returns NO, only deleting the method from **GlassWindow.m** did not fix the crash. So I tried to solve the problem that a shortcut key event is handled in the performKeyEquivalent loop. The call of **sendJavaKeyEvent** in **GlassViewDelegate.m** which is caused by a performKeyEquivalent should not be handled, actually. So, I simply removed this call which is done in **GlassView3D.m** **performKeyEquivalent** method. By removing the call, there is also no longer any need to check if the same key event was passed to **sendJavaKeyEvent** in **GlassViewDelegate.m**, so this check is also removed. > > I'm curious about your comments and reviews and I wonder if this is a clean solution. All my tests so far seemed to be fine. Closed in favor of #714, which has now been integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/704 From duke at openjdk.java.net Wed Jan 12 19:36:32 2022 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 12 Jan 2022 19:36:32 GMT Subject: Integrated: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Tue, 11 Jan 2022 22:18:53 GMT, Martin Fox wrote: > The OS crashes if the contentView of a window is set to nil while handling processKeyEquivalent. With this PR we just set the contentView to a basic do-nothing NSView for the interim. This pull request has now been integrated. Changeset: a2a0acff Author: Martin Fox Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/a2a0acff66727167bfca879bf908361433e74791 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8242544: CMD+ENTER key event crashes the application when invoked on dialog Reviewed-by: jpereda, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/714 From kcr at openjdk.java.net Wed Jan 12 19:36:32 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Jan 2022 19:36:32 GMT Subject: Withdrawn: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Wed, 29 Dec 2021 00:44:44 GMT, Andreas Heger wrote: > This also solves [JDK-8205915 [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage](https://bugs.openjdk.java.net/browse/JDK-8205915l). > > I must admit that I don't have 100% insight about what actually caused the problems and how the event flow completely works. > > In MacOS, key events with a command or control modifier are handled via the performKeyEquivalent method, first. If no view or window handles such a shortcut key event (indicated by a return value NO in performKeyEquivalent), the key event is sent a second time via the sendEvent method. Before this fix, the method **sendJavaKeyEvent** in **GlassViewDelegate.m** seemed to be called twice: first by performKeyEquivalent and then by sendEvent, since no responder returned YES in performKeyEquivalent. For not handling the same event twice in JFX, there seemed to be a workaround in **sendJavaKeyEvent** in **GlassViewDelegate.m**. It only handled the first call. The second call checked if the given event was exactly the same like in the last call. In this case it simply returned and did not forward the event. This means that all key events with a CMD or CTRL modifier were handled in JFX in the performKeyEquivalent event loop, even though they actually weren't used by the MacOS keyEquivale nt functionality and all responders returned NO in performKeyEquivalent. So MacOS sent the event again to all responders in the sendEvent loop. I assume that the window has been destroyed already, when MacOS tried to send the second event to it, because the closing was handled in the first call. Sending an event to a no longer existing window probably caused the crash by an unhandled exception. > > It seems that this problem existed in the past and there was a workaround in **GlassWindow.m**. In the method **performKeyEquivalent**, it was checked if the window was closed and if so, it returned YES. However, nowadays the window closing check did not work... self->gWindow->isClosed returned NO when I debugged it, although the window should be closed by the key event. Returning YES in case of a closed window is not a clean solution, anyway, because YES should mean that the shortcut key equivalent is handled. Another point is that Apple writes that overwriting performKeyEquivalent in an NSWindow subclass is discouraged. So, I completely deleted the method from **GlassWindow.m**, since it only returned the value of the super function, except for the non working closing check. > > Since the default version of performKeyEquivalent in NSWindow always returns NO, only deleting the method from **GlassWindow.m** did not fix the crash. So I tried to solve the problem that a shortcut key event is handled in the performKeyEquivalent loop. The call of **sendJavaKeyEvent** in **GlassViewDelegate.m** which is caused by a performKeyEquivalent should not be handled, actually. So, I simply removed this call which is done in **GlassView3D.m** **performKeyEquivalent** method. By removing the call, there is also no longer any need to check if the same key event was passed to **sendJavaKeyEvent** in **GlassViewDelegate.m**, so this check is also removed. > > I'm curious about your comments and reviews and I wonder if this is a clean solution. All my tests so far seemed to be fine. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/704 From duke at openjdk.java.net Wed Jan 12 20:45:02 2022 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 12 Jan 2022 20:45:02 GMT Subject: RFR: 8278938: [Win] Robot can target wrong key for punctuation and symbols [v2] In-Reply-To: References: Message-ID: > When processing a `WM_CHAR` event on an OEM key (punctuation, symbol, dead key) the glass code will dynamically query the key's unshifted character to determine the Java code to assign to it. This is necessary since the relationship between OEM key codes and the characters they generate varies from layout to layout. > > The Robot implementation was consulting a table which assumed a fixed relationship between Java codes and Windows key codes even for the OEM keys. The table was also missing entries for any Java code not on a US QWERTY layout, like PLUS. > > In this PR if we don't find the Java code in the table or if it maps to an OEM key (which may be wrong) we sweep through all the OEM keys looking for the matching Java code. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: A Robot now correctly handles KeyCodes that aren't in the current layout ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/702/files - new: https://git.openjdk.java.net/jfx/pull/702/files/dcd4c98c..e9dfaa75 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=702&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=702&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/702.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/702/head:pull/702 PR: https://git.openjdk.java.net/jfx/pull/702 From kcr at openjdk.java.net Wed Jan 12 22:27:34 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Jan 2022 22:27:34 GMT Subject: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v6] In-Reply-To: References: Message-ID: On Sat, 8 Jan 2022 17:30:55 GMT, Michael Strau? wrote: >> `com.sun.javafx.iio.ImageStorage` currently ignores the MIME image subtype specified for images encoded in data URIs. This should be improved as follows: >> >> 1. If the specified image subtype is not supported, an exception will be thrown. >> 2. If the specified image subtype is supported, but the data contained in the URI is of a different (but also supported) image format, the image will be loaded and a warning will be logged. For example, if the MIME type is "image/jpeg", but the image data is PNG, the following warning will be generated: >> >> >> Image format 'PNG' does not match MIME type 'image/jpeg' in URI 'data:image/jpeg;base64,iVBORw0KGgoAAA...AAAElFTkSuQmCC' >> >> >> Also, the javadoc of `javafx.scene.image.Image` incorrectly states: >> >> 94 * If a URL uses the "data" scheme, the data must be base64-encoded >> 95 * and the MIME type must either be empty or a subtype of the >> 96 * {@code image} type. >> >> However, omitting the MIME type of a data URI is specified to imply "text/plain" (RFC 2397, section 2). Since the `com.sun.javafx.util.DataURI` class is implemented according to this specification, trying to load an image without MIME type correctly fails with an `ImageStorageException`: "Unexpected MIME type: text". >> >> The solution is to fix the documentation: >> >> 94 * If a URL uses the "data" scheme, the data must be base64-encoded >> - 95 * and the MIME type must either be empty or a subtype of the >> - 96 * {@code image} type. >> + 95 * and the MIME type must be a subtype of the {@code image} type. >> + 96 * The MIME type must match the image format of the data contained in >> + 97 * the URL. In case of a mismatch between MIME type and image format, >> + 98 * the image will be loaded if the image format can be determined by >> + 99 * JavaFX, and a warning will be logged. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Don't let EOFException bubble up Looks good. Pending a second reviewer. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/676 From duke at openjdk.java.net Thu Jan 13 00:22:47 2022 From: duke at openjdk.java.net (meghanEmbrace) Date: Thu, 13 Jan 2022 00:22:47 GMT Subject: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning Message-ID: With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. ------------- Commit messages: - 8277853 : With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning Changes: https://git.openjdk.java.net/jfx/pull/688/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=688&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277853 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/688.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/688/head:pull/688 PR: https://git.openjdk.java.net/jfx/pull/688 From kcr at openjdk.java.net Thu Jan 13 00:32:29 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Jan 2022 00:32:29 GMT Subject: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning In-Reply-To: References: Message-ID: <1bzN7hgN5KizP_XjjkGSgWAi8jEXBxldmX6KaSBMTTc=.15de738b-a65b-4c64-86fe-6b4890561559@github.com> On Thu, 2 Dec 2021 10:12:50 GMT, meghanEmbrace wrote: > With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. This seems like the correct fix, but I'll ask @aghaisas to review. What testing have you done to ensure that there are no regressions or unintended side effects of this change? Can you provide an automated test? ------------- PR: https://git.openjdk.java.net/jfx/pull/688 From kcr at openjdk.java.net Thu Jan 13 01:24:31 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Jan 2022 01:24:31 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: <4P-PQeNwbtgg8zrgC3q7CKo1Cu9NDFkiBgxT96hYWZ4=.469587ef-94a9-4ecc-9209-710403d4eda4@github.com> On Mon, 10 Jan 2022 00:04:00 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > added test for huge polygon coords I did an initial build / test (on macOS) along with a quick look at the changes. This will take a bit more time to complete. As a P3 regression, it is a possible candidate for fixing during RDP1, provided the fix is safe and well-tested. General comments: Why did you need to make a copy of the JDK DualPivotQuicksort class, `DualPivotQuicksort20191112Ext`? This is a maintenance burden that we don't want without a very compelling reason. What additional testing would you recommend? ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From jvos at openjdk.java.net Thu Jan 13 08:38:35 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 13 Jan 2022 08:38:35 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Mon, 10 Jan 2022 00:04:00 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > added test for huge polygon coords Building and testing works, I am looking into the diffs as well now. The DualPivotQuicksort20191112Ext seems to be an improved version of what is in java.util. Ideally, we can somehow extend or leverage the version in java.util without duplicating the original code. For testing: one of the tests I would like to do is to see if the complexity increases as expected when increasing coordinates. Since the original Dual-Pivot quicksort has O(n log(n)) time complexity, it should be possible to have an upper bound on the number of invocations. ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From fkirmaier at openjdk.java.net Thu Jan 13 09:52:31 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 13 Jan 2022 09:52:31 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed In-Reply-To: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: <7Hmi_DmEWFZE9ZEIF8hGs1jCz71ABrU-4woIsfa_4gQ=.bdc58bcb-e4a8-4905-85eb-f42975b1963d@github.com> On Sun, 9 Jan 2022 15:20:36 GMT, Johan Vos wrote: > When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. I've added a new button to the test programm. The 5th button now literally jumps into the "Nothingness" Screenshot 2022-01-13 at 10 48 52 . ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From aghaisas at openjdk.java.net Thu Jan 13 11:39:34 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 13 Jan 2022 11:39:34 GMT Subject: RFR: 8273998: Clarify specification for Window properties controlled by the window manager In-Reply-To: References: Message-ID: On Fri, 7 Jan 2022 18:19:23 GMT, Kevin Rushforth wrote: > Update the API specification for the `Window` and `Stage` classes to clarify that the values for some properties and methods can be changed or ignored by the platform. Several of the properties already have a comment to the effect that the value can change externally, and thus the properties are not bindable, but this should be clarified further and for all such properties and methods. > > See the Description of the JBS issues for this bug and its associated CSR for more details. Changes look good to me except at one place where you have removed the description. I will it out separately. modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 660: > 658: /** > 659: * Whether or not this {@code Window} has the keyboard or input focus. > 660: *

Is this removal intentional? ------------- PR: https://git.openjdk.java.net/jfx/pull/708 From kcr at openjdk.java.net Thu Jan 13 12:16:34 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Jan 2022 12:16:34 GMT Subject: RFR: 8273998: Clarify specification for Window properties controlled by the window manager In-Reply-To: References: Message-ID: <0AjHIJ9Fd5vcA3eRWqHn-VGE3xSgvaN38uEgo0wVvdo=.5b8a2b3e-212a-44d1-8c37-5326e2090ba1@github.com> On Thu, 13 Jan 2022 11:35:22 GMT, Ajit Ghaisas wrote: >> Update the API specification for the `Window` and `Stage` classes to clarify that the values for some properties and methods can be changed or ignored by the platform. Several of the properties already have a comment to the effect that the value can change externally, and thus the properties are not bindable, but this should be clarified further and for all such properties and methods. >> >> See the Description of the JBS issues for this bug and its associated CSR for more details. > > modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 660: > >> 658: /** >> 659: * Whether or not this {@code Window} has the keyboard or input focus. >> 660: *

> > Is this removal intentional? Yes, this is intentional. This property has no setter, so the existing comment is in error. ------------- PR: https://git.openjdk.java.net/jfx/pull/708 From aghaisas at openjdk.java.net Thu Jan 13 12:28:31 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 13 Jan 2022 12:28:31 GMT Subject: RFR: 8273998: Clarify specification for Window properties controlled by the window manager In-Reply-To: References: Message-ID: On Fri, 7 Jan 2022 18:19:23 GMT, Kevin Rushforth wrote: > Update the API specification for the `Window` and `Stage` classes to clarify that the values for some properties and methods can be changed or ignored by the platform. Several of the properties already have a comment to the effect that the value can change externally, and thus the properties are not bindable, but this should be clarified further and for all such properties and methods. > > See the Description of the JBS issues for this bug and its associated CSR for more details. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/708 From jvos at openjdk.java.net Thu Jan 13 14:29:36 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 13 Jan 2022 14:29:36 GMT Subject: RFR: 8273998: Clarify specification for Window properties controlled by the window manager In-Reply-To: References: Message-ID: On Fri, 7 Jan 2022 18:19:23 GMT, Kevin Rushforth wrote: > Update the API specification for the `Window` and `Stage` classes to clarify that the values for some properties and methods can be changed or ignored by the platform. Several of the properties already have a comment to the effect that the value can change externally, and thus the properties are not bindable, but this should be clarified further and for all such properties and methods. > > See the Description of the JBS issues for this bug and its associated CSR for more details. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/708 From lbourges at openjdk.java.net Thu Jan 13 15:24:34 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Thu, 13 Jan 2022 15:24:34 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Mon, 10 Jan 2022 00:04:00 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > added test for huge polygon coords I advocate I did not give more information on the current patch. Do you need a detailled change log ? Concerning DualPivotQuicksort20191112Ext, it was developped in collaboration with Vladimir to have a new sort algorithm based on two int arrays: a[] vector contains crossing x positions, b[] vector contains the edge indices. Both arrays are returned sorted by a (positions) to satisfy my MergeSort. It was developped in the following repository (intensively tested like the current DPQS in jdk17 or the new proposed patch for JDK19?): https://github.com/bourgesl/nearly-optimal-mergesort-code Here are java2d results with complex random polygons (1k to 100k random segments): https://raw.githubusercontent.com/bourgesl/bourgesl.github.io/master/marlin-0.9.4/diff-marlin-094-gain.png from https://github.com/bourgesl/marlin-renderer/releases/tag/v0_9_4_b2 It mostly fixes performance in case of insanely complex polygons; but it could happen with large text blocks + complex fonts or overly detailed maps. Thanks ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From kcr at openjdk.java.net Thu Jan 13 16:17:38 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Jan 2022 16:17:38 GMT Subject: Integrated: 8279615: Change JavaFX release version to 19 In-Reply-To: <7rssAxILuknW69p-jzMFo5inJlNS1eSU06SnvnwsYf8=.d496c57c-27a4-4be6-90ab-6cfdbd4f3cef@github.com> References: <7rssAxILuknW69p-jzMFo5inJlNS1eSU06SnvnwsYf8=.d496c57c-27a4-4be6-90ab-6cfdbd4f3cef@github.com> Message-ID: <5sGbsjRGt-Knj9HAfh3-qtpCouCY93Bbxn-iAgIIqu4=.272ec0d4-50d7-4d10-8695-abf74eedc30e@github.com> On Fri, 7 Jan 2022 12:55:33 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 19. I will integrate this immediately after forking the `jfx18` stabilization branch, which is scheduled for Thursday, January 13, 2022 at 16:00 UTC. This pull request has now been integrated. Changeset: dd096783 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/dd096783b806a7a5f803292adb3fbd9ddfb047f5 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod 8279615: Change JavaFX release version to 19 Reviewed-by: arapte, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/707 From kevin.rushforth at oracle.com Thu Jan 13 16:22:50 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 13 Jan 2022 08:22:50 -0800 Subject: JavaFX 18 is in Rampdown Phase One (RDP1) Message-ID: <9a9d9312-6663-0a1a-54ea-1278329c27a3@oracle.com> JavaFX 18 is now in Rampdown Phase One (RDP1) [1]. We have forked a new jfx18 branch [2] for stabilizing the JavaFX 18 release. Here is the short summary of what this means: - The master branch of the jfx repo is available for integrating bug fixes or enhancements for openjfx19. Most fixes will be integrated to master for 19. - The jfx18 branch of the jfx repo is now open for integrating fixes for openjfx18 that meet the RDP1 criteria as outlined below. - Reviewers and Committers now have an additional responsibility to verify the target branch of each pull request. - I will periodically sync jfx18 --> master, meaning that developers should integrate fixes to one or the other, not both DETAILS: P1-P3 bug fixes, and test or doc fixes of any priority are good candidates for integrating to jfx18 during RDP1. The only hard restriction is that enhancements need explicit approval, over and above the review of the PR, to go into jfx18. The bar for such approval is appropriately high. We also need to be careful to avoid potentially risky fixes during this time. Note that these restrictions apply to the jfx18 branch. The master branch is open for all openjfx19 fixes, including enhancements. As a reminder, we use a single openjdk/jfx GitHub repo with stabilization branches [3] rather than a separate stabilization repo. The jfx18 branch is used to stabilize the upcoming openjfx18 release. Please be aware of this, especially if you are a Reviewer or Committer in the Project. This allows all pull requests to be in the same place, but care needs to be taken for any PR that is targeted to jfx18 to ensure that it doesn't contain any commits from master after the jfx18 fork date. What that means is that if you intend a PR to be for jfx18, don't merge master into your local source branch! IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (OpenJFX 19 as of today). This is usually what we want. A PR should be targeted to `jfx18` if, and only if, it is intended for OpenJFX 18 and meets the criteria for the current rampdown phase (we're in RDP1 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx18`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 19. Reviewers also need to be extra careful when reviewing PRs targeted to jfx18 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed. We will use the same rules for RDP1 that the JDK uses [4], with the same three modifications we did for the previous release: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 18 release. As an obvious choice, derived from the JBS fix version, we will use "openjfx18-enhancement-request", "openjfx18-enhancement-yes", "openjfx18-enhancement-no" and "openjfx18-enhancement-nmi" as corresponding labels. 3. No explicit approval (no JBS label) is needed to integrate P4 bugs to the jfx18 branch during RDP1, as long as those bugs have otherwise met the usual code review criteria. Having said that, most P4 bugs should now go into master for openjfx19, since we do not want to risk anything that would destabilize the openjfx18 release without a compelling reason. Also, we have only 3 weeks until RDP2 of openjfx18 and we would be better served fixing higher priority bugs. Note that doc bugs and test bugs of any priority are fine to fix for openjfx18 during this time. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-November/032657.html [2] https://github.com/openjdk/jfx/tree/jfx18 [3] https://github.com/openjdk/jfx/branches/all [4] http://openjdk.java.net/jeps/3 From kcr at openjdk.java.net Thu Jan 13 17:39:25 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Jan 2022 17:39:25 GMT Subject: [jfx18] RFR: 8273998: Clarify specification for Window properties controlled by the window manager In-Reply-To: References: Message-ID: On Fri, 7 Jan 2022 18:19:23 GMT, Kevin Rushforth wrote: > Update the API specification for the `Window` and `Stage` classes to clarify that the values for some properties and methods can be changed or ignored by the platform. Several of the properties already have a comment to the effect that the value can change externally, and thus the properties are not bindable, but this should be clarified further and for all such properties and methods. > > See the Description of the JBS issues for this bug and its associated CSR for more details. This is intended for JavaFX 18, so I am changing the branch to `jfx18`, which will require a re-review by the reviewers. ------------- PR: https://git.openjdk.java.net/jfx/pull/708 From jvos at openjdk.java.net Thu Jan 13 17:50:29 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 13 Jan 2022 17:50:29 GMT Subject: [jfx18] RFR: 8273998: Clarify specification for Window properties controlled by the window manager In-Reply-To: References: Message-ID: On Fri, 7 Jan 2022 18:19:23 GMT, Kevin Rushforth wrote: > Update the API specification for the `Window` and `Stage` classes to clarify that the values for some properties and methods can be changed or ignored by the platform. Several of the properties already have a comment to the effect that the value can change externally, and thus the properties are not bindable, but this should be clarified further and for all such properties and methods. > > See the Description of the JBS issues for this bug and its associated CSR for more details. Re-approved ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/708 From duke at openjdk.java.net Thu Jan 13 19:23:51 2022 From: duke at openjdk.java.net (Martin Fox) Date: Thu, 13 Jan 2022 19:23:51 GMT Subject: RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage Message-ID: When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. ------------- Commit messages: - Re-instating fix for Cmd shortcut being handled by two windows Changes: https://git.openjdk.java.net/jfx/pull/715/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=715&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8205915 Stats: 173 lines in 2 files changed: 173 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/715.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/715/head:pull/715 PR: https://git.openjdk.java.net/jfx/pull/715 From kcr at openjdk.java.net Fri Jan 14 00:11:27 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 Jan 2022 00:11:27 GMT Subject: RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 19:18:33 GMT, Martin Fox wrote: > When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. > > This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. > > System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. This seems like a safe fix, and a candidate for fixing in JavaFX 18. If you are comfortable with the level of risk, then go ahead and change the target branch to `jfx18`. ------------- PR: https://git.openjdk.java.net/jfx/pull/715 From mhanl at openjdk.java.net Fri Jan 14 00:09:48 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Fri, 14 Jan 2022 00:09:48 GMT Subject: RFR: 8251481: TableCell accessing row: NPE on auto-sizing Message-ID: This PR will fix a simple NPE which may happens when using the `TableRow` inside a `TableCell` during the initial auto sizing. In the auto sizing code, no `TableRow` is set, therefore `getTableRow()` will return null and it is not possible to e.g. access the row item. This is fixed by adding the `TableRow` in the `resizeColumnToFitContent` method, similar as it is already done for the `TreeTableView` (`TreeTableRow`). ------------- Commit messages: - 8251481: TableCell accessing row: NPE on auto-sizing Changes: https://git.openjdk.java.net/jfx/pull/716/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=716&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251481 Stats: 28 lines in 2 files changed: 26 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/716.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/716/head:pull/716 PR: https://git.openjdk.java.net/jfx/pull/716 From duke at openjdk.java.net Fri Jan 14 00:49:43 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Fri, 14 Jan 2022 00:49:43 GMT Subject: RFR: 8255940: localStorage is null after window.close() Message-ID: Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." ------------- Commit messages: - Window.close(), Fix for localstoarge Changes: https://git.openjdk.java.net/jfx/pull/703/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255940 Stats: 128 lines in 3 files changed: 118 ins; 9 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/703/head:pull/703 PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Fri Jan 14 00:55:00 2022 From: duke at openjdk.java.net (Martin Fox) Date: Fri, 14 Jan 2022 00:55:00 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v2] In-Reply-To: References: Message-ID: > When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. > > This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. > > System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. Martin Fox 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. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/715/files - new: https://git.openjdk.java.net/jfx/pull/715/files/fc24f9c7..fc24f9c7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=715&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=715&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/715.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/715/head:pull/715 PR: https://git.openjdk.java.net/jfx/pull/715 From fastegal at openjdk.java.net Fri Jan 14 11:55:30 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 14 Jan 2022 11:55:30 GMT Subject: RFR: 8251481: TableCell accessing row: NPE on auto-sizing In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 00:04:49 GMT, Marius Hanl wrote: > This PR will fix a simple NPE which may happens when using the `TableRow` inside a `TableCell` during the initial auto sizing. > In the auto sizing code, no `TableRow` is set, therefore `getTableRow()` will return null and it is not possible to e.g. access the row item. > > This is fixed by adding the `TableRow` in the `resizeColumnToFitContent` method, similar as it is already done for the `TreeTableView` (`TreeTableRow`). hmm .. I think here are two issues: - the auto-sizing code definitely needs to fully configure the cell (with index, row, column, tableView plus applying css) to measure the correct size - the implementation of cell.updateItem (even though it's my own ;) is a bit fishy: does its spec really guarantee that getTableRow() != null if !empty()? Meanwhile, I think that's not the case - but then, it's for demonstrating the first bullet :) The first is fixed by this PR (looks good on first sight). The second might need a clarification in the method doc .. or not, undecided. ------------- PR: https://git.openjdk.java.net/jfx/pull/716 From mhanl at openjdk.java.net Fri Jan 14 18:09:29 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Fri, 14 Jan 2022 18:09:29 GMT Subject: RFR: 8251481: TableCell accessing row: NPE on auto-sizing In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 11:52:40 GMT, Jeanette Winzenburg wrote: > hmm .. I think here are two issues: > > * the auto-sizing code definitely needs to fully configure the cell (with index, row, column, tableView plus applying css) to measure the correct size > * the implementation of cell.updateItem (even though it's my own ;) is a bit fishy: does its spec really guarantee that getTableRow() != null if !empty()? Meanwhile, I think that's not the case - but then, it's for demonstrating the first bullet :) > > The first is fixed by this PR (looks good on first sight). The second might need a clarification in the method doc .. or not, undecided. Yes the auto sizing has some more issues. While looking on it, I found two problems which should be done as follow-up: 1. Both `resizeColumnToFitContent` methods do not use the row factory of the corresponding table (minor, but still something which should be improved here) 2. Currently both implementation add the `TableCell` directly into the `TableSkin`, which is not how it is usually done. Normally the `TableRow` is added (by the `VirtualFlow`), therefore the example of the related ticket [JDK-8251480](https://bugs.openjdk.java.net/browse/JDK-8251480) won't work after this fix, but may do when the `TableRow` is added instead (didn't tested it though) May both can be addressed in future via [JDK-8251480](https://bugs.openjdk.java.net/browse/JDK-8251480) ------------- PR: https://git.openjdk.java.net/jfx/pull/716 From mhanl at openjdk.java.net Fri Jan 14 20:12:33 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Fri, 14 Jan 2022 20:12:33 GMT Subject: RFR: 8187307: ListView, TableView, TreeView: receives editCancel event when edit is committed In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 12:32:37 GMT, Jeanette Winzenburg wrote: > The misbehaviour was that an edit handler received both a commit and cancel event when cell commitEdit is called. That happened whenever a collaborator reset the controls editing state (either directly or indirectly) while processing the editCommit event. The reason was that the cell had not yet updated its own editing state when receiving the change of editing from the control. > > Fix is to update cell's editing state before firing the event, that is change the sequence or method calls from fire/super.commit to super.commit/fire. > > Added tests that fail/pass before/after the fix. Looks good to me. I also did some manual tests and everything looks fine here too. ------------- Marked as reviewed by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/684 From jpereda at openjdk.java.net Fri Jan 14 20:18:57 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 14 Jan 2022 20:18:57 GMT Subject: RFR: 8273339: IOOBE with ListChangeListener added to the selectedItems list of a TableView [v2] In-Reply-To: References: Message-ID: <9UHlTn7GwMq-jxi39MMI4ntLgnIL8tRfAj26Przc4HU=.56d65c7b-8f72-4256-8f7b-705fecb22899@github.com> > This PR converts the change's `from` field from a list of tablePositions into a list of selected indices of rows. > > It includes two tests for TableView and one for TreeTableView (the second test wasn't included due to an [issue|https://bugs.openjdk.java.net/browse/JDK-8232825] with key navigation), that pass with this PR and fail without it. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Apply change only when cell selection is enabled ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/710/files - new: https://git.openjdk.java.net/jfx/pull/710/files/47abd328..ea09a464 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=710&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=710&range=00-01 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/710.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/710/head:pull/710 PR: https://git.openjdk.java.net/jfx/pull/710 From nlisker at openjdk.java.net Sun Jan 16 22:04:39 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 16 Jan 2022 22:04:39 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v5] In-Reply-To: <9nHf-iDivaY2uA-UZ4u0M_2pwvszEGwxh5TjJKhVXck=.63894eb0-dc08-47ac-b672-5b0d5e4a464a@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <9nHf-iDivaY2uA-UZ4u0M_2pwvszEGwxh5TjJKhVXck=.63894eb0-dc08-47ac-b672-5b0d5e4a464a@github.com> Message-ID: On Mon, 10 Jan 2022 21:09:15 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix grammar mistakes and did some small rephrases The API looks good to me. After you get the other reviewers to look at it you can update the CSR. As for the fluent binding tests: * The `private` fields in `ObservableValueFluentBindingsTest` can be `final`. * Most tests that I have seen in JavaFX use the assert overloads that include a message that explains what the value should be or what it means if the assertion failed. I don't know how much of a requirement it is. I can help write these if you want. * There is a utility class `JMemoryBuddy` that was added to JavaFX to test for memory leaks. This would have been helpful in the GC tests, but it seems that the class is not suited too well for this case (it requires you to `null` you own reference etc.). I think the way you did it is fine, but maybe that class should be updated (in a different patch) to be more welcoming for these checks. I would also add tests of chaining the observables in common use cases. I wrote some myself to test it for `map`: ObservableValue observableValue1 = property.map(v -> v + "Z"); ObservableValue observableValue2 = observableValue1.map(v -> v + "X"); assertEquals("AZ", observableValue1.getValue()); assertEquals("AZX", observableValue2.getValue()); property.set("B"); assertEquals("BZ", observableValue1.getValue()); assertEquals("BZX", observableValue2.getValue()); for `orElse`: ObservableValue observableValue1 = property.map(v -> v + "Z"); ObservableValue observableValue2 = observableValue1.orElse("K"); assertEquals("AZ", observableValue1.getValue()); assertEquals("AZ", observableValue2.getValue()); property.set("B"); assertEquals("BZ", observableValue1.getValue()); assertEquals("BZ", observableValue2.getValue()); property.set(null); assertNull(observableValue1.getValue()); assertEquals("K", observableValue2.getValue()); You can clean these up and use them or write your own. `flatMap` should also have one. I can clean mine up and post it if it helps (I did some dirty testing there). modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 189: > 187: * holds {@code null}; can be {@code null} > 188: * @return an {@code ObservableValue} holding this {@code ObservableValue}'s value, > 189: * or the given value it is {@code null}; never returns {@code null} `or the given value it is {@code null}` missing "when" or "if"? modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 271: > 269: @Test > 270: void shouldReturnPropertyValuesWithOperationApplied() { > 271: assertEquals((Integer) 65, observableValue.getValue()); I don't think that the cast is needed as autoboxing will take care of it. Fine to leave as-is. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From nlisker at openjdk.java.net Sun Jan 16 23:11:46 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 16 Jan 2022 23:11:46 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses Message-ID: Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. * Added examples of real-world applications for each light type. * Consolidated the writing style for all the subclasses. ------------- Commit messages: - Updated copyright years - Initial commit Changes: https://git.openjdk.java.net/jfx/pull/717/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=717&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279345 Stats: 149 lines in 5 files changed: 93 ins; 26 del; 30 mod Patch: https://git.openjdk.java.net/jfx/pull/717.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/717/head:pull/717 PR: https://git.openjdk.java.net/jfx/pull/717 From nlisker at openjdk.java.net Sun Jan 16 23:11:46 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 16 Jan 2022 23:11:46 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses In-Reply-To: References: Message-ID: On Sun, 16 Jan 2022 22:54:22 GMT, Nir Lisker wrote: > Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: > > * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. > * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. > * Added examples of real-world applications for each light type. > * Consolidated the writing style for all the subclasses. @kevinrushforth @arapte Please review this docs-only change for JavaFX 18. ------------- PR: https://git.openjdk.java.net/jfx/pull/717 From aghaisas at openjdk.java.net Mon Jan 17 05:18:30 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 17 Jan 2022 05:18:30 GMT Subject: [jfx18] RFR: 8273998: Clarify specification for Window properties controlled by the window manager In-Reply-To: References: Message-ID: On Fri, 7 Jan 2022 18:19:23 GMT, Kevin Rushforth wrote: > Update the API specification for the `Window` and `Stage` classes to clarify that the values for some properties and methods can be changed or ignored by the platform. Several of the properties already have a comment to the effect that the value can change externally, and thus the properties are not bindable, but this should be clarified further and for all such properties and methods. > > See the Description of the JBS issues for this bug and its associated CSR for more details. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/708 From aghaisas at openjdk.java.net Mon Jan 17 15:16:30 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 17 Jan 2022 15:16:30 GMT Subject: RFR: 8244234: MenuButton: NPE on removing from scene with open popup In-Reply-To: <7ZKE5nr--G67c-cJVTfdL_enSZ3RgmOQsksX8cANW2Q=.909b7201-ddff-470f-9201-8e263f3d9fd5@github.com> References: <7ZKE5nr--G67c-cJVTfdL_enSZ3RgmOQsksX8cANW2Q=.909b7201-ddff-470f-9201-8e263f3d9fd5@github.com> Message-ID: On Tue, 11 Jan 2022 14:42:19 GMT, eduardsdv wrote: > The NPE occurs when the skinnable is removed from the scene while the popup is showing. > The MenuButtonSkinBase, when popup becomes hidden, tries to remove Mnemonics from the scene and runs into NPE. > To avoid NPE a null-check is added to the 'showing' listener. > > Since the mnemonics cannot be removed from the scene in standard way, when popup becomes hidden. > They are now also removed from the scene, when the skinnable is removed from it. The fix looks OK, but, a few cleanups are required. modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java line 157: > 155: > 156: // We only need to remove the mnemonics from the old scene, > 157: // they will be added to the new one as soon as the pop becomes visible again. typo : pop --> popup modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java line 250: > 248: @Override protected double computeMinWidth(double height, double topInset, double rightInset, double bottomInset, double leftInset) { > 249: return leftInset > 250: + label.minWidth(height) Unintended spacing changes are there in computePrefHeight, computePrefWidth, computeMinHeight and computeMinWidth methods. Please revert these unrelated spacing changes. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/MenuButtonSkinBaseTest.java line 1: > 1: package test.javafx.scene.control.skin; Please add the missing copyright header. ------------- PR: https://git.openjdk.java.net/jfx/pull/713 From duke at openjdk.java.net Mon Jan 17 15:32:13 2022 From: duke at openjdk.java.net (eduardsdv) Date: Mon, 17 Jan 2022 15:32:13 GMT Subject: RFR: 8244234: MenuButton: NPE on removing from scene with open popup [v2] In-Reply-To: <7ZKE5nr--G67c-cJVTfdL_enSZ3RgmOQsksX8cANW2Q=.909b7201-ddff-470f-9201-8e263f3d9fd5@github.com> References: <7ZKE5nr--G67c-cJVTfdL_enSZ3RgmOQsksX8cANW2Q=.909b7201-ddff-470f-9201-8e263f3d9fd5@github.com> Message-ID: <-VPQ6Q4eZlyeN29c6pHu4Ttea4g6tqhoyZmFZ67-8-w=.533bc5cb-9fef-4f3b-bf5f-64644e8dfc7a@github.com> > The NPE occurs when the skinnable is removed from the scene while the popup is showing. > The MenuButtonSkinBase, when popup becomes hidden, tries to remove Mnemonics from the scene and runs into NPE. > To avoid NPE a null-check is added to the 'showing' listener. > > Since the mnemonics cannot be removed from the scene in standard way, when popup becomes hidden. > They are now also removed from the scene, when the skinnable is removed from it. eduardsdv has updated the pull request incrementally with one additional commit since the last revision: 8244234: Add changes suggested in review and add file header to the test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/713/files - new: https://git.openjdk.java.net/jfx/pull/713/files/0c598695..6749816f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=713&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=713&range=00-01 Stats: 36 lines in 2 files changed: 25 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/713.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/713/head:pull/713 PR: https://git.openjdk.java.net/jfx/pull/713 From duke at openjdk.java.net Mon Jan 17 15:32:15 2022 From: duke at openjdk.java.net (eduardsdv) Date: Mon, 17 Jan 2022 15:32:15 GMT Subject: RFR: 8244234: MenuButton: NPE on removing from scene with open popup In-Reply-To: <7ZKE5nr--G67c-cJVTfdL_enSZ3RgmOQsksX8cANW2Q=.909b7201-ddff-470f-9201-8e263f3d9fd5@github.com> References: <7ZKE5nr--G67c-cJVTfdL_enSZ3RgmOQsksX8cANW2Q=.909b7201-ddff-470f-9201-8e263f3d9fd5@github.com> Message-ID: On Tue, 11 Jan 2022 14:42:19 GMT, eduardsdv wrote: > The NPE occurs when the skinnable is removed from the scene while the popup is showing. > The MenuButtonSkinBase, when popup becomes hidden, tries to remove Mnemonics from the scene and runs into NPE. > To avoid NPE a null-check is added to the 'showing' listener. > > Since the mnemonics cannot be removed from the scene in standard way, when popup becomes hidden. > They are now also removed from the scene, when the skinnable is removed from it. I added changes suggested in the review and added the file header to the test class. Please review. ------------- PR: https://git.openjdk.java.net/jfx/pull/713 From duke at openjdk.java.net Mon Jan 17 18:00:30 2022 From: duke at openjdk.java.net (Martin Fox) Date: Mon, 17 Jan 2022 18:00:30 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v6] In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 16:42:40 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. >> >> When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. >> >> There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. >> >> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts >> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard >> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout >> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Bug fixes in Robot. Ensure symbols uncovered using Option are ignored. I've been working on automated tests for keyboard handling but am thinking of dropping them. IMHO the tests need to cover punctuation and symbols (that's where the bugs are) but testing those keys on a random keyboard layout is complicated. I'm running into bugs on Mac and Linux that I can fix but that are probably not worth the trouble. For example, with this PR dead keys are miscoded (what should be DEAD_CIRCUMFLEX is CIRCUMFLEX) and that can lead an automated test to accidentally trigger a dead key state (this can also happen on Windows though PR #702 should fix that). The fixes to get the codes right on Mac aren't deep but I don't think they would be of any benefit to JavaFX developers so I would be asking for review cycles just to appease the automated tests. The manual test attached to this thread is more likely to find relevant bugs. ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From duke at openjdk.java.net Mon Jan 17 20:29:48 2022 From: duke at openjdk.java.net (Martin Fox) Date: Mon, 17 Jan 2022 20:29:48 GMT Subject: RFR: 8278924: [Linux] Robot key test can fail if multiple keyboard layouts are installed Message-ID: <5SPjvG13-ikrrvdyb0M7KJNSmvRIM-bWEXTxLNka8Jg=.49267d9e-a893-4251-88ce-667da5567405@github.com> The Robot implementation on Linux did not consult the current layout when mapping from a KeyCode to a hardware code. Internally it retrieved results for all the layouts but just picked the first one it saw leading to random effects. Though not part of the original bug report, the code also ignored the shift level when choosing which result to pick. On a French layout the dollar sign is on two keys (AltGr 4 is the second one) and the code could choose either one. Same is true for pound. This PR consults the current layout and only on shift level 0 which is the same level used in get_glass_key to figure out which KeyCode to assign when generating a KeyEvent. ------------- Commit messages: - Robot no longer gets confused by multiple layouts Changes: https://git.openjdk.java.net/jfx/pull/718/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=718&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278924 Stats: 86 lines in 3 files changed: 73 ins; 8 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/718.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/718/head:pull/718 PR: https://git.openjdk.java.net/jfx/pull/718 From aghaisas at openjdk.java.net Tue Jan 18 10:11:35 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 18 Jan 2022 10:11:35 GMT Subject: RFR: 8244234: MenuButton: NPE on removing from scene with open popup [v2] In-Reply-To: <-VPQ6Q4eZlyeN29c6pHu4Ttea4g6tqhoyZmFZ67-8-w=.533bc5cb-9fef-4f3b-bf5f-64644e8dfc7a@github.com> References: <7ZKE5nr--G67c-cJVTfdL_enSZ3RgmOQsksX8cANW2Q=.909b7201-ddff-470f-9201-8e263f3d9fd5@github.com> <-VPQ6Q4eZlyeN29c6pHu4Ttea4g6tqhoyZmFZ67-8-w=.533bc5cb-9fef-4f3b-bf5f-64644e8dfc7a@github.com> Message-ID: On Mon, 17 Jan 2022 15:32:13 GMT, eduardsdv wrote: >> The NPE occurs when the skinnable is removed from the scene while the popup is showing. >> The MenuButtonSkinBase, when popup becomes hidden, tries to remove Mnemonics from the scene and runs into NPE. >> To avoid NPE a null-check is added to the 'showing' listener. >> >> Since the mnemonics cannot be removed from the scene in standard way, when popup becomes hidden. >> They are now also removed from the scene, when the skinnable is removed from it. > > eduardsdv has updated the pull request incrementally with one additional commit since the last revision: > > 8244234: Add changes suggested in review and add file header to the test Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/713 From fastegal at swingempire.de Tue Jan 18 14:46:57 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 18 Jan 2022 15:46:57 +0100 Subject: Strange test failures: validation of PGGroup children failed Message-ID: <20220118154657.Horde.iKWEYuOFVRGBogGLEIItQA8@webmail.df.eu> Just stumbled across it while reviewing PR 719 (https://github.com/openjdk/jfx/pull/716) - added the new test method to see it fail (which it does) - run all control tests throws the error below in _unrelated_ tests (the one below is from TableCellTest, that is the same test the new failing method resides in, but seeing similar in other tests that use Toolkit.firePulse) Still happens after a clean build from gradle (clean, sdk, :controls:test). Any idea what might be the reason? java.lang.AssertionError: validation of PGGroup children failed at javafx.graphics at 19-internal/javafx.scene.Parent.validatePG(Parent.java:243) at javafx.graphics at 19-internal/javafx.scene.Parent.doUpdatePeer(Parent.java:201) at javafx.graphics at 19-internal/javafx.scene.Parent$1.doUpdatePeer(Parent.java:109) at javafx.graphics at 19-internal/com.sun.javafx.scene.ParentHelper.updatePeerImpl(ParentHelper.java:78) at javafx.graphics at 19-internal/com.sun.javafx.scene.layout.RegionHelper.updatePeerImpl(RegionHelper.java:72) at javafx.graphics at 19-internal/com.sun.javafx.scene.NodeHelper.updatePeer(NodeHelper.java:103) at javafx.graphics at 19-internal/javafx.scene.Node.syncPeer(Node.java:715) at javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.syncAll(Scene.java:2397) at javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.syncAll(Scene.java:2406) at javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.syncAll(Scene.java:2406) at javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.syncAll(Scene.java:2406) at javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2373) at javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2529) at javafx.graphics at 19-internal/com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:405) at java.base/java.security.AccessController.doPrivileged(AccessController.java:389) at javafx.graphics at 19-internal/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:404) at javafx.graphics at 19-internal/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:434) at test.javafx.scene.control.TableCellTest.testEditCancelEventAfterModifyItems(TableCellTest.java:557) From duke at openjdk.java.net Tue Jan 18 14:54:33 2022 From: duke at openjdk.java.net (eduardsdv) Date: Tue, 18 Jan 2022 14:54:33 GMT Subject: Integrated: 8244234: MenuButton: NPE on removing from scene with open popup In-Reply-To: <7ZKE5nr--G67c-cJVTfdL_enSZ3RgmOQsksX8cANW2Q=.909b7201-ddff-470f-9201-8e263f3d9fd5@github.com> References: <7ZKE5nr--G67c-cJVTfdL_enSZ3RgmOQsksX8cANW2Q=.909b7201-ddff-470f-9201-8e263f3d9fd5@github.com> Message-ID: On Tue, 11 Jan 2022 14:42:19 GMT, eduardsdv wrote: > The NPE occurs when the skinnable is removed from the scene while the popup is showing. > The MenuButtonSkinBase, when popup becomes hidden, tries to remove Mnemonics from the scene and runs into NPE. > To avoid NPE a null-check is added to the 'showing' listener. > > Since the mnemonics cannot be removed from the scene in standard way, when popup becomes hidden. > They are now also removed from the scene, when the skinnable is removed from it. This pull request has now been integrated. Changeset: 6e215263 Author: Eduard Sedov Committer: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/6e215263e6fe94099528d386ccda65b22bce3138 Stats: 131 lines in 2 files changed: 126 ins; 1 del; 4 mod 8244234: MenuButton: NPE on removing from scene with open popup Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/713 From kcr at openjdk.java.net Tue Jan 18 15:00:37 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 18 Jan 2022 15:00:37 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v2] In-Reply-To: References: Message-ID: <1Pij53k0utvuzn39blVGkyWBZIgvp-wZeSjc46hOeUY=.291fd0da-ee15-48f7-9165-4566b1e01060@github.com> On Fri, 14 Jan 2022 00:55:00 GMT, Martin Fox wrote: >> When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. >> >> This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. >> >> System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. > > Martin Fox 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. I just started to look at this and noticed that this PR is based off of the current `master`, and has commits not in `jfx18`. You will need to rebase to `jfx18` and force-push to your branch. ------------- PR: https://git.openjdk.java.net/jfx/pull/715 From mhanl at openjdk.java.net Tue Jan 18 17:12:36 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 18 Jan 2022 17:12:36 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: References: <_1o1rIEYrV7bCc5272WY1RWTZC8COA1jnU8VOTG1pJw=.2ed841df-9bdf-4daa-a360-5857412abbea@github.com> Message-ID: <952_YvXBUl-1LwJwvKk_OTjGkwmjc58_VTVR_6A4b4k=.0ae72d74-b44c-4667-9574-6c025ae4b41d@github.com> On Tue, 11 Jan 2022 17:21:13 GMT, Michael Strau? wrote: > The question is whether or not `null` should be a valid value for the `selectionModel` and `focusModel` properties. I think there are good reasons to think that it shouldn't. The primitive property classes (`IntegerProperty`, `BooleanProperty`, etc.) have the same issue, and they deal with this situation by coercing the invalid `null` value to their respective default value. I think the property classes for primitives are another use case, since those values really can't be null. I get your point but I think a null `selectionModel` or `focusModel` should be allowed. At least an use case would be to have a read-only `ListView` which should not be selectable nor focusable. If you just set a ListView to uneditable (via `setEditable(..)`), you can still select entries. If you disable the `ListView` it is grey styled which is not desired in this use case. Of course I can change the style, but a null selection and-focusModel may make sense as well. But I agree to a certain point, maybe it make's sense to fail for some properties when null is set/or use default values (but without changing the property?). Right now some properties in e.g. `Node` can be set to null and it will throw a NPE somewhere (e.g. `setCacheHint(null)`, `setRotationAxis(null)`, `Labeled.setFont(null)` ...). But on the other hand a lot of code handle properties with null with some kind of default behaviour (the property itself is never changed). Examples for this: - `Labeled.getTextOverrun()` -> null will be handled as ELLIPSIS in LabeledSkinBase - `Labeled.getEllipsisString()` -> null will be handled as "" in LabeledSkinBase - ... So there is no consistent behaviour for this, but a lot of code already handles null by behaving in some kind of default way without changing the property directly, and I think it might be the best to adapt to this. ------------- PR: https://git.openjdk.java.net/jfx/pull/711 From kevin.rushforth at oracle.com Tue Jan 18 17:24:42 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Jan 2022 09:24:42 -0800 Subject: [jfx18] RFR: Request to sync January 2022 changes into jfx In-Reply-To: <2ad5d6d0-b3c5-75ac-1a04-5176292379fd@oracle.com> References: <2ad5d6d0-b3c5-75ac-1a04-5176292379fd@oracle.com> Message-ID: Hi Johan, I request approval to sync changes from to the just-released January 2022 CPU release into the 'jfx18' branch of the 'jfx' repo. Here is the aggregate set of changes for the fixes: https://github.com/kevinrushforth/jfx/compare/a2a0acff66...cpu-2201-sync NOTE: Since this is an integration of already-reviewed fixes, I will push it directly to the jfx18 branch of the jfx repo rather than via a pull request. -- Kevin From kevin.rushforth at oracle.com Tue Jan 18 17:24:57 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Jan 2022 09:24:57 -0800 Subject: [jfx17u, jfx11u] RFR: Request to backport January 2022 CPU changes Message-ID: <1c064f16-62b2-4f47-190e-2cf8502d0235@oracle.com> Hi Johan, I request approval to backport the changes from the just-released January 2022 CPU to jfx17u (for 17.0.2) and to jfx11u (for 11.0.14) . https://github.com/kevinrushforth/jfx17u/compare/b6b7207a19...cpu-2201-sync https://github.com/kevinrushforth/jfx11u/compare/e80660685e...cpu-2201-sync For each repo, this is a straight backport (patch applies cleanly) of the one FX fix that went into the January CPU. NOTE: Since this is an integration of already-reviewed fixes, I will push it directly to the master branch of the jfx17u and jfx11u repos rather than via a pull request. Thanks. -- Kevin From duke at openjdk.java.net Tue Jan 18 17:26:15 2022 From: duke at openjdk.java.net (Martin Fox) Date: Tue, 18 Jan 2022 17:26:15 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v3] In-Reply-To: References: Message-ID: > When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. > > This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. > > System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. Martin Fox has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Re-instating fix for Cmd shortcut being handled by two windows ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/715/files - new: https://git.openjdk.java.net/jfx/pull/715/files/fc24f9c7..edebba96 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=715&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=715&range=01-02 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/715.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/715/head:pull/715 PR: https://git.openjdk.java.net/jfx/pull/715 From johan at lodgon.com Tue Jan 18 17:51:53 2022 From: johan at lodgon.com (Johan Vos) Date: Tue, 18 Jan 2022 18:51:53 +0100 Subject: [jfx18] RFR: Request to sync January 2022 changes into jfx In-Reply-To: References: <2ad5d6d0-b3c5-75ac-1a04-5176292379fd@oracle.com> Message-ID: Approved. Op di 18 jan. 2022 om 18:25 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > Hi Johan, > > I request approval to sync changes from to the just-released January > 2022 CPU release into the 'jfx18' branch of the 'jfx' repo. Here is the > aggregate set of changes for the fixes: > > https://github.com/kevinrushforth/jfx/compare/a2a0acff66...cpu-2201-sync > > NOTE: Since this is an integration of already-reviewed fixes, I will > push it directly to the jfx18 branch of the jfx repo rather than via a > pull request. > > -- Kevin > > From johan at lodgon.com Tue Jan 18 17:53:10 2022 From: johan at lodgon.com (Johan Vos) Date: Tue, 18 Jan 2022 18:53:10 +0100 Subject: [jfx17u, jfx11u] RFR: Request to backport January 2022 CPU changes In-Reply-To: <1c064f16-62b2-4f47-190e-2cf8502d0235@oracle.com> References: <1c064f16-62b2-4f47-190e-2cf8502d0235@oracle.com> Message-ID: Approved Op di 18 jan. 2022 om 18:25 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > Hi Johan, > > I request approval to backport the changes from the just-released > January 2022 CPU to jfx17u (for 17.0.2) and to jfx11u (for 11.0.14) . > > https://github.com/kevinrushforth/jfx17u/compare/b6b7207a19...cpu-2201-sync > https://github.com/kevinrushforth/jfx11u/compare/e80660685e...cpu-2201-sync > > For each repo, this is a straight backport (patch applies cleanly) of > the one FX fix that went into the January CPU. > > NOTE: Since this is an integration of already-reviewed fixes, I will > push it directly to the master branch of the jfx17u and jfx11u repos > rather than via a pull request. > > Thanks. > > -- Kevin > > From mariushanl at web.de Tue Jan 18 18:07:12 2022 From: mariushanl at web.de (Marius Hanl) Date: Tue, 18 Jan 2022 19:07:12 +0100 Subject: Aw: Strange test failures: validation of PGGroup children failed In-Reply-To: <20220118154657.Horde.iKWEYuOFVRGBogGLEIItQA8@webmail.df.eu> References: <20220118154657.Horde.iKWEYuOFVRGBogGLEIItQA8@webmail.df.eu> Message-ID: I think I had the same issues some days ago. What helped was to delete all the 'build' or 'target' or 'out' folders - so basically all the folders with the compiled files. Gesendet: Dienstag, 18. Januar 2022 um 15:46 Uhr Von: "Jeanette Winzenburg" An: "openjfx-dev" Betreff: Strange test failures: validation of PGGroup children failed Just stumbled across it while reviewing PR 719 ([1]https://github.com/openjdk/jfx/pull/716) - added the new test method to see it fail (which it does) - run all control tests throws the error below in _unrelated_ tests (the one below is from TableCellTest, that is the same test the new failing method resides in, but seeing similar in other tests that use Toolkit.firePulse) Still happens after a clean build from gradle (clean, sdk, :controls:test). Any idea what might be the reason? java.lang.AssertionError: validation of PGGroup children failed at javafx.graphics at 19-internal/javafx.scene.Parent.validatePG(Parent.java: 243) at javafx.graphics at 19-internal/javafx.scene.Parent.doUpdatePeer(Parent.jav a:201) at javafx.graphics at 19-internal/javafx.scene.Parent$1.doUpdatePeer(Parent.j ava:109) at javafx.graphics at 19-internal/com.sun.javafx.scene.ParentHelper.updatePee rImpl(ParentHelper.java:78) at javafx.graphics at 19-internal/com.sun.javafx.scene.layout.RegionHelper.up datePeerImpl(RegionHelper.java:72) at javafx.graphics at 19-internal/com.sun.javafx.scene.NodeHelper.updatePeer( NodeHelper.java:103) at javafx.graphics at 19-internal/javafx.scene.Node.syncPeer(Node.java:715) at javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.syncA ll(Scene.java:2397) at javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.syncA ll(Scene.java:2406) at javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.syncA ll(Scene.java:2406) at javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.syncA ll(Scene.java:2406) at javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.synch ronizeSceneNodes(Scene.java:2373) at javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.pulse (Scene.java:2529) at javafx.graphics at 19-internal/com.sun.javafx.tk.Toolkit.lambda$runPulse$2 (Toolkit.java:405) at java.base/java.security.AccessController.doPrivileged(AccessController. java:389) at javafx.graphics at 19-internal/com.sun.javafx.tk.Toolkit.runPulse(Toolkit. java:404) at javafx.graphics at 19-internal/com.sun.javafx.tk.Toolkit.firePulse(Toolkit .java:434) at test.javafx.scene.control.TableCellTest.testEditCancelEventAfterModifyI tems(TableCellTest.java:557) References 1. https://github.com/openjdk/jfx/pull/716 From kcr at openjdk.java.net Tue Jan 18 19:43:27 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 18 Jan 2022 19:43:27 GMT Subject: [jfx18] Integrated: 8273998: Clarify specification for Window properties controlled by the window manager In-Reply-To: References: Message-ID: On Fri, 7 Jan 2022 18:19:23 GMT, Kevin Rushforth wrote: > Update the API specification for the `Window` and `Stage` classes to clarify that the values for some properties and methods can be changed or ignored by the platform. Several of the properties already have a comment to the effect that the value can change externally, and thus the properties are not bindable, but this should be clarified further and for all such properties and methods. > > See the Description of the JBS issues for this bug and its associated CSR for more details. This pull request has now been integrated. Changeset: 7a1a19c0 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/7a1a19c098e21572077c9c3d75cc2141fadc99f6 Stats: 84 lines in 2 files changed: 59 ins; 4 del; 21 mod 8273998: Clarify specification for Window properties controlled by the window manager Reviewed-by: jvos, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/708 From kcr at openjdk.java.net Tue Jan 18 20:11:30 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 18 Jan 2022 20:11:30 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v3] In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 17:26:15 GMT, Martin Fox wrote: >> When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. >> >> This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. >> >> System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. > > Martin Fox has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Re-instating fix for Cmd shortcut being handled by two windows @jperedadnr Can you also review this? I see that you filed a related bug, [JDK-8280057](https://bugs.openjdk.java.net/browse/JDK-8280057), which sounds like something we might want to do as a follow-on to this one. ------------- PR: https://git.openjdk.java.net/jfx/pull/715 From kcr at openjdk.java.net Tue Jan 18 20:20:34 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 18 Jan 2022 20:20:34 GMT Subject: Integrated: Merge jfx18 Message-ID: Merge ...Merge `jfx18` into `master`. ------------- Commit messages: - Merge jfx18 - 8244234: MenuButton: NPE on removing from scene with open popup - 8279615: Change JavaFX release version to 19 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jfx/pull/719/files Stats: 136 lines in 5 files changed: 126 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/719.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/719/head:pull/719 PR: https://git.openjdk.java.net/jfx/pull/719 From kcr at openjdk.java.net Tue Jan 18 20:20:34 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 18 Jan 2022 20:20:34 GMT Subject: Integrated: Merge jfx18 In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 20:12:52 GMT, Kevin Rushforth wrote: > Merge ...Merge `jfx18` into `master`. This pull request has now been integrated. Changeset: f01c50d5 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/f01c50d5680ab038fa12774f58b60c33a85156a6 Stats: 88 lines in 3 files changed: 62 ins; 4 del; 22 mod Merge ------------- PR: https://git.openjdk.java.net/jfx/pull/719 From jpereda at openjdk.java.net Tue Jan 18 23:52:32 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 18 Jan 2022 23:52:32 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v3] In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 17:26:15 GMT, Martin Fox wrote: >> When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. >> >> This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. >> >> System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. > > Martin Fox has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Re-instating fix for Cmd shortcut being handled by two windows Fix looks good. Test fails without it, works with it. I've added just a few minor comments about formatting. tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessing.java line 53: > 51: // When a key equivalent closes a window it can be passed > 52: // to the new key window and processed twice. > 53: public class DoubleShortcutProcessing { Rename to `DoubleShortcutProcessingTest`? tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessing.java line 53: > 51: // When a key equivalent closes a window it can be passed > 52: // to the new key window and processed twice. > 53: public class DoubleShortcutProcessing { When I launch the test with: sh gradlew -PUSE_ROBOT=true -PFULL_TEST=true :systemTests:test --tests=test.robot.javafx.scene.DoubleShortcutProcessing I get the system dialog "Accessibility Access (Events)" with the message "'java' would like to control this computer using accessibility features." After adding java to Security&Privacy->accessibility, the test works fine. Maybe this need to be added to the javadoc of the test. tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessing.java line 63: > 61: @Test > 62: void testDoubleShortcut() > 63: { Minor: move the opening curly brace to the line above tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessing.java line 79: > 77: @AfterAll > 78: static void exit() { > 79: Platform.runLater(() -> { It can be simplified with a method reference tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessing.java line 116: > 114: > 115: public void startTest() > 116: { Move curly brace to line above tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessing.java line 133: > 131: > 132: public boolean failed() > 133: { same here ------------- PR: https://git.openjdk.java.net/jfx/pull/715 From duke at openjdk.java.net Wed Jan 19 11:03:54 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Wed, 19 Jan 2022 11:03:54 GMT Subject: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 Message-ID: Release Notes for 17.0.2 ------------- Commit messages: - 8280172: Create release notes for JavaFX 17.0.2 Changes: https://git.openjdk.java.net/jfx17u/pull/28/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=28&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280172 Stats: 33 lines in 1 file changed: 33 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/28.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/28/head:pull/28 PR: https://git.openjdk.java.net/jfx17u/pull/28 From duke at openjdk.java.net Wed Jan 19 11:03:55 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Wed, 19 Jan 2022 11:03:55 GMT Subject: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 10:58:54 GMT, Abhinay Agarwal wrote: > Release Notes for 17.0.2 doc-files/release-notes-17.0.2.md line 18: > 16: | [JDK-8272638](https://bugs.openjdk.java.net/browse/JDK-8272638) | Update copyright header for files modified in 2021 | other | > 17: | [JDK-8274413](https://bugs.openjdk.java.net/browse/JDK-8274413) | FX: Update copyright year in docs, readme files to 2022 | other | > 18: | [JDK-8279396](https://bugs.openjdk.java.net/browse/JDK-8279396) | Define version in .jcheck/conf | other | Hi @kevinrushforth , Can you confirm if issues like this needs to be in the release note. The issue itself is labelled as `noreg-cleanup`, however, the backport issue for openjfx17.0.1 doesn't have any such label. ------------- PR: https://git.openjdk.java.net/jfx17u/pull/28 From duke at openjdk.java.net Wed Jan 19 11:30:10 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Wed, 19 Jan 2022 11:30:10 GMT Subject: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v2] In-Reply-To: References: Message-ID: <7Z5AbtG_v8JRwRgKZiUENENCg9msns3scO4JxPamh0w=.810788f0-2f90-4ab8-90ea-6e1c11dd4b26@github.com> > Release Notes for 17.0.2 Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: Fix formatting ------------- Changes: - all: https://git.openjdk.java.net/jfx17u/pull/28/files - new: https://git.openjdk.java.net/jfx17u/pull/28/files/824c5fcd..267df8a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=28&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=28&range=00-01 Stats: 23 lines in 1 file changed: 0 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jfx17u/pull/28.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/28/head:pull/28 PR: https://git.openjdk.java.net/jfx17u/pull/28 From kcr at openjdk.java.net Wed Jan 19 12:32:33 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Jan 2022 12:32:33 GMT Subject: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v2] In-Reply-To: <7Z5AbtG_v8JRwRgKZiUENENCg9msns3scO4JxPamh0w=.810788f0-2f90-4ab8-90ea-6e1c11dd4b26@github.com> References: <7Z5AbtG_v8JRwRgKZiUENENCg9msns3scO4JxPamh0w=.810788f0-2f90-4ab8-90ea-6e1c11dd4b26@github.com> Message-ID: On Wed, 19 Jan 2022 11:30:10 GMT, Abhinay Agarwal wrote: >> Release Notes for 17.0.2 > > Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting The list of bugs fixed looks correct, with the addition of the following security fix: JDK-8272546 (not public) | Better TrueType font loading | graphics See [release-notes-17.md](https://github.com/openjdk/jfx17u/blob/master/doc-files/release-notes-17.md#list-of-security-fixes) for an example of how we include security fixes. Additionally, one comment left inline below. doc-files/release-notes-17.0.2.md line 17: > 15: [JDK-8272638](https://bugs.openjdk.java.net/browse/JDK-8272638)|Update copyright header for files modified in 2021|other > 16: [JDK-8274413](https://bugs.openjdk.java.net/browse/JDK-8274413)|FX: Update copyright year in docs, readme files to 2022|other > 17: [JDK-8279396](https://bugs.openjdk.java.net/browse/JDK-8279396)|Define version in .jcheck/conf|other We normally exclude `Task`s along with build and test changes from the release notes. ------------- PR: https://git.openjdk.java.net/jfx17u/pull/28 From fastegal at swingempire.de Wed Jan 19 12:42:34 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Wed, 19 Jan 2022 13:42:34 +0100 Subject: Aw: Strange test failures: validation of PGGroup children failed In-Reply-To: References: <20220118154657.Horde.iKWEYuOFVRGBogGLEIItQA8@webmail.df.eu> Message-ID: <20220119134234.Horde.wQ0p4L97QXefwoMeBaCxWQ6@webmail.df.eu> Zitat von Marius Hanl : > I think I had the same issues some days ago. What helped was to delete all > the 'build' or 'target' or 'out' folders - so basically all the folders > with the compiled files. thanks for the suggestion - didn't help, unfortunately wondering what is "javafx.graphics at 19-internal" - doesn't it sound like some mis-configuration somewhere? (in Eclipse it's the same error message, but without the @19-internal). Will simply ignore it for now (working fine if the test is passing and that's what we are after in the end :), nevertheless itching .. > ? ? GESENDET:?Dienstag, 18. Januar 2022 um 15:46 Uhr > VON:?"Jeanette Winzenburg" > AN:?"openjfx-dev" > BETREFF:?Strange test failures: validation of PGGroup children failed > > Just stumbled across it while reviewing PR 719 > (https://github.com/openjdk/jfx/pull/716) > > - added the new test method to see it fail (which it does) > - run all control tests throws the error below in _unrelated_ tests > (the one below is from TableCellTest, that is the same test the new > failing method resides in, but seeing similar in other tests that use > Toolkit.firePulse) > > Still happens after a clean build from gradle (clean, sdk, :controls:test). > > Any idea what might be the reason? > > java.lang.AssertionError: validation of PGGroup children failed > at > javafx.graphics at 19-internal/javafx.scene.Parent.validatePG(Parent.java:243) > at > javafx.graphics at 19-internal/javafx.scene.Parent.doUpdatePeer(Parent.java:201) > at > javafx.graphics at 19-internal/javafx.scene.Parent$1.doUpdatePeer(Parent.java:109) > at > javafx.graphics at 19-internal/com.sun.javafx.scene.ParentHelper.updatePeerImpl(ParentHelper.java:78) > at > javafx.graphics at 19-internal/com.sun.javafx.scene.layout.RegionHelper.updatePeerImpl(RegionHelper.java:72) > at > javafx.graphics at 19-internal/com.sun.javafx.scene.NodeHelper.updatePeer(NodeHelper.java:103) > at javafx.graphics at 19-internal/javafx.scene.Node.syncPeer(Node.java:715) > at > javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.syncAll(Scene.java:2397) > at > javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.syncAll(Scene.java:2406) > at > javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.syncAll(Scene.java:2406) > at > javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.syncAll(Scene.java:2406) > at > javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2373) > at > javafx.graphics at 19-internal/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2529) > at > javafx.graphics at 19-internal/com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:405) > at > java.base/java.security.AccessController.doPrivileged(AccessController.java:389) > at > javafx.graphics at 19-internal/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:404) > at > javafx.graphics at 19-internal/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:434) > at > test.javafx.scene.control.TableCellTest.testEditCancelEventAfterModifyItems(TableCellTest.java:557) > > ? From duke at openjdk.java.net Wed Jan 19 12:51:35 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Wed, 19 Jan 2022 12:51:35 GMT Subject: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v2] In-Reply-To: References: <7Z5AbtG_v8JRwRgKZiUENENCg9msns3scO4JxPamh0w=.810788f0-2f90-4ab8-90ea-6e1c11dd4b26@github.com> Message-ID: On Wed, 19 Jan 2022 12:18:40 GMT, Kevin Rushforth wrote: >> Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix formatting > > doc-files/release-notes-17.0.2.md line 17: > >> 15: [JDK-8272638](https://bugs.openjdk.java.net/browse/JDK-8272638)|Update copyright header for files modified in 2021|other >> 16: [JDK-8274413](https://bugs.openjdk.java.net/browse/JDK-8274413)|FX: Update copyright year in docs, readme files to 2022|other >> 17: [JDK-8279396](https://bugs.openjdk.java.net/browse/JDK-8279396)|Define version in .jcheck/conf|other > > We normally exclude `Task`s along with build and test changes from the release notes. I had added a [comment](https://github.com/openjdk/jfx17u/pull/28#discussion_r787632463), asking about the same. To confirm, if the parent or the backport issue has any [build and test related labels](https://github.com/openjdk/jfx/pull/414#issuecomment-789709510), it should be skipped. Is my understanding correct? ------------- PR: https://git.openjdk.java.net/jfx17u/pull/28 From duke at openjdk.java.net Wed Jan 19 13:06:14 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Wed, 19 Jan 2022 13:06:14 GMT Subject: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v3] In-Reply-To: References: Message-ID: <7k9WWCuHMrPa0RYCtM1S4Yn-TANATNak_4j-t645SI0=.9fab64c4-7e2d-4f30-a2b7-55ea9f909844@github.com> > Release Notes for 17.0.2 Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: Add security fix ------------- Changes: - all: https://git.openjdk.java.net/jfx17u/pull/28/files - new: https://git.openjdk.java.net/jfx17u/pull/28/files/267df8a1..229bcb00 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=28&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=28&range=01-02 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/28.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/28/head:pull/28 PR: https://git.openjdk.java.net/jfx17u/pull/28 From kcr at openjdk.java.net Wed Jan 19 13:19:31 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Jan 2022 13:19:31 GMT Subject: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v2] In-Reply-To: References: <7Z5AbtG_v8JRwRgKZiUENENCg9msns3scO4JxPamh0w=.810788f0-2f90-4ab8-90ea-6e1c11dd4b26@github.com> Message-ID: On Wed, 19 Jan 2022 12:48:32 GMT, Abhinay Agarwal wrote: >> doc-files/release-notes-17.0.2.md line 17: >> >>> 15: [JDK-8272638](https://bugs.openjdk.java.net/browse/JDK-8272638)|Update copyright header for files modified in 2021|other >>> 16: [JDK-8274413](https://bugs.openjdk.java.net/browse/JDK-8274413)|FX: Update copyright year in docs, readme files to 2022|other >>> 17: [JDK-8279396](https://bugs.openjdk.java.net/browse/JDK-8279396)|Define version in .jcheck/conf|other >> >> We normally exclude `Task`s along with build and test changes from the release notes. > > I had added a [comment](https://github.com/openjdk/jfx17u/pull/28#discussion_r787632463), asking about the same. To confirm, if the parent or the backport issue has any [build and test related labels](https://github.com/openjdk/jfx/pull/414#issuecomment-789709510), it should be skipped. Is my understanding correct? I don't see a comment asking about it, but yes, your understanding is correct. The release notes should include bugs and enhancements (or backports of same) without build, test, or cleanup labels. ------------- PR: https://git.openjdk.java.net/jfx17u/pull/28 From kcr at openjdk.java.net Wed Jan 19 13:46:35 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Jan 2022 13:46:35 GMT Subject: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v3] In-Reply-To: <7k9WWCuHMrPa0RYCtM1S4Yn-TANATNak_4j-t645SI0=.9fab64c4-7e2d-4f30-a2b7-55ea9f909844@github.com> References: <7k9WWCuHMrPa0RYCtM1S4Yn-TANATNak_4j-t645SI0=.9fab64c4-7e2d-4f30-a2b7-55ea9f909844@github.com> Message-ID: On Wed, 19 Jan 2022 13:06:14 GMT, Abhinay Agarwal wrote: >> Release Notes for 17.0.2 > > Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: > > Add security fix The latest addition looks good. Per the above discussion, you should remove the "List of Task" section. ------------- PR: https://git.openjdk.java.net/jfx17u/pull/28 From duke at openjdk.java.net Wed Jan 19 14:16:14 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Wed, 19 Jan 2022 14:16:14 GMT Subject: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v4] In-Reply-To: References: Message-ID: > Release Notes for 17.0.2 Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: Remove build and test changes ------------- Changes: - all: https://git.openjdk.java.net/jfx17u/pull/28/files - new: https://git.openjdk.java.net/jfx17u/pull/28/files/229bcb00..45b41200 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=28&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=28&range=02-03 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/28.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/28/head:pull/28 PR: https://git.openjdk.java.net/jfx17u/pull/28 From kcr at openjdk.java.net Wed Jan 19 14:31:48 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Jan 2022 14:31:48 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v3] In-Reply-To: References: Message-ID: <6DOjPa8oc4lu1Dk16J-X1S23SV_wJGk921KVeQwfrAo=.c6e499ba-9eab-4291-8de0-530c817e8682@github.com> On Tue, 18 Jan 2022 17:26:15 GMT, Martin Fox wrote: >> When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. >> >> This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. >> >> System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. > > Martin Fox has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Re-instating fix for Cmd shortcut being handled by two windows The fix looks good to me. It looks like we have a build dependency problem with the new JUnit5 Assumptions API. I get the following compilation error on my system when trying to run the system tests: gradle --info -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests DoubleShortcutProcessing ... > Task :systemTests:compileTestJava tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessing.java:64: error: cannot access TestAbortedException Assumptions.assumeTrue(PlatformUtil.isMac()); ^ class file for org.opentest4j.TestAbortedException not found The following fixes it, although the fact that this is needed at test compilation time seems like an unfortunate choice on the part of JUnit. --- a/build.gradle +++ b/build.gradle @@ -1969,7 +1969,7 @@ allprojects { testRuntimeOnly group: "org.junit.platform", name: "junit-platform-commons", version: "1.8.1" testRuntimeOnly group: "org.junit.platform", name: "junit-platform-engine", version: "1.8.1" testRuntimeOnly group: "org.junit.vintage", name: "junit-vintage-engine", version: "5.8.1" - testRuntimeOnly group: "org.opentest4j", name: "opentest4j", version: "1.2.0" + testImplementation group: "org.opentest4j", name: "opentest4j", version: "1.2.0" It seems odd that this doesn't fail in the GitHub action run, since it fails for me even running `gradle test` (the systemTests project is compiled, but not executed, even when `FULL_TEST` is not set to true). I'd prefer this dependency issue to be fixed by a separate bug, which I will file today. ------------- PR: https://git.openjdk.java.net/jfx/pull/715 From kcr at openjdk.java.net Wed Jan 19 14:38:34 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Jan 2022 14:38:34 GMT Subject: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v4] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 14:16:14 GMT, Abhinay Agarwal wrote: >> Release Notes for 17.0.2 > > Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: > > Remove build and test changes Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx17u/pull/28 From kcr at openjdk.java.net Wed Jan 19 14:48:34 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Jan 2022 14:48:34 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v3] In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 17:26:15 GMT, Martin Fox wrote: >> When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. >> >> This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. >> >> System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. > > Martin Fox has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Re-instating fix for Cmd shortcut being handled by two windows I filed [JDK-8280275](https://bugs.openjdk.java.net/browse/JDK-8280275) to track the test failure. I'll submit a PR against jfx18 shortly. ------------- PR: https://git.openjdk.java.net/jfx/pull/715 From kcr at openjdk.java.net Wed Jan 19 15:25:05 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Jan 2022 15:25:05 GMT Subject: [jfx18] RFR: 8280275: JUnit5 tests using Assumptions API fail to compile in some cases Message-ID: Fixed a test dependency issue in `build.gradle` that causes a compilation failure when running `gradle test` if the `Assumptions` API from JUnit5 is used. I added a test that fails to compile without the build fix and passes with the fix. This was first discovered when testing the patch for PR #715, which fails to compile on my local macOS system. After applying this fix, I can compile and run the test from that PR. ------------- Commit messages: - 8280275: JUnit5 tests using Assumptions API fail to compile in some cases Changes: https://git.openjdk.java.net/jfx/pull/720/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=720&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280275 Stats: 6 lines in 2 files changed: 4 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/720.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/720/head:pull/720 PR: https://git.openjdk.java.net/jfx/pull/720 From duke at openjdk.java.net Wed Jan 19 16:25:17 2022 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 19 Jan 2022 16:25:17 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v4] In-Reply-To: References: Message-ID: > When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. > > This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. > > System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Renamed test to match existing conventions along with minor cleanup. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/715/files - new: https://git.openjdk.java.net/jfx/pull/715/files/edebba96..4962a1fb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=715&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=715&range=02-03 Stats: 10 lines in 1 file changed: 0 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/715.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/715/head:pull/715 PR: https://git.openjdk.java.net/jfx/pull/715 From duke at openjdk.java.net Wed Jan 19 16:42:31 2022 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 19 Jan 2022 16:42:31 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v3] In-Reply-To: References: Message-ID: <7yFfdiDveWQlysXZGAJoGkIch5XU2CJ8wUy-S6QLbmc=.0c15ccca-8547-4f5f-9ace-79f3ea23a2e2@github.com> On Tue, 18 Jan 2022 23:35:43 GMT, Jose Pereda wrote: >> Martin Fox has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> Re-instating fix for Cmd shortcut being handled by two windows > > tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessing.java line 53: > >> 51: // When a key equivalent closes a window it can be passed >> 52: // to the new key window and processed twice. >> 53: public class DoubleShortcutProcessing { > > When I launch the test with: > > sh gradlew -PUSE_ROBOT=true -PFULL_TEST=true :systemTests:test --tests=test.robot.javafx.scene.DoubleShortcutProcessing > > I get the system dialog "Accessibility Access (Events)" with the message "'java' would like to control this computer using accessibility features." > > After adding java to Security&Privacy->accessibility, the test works fine. > > Maybe this need to be added to the javadoc of the test. I wouldn't know what to write. On my system adding 'java' doesn't fix the problem, the OS insists I have to add 'Terminal'. In general it's easier to bump into this dialog and then go to System Preferences since the OS will have added the executable to the list which is convenient for a file like /usr/bin/java that's normally hidden. ------------- PR: https://git.openjdk.java.net/jfx/pull/715 From kcr at openjdk.java.net Wed Jan 19 16:49:36 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Jan 2022 16:49:36 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v3] In-Reply-To: <7yFfdiDveWQlysXZGAJoGkIch5XU2CJ8wUy-S6QLbmc=.0c15ccca-8547-4f5f-9ace-79f3ea23a2e2@github.com> References: <7yFfdiDveWQlysXZGAJoGkIch5XU2CJ8wUy-S6QLbmc=.0c15ccca-8547-4f5f-9ace-79f3ea23a2e2@github.com> Message-ID: On Wed, 19 Jan 2022 16:38:58 GMT, Martin Fox wrote: >> tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessing.java line 53: >> >>> 51: // When a key equivalent closes a window it can be passed >>> 52: // to the new key window and processed twice. >>> 53: public class DoubleShortcutProcessing { >> >> When I launch the test with: >> >> sh gradlew -PUSE_ROBOT=true -PFULL_TEST=true :systemTests:test --tests=test.robot.javafx.scene.DoubleShortcutProcessing >> >> I get the system dialog "Accessibility Access (Events)" with the message "'java' would like to control this computer using accessibility features." >> >> After adding java to Security&Privacy->accessibility, the test works fine. >> >> Maybe this need to be added to the javadoc of the test. > > I wouldn't know what to write. On my system adding 'java' doesn't fix the problem, the OS insists I have to add 'Terminal'. In general it's easier to bump into this dialog and then go to System Preferences since the OS will have added the executable to the list which is convenient for a file like /usr/bin/java that's normally hidden. This requirement is independent of this fix and applies to all robot tests. I do not think any additional documentation is needed here. ------------- PR: https://git.openjdk.java.net/jfx/pull/715 From kcr at openjdk.java.net Wed Jan 19 17:18:32 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Jan 2022 17:18:32 GMT Subject: [jfx18] RFR: 8280275: JUnit5 tests using Assumptions API fail to compile in some cases In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 15:18:48 GMT, Kevin Rushforth wrote: > Fixed a test dependency issue in `build.gradle` that causes a compilation failure when running `gradle test` if the `Assumptions` API from JUnit5 is used. I added a test that fails to compile without the build fix and passes with the fix. > > This was first discovered when testing the patch for PR #715, which fails to compile on my local macOS system. After applying this fix, I can compile and run the test from that PR. NOTE: this test fix is targeted to `jfx18`. ------------- PR: https://git.openjdk.java.net/jfx/pull/720 From jpereda at openjdk.java.net Wed Jan 19 17:29:32 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 19 Jan 2022 17:29:32 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v4] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 16:25:17 GMT, Martin Fox wrote: >> When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. >> >> This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. >> >> System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Renamed test to match existing conventions along with minor cleanup. Looks good ------------- Marked as reviewed by jpereda (Committer). PR: https://git.openjdk.java.net/jfx/pull/715 From steve at weblite.ca Wed Jan 19 17:40:55 2022 From: steve at weblite.ca (Steve Hannah) Date: Wed, 19 Jan 2022 09:40:55 -0800 Subject: JavaFX Launch Failure on Ubuntu from JNI Message-ID: The following issue only seems to occur on Linux (Ubuntu 20.04.1), and only when I try to launch the JVM from a custom C launcher using JNI. It does not occur when launching the JVM as a separate process using the "java" binary. It also does not occur on MacOS when using the same C launcher using JNI. When I call MyApplication.launch(args). (where MyApplication extends the JavaFX Application class), I get the following stack trace: Jan. 19, 2022 8:54:27 A.M. com.sun.javafx.application.PlatformImpl startup Exception in thread "Thread-5" java.lang.IllegalStateException: This operation is permitted on the event thread only; currentThread = Thread-5 at com.sun.glass.ui.Application.checkEventThread(Application.java:447) at com.sun.glass.ui.Application.setName(Application.java:200) at com.sun.javafx.application.PlatformImpl.lambda$setApplicationName$2(PlatformImpl.java:142) at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) at java.base/java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) Exception in Application start method Exception in thread "Thread-31" Failed to show docs java.lang.IllegalStateException: Not on FX application thread; currentThread = Thread-31 at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) at com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:828) at com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:624) at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) at java.base/java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) java.lang.RuntimeException: Exception in Application start method at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196) at java.base/java.lang.Thread.run(Thread.java:829) Caused by: java.lang.IllegalStateException: Not on FX application thread; currentThread = Thread-6 at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) at javafx.stage.Stage.(Stage.java:254) at javafx.stage.Stage.(Stage.java:240) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:845) at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) at java.base/java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) I have tried a few different versions of JavaFX (11, 11.0.2, 17.0.1), running on a few different JDK installs (all JDK11). Above stacktrace is from 17.0.1. >From the C application that launches the JVM, I have tried running directly on the main thread, and also launching it in a fresh thread using pthreads - but same issue. I am running this inside an application written in Go but the JNI code is all in C. It appears as though JavaFX is unable to create its application thread for some reason. Does anyone have any suggestions on reasons why this would be the case? Are there some system properties that need to be there which would have been bootstrapped by the "java" binary, but would not when the JVM is launched via JNI? Any suggestions appreciated. I've been banging my head on this for a while now. Best regards Steve From kevin.rushforth at oracle.com Wed Jan 19 18:35:23 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Jan 2022 10:35:23 -0800 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: References: Message-ID: <16d55f27-dc25-c47d-cb84-b0635e4d3f1e@oracle.com> Hard to say what's going on without more information. What are the JVM args you use for launching? Are the JavaFX modules jlink'ed into the JDK or loaded via --module-path? As a debugging aid, you might try setting the system property "javafx.verbose" to "true" before loading your MyApplication class. -- Kevin On 1/19/2022 9:40 AM, Steve Hannah wrote: > The following issue only seems to occur on Linux (Ubuntu 20.04.1), and only > when I try to launch the JVM from a custom C launcher using JNI. It does > not occur when launching the JVM as a separate process using the "java" > binary. It also does not occur on MacOS when using the same C launcher > using JNI. > > When I call MyApplication.launch(args). (where MyApplication extends the > JavaFX Application class), I get the following stack trace: > > Jan. 19, 2022 8:54:27 A.M. com.sun.javafx.application.PlatformImpl startup > Exception in thread "Thread-5" java.lang.IllegalStateException: This > operation is permitted on the event thread only; currentThread = > Thread-5 > at com.sun.glass.ui.Application.checkEventThread(Application.java:447) > at com.sun.glass.ui.Application.setName(Application.java:200) > at com.sun.javafx.application.PlatformImpl.lambda$setApplicationName$2(PlatformImpl.java:142) > at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > Exception in Application start method > Exception in thread "Thread-31" Failed to show docs > java.lang.IllegalStateException: Not on FX application thread; > currentThread = Thread-31 > at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) > at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) > at com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:828) > at com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:624) > at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) > at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > java.lang.RuntimeException: Exception in Application start method > at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901) > at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196) > at java.base/java.lang.Thread.run(Thread.java:829) > Caused by: java.lang.IllegalStateException: Not on FX application > thread; currentThread = Thread-6 > at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) > at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) > at javafx.stage.Stage.(Stage.java:254) > at javafx.stage.Stage.(Stage.java:240) > at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:845) > at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) > at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > > I have tried a few different versions of JavaFX (11, 11.0.2, 17.0.1), > running on a few different JDK installs (all JDK11). Above stacktrace is > from 17.0.1. > > From the C application that launches the JVM, I have tried running directly > on the main thread, and also launching it in a fresh thread using pthreads > - but same issue. I am running this inside an application written in Go > but the JNI code is all in C. > > It appears as though JavaFX is unable to create its application thread for > some reason. Does anyone have any suggestions on reasons why this would be > the case? Are there some system properties that need to be there which > would have been bootstrapped by the "java" binary, but would not when the > JVM is launched via JNI? > > Any suggestions appreciated. I've been banging my head on this for a while > now. > > Best regards > > Steve From steve at weblite.ca Wed Jan 19 18:42:13 2022 From: steve at weblite.ca (Steve Hannah) Date: Wed, 19 Jan 2022 10:42:13 -0800 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: <16d55f27-dc25-c47d-cb84-b0635e4d3f1e@oracle.com> References: <16d55f27-dc25-c47d-cb84-b0635e4d3f1e@oracle.com> Message-ID: Thanks for the reply. > What are the JVM args you use for launching? vm_args.version = JNI_VERSION_1_6; vm_args.options = options; vm_args.nOptions = numOptions; vm_args.ignoreUnrecognized = 1; For options, I'm just using -Djava.class.path, though I have experimented using -Djavafx.verbose=true, which doesn't tell me much more. It just logs warnings when it can't find the javafx nativelibs, in the JDK libs directory - and reports that they are loaded from resource. > Are the JavaFX modules jlink'ed into the JDK or loaded via --module-path? They are included in the classpath. I'm not using modules. Best regards Steve On Wed, Jan 19, 2022 at 10:35 AM Kevin Rushforth wrote: > Hard to say what's going on without more information. What are the JVM > args you use for launching? Are the JavaFX modules jlink'ed into the JDK > or loaded via --module-path? As a debugging aid, you might try setting > the system property "javafx.verbose" to "true" before loading your > MyApplication class. > > -- Kevin > > > On 1/19/2022 9:40 AM, Steve Hannah wrote: > > The following issue only seems to occur on Linux (Ubuntu 20.04.1), and > only > > when I try to launch the JVM from a custom C launcher using JNI. It does > > not occur when launching the JVM as a separate process using the "java" > > binary. It also does not occur on MacOS when using the same C launcher > > using JNI. > > > > When I call MyApplication.launch(args). (where MyApplication extends the > > JavaFX Application class), I get the following stack trace: > > > > Jan. 19, 2022 8:54:27 A.M. com.sun.javafx.application.PlatformImpl > startup > > Exception in thread "Thread-5" java.lang.IllegalStateException: This > > operation is permitted on the event thread only; currentThread = > > Thread-5 > > at > com.sun.glass.ui.Application.checkEventThread(Application.java:447) > > at com.sun.glass.ui.Application.setName(Application.java:200) > > at > com.sun.javafx.application.PlatformImpl.lambda$setApplicationName$2(PlatformImpl.java:142) > > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > > at java.base/java.security.AccessController.doPrivileged(Native > Method) > > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > > at > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > Exception in Application start method > > Exception in thread "Thread-31" Failed to show docs > > java.lang.IllegalStateException: Not on FX application thread; > > currentThread = Thread-31 > > at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) > > at > com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) > > at > com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:828) > > at > com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:624) > > at > com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) > > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > > at java.base/java.security.AccessController.doPrivileged(Native > Method) > > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > > at > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > java.lang.RuntimeException: Exception in Application start method > > at > com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901) > > at > com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196) > > at java.base/java.lang.Thread.run(Thread.java:829) > > Caused by: java.lang.IllegalStateException: Not on FX application > > thread; currentThread = Thread-6 > > at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) > > at > com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) > > at javafx.stage.Stage.(Stage.java:254) > > at javafx.stage.Stage.(Stage.java:240) > > at > com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:845) > > at > com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) > > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > > at java.base/java.security.AccessController.doPrivileged(Native > Method) > > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > > at > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > > > > > I have tried a few different versions of JavaFX (11, 11.0.2, 17.0.1), > > running on a few different JDK installs (all JDK11). Above stacktrace is > > from 17.0.1. > > > > From the C application that launches the JVM, I have tried running > directly > > on the main thread, and also launching it in a fresh thread using > pthreads > > - but same issue. I am running this inside an application written in Go > > but the JNI code is all in C. > > > > It appears as though JavaFX is unable to create its application thread > for > > some reason. Does anyone have any suggestions on reasons why this would > be > > the case? Are there some system properties that need to be there which > > would have been bootstrapped by the "java" binary, but would not when the > > JVM is launched via JNI? > > > > Any suggestions appreciated. I've been banging my head on this for a > while > > now. > > > > Best regards > > > > Steve > > -- Steve Hannah Web Lite Solutions Corp. From duke at openjdk.java.net Wed Jan 19 18:56:54 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Wed, 19 Jan 2022 18:56:54 GMT Subject: [jfx17u] Integrated: 8280172: Create release notes for JavaFX 17.0.2 In-Reply-To: References: Message-ID: <9oR0Y9PT4haa6jPihDIGWhWdMFLC_NEZ8NFsO4haxAo=.080e6b12-89ff-44f3-8132-b2a9f91f34cf@github.com> On Wed, 19 Jan 2022 10:58:54 GMT, Abhinay Agarwal wrote: > Release Notes for 17.0.2 This pull request has now been integrated. Changeset: 3aa459eb Author: Abhinay Agarwal Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/3aa459ebda3ffeccd5349a026e843d4489121ecd Stats: 29 lines in 1 file changed: 29 ins; 0 del; 0 mod 8280172: Create release notes for JavaFX 17.0.2 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx17u/pull/28 From kevin.rushforth at oracle.com Wed Jan 19 19:01:46 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Jan 2022 11:01:46 -0800 Subject: [External] : Re: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: References: <16d55f27-dc25-c47d-cb84-b0635e4d3f1e@oracle.com> Message-ID: Very odd. If you can create a simple, standalone test case, ideally a single, self-contained JavaFX application and a C main program as a launcher, then you might want to file a bug at https://bugreport.java.com/ -- Kevin On 1/19/2022 10:42 AM, Steve Hannah wrote: > Thanks for the reply. > > >? What are the JVM args you use for launching? > > vm_args.version = JNI_VERSION_1_6; > ? vm_args.options = options; > ? vm_args.nOptions = numOptions; > ? vm_args.ignoreUnrecognized = 1; > > For options, I'm just using -Djava.class.path, though I have > experimented using -Djavafx.verbose=true, which doesn't tell me much > more.? It just logs warnings when it can't find the javafx nativelibs, > in the JDK libs directory - and reports that they are loaded from > resource. > > >? Are the JavaFX modules jlink'ed into the JDK or loaded via > --module-path? > > They are included in the classpath.? I'm not using modules. > > Best regards > > Steve > > On Wed, Jan 19, 2022 at 10:35 AM Kevin Rushforth > wrote: > > Hard to say what's going on without more information. What are the > JVM > args you use for launching? Are the JavaFX modules jlink'ed into > the JDK > or loaded via --module-path? As a debugging aid, you might try > setting > the system property "javafx.verbose" to "true" before loading your > MyApplication class. > > -- Kevin > > > On 1/19/2022 9:40 AM, Steve Hannah wrote: > > The following issue only seems to occur on Linux (Ubuntu > 20.04.1), and only > > when I try to launch the JVM from a custom C launcher using > JNI.? It does > > not occur when launching the JVM as a separate process using the > "java" > > binary.? It also does not occur on MacOS when using the same C > launcher > > using JNI. > > > > When I call MyApplication.launch(args). (where MyApplication > extends the > > JavaFX Application class), I get the following stack trace: > > > > Jan. 19, 2022 8:54:27 A.M. > com.sun.javafx.application.PlatformImpl startup > > Exception in thread "Thread-5" java.lang.IllegalStateException: This > > operation is permitted on the event thread only; currentThread = > > Thread-5 > >? ? ? ? ? at > com.sun.glass.ui.Application.checkEventThread(Application.java:447) > >? ? ? ? ? at > com.sun.glass.ui.Application.setName(Application.java:200) > >? ? ? ? ? at > com.sun.javafx.application.PlatformImpl.lambda$setApplicationName$2(PlatformImpl.java:142) > >? ? ? ? ? at > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > >? ? ? ? ? at > java.base/java.security.AccessController.doPrivileged(Native Method) > >? ? ? ? ? at > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > >? ? ? ? ? at > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > Exception in Application start method > > Exception in thread "Thread-31" Failed to show docs > > java.lang.IllegalStateException: Not on FX application thread; > > currentThread = Thread-31 > >? ? ? ? ? at > com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) > >? ? ? ? ? at > com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) > >? ? ? ? ? at > com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:828) > >? ? ? ? ? at > com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:624) > >? ? ? ? ? at > com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) > >? ? ? ? ? at > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > >? ? ? ? ? at > java.base/java.security.AccessController.doPrivileged(Native Method) > >? ? ? ? ? at > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > >? ? ? ? ? at > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > java.lang.RuntimeException: Exception in Application start method > >? ? ? ? ? at > com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901) > >? ? ? ? ? at > com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196) > >? ? ? ? ? at java.base/java.lang.Thread.run(Thread.java:829) > > Caused by: java.lang.IllegalStateException: Not on FX application > > thread; currentThread = Thread-6 > >? ? ? ? ? at > com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) > >? ? ? ? ? at > com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) > >? ? ? ? ? at javafx.stage.Stage.(Stage.java:254) > >? ? ? ? ? at javafx.stage.Stage.(Stage.java:240) > >? ? ? ? ? at > com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:845) > >? ? ? ? ? at > com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) > >? ? ? ? ? at > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > >? ? ? ? ? at > java.base/java.security.AccessController.doPrivileged(Native Method) > >? ? ? ? ? at > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > >? ? ? ? ? at > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > > > > > I have tried a few different versions of JavaFX (11, 11.0.2, > 17.0.1), > > running on a few different JDK installs (all JDK11). Above > stacktrace is > > from 17.0.1. > > > >? From the C application that launches the JVM, I have tried > running directly > > on the main thread, and also launching it in a fresh thread > using pthreads > > - but same issue.? I am running this inside an application > written in Go > > but the JNI code is all in C. > > > > It appears as though JavaFX is unable to create its application > thread for > > some reason.? Does anyone have any suggestions on reasons why > this would be > > the case?? Are there some system properties that need to be > there which > > would have been bootstrapped by the "java" binary, but would not > when the > > JVM is launched via JNI? > > > > Any suggestions appreciated.? I've been banging my head on this > for a while > > now. > > > > Best regards > > > > Steve > > > > -- > Steve Hannah > Web Lite Solutions Corp. From kcr at openjdk.java.net Wed Jan 19 19:17:33 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Jan 2022 19:17:33 GMT Subject: [jfx18] RFR: 8280280: Update boot JDK to 17.0.2 Message-ID: <0kGa7SQdsmEK2nui5ZmZ55XGLJM9t-kAv5Axg1Xrwes=.f7123d56-d29e-4505-aa27-ae56c9e45c46@github.com> JDK 17.0.2 shipped yesterday as part of the January CPU release. We should update the JavaFX 18 build to use that version, so this is targeted for `jfx18`. ------------- Commit messages: - 8280280: Update boot JDK to 17.0.2 Changes: https://git.openjdk.java.net/jfx/pull/721/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=721&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280280 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/721.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/721/head:pull/721 PR: https://git.openjdk.java.net/jfx/pull/721 From kcr at openjdk.java.net Wed Jan 19 19:17:34 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Jan 2022 19:17:34 GMT Subject: [jfx18] RFR: 8280280: Update boot JDK to 17.0.2 In-Reply-To: <0kGa7SQdsmEK2nui5ZmZ55XGLJM9t-kAv5Axg1Xrwes=.f7123d56-d29e-4505-aa27-ae56c9e45c46@github.com> References: <0kGa7SQdsmEK2nui5ZmZ55XGLJM9t-kAv5Axg1Xrwes=.f7123d56-d29e-4505-aa27-ae56c9e45c46@github.com> Message-ID: On Wed, 19 Jan 2022 18:43:31 GMT, Kevin Rushforth wrote: > JDK 17.0.2 shipped yesterday as part of the January CPU release. We should update the JavaFX 18 build to use that version, so this is targeted for `jfx18`. I'd like two reviewers given that we are in ramp-down for JavaFX 18. ------------- PR: https://git.openjdk.java.net/jfx/pull/721 From kcr at openjdk.java.net Wed Jan 19 19:23:59 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Jan 2022 19:23:59 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v4] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 16:25:17 GMT, Martin Fox wrote: >> When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. >> >> This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. >> >> System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Renamed test to match existing conventions along with minor cleanup. The fix and test both look good, with one requested code style change. I can confirm that the test fails without the fix and passes with the fix. Also, In order to avoid problems with our CI and nightly build, I want #720 to be integrated before this PR. tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessingTest.java line 25: > 23: * questions. > 24: */ > 25: package test.robot.javafx.scene; Very minor: we usually add a blank line between the copyright header block and the `package` statement. I only mention it because I have another change to request. tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessingTest.java line 67: > 65: waitForLatch(dialogLatch, 5, "Dialog never received shortcut"); > 66: if (testApp.failed()) > 67: Assertions.fail("performKeyEquivalent was handled twice in separate windows"); Please add curly braces around the target of the `if` statement. The only exception to this rule for Java code is where the statement is short enough to be on the same line as the `if`. ------------- PR: https://git.openjdk.java.net/jfx/pull/715 From duke at openjdk.java.net Wed Jan 19 19:43:38 2022 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 19 Jan 2022 19:43:38 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v5] In-Reply-To: References: Message-ID: <0zNj5dADRh9nQulBX5wwpn4yOv0fW3qASFK7yXEKHss=.cae1d4bf-a796-47f4-ae59-e0da5c82f435@github.com> > When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. > > This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. > > System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: More coding standard tweaks ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/715/files - new: https://git.openjdk.java.net/jfx/pull/715/files/4962a1fb..182bad4b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=715&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=715&range=03-04 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/715.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/715/head:pull/715 PR: https://git.openjdk.java.net/jfx/pull/715 From mik3hall at gmail.com Wed Jan 19 19:49:45 2022 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 19 Jan 2022 13:49:45 -0600 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: References: Message-ID: > On Jan 19, 2022, at 11:40 AM, Steve Hannah wrote: > > com.sun.javafx.application.PlatformImpl startup > Exception in thread "Thread-5" java.lang.IllegalStateException: This > operation is permitted on the event thread only; currentThread = > Thread-5 Searching on? com.sun.javafx.application.PlatformImpl startup Exception in java.lang.IllegalStateException: This operation is permitted on the event thread only; Gets some hits. Somewhat interestingly given? > They are included in the classpath. I'm not using modules. This one https://stackoverflow.com/questions/67854139/javafx-warning-unsupported-javafx-configuration-classes-were-loaded-from-unna Says? The Warning JavaFX only supports being loaded as named modules. In other words, JavaFX only supports being loaded from the module-path, not the class-path. With? > java.lang.IllegalStateException: Not on FX application thread; > currentThread = Thread-31 > at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) Searching only on checkFxUserThread gets a number of similar sounding issues. Mostly they seem to suggest timing issues or taking various steps to ensure you are on the correct thread. e.g. https://stackoverflow.com/questions/29449297/java-lang-illegalstateexception-not-on-fx-application-thread-currentthread-t https://github.com/sarxos/webcam-capture/issues/469 From mblaesing at doppel-helix.eu Wed Jan 19 20:13:20 2022 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Wed, 19 Jan 2022 21:13:20 +0100 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: References: Message-ID: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> Hi, Am Mittwoch, dem 19.01.2022 um 13:49 -0600 schrieb Michael Hall: > > > They are included in the classpath. I'm not using modules. > > This one https://stackoverflow.com/questions/67854139/javafx-warning-unsupported-javafx-configuration-classes-were-loaded-from-unna > Says? > > The Warning > > JavaFX only supports being loaded as named modules. In other words, JavaFX only supports being loaded from the module-path, not the class-path. > Unsupported != does not work! At this point in time Apache NetBeans loads JavaFX from classpath and it works. And before people throw fire at me, doing this revealed at least two implementation issues, that would have bitten anyone running JavaFX with a semi-complex module setup, but the classpath case is just so much more realistic for an applicatin, that tries to work on JDK 8-17. Greetings Matthias From kevin.rushforth at oracle.com Wed Jan 19 20:42:59 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Jan 2022 12:42:59 -0800 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> References: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> Message-ID: FWIW,? in a draft of my earlier reply, I had written a comment pointing out that JavaFX is only supported with modules. I didn't include it, because I think it very unlikely that that's related to the problem. I think a simple reproducer will be most helpful in tracking this down. -- Kevin On 1/19/2022 12:13 PM, Matthias Bl?sing wrote: > Hi, > > Am Mittwoch, dem 19.01.2022 um 13:49 -0600 schrieb Michael Hall: >>> They are included in the classpath. I'm not using modules. >> This one https://stackoverflow.com/questions/67854139/javafx-warning-unsupported-javafx-configuration-classes-were-loaded-from-unna >> Says? >> >> The Warning >> >> JavaFX only supports being loaded as named modules. In other words, JavaFX only supports being loaded from the module-path, not the class-path. >> > Unsupported != does not work! > > At this point in time Apache NetBeans loads JavaFX from classpath and > it works. > > And before people throw fire at me, doing this revealed at least two > implementation issues, that would have bitten anyone running JavaFX > with a semi-complex module setup, but the classpath case is just so > much more realistic for an applicatin, that tries to work on JDK 8-17. > > Greetings > > Matthias > > From mik3hall at gmail.com Wed Jan 19 21:46:33 2022 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 19 Jan 2022 15:46:33 -0600 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> References: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> Message-ID: > On Jan 19, 2022, at 2:13 PM, Matthias Bl?sing wrote: > > Unsupported != does not work! But it might mean less tested. So you might have to worry about things like it works here but does it work on Linux? It works with version x but does it work with y? > At this point in time Apache NetBeans loads JavaFX from classpath and > it works. Probably means it?s pretty thoroughly tested though. > FWIW, in a draft of my earlier reply, I had written a comment pointing out that JavaFX is only supported with modules. I didn't include it, because I think it very unlikely that that's related to the problem. > > I think a simple reproducer will be most helpful in tracking this down. > > ? Kevin It probably isn?t the cause but since the OP indicated he was looking for suggestions, and not necessarily a bug fix at this point, I thought it might be worth a mention. If he wasn?t aware of this he might want to consider it on future updates. From kevin.rushforth at oracle.com Wed Jan 19 21:49:16 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Jan 2022 13:49:16 -0800 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: References: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> Message-ID: On 1/19/2022 1:46 PM, Michael Hall wrote: > >> On Jan 19, 2022, at 2:13 PM, Matthias Bl?sing wrote: >> >> Unsupported != does not work! > But it might mean less tested. So you might have to worry about things like it works here but does it work on Linux? It works with version x but does it work with y? > >> At this point in time Apache NetBeans loads JavaFX from classpath and >> it works. > Probably means it?s pretty thoroughly tested though. > >> FWIW, in a draft of my earlier reply, I had written a comment pointing out that JavaFX is only supported with modules. I didn't include it, because I think it very unlikely that that's related to the problem. >> >> I think a simple reproducer will be most helpful in tracking this down. >> >> ? Kevin > It probably isn?t the cause but since the OP indicated he was looking for suggestions, and not necessarily a bug fix at this point, I thought it might be worth a mention. If he wasn?t aware of this he might want to consider it on future updates. Yes, it was worth a mention, and might even be something he could test locally to see if it makes a difference. -- Kevin From steve at weblite.ca Wed Jan 19 22:12:27 2022 From: steve at weblite.ca (Steve Hannah) Date: Wed, 19 Jan 2022 14:12:27 -0800 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: References: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> Message-ID: Thanks for all the replies on this. I'm working on getting a minimal example. Sadly I'm reduced to a hello-world JavaFX application that I can't get running using Maven dependencies, even just doing it the plain old way with "java -jar target/hello-world-1.0-SNAPSHOT.jar". I get: "Error: JavaFX runtime components are missing, and are required to run this application", even though all the jars should be findable on the classpath via the executable jar's Class-Path entry. I have been resisting using modules for a long time because it just makes things more complicated, but I'm getting the feeling (both from replies on this thread, and from the quirks I'm hitting here) that I'll need to use modules if I want to use JavaFX. Currently the hello world project is just a plain maven project where I add the javafx dependencies (i.e. I'm not using the javafx archetype). This works in my real projects, but not in the hello-world - perhaps because the hello world project extends Application in its main class, and the real-world project does not. I'll have to dissect the javafx archetype to see what kind of magic sauce it adds over and above just the dependencies. Steve On Wed, Jan 19, 2022 at 1:49 PM Kevin Rushforth wrote: > > > On 1/19/2022 1:46 PM, Michael Hall wrote: > > > >> On Jan 19, 2022, at 2:13 PM, Matthias Bl?sing < > mblaesing at doppel-helix.eu> wrote: > >> > >> Unsupported != does not work! > > But it might mean less tested. So you might have to worry about things > like it works here but does it work on Linux? It works with version x but > does it work with y? > > > >> At this point in time Apache NetBeans loads JavaFX from classpath and > >> it works. > > Probably means it?s pretty thoroughly tested though. > > > >> FWIW, in a draft of my earlier reply, I had written a comment pointing > out that JavaFX is only supported with modules. I didn't include it, > because I think it very unlikely that that's related to the problem. > >> > >> I think a simple reproducer will be most helpful in tracking this down. > >> > >> ? Kevin > > It probably isn?t the cause but since the OP indicated he was looking > for suggestions, and not necessarily a bug fix at this point, I thought it > might be worth a mention. If he wasn?t aware of this he might want to > consider it on future updates. > > Yes, it was worth a mention, and might even be something he could test > locally to see if it makes a difference. > > -- Kevin > > -- Steve Hannah Web Lite Solutions Corp. From john at status6.com Wed Jan 19 23:06:05 2022 From: john at status6.com (John Neffenger) Date: Wed, 19 Jan 2022 15:06:05 -0800 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: References: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> Message-ID: <49c84da5-9590-74cf-21d3-5a87c38fbc20@status6.com> On 1/19/22 2:12 PM, Steve Hannah wrote: > I have been resisting using modules for a long time because it just makes > things more complicated, ... It also makes some things easier, though, and certainly smaller. It's easier to use an old-school Makefile with modules, and using 'jlink' can get a simple Hello World JavaFX application and Java runtime down to just 31 megabytes. Here's my minimal, no-magic example: https://github.com/jgneff/hello-javafx with a simple Makefile: https://github.com/jgneff/hello-javafx/blob/main/Makefile and a Maven POM for use online with Maven Central or offline with a local Debian- or Ubuntu-built Maven repository: https://github.com/jgneff/hello-javafx/blob/main/pom.xml John From steve at weblite.ca Thu Jan 20 00:07:16 2022 From: steve at weblite.ca (Steve Hannah) Date: Wed, 19 Jan 2022 16:07:16 -0800 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: <49c84da5-9590-74cf-21d3-5a87c38fbc20@status6.com> References: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> <49c84da5-9590-74cf-21d3-5a87c38fbc20@status6.com> Message-ID: I've reduced the problem down to something minimal and have found that: 1. If your main class extends Application, and you try to run it like: java -jar MyApplication.jar It will fail immediately with: Error: JavaFX runtime components are missing, and are required to run this application 2. If you "trick" it, by making your Application class a separate class that you call from your main class, it will run fine using: java -jar MyApplication.jar 3. It will also run fine in this scenario using -Djava.class.path=MyApplication.jar instead of -jar: java -Djava.class.path=MyApplication.jar Main 3. If I try to simulate the exact same thing with my own launcher, it will hang somewhere in the JavaFX initialization: with javafx.verbose=true, the output is: System.loadLibrary(prism_es2) succeeded JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit System.loadLibrary(glass) succeeded But it hangs there, and never displays the screen. The C code for this launcher is: char *mainClass; JavaVM *vm; JNIEnv *env; JavaVMInitArgs vm_args; JavaVMOption options[2]; mainClass = "Main"; options[0].optionString = "-Djava.class.path=MyApplication.jar"; options[1].optionString = "-Djavafx.verbose=true"; vm_args.version = JNI_VERSION_1_2; vm_args.options = options; vm_args.nOptions = 2; vm_args.ignoreUnrecognized = 0; jobjectArray args; jint res = JNI_CreateJavaVM(&vm, (void **)&env, &vm_args); if (res < 0) { printf("Can't create Java VM\n"); exit(1); } jclass cls = (*env)->FindClass(env, mainClass); if (cls == 0) { printf("Main class %s class not found\n", mainClass); exit(1); } jmethodID mid = (*env)->GetStaticMethodID(env, cls, "main", "([Ljava/lang/String;)V"); if (mid == 0) { printf("main() method not found\n"); exit(1); } //jstring argString = (*env)->NewStringUTF(env, ""); //empty arg list args = (*env)->NewObjectArray(env, 0, (*env)->FindClass(env, "java/lang/String"), NULL); if (args == 0) { printf("Out of memory\n"); exit(1); } (*env)->CallStaticVoidMethod(env, cls, mid, args); Can anyone spot any differences between that and running with the "java" binary:? java -Djava.class.path=MyApplication.jar Main I have experimented both with JDKs that include JavaFX (e.g. Zulu) and ones that do not (e.g. AdoptOpenJDK). Both exhibit the same behaviour (except with AdoptOpenJDK, I also add the javafx jars to the classpath). For this test I'm using JDK 11 on Mac OS Mojave, but it is consistent with my earlier troubles on Ubuntu (also JDK11). Best regards Steve On Wed, Jan 19, 2022 at 3:06 PM John Neffenger wrote: > On 1/19/22 2:12 PM, Steve Hannah wrote: > > I have been resisting using modules for a long time because it just makes > > things more complicated, ... > > It also makes some things easier, though, and certainly smaller. It's > easier to use an old-school Makefile with modules, and using 'jlink' can > get a simple Hello World JavaFX application and Java runtime down to > just 31 megabytes. > > Here's my minimal, no-magic example: > > https://github.com/jgneff/hello-javafx > > with a simple Makefile: > > https://github.com/jgneff/hello-javafx/blob/main/Makefile > > and a Maven POM for use online with Maven Central or offline with a > local Debian- or Ubuntu-built Maven repository: > > https://github.com/jgneff/hello-javafx/blob/main/pom.xml > > John > -- Steve Hannah Web Lite Solutions Corp. From nlisker at gmail.com Thu Jan 20 00:57:21 2022 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 20 Jan 2022 02:57:21 +0200 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: References: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> <49c84da5-9590-74cf-21d3-5a87c38fbc20@status6.com> Message-ID: > > 1. If your main class extends Application, and you try to run it like: > java -jar MyApplication.jar > It will fail immediately with: > Error: JavaFX runtime components are missing, and are required to run this > application > 2. If you "trick" it, by making your Application class a separate class > that you call from your main class, it will run fine using: > java -jar MyApplication.jar This is documented behavior, although I admit it was hard to find it. If you go to the getting started documentation at https://openjfx.io/openjfx-docs/ and the go to Runtime images > Non-Modular project it will tell you that: "As explained here, in order to create a runnable jar with all the required JavaFX dependencies, you will need to use a launcher class that doesn't extend from Application." with a link to the explanation. Another option is to add the vm argument -Djava.library.path and point to the missing runtime components (which I believe is just the bin directory of the JavaFX runtime where the .dll files are in the case of Windows). If we could explain this in the error message somehow it will save a lot of trouble for a lot of people. Something like: "Error: JavaFX runtime components are missing, and are required to run this application. Either start the application from a class that does not extend Application or specify the -Djava.library.path VM argument pointing to the bin directory". I don't know if this specific case is detectable. Maybe Johan can comment. On Thu, Jan 20, 2022 at 2:08 AM Steve Hannah wrote: > I've reduced the problem down to something minimal and have found that: > > 1. If your main class extends Application, and you try to run it like: > java -jar MyApplication.jar > > It will fail immediately with: > Error: JavaFX runtime components are missing, and are required to run this > application > > 2. If you "trick" it, by making your Application class a separate class > that you call from your main class, it will run fine using: > java -jar MyApplication.jar > > 3. It will also run fine in this scenario using > -Djava.class.path=MyApplication.jar instead of -jar: > java -Djava.class.path=MyApplication.jar Main > > 3. If I try to simulate the exact same thing with my own launcher, it will > hang somewhere in the JavaFX initialization: > > with javafx.verbose=true, the output is: > > System.loadLibrary(prism_es2) succeeded > JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit > System.loadLibrary(glass) succeeded > > But it hangs there, and never displays the screen. > > The C code for this launcher is: > > char *mainClass; > > JavaVM *vm; > JNIEnv *env; > JavaVMInitArgs vm_args; > JavaVMOption options[2]; > mainClass = "Main"; > options[0].optionString = "-Djava.class.path=MyApplication.jar"; > options[1].optionString = "-Djavafx.verbose=true"; > vm_args.version = JNI_VERSION_1_2; > vm_args.options = options; > vm_args.nOptions = 2; > vm_args.ignoreUnrecognized = 0; > > jobjectArray args; > jint res = JNI_CreateJavaVM(&vm, (void **)&env, &vm_args); > if (res < 0) { > printf("Can't create Java VM\n"); > exit(1); > } > jclass cls = (*env)->FindClass(env, mainClass); > if (cls == 0) { > > printf("Main class %s class not found\n", mainClass); > exit(1); > } > jmethodID mid = > (*env)->GetStaticMethodID(env, cls, "main", "([Ljava/lang/String;)V"); > if (mid == 0) { > printf("main() method not found\n"); > exit(1); > } > //jstring argString = (*env)->NewStringUTF(env, ""); //empty arg list > args = > (*env)->NewObjectArray(env, 0, (*env)->FindClass(env, > "java/lang/String"), NULL); > if (args == 0) { > printf("Out of memory\n"); > exit(1); > } > > (*env)->CallStaticVoidMethod(env, cls, mid, args); > > > > Can anyone spot any differences between that and running with the "java" > binary:? > java -Djava.class.path=MyApplication.jar Main > > I have experimented both with JDKs that include JavaFX (e.g. Zulu) and ones > that do not (e.g. AdoptOpenJDK). Both exhibit the same behaviour (except > with AdoptOpenJDK, I also add the javafx jars to the classpath). > > For this test I'm using JDK 11 on Mac OS Mojave, but it is consistent with > my earlier troubles on Ubuntu (also JDK11). > > > Best regards > > Steve > > > On Wed, Jan 19, 2022 at 3:06 PM John Neffenger wrote: > > > On 1/19/22 2:12 PM, Steve Hannah wrote: > > > I have been resisting using modules for a long time because it just > makes > > > things more complicated, ... > > > > It also makes some things easier, though, and certainly smaller. It's > > easier to use an old-school Makefile with modules, and using 'jlink' can > > get a simple Hello World JavaFX application and Java runtime down to > > just 31 megabytes. > > > > Here's my minimal, no-magic example: > > > > https://github.com/jgneff/hello-javafx > > > > with a simple Makefile: > > > > https://github.com/jgneff/hello-javafx/blob/main/Makefile > > > > and a Maven POM for use online with Maven Central or offline with a > > local Debian- or Ubuntu-built Maven repository: > > > > https://github.com/jgneff/hello-javafx/blob/main/pom.xml > > > > John > > > > > -- > Steve Hannah > Web Lite Solutions Corp. > From kevin.rushforth at oracle.com Thu Jan 20 01:04:26 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Jan 2022 17:04:26 -0800 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: References: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> <49c84da5-9590-74cf-21d3-5a87c38fbc20@status6.com> Message-ID: <1171f44f-6eb3-374d-2999-417a49a46010@oracle.com> Point #1 is one of the known limitations of using javafx modules on the classpath (and is one of the reasons we recommend against it), so that's not surprising. And I see you found the workaround. I wonder if it might have something to do with a shared library that is being loaded in one case and not the other, but that's just a vague guess. Maybe someone else will spot something. Since you have something minimal that reproduces the problem for you, can you file a bug? -- Kevin On 1/19/2022 4:07 PM, Steve Hannah wrote: > I've reduced the problem down to something minimal and have found that: > > 1. If your main class extends Application, and you try to run it like: > java -jar MyApplication.jar > > It will fail immediately with: > Error: JavaFX runtime components are missing, and are required to run this > application > > 2. If you "trick" it, by making your Application class a separate class > that you call from your main class, it will run fine using: > java -jar MyApplication.jar > > 3. It will also run fine in this scenario using > -Djava.class.path=MyApplication.jar instead of -jar: > java -Djava.class.path=MyApplication.jar Main > > 3. If I try to simulate the exact same thing with my own launcher, it will > hang somewhere in the JavaFX initialization: > > with javafx.verbose=true, the output is: > > System.loadLibrary(prism_es2) succeeded > JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit > System.loadLibrary(glass) succeeded > > But it hangs there, and never displays the screen. > > The C code for this launcher is: > > char *mainClass; > > JavaVM *vm; > JNIEnv *env; > JavaVMInitArgs vm_args; > JavaVMOption options[2]; > mainClass = "Main"; > options[0].optionString = "-Djava.class.path=MyApplication.jar"; > options[1].optionString = "-Djavafx.verbose=true"; > vm_args.version = JNI_VERSION_1_2; > vm_args.options = options; > vm_args.nOptions = 2; > vm_args.ignoreUnrecognized = 0; > > jobjectArray args; > jint res = JNI_CreateJavaVM(&vm, (void **)&env, &vm_args); > if (res < 0) { > printf("Can't create Java VM\n"); > exit(1); > } > jclass cls = (*env)->FindClass(env, mainClass); > if (cls == 0) { > > printf("Main class %s class not found\n", mainClass); > exit(1); > } > jmethodID mid = > (*env)->GetStaticMethodID(env, cls, "main", "([Ljava/lang/String;)V"); > if (mid == 0) { > printf("main() method not found\n"); > exit(1); > } > //jstring argString = (*env)->NewStringUTF(env, ""); //empty arg list > args = > (*env)->NewObjectArray(env, 0, (*env)->FindClass(env, > "java/lang/String"), NULL); > if (args == 0) { > printf("Out of memory\n"); > exit(1); > } > > (*env)->CallStaticVoidMethod(env, cls, mid, args); > > > > Can anyone spot any differences between that and running with the "java" > binary:? > java -Djava.class.path=MyApplication.jar Main > > I have experimented both with JDKs that include JavaFX (e.g. Zulu) and ones > that do not (e.g. AdoptOpenJDK). Both exhibit the same behaviour (except > with AdoptOpenJDK, I also add the javafx jars to the classpath). > > For this test I'm using JDK 11 on Mac OS Mojave, but it is consistent with > my earlier troubles on Ubuntu (also JDK11). > > > Best regards > > Steve > > > On Wed, Jan 19, 2022 at 3:06 PM John Neffenger wrote: > >> On 1/19/22 2:12 PM, Steve Hannah wrote: >>> I have been resisting using modules for a long time because it just makes >>> things more complicated, ... >> It also makes some things easier, though, and certainly smaller. It's >> easier to use an old-school Makefile with modules, and using 'jlink' can >> get a simple Hello World JavaFX application and Java runtime down to >> just 31 megabytes. >> >> Here's my minimal, no-magic example: >> >> https://github.com/jgneff/hello-javafx >> >> with a simple Makefile: >> >> https://github.com/jgneff/hello-javafx/blob/main/Makefile >> >> and a Maven POM for use online with Maven Central or offline with a >> local Debian- or Ubuntu-built Maven repository: >> >> https://github.com/jgneff/hello-javafx/blob/main/pom.xml >> >> John >> > From zjx001202 at gmail.com Thu Jan 20 05:13:14 2022 From: zjx001202 at gmail.com (Glavo) Date: Thu, 20 Jan 2022 13:13:14 +0800 Subject: The openjfx native library cache path should be platform dependent Message-ID: I noticed that openjfx packaged in jar caches native libraries in ~/.openjfx/cache/${version}, it is not related to the system and architecture. It should be noted that in fact, we can start programs with different architectures on the same system. A typical example is that Windows x86 software can be run on the Windows amd64 platform. With the popularization of aarch64 architecture, this situation will become more common: The software of Windows x86 and Windows amd64 can be run on the Windows aarch64 platform, and the software of MacOs x86 can be run on the MacOS aarch64. The native library file names of different schemas on the same system are usually the same, which will cause conflicts. For example, I tried to launch the same JavaFX application on my Windows amd64 machine with two jdks that for x86 architecture and amd64 architecture at the same time, and it crashed: https://paste.ubuntu.com/p/NZBK3pNrh7/ On ARM machines, it is often necessary to run x86 applications through translators, and such crashes may be more common. I think openjfx should adjust the cache path of the native library, such as ~/.openjfx/cache/17.0.2/win-aarch64/. This can avoid crashes and avoid openjfx repeatedly decompressing the native library to cover the native libraries of other architectures. I don't have a JBS account. If you need to open an issue for this problem, please do it for me, thanks. From johan.vos at gluonhq.com Thu Jan 20 08:25:46 2022 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 20 Jan 2022 09:25:46 +0100 Subject: The openjfx native library cache path should be platform dependent In-Reply-To: References: Message-ID: That sounds correct indeed. I filed https://bugs.openjdk.java.net/browse/JDK-8280369 for this. Thanks for reporting! - Johan On Thu, Jan 20, 2022 at 6:14 AM Glavo wrote: > I noticed that openjfx packaged in jar caches native libraries in > ~/.openjfx/cache/${version}, it is not related to the system and > architecture. > > It should be noted that in fact, we can start programs with different > architectures on the same system. A typical example is that Windows x86 > software can be run on the Windows amd64 platform. > With the popularization of aarch64 architecture, this situation will become > more common: The software of Windows x86 and Windows amd64 can be run on > the Windows aarch64 platform, and the software of MacOs x86 can be run on > the MacOS aarch64. > > The native library file names of different schemas on the same system are > usually the same, which will cause conflicts. > For example, I tried to launch the same JavaFX application on my Windows > amd64 machine with two jdks that for x86 architecture and amd64 > architecture at the same time, and it crashed: > > https://paste.ubuntu.com/p/NZBK3pNrh7/ > > On ARM machines, it is often necessary to run x86 applications through > translators, and such crashes may be more common. > > I think openjfx should adjust the cache path of the native library, such as > ~/.openjfx/cache/17.0.2/win-aarch64/. > This can avoid crashes and avoid openjfx repeatedly decompressing the > native library to cover the native libraries of other architectures. > > I don't have a JBS account. If you need to open an issue for this problem, > please do it for me, thanks. > From arapte at openjdk.java.net Thu Jan 20 08:35:57 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 20 Jan 2022 08:35:57 GMT Subject: [jfx18] RFR: 8280280: Update boot JDK to 17.0.2 In-Reply-To: <0kGa7SQdsmEK2nui5ZmZ55XGLJM9t-kAv5Axg1Xrwes=.f7123d56-d29e-4505-aa27-ae56c9e45c46@github.com> References: <0kGa7SQdsmEK2nui5ZmZ55XGLJM9t-kAv5Axg1Xrwes=.f7123d56-d29e-4505-aa27-ae56c9e45c46@github.com> Message-ID: On Wed, 19 Jan 2022 18:43:31 GMT, Kevin Rushforth wrote: > JDK 17.0.2 shipped yesterday as part of the January CPU release. We should update the JavaFX 18 build to use that version, so this is targeted for `jfx18`. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/721 From aghaisas at openjdk.java.net Thu Jan 20 09:48:57 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 20 Jan 2022 09:48:57 GMT Subject: RFR: 8187307: ListView, TableView, TreeView: receives editCancel event when edit is committed In-Reply-To: References: Message-ID: <_wi8KdehBE66gI_gCNDYa34yU-dwLLdKdBjXUSaxDug=.d886e876-ea97-47c1-a95e-47203af741ab@github.com> On Tue, 30 Nov 2021 12:32:37 GMT, Jeanette Winzenburg wrote: > The misbehaviour was that an edit handler received both a commit and cancel event when cell commitEdit is called. That happened whenever a collaborator reset the controls editing state (either directly or indirectly) while processing the editCommit event. The reason was that the cell had not yet updated its own editing state when receiving the change of editing from the control. > > Fix is to update cell's editing state before firing the event, that is change the sequence or method calls from fire/super.commit to super.commit/fire. > > Added tests that fail/pass before/after the fix. The fix and tests look good. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/684 From aghaisas at openjdk.java.net Thu Jan 20 10:12:52 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 20 Jan 2022 10:12:52 GMT Subject: [jfx18] RFR: 8280275: JUnit5 tests using Assumptions API fail to compile in some cases In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 15:18:48 GMT, Kevin Rushforth wrote: > Fixed a test dependency issue in `build.gradle` that causes a compilation failure when running `gradle test` if the `Assumptions` API from JUnit5 is used. I added a test that fails to compile without the build fix and passes with the fix. > > This was first discovered when testing the patch for PR #715, which fails to compile on my local macOS system. After applying this fix, I can compile and run the test from that PR. I verified that the test fails to compile without fix & runs successfully with the fix. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/720 From fastegal at openjdk.java.net Thu Jan 20 11:51:58 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 20 Jan 2022 11:51:58 GMT Subject: Integrated: 8187307: ListView, TableView, TreeView: receives editCancel event when edit is committed In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 12:32:37 GMT, Jeanette Winzenburg wrote: > The misbehaviour was that an edit handler received both a commit and cancel event when cell commitEdit is called. That happened whenever a collaborator reset the controls editing state (either directly or indirectly) while processing the editCommit event. The reason was that the cell had not yet updated its own editing state when receiving the change of editing from the control. > > Fix is to update cell's editing state before firing the event, that is change the sequence or method calls from fire/super.commit to super.commit/fire. > > Added tests that fail/pass before/after the fix. This pull request has now been integrated. Changeset: 4c79c54c Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/4c79c54c490031a9491790702c6bfb611d88f3b9 Stats: 158 lines in 8 files changed: 117 ins; 29 del; 12 mod 8187307: ListView, TableView, TreeView: receives editCancel event when edit is committed Reviewed-by: mhanl, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/684 From fastegal at swingempire.de Thu Jan 20 12:13:56 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 20 Jan 2022 13:13:56 +0100 Subject: Commit bots confused? Message-ID: <20220120131356.Horde.tneQ-yVhNzWKjx6D5WkQdA1@webmail.df.eu> wondering what happened in https://github.com/openjdk/jfx/pull/684 (fix for https://bugs.openjdk.java.net/browse/JDK-8187307) - requested integration (into master) after review approval - the bots did the usual thingies (commit, comment/close the issue in jbs) - the bots did some unusual thingies: creating a backport https://bugs.openjdk.java.net/browse/JDK-8280380 into jfx19 and commented/closed it as fixed immediately) verified that the commit (as of now) really is into master, not fx18 - so the actual commits seem to be clean, it's just that weird auto-backport What might have confused them is that I didn't update the fix version of the issue (it's still fx18) after rampdown (being still in holiday mode ;) Anything I should do? -- Jeanette From kcr at openjdk.java.net Thu Jan 20 12:16:00 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 20 Jan 2022 12:16:00 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v5] In-Reply-To: <0zNj5dADRh9nQulBX5wwpn4yOv0fW3qASFK7yXEKHss=.cae1d4bf-a796-47f4-ae59-e0da5c82f435@github.com> References: <0zNj5dADRh9nQulBX5wwpn4yOv0fW3qASFK7yXEKHss=.cae1d4bf-a796-47f4-ae59-e0da5c82f435@github.com> Message-ID: On Wed, 19 Jan 2022 19:43:38 GMT, Martin Fox wrote: >> When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. >> >> This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. >> >> System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > More coding standard tweaks Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/715 From kcr at openjdk.java.net Thu Jan 20 12:16:01 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 20 Jan 2022 12:16:01 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v4] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 17:26:44 GMT, Jose Pereda wrote: >> Martin Fox has updated the pull request incrementally with one additional commit since the last revision: >> >> Renamed test to match existing conventions along with minor cleanup. > > Looks good @jperedadnr can you re-review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/715 From kcr at openjdk.java.net Thu Jan 20 12:16:58 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 20 Jan 2022 12:16:58 GMT Subject: [jfx18] Integrated: 8280275: JUnit5 tests using Assumptions API fail to compile in some cases In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 15:18:48 GMT, Kevin Rushforth wrote: > Fixed a test dependency issue in `build.gradle` that causes a compilation failure when running `gradle test` if the `Assumptions` API from JUnit5 is used. I added a test that fails to compile without the build fix and passes with the fix. > > This was first discovered when testing the patch for PR #715, which fails to compile on my local macOS system. After applying this fix, I can compile and run the test from that PR. This pull request has now been integrated. Changeset: 94807b6e Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/94807b6edfb9af55be353cab237e8e64007c61dc Stats: 6 lines in 2 files changed: 4 ins; 1 del; 1 mod 8280275: JUnit5 tests using Assumptions API fail to compile in some cases Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/720 From jpereda at openjdk.java.net Thu Jan 20 12:22:58 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 20 Jan 2022 12:22:58 GMT Subject: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v5] In-Reply-To: <0zNj5dADRh9nQulBX5wwpn4yOv0fW3qASFK7yXEKHss=.cae1d4bf-a796-47f4-ae59-e0da5c82f435@github.com> References: <0zNj5dADRh9nQulBX5wwpn4yOv0fW3qASFK7yXEKHss=.cae1d4bf-a796-47f4-ae59-e0da5c82f435@github.com> Message-ID: On Wed, 19 Jan 2022 19:43:38 GMT, Martin Fox wrote: >> When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. >> >> This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. >> >> System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > More coding standard tweaks Tested again, looks good ------------- Marked as reviewed by jpereda (Committer). PR: https://git.openjdk.java.net/jfx/pull/715 From kevin.rushforth at oracle.com Thu Jan 20 12:32:48 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 20 Jan 2022 04:32:48 -0800 Subject: Commit bots confused? In-Reply-To: <20220120131356.Horde.tneQ-yVhNzWKjx6D5WkQdA1@webmail.df.eu> References: <20220120131356.Horde.tneQ-yVhNzWKjx6D5WkQdA1@webmail.df.eu> Message-ID: Yes, this happened because the bug was still targeted to openjfx18. I had meant to go through all of the issues still targeted to openjfx18 earlier this week, but then got busy with (too many) other things. I'll fix up the JBS records. Thanks. -- Kevin On 1/20/2022 4:13 AM, Jeanette Winzenburg wrote: > > wondering what happened in https://github.com/openjdk/jfx/pull/684 > (fix for https://bugs.openjdk.java.net/browse/JDK-8187307) > > - requested integration (into master) after review approval > - the bots did the usual thingies (commit, comment/close the issue in > jbs) > - the bots did some unusual thingies: creating a backport > https://bugs.openjdk.java.net/browse/JDK-8280380 into jfx19 and > commented/closed it as fixed immediately) > > verified that the commit (as of now) really is into master, not fx18 - > so the actual commits seem to be clean, it's just that weird > auto-backport > > What might have confused them is that I didn't update the fix version > of the issue (it's still fx18) after rampdown (being still in holiday > mode ;) > > Anything I should do? > > -- Jeanette > From steve at weblite.ca Thu Jan 20 13:00:20 2022 From: steve at weblite.ca (Steve Hannah) Date: Thu, 20 Jan 2022 05:00:20 -0800 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: <1171f44f-6eb3-374d-2999-417a49a46010@oracle.com> References: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> <49c84da5-9590-74cf-21d3-5a87c38fbc20@status6.com> <1171f44f-6eb3-374d-2999-417a49a46010@oracle.com> Message-ID: Thanks for all the help on this. I have done some further digging and I think the current problem (with the minimal test case) may not be JavaFX specific, but rather something related to GUI in general on Mac OS. I changed the test to just use Swing but it also hangs as soon as it tries to create a JFrame. I'm guessing that this is something related to gatekeeper, or perhaps I need some special compile flags on MacOS to allow a binary to do GUI stuff. I find this absolutely bizarre since I had "real-world" test cases working earlier with almost identical code. I must have done something in those real world apps that "enabled" GUI as a byproduct. I'm just not sure what. Best regards Steve On Wed, Jan 19, 2022 at 5:04 PM Kevin Rushforth wrote: > Point #1 is one of the known limitations of using javafx modules on the > classpath (and is one of the reasons we recommend against it), so that's > not surprising. And I see you found the workaround. > > I wonder if it might have something to do with a shared library that is > being loaded in one case and not the other, but that's just a vague > guess. Maybe someone else will spot something. > > Since you have something minimal that reproduces the problem for you, > can you file a bug? > > -- Kevin > > > On 1/19/2022 4:07 PM, Steve Hannah wrote: > > I've reduced the problem down to something minimal and have found that: > > > > 1. If your main class extends Application, and you try to run it like: > > java -jar MyApplication.jar > > > > It will fail immediately with: > > Error: JavaFX runtime components are missing, and are required to run > this > > application > > > > 2. If you "trick" it, by making your Application class a separate class > > that you call from your main class, it will run fine using: > > java -jar MyApplication.jar > > > > 3. It will also run fine in this scenario using > > -Djava.class.path=MyApplication.jar instead of -jar: > > java -Djava.class.path=MyApplication.jar Main > > > > 3. If I try to simulate the exact same thing with my own launcher, it > will > > hang somewhere in the JavaFX initialization: > > > > with javafx.verbose=true, the output is: > > > > System.loadLibrary(prism_es2) succeeded > > JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit > > System.loadLibrary(glass) succeeded > > > > But it hangs there, and never displays the screen. > > > > The C code for this launcher is: > > > > char *mainClass; > > > > JavaVM *vm; > > JNIEnv *env; > > JavaVMInitArgs vm_args; > > JavaVMOption options[2]; > > mainClass = "Main"; > > options[0].optionString = "-Djava.class.path=MyApplication.jar"; > > options[1].optionString = "-Djavafx.verbose=true"; > > vm_args.version = JNI_VERSION_1_2; > > vm_args.options = options; > > vm_args.nOptions = 2; > > vm_args.ignoreUnrecognized = 0; > > > > jobjectArray args; > > jint res = JNI_CreateJavaVM(&vm, (void **)&env, &vm_args); > > if (res < 0) { > > printf("Can't create Java VM\n"); > > exit(1); > > } > > jclass cls = (*env)->FindClass(env, mainClass); > > if (cls == 0) { > > > > printf("Main class %s class not found\n", mainClass); > > exit(1); > > } > > jmethodID mid = > > (*env)->GetStaticMethodID(env, cls, "main", "([Ljava/lang/String;)V"); > > if (mid == 0) { > > printf("main() method not found\n"); > > exit(1); > > } > > //jstring argString = (*env)->NewStringUTF(env, ""); //empty arg list > > args = > > (*env)->NewObjectArray(env, 0, (*env)->FindClass(env, > > "java/lang/String"), NULL); > > if (args == 0) { > > printf("Out of memory\n"); > > exit(1); > > } > > > > (*env)->CallStaticVoidMethod(env, cls, mid, args); > > > > > > > > Can anyone spot any differences between that and running with the "java" > > binary:? > > java -Djava.class.path=MyApplication.jar Main > > > > I have experimented both with JDKs that include JavaFX (e.g. Zulu) and > ones > > that do not (e.g. AdoptOpenJDK). Both exhibit the same behaviour (except > > with AdoptOpenJDK, I also add the javafx jars to the classpath). > > > > For this test I'm using JDK 11 on Mac OS Mojave, but it is consistent > with > > my earlier troubles on Ubuntu (also JDK11). > > > > > > Best regards > > > > Steve > > > > > > On Wed, Jan 19, 2022 at 3:06 PM John Neffenger wrote: > > > >> On 1/19/22 2:12 PM, Steve Hannah wrote: > >>> I have been resisting using modules for a long time because it just > makes > >>> things more complicated, ... > >> It also makes some things easier, though, and certainly smaller. It's > >> easier to use an old-school Makefile with modules, and using 'jlink' can > >> get a simple Hello World JavaFX application and Java runtime down to > >> just 31 megabytes. > >> > >> Here's my minimal, no-magic example: > >> > >> https://github.com/jgneff/hello-javafx > >> > >> with a simple Makefile: > >> > >> https://github.com/jgneff/hello-javafx/blob/main/Makefile > >> > >> and a Maven POM for use online with Maven Central or offline with a > >> local Debian- or Ubuntu-built Maven repository: > >> > >> https://github.com/jgneff/hello-javafx/blob/main/pom.xml > >> > >> John > >> > > > > -- Steve Hannah Web Lite Solutions Corp. From fastegal at swingempire.de Thu Jan 20 13:30:18 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 20 Jan 2022 14:30:18 +0100 Subject: Commit bots confused? In-Reply-To: References: <20220120131356.Horde.tneQ-yVhNzWKjx6D5WkQdA1@webmail.df.eu> Message-ID: <20220120143018.Horde.OKDLxA_vUhMYiDgnzJb8Jg2@webmail.df.eu> Thanks for the cleanup, Kevin - and sry for having created the mess ;) -- Jeanette Zitat von Kevin Rushforth : > Yes, this happened because the bug was still targeted to openjfx18. > I had meant to go through all of the issues still targeted to > openjfx18 earlier this week, but then got busy with (too many) other > things. > > I'll fix up the JBS records. > > Thanks. > > -- Kevin > > > On 1/20/2022 4:13 AM, Jeanette Winzenburg wrote: >> >> wondering what happened in https://github.com/openjdk/jfx/pull/684 >> (fix for https://bugs.openjdk.java.net/browse/JDK-8187307) >> >> - requested integration (into master) after review approval >> - the bots did the usual thingies (commit, comment/close the issue in jbs) >> - the bots did some unusual thingies: creating a backport >> https://bugs.openjdk.java.net/browse/JDK-8280380 into jfx19 and >> commented/closed it as fixed immediately) >> >> verified that the commit (as of now) really is into master, not >> fx18 - so the actual commits seem to be clean, it's just that weird >> auto-backport >> >> What might have confused them is that I didn't update the fix >> version of the issue (it's still fx18) after rampdown (being still >> in holiday mode ;) >> >> Anything I should do? >> >> -- Jeanette >> From kevin.rushforth at oracle.com Thu Jan 20 13:45:07 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 20 Jan 2022 05:45:07 -0800 Subject: Commit bots confused? In-Reply-To: <20220120143018.Horde.OKDLxA_vUhMYiDgnzJb8Jg2@webmail.df.eu> References: <20220120131356.Horde.tneQ-yVhNzWKjx6D5WkQdA1@webmail.df.eu> <20220120143018.Horde.OKDLxA_vUhMYiDgnzJb8Jg2@webmail.df.eu> Message-ID: <808259b5-36f6-d828-f5ab-c5be3a25025e@oracle.com> No worries. -- Kevin On 1/20/2022 5:30 AM, Jeanette Winzenburg wrote: > > Thanks for the cleanup, Kevin - and sry for having created the mess ;) > > -- Jeanette > > Zitat von Kevin Rushforth : > >> Yes, this happened because the bug was still targeted to openjfx18. I >> had meant to go through all of the issues still targeted to openjfx18 >> earlier this week, but then got busy with (too many) other things. >> >> I'll fix up the JBS records. >> >> Thanks. >> >> -- Kevin >> >> >> On 1/20/2022 4:13 AM, Jeanette Winzenburg wrote: >>> >>> wondering what happened in https://github.com/openjdk/jfx/pull/684 >>> (fix for https://bugs.openjdk.java.net/browse/JDK-8187307) >>> >>> - requested integration (into master) after review approval >>> - the bots did the usual thingies (commit, comment/close the issue >>> in jbs) >>> - the bots did some unusual thingies: creating a backport >>> https://bugs.openjdk.java.net/browse/JDK-8280380 into jfx19 and >>> commented/closed it as fixed immediately) >>> >>> verified that the commit (as of now) really is into master, not fx18 >>> - so the actual commits seem to be clean, it's just that weird >>> auto-backport >>> >>> What might have confused them is that I didn't update the fix >>> version of the issue (it's still fx18) after rampdown (being still >>> in holiday mode ;) >>> >>> Anything I should do? >>> >>> -- Jeanette >>> > > > From steve at weblite.ca Thu Jan 20 15:08:56 2022 From: steve at weblite.ca (Steve Hannah) Date: Thu, 20 Jan 2022 07:08:56 -0800 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: References: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> <49c84da5-9590-74cf-21d3-5a87c38fbc20@status6.com> <1171f44f-6eb3-374d-2999-417a49a46010@oracle.com> Message-ID: I just wanted to post an update on this in case it helps some future dev who gets stuck on the same issue. It seems that on Mac OS you can't use JNI_CreateJavaVM() to launch the JVM if you hope to use any GUI stuff. This issue is described in this issue: https://bugs.openjdk.java.net/browse/JDK-8265755 This is because the initialising the Frame class initialises the Toolkit > class which > in turn has to start the macos AppKit loop on this main thread of the > application. > This is a "hard" macOS requirement and there's no getting around it. > So it blocks and never returns. When running a Java app in the usual way > this > initial thread is reserved for the UI and the thread on which the Java app > is run > is a different one created by the VM. > ... > The only workaround is not a complete workaround. So far, the appbundler > has to use the JLI_Launch function but that function does provide any > feedback if, say, the class loader fails. By changing my launcher to use JLI_Launch() it resolves the simple test case on Mac OS. I expect that it will probably solve my other problems on Ubuntu also. It also comes with the added benefit of accepting arguments at the same level of abstraction as the "java" binary itself. E.g. When using JNI_CreateJavaVM(), I couldn't just pass "-jar MyApplication.jar" because it doesn't know how to parse the Main class and classpath from the jar. With JNI_Launch(), however, it will handle such arguments. Here is the basic test case I built using JLI_Launch, which seems to work. https://gist.github.com/shannah/57fc4bf4be42cac4e2ab4475f1d308a6 Anyways, thank you for all of the input you guys have provided. Best regards Steve On Thu, Jan 20, 2022 at 5:00 AM Steve Hannah wrote: > Thanks for all the help on this. > > I have done some further digging and I think the current problem (with the > minimal test case) may not be JavaFX specific, but rather something related > to GUI in general on Mac OS. I changed the test to just use Swing but it > also hangs as soon as it tries to create a JFrame. I'm guessing that this > is something related to gatekeeper, or perhaps I need some special compile > flags on MacOS to allow a binary to do GUI stuff. > > I find this absolutely bizarre since I had "real-world" test cases working > earlier with almost identical code. I must have done something in those > real world apps that "enabled" GUI as a byproduct. I'm just not sure what. > > Best regards > > Steve > > On Wed, Jan 19, 2022 at 5:04 PM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Point #1 is one of the known limitations of using javafx modules on the >> classpath (and is one of the reasons we recommend against it), so that's >> not surprising. And I see you found the workaround. >> >> I wonder if it might have something to do with a shared library that is >> being loaded in one case and not the other, but that's just a vague >> guess. Maybe someone else will spot something. >> >> Since you have something minimal that reproduces the problem for you, >> can you file a bug? >> >> -- Kevin >> >> >> On 1/19/2022 4:07 PM, Steve Hannah wrote: >> > I've reduced the problem down to something minimal and have found that: >> > >> > 1. If your main class extends Application, and you try to run it like: >> > java -jar MyApplication.jar >> > >> > It will fail immediately with: >> > Error: JavaFX runtime components are missing, and are required to run >> this >> > application >> > >> > 2. If you "trick" it, by making your Application class a separate class >> > that you call from your main class, it will run fine using: >> > java -jar MyApplication.jar >> > >> > 3. It will also run fine in this scenario using >> > -Djava.class.path=MyApplication.jar instead of -jar: >> > java -Djava.class.path=MyApplication.jar Main >> > >> > 3. If I try to simulate the exact same thing with my own launcher, it >> will >> > hang somewhere in the JavaFX initialization: >> > >> > with javafx.verbose=true, the output is: >> > >> > System.loadLibrary(prism_es2) succeeded >> > JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit >> > System.loadLibrary(glass) succeeded >> > >> > But it hangs there, and never displays the screen. >> > >> > The C code for this launcher is: >> > >> > char *mainClass; >> > >> > JavaVM *vm; >> > JNIEnv *env; >> > JavaVMInitArgs vm_args; >> > JavaVMOption options[2]; >> > mainClass = "Main"; >> > options[0].optionString = "-Djava.class.path=MyApplication.jar"; >> > options[1].optionString = "-Djavafx.verbose=true"; >> > vm_args.version = JNI_VERSION_1_2; >> > vm_args.options = options; >> > vm_args.nOptions = 2; >> > vm_args.ignoreUnrecognized = 0; >> > >> > jobjectArray args; >> > jint res = JNI_CreateJavaVM(&vm, (void **)&env, &vm_args); >> > if (res < 0) { >> > printf("Can't create Java VM\n"); >> > exit(1); >> > } >> > jclass cls = (*env)->FindClass(env, mainClass); >> > if (cls == 0) { >> > >> > printf("Main class %s class not found\n", mainClass); >> > exit(1); >> > } >> > jmethodID mid = >> > (*env)->GetStaticMethodID(env, cls, "main", "([Ljava/lang/String;)V"); >> > if (mid == 0) { >> > printf("main() method not found\n"); >> > exit(1); >> > } >> > //jstring argString = (*env)->NewStringUTF(env, ""); //empty arg list >> > args = >> > (*env)->NewObjectArray(env, 0, (*env)->FindClass(env, >> > "java/lang/String"), NULL); >> > if (args == 0) { >> > printf("Out of memory\n"); >> > exit(1); >> > } >> > >> > (*env)->CallStaticVoidMethod(env, cls, mid, args); >> > >> > >> > >> > Can anyone spot any differences between that and running with the "java" >> > binary:? >> > java -Djava.class.path=MyApplication.jar Main >> > >> > I have experimented both with JDKs that include JavaFX (e.g. Zulu) and >> ones >> > that do not (e.g. AdoptOpenJDK). Both exhibit the same behaviour >> (except >> > with AdoptOpenJDK, I also add the javafx jars to the classpath). >> > >> > For this test I'm using JDK 11 on Mac OS Mojave, but it is consistent >> with >> > my earlier troubles on Ubuntu (also JDK11). >> > >> > >> > Best regards >> > >> > Steve >> > >> > >> > On Wed, Jan 19, 2022 at 3:06 PM John Neffenger >> wrote: >> > >> >> On 1/19/22 2:12 PM, Steve Hannah wrote: >> >>> I have been resisting using modules for a long time because it just >> makes >> >>> things more complicated, ... >> >> It also makes some things easier, though, and certainly smaller. It's >> >> easier to use an old-school Makefile with modules, and using 'jlink' >> can >> >> get a simple Hello World JavaFX application and Java runtime down to >> >> just 31 megabytes. >> >> >> >> Here's my minimal, no-magic example: >> >> >> >> https://github.com/jgneff/hello-javafx >> >> >> >> with a simple Makefile: >> >> >> >> https://github.com/jgneff/hello-javafx/blob/main/Makefile >> >> >> >> and a Maven POM for use online with Maven Central or offline with a >> >> local Debian- or Ubuntu-built Maven repository: >> >> >> >> https://github.com/jgneff/hello-javafx/blob/main/pom.xml >> >> >> >> John >> >> >> > >> >> > > -- > Steve Hannah > Web Lite Solutions Corp. > -- Steve Hannah Web Lite Solutions Corp. From mik3hall at gmail.com Thu Jan 20 15:13:54 2022 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 20 Jan 2022 09:13:54 -0600 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: References: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> <49c84da5-9590-74cf-21d3-5a87c38fbc20@status6.com> <1171f44f-6eb3-374d-2999-417a49a46010@oracle.com> Message-ID: <430F90D2-471E-472F-9438-5AEA2B5FCBEF@gmail.com> > On Jan 20, 2022, at 9:08 AM, Steve Hannah wrote: > > I just wanted to post an update on this in case it helps some future dev > who gets stuck on the same issue. > You probably have good reasons for having your own launcher but you might want to consider if jpackage could be an alternative and let that handle these cross-platform application details. From steve at weblite.ca Thu Jan 20 15:23:34 2022 From: steve at weblite.ca (Steve Hannah) Date: Thu, 20 Jan 2022 07:23:34 -0800 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: <430F90D2-471E-472F-9438-5AEA2B5FCBEF@gmail.com> References: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> <49c84da5-9590-74cf-21d3-5a87c38fbc20@status6.com> <1171f44f-6eb3-374d-2999-417a49a46010@oracle.com> <430F90D2-471E-472F-9438-5AEA2B5FCBEF@gmail.com> Message-ID: My reason for a launcher is that I'm building an alternative to jpackage that uses npm for deployment/versioning/updates and allows you to build native bundles for all platforms (Mac/Linux/Windows) on any platform. I.e. You don't need to be building on a Windows box to create a native windows exe. You don't need to worry about Mac codesigning and notarization, etc... It just takes care of all that for you on whatever system you're developing on. I already had it working well but it currently launches JVM in a separate process which wasn't optimal - so I'm working on improving it to be able to run in the same process as the launcher. This (I think) was the last obstacle. Best regards Steve On Thu, Jan 20, 2022 at 7:13 AM Michael Hall wrote: > > > > On Jan 20, 2022, at 9:08 AM, Steve Hannah wrote: > > > > I just wanted to post an update on this in case it helps some future dev > > who gets stuck on the same issue. > > > > You probably have good reasons for having your own launcher but you might > want to consider if jpackage could be an alternative and let that handle > these cross-platform application details. > > -- Steve Hannah Web Lite Solutions Corp. From mik3hall at gmail.com Thu Jan 20 15:31:34 2022 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 20 Jan 2022 09:31:34 -0600 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: References: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> <49c84da5-9590-74cf-21d3-5a87c38fbc20@status6.com> <1171f44f-6eb3-374d-2999-417a49a46010@oracle.com> <430F90D2-471E-472F-9438-5AEA2B5FCBEF@gmail.com> Message-ID: > On Jan 20, 2022, at 9:23 AM, Steve Hannah wrote: > > My reason for a launcher is that I'm building an alternative to jpackage that uses npm for deployment/versioning/updates and allows you to build native bundles for all platforms (Mac/Linux/Windows) on any platform. I.e. You don't need to be building on a Windows box to create a native windows exe. You don't need to worry about Mac codesigning and notarization, etc... It just takes care of all that for you on whatever system you're developing on. > > I already had it working well but it currently launches JVM in a separate process which wasn't optimal - so I'm working on improving it to be able to run in the same process as the launcher. This (I think) was the last obstacle. > > Best regards > > Steve I?m not sure jpackage handles the notarization. I had done it for a jpackage application and posted something on how to do it on my site. My builds are currently throwing some sort of error on that I haven?t looked at yet. The code signing and packaging I think all invoke native OS/X commands. Not trivial but that could also probably be done on your own. It appeared tricky with an already signed embedded jdk. It took jpackage a few releases to get it right. > > On Thu, Jan 20, 2022 at 7:13 AM Michael Hall > wrote: > > > > On Jan 20, 2022, at 9:08 AM, Steve Hannah > wrote: > > > > I just wanted to post an update on this in case it helps some future dev > > who gets stuck on the same issue. > > > > You probably have good reasons for having your own launcher but you might want to consider if jpackage could be an alternative and let that handle these cross-platform application details. > > > From steve at weblite.ca Thu Jan 20 15:56:54 2022 From: steve at weblite.ca (Steve Hannah) Date: Thu, 20 Jan 2022 07:56:54 -0800 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: References: <10f84b5c0d3e1a48076aea94863ad971c3b638e5.camel@doppel-helix.eu> <49c84da5-9590-74cf-21d3-5a87c38fbc20@status6.com> <1171f44f-6eb3-374d-2999-417a49a46010@oracle.com> <430F90D2-471E-472F-9438-5AEA2B5FCBEF@gmail.com> Message-ID: > > I?m not sure jpackage handles the notarization. I had done it for a > jpackage application and posted something on how to do it on my site. My > builds are currently throwing some sort of error on that I haven?t looked > at yet. The code signing and packaging I think all invoke native OS/X > commands. Not trivial but that could also probably be done on your own. It > appeared tricky with an already signed embedded jdk. It took jpackage a few > releases to get it right. > The way that I'm getting around this is by generating a platform-specific "Installer" which can be distributed. The installer itself is notarized, so it can be distributed to users outside the app store, and run without the Gatekeeper restrictions. Since the installer app bundle itself is the same for every app, it needs to look up the metadata for the specific app being installed using a naming convention of the app. I have the codesigning and notarization of this installer set up in github actions. It's not that complicated, but it's enough of a hassle that I would rather do this once, and never worry about it again. Here is the bit of my github action that deals with signing and notarization: https://github.com/shannah/jdeploy/blob/64bf78a9c3f1f526a7361c10cfa0e6f42da430a5/release.sh#L33-L50 When the end-user downloads and runs the installer, it will then install the app itself locally. The final, resulting app won't be signed or notarized, but that is OK because it isn't subject to the notarization restriction like it would be if you had downloaded it directly. This is similar to the way that Chrome creates Chrome apps from a PWA. Apps distributed in this way would not be acceptable in the Mac App Store. For that you would need jpackage. But it solves the problem of "I just built a Java app that I want to distribute to my users, and I don't want to get bogged down in creating native bundles for each platform, or worrying about distribution/updates". Best regards Steve > > > On Thu, Jan 20, 2022 at 7:13 AM Michael Hall wrote: > >> >> >> > On Jan 20, 2022, at 9:08 AM, Steve Hannah wrote: >> > >> > I just wanted to post an update on this in case it helps some future dev >> > who gets stuck on the same issue. >> > >> >> You probably have good reasons for having your own launcher but you might >> want to consider if jpackage could be an alternative and let that handle >> these cross-platform application details. >> >> > > > -- Steve Hannah Web Lite Solutions Corp. From duke at openjdk.java.net Thu Jan 20 17:52:53 2022 From: duke at openjdk.java.net (Martin Fox) Date: Thu, 20 Jan 2022 17:52:53 GMT Subject: [jfx18] Integrated: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 19:18:33 GMT, Martin Fox wrote: > When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquivalent. To fix RT-39813 the closing of the window was deferred causing the flag to be set too late. This PR simply sets that flag when we schedule the close event instead of when the OS actually closes the window. > > This is a spot-fix for a larger problem, namely that we have no way of knowing whether a performKeyEquivalent event was consumed or not. The changes for fixing that are in PR #694. The changes got bundled into that PR only because there's a lot of files involved and the exact same code paths are touched. > > System test is included (I'm surprised, it really is possible to generate Cmd+Enter using a Robot). This is new territory for me so I have a manual test I can submit as a backup. This pull request has now been integrated. Changeset: 217e086b Author: Martin Fox Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/217e086b3493dfc7d419d8fa632a9d3091e7f823 Stats: 170 lines in 2 files changed: 170 ins; 0 del; 0 mod 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage Reviewed-by: jpereda, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/715 From nlisker at openjdk.java.net Thu Jan 20 18:02:58 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 20 Jan 2022 18:02:58 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v5] In-Reply-To: <9nHf-iDivaY2uA-UZ4u0M_2pwvszEGwxh5TjJKhVXck=.63894eb0-dc08-47ac-b672-5b0d5e4a464a@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <9nHf-iDivaY2uA-UZ4u0M_2pwvszEGwxh5TjJKhVXck=.63894eb0-dc08-47ac-b672-5b0d5e4a464a@github.com> Message-ID: On Mon, 10 Jan 2022 21:09:15 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix grammar mistakes and did some small rephrases The `LazyObjectBindingTest` tests look good. I was thinking about adding a test that checks the `compyteValue` calls when a listener is attached (should increase) and when not attached (should not increase), but I think this behavior is already tested in `ObjectBinding` itself, so I'll leave it to you. modules/javafx.base/src/main/java/javafx/beans/value/LazyObjectBinding.java line 91: > 89: * > 90: * As the binding must be valid after it becomes observed the first time > 91: * 'get' is called again. Maybe add an `@link` to `ExpressionHelper` where the validation happens before listener registration, for clarity. modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java line 86: > 84: * valid because it is not yet considered "observed" as the > 85: * computeValue call occurs in the middle of the listener > 86: * registration process. I would add a link to `LazyObjectBinding#updateSubcriptionAfterAdd` where the 2nd call happens. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From nlisker at gmail.com Fri Jan 21 07:07:02 2022 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 21 Jan 2022 09:07:02 +0200 Subject: Unused members in JMemoryBuddy Message-ID: Hi, Looking at JMemoryBuddy, there are unused fields and methods. It's not clear if they were left in by mistake or are part of future work. * line 89: AssertCollectable assertCollectable = new AssertCollectable(weakReference); * line 237: the method setMxBeanProxyName * line 309: setAsReferenced The last one is part of the class SetAsReferenced, which is used in the memoryTest method's setAsReferenced, but the list it is added to is never read from. Could be that it just holds references so that they won't be collected. Are these needed? - Nir From sykora at openjdk.java.net Fri Jan 21 07:47:56 2022 From: sykora at openjdk.java.net (Joeri Sykora) Date: Fri, 21 Jan 2022 07:47:56 GMT Subject: [jfx18] RFR: 8280280: Update boot JDK to 17.0.2 In-Reply-To: <0kGa7SQdsmEK2nui5ZmZ55XGLJM9t-kAv5Axg1Xrwes=.f7123d56-d29e-4505-aa27-ae56c9e45c46@github.com> References: <0kGa7SQdsmEK2nui5ZmZ55XGLJM9t-kAv5Axg1Xrwes=.f7123d56-d29e-4505-aa27-ae56c9e45c46@github.com> Message-ID: On Wed, 19 Jan 2022 18:43:31 GMT, Kevin Rushforth wrote: > JDK 17.0.2 shipped yesterday as part of the January CPU release. We should update the JavaFX 18 build to use that version, so this is targeted for `jfx18`. Verified that builds and tests on all three platforms ran successfully. ------------- Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/721 From kcr at openjdk.java.net Fri Jan 21 14:54:53 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 21 Jan 2022 14:54:53 GMT Subject: [jfx18] Integrated: 8280280: Update boot JDK to 17.0.2 In-Reply-To: <0kGa7SQdsmEK2nui5ZmZ55XGLJM9t-kAv5Axg1Xrwes=.f7123d56-d29e-4505-aa27-ae56c9e45c46@github.com> References: <0kGa7SQdsmEK2nui5ZmZ55XGLJM9t-kAv5Axg1Xrwes=.f7123d56-d29e-4505-aa27-ae56c9e45c46@github.com> Message-ID: On Wed, 19 Jan 2022 18:43:31 GMT, Kevin Rushforth wrote: > JDK 17.0.2 shipped yesterday as part of the January CPU release. We should update the JavaFX 18 build to use that version, so this is targeted for `jfx18`. This pull request has now been integrated. Changeset: c47f18ef Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/c47f18effb4b959eb0f943095603d02f398e6fd2 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod 8280280: Update boot JDK to 17.0.2 Reviewed-by: arapte, sykora ------------- PR: https://git.openjdk.java.net/jfx/pull/721 From kcr at openjdk.java.net Fri Jan 21 16:09:54 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 21 Jan 2022 16:09:54 GMT Subject: Integrated: Merge jfx18 Message-ID: Merge `jfx18` into `master`. ------------- Commit messages: - Merge jfx18 - 8187307: ListView, TableView, TreeView: receives editCancel event when edit is committed - Merge - 8244234: MenuButton: NPE on removing from scene with open popup - 8279615: Change JavaFX release version to 19 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jfx/pull/722/files Stats: 294 lines in 13 files changed: 243 ins; 30 del; 21 mod Patch: https://git.openjdk.java.net/jfx/pull/722.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/722/head:pull/722 PR: https://git.openjdk.java.net/jfx/pull/722 From kcr at openjdk.java.net Fri Jan 21 16:09:54 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 21 Jan 2022 16:09:54 GMT Subject: Integrated: Merge jfx18 In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 16:03:04 GMT, Kevin Rushforth wrote: > Merge `jfx18` into `master`. This pull request has now been integrated. Changeset: 92b10aa1 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/92b10aa10bb2f446f97d38ec4297bc0d16b91803 Stats: 187 lines in 6 files changed: 174 ins; 1 del; 12 mod Merge ------------- PR: https://git.openjdk.java.net/jfx/pull/722 From nlisker at gmail.com Sat Jan 22 10:54:22 2022 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 22 Jan 2022 12:54:22 +0200 Subject: Unused members in JMemoryBuddy In-Reply-To: References: Message-ID: Got it, thanks. On Fri, Jan 21, 2022 at 11:08 AM Florian Kirmaier < florian.kirmaier at gmail.com> wrote: > Hi Nir Lisker, > > Yes, these are required. > Btw, here is the link to the project, which can be used independently of > OpenJFX: https://github.com/Sandec/JMemoryBuddy > > > * line 89: AssertCollectable assertCollectable = new > AssertCollectable(weakReference); > This is useful to find the reference, which was not collectible. You can > just search the heap for the class "AssertCollectable" and find the > troublemaker. This really speeds up debugging failing tests. > > > * line 237: the method setMxBeanProxyName > This was provided by someone to the original project. This makes it > possible to configure the "createHeapDump" method to work with different > JVMs. > > > * line 309: setAsReferenced > You are right, this is only used to make sure a certain reference will not > be collected. > This way, it's possible to define a set of objects which are referenced, > and then check whether certain objects are still collectible. > > Florian Kirmaier > > On Fri, 21 Jan 2022 at 08:07, Nir Lisker wrote: > >> Hi, >> >> Looking at JMemoryBuddy, there are unused fields and methods. It's not >> clear if they were left in by mistake or are part of future work. >> >> * line 89: AssertCollectable assertCollectable = new >> AssertCollectable(weakReference); >> * line 237: the method setMxBeanProxyName >> * line 309: setAsReferenced >> >> The last one is part of the class SetAsReferenced, which is used in the >> memoryTest method's setAsReferenced, but the list it is added to is never >> read from. Could be that it just holds references so that they won't be >> collected. >> >> Are these needed? >> >> - Nir >> > From swpalmer at gmail.com Sun Jan 23 04:10:07 2022 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 22 Jan 2022 23:10:07 -0500 Subject: WebView missing resource Message-ID: Is this an issue with WebView, my code, both? Exception in thread "JavaFX Application Thread" java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key blockedPluginByContentSecurityPolicyText at java.base/java.util.ResourceBundle.getObject(ResourceBundle.java:564) at java.base/java.util.ResourceBundle.getString(ResourceBundle.java:521) at javafx.web/com.sun.webkit.LocalizedStrings.getLocalizedProperty(LocalizedStrings.java:45) at javafx.web/com.sun.webkit.Timer.twkFireTimerEvent(Native Method) at javafx.web/com.sun.webkit.Timer.fireTimerEvent(Timer.java:84) at javafx.web/com.sun.webkit.Timer.notifyTick(Timer.java:65) at javafx.web/javafx.scene.web.WebEngine$PulseTimer.lambda$static$0(WebEngine.java:1205) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) at java.base/java.security.AccessController.doPrivileged(AccessController.java:399) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) I?m just testing out some WebView things in a new modular app on Java 17.0.1 (Azul?s Zulu build with JavaFX included). Noticing a lot of issues actually.. I?ll have to search the bug tracker to see if they are known. Regards, Scott From thiago.sayao at gmail.com Sun Jan 23 16:18:59 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Sun, 23 Jan 2022 13:18:59 -0300 Subject: Thank you for JavaFX Message-ID: Hi, Just wanted to share, the software on this pharmacy store has all it's frontend on JavaFX, including the self checkout, that doesn't look like a traditional desktop app yet uses pure JavaFX (customized with css). https://ndmais.com.br/saude/joinville-ganha-uma-farmacia-do-futuro-entenda/ Thank you. From kevin.rushforth at oracle.com Mon Jan 24 13:28:54 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 24 Jan 2022 05:28:54 -0800 Subject: WebView missing resource In-Reply-To: References: Message-ID: This is a bug in WebView. I ran into something similar a while back, but wasn't able to reproduce it, and didn't file a bug at that time. In looking at it, there are two problems. First, the getLocalizedProperty method should catch MissingResourceException and log a warning rather than letting the exception propagate. Second, there are a few missing property strings that should be added. I'll file both bugs. If you notice other issues, please file bugs for them (if not already filed). Thanks. -- Kevin On 1/22/2022 8:10 PM, Scott Palmer wrote: > Is this an issue with WebView, my code, both? > > Exception in thread "JavaFX Application Thread" java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key blockedPluginByContentSecurityPolicyText > at java.base/java.util.ResourceBundle.getObject(ResourceBundle.java:564) > at java.base/java.util.ResourceBundle.getString(ResourceBundle.java:521) > at javafx.web/com.sun.webkit.LocalizedStrings.getLocalizedProperty(LocalizedStrings.java:45) > at javafx.web/com.sun.webkit.Timer.twkFireTimerEvent(Native Method) > at javafx.web/com.sun.webkit.Timer.fireTimerEvent(Timer.java:84) > at javafx.web/com.sun.webkit.Timer.notifyTick(Timer.java:65) > at javafx.web/javafx.scene.web.WebEngine$PulseTimer.lambda$static$0(WebEngine.java:1205) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:399) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > I?m just testing out some WebView things in a new modular app on Java 17.0.1 (Azul?s Zulu build with JavaFX included). Noticing a lot of issues actually.. I?ll have to search the bug tracker to see if they are known. > > Regards, > > Scott From swpalmer at gmail.com Mon Jan 24 16:46:48 2022 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 24 Jan 2022 11:46:48 -0500 Subject: WebView missing resource In-Reply-To: References: Message-ID: <4948056C-A04F-4E1A-9FBD-87E7A872EE19@gmail.com> This one might cover some of the issues: https://bugs.openjdk.java.net/browse/JDK-8088781 but it doesn?t look like anyone is paying attention to it.. some of the issues in that seem to be gone now. In general I?m finding a lot of rendering glitches. Odd clipping, odd scaling, odd coordinates on polygons or borders. Pages that scale and shift drastically simply by resizing the WebView by a single pixel. I?m just using public web pages, so digging into what the page is actually doing is beyond what I have the time or resources to investigate, so the report will be rather vague. Having a bug report depend on a public webpage that may change before somebody gets around to looking into it also is less than ideal. I will give an example and attach screenshots just to capture what I?m seeing today. I?ve filed: https://bugs.openjdk.java.net/browse/JDK-8280529 Regards, Scott > On Jan 24, 2022, at 8:28 AM, Kevin Rushforth wrote: > > This is a bug in WebView. I ran into something similar a while back, but wasn't able to reproduce it, and didn't file a bug at that time. In looking at it, there are two problems. First, the getLocalizedProperty method should catch MissingResourceException and log a warning rather than letting the exception propagate. Second, there are a few missing property strings that should be added. I'll file both bugs. > > If you notice other issues, please file bugs for them (if not already filed). > > Thanks. > > -- Kevin > > > On 1/22/2022 8:10 PM, Scott Palmer wrote: >> Is this an issue with WebView, my code, both? >> >> Exception in thread "JavaFX Application Thread" java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key blockedPluginByContentSecurityPolicyText >> at java.base/java.util.ResourceBundle.getObject(ResourceBundle.java:564) >> at java.base/java.util.ResourceBundle.getString(ResourceBundle.java:521) >> at javafx.web/com.sun.webkit.LocalizedStrings.getLocalizedProperty(LocalizedStrings.java:45) >> at javafx.web/com.sun.webkit.Timer.twkFireTimerEvent(Native Method) >> at javafx.web/com.sun.webkit.Timer.fireTimerEvent(Timer.java:84) >> at javafx.web/com.sun.webkit.Timer.notifyTick(Timer.java:65) >> at javafx.web/javafx.scene.web.WebEngine$PulseTimer.lambda$static$0(WebEngine.java:1205) >> at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) >> at java.base/java.security.AccessController.doPrivileged(AccessController.java:399) >> at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) >> at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >> >> I?m just testing out some WebView things in a new modular app on Java 17.0.1 (Azul?s Zulu build with JavaFX included). Noticing a lot of issues actually.. I?ll have to search the bug tracker to see if they are known. >> >> Regards, >> >> Scott > From steve at weblite.ca Mon Jan 24 17:48:39 2022 From: steve at weblite.ca (Steve Hannah) Date: Mon, 24 Jan 2022 09:48:39 -0800 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: References: Message-ID: I just wanted to follow up with this in case someone comes across this thread later. After thoroughly exploring the landscape, I found that the issue on Ubuntu was caused by a conflict between the webkit2gtk-4.0 library (which I was using to show a progress dialog in the case that the JRE or app needs to download an update). Additionally it seemed to have a problem with just the general gtk+-3.0 dependency, if GTK was initialized before JavaFX was loaded. I worked around the gtk+-3.0 issue by breaking the GTK stuff into a separate process (calling itself with different args). This workaround was not sufficient to resolve the webkit2gtk-4.0 conflict as, even if it wasn't used at runtime, it would still conflict with JavaFX's webview - resulting in a segfault. The only solution was to remove the webkit2gtk-4.0 dependency entirely from my app, and do the progress dialog differently (I ended up just using basic GTK widgets). Best regards Steve On Wed, Jan 19, 2022 at 9:40 AM Steve Hannah wrote: > The following issue only seems to occur on Linux (Ubuntu 20.04.1), and > only when I try to launch the JVM from a custom C launcher using JNI. It > does not occur when launching the JVM as a separate process using the > "java" binary. It also does not occur on MacOS when using the same C > launcher using JNI. > > When I call MyApplication.launch(args). (where MyApplication extends the > JavaFX Application class), I get the following stack trace: > > Jan. 19, 2022 8:54:27 A.M. com.sun.javafx.application.PlatformImpl startup > Exception in thread "Thread-5" java.lang.IllegalStateException: This operation is permitted on the event thread only; currentThread = Thread-5 > at com.sun.glass.ui.Application.checkEventThread(Application.java:447) > at com.sun.glass.ui.Application.setName(Application.java:200) > at com.sun.javafx.application.PlatformImpl.lambda$setApplicationName$2(PlatformImpl.java:142) > at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > Exception in Application start method > Exception in thread "Thread-31" Failed to show docs > java.lang.IllegalStateException: Not on FX application thread; currentThread = Thread-31 > at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) > at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) > at com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:828) > at com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:624) > at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) > at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > java.lang.RuntimeException: Exception in Application start method > at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901) > at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196) > at java.base/java.lang.Thread.run(Thread.java:829) > Caused by: java.lang.IllegalStateException: Not on FX application thread; currentThread = Thread-6 > at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) > at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) > at javafx.stage.Stage.(Stage.java:254) > at javafx.stage.Stage.(Stage.java:240) > at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:845) > at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) > at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > > I have tried a few different versions of JavaFX (11, 11.0.2, 17.0.1), > running on a few different JDK installs (all JDK11). Above stacktrace is > from 17.0.1. > > From the C application that launches the JVM, I have tried running > directly on the main thread, and also launching it in a fresh thread using > pthreads - but same issue. I am running this inside an application written > in Go but the JNI code is all in C. > > It appears as though JavaFX is unable to create its application thread for > some reason. Does anyone have any suggestions on reasons why this would be > the case? Are there some system properties that need to be there which > would have been bootstrapped by the "java" binary, but would not when the > JVM is launched via JNI? > > Any suggestions appreciated. I've been banging my head on this for a > while now. > > Best regards > > Steve > -- Steve Hannah Web Lite Solutions Corp. From kcr at openjdk.java.net Tue Jan 25 01:20:44 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 25 Jan 2022 01:20:44 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses In-Reply-To: References: Message-ID: On Sun, 16 Jan 2022 22:54:22 GMT, Nir Lisker wrote: > Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: > > * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. > * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. > * Added examples of real-world applications for each light type. > * Consolidated the writing style for all the subclasses. I'll need a second pass over this to look at the generated docs, but what I did read looks good. I left a few inline comments. modules/javafx.graphics/src/main/java/javafx/scene/AmbientLight.java line 37: > 35: *

> 36: * {@code AmbientLight}s can represent strong light sources in an enclosed area where the lights bounces from many > 37: * objects, causing them to be illuminated from many directions. A strong light in a room and moonlight are common light > A strong light in a room ... I think this is OK, as long as a reader doesn't think of an overhead light in a room, which also has the properties of a point light. modules/javafx.graphics/src/main/java/javafx/scene/DirectionalLight.java line 2: > 1: /* > 2: * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. Normally we do not change the start year, however it's OK in this case, since it is correcting an earlier mistake. modules/javafx.graphics/src/main/java/javafx/scene/LightBase.java line 69: > 67: * In addition to these, each light type supports a different set of properties, summarized in the following table: > 68: * > 69: *

I think the table itself would be better if it were not centered (the columns are fine centered). modules/javafx.graphics/src/main/java/javafx/scene/LightBase.java line 78: > 76: * > 77: * > 78: * {@link AmbientLight} In order to avoid introducing accessibility issues, tables need to have column and row headers with `scope="col"` or `scope="row"` as appropriate. See [JDK-8184223](https://bugs.openjdk.java.net/browse/JDK-8184223) for more details. modules/javafx.graphics/src/main/java/javafx/scene/LightBase.java line 119: > 117: *
  • The transparency (alpha) component of a light is ignored. > 118: * > 119: * There are no guarantee that these behaviors will not change. This is a new specification of behavior rather than a doc reorganization or clarification of an existing note. As such, I think it should be done separately and with a CSR. modules/javafx.graphics/src/main/java/javafx/scene/LightBase.java line 401: > 399: if (node instanceof Shape3D) { > 400: // Dirty using a lightweight DirtyBits.NODE_DRAWMODE bit > 401: NodeHelper.markDirty(node, DirtyBits.NODE_DRAWMODE); I realize that this is an unnecessary cast, but since this is a doc-only change and we are in rampdown for jfx18, it would be best to revert this change. modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 2: > 1: /* > 2: * Copyright (c) 2021, 2022, Oracle and/or its affiliates. All rights reserved. Normally we do not change the start year, however it's OK in this case, since it is correcting an earlier mistake. ------------- PR: https://git.openjdk.java.net/jfx/pull/717 From kcr at openjdk.java.net Tue Jan 25 01:25:05 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 25 Jan 2022 01:25:05 GMT Subject: [jfx17u] RFR: 8280490: Change JavaFX release version in jfx17u to 17.0.3 Message-ID: Bump release version in `jfx17u` repo to 17.0.3 for the start of a new release. ------------- Commit messages: - 8280490: Change JavaFX release version in jfx17u to 17.0.3 Changes: https://git.openjdk.java.net/jfx17u/pull/29/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=29&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280490 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx17u/pull/29.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/29/head:pull/29 PR: https://git.openjdk.java.net/jfx17u/pull/29 From kcr at openjdk.java.net Tue Jan 25 01:25:09 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 25 Jan 2022 01:25:09 GMT Subject: [jfx11u] RFR: 8280489: Change JavaFX release version in jfx11u to 11.0.15 Message-ID: <0SnZzYbBkA0j-rM1OEKBmzMdboSslVrKa7-uf2IRQbg=.4987ed19-7179-4149-9ac9-590d4dba8431@github.com> Bump release version in `jfx11u` repo to 11.0.15 for the start of a new release. ------------- Commit messages: - 8280489: Change JavaFX release version in jfx11u to 11.0.15 Changes: https://git.openjdk.java.net/jfx11u/pull/69/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=69&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280489 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx11u/pull/69.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/69/head:pull/69 PR: https://git.openjdk.java.net/jfx11u/pull/69 From duke at openjdk.java.net Tue Jan 25 07:54:21 2022 From: duke at openjdk.java.net (meghanEmbrace) Date: Tue, 25 Jan 2022 07:54:21 GMT Subject: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning [v2] In-Reply-To: References: Message-ID: > With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. meghanEmbrace has updated the pull request incrementally with one additional commit since the last revision: Added requested automated test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/688/files - new: https://git.openjdk.java.net/jfx/pull/688/files/990a3dce..4a7fdae6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=688&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=688&range=00-01 Stats: 30 lines in 1 file changed: 30 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/688.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/688/head:pull/688 PR: https://git.openjdk.java.net/jfx/pull/688 From duke at openjdk.java.net Tue Jan 25 08:02:41 2022 From: duke at openjdk.java.net (meghanEmbrace) Date: Tue, 25 Jan 2022 08:02:41 GMT Subject: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 07:54:21 GMT, meghanEmbrace wrote: >> With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. > > meghanEmbrace has updated the pull request incrementally with one additional commit since the last revision: > > Added requested automated test Added requested automated test. ------------- PR: https://git.openjdk.java.net/jfx/pull/688 From arapte at openjdk.java.net Tue Jan 25 09:19:44 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 25 Jan 2022 09:19:44 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 00:40:18 GMT, Kevin Rushforth wrote: >> Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: >> >> * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. >> * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. >> * Added examples of real-world applications for each light type. >> * Consolidated the writing style for all the subclasses. > > modules/javafx.graphics/src/main/java/javafx/scene/AmbientLight.java line 37: > >> 35: *

    >> 36: * {@code AmbientLight}s can represent strong light sources in an enclosed area where the lights bounces from many >> 37: * objects, causing them to be illuminated from many directions. A strong light in a room and moonlight are common light > >> A strong light in a room ... > > I think this is OK, as long as a reader doesn't think of an overhead light in a room, which also has the properties of a point light. Ambient light is a light that comes from all directions, scattered from different surfaces and it does not cast shadow. So I think the example of strong light and moon light should be avoided. Moon light is more like the Sun light, a directional light. ------------- PR: https://git.openjdk.java.net/jfx/pull/717 From arapte at openjdk.java.net Tue Jan 25 09:19:45 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 25 Jan 2022 09:19:45 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses In-Reply-To: References: Message-ID: On Sun, 16 Jan 2022 22:54:22 GMT, Nir Lisker wrote: > Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: > > * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. > * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. > * Added examples of real-world applications for each light type. > * Consolidated the writing style for all the subclasses. modules/javafx.graphics/src/main/java/javafx/scene/DirectionalLight.java line 46: > 44: * {@code DirectionalLight}s can represent strong light sources that are far enough from the objects they illuminate > 45: * that their light rays appear to be parallel. Because these light sources are considered to be infinitely far, they > 46: * cannot be attenuated. The sun's light on Earth is a common light source that can be simulated with this light type. The previous statement seems more suitable here: `The Sun is a common light source that can be simulated with this light type.` or little modified version of this new statement: `The Sun light on Earth is a common type of light that can be simulated with this light type.` modules/javafx.graphics/src/main/java/javafx/scene/LightBase.java line 133: > 131: * > 132: *

    Direction

    > 133: * The direction the light is facing, defined by the {@code direction} vector property of the light. The light's The direction of the light is defined by the {@code direction} vector property of the light ------------- PR: https://git.openjdk.java.net/jfx/pull/717 From fastegal at openjdk.java.net Tue Jan 25 12:15:34 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 25 Jan 2022 12:15:34 GMT Subject: RFR: 8251481: TableCell accessing row: NPE on auto-sizing In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 00:04:49 GMT, Marius Hanl wrote: > This PR will fix a simple NPE which may happens when using the `TableRow` inside a `TableCell` during the initial auto sizing. > In the auto sizing code, no `TableRow` is set, therefore `getTableRow()` will return null and it is not possible to e.g. access the row item. > > This is fixed by adding the `TableRow` in the `resizeColumnToFitContent` method, similar as it is already done for the `TreeTableView` (`TreeTableRow`). fix looks good: verified that the bug example doesn't throw after the fix, also that the test failed/passed before/after the fix left a couple of inline comments for the test modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 371: > 369: @Test > 370: public void testRowIsNotNullWhenAutoSizing() { > 371: TableColumn tableColumn = new TableColumn<>(); - the bug that's fixed in this PR is in TableColumnHeader, shouldn't the test be in TableColumnHeaderTest? - if you decide to keep it here: it's in the middle of some edit-related tests, you might consider moving it up/down before/after those - the fix aligns the resizeToFit method for TableView with that for TreeTableView: for symmetry, I would also expect a test method for the latter (which will pass both before and after the fix) modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 379: > 377: > 378: assertNotNull(getTableRow()); > 379: } feeling slightly uncomfortable with the generality of this: looks a bit like it's guaranteed that tableRow != null always (bullet 2 of our previous conversation) - would suggest to make it more specific to auto-sizing (f.i. start without auto-size, then trigger autosizing by code). Or at least doc it (add a message to the assertion, add the bug id) so that future readers will know what exactly is tested here :) modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 385: > 383: StageLoader loader = new StageLoader(table); > 384: > 385: loader.dispose(); note that the loader isn't disposed if the test fails - that's why there's an instance field (which will be disposed in cleanup), which should be used here ------------- Changes requested by fastegal (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/716 From kcr at openjdk.java.net Tue Jan 25 13:05:41 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 25 Jan 2022 13:05:41 GMT Subject: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning [v2] In-Reply-To: References: Message-ID: <7V5lHyV-3lrUO2WV5dJ0WjKJz1gJiABZF0ShVBCqeds=.1833ff29-1e0c-44e5-84dc-ae46f1e35517@github.com> On Tue, 25 Jan 2022 07:54:21 GMT, meghanEmbrace wrote: >> With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. > > meghanEmbrace has updated the pull request incrementally with one additional commit since the last revision: > > Added requested automated test The test looks good with one comment about replacing the null test with an assert. modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 820: > 818: > 819: ScrollBar horizontalBar = VirtualFlowTestUtils.getVirtualFlowHorizontalScrollbar(table); > 820: if (horizontalBar != null) { Won't `horizontalBar` always be non-null (else the test won't test anything)? I recommend removing this `if` test, and instead `assertNotNull(horizontalBar);`. ------------- PR: https://git.openjdk.java.net/jfx/pull/688 From jvos at openjdk.java.net Tue Jan 25 13:50:45 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 25 Jan 2022 13:50:45 GMT Subject: [jfx17u] RFR: 8280490: Change JavaFX release version in jfx17u to 17.0.3 In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 01:19:11 GMT, Kevin Rushforth wrote: > Bump release version in `jfx17u` repo to 17.0.3 for the start of a new release. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx17u/pull/29 From jvos at openjdk.java.net Tue Jan 25 13:50:45 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 25 Jan 2022 13:50:45 GMT Subject: [jfx11u] RFR: 8280489: Change JavaFX release version in jfx11u to 11.0.15 In-Reply-To: <0SnZzYbBkA0j-rM1OEKBmzMdboSslVrKa7-uf2IRQbg=.4987ed19-7179-4149-9ac9-590d4dba8431@github.com> References: <0SnZzYbBkA0j-rM1OEKBmzMdboSslVrKa7-uf2IRQbg=.4987ed19-7179-4149-9ac9-590d4dba8431@github.com> Message-ID: On Tue, 25 Jan 2022 01:20:04 GMT, Kevin Rushforth wrote: > Bump release version in `jfx11u` repo to 11.0.15 for the start of a new release. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/69 From fastegal at openjdk.java.net Tue Jan 25 13:52:38 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 25 Jan 2022 13:52:38 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout [v2] In-Reply-To: <_grncaimIi3UGlnE44XBdS9hIQYAVlOGOpcXErtg-nA=.cce76737-295b-48fa-b8a9-17e39d7cfa70@github.com> References: <_grncaimIi3UGlnE44XBdS9hIQYAVlOGOpcXErtg-nA=.cce76737-295b-48fa-b8a9-17e39d7cfa70@github.com> Message-ID: On Mon, 22 Nov 2021 14:03:56 GMT, Marius Hanl wrote: >> When a divider is moved via drag or code it will call **requestLayout()** for the **SplitPane**. >> While this is fine, it is also called when the **SplitPaneSkin#layoutChildren(..)** method is repositioning the divider. >> >> This makes no sense since we are currently layouting everything, so we don't need to request it again. (The divider positioning is the first part of **layoutChildren(..)**. In the second part the SplitPane content is layouted based off those positions) >> >> -> With this behaviour the layout may hang under some conditions (check attached source). The problem is that the **requestLayout()** will mark the **SplitPane** dirty but won't propagate to the parent since the **SplitPane** is currently doing a layout. >> >> This PR fixes this by not requesting layout when we are currently doing it (and thus repositioning the dividers as part of it). >> >> Note: I also fixed a simple typo of a private method in SplitPaneSkin: >> initializeDivderEventHandlers -> initializeDiv**i**derEventHandlers > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8277122: Added test for setting a negative divider position + improved readability fix looks good (though it _feels_ a bit upside down that it is needed ;) - verified example/tests failing/passing before/after fixing left minor inline comments (just to make it easier to understand :) modules/javafx.controls/src/main/java/javafx/scene/control/skin/SplitPaneSkin.java line 72: > 70: * {@link #layoutChildren(double, double, double, double)} since we are currently doing the layout. > 71: */ > 72: private boolean duringLayout; would like a reference to the bug this fixes modules/javafx.controls/src/main/java/javafx/scene/control/skin/SplitPaneSkin.java line 226: > 224: // If the window is less than the min size we want to resize proportionally > 225: duringLayout = true; > 226: double minSize = totalMinSize(); - setting the flag belongs above the code comment to not disrupt explanation and its target (== minsize) - I think we don't do formatting (here: change the code comment to a single line) modules/javafx.controls/src/test/java/test/javafx/scene/control/SplitPaneTest.java line 1344: > 1342: * which can hang the layout as it resulted in multiple layout requests (through SplitPaneSkin.layoutChildren). > 1343: */ > 1344: @Test My preference would be to add the bug id to the tests as well .. modules/javafx.controls/src/test/java/test/javafx/scene/control/SplitPaneTest.java line 1387: > 1385: assertTrue(layoutCounter.get() > 0); > 1386: stageLoader.dispose(); > 1387: } the stageLoader is not disposed if the test fails - a (recently introduced :) general pattern is to use an instance field that's disposed in the test cleanup ------------- Changes requested by fastegal (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/669 From duke at openjdk.java.net Tue Jan 25 14:34:09 2022 From: duke at openjdk.java.net (meghanEmbrace) Date: Tue, 25 Jan 2022 14:34:09 GMT Subject: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning [v3] In-Reply-To: References: Message-ID: > With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. meghanEmbrace has updated the pull request incrementally with one additional commit since the last revision: Replaced the null test with an assert. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/688/files - new: https://git.openjdk.java.net/jfx/pull/688/files/4a7fdae6..b3e29d70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=688&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=688&range=01-02 Stats: 12 lines in 1 file changed: 5 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/688.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/688/head:pull/688 PR: https://git.openjdk.java.net/jfx/pull/688 From duke at openjdk.java.net Tue Jan 25 14:36:32 2022 From: duke at openjdk.java.net (meghanEmbrace) Date: Tue, 25 Jan 2022 14:36:32 GMT Subject: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 07:54:21 GMT, meghanEmbrace wrote: >> With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. > > meghanEmbrace has updated the pull request incrementally with one additional commit since the last revision: > > Added requested automated test Replaced the null test with an assert. Thanks. ------------- PR: https://git.openjdk.java.net/jfx/pull/688 From kcr at openjdk.java.net Tue Jan 25 15:25:34 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 25 Jan 2022 15:25:34 GMT Subject: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning [v3] In-Reply-To: References: Message-ID: <_FCLozQ9fmMbhFbKhv7Yew0-6gtY5s92UZkYj_1gSiI=.54248356-7e21-412d-bf5f-6376d3f08476@github.com> On Tue, 25 Jan 2022 14:34:09 GMT, meghanEmbrace wrote: >> With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. > > meghanEmbrace has updated the pull request incrementally with one additional commit since the last revision: > > Replaced the null test with an assert. The updated test looks good. I verified that the new test fails without the fix and passes with the fix. This is a simple enough fix that it doesn't need a second reviewer. I can sponsor it once you integrate it. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/688 From mhanl at openjdk.java.net Tue Jan 25 15:25:35 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 25 Jan 2022 15:25:35 GMT Subject: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning [v3] In-Reply-To: References: Message-ID: <_QLDu-_f-ewhiY5MiYCDFurOzfqy3iBz8qoInqXB6Ko=.247e2c49-a778-4c97-8135-7df915858c14@github.com> On Tue, 25 Jan 2022 14:34:09 GMT, meghanEmbrace wrote: >> With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. > > meghanEmbrace has updated the pull request incrementally with one additional commit since the last revision: > > Replaced the null test with an assert. modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 801: > 799: * Tests for specific bugs * > 800: ********************************************************************/ > 801: @Test public void test_jdk_8277853() { Not sure if there is some preference around here but I always like if the test method is not just named after the ticket but instead what it actually tests, e.g. something like `testInvisibleScrollbarDoesNotScrollTableToBeginning`. Optionally the ticket number can be referenced in the javadoc then. But that's just me (just a side note here). ------------- PR: https://git.openjdk.java.net/jfx/pull/688 From kcr at openjdk.java.net Tue Jan 25 15:25:35 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 25 Jan 2022 15:25:35 GMT Subject: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning [v3] In-Reply-To: <_QLDu-_f-ewhiY5MiYCDFurOzfqy3iBz8qoInqXB6Ko=.247e2c49-a778-4c97-8135-7df915858c14@github.com> References: <_QLDu-_f-ewhiY5MiYCDFurOzfqy3iBz8qoInqXB6Ko=.247e2c49-a778-4c97-8135-7df915858c14@github.com> Message-ID: <3iwN0vDsIxlJ8GvddTPV1m0v66uQmT1sgcWEfbM0vf8=.95f8b13c-ecb9-46d4-ae51-15db8ed6893a@github.com> On Tue, 25 Jan 2022 15:19:44 GMT, Marius Hanl wrote: >> meghanEmbrace has updated the pull request incrementally with one additional commit since the last revision: >> >> Replaced the null test with an assert. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 801: > >> 799: * Tests for specific bugs * >> 800: ********************************************************************/ >> 801: @Test public void test_jdk_8277853() { > > Not sure if there is some preference around here but I always like if the test method is not just named after the ticket but instead what it actually tests, e.g. something like `testInvisibleScrollbarDoesNotScrollTableToBeginning`. Optionally the ticket number can be referenced in the javadoc then. But that's just me (just a side note here). I almost made the same comment as you did. In general we no longer use the pattern of putting the bug ID in the test name. In this case all of the surrounding tests do that, so I decided not to mention it, but I am perfectly happy for the test name to be changed to reflect its function (with the bug ID in a comment). ------------- PR: https://git.openjdk.java.net/jfx/pull/688 From kcr at openjdk.java.net Tue Jan 25 17:31:38 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 25 Jan 2022 17:31:38 GMT Subject: [jfx11u] Integrated: 8280489: Change JavaFX release version in jfx11u to 11.0.15 In-Reply-To: <0SnZzYbBkA0j-rM1OEKBmzMdboSslVrKa7-uf2IRQbg=.4987ed19-7179-4149-9ac9-590d4dba8431@github.com> References: <0SnZzYbBkA0j-rM1OEKBmzMdboSslVrKa7-uf2IRQbg=.4987ed19-7179-4149-9ac9-590d4dba8431@github.com> Message-ID: On Tue, 25 Jan 2022 01:20:04 GMT, Kevin Rushforth wrote: > Bump release version in `jfx11u` repo to 11.0.15 for the start of a new release. This pull request has now been integrated. Changeset: cb0314b6 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/cb0314b6551229360771fea7697e97a6f25eeafd Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8280489: Change JavaFX release version in jfx11u to 11.0.15 Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx11u/pull/69 From kcr at openjdk.java.net Tue Jan 25 17:32:42 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 25 Jan 2022 17:32:42 GMT Subject: [jfx17u] Integrated: 8280490: Change JavaFX release version in jfx17u to 17.0.3 In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 01:19:11 GMT, Kevin Rushforth wrote: > Bump release version in `jfx17u` repo to 17.0.3 for the start of a new release. This pull request has now been integrated. Changeset: d4973293 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/d49732938159dd969a1dec7d4ad7f09fca81fc65 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8280490: Change JavaFX release version in jfx17u to 17.0.3 Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx17u/pull/29 From tsayao at openjdk.java.net Tue Jan 25 17:55:09 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 25 Jan 2022 17:55:09 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v8] In-Reply-To: References: Message-ID: > Found the problem thru this path: > > **WindowStage.java** > > final void handleFocusDisabled() { > if (activeWindows.isEmpty()) { > return; > } > WindowStage window = activeWindows.get(activeWindows.size() - 1); > window.setIconified(false); > window.requestToFront(); > window.requestFocus(); > } > > > **glass_window.cpp** > > void WindowContextBase::process_focus(GdkEventFocus* event) { > ... > > if (jwindow) { > if (!event->in || isEnabled()) { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, > event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); > CHECK_JNI_EXCEPTION(mainEnv) > } else { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); > CHECK_JNI_EXCEPTION(mainEnv) > } > } > } > > > So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). > > The docs states: > > /** > * Enables or disables the window. > * > * A disabled window is unfocusable by definition. > * Also, key or mouse events aren't generated for disabled windows. > * > * When a user tries to activate a disabled window, or the window gets > * accidentally brought to the top of the stacking order, the window > * generates the FOCUS_DISABLED window event. A Glass client should react > * to this event and bring the currently active modal blocker of the > * disabled window to top by calling blocker's minimize(false), toFront(), > * and requestFocus() methods. It may also 'blink' the blocker window to > * further attract user's attention. > * > ..... > > > So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. > > The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Another approach. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/598/files - new: https://git.openjdk.java.net/jfx/pull/598/files/196cecfe..8630c557 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=06-07 Stats: 22 lines in 3 files changed: 12 ins; 7 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/598.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598 PR: https://git.openjdk.java.net/jfx/pull/598 From duke at openjdk.java.net Tue Jan 25 23:45:42 2022 From: duke at openjdk.java.net (Paul) Date: Tue, 25 Jan 2022 23:45:42 GMT Subject: RFR: 8279013 : ES2Pipeline fails to detect AMD vega20 graphics card Message-ID: I have an AMD Radeon VII (vega20) series GPU which is identifying with a vendor string of "AMD". This is not present in the `X11GLFactory` list of `preQualificationFilter` vendor names, so my system (and probably any other vega20 based cards under Linux) will always fall back to software rendering. This adds the "amd" string to the `preQualificationFilter` list. ------------- Commit messages: - Adds support for AMD graphics cards that identify themselves with "AMD" vendor strings. Changes: https://git.openjdk.java.net/jfx/pull/698/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=698&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279013 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/698.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/698/head:pull/698 PR: https://git.openjdk.java.net/jfx/pull/698 From duke at openjdk.java.net Tue Jan 25 23:45:42 2022 From: duke at openjdk.java.net (Paul) Date: Tue, 25 Jan 2022 23:45:42 GMT Subject: RFR: 8279013 : ES2Pipeline fails to detect AMD vega20 graphics card In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 17:48:19 GMT, Paul wrote: > I have an AMD Radeon VII (vega20) series GPU which is identifying with a vendor string of "AMD". > > This is not present in the `X11GLFactory` list of `preQualificationFilter` vendor names, so my system (and probably any other vega20 based cards under Linux) will always fall back to software rendering. > > This adds the "amd" string to the `preQualificationFilter` list. Just as a side note, I signed the OCA last year when I was doing some work with the Helidon project. I thought it was one OCA for all things Oracle? Hi. I'm just wondering if there is anything else I need to do for the OCA? It's been 4 weeks now, so even taking into account the holidays, I'm wondering if this request has fallen through the cracks? Thanks ------------- PR: https://git.openjdk.java.net/jfx/pull/698 From kcr at openjdk.java.net Tue Jan 25 23:45:42 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 25 Jan 2022 23:45:42 GMT Subject: RFR: 8279013 : ES2Pipeline fails to detect AMD vega20 graphics card In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 08:09:08 GMT, Paul wrote: > I thought it was one OCA for all things Oracle? It is. There is a manual step to verify the connection between a user's GitHub account and their OCA, but it ordinarily happens quickly. Given that we are close to the holidays, there may be a longer delay than usual. ------------- PR: https://git.openjdk.java.net/jfx/pull/698 From duke at openjdk.java.net Tue Jan 25 23:45:43 2022 From: duke at openjdk.java.net (Paul) Date: Tue, 25 Jan 2022 23:45:43 GMT Subject: RFR: 8279013 : ES2Pipeline fails to detect AMD vega20 graphics card In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 08:09:08 GMT, Paul wrote: > ... I signed the OCA **last year** ... Added some emphasis. Hope I get a year off for Christmas next year! ;-) ------------- PR: https://git.openjdk.java.net/jfx/pull/698 From jvos at openjdk.java.net Tue Jan 25 23:45:43 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 25 Jan 2022 23:45:43 GMT Subject: RFR: 8279013 : ES2Pipeline fails to detect AMD vega20 graphics card In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 17:48:19 GMT, Paul wrote: > I have an AMD Radeon VII (vega20) series GPU which is identifying with a vendor string of "AMD". > > This is not present in the `X11GLFactory` list of `preQualificationFilter` vendor names, so my system (and probably any other vega20 based cards under Linux) will always fall back to software rendering. > > This adds the "amd" string to the `preQualificationFilter` list. I agree this would be a good and easy fix. Since there is an easy fallback to sw-rendering, this issue might impact more runtime environments than we are aware of. @kevinrushforth is there anything we can do to check the OCA status? ------------- PR: https://git.openjdk.java.net/jfx/pull/698 From kcr at openjdk.java.net Tue Jan 25 23:45:43 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 25 Jan 2022 23:45:43 GMT Subject: RFR: 8279013 : ES2Pipeline fails to detect AMD vega20 graphics card In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 17:48:19 GMT, Paul wrote: > I have an AMD Radeon VII (vega20) series GPU which is identifying with a vendor string of "AMD". > > This is not present in the `X11GLFactory` list of `preQualificationFilter` vendor names, so my system (and probably any other vega20 based cards under Linux) will always fall back to software rendering. > > This adds the "amd" string to the `preQualificationFilter` list. I'll check into this. ------------- PR: https://git.openjdk.java.net/jfx/pull/698 From kcr at openjdk.java.net Tue Jan 25 23:50:38 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 25 Jan 2022 23:50:38 GMT Subject: RFR: 8279013 : ES2Pipeline fails to detect AMD vega20 graphics card In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 17:48:19 GMT, Paul wrote: > I have an AMD Radeon VII (vega20) series GPU which is identifying with a vendor string of "AMD". > > This is not present in the `X11GLFactory` list of `preQualificationFilter` vendor names, so my system (and probably any other vega20 based cards under Linux) will always fall back to software rendering. > > This adds the "amd" string to the `preQualificationFilter` list. Looks good to me, too. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/698 From tsayao at openjdk.java.net Tue Jan 25 23:57:09 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 25 Jan 2022 23:57:09 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v9] In-Reply-To: References: Message-ID: > Found the problem thru this path: > > **WindowStage.java** > > final void handleFocusDisabled() { > if (activeWindows.isEmpty()) { > return; > } > WindowStage window = activeWindows.get(activeWindows.size() - 1); > window.setIconified(false); > window.requestToFront(); > window.requestFocus(); > } > > > **glass_window.cpp** > > void WindowContextBase::process_focus(GdkEventFocus* event) { > ... > > if (jwindow) { > if (!event->in || isEnabled()) { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, > event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); > CHECK_JNI_EXCEPTION(mainEnv) > } else { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); > CHECK_JNI_EXCEPTION(mainEnv) > } > } > } > > > So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). > > The docs states: > > /** > * Enables or disables the window. > * > * A disabled window is unfocusable by definition. > * Also, key or mouse events aren't generated for disabled windows. > * > * When a user tries to activate a disabled window, or the window gets > * accidentally brought to the top of the stacking order, the window > * generates the FOCUS_DISABLED window event. A Glass client should react > * to this event and bring the currently active modal blocker of the > * disabled window to top by calling blocker's minimize(false), toFront(), > * and requestFocus() methods. It may also 'blink' the blocker window to > * further attract user's attention. > * > ..... > > > So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. > > The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Capture event serial on process_key ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/598/files - new: https://git.openjdk.java.net/jfx/pull/598/files/8630c557..ee8ab1e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=07-08 Stats: 7 lines in 2 files changed: 6 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/598.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598 PR: https://git.openjdk.java.net/jfx/pull/598 From duke at openjdk.java.net Wed Jan 26 00:04:39 2022 From: duke at openjdk.java.net (Paul) Date: Wed, 26 Jan 2022 00:04:39 GMT Subject: Integrated: 8279013 : ES2Pipeline fails to detect AMD vega20 graphics card In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 17:48:19 GMT, Paul wrote: > I have an AMD Radeon VII (vega20) series GPU which is identifying with a vendor string of "AMD". > > This is not present in the `X11GLFactory` list of `preQualificationFilter` vendor names, so my system (and probably any other vega20 based cards under Linux) will always fall back to software rendering. > > This adds the "amd" string to the `preQualificationFilter` list. This pull request has now been integrated. Changeset: ae334c56 Author: Paul Court Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/ae334c56687ad81cb3963f2529f93144586dd750 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8279013: ES2Pipeline fails to detect AMD vega20 graphics card Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/698 From duke at openjdk.java.net Wed Jan 26 05:36:07 2022 From: duke at openjdk.java.net (meghanEmbrace) Date: Wed, 26 Jan 2022 05:36:07 GMT Subject: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning [v4] In-Reply-To: References: Message-ID: <1PGClv3IDKoxTzREjXyS0mFj_IQ61he-UKXFjWQz_7E=.ec69a4e1-0f86-42a1-91ea-5409232420a0@github.com> > With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. meghanEmbrace has updated the pull request incrementally with one additional commit since the last revision: Updated test name to be more descriptive. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/688/files - new: https://git.openjdk.java.net/jfx/pull/688/files/b3e29d70..f4232678 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=688&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=688&range=02-03 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/688.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/688/head:pull/688 PR: https://git.openjdk.java.net/jfx/pull/688 From duke at openjdk.java.net Wed Jan 26 05:36:10 2022 From: duke at openjdk.java.net (meghanEmbrace) Date: Wed, 26 Jan 2022 05:36:10 GMT Subject: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning [v3] In-Reply-To: References: Message-ID: <06hMqswyL-My-tkUrwtrS00cduziW__HxJin-bzY7_w=.1c72ecf0-8a12-45e6-a7e4-4626eadbbd90@github.com> On Tue, 25 Jan 2022 14:34:09 GMT, meghanEmbrace wrote: >> With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. > > meghanEmbrace has updated the pull request incrementally with one additional commit since the last revision: > > Replaced the null test with an assert. Updated test name to be more descriptive. ------------- PR: https://git.openjdk.java.net/jfx/pull/688 From kcr at openjdk.java.net Wed Jan 26 12:56:34 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 26 Jan 2022 12:56:34 GMT Subject: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning [v4] In-Reply-To: <1PGClv3IDKoxTzREjXyS0mFj_IQ61he-UKXFjWQz_7E=.ec69a4e1-0f86-42a1-91ea-5409232420a0@github.com> References: <1PGClv3IDKoxTzREjXyS0mFj_IQ61he-UKXFjWQz_7E=.ec69a4e1-0f86-42a1-91ea-5409232420a0@github.com> Message-ID: <-r13bPYy-vFKa7iWBx1ylf0D7ZRzddALs1L_0_n5MRs=.2516127d-1def-42f0-8cdf-aa3531514f84@github.com> On Wed, 26 Jan 2022 05:36:07 GMT, meghanEmbrace wrote: >> With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. > > meghanEmbrace has updated the pull request incrementally with one additional commit since the last revision: > > Updated test name to be more descriptive. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/688 From kcr at openjdk.java.net Wed Jan 26 13:03:36 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 26 Jan 2022 13:03:36 GMT Subject: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning [v4] In-Reply-To: <1PGClv3IDKoxTzREjXyS0mFj_IQ61he-UKXFjWQz_7E=.ec69a4e1-0f86-42a1-91ea-5409232420a0@github.com> References: <1PGClv3IDKoxTzREjXyS0mFj_IQ61he-UKXFjWQz_7E=.ec69a4e1-0f86-42a1-91ea-5409232420a0@github.com> Message-ID: On Wed, 26 Jan 2022 05:36:07 GMT, meghanEmbrace wrote: >> With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. > > meghanEmbrace has updated the pull request incrementally with one additional commit since the last revision: > > Updated test name to be more descriptive. This is now ready to be integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/688 From mhanl at openjdk.java.net Wed Jan 26 15:33:41 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 26 Jan 2022 15:33:41 GMT Subject: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning [v4] In-Reply-To: <1PGClv3IDKoxTzREjXyS0mFj_IQ61he-UKXFjWQz_7E=.ec69a4e1-0f86-42a1-91ea-5409232420a0@github.com> References: <1PGClv3IDKoxTzREjXyS0mFj_IQ61he-UKXFjWQz_7E=.ec69a4e1-0f86-42a1-91ea-5409232420a0@github.com> Message-ID: On Wed, 26 Jan 2022 05:36:07 GMT, meghanEmbrace wrote: >> With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. > > meghanEmbrace has updated the pull request incrementally with one additional commit since the last revision: > > Updated test name to be more descriptive. Looks good to me too. Tested with `-Dcom.sun.javafx.touch=true` and also without to make sure there is no regression. ------------- Marked as reviewed by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/688 From mhanl at openjdk.java.net Wed Jan 26 20:08:11 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 26 Jan 2022 20:08:11 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout [v3] In-Reply-To: References: Message-ID: > When a divider is moved via drag or code it will call **requestLayout()** for the **SplitPane**. > While this is fine, it is also called when the **SplitPaneSkin#layoutChildren(..)** method is repositioning the divider. > > This makes no sense since we are currently layouting everything, so we don't need to request it again. (The divider positioning is the first part of **layoutChildren(..)**. In the second part the SplitPane content is layouted based off those positions) > > -> With this behaviour the layout may hang under some conditions (check attached source). The problem is that the **requestLayout()** will mark the **SplitPane** dirty but won't propagate to the parent since the **SplitPane** is currently doing a layout. > > This PR fixes this by not requesting layout when we are currently doing it (and thus repositioning the dividers as part of it). > > Note: I also fixed a simple typo of a private method in SplitPaneSkin: > initializeDivderEventHandlers -> initializeDiv**i**derEventHandlers Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8277122: Added bug id to the fix and test for future reference ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/669/files - new: https://git.openjdk.java.net/jfx/pull/669/files/9db28ff0..345552d4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=669&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=669&range=01-02 Stats: 5 lines in 2 files changed: 4 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/669.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/669/head:pull/669 PR: https://git.openjdk.java.net/jfx/pull/669 From mhanl at openjdk.java.net Wed Jan 26 20:08:16 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 26 Jan 2022 20:08:16 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout [v2] In-Reply-To: References: <_grncaimIi3UGlnE44XBdS9hIQYAVlOGOpcXErtg-nA=.cce76737-295b-48fa-b8a9-17e39d7cfa70@github.com> Message-ID: On Tue, 25 Jan 2022 13:38:53 GMT, Jeanette Winzenburg wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8277122: Added test for setting a negative divider position + improved readability > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/SplitPaneSkin.java line 72: > >> 70: * {@link #layoutChildren(double, double, double, double)} since we are currently doing the layout. >> 71: */ >> 72: private boolean duringLayout; > > would like a reference to the bug this fixes Added it > modules/javafx.controls/src/main/java/javafx/scene/control/skin/SplitPaneSkin.java line 226: > >> 224: // If the window is less than the min size we want to resize proportionally >> 225: duringLayout = true; >> 226: double minSize = totalMinSize(); > > - setting the flag belongs above the code comment to not disrupt explanation and its target (== minsize) > - I think we don't do formatting (here: change the code comment to a single line) Changed. I kept the comment since it is basically just a single line but yes you are right :) > modules/javafx.controls/src/test/java/test/javafx/scene/control/SplitPaneTest.java line 1344: > >> 1342: * which can hang the layout as it resulted in multiple layout requests (through SplitPaneSkin.layoutChildren). >> 1343: */ >> 1344: @Test > > My preference would be to add the bug id to the tests as well .. Added it ------------- PR: https://git.openjdk.java.net/jfx/pull/669 From mhanl at openjdk.java.net Wed Jan 26 20:17:40 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 26 Jan 2022 20:17:40 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout [v2] In-Reply-To: References: <_grncaimIi3UGlnE44XBdS9hIQYAVlOGOpcXErtg-nA=.cce76737-295b-48fa-b8a9-17e39d7cfa70@github.com> Message-ID: On Tue, 25 Jan 2022 13:45:54 GMT, Jeanette Winzenburg wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8277122: Added test for setting a negative divider position + improved readability > > modules/javafx.controls/src/test/java/test/javafx/scene/control/SplitPaneTest.java line 1387: > >> 1385: assertTrue(layoutCounter.get() > 0); >> 1386: stageLoader.dispose(); >> 1387: } > > the stageLoader is not disposed if the test fails - a (recently introduced :) general pattern is to use an instance field that's disposed in the test cleanup Hm, is this really needed? Not sure, are there any side effects by the `StageLoader` like this when a test failed? Just asking since the `StageLoader` is used a lot like this. And since the tests normally run green unless you may change something locally (on the JavaFX Pipeline it should never be red), it would probably never affect anything (or maybe it does?). ------------- PR: https://git.openjdk.java.net/jfx/pull/669 From fastegal at openjdk.java.net Thu Jan 27 10:21:42 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 27 Jan 2022 10:21:42 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout [v2] In-Reply-To: References: <_grncaimIi3UGlnE44XBdS9hIQYAVlOGOpcXErtg-nA=.cce76737-295b-48fa-b8a9-17e39d7cfa70@github.com> Message-ID: <-AZkTYSvu_GKQRFpTn4ArKCrFgprKQHACPCrISTIjb0=.1161a22b-301f-4e64-9dfc-65fc92afad54@github.com> On Wed, 26 Jan 2022 20:14:37 GMT, Marius Hanl wrote: > Hm, is this really needed? yes, IMO, we want the exact same cleanup for passing/failing tests. So either dispose is required always (then need to make sure it's called on failure) or not required always (then all its calls would be noise). > Not sure, are there any side effects by the `StageLoader` like this when a test failed? Just asking since the `StageLoader` is used a lot like this. don't now (and doesn't matter, what matters is the guaranteed cleanup) - and aware of those slightly fishy patterns, we all learn :) Faintly remember having discussed the point in a PR (can't find it right now, though), and just as faintly remember the outcome was to guarantee the cleanup in new tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/669 From mhanl at openjdk.java.net Thu Jan 27 10:25:39 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 27 Jan 2022 10:25:39 GMT Subject: RFR: 8251481: TableCell accessing row: NPE on auto-sizing In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 12:00:11 GMT, Jeanette Winzenburg wrote: >> This PR will fix a simple NPE which may happens when using the `TableRow` inside a `TableCell` during the initial auto sizing. >> In the auto sizing code, no `TableRow` is set, therefore `getTableRow()` will return null and it is not possible to e.g. access the row item. >> >> This is fixed by adding the `TableRow` in the `resizeColumnToFitContent` method, similar as it is already done for the `TreeTableView` (`TreeTableRow`). > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 371: > >> 369: @Test >> 370: public void testRowIsNotNullWhenAutoSizing() { >> 371: TableColumn tableColumn = new TableColumn<>(); > > - the bug that's fixed in this PR is in TableColumnHeader, shouldn't the test be in TableColumnHeaderTest? > - if you decide to keep it here: it's in the middle of some edit-related tests, you might consider moving it up/down before/after those > - the fix aligns the resizeToFit method for TableView with that for TreeTableView: for symmetry, I would also expect a test method for the latter (which will pass both before and after the fix) I can align it. And yeah makes sense to add a test for the TreeTableView/TreeTableCell. > modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 379: > >> 377: >> 378: assertNotNull(getTableRow()); >> 379: } > > feeling slightly uncomfortable with the generality of this: looks a bit like it's guaranteed that tableRow != null always (bullet 2 of our previous conversation) - would suggest to make it more specific to auto-sizing (f.i. start without auto-size, then trigger autosizing by code). Or at least doc it (add a message to the assertion, add the bug id) so that future readers will know what exactly is tested here :) Pretty sure table row is never null. Or is it on some corner case? Because even on an empty table, table rows with empty cells will have the row (since rows will be added in the virtualflow) ------------- PR: https://git.openjdk.java.net/jfx/pull/716 From mhanl at openjdk.java.net Thu Jan 27 10:49:08 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 27 Jan 2022 10:49:08 GMT Subject: RFR: 8251481: TableCell accessing row: NPE on auto-sizing [v2] In-Reply-To: References: Message-ID: > This PR will fix a simple NPE which may happens when using the `TableRow` inside a `TableCell` during the initial auto sizing. > In the auto sizing code, no `TableRow` is set, therefore `getTableRow()` will return null and it is not possible to e.g. access the row item. > > This is fixed by adding the `TableRow` in the `resizeColumnToFitContent` method, similar as it is already done for the `TreeTableView` (`TreeTableRow`). Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8251481: Added TreeTableCellTest / reordered TableCellTest and added more details to it (javadoc) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/716/files - new: https://git.openjdk.java.net/jfx/pull/716/files/0ba6b283..30dd77e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=716&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=716&range=00-01 Stats: 65 lines in 2 files changed: 45 ins; 19 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/716.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/716/head:pull/716 PR: https://git.openjdk.java.net/jfx/pull/716 From clemens.lanthaler at itarchitects.at Thu Jan 27 11:02:22 2022 From: clemens.lanthaler at itarchitects.at (Clemens Lanthaler) Date: Thu, 27 Jan 2022 12:02:22 +0100 Subject: AVIF ImageProvider registering Message-ID: <580dc8c4-160f-ab3b-14da-0fe19c89656a@itarchitects.at> Hello everyone, as some of you already know I have created the project LibHeifFX (github.com/lanthaler/libheiffx) for adding HEIC (iPhone) and AVIF file format to the image class. Basically all is working with HEIC files, but as soons as I try to open a AVIF file OpenJFX gives me the error message "No imagedataprovider found!". But I have correctly registered AVIF as well. Tested OpenJFX: 17.0.2 Could it be that I am in a conflict with an internal signature ? Because it seems that OpenJFX only is checking the file signature and ignores the extension. Thank you in advance. Clemens -- ITArchitects CEO: B.Sc. Clemens Lanthaler Forchachstrasse 3 A-6166 Fulpmes Tel.: +43 (0)650 855 2954 email: office at itarchitects.at homepage: http://www.itarchitects.at ------------------------------------------------- Notice: This e-mail and any attachments are confidential and may be privileged. If you are not the intended recipient, notify the sender immediately, destroy all copies from your system and do not disclose or use the information for any purpose. Diese E-Mail inklusive aller Anhaenge ist vertraulich und koennte bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie bitte den Absender unverzueglich, loeschen Sie alle Kopien von Ihrem System und veroeffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck. From mhanl at openjdk.java.net Thu Jan 27 11:45:35 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 27 Jan 2022 11:45:35 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout [v2] In-Reply-To: <-AZkTYSvu_GKQRFpTn4ArKCrFgprKQHACPCrISTIjb0=.1161a22b-301f-4e64-9dfc-65fc92afad54@github.com> References: <_grncaimIi3UGlnE44XBdS9hIQYAVlOGOpcXErtg-nA=.cce76737-295b-48fa-b8a9-17e39d7cfa70@github.com> <-AZkTYSvu_GKQRFpTn4ArKCrFgprKQHACPCrISTIjb0=.1161a22b-301f-4e64-9dfc-65fc92afad54@github.com> Message-ID: <9vNdQ5rGRT1zP_I_flP1h0-mxgnxmoXeaa2xw2Rgmd8=.c4eddc9b-4ca9-4d80-b0ad-a39784346614@github.com> On Thu, 27 Jan 2022 10:18:31 GMT, Jeanette Winzenburg wrote: >> Hm, is this really needed? Not sure, are there any side effects by the `StageLoader` like this when a test failed? >> Just asking since the `StageLoader` is used a lot like this. >> And since the tests normally run green unless you may change something locally (on the JavaFX Pipeline it should never be red), it would probably never affect anything (or maybe it does?). > >> Hm, is this really needed? > > yes, IMO, we want the exact same cleanup for passing/failing tests. So either dispose is required always (then need to make sure it's called on failure) or not required always (then all its calls would be noise). > >> Not sure, are there any side effects by the `StageLoader` like this when a test failed? Just asking since the `StageLoader` is used a lot like this. > > don't now (and doesn't matter, what matters is the guaranteed cleanup) - and aware of those slightly fishy patterns, we all learn :) Faintly remember having discussed the point in a PR (can't find it right now, though), and just as faintly remember the outcome was to guarantee the cleanup in new tests. ah okay. Was just confusing for me since I never read that and I think some recent PRs still had this pattern, e.g. also the touch table scrolling PR I had a look at yesterday. Maybe for future it makes sense to have an abstract test class with the stage loader setup already in place. ------------- PR: https://git.openjdk.java.net/jfx/pull/669 From fastegal at openjdk.java.net Thu Jan 27 12:49:37 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 27 Jan 2022 12:49:37 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout [v2] In-Reply-To: <9vNdQ5rGRT1zP_I_flP1h0-mxgnxmoXeaa2xw2Rgmd8=.c4eddc9b-4ca9-4d80-b0ad-a39784346614@github.com> References: <_grncaimIi3UGlnE44XBdS9hIQYAVlOGOpcXErtg-nA=.cce76737-295b-48fa-b8a9-17e39d7cfa70@github.com> <-AZkTYSvu_GKQRFpTn4ArKCrFgprKQHACPCrISTIjb0=.1161a22b-301f-4e64-9dfc-65fc92afad54@github.com> <9vNdQ5rGRT1zP_I_flP1h0-mxgnxmoXeaa2xw2Rgmd8=.c4eddc9b-4ca9-4d80-b0ad-a39784346614@github.com> Message-ID: On Thu, 27 Jan 2022 11:42:28 GMT, Marius Hanl wrote: >>> Hm, is this really needed? >> >> yes, IMO, we want the exact same cleanup for passing/failing tests. So either dispose is required always (then need to make sure it's called on failure) or not required always (then all its calls would be noise). >> >>> Not sure, are there any side effects by the `StageLoader` like this when a test failed? Just asking since the `StageLoader` is used a lot like this. >> >> don't now (and doesn't matter, what matters is the guaranteed cleanup) - and aware of those slightly fishy patterns, we all learn :) Faintly remember having discussed the point in a PR (can't find it right now, though), and just as faintly remember the outcome was to guarantee the cleanup in new tests. > > ah okay. Was just confusing for me since I never read that and I think some recent PRs still had this pattern, e.g. also the touch table scrolling PR I had a look at yesterday. > > Maybe for future it makes sense to have an abstract test class with the stage loader setup already in place. just for reference - found the source of my [faintly remember](https://github.com/openjdk/jfx/pull/337/files/8a6fc1cf6cad2c453de17b71777ddd63fadb539e#r510975640) ------------- PR: https://git.openjdk.java.net/jfx/pull/669 From duke at openjdk.java.net Thu Jan 27 13:55:44 2022 From: duke at openjdk.java.net (meghanEmbrace) Date: Thu, 27 Jan 2022 13:55:44 GMT Subject: Integrated: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning In-Reply-To: References: Message-ID: On Thu, 2 Dec 2021 10:12:50 GMT, meghanEmbrace wrote: > With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. This pull request has now been integrated. Changeset: 78d92275 Author: Meghan Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/78d922750747517553b101f5ff4af5361b1e7959 Stats: 36 lines in 2 files changed: 35 ins; 0 del; 1 mod 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning Reviewed-by: kcr, mhanl ------------- PR: https://git.openjdk.java.net/jfx/pull/688 From michaelstrau2 at gmail.com Thu Jan 27 14:03:45 2022 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 27 Jan 2022 15:03:45 +0100 Subject: AVIF ImageProvider registering In-Reply-To: <580dc8c4-160f-ab3b-14da-0fe19c89656a@itarchitects.at> References: <580dc8c4-160f-ab3b-14da-0fe19c89656a@itarchitects.at> Message-ID: The error message of the exception that is thrown by `ImageStorage` when attempting to load an unsupported image type is: "No loader for image data". If you're encountering a different exception, maybe it originates from somewhere else. That being said, you're right that OpenJFX doesn't care about file extensions and only checks file signatures. For both HEIC and AVIF files, that's "ftyp" followed by a `major_brand` identifier. Maybe you're encountering files with different kinds of `major_brand`? Note that image loaders are an implementation detail of OpenJFX and not public API, which means that the classes could change at any time without notice. On Thu, Jan 27, 2022 at 12:04 PM Clemens Lanthaler wrote: > > Hello everyone, > > as some of you already know I have created the project LibHeifFX > (github.com/lanthaler/libheiffx) for adding HEIC (iPhone) and AVIF file > format to the image class. > > Basically all is working with HEIC files, but as soons as I try to open > a AVIF file OpenJFX gives me the error message "No imagedataprovider > found!". But I have correctly registered AVIF as well. > > Tested OpenJFX: 17.0.2 > > Could it be that I am in a conflict with an internal signature ? Because > it seems that OpenJFX only is checking the file signature and ignores > the extension. > > Thank you in advance. > Clemens From swpalmer at gmail.com Thu Jan 27 14:20:47 2022 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 27 Jan 2022 09:20:47 -0500 Subject: AVIF ImageProvider registering In-Reply-To: <580dc8c4-160f-ab3b-14da-0fe19c89656a@itarchitects.at> References: <580dc8c4-160f-ab3b-14da-0fe19c89656a@itarchitects.at> Message-ID: <9D6DBD95-507B-472A-9701-493E1525DF5E@gmail.com> That link should be https://github.com/lanthale/LibHeifFX > On Jan 27, 2022, at 6:02 AM, Clemens Lanthaler wrote: > > Hello everyone, > > as some of you already know I have created the project LibHeifFX (github.com/lanthaler/libheiffx) for adding HEIC (iPhone) and AVIF file format to the image class. > > Basically all is working with HEIC files, but as soons as I try to open a AVIF file OpenJFX gives me the error message "No imagedataprovider found!". But I have correctly registered AVIF as well. > > Tested OpenJFX: 17.0.2 > > Could it be that I am in a conflict with an internal signature ? Because it seems that OpenJFX only is checking the file signature and ignores the extension. > > Thank you in advance. > Clemens From fkirmaier at openjdk.java.net Thu Jan 27 14:50:16 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 27 Jan 2022 14:50:16 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v5] In-Reply-To: References: Message-ID: > After thinking about this issue for some time, I've now got a solution. > I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. > This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8269907 Removed the sync methods for the scene, because they don't work when peer is null, and they are not necessary. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/584/files - new: https://git.openjdk.java.net/jfx/pull/584/files/29b90745..22326ccf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=584&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=584&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/584.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/584/head:pull/584 PR: https://git.openjdk.java.net/jfx/pull/584 From michaelstrau2 at gmail.com Thu Jan 27 15:08:23 2022 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 27 Jan 2022 16:08:23 +0100 Subject: AVIF ImageProvider registering In-Reply-To: <9D6DBD95-507B-472A-9701-493E1525DF5E@gmail.com> References: <580dc8c4-160f-ab3b-14da-0fe19c89656a@itarchitects.at> <9D6DBD95-507B-472A-9701-493E1525DF5E@gmail.com> Message-ID: >From a quick look at the code, two things come to mind: 1. The file signature is specified as "0000001C6674797061760000", which corresponds to "ftypav" followed by two null bytes. Maybe "av" ist not a valid `major_brand`. 2. The first four bytes of the file specify the size of the header, which can change depending on the number of `compatible_brands`. That's bad news for JavaFX, since the current implementation cannot account for variable fields in file signatures (it always matches all bytes of the signature exactly). On Thu, Jan 27, 2022 at 3:22 PM Scott Palmer wrote: > > That link should be https://github.com/lanthale/LibHeifFX > > > > On Jan 27, 2022, at 6:02 AM, Clemens Lanthaler wrote: > > > > Hello everyone, > > > > as some of you already know I have created the project LibHeifFX (github.com/lanthaler/libheiffx) for adding HEIC (iPhone) and AVIF file format to the image class. > > > > Basically all is working with HEIC files, but as soons as I try to open a AVIF file OpenJFX gives me the error message "No imagedataprovider found!". But I have correctly registered AVIF as well. > > > > Tested OpenJFX: 17.0.2 > > > > Could it be that I am in a conflict with an internal signature ? Because it seems that OpenJFX only is checking the file signature and ignores the extension. > > > > Thank you in advance. > > Clemens From nlisker at openjdk.java.net Thu Jan 27 15:10:42 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 27 Jan 2022 15:10:42 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses In-Reply-To: References: Message-ID: <1HVL-H84XizlRUzvtFRxC0mNWA_fAsimBUsQElWAdpQ=.e79815e6-e372-440e-a90d-b069ce0d27e9@github.com> On Tue, 25 Jan 2022 06:21:37 GMT, Ambarish Rapte wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/AmbientLight.java line 37: >> >>> 35: *

    >>> 36: * {@code AmbientLight}s can represent strong light sources in an enclosed area where the lights bounces from many >>> 37: * objects, causing them to be illuminated from many directions. A strong light in a room and moonlight are common light >> >>> A strong light in a room ... >> >> I think this is OK, as long as a reader doesn't think of an overhead light in a room, which also has the properties of a point light. > > Ambient light is a light that comes from all directions, scattered from different surfaces and it does not cast shadow. So I think the example of strong light and moon light should be avoided. Moon light is more like the Sun light, a directional light. What examples would you use? If a light in a room is strong it will barely cast shadows since its reflections from all directions eliminate them. Maybe I should mention that Ambient light can be used with a dark color to provide a base weak lighting of the environment, and on top of it use other lights. ------------- PR: https://git.openjdk.java.net/jfx/pull/717 From mhanl at openjdk.java.net Thu Jan 27 15:24:37 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 27 Jan 2022 15:24:37 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout [v2] In-Reply-To: References: <_grncaimIi3UGlnE44XBdS9hIQYAVlOGOpcXErtg-nA=.cce76737-295b-48fa-b8a9-17e39d7cfa70@github.com> <-AZkTYSvu_GKQRFpTn4ArKCrFgprKQHACPCrISTIjb0=.1161a22b-301f-4e64-9dfc-65fc92afad54@github.com> <9vNdQ5rGRT1zP_I_flP1h0-mxgnxmoXeaa2xw2Rgmd8=.c4eddc9b-4ca9-4d80-b0ad-a39784346614@github.com> Message-ID: On Thu, 27 Jan 2022 12:46:19 GMT, Jeanette Winzenburg wrote: >> ah okay. Was just confusing for me since I never read that and I think some recent PRs still had this pattern, e.g. also the touch table scrolling PR I had a look at yesterday. >> >> Maybe for future it makes sense to have an abstract test class with the stage loader setup already in place. > > just for reference - found the source of my [faintly remember](https://github.com/openjdk/jfx/pull/337/files/8a6fc1cf6cad2c453de17b71777ddd63fadb539e#r510975640) I see. Unfortunately though that was not done consistently during the past PRs. ------------- PR: https://git.openjdk.java.net/jfx/pull/669 From mstrauss at openjdk.java.net Thu Jan 27 15:48:40 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 27 Jan 2022 15:48:40 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses In-Reply-To: <1HVL-H84XizlRUzvtFRxC0mNWA_fAsimBUsQElWAdpQ=.e79815e6-e372-440e-a90d-b069ce0d27e9@github.com> References: <1HVL-H84XizlRUzvtFRxC0mNWA_fAsimBUsQElWAdpQ=.e79815e6-e372-440e-a90d-b069ce0d27e9@github.com> Message-ID: On Thu, 27 Jan 2022 15:07:26 GMT, Nir Lisker wrote: >> Ambient light is a light that comes from all directions, scattered from different surfaces and it does not cast shadow. So I think the example of strong light and moon light should be avoided. Moon light is more like the Sun light, a directional light. > > What examples would you use? > > If a light in a room is strong it will barely cast shadows since its reflections from all directions eliminate them. > > Maybe I should mention that Ambient light can be used with a dark color to provide a base weak lighting of the environment, and on top of it use other lights. I think the description should focus on the meaning of the respective term in the lighting equation, and not on a non-technical analogy. In this case, the analogy is a bit misleading on several aspects, including the fact that ambient lighting is not dependent on an area being enclosed. Here's a suggestion: Ambient lights add a constant term to the amount of light reflected by each point on the surface of an object, thereby increasing the brightness of the object uniformly and independently of the orientation of its surfaces. It is often used to represent the base amount of illumination in a scene. ------------- PR: https://git.openjdk.java.net/jfx/pull/717 From nlisker at openjdk.java.net Thu Jan 27 17:17:42 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 27 Jan 2022 17:17:42 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 01:17:51 GMT, Kevin Rushforth wrote: >> Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: >> >> * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. >> * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. >> * Added examples of real-world applications for each light type. >> * Consolidated the writing style for all the subclasses. > > modules/javafx.graphics/src/main/java/javafx/scene/LightBase.java line 119: > >> 117: *

  • The transparency (alpha) component of a light is ignored. >> 118: * >> 119: * There are no guarantee that these behaviors will not change. > > This is a new specification of behavior rather than a doc reorganization or clarification of an existing note. As such, I think it should be done separately and with a CSR. Even if this just clarifies the current behavior and doesn't make a guarantee? ------------- PR: https://git.openjdk.java.net/jfx/pull/717 From nlisker at openjdk.java.net Thu Jan 27 17:28:15 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 27 Jan 2022 17:28:15 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses [v2] In-Reply-To: References: Message-ID: > Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: > > * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. > * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. > * Added examples of real-world applications for each light type. > * Consolidated the writing style for all the subclasses. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/717/files - new: https://git.openjdk.java.net/jfx/pull/717/files/dd2c99f5..3f62718b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=717&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=717&range=00-01 Stats: 10 lines in 3 files changed: 0 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/717.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/717/head:pull/717 PR: https://git.openjdk.java.net/jfx/pull/717 From kcr at openjdk.java.net Thu Jan 27 19:04:33 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 27 Jan 2022 19:04:33 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses [v2] In-Reply-To: References: <1HVL-H84XizlRUzvtFRxC0mNWA_fAsimBUsQElWAdpQ=.e79815e6-e372-440e-a90d-b069ce0d27e9@github.com> Message-ID: On Thu, 27 Jan 2022 15:45:44 GMT, Michael Strau? wrote: >> What examples would you use? >> >> If a light in a room is strong it will barely cast shadows since its reflections from all directions eliminate them. >> >> Maybe I should mention that Ambient light can be used with a dark color to provide a base weak lighting of the environment, and on top of it use other lights. > > I think the description should focus on the meaning of the respective term in the lighting equation, and not on a non-technical analogy. In this case, the analogy is a bit misleading on several aspects, including the fact that ambient lighting is not dependent on an area being enclosed. Here's a suggestion: > > Ambient lights add a constant term to the amount of light reflected by each point on > the surface of an object, thereby increasing the brightness of the object uniformly and > independently of the orientation of its surfaces. It is often used to represent the base > amount of illumination in a scene. I think the key aspects of an Ambient light are that: the light seems to come from all directions (and thus has no position or direction), and that it illuminates objects independently of the position or orientation of the object. I don't have a problem with also giving a real-world analogy if one can be found that makes it easier to understand without causing confusion. ------------- PR: https://git.openjdk.java.net/jfx/pull/717 From kcr at openjdk.java.net Thu Jan 27 19:11:41 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 27 Jan 2022 19:11:41 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses [v2] In-Reply-To: References: Message-ID: <_sba0du_gzj-CHRO6umA5QlWwnnNkfNqdzvADcgIi0g=.9acea318-9e75-435b-86ce-a0eacbba5527@github.com> On Thu, 27 Jan 2022 17:14:51 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/LightBase.java line 119: >> >>> 117: *
  • The transparency (alpha) component of a light is ignored. >>> 118: * >>> 119: * There are no guarantee that these behaviors will not change. >> >> This is a new specification of behavior rather than a doc reorganization or clarification of an existing note. As such, I think it should be done separately and with a CSR. > > Even if this just clarifies the current behavior and doesn't make a guarantee? We will sometimes clarify existing behavior in JavaFX without a CSR. If that's what you intend with this, then I might suggest moving it to an `@implNote`. Also, I prefer something more like the following for the last sentence: * These behaviors are not specified and could change in the future. ------------- PR: https://git.openjdk.java.net/jfx/pull/717 From nlisker at openjdk.java.net Thu Jan 27 19:29:19 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 27 Jan 2022 19:29:19 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses [v3] In-Reply-To: References: Message-ID: > Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: > > * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. > * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. > * Added examples of real-world applications for each light type. > * Consolidated the writing style for all the subclasses. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Added implNote ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/717/files - new: https://git.openjdk.java.net/jfx/pull/717/files/3f62718b..fd12a2ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=717&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=717&range=01-02 Stats: 15 lines in 1 file changed: 8 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/717.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/717/head:pull/717 PR: https://git.openjdk.java.net/jfx/pull/717 From kcr at openjdk.java.net Thu Jan 27 19:29:21 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 27 Jan 2022 19:29:21 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses [v2] In-Reply-To: References: Message-ID: On Thu, 27 Jan 2022 17:28:15 GMT, Nir Lisker wrote: >> Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: >> >> * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. >> * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. >> * Added examples of real-world applications for each light type. >> * Consolidated the writing style for all the subclasses. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments I added an additional comment about the accessibility of the table. modules/javafx.graphics/src/main/java/javafx/scene/LightBase.java line 77: > 75: * > 76: * > 77: * {@link AmbientLight} In addition to `scope="col"` for the first row, the first column in each other row needs a `scope="row:` (and should use a `` element for that column). For example, see [javafx/scene/media/package.html#L92](https://github.com/openjdk/jfx/blob/3f62718b0ce00c1cab7f23cbd67c26887b4f50ad/modules/javafx.media/src/main/java/javafx/scene/media/package.html#L92). ------------- PR: https://git.openjdk.java.net/jfx/pull/717 From nlisker at openjdk.java.net Thu Jan 27 19:57:13 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 27 Jan 2022 19:57:13 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses [v4] In-Reply-To: References: Message-ID: <-qb8omDXytqaMmDQ0fyrY3SGI7-f0EVQ9RY_DnuMIA4=.2f099e4e-9edb-4897-8184-54a8e82cfb4b@github.com> > Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: > > * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. > * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. > * Added examples of real-world applications for each light type. > * Consolidated the writing style for all the subclasses. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Fixed table accessibility ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/717/files - new: https://git.openjdk.java.net/jfx/pull/717/files/fd12a2ea..cae874d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=717&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=717&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/717.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/717/head:pull/717 PR: https://git.openjdk.java.net/jfx/pull/717 From mhanl at openjdk.java.net Thu Jan 27 20:38:56 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 27 Jan 2022 20:38:56 GMT Subject: RFR: 8251481: TableCell accessing row: NPE on auto-sizing [v3] In-Reply-To: References: Message-ID: > This PR will fix a simple NPE which may happens when using the `TableRow` inside a `TableCell` during the initial auto sizing. > In the auto sizing code, no `TableRow` is set, therefore `getTableRow()` will return null and it is not possible to e.g. access the row item. > > This is fixed by adding the `TableRow` in the `resizeColumnToFitContent` method, similar as it is already done for the `TreeTableView` (`TreeTableRow`). Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8251481: Using global stageLoader now ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/716/files - new: https://git.openjdk.java.net/jfx/pull/716/files/30dd77e9..a8d99555 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=716&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=716&range=01-02 Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/716.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/716/head:pull/716 PR: https://git.openjdk.java.net/jfx/pull/716 From mhanl at openjdk.java.net Thu Jan 27 20:39:13 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 27 Jan 2022 20:39:13 GMT Subject: RFR: 8251481: TableCell accessing row: NPE on auto-sizing [v3] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 12:09:31 GMT, Jeanette Winzenburg wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8251481: Using global stageLoader now > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 385: > >> 383: StageLoader loader = new StageLoader(table); >> 384: >> 385: loader.dispose(); > > note that the loader isn't disposed if the test fails - that's why there's an instance field (which will be disposed in cleanup), which should be used here done ------------- PR: https://git.openjdk.java.net/jfx/pull/716 From mhanl at openjdk.java.net Thu Jan 27 20:48:40 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 27 Jan 2022 20:48:40 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout [v4] In-Reply-To: References: Message-ID: > When a divider is moved via drag or code it will call **requestLayout()** for the **SplitPane**. > While this is fine, it is also called when the **SplitPaneSkin#layoutChildren(..)** method is repositioning the divider. > > This makes no sense since we are currently layouting everything, so we don't need to request it again. (The divider positioning is the first part of **layoutChildren(..)**. In the second part the SplitPane content is layouted based off those positions) > > -> With this behaviour the layout may hang under some conditions (check attached source). The problem is that the **requestLayout()** will mark the **SplitPane** dirty but won't propagate to the parent since the **SplitPane** is currently doing a layout. > > This PR fixes this by not requesting layout when we are currently doing it (and thus repositioning the dividers as part of it). > > Note: I also fixed a simple typo of a private method in SplitPaneSkin: > initializeDivderEventHandlers -> initializeDiv**i**derEventHandlers Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8277122: Added and used global stageLoader + changed copyright year to 2022 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/669/files - new: https://git.openjdk.java.net/jfx/pull/669/files/345552d4..a5f9f500 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=669&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=669&range=02-03 Stats: 11 lines in 2 files changed: 7 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/669.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/669/head:pull/669 PR: https://git.openjdk.java.net/jfx/pull/669 From mhanl at openjdk.java.net Thu Jan 27 20:53:38 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 27 Jan 2022 20:53:38 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout [v2] In-Reply-To: References: <_grncaimIi3UGlnE44XBdS9hIQYAVlOGOpcXErtg-nA=.cce76737-295b-48fa-b8a9-17e39d7cfa70@github.com> <-AZkTYSvu_GKQRFpTn4ArKCrFgprKQHACPCrISTIjb0=.1161a22b-301f-4e64-9dfc-65fc92afad54@github.com> <9vNdQ5rGRT1zP_I_flP1h0-mxgnxmoXeaa2xw2Rgmd8=.c4eddc9b-4ca9-4d80-b0ad-a39784346614@github.com> Message-ID: On Thu, 27 Jan 2022 15:21:33 GMT, Marius Hanl wrote: >> just for reference - found the source of my [faintly remember](https://github.com/openjdk/jfx/pull/337/files/8a6fc1cf6cad2c453de17b71777ddd63fadb539e#r510975640) > > I see. Unfortunately though that was not done consistently during the past PRs. Done. Also adjusted the copyright year ;) ------------- PR: https://git.openjdk.java.net/jfx/pull/669 From jhendrikx at openjdk.java.net Thu Jan 27 21:04:15 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 27 Jan 2022 21:04:15 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v5] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <9nHf-iDivaY2uA-UZ4u0M_2pwvszEGwxh5TjJKhVXck=.63894eb0-dc08-47ac-b672-5b0d5e4a464a@github.com> Message-ID: On Sun, 16 Jan 2022 12:25:13 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix grammar mistakes and did some small rephrases > > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 189: > >> 187: * holds {@code null}; can be {@code null} >> 188: * @return an {@code ObservableValue} holding this {@code ObservableValue}'s value, >> 189: * or the given value it is {@code null}; never returns {@code null} > > `or the given value it is {@code null}` missing "when" or "if"? Fixed this with "if" > modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 271: > >> 269: @Test >> 270: void shouldReturnPropertyValuesWithOperationApplied() { >> 271: assertEquals((Integer) 65, observableValue.getValue()); > > I don't think that the cast is needed as autoboxing will take care of it. Fine to leave as-is. I rewrote this now anyway to use strings, and I made the fluent binding test a bit easier to follow (I hope). ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Thu Jan 27 21:20:08 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 27 Jan 2022 21:20:08 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v6] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Change code according to review comments Rewrote and extended ObservableFluentBindingsTest for more clarity Use JMemoryBuddy in ReferenceAsserts helper ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/675/files - new: https://git.openjdk.java.net/jfx/pull/675/files/040bfe40..b013e2d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=04-05 Stats: 438 lines in 5 files changed: 337 ins; 27 del; 74 mod Patch: https://git.openjdk.java.net/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/675/head:pull/675 PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Thu Jan 27 21:20:09 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 27 Jan 2022 21:20:09 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v5] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <9nHf-iDivaY2uA-UZ4u0M_2pwvszEGwxh5TjJKhVXck=.63894eb0-dc08-47ac-b672-5b0d5e4a464a@github.com> Message-ID: On Thu, 20 Jan 2022 17:19:49 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix grammar mistakes and did some small rephrases > > modules/javafx.base/src/main/java/javafx/beans/value/LazyObjectBinding.java line 91: > >> 89: * >> 90: * As the binding must be valid after it becomes observed the first time >> 91: * 'get' is called again. > > Maybe add an `@link` to `ExpressionHelper` where the validation happens before listener registration, for clarity. I've added this additional text: * See com.sun.javafx.binding.ExpressionHelper (which is used * by ObjectBinding) where it will do a call to ObservableValue#getValue * BEFORE adding the actual listener. This results in ObjectBinding#get * to be called in which the #allowValidation call will block it from * becoming valid as the condition is "isObserved()"; this is technically * correct as the listener wasn't added yet, but means we must call * #get again to make this binding valid. This might be something we can fix in future work, to avoid this double call to `get`. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Thu Jan 27 21:37:06 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 27 Jan 2022 21:37:06 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v5] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <9nHf-iDivaY2uA-UZ4u0M_2pwvszEGwxh5TjJKhVXck=.63894eb0-dc08-47ac-b672-5b0d5e4a464a@github.com> Message-ID: <8OXbCj4JbKzkbvO9QWR1PnkfaedXe10Gv2JIlL9VvBA=.b377a073-da55-41c1-bb91-506e06dc11eb@github.com> On Sun, 16 Jan 2022 22:01:33 GMT, Nir Lisker wrote: > * Most tests that I have seen in JavaFX use the assert overloads that include a message that explains what the value should be or what it means if the assertion failed. I don't know how much of a requirement it is. I can help write these if you want. I'm a bit at a loss there, many of the asserts are think are self explanatory already, and a text describing the events that led to this assert would basically describe the same as the path of all `@Nested` classes + method name. For example: - ObservableFluentBindingsTest - When_map_Called - WithNotNullReturns_ObservableValue_Which - When_orElse_CalledReturns_ObservableValue_Which - WhenObserved - ShouldApplyMapThenOrElseOperation I've however cleaned up the entire test using different values that more clearly show what is happening (like `Left` after map becomes `Left+map` and after a second map it becomes `Left+map+map2`). For `orElse` I use `Empty` now to make it more clear. I also added `assertObserved` and `assertNothingIsObserved` methods to get rid of the ugly checking of the `values` list to see what the test listener was observing. Please let me know if that helps. > * There is a utility class `JMemoryBuddy` that was added to JavaFX to test for memory leaks. This would have been helpful in the GC tests, but it seems that the class is not suited too well for this case (it requires you to `null` you own reference etc.). I think the way you did it is fine, but maybe that class should be updated (in a different patch) to be more welcoming for these checks. I've applied it in the helper class I was using. > I would also add tests of chaining the observables in common use cases. I wrote some myself to test it for `map`: I added additional nested classes for Map which adds another nesting that applies another Map or an OrElse. Same for FlatMap. I see the fluent binding test mostly as a test to ensure the basic functionality and to ensure things are getting garbage collected when they should and not when they shouldn't. If we want to test more specific cases without having to worry about GC, perhaps another test class is better suited. > You can clean these up and use them or write your own. `flatMap` should also have one. I can clean mine up and post it if it helps (I did some dirty testing there). That's good, I hope you didn't find anything surprising :) ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Thu Jan 27 21:37:06 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 27 Jan 2022 21:37:06 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v7] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Clean up some missed asserts and some nested class names ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/675/files - new: https://git.openjdk.java.net/jfx/pull/675/files/b013e2d1..14048a99 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=05-06 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/675/head:pull/675 PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Thu Jan 27 21:49:07 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 27 Jan 2022 21:49:07 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v8] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix wrong test values ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/675/files - new: https://git.openjdk.java.net/jfx/pull/675/files/14048a99..30733ccb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=06-07 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/675/head:pull/675 PR: https://git.openjdk.java.net/jfx/pull/675 From kcr at openjdk.java.net Thu Jan 27 23:46:10 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 27 Jan 2022 23:46:10 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Mon, 10 Jan 2022 00:04:00 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > added test for huge polygon coords Here are my general review comments. The new version of Marlin fixes the specific problem identified in [JDK-8274066](https://bugs.openjdk.java.net/browse/JDK-8274066). It also seems inherently more robust for large coordinates, which is a plus. All my testing looks good, although the new system test fails for me on my Mac: HugePolygonClipTest > TestHugePolygonCoords FAILED java.lang.AssertionError: bad pixel at (300, 198) = -16711426 expected: -16776961 at org.junit.Assert.fail(Assert.java:89) at test.com.sun.marlin.HugePolygonClipTest.checkColumn(HugePolygonClipTest.java:231) at test.com.sun.marlin.HugePolygonClipTest.lambda$TestHugePolygonCoords$1(HugePolygonClipTest.java:207) I have a Retina display, so it might have something to do with that. I recommend sampling a few pixels at locations slightly away from the boundaries to avoid this problem. This updated version of Marlin is a large change, especially when coupled with the performance improvements provided by the newly added Dual-Pivot QuickSort, DQPS (more on this below). It's really an enhancement to update to a new version of Marlin rather than a bug fix. It's out of scope to try and get into JavaFX 18 during ramp-down. This should go into `master` for JavaFX 19 so it can get more bake time. We should file a new JBS Enhancement issue -- similar to what was done for Marlin 0.9.2 via [JDK-8204621](https://bugs.openjdk.java.net/browse/JDK-8204621) rather than using a narrow bug, since that bug is only part of what's being done. The current bug can either be added to the PR, or else that JBS bug (JDK-8274066) can be closed as a duplicate of the new Enhancement. Regarding the Dual-Pivot QuickSort (DQPS) code, I'm still not sure that the extra maintenance burden of having our own modified copy of DPQS is justified. It seems like the improvements are mostly in corner cases. Do you have any real world examples that would correlate to the benchmark cases you ran? I also have a question about the provenance of this DQPS code. Much of it is already in the JDK, which is OK (leaving aside the maintenance aspect of having a copy of the code), so my questions are around the modifications. You indicated that this is being developed by you and Vladimir in [bourgesl/nearly-optimal-mergesort-code](https://github.com/bourgesl/nearly-optimal-mergesort-code), which is a fork of [sebawild/nearly-optimal-mergesort-code](https://github.com/sebawild/nearly-optimal-mergesort-code). Can you assert that the modifications you are making to the code imported from the JDK are entirely form you? Or from other OCA signatories who have explicitly agreed to contribute these modifications under the terms of the OCA? ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From kcr at openjdk.java.net Fri Jan 28 00:42:19 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 28 Jan 2022 00:42:19 GMT Subject: RFR: 8255940: localStorage is null after window.close() In-Reply-To: References: Message-ID: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> On Mon, 27 Dec 2021 09:31:08 GMT, Jay Bhaskar wrote: > Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. > Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) > "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." This change will cause the typical case where the page isn't closing to always allocate a new storage area, whereas the current code returns `m_localStorage.get()` if `m_localStorage` is valid. Also, will cause the case where `page` is `null` to return `nullptr`, whereas the current code returns `m_localStorage.get()` if `m_localStorage` is valid. Unless I'm missing something, the more correct fix is is to restore the check for `m_localStorage`, without the check for `page` (not removing the whole block). See inline comments. modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindow.cpp line 854: > 852: return m_localStorage.get(); > 853: } > 854: This will change the behavior for the case where page is null or where the page is valid, but not closing. I think you should partially revert this part of the fix, restoring it as follows: if (m_localStorage) return m_localStorage.get(); modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindow.cpp line 859: > 857: if (page->isClosing() && m_localStorage) > 858: return m_localStorage.get(); > 859: If you make the earlier modification I suggested, then you don't need this block. modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 2: > 1: /* > 2: * Copyright (c) 2011, 2020, Oracle and/or its affiliates. All rights reserved. Copyright should be a single year (2022) modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 48: > 46: final WebEngine webEngine = getEngine(); > 47: webEngine.setJavaScriptEnabled(true); > 48: webEngine.setUserDataDirectory(new File("/tmp/java-store")); You should not hard-code /tmp/. You can either use a local subdirectory in the build dir (which some other tests do), or else you will need to use something like `Files.createTempDirectory("webstorage")`. If you use the latter, then you will need to worry about how to clean up after the test, so the former seems better. modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 60: > 58: assertNotNull(webEngine.executeScript("localStorage;")); > 59: getEngine().executeScript("window.close();"); > 60: assertNotNull(webEngine.executeScript("localStorage;")); It seems useful to verify the contents by writing something before the window is closed, and then verifying that the same value can be read. modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 70: > 68: WebView view = getView(); > 69: view.getEngine().executeScript("test_local_storage_set();"); > 70: String s = (String) view.getEngine().executeScript("document.getElementById('key').innerText;"); This will work, but it might be cleaner to add a JavaScript `getLocalStorage` method so you don't have to get it from a DOM element. modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 80: > 78: submit(() -> { > 79: WebView view = getView(); > 80: view.getEngine().executeScript("delete_items();"); You need to set some items first before deleting them if you want it to be an effective test of this case. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/703 From fastegal at openjdk.java.net Fri Jan 28 12:32:18 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 28 Jan 2022 12:32:18 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout [v4] In-Reply-To: References: Message-ID: On Thu, 27 Jan 2022 20:48:40 GMT, Marius Hanl wrote: >> When a divider is moved via drag or code it will call **requestLayout()** for the **SplitPane**. >> While this is fine, it is also called when the **SplitPaneSkin#layoutChildren(..)** method is repositioning the divider. >> >> This makes no sense since we are currently layouting everything, so we don't need to request it again. (The divider positioning is the first part of **layoutChildren(..)**. In the second part the SplitPane content is layouted based off those positions) >> >> -> With this behaviour the layout may hang under some conditions (check attached source). The problem is that the **requestLayout()** will mark the **SplitPane** dirty but won't propagate to the parent since the **SplitPane** is currently doing a layout. >> >> This PR fixes this by not requesting layout when we are currently doing it (and thus repositioning the dividers as part of it). >> >> Note: I also fixed a simple typo of a private method in SplitPaneSkin: >> initializeDivderEventHandlers -> initializeDiv**i**derEventHandlers > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8277122: Added and used global stageLoader + changed copyright year to 2022 looks good now :) ------------- Marked as reviewed by fastegal (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/669 From kcr at openjdk.java.net Fri Jan 28 12:43:16 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 28 Jan 2022 12:43:16 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses [v4] In-Reply-To: <-qb8omDXytqaMmDQ0fyrY3SGI7-f0EVQ9RY_DnuMIA4=.2f099e4e-9edb-4897-8184-54a8e82cfb4b@github.com> References: <-qb8omDXytqaMmDQ0fyrY3SGI7-f0EVQ9RY_DnuMIA4=.2f099e4e-9edb-4897-8184-54a8e82cfb4b@github.com> Message-ID: On Thu, 27 Jan 2022 19:57:13 GMT, Nir Lisker wrote: >> Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: >> >> * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. >> * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. >> * Added examples of real-world applications for each light type. >> * Consolidated the writing style for all the subclasses. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Fixed table accessibility The latest changes all look good. The only open question is around the description of `AmbientLight`. ------------- PR: https://git.openjdk.java.net/jfx/pull/717 From fastegal at openjdk.java.net Fri Jan 28 12:43:18 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 28 Jan 2022 12:43:18 GMT Subject: RFR: 8251481: TableCell accessing row: NPE on auto-sizing [v3] In-Reply-To: References: Message-ID: On Thu, 27 Jan 2022 10:21:18 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 371: >> >>> 369: @Test >>> 370: public void testRowIsNotNullWhenAutoSizing() { >>> 371: TableColumn tableColumn = new TableColumn<>(); >> >> - the bug that's fixed in this PR is in TableColumnHeader, shouldn't the test be in TableColumnHeaderTest? >> - if you decide to keep it here: it's in the middle of some edit-related tests, you might consider moving it up/down before/after those >> - the fix aligns the resizeToFit method for TableView with that for TreeTableView: for symmetry, I would also expect a test method for the latter (which will pass both before and after the fix) > > I can align it. And yeah makes sense to add a test for the TreeTableView/TreeTableCell. just curious: why didn't you move the tests into TableColumnHeaderTest? > Pretty sure table row is never null. Or is it on some corner case? updateItem has no precondition :) So a clean implementation must cope with whatever state the cell is in (getting away with not thinking of potential corner cases most of the time). ------------- PR: https://git.openjdk.java.net/jfx/pull/716 From mhanl at openjdk.java.net Fri Jan 28 13:17:12 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Fri, 28 Jan 2022 13:17:12 GMT Subject: RFR: 8251481: TableCell accessing row: NPE on auto-sizing [v3] In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 12:40:15 GMT, Jeanette Winzenburg wrote: >> I can align it. And yeah makes sense to add a test for the TreeTableView/TreeTableCell. > > just curious: why didn't you move the tests into TableColumnHeaderTest? I had no particular reason, I think the test fits both classes, although `TableColumnHeaderTest` just tests the normal `TableView`. So I kept it in the `TableCellTest` class ------------- PR: https://git.openjdk.java.net/jfx/pull/716 From fastegal at openjdk.java.net Sat Jan 29 13:57:14 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 29 Jan 2022 13:57:14 GMT Subject: RFR: 8251481: TableCell accessing row: NPE on auto-sizing [v3] In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 13:14:37 GMT, Marius Hanl wrote: >> just curious: why didn't you move the tests into TableColumnHeaderTest? > > I had no particular reason, I think the test fits both classes, although `TableColumnHeaderTest` just tests the normal `TableView`. So I kept it in the `TableCellTest` class just thought I had overlooked something, .. okay, fair enough :) Still think that all tests for autosizing (both for Tree/TableView) have their best home in TableColumnHeaderTest, but then that's my personal preference. ------------- PR: https://git.openjdk.java.net/jfx/pull/716 From fastegal at openjdk.java.net Sat Jan 29 14:01:16 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 29 Jan 2022 14:01:16 GMT Subject: RFR: 8251481: TableCell accessing row: NPE on auto-sizing [v3] In-Reply-To: References: Message-ID: <0KfzvfTmEt753F_yPzBc4bLtS9uvXaAvy8Np7SSqLcM=.e84d2e84-14e4-42ad-ad7f-2a9aa6b704c1@github.com> On Thu, 27 Jan 2022 20:38:56 GMT, Marius Hanl wrote: >> This PR will fix a simple NPE which may happens when using the `TableRow` inside a `TableCell` during the initial auto sizing. >> In the auto sizing code, no `TableRow` is set, therefore `getTableRow()` will return null and it is not possible to e.g. access the row item. >> >> This is fixed by adding the `TableRow` in the `resizeColumnToFitContent` method, similar as it is already done for the `TreeTableView` (`TreeTableRow`). > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8251481: Using global stageLoader now looks good (there's one minor thingy in completely aligning the test for TreeTable) modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableCellTest.java line 690: > 688: */ > 689: @Test > 690: public void testRowIsNotNullWhenAutoSizing() { same as autosizing test for TableCell: would like the issue id :) ------------- Marked as reviewed by fastegal (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/716 From aghaisas at openjdk.java.net Mon Jan 31 12:38:17 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 31 Jan 2022 12:38:17 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout [v4] In-Reply-To: References: Message-ID: <8g84uTwxP2cxP9Tvhw7WxF2acXkYCZkMoDWY9S7DuHU=.a8ccf23a-560c-4fb0-af1c-3ca4df2c4e04@github.com> On Thu, 27 Jan 2022 20:48:40 GMT, Marius Hanl wrote: >> When a divider is moved via drag or code it will call **requestLayout()** for the **SplitPane**. >> While this is fine, it is also called when the **SplitPaneSkin#layoutChildren(..)** method is repositioning the divider. >> >> This makes no sense since we are currently layouting everything, so we don't need to request it again. (The divider positioning is the first part of **layoutChildren(..)**. In the second part the SplitPane content is layouted based off those positions) >> >> -> With this behaviour the layout may hang under some conditions (check attached source). The problem is that the **requestLayout()** will mark the **SplitPane** dirty but won't propagate to the parent since the **SplitPane** is currently doing a layout. >> >> This PR fixes this by not requesting layout when we are currently doing it (and thus repositioning the dividers as part of it). >> >> Note: I also fixed a simple typo of a private method in SplitPaneSkin: >> initializeDivderEventHandlers -> initializeDiv**i**derEventHandlers > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8277122: Added and used global stageLoader + changed copyright year to 2022 The fix looks good. +1. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/669 From fastegal at swingempire.de Mon Jan 31 14:57:38 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Mon, 31 Jan 2022 15:57:38 +0100 Subject: JBS: possibilty to merge issues? Message-ID: <20220131155738.Horde.HmnjrIdwPTvwYbLqW3ypvA5@webmail.df.eu> Currently working on two related issues: https://bugs.openjdk.java.net/browse/JDK-8187309: TreeCell must not change data of treeView https://bugs.openjdk.java.net/browse/JDK-8187473: TreeView must have default commit handler which are so intertwined that there's no way to fix one without the other (we must have a default commit mechanism in place at any time). I could merge them in the PR (also-fixes), but would feel cleaner to merge in JBS, if possible. -- Jeanette From mhanl at openjdk.java.net Mon Jan 31 15:03:15 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Mon, 31 Jan 2022 15:03:15 GMT Subject: Integrated: 8277122: SplitPane divider drag can hang the layout In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 14:34:04 GMT, Marius Hanl wrote: > When a divider is moved via drag or code it will call **requestLayout()** for the **SplitPane**. > While this is fine, it is also called when the **SplitPaneSkin#layoutChildren(..)** method is repositioning the divider. > > This makes no sense since we are currently layouting everything, so we don't need to request it again. (The divider positioning is the first part of **layoutChildren(..)**. In the second part the SplitPane content is layouted based off those positions) > > -> With this behaviour the layout may hang under some conditions (check attached source). The problem is that the **requestLayout()** will mark the **SplitPane** dirty but won't propagate to the parent since the **SplitPane** is currently doing a layout. > > This PR fixes this by not requesting layout when we are currently doing it (and thus repositioning the dividers as part of it). > > Note: I also fixed a simple typo of a private method in SplitPaneSkin: > initializeDivderEventHandlers -> initializeDiv**i**derEventHandlers This pull request has now been integrated. Changeset: ee52d146 Author: Marius Hanl Committer: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/ee52d14653996921a9bd30e9b568151d3d4d06de Stats: 84 lines in 2 files changed: 76 ins; 1 del; 7 mod 8277122: SplitPane divider drag can hang the layout Reviewed-by: fastegal, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/669 From kevin.rushforth at oracle.com Mon Jan 31 15:13:09 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 31 Jan 2022 07:13:09 -0800 Subject: JBS: possibilty to merge issues? In-Reply-To: <20220131155738.Horde.HmnjrIdwPTvwYbLqW3ypvA5@webmail.df.eu> References: <20220131155738.Horde.HmnjrIdwPTvwYbLqW3ypvA5@webmail.df.eu> Message-ID: <0b4fa041-c3bd-0823-28fd-635a9bb7216c@oracle.com> Based on your description, it seems fine to combine them. To do this, just closed one of the (probably 8187473) as a duplicate of the other, and add any information from the closed bug into the other one, adjusting the title of the bug if needed. -- Kevin On 1/31/2022 6:57 AM, Jeanette Winzenburg wrote: > > Currently working on two related issues: > > https://bugs.openjdk.java.net/browse/JDK-8187309: TreeCell must not > change data of treeView > https://bugs.openjdk.java.net/browse/JDK-8187473: TreeView must have > default commit handler > > which are so intertwined that there's no way to fix one without the > other (we must have a default commit mechanism in place at any time). > I could merge them in the PR (also-fixes), but would feel cleaner to > merge in JBS, if possible. > > -- Jeanette > From fastegal at swingempire.de Mon Jan 31 15:24:53 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Mon, 31 Jan 2022 16:24:53 +0100 Subject: JBS: possibilty to merge issues? In-Reply-To: <0b4fa041-c3bd-0823-28fd-635a9bb7216c@oracle.com> References: <20220131155738.Horde.HmnjrIdwPTvwYbLqW3ypvA5@webmail.df.eu> <0b4fa041-c3bd-0823-28fd-635a9bb7216c@oracle.com> Message-ID: <20220131162453.Horde.zWO9OSMl5lFweDsx2koP8Q1@webmail.df.eu> will do, thanks Kevin :) Zitat von Kevin Rushforth : > Based on your description, it seems fine to combine them. To do > this, just closed one of the (probably 8187473) as a duplicate of > the other, and add any information from the closed bug into the > other one, adjusting the title of the bug if needed. > > -- Kevin > > > On 1/31/2022 6:57 AM, Jeanette Winzenburg wrote: >> >> Currently working on two related issues: >> >> https://bugs.openjdk.java.net/browse/JDK-8187309: TreeCell must not >> change data of treeView >> https://bugs.openjdk.java.net/browse/JDK-8187473: TreeView must >> have default commit handler >> >> which are so intertwined that there's no way to fix one without the >> other (we must have a default commit mechanism in place at any >> time). I could merge them in the PR (also-fixes), but would feel >> cleaner to merge in JBS, if possible. >> >> -- Jeanette >>